[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07                                       
Network Working Group                                      Derrell Piper
INTERNET-DRAFT                                           Network Alchemy
draft-ietf-ipsec-isakmp-gss-auth-01.txt                December 18, 1997

            A GSS-API Authentication Mode for ISAKMP/Oakley

Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and 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.''

   To learn the current status of any Internet Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Australia), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.  This draft will expire six
   months from date of issue.

1. Abstract

   This document describes an alternate authentication method for
   ISAKMP/Oakley which makes use of GSS-API to authenticate the Diffie-
   Hellman exchange.  The mechanism described here extends the
   authentication modes defined in [Harkins97] without introducing any
   modifications to the ISAKMP/Oakley key exchange protocol.  This
   constraint however, necessarily restricts the number of GSS-API
   exchanges and may limit the broader applicability of this method.
   Additional work is needed to provide a fully generalized solution.
   Such a solution will require ISAKMP/Oakley protocol modifications.

   For a list of changes since the previous version of the IPSEC DOI,
   please see Section 5.

Piper                      Expires in 6 months                  [Page 1]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

2. Terms and Definitions

   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC 2119].

2.1 Notation

   [Harkins97] uses the following notation throughout that draft.  That
   notation is included here along with a few additions.

      HDR is an ISAKMP header whose exchange type is the mode.  When
      written as HDR* it indicates payload encryption.

      SA is an SA negotiation payload with one or more proposals. An
      initiator MAY provide multiple proposals for negotiation; a
      responder MUST reply with only one.

      <P>_b indicates the body of payload <P>-- the ISAKMP generic
      payload is not included.

      SAi_b is the entire body of the SA payload (minus the ISAKMP
      generic header)-- i.e. the DOI, situation, all proposals and all
      transforms offered by the Initiator.

      CKY-I and CKY-R are the Initiator's cookie and the Responder's
      cookie, respectively, from the ISAKMP header.

      g^xi and g^xr are the Diffie-Hellman public values of the
      initiator and responder respectively.

      g^xy is the Diffie-Hellman shared secret.

      GIi and GIr are identity name strings for the GSS-API initiator
      and responder GSS-API endpoints.  These name strings are private
      to GSS-API.

      GSSi and GSSr are the initiator and responder GSS-API tokens
      generated by the local GSS-API's using GSS_Init_sec_context and
      GSS_Accept_sec_context respectively.

      GSSIi and GSSIr are the concatenation of optional GSS-API identity
      strings and either GSSi or GSSr for the initiator and responder

      KE is the key exchange payload which contains the public
      information exchanged in a Diffie-Hellman exchange. There is no
      particular encoding used for the data of a KE payload.

Piper                      Expires in 6 months                  [Page 2]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

      Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
      and responder respectively.

      IDx is the identity payload for "x".  x can be: "ii" or "ir" for
      the ISAKMP initiator and responder respectively during phase one
      negotiation; or "ui" or "ur" for the user initiator and responder
      respectively during phase two.  The ID payload format for the
      Internet DOI is defined in [Pip97].

      HASH (and any derivative such as HASH(2) or HASH_I) is the hash
      payload. The contents of the hash are specific to the
      authentication method.

      prf(key, msg) is the keyed pseudo-random function-- often a keyed
      hash function-- used to generate a deterministic output that
      appears pseudo-random.  prf's are used both for key derivations
      and for authentication (i.e. as a keyed MAC).

      SKEYID is a string derived from secret material known only to the
      active players in the exchange.

      SKEYID_e is the keying material used by the ISAKMP SA to protect
      it's messages.

      SKEYID_a is the keying material used by the ISAKMP SA to
      authenticate it's messages.

      SKEYID_d is the keying material used to derive keys for non-ISAKMP
      security associations.

      <x>y indicates that "x" is encrypted with the key "y".

      --> signifies "initiator to responder" communication (requests).

      <-- signifies "responder to initiator" communication (replies).

      | signifies concatenation of information-- e.g. X | Y is the
      concatenation of X with Y.

      [x] indicates that x is optional.

   Payload encryption (when noted by a '*' after the ISAKMP header) MUST
   begin immediately after the ISAKMP header. When communication is
   protected, all payloads following the ISAKMP header MUST be
   encrypted.  Encryption keys are generated from SKEYID_e in a manner
   that is defined for each algorithm.

Piper                      Expires in 6 months                  [Page 3]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

3. Discussion

   The ISAKMP/Oakley resolution document ([Harkins97]) defines a key
   negotiation protocol that blends the Oakley key determination
   protocol ([Orman97]) with ISAKMP ([Maughan97]) to provide
   authenticated cryptographic key exchange for use with IP security
   protocols (e.g. AH/ESP).  The ISAKMP/Oakley negotiation includes an
   authentication method negotiation which is used to select a scheme to
   be used for authenticating a Diffie-Hellman key exchange.  There are
   currently five defined authentication methods: pre-shared key, DSS
   signature, RSA signature, and two forms of RSA encryption.  This
   document defines a new method that uses the Generic Security Services
   API ([Linn97]) to provide the necessary authentication.

   The GSS-API abstraction is that a host operating system provides an
   API to applications that request security services (e.g. integrity
   protection or confidentiality) through a formal interface (e.g.,
   [Wray97]).  GSS-API provides opaque tokens to applications which are
   responsible for sending the tokens to peer GSS-API implementations,
   presumably on remote hosts.  A by-product of any GSS-API exchange is
   a one way or mutual authentication using whatever authentication
   scheme the application chose to bind to when GSS-API was initialized
   (or whatever was negotiated by SNEGO ([Pinkas97])).  Typical
   authentication packages include Kerberos and SSL.

   The ISAKMP/Oakley resolution defines a Main Mode and an Aggressive
   Mode for establishing Security Associations (SA's) between IPSEC
   hosts.  These modes have a fixed set of round-trips: 4.5 or 5 for
   Main Mode and 1 or 1.5 for Aggressive (depending on whether the
   Commit bit ([ISAKMP], Section 3.1) is used by the responder).

   When using GSS-API, there's a separate protocol being run by the GSS-
   API packages on the initiator and on the responder.  (Initiator and
   responder are ISAKMP terms, both are GSS-API clients.)  The basic
   model is that the ISAKMP/Oakley initiator calls GSS_Init_sec_context
   (with mutual_req_flag) to construct a GSS-API token and sends this
   along with the KE and nonce in the second Main Mode exchange.  The
   responder calls GSS_Accept_sec_context on this token and sends the
   output of GSS_Accept_sec_context (another token) back along with his
   KE and his nonce.  On receipt of the responder's token, the initiator
   calls GSS_Init_sec_context a second time to complete the mutual
   authentication.  Finally, each side exchanges a HASH payload which
   has been wrapped using GSS_Wrap.  Successfully calling GSS_Unwrap to
   unwrap the HASH payloads along with verfiying the hashes proves
   possesion of the GSS-API shared secret and authenticates the Diffie-
   Hellman exchange.

   GSS-API requires that a client identify the target GSS-API endpoint

Piper                      Expires in 6 months                  [Page 4]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

   by name.  If the initiator does not already know the GSS-API endpoint
   name of the ISAKMP target, a new Phase 1 attribute can be used to
   exchange endpoint names during the first Main Mode round trip
   (Section 4.3).  Note that these name string are bound to the exchange
   but otherwise unauthenticated.  The GSS-API endpoint names are also
   assumed to be opaque.

   Since the GSS-API tokens are exchanged during Phase 1 along with the
   KE payloads, they are not protected by the (yet to be formed) ISAKMP
   SA.  To prevent a cut/paste attack on the GSS-API tokens, it's
   therefore necessary to include the tokens in the HASH_I and HASH_R
   computation (Section 4.1).  This binds the tokens to a particular
   ISAKMP exchange.  If used, the GSS Identity Name strings MUST also be
   included in these hash calculations.

   In addition, the output from the prf for each hash is wrapped using
   GSS_Wrap.  Upon receipt of either hash payload, each side MUST
   successfully call GSS_Unwrap.  This proves possession of the GSS-API
   shared secret by each peer and prevents an active man-in-the-middle
   attack from simply forwarding on the GSS-API tokens.  The choice of
   whether to use integrity protection only or integrity with
   confidentiality is somewhat mechanism specific.  However, since the
   strength of the algorithm chosen necessarily determines the outcome
   of the authentication for ISAKMP, the strongest possible protection
   SHOULD be chosen.  The following flags should be specified to
   GSS_Init_sec_context on the initiating side:

           Flag                    Requirement
           ----                    -----------
           mutual_req_flag         MUST
           integ_req_flag          MUST
           conf_req_flag           SHOULD

   If the GSS-API authentication cannot be completed in 1.5 round-trips,
   the method described in this document will not work.  To fully
   generalize this extension, a new XCHG type will need to be created
   that allows for any number of GSS-API exchanges but is otherwise
   similar to the existing Main Mode exchange.  A single Main Mode-like
   XCHG type is probably sufficient since there would be little use for
   an Aggressive Mode construct given the open ended nature of GSS-API.

   The primary motivation for this work was to integrate Kerberos
   authentication into ISAKMP/Oakley in an environment where the host
   operating system did not expose the underlying Kerberos
   authentication services except as a GSS-API package.  Since the
   details of the host operating system's Kerberos package were known,
   the limitations described above were addressed in a reasonable manner
   by simply failing the ISAKMP/Oakley negotiation when the GSS-API's

Piper                      Expires in 6 months                  [Page 5]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

   failed to converge in the requisite number of round-trips.  When
   implemented this way, this event SHOULD be auditable and should
   clearly differentiate this type of authentication failure from one
   caused by truly bad credentials.

4.1 SKEYID Generation for GSS-API

   [Harkins97] defines several authentication methods for Main Mode or
   Aggressive Mode -- digital signatures, authentication using public
   key encryption, and pre-shared keys.  This document introduces
   another and defines the value of SKEYID for GSS-API authentication as

     For GSS-API:               SKEYID = prf(Ni_b | Nr_b, g^xy)

   To authenticate either exchange the initiator of the protocol
   generates HASH_I and the responder generates HASH_R where:

     HASH_I = GSS_Wrap(prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b |
                  IDii_b | GSSIi))

     HASH_R = GSS_Wrap(prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b |
                  IDir_b | GSSIr))

   For authentication using GSS-API, the GSS-API package on either side
   provides authentication of the GSS-API identities, and HASH_I and
   HASH_R are used to bind the GSS-API identities and tokens to the Main
   Mode exchange.  The GSS_Wrap (and subsequent GSS_Unwrap) proves
   possession of the GSS-API shared secret for each peer.  The initiator
   MUST specify the mutual_req_flag to request mutual authentication
   between the two GSS-API packages.  A provision is defined for the
   GSS-API peers to exchange GSS-API identities during Main Mode, at the
   expense of identity protection for the GSS-API endpoint identities.

4.2 ISAKMP/Oakley Phase 1 Authenticated With GSS-API

   Using GSS-API, the ancillary information exchanged during the second
   roundtrip are GSS-API tokens; the exchange is authenticated in GSS-
   API and the GSS-API tokens are bound to the exchange using HASH_I and

   If the GSS-API requires that the initiator and responder have prior
   knowledge of the GSS-API endpoint names for each peer, this
   information may be exchanged during the first round trip (by
   including the GSS Identity Name attribute in the SA) at the expense
   of identity protection for the GSS-API endpoints. When the GSS-API
   requires the exchange of identity names, Aggressive Mode cannot be

Piper                      Expires in 6 months                  [Page 6]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

              Initiator                        Responder
             ----------                       -----------
              HDR, SA             -->
                                  <--    HDR, SA
              HDR, KE, Ni, GSSi   -->
                                  <--    HDR, KE, Nr, GSSr
              HDR*, IDii, HASH_I  -->
                                  <--    HDR*, IDir, HASH_R

   Aggressive mode using GSS-API is defined as

              Initiator                        Responder
             -----------                      -----------
              HDR, SA, KE, Ni,
                IDii, GSSi        -->
                                  <--    HDR, SA, KE, Nr,
                                           IDir, GSSr, HASH_R
              HDR, HASH_I         -->

4.3 GSS-API Identifiers and Attributes

   Implementations using the GSS-API Authentication Mode will need to
   agree on the following values.  These numbers are simply the
   beginning of the "private use" range for each particular list.

   - Authentication Method
      Authentication with GSS-API         65001

     Attribute Classes

            class                         value              type
        GSS Identity Name                 32001               B/V

   - GSS Identity Name

     When using the GSS-API authentication mode, the GSS Identity Name
     attribute may be used to pass the GSS-API endpoint names for the
     initiator and responder.  The format for these name strings are
     private to GSS-API.

5. Change Log

5.1 Changes from V0

     o  GSSIi and GSSIr are required; removed optional brackets
     o  added text for GSS_Wrap/GSS_Unwrap over HASH_I and HASH_R

Piper                      Expires in 6 months                  [Page 7]

INTERNET DRAFT          GSS-API for ISAKMP/Oakley      December 18, 1997

6. Security Considerations

   This entire draft pertains to a negotiated key management protocol,
   combining Oakley ([Orman97]) with ISAKMP ([Maughan97]), which
   negotiates and derives keying material for security associations in a
   secure and authenticated manner.  Specific discussion of the various
   security protocols and transforms identified in this document can be
   found in the associated base documents, in the cipher references, and
   throughout this document.


   Thanks to Dan Harkins for reviewing the early drafts and for allowing
   me to liberate the notation from [Harkins97].  Special thanks to Bill
   Sommerfeld, Ran Canetti, Pau-Chen Cheng, and Hugo Krawczyk for
   pointing out problems in previous versions of this document.


   [Harkins97] Harkins, D., Carrel, D., "The Resolution of ISAKMP with
   Oakley," draft-ietf-ipsec-isakmp-oakley-05.txt.

   [Linn97] Linn, J., "Generic Security Service Application Program
   Interface, Version 2, Update 1," draft-ietf-cat-rfc2078bis-01.txt.

   [Maughan97] Maughan, D., Schertler, M., Schneider, M., and Turner,
   J., "Internet Security Association and Key Management Protocol
   (ISAKMP)," draft-ietf-ipsec-isakmp-08.{ps,txt}.

   [Orman97] H. K. Orman, "The OAKLEY Key Determination Protocol,"

   [Pinkas97] Pinkas, D., Baize, E., "The Simple and Protected GSS-API
   Negotiation Mechanism," draft-ietf-cat-snego-07.txt.

   [Wray97] Wray, J., "Generic Security Service API Version 2 : C-
   bindings," draft-ietf-cat-gssv2-cbind-04.txt (supercedes RFC-1509).

Author's Address:

   Derrell Piper <ddp@network-alchemy.com>
   Network Alchemy
   1521.5 Pacific Ave
   Santa Cruz, California, 95060
   United States of America
   +1 408 460-3822

Piper                      Expires in 6 months                  [Page 8]