Internet DRAFT - draft-adamson-nfsv4-spkm3

draft-adamson-nfsv4-spkm3






Network Working Group                                         W. Adamson
Internet-Draft                                           O. Kornievskaia
Expires: April 17, 2006                                 October 14, 2005


         Low Infrastructure Mutual Authentication Using SPKM-3
                    draft-adamson-nfsv4-spkm3-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memorandum describes a method whereby one can use GSS-API
   [RFC2078] to supply a secure channel between a user on a client and a
   server, authenticating both the user and server with public key
   certificates [RFC3280], without the need for an external Public Key
   Infrastructure for certificate verification.  The method leverages
   the existing Simple Public Key Mechanism Version 3 (SPKM-3)
   [RFC2847].  In addition to describing the use of SPKM-3 for mutual
   authentication, this memorandum updates RFC2847, reflecting
   implementation experience.



Adamson & Kornievskaia    Expires April 17, 2006                [Page 1]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Mutual Authentication Requirements of SPKM-3 . . . . . . . . .  4
     2.1   SPKM_REQ token . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1   requestToken . . . . . . . . . . . . . . . . . . . . .  4
       2.1.2   certif-data  . . . . . . . . . . . . . . . . . . . . .  5
     2.2   SPKM-REP-TI token  . . . . . . . . . . . . . . . . . . . .  5
     2.3   SPKM-REP-IT token  . . . . . . . . . . . . . . . . . . . .  5
   3.  Clarifications . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Naming . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2   Certificates . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3   Misc for now . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   A.  Appendix A: Imported Types . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 12
































Adamson & Kornievskaia    Expires April 17, 2006                [Page 2]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This memorandum describes the use of SPKM-3 to provide mutual
   authentication between a user with public key certificates [RFC3280],
   and a server with public key certificates.  Mutual authentication can
   be accomplished via the Simple Public Key Mechanism (SPKM) [RFC2025],
   but requires a great deal of public key infrastructure.  SPKM-3 can
   perform mutual authentication in the case of no public key
   infrastructure, where the target and initiator have no knowledge of
   each others certificates and no way to obtain them except through
   SPKM.




































Adamson & Kornievskaia    Expires April 17, 2006                [Page 3]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


2.  Mutual Authentication Requirements of SPKM-3

   SPKM-3 describes a method of obtaining a secure channel between an
   anonymous user on the client an a server.  The secure channel is then
   used by the LIPKEY GSS-API mechanism [RFC2847] to transport a
   username and password to the server.  This section describes some
   changes to how SPKM-3 operates in order to realize the low
   infrastructure model of mutual authentication.

2.1  SPKM_REQ token

   The initiator constructs an SPKM-REQ token as described for anonymous
   authentication in [RFC2847] SPKM-3 with the following changes.

2.1.1  requestToken

   The SPKM-REQ token contains a required requestToken.

2.1.1.1  Key Establishment Algorithm (K-ALG)

   The requestToken has a req-contents, which has a key-estb-set.  The
   key-estb-set must be dhKeyAgreement, because the initiator doesn't
   know the target's public key, and so cannot encrypt a session key
   with the target's public key.  And the initiator can't encrypt a
   session with her private key, because then anyone will be able to
   know what the session key is since the initiator's public key is,
   well, public.

2.1.1.2  target-certif-data-required

   The requestToken has a req-contents, which has a req-data, which has
   an options field.  The target-certif-data-required option must be
   set.  While this is not a difference from anonymous authentication
   defined in [RFC2847] SPKM-3, it is mentioned because it is critical.

2.1.1.3  mutual-state

   The req-data options field also contains a mutual-state option which
   must be set to TRUE.  As noted in [RFC2025], this derives from the
   mutual-req-flag provided to the GSS-API gss_init_sec_context call.

2.1.1.4  Alg-Id

   The requestToken has an algId field used for the req-integrity field.
   The algId needs to be one of id-dsa-with-sha1, md4WithRSAEncryption,
   or sha1WithRSAEncryption.  The signature will be based on the
   initiator's certificate in the userCertif field (Section 2.1.2).




Adamson & Kornievskaia    Expires April 17, 2006                [Page 4]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


2.1.2  certif-data

   The SPKM-REQ token contains an optional certif-data.  The certif-data
   has an optional certificationPath field.  The certificationPath field
   has an optional userCertif field which contains the user Certificate.
   This field needs to be set, because it is needed in order for the
   target to authenticate the initiator in a later step.

2.2  SPKM-REP-TI token

   The target verifies the initiator's SPKM-REQ token by verifying that
   the req-integrity field was computed by the owner of the userCertif
   field.  This is phase 1 of authenticating the target.  The target
   produces the SPKM-REP-TI token as defined in [RFC2847] and [RFC2025].

2.3  SPKM-REP-IT token

   Unlike [RFC2847], because mutual authentication was requested, the
   initiator must construct a SPKM-REP-IT token.  This is because
   attackers could replay SPKM-REQ tokens, and since the target doesn't
   have an infinite cache, and since SPKM-1 and SPKM-3 do not require
   synchronized time, a 3-way handshake is needed.

   It should be mostly clear from [RFC2025](Section 3.1.3) how to do
   this.  However, there's one point that isn't clear.  The randTarg
   field in the SPKM-REP-IT responseToken is randomly generated by the
   initiator, and so should be the same value that was in the
   SPKM-REP-TI rep-ti-contents randTarg field.  Similarly, the randSrc
   field in the SPKM-REP-TI rep-ti-contents is the same value as the
   SPKM-REQ requestToken req-contents randSrc field.

   The SPKM-REP-IT token algId field used to create the rep-it-integ
   field should use id-dsa-with-sha1, md5WithRSAEncryption, or
   sha1WithRSAEncryption.  The initiator verifies the SPKM-REP-IT token
   by verifying that the req-it-integ field was computed by the owner of
   the targets certificate, obtained in the SPKM-REP-TI certif-data
   certificationPath userCertif field.














Adamson & Kornievskaia    Expires April 17, 2006                [Page 5]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


3.  Clarifications

3.1  Naming

   In this section, we clarify the construction and verification of
   names in SPKM-3.  Names are constructed by both the initiator and the
   target.  The initiator always constructs a target name.  When mutual
   authentication is requested, the initiator also constructs a source
   name.  The initiator retrieves its source name information (ie., the
   Distinguished Name) from its own certificate which the initiator
   acquired by calling GSS_acquire_cred().  The initiator should encode
   the source name in a single RDN sequence and use a
   GSS_SPKM_NT_USER_NAME name type.  The target, like the initiator,
   constructs the target name using its certificate, but uses a
   GSS_SPKM_NT_MACHINE_UID_NAME name type.

   We assume that during the construction of the REQ_TOKEN the initiator
   has no access to the target's certificate and therefore has to
   construct the target name with the information provided by the
   application which might be of the form "service@host".  In such case,
   the initiator should convert the name to a common name "CN=service/
   host", encoded in a single RDN sequence, and use a
   GSS_SPKM_NT_MACHINE_UID_NAME name type.

   During the validation of a name (either when the target validates the
   name of the initiator or vice versa), a match occurs:

   o  if the target name is the same as the subject name or a DN entry
      for the subject alternate name in the target certificate.

   o  if the target name is just a common name and the common name
      matches the CN portion of the subject name or the CN portion of a
      DN entry for the subject alternate name in the target certificate.

   o  if the target name is a service name ("CN=service/host") and the
      host matches the CN portion of the subject name or a DNS entry for
      the subject alternate name in the target certificate.

   For anonymous SPKM-3, GSS_display_name() returns the string
   "<anonymous>".  Define an OID for it?

3.2  Certificates

   SPKM-3 must support X509 v3 certificates.

   In SPKM-3, certificate validation follows the SSL model where the
   source provides its certificate and the certification chain up to the
   root certificate.  The target then provides its certificate and the



Adamson & Kornievskaia    Expires April 17, 2006                [Page 6]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


   certification chain up to the root certificate.  Thus, the
   certification data consists of the forward root certificate followed
   by any reverse certificates required to reach the user certificate.

   In authenticated SPKM-3, both parties (initiator and target) always
   send their certificates and certification chains.  Consequently, the
   field target-certif-data-required is always TRUE.  Also, in SPKM-
   REP_TI the certif-data field is no longer OPTIONAL.

3.3  Misc for now

   o  padding in cast5.

   o  how to generate 8byte DES key from the key material.

   o  key length for hmac-md5.

   o  encoding of DH parameters and keys.

   o  add AES to C-ALG.

   o  channel binding.

   o  clarify the description of the "Integrity" field in SPKM-3 tokens.

   o  spkm3_parse_token() should not be a mandatory function.

   o  Numbering of bits in ASN1 BIT_STRING is left-to-right.























Adamson & Kornievskaia    Expires April 17, 2006                [Page 7]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


4.  Issues

   SPKM-3 should not use NULL-MAC or md5WithRSAEncryption as integrity
   algorithms for exchange of messages after the security context has
   been established.  By doing a DH key agreement, the initiator and the
   target establish a symmetric key which can be used by HMAC-md5 (or a
   like protocols).  Trying to use NULL-MAC reduces security because
   only hashing is performed on a message and using md5WithRSAEncryption
   reduces performances because a public key operation (signing) is
   applied to every message.

   In anonymous SPKM-3, the only choice for the integrity algorithm in
   the REQ-TOKEN is NULL-MAC.  HMAC-MD5 cannot be used because no
   symmetric key has been established. md5WithRSAEncryption cannot be
   used because the initiator does not have a certificate.

   In SPKM-3, the only choice for the integrity algorithm in the REP-TI-
   TOKEN is md5WithRSAEncryption.  In anonymous case, to avoid the man-
   in-the-middle attack, the target has to authenticate to the
   initiator.  The target needs to sign the rep-ti-contents using
   md5WithRSAEncryption (or a like protocols).  In mutual
   authentication, the target uses md5WithRSAEncryption to authenticate
   to the initiator.




























Adamson & Kornievskaia    Expires April 17, 2006                [Page 8]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


5.  Security Considerations

   Security issues are discussed throughout this memo.
















































Adamson & Kornievskaia    Expires April 17, 2006                [Page 9]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


Appendix A.  Appendix A: Imported Types

   The ASN.1 types in Appendix B of RFC2025 imported from
   InformationFramework (1993) and AuthenticationFramework (1993), and
   [PKCS3] are outdated.  Both the InformationFrameWork and the
   AuthenticationFramework have moved forward to new versions.
   Implementations of this specification MUST be capable of processing
   the Version 3 X.509 certificates and extensions described in the
   RFC3280 appendix A.1 "Explicitly Tagged Module, 1988 Syntax" with the
   following OID.

   PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
   internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-
   explicit(18) }

6.  References

   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
              (SPKM)", RFC 2025, October 1996.

   [RFC2078]  Linn, J., "Generic Security Service Application Program
              Interface, Version 2", RFC 2078, January 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2847]  Eisler, M. and Zambeel, "LIPKEY - A Low Infrastructure
              Public Key Mechanism Using SPKM", RFC 2847, June 2000.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.


Authors' Addresses

   William A. (Andy) Adamson
   CITI, University of Michigan
   535 W. William
   Ann Arbor MI 48103
   USA

   Email: andros@umich.edu







Adamson & Kornievskaia    Expires April 17, 2006               [Page 10]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


   Olga Kornievskaia

   Email: aglo@umich.edu
















































Adamson & Kornievskaia    Expires April 17, 2006               [Page 11]

Internet-Draft             SPKM-3 Mutual Auth               October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Adamson & Kornievskaia    Expires April 17, 2006               [Page 12]