[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         J. Salowey
Internet-Draft                                             Cisco Systems
Expires: December 27, 2006                                 June 25, 2006


   Guidelines for Creating Generally Useful Authentication Mechanisms
                                 (GUAM)
                     draft-salowey-guam-mech-01.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 December 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Generic Security Services API (GSS-API), the Simple Authentication
   and Security Layer (SASL), and the Extensible Authentication Protocol
   (EAP) are three authentication and frameworks used within the IETF
   that have similar goals.  This document describes guidelines for
   creating authentication mechanisms that are generally usable in any
   of these frameworks.





Salowey                 Expires December 27, 2006               [Page 1]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


Table of Contents

   1.   Requirements notation  . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1  GSS-API Model  . . . . . . . . . . . . . . . . . . . . . .   4
     2.2  SASL Model . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3  EAP Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Mechanism Guidelines . . . . . . . . . . . . . . . . . . . .   6
     3.1  Mechanism Naming . . . . . . . . . . . . . . . . . . . . .   6
     3.2  Framing and Protocol . . . . . . . . . . . . . . . . . . .   6
     3.3  Mechanism Security Properties  . . . . . . . . . . . . . .   8
     3.4  Key Derivation . . . . . . . . . . . . . . . . . . . . . .   9
     3.5  Security Layer . . . . . . . . . . . . . . . . . . . . . .  10
     3.6  Target Identification  . . . . . . . . . . . . . . . . . .  10
     3.7  Session Identification . . . . . . . . . . . . . . . . . .  12
     3.8  Channel Binding  . . . . . . . . . . . . . . . . . . . . .  12
     3.9  Principal Naming and Attributes  . . . . . . . . . . . . .  14
     3.10   Mechanism Negotiation  . . . . . . . . . . . . . . . . .  15
     3.11   Indentity Protection . . . . . . . . . . . . . . . . . .  16
     3.12   Fast Reconnect . . . . . . . . . . . . . . . . . . . . .  16
   4.   Tools for creating GUAM mechanisms . . . . . . . . . . . . .  17
     4.1  Mechanism Bridges  . . . . . . . . . . . . . . . . . . . .  17
     4.2  Protocol Initiation  . . . . . . . . . . . . . . . . . . .  17
     4.3  Generic PRF  . . . . . . . . . . . . . . . . . . . . . . .  17
     4.4  Generic Per-Message Security Layer . . . . . . . . . . . .  17
     4.5  Fragmentation Support  . . . . . . . . . . . . . . . . . .  18
     4.6  Channel Binding and Authenticated Data . . . . . . . . . .  18
     4.7  Fast Reconnect . . . . . . . . . . . . . . . . . . . . . .  18
     4.8  Mechanism Naming . . . . . . . . . . . . . . . . . . . . .  18
     4.9  Naming . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   5.   Interface Specification  . . . . . . . . . . . . . . . . . .  20
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  21
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  22
     7.1  Same mechanism accessed through different frameworks . . .  22
     7.2  Algorithm identification and negotiation . . . . . . . . .  22
   8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  23
   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1  Normative References . . . . . . . . . . . . . . . . . . .  24
     9.2  Informative References . . . . . . . . . . . . . . . . . .  24
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . . . . .  26










Salowey                 Expires December 27, 2006               [Page 2]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


1.  Requirements notation

   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].














































Salowey                 Expires December 27, 2006               [Page 3]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


2.  Introduction


2.1  GSS-API Model

   The Generic Security Service Application Program Interface (GSS-API)
   [RFC2743] defines interface into security modules for the purpose of
   establish a security context between two peers.  The peers are
   usually identified as the GSS-API context initiator and the GSS-API
   context acceptor.  GSS-API is generally applicable in a wide variety
   of situations, however it is most often used in application layer
   protocols.

   +-----------+                              +-----------+
   |           |        Authentication        |           |
   |  GSS-API  |<---------------------------->|  GSS-API  |
   |  Context  |                              |  Context  |
   | Initiator |      Message Protection      |  Acceptor |
   |           |<---------------------------->|           |
   +-----------+                              +-----------+

   GSS-API can provide optional message protection services between the
   GSS-API initiator and Acceptor.

2.2  SASL Model

   The Simple Authentication and Security Layer (SASL) provides a
   framework for providing authentication and security services between
   a SASL Client and a SASL Server.  SASL provides an abstraction layer
   between application protocols and authentication mechanisms.  SASL is
   generally applicable within application layer protocols.

   +-----------+                              +-----------+
   |           |        Authentication        |           |
   |    SASL   |<---------------------------->|   SASL    |
   |   Client  |                              |  Server   |
   |           |    Octet Stream Protection   |           |
   |           |<---------------------------->|           |
   +-----------+                              +-----------+


2.3  EAP Model

   The Extensible Authentication Protocol (EAP) [RFC3748] defines a
   protocol for performing authentication between two entities.  EAP is
   generally applicable for network access authentication.  The protocol
   allows different authentication mechanisms through different EAP
   methods.  The EAP conversation is carried in a lower layer protocol



Salowey                 Expires December 27, 2006               [Page 4]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   between the EAP Peer and EAP Authenticator, however the EAP
   authentication conversation is actually terminated in a logical
   entity known as the EAP server.  The EAP server may be co-located
   with the EAP authenticator or it may be located on a physically
   separate device such as a AAA server.  When the EAP server is
   separated from the EAP authenticator the authenticator device
   operates in pass-through mode.  Message protection is not provided by
   EAP, however it is common for key material from the authentication
   exchange to be exported from the EAP server to the EAP authenticator
   so it can be used in lower layer message protection schemes.  The
   export of the key material outside the EAP Server and the message
   protection between the EAP Peer and the EAP Authenticator is done
   outside the EAP protocol.

   +--------+                  +-----------+                 +---------+
   |        |                  Authentication                |         |
   |        |<---------------------------------------------->|         |
   |  EAP   |                  |    EAP    |                 |   EAP   |
   |  Peer  |                  | Authenti- |   Key Material  |  Server |
   |        |  Message Prot.   |   cator   |<----------------|         |
   |        |<---------------->|           |                 |         |
   +--------+                  +-----------+                 +---------+





























Salowey                 Expires December 27, 2006               [Page 5]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


3.  Mechanism Guidelines


3.1  Mechanism Naming

   Each of the frameworks described in Section 2 provides a means to
   identify mechanisms.  A SASL mechanism name as 1 to 20 character
   string selected from a subset of the ASCII character set.  An GSS-API
   mechanism is identified by an ASN.1 OID.  An EAP mechanism is defined
   either by a single by number if it is a normal type mechanism and a 3
   byte SMI vendor indicator followed by a 4 byte type indicator if it
   is an expanded type mechanism.

   The recommendation for general mechanism naming is as follows:

   1.  A GUAM mechanism must provide a mechanism name for use in each of
       these frameworks.


3.2  Framing and Protocol

   All the frameworks rely upon the authentication mechanism to define
   the authentication protocol messages exchanged between the
   authenticating peers.  All the frameworks treat the tokens that are
   exchanged as opaque and can support an arbitrary number of exchanges
   to establish a security context.  The different frameworks have
   different approaches to providing protocol support and framing for
   carrying out authentication exchanges.  From an authentication
   protocol standpoint all the frameworks deal with two entities.  The
   GSS-API initiator, SASL client and EAP peer are equivalent and the
   GSS-API acceptor, SASL server and EAP server are equivalent.

   SASL mechanisms are designed to be embedded in an application
   protocol and require no special framing of messages as this is
   handled in the application layer protocol.  Since SASL runs within a
   connection oriented application protocol there is no consideration
   for the fragmentation or retransmission.  SASL allows either the SASL
   client or the SASL server to initiate the conversation depending on
   the capabilities of the SASL mechanism.  In some cases application
   protocols do not allow to send a server message with a result
   indication.  In these cases the SASL client mechanism may need to
   respond with an empty message to the final server message.  The SASL
   security layer assumes it is running under a reliable connection
   oriented application protocol.

   GSS-API is also designed to be run within the context of another
   protocol which will handle framing, fragmentation, retransmission and
   message exchange.  GSS-API does require that the initial token sent



Salowey                 Expires December 27, 2006               [Page 6]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   between GSS-API initiator and acceptor start with the OID that
   identifies the mechanism, but this is the only required framing.
   GSS-API mechanism exchanges are always initiated by the GSS-API
   context initiator.  GSS-API provides per-message security services
   that may provide replay detection and sequence detection so they may
   be used in protocols that are not connection oriented.

   EAP was designed to be embedded within lower layer protocols that do
   not provide support fragmentation or retransmission.  Therefore EAP
   provides a protocol outside of the authentication protocol provided
   by EAP methods.  This protocol provides basic message framing which
   is required on every EAP message.  The protocol also defines
   retransmission behavior that can be used when the underlying protocol
   does not provide retransmission of lost packets.  EAP does not
   provide fragmentation so it is up to the implementation of individual
   EAP mechanisms to provide this support.  EAP authentication exchanges
   are always initiated from the EAP server side of the conversation.
   The last EAP message in the method conversation is sent from peer to
   server, excluding the EAP Success or failure message.  The EAP
   protocol also includes a negotiation phase which is described in
   Section 3.10 and an unprotected way to indicate success or failure.
   EAP does not provide a security layer or per-message security
   services.  EAP also does not define a way to distribute key material
   from the EAP server to an EAP authenticator.  In the case where the
   EAP server and the EAP authenticator are collocated this is a local
   interface and in the case where they are separated from one another
   the key distribution typically makes use of a AAA protocol such as
   RADIUS or Diameter.

   Another consideration with EAP is often used to perform
   authentication to get authorization to a network.  This means that
   all or some network services may not be available at authentication
   time.  Therefore if the underlying authentication technology requires
   access to network services such as a Kerberos KDC the authentication
   may be impossible.  Mechanism developers should take this into
   consideration and possibly provide additional mechanisms to support
   cases in which network services are not available and authentication
   exchanges need to be carried out through the authenticator.

   The recommendation for handling this in a general mechanism is as
   follows.

   1.  The core authentication protocol messages SHOULD be the same
       regardless of which framework is used.

   2.  A GUAM mechanism MUST define message flows that can be initiated
       from the server/acceptor side or the initiator/client side.




Salowey                 Expires December 27, 2006               [Page 7]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   3.  When operating in GSS-API mode the first message sent from the
       client MUST begin with the GSS-API OID for the mechanism.  When
       operating in first message sent by client mode in other
       frameworks the first message MAY begin with the GSS-API OID for
       the mechanism.  If the mechanism excludes the OID in certain
       frameworks then the absence of the OID MUST NOT create any
       difference in the subsequent message or operation of the
       mechanism.

   4.  GUAM mechanisms MUST define how to do fragmentation.  In order to
       accommodate this a generic fragmentation wrapper should be used.
       The Internet community may develop a fragmentation framework as
       part of a generic framing facility.

   5.  A GUAM mechanism MUST define itself as client initiated, server
       initiated or variable when operating in SASL mode.

   6.  If the last message in the core authentication exchange is sent
       by the server then the client/peer MUST be prepared to send an
       empty message to satisfy the SASL application and EAP
       requirements.  The server/acceptor side of the conversation MUST
       be prepared to accept this empty message when operating in these
       modes.  This along with 2 SHOULD be the only protocol difference
       between the messages used in different frameworks.

   7.  A GUAM mechanism SHOULD take into consideration scenarios where
       network services are not available to an entity wishing to join
       the network and provide mechanisms or modes of operation which do
       not require direct access to network services.  Typically it will
       be the client side of the conversation that does not have access
       to network services.


3.3  Mechanism Security Properties

   This section makes recommendations on the types of security
   properties that a mechanism should have.  This list is taken from
   [RFC3748] and refers to the capabilities of the authentication
   exchange itself and not to subsequent per-message protection or
   security layers.

   1.  A mechanism MUST identify the algorithms in use and provide for
       algorithm agility.  A mechanism SHOULD support ciphersuite
       negotiation for the algorithms used in the authentication
       exchange.

   2.  If a mechanism supports ciphersuite negotiation then it SHOULD be
       protected



Salowey                 Expires December 27, 2006               [Page 8]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   3.  A mechanism MUST support mutual authentication.  For EAP
       mechanisms this means mutual authentication between EAP peer and
       EAP server.

   4.  A mechanism MUST support integrity protection for messages
       exchanged within the authenticated key exchange.

   5.  A mechanism MUST support replay protection for the message
       exchanged within the core authenticated key exchange.

   6.  A mechanism MAY support confidentiality for the message exchanged
       within the core authenticated key exchange.

   7.  A mechanism SHOULD provide passive and active dictionary attack
       resistance.

   8.  A mechanism SHOULD support Session independence so the compromise
       of one session does not compromise previous or subsequent
       sessions

   9.  If a mechanism incorporates or uses another mechanism it SHOULD
       provide a means to cryptographically bind the mechanism exchanges
       together if possible.


3.4  Key Derivation

   All of the frameworks support an authenticated key exchange.  SASL
   does not provide access to generated key material, however key
   material from a SASL exchange may be used in a SASL security layer.
   EAP methods derive two keys, the master session key (MSK) and the
   extended master session key (EMSK).  GSS-API mechanisms can provide
   access to a pseudo-random function that derives keys from the
   underlying authenticated key exchange.

   The recommendations for key derivation in a general mechanism is as
   follows:

   1.  A mechanism MUST support the derivation of key material.

   2.  Mechanisms MUST support a PRF that can interface with the GSS-API
       PRF function.  A default generic PRF may be defined for this
       purpose.

   3.  A mechanism SHOULD provide a way to provide cryptographic agility
       for a PRF.





Salowey                 Expires December 27, 2006               [Page 9]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   4.  A mechanism MUST define key material that may be defined as the
       EAP MSK and EMSK.  It is possible that these keys may be derived
       from the GSS-API PRF using well defined strings as input.  This
       may need more investigation since it is possible that a mechanism
       may not export the EMSK but would instead export only keys
       derived from the EMSK.

   5.  Key material exported from mechanisms MUST be cryptographically
       separate from keys used for other purposes by the mechanism such
       as those used in a security layer.


3.5  Security Layer

   SASL and GSS-API provide a security layer that can be used to protect
   further information between the two authenticated parties.  The SASL
   security layer expects to be run over a connection oriented
   transport.  The GSS-API security services may be used for message
   protection and do not necessarily expect to run over a connection
   oriented transport.  EAP does not provide a security layer, instead
   it exports key material that is used to seed an external security
   layer that protects data between the EAP peer and EAP authenticator.

   All GUAMs MUST meet the recommendations for general mechanism
   security layer as follows:

   1.  A mechanism MUST support a security layer which provides message
       integrity protection at a minimum.  A generic security layer may
       be defined that can use key material generated from the
       authentication exchange.

   2.  A mechanism SHOULD support confidentiality in the security layer.

   3.  A mechanism MUST provide for replay detection and MAY provide
       out-of-sequence detection.

   4.  A mechanism MUST provide cryptographic agility with respect to
       integrity and confidentiality algorithms.


3.6  Target Identification

   Specifying the target name of the service is useful when
   communicating with an entity which supports multiple virtual
   services.

   When establishing a security context the GSS-API context initiator
   specifies the name of the target service it wants to communicate



Salowey                 Expires December 27, 2006              [Page 10]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   with.  SASL also allows the specification of the name of a target
   service when establishing a security context.  What is expected of
   the target name is not completely described.  A Kerberos mechanism
   requires a target service name so it can obtain an select the
   appropriate service tickets for the service.  The type of names
   typically used as target names are host based service names to
   represent a service on a host.

   EAP does not have a notion of a target service name.  Originally EAP
   was more concerned with the authentication of the client accessing a
   network rather than of a host to a client.  In addition EAP has
   largely been concerned with clients trying to access a network which
   provides a uniform service with all authenticators providing the same
   access service.  As networks evolve this is changing somewhat so the
   need to specify a target type of network service or, in some cases, a
   particular instance of an authenticator providing a service.  Some
   EAP methods such as EAP-SIM and EAP-AKA do not explicitly name the
   target but rather rely upon the assumption that an authorized party
   has access to a shared secret.  In some cases the EAP peer trying to
   access the network does not know the identity of the network ahead of
   time.  Therefore it is desirable for the network to provide a hint of
   its identity in its initial message.  This can also be done in the
   EAP identity request message as in [I-D.adrangi-eap-network-
   discovery], however this message is not specific to a mechanism so it
   may not be possible to provide accurate information.

   The recommendations for general mechanism target identification are
   as follows:

   1.  A mechanism SHOULD provide a means to bind a target service name
       to the authentication exchange so at least the initiator and
       acceptor can select the correct credentials and verify that the
       target is consistent with the type of request being made.  Note
       that credential selection is a technique that can help in some
       types of channel bindings described in Section 3.8.

   2.  A mechanism SHOULD provide support for host based service names
       as defined in [RFC2743].  Note that it may be beneficial to
       define name types that identify network based services to support
       environments where EAP is currently used.

   3.  A mechanism SHOULD provide a means for the acceptor to provide a
       hint of its identity to the initiator when the acceptor issues
       the first message.  It SHOULD be possible to suppress this hint
       for cases where this information should not be revealed.






Salowey                 Expires December 27, 2006              [Page 11]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


3.7  Session Identification

   Session identification information provides a way to identify a
   particular instance of an authentication transaction.  This
   information could be used to bind this authentication transaction to
   another exchange or it could be used to identify keys generated by
   the exchange.  GSS-API and SASL frameworks do not provide an external
   way to identify a particular authentication transaction.  It is
   possible that the GSS-API PRF interface could be used for this
   purpose, but it may be preferred to generate a value that is a
   property of the mechanism execution instead of application specific
   information.  EAP also does not provide a external way to identify a
   particular exchange, however [I-D.ietf-eap-keying] does make
   recommendations in this area.

   The recommendations for general mechanism session identification are
   as follows:

      A mechanism SHOULD provide a means to export a value to identify a
      particular instance of an authentication transaction.  This value
      is a public value and must not reveal any secret information.


3.8  Channel Binding

   The term channel binding has been used with various different
   meanings in the different frameworks.

   GSS-API included the concept of channel binding to bind the context
   establishment to an existing underlying cryptographic channel.  The
   helps to ensure that the end points of the secure channel are the
   same as the endpoints of the context establishment.  In the GSS-API
   initiator and acceptor applications provide "channel bindings" data,
   a strong identifier for a secure channel, to the mechanism which
   determines the channel bindings data are the same for both peers,
   such as by exchanging and comparing integrity hashes thereof.  The
   data from channel bindings could be transformations of key material
   negotiated by the underlying channel or unique public data that has
   been exchanged within and bound to the channel negotiation (such as
   the TLS finished messages).  In some cases network addresses have
   also been used as channel bindings which can be problematic since
   address may be translated and are often not bound to an underlying
   cryptographic channel.  GSS-API type of channel binding has also been
   referred to cryptographic binding in the context of EAP method
   discussions.

   In EAP the term channel binding has been used with a different
   emphasis.  It is common for EAP deployments to locate the EAP server



Salowey                 Expires December 27, 2006              [Page 12]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   on a AAA server which is physically separated from the authenticator.
   The AAA server typically supports multiple authenticators.  This
   results in the EAP peer authenticating the identity of the AAA server
   and not the identity of the authenticator, it just knows that the
   authenticator it is talking to has been authorized by the AAA server.
   In many cases this does not cause a problem since all authenticators
   provide the same service.  However in the case where authenticators
   providing different services use the same AAA server or in cases
   where the identity of the individual authenticator is important this
   does raise an issue.  A peer requesting a particular service may be
   fooled into accepting service from an authenticator that is not
   authorized to provide the service.  In attempt to solve this problem
   it is recommended that the EAP authentication method provide a way to
   bind parameters in the lower layer request to the authentication
   protocol so they AAA server can verify the binding between the
   service requested by the client and a service that the authenticator
   is authorized to provide.  This type of channel binding might be
   better called service binding.  There are several ways that this type
   of channel binding may be achieved.

   o  Credential Selection - by including a target service identifier in
      the authentication protocol the initiator and/or acceptor can
      select an appropriate credentials to perform authentication as a
      particular service.  For example this could result in the
      acquisition of a Kerberos service ticket for a specific service,
      selection of an appropriate certificate to identify a specific
      service, or localization of a shared secret for use with a
      specific service.  This requires each target service to have its
      own name and credential.  Credential selection may not provide
      enough granularity for all the parameters specified by a service.

   o  GSS-API style channel bindings - in this case each side hashes the
      binding information and the two hashes are compared.  The contents
      of the binding information must be rigidly defined because any
      variation will cause the binding to fail.  The AAA server will
      need to know what binding parameters are associated with the
      authenticator in order to correctly compute the binding.

   o  Authenticated data style bindings - in this case the binding
      information is communicated from initiator or vice versa.  The
      data can then be exported from the mechanism and compared with
      additional parameters communicated out of band.  This approach
      allows for a more complex comparison where some variation of
      binding parameters is allowed.

   o  Binding through external key derivation - in this case the keys
      that are exported from a mechanism are bound to a particular
      channel parameters through the key derivation algorithm.  This



Salowey                 Expires December 27, 2006              [Page 13]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


      approach does not require support from a mechanism and can only be
      used when the key material is made use of externally.

   SASL does not currently have a concept similar to channel bindings
   although it does support specifying a target service identifier.
   However there is ongoing work on defining channel bindings for SASL
   mechanisms.

   The recommendations for general mechanism channel bindings are as
   follows:

   1.  A mechanism MUST support channel bindings compatible with
       [RFC2743].

   2.  A mechanism MUST support authenticated data style channel
       bindings.


3.9  Principal Naming and Attributes

   GSS-API has a formal system of mechanism independent naming described
   in [RFC2743].  The most commonly used name types are host based
   service names (GSS_C_NT_HOSTBASED_SERVICE) and user names
   GSS_C_NT_USER_NAME.  GSS-API also has the concept of a canonical name
   representation that can be used for binary comparisons of equality.
   There are ongoing investigations into providing a more structured
   naming scheme which could provide additional attributes such as group
   affiliation.

   EAP typically beings with an identity assertion phase where the peer
   responds to an EAP-Identity request with an EAP-Identity response
   containing an network access identifier (NAI).  The NAI is not
   authenticated at this point, but provides a hint to the back end
   authentication services as how to authenticated the peer, i.e. which
   authentication server to contact.  In some ways this identifies the
   target of the authentication, but it is just specify a realm instead
   of a specific service that is being provided.  The actual
   authentication may or may not authenticate the NAI depending on the
   authentication method.  In some cases the NAI is anonymous and
   completely unrelated to the final authenticated identity.  EAP does
   not provide a formal way of dealing with authenticated names.  EAP
   methods may provide a means for exchanging application specified data
   which could be possibly be structured as naming attributes.

   SASL defines an authorization identity in addition to the
   authenticated identity.  The authorization identity is the identity
   that the client is expected to act as.  The SASL implementation must
   verify that the authenticated identity is authorized to act as the



Salowey                 Expires December 27, 2006              [Page 14]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   authenticated identity.  SASL does not specify the structure or
   format of names.

   The recommendations for general mechanism principal naming and
   attributes are as follows:

   1.  A mechanism MUST define how to export names in the GSS-API
       mechanism independent and canonical formats.

   2.  A mechanism MUST support the authenticated communication of an
       application specific authorization identity.  The mechanism
       should provide hooks where appropriate to allow for the
       authorization of the authorization identity to authenticated
       identity mapping.

   3.  A mechanism MAY define support for other identity attribute types
       as appropriate.


3.10  Mechanism Negotiation

   GSS-API does not provide native support for mechanism negotiation,
   however there is a pseudo-mechanism designed to perform negotiation
   called Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
   [RFC4178].  SPNEGO can negotiate a mechanism in common between the
   initiator and acceptor, and, provided the mechanisms negotiated
   provide integrity support, then it can also protect the negotiation.
   Some GSS-API applications eschew SPNEGO and perform mechanism
   negotiation at the application protocol layer. .

   EAP provides a negotiation mechanism in which the server suggests a
   mechanism by sending the initial message in the authentication
   exchange and the peer replies with either a response or a NAK message
   containing a list of mechanisms it supports.  The negotiation is not
   protected.  Once a particular negotiation method is selected it is
   not possible to abort and switch to a new mechanism without
   restarting the conversation.

   In SASL mechanism negotiation is left to the application.  Typically
   the server presents a list that the client chooses from.  The
   negotiation may be protected if a security layer is provided and the
   application defines a way to obtain a list of mechanisms after the
   security layer is established.

   Multiple layers of mechanism negotiation can cause problems.  The
   main problem with multi-layer mechanism negotiation is that security
   requirements may not be maintained at all negotiation layers, thus
   one layer may select a security mechanism that is too weak or



Salowey                 Expires December 27, 2006              [Page 15]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   otherwise inappropriate at a higher layer.  It is also possible for
   the negotiation to fail because a mechanism selected tries to do
   negotiation which fails and there is no way to go backwards in the
   mechanism tree without restarting the negotiation from the beginning.

   The recommendations for general mechanism negotiation are as follows:

   1.  Mechanism specifications should analyze the security implications
       of sub mechanism negotiation and include security considerations
       to address security issues that may arise from sub-mechanism
       negotiation.


3.11  Indentity Protection

   Some mechanisms provide support for concealing the identity of one of
   the parties executing the authentication protocol from an
   eavesdropper.  The recommendation for general mechanisms support for
   identity protection is as follows,

   1.  A mechanism MAY support identity protection for one of the
       participants in the authentication conversation.  In general
       mechanisms are more interested in protecting the identity of
       clients rather than services.


3.12  Fast Reconnect

   Fast reconnect is defined in [RFC3748]as "The ability, in the case
   where a security association has been previously established, to
   create a new or refreshed security association more efficiently or in
   a smaller number of round-trips."  The recommendation for general
   mechanisms support for fast reconnect is as follows.

   1.  A mechanism MAY support fast reconnect for one of the
       participants in the authentication conversation.















Salowey                 Expires December 27, 2006              [Page 16]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


4.  Tools for creating GUAM mechanisms

   This section describes tools and techniques that mechanism developers
   can use to help them create generally usable mechanism.


4.1  Mechanism Bridges

   A mechanism bridge creates an automated way to incorporate mechanisms
   from one framework into another framework.  An example of such a
   bridge is the SASL GSS-API based mechanism [I-D.ietf-sasl-gssapi].
   This specification describes how a GSS-API mechanism may be invoked
   as a SASL mechanism.  This allows any mechanism specified in GSS-API
   to be invoked through the SASL framework.  When the SASL GSS-API
   mechanism was first defined all GSS-API mechanism appeared as one
   SASL mechanism within the SASL framework.

   It may be possible to create bridges for other combinations of
   mechanisms, but there often exists gaps in functionality between
   mechanisms of different frameworks.  The following sections describe
   techniques that make it easier to overcome these gaps and make it
   possible to adapt a candidate mechanism to different frameworks.  As
   a mechanism is incorporated from one framework into another it should
   retain a unique identity so existing negotiation mechanisms of
   frameworks and applications are not broken.

4.2  Protocol Initiation

   The different frameworks require different entities to start the
   authentication conversation.  In EAP it is the server/acceptor side
   that starts the conversation, in GSS-API it is the opposite and SASL
   can operate in either mode.  It is often possible to include an
   additional message or remove a message without affecting the
   protocol.  For example to convert a client initiated protocol for use
   with EAP an initial message that contains a hint of the identity of
   the server could be added.  The hint can be useful in EAP where the
   peer may not have another means of knowing who it is talking to until
   the authentication protocol is underway.

4.3  Generic PRF

   For mechanisms that do not define a PRF that can be used in GSS-API
   calls a default PRF can be defined.

4.4  Generic Per-Message Security Layer

   Mechanisms that are defined as EAP methods do not provide a security
   layer.  However they do provide cryptographic key material generated



Salowey                 Expires December 27, 2006              [Page 17]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


   from the EAP exchange in the form of the MSK and EMSK.  Key material
   derived from these quantities could be used to key a generic security
   layer.  An generic security layer could be based on Kerberos
   encryption and checksum profile [RFC4121][RFC3961] or on IPSec ESP.
   EAP methods also do not provide for the negotiation of a ciphersuite
   for the security layer.  One approach would be to add negotiation
   into the generic security layer.  Another approach may be to exchange
   quality of protection parameters as authenticated data.

4.5  Fragmentation Support

   Mechanisms that are defined as GSS-API or SASL mechanisms leave any
   fragmentation up to the application itself.  In order to support EAP
   these mechanisms would have to include fragmentation support.  A
   generic fragmentation layer could be modelled after EAP-TLS
   [RFC2716].

4.6  Channel Binding and Authenticated Data

   The ability to carry data that is integrity protected between the
   authenticating parties is a useful feature for a mechanism.  Channel
   binding would certainly be helped by this capability.  The data
   should be tagged for different purposes.  One use could be to carry a
   hash of channel binding parameters used for GSS-API style channel
   bindings.  Another use could be for communicating a SASL
   authorization ID or for carry EAP style channel bindings.  Having a
   common name space for different types of attributes could be useful
   in developing mechanisms in a consistent way.

4.7  Fast Reconnect

   Some mechanisms provide support for a fast reconnect feature that
   optimizes subsequent authentications after an initial authentication.
   In some cases this may be best provided by the mechanism, however it
   could be possible for a generic fast reauthentication mechanism be
   developed to address this need for general mechanisms.

4.8  Mechanism Naming

   It is possible to automatically generate types from a single value.
   The recommended approach is to assign an EAP type to a mechanism.  A
   GSS-API OID can be created from the EAP type by appending the EAP
   type as an integer appended to the GUAM mechanism base OID [TBD].
   The SASL specification for using GSS-API mechanisms in SASL is
   defined in [I-D.ietf-sasl-gssapi] and specifies a way to create a
   SASL name from a GSS-API OID.





Salowey                 Expires December 27, 2006              [Page 18]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


4.9  Naming

   TBD - Some guidance in naming is needed.

   We need at least support for naming services, both domain-wide (AAA
   services) and host-based, and we need support for naming users.
   Everything else should pretty much be optional, including anonymity
   and pseudonymity.











































Salowey                 Expires December 27, 2006              [Page 19]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


5.  Interface Specification

   This section outlines how the GSS-API can provide a interface that
   could potentially be used by any of the mechanism frameworks.  Some
   required enhancements to GSS-API to make this happen are discussed.














































Salowey                 Expires December 27, 2006              [Page 20]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


6.  IANA Considerations

   To be determined.
















































Salowey                 Expires December 27, 2006              [Page 21]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


7.  Security Considerations


7.1  Same mechanism accessed through different frameworks


7.2  Algorithm identification and negotiation












































Salowey                 Expires December 27, 2006              [Page 22]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


8.  Acknowledgements

   Nicolas Williams, Sam Hartman, and Glen Zorn provided valuable
   discussions and feedback that went into the preparation of this
   document.














































Salowey                 Expires December 27, 2006              [Page 23]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


9.  References

9.1  Normative References

   [I-D.ietf-sasl-rfc2222bis]
              Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-15
              (work in progress), January 2006.

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

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

9.2  Informative References

   [I-D.adrangi-eap-network-discovery]
              Adrangi, F., "Identity selection hints for Extensible
              Authentication Protocol (EAP)",
              draft-adrangi-eap-network-discovery-14 (work in progress),
              August 2005.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-13 (work in
              progress), May 2006.

   [I-D.ietf-sasl-gssapi]
              Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism",
              draft-ietf-sasl-gssapi-06 (work in progress), June 2006.

   [I-D.salowey-guam]
              Salowey, J., "Generally Useful Authentication Mechanisms
              (GUAM)", draft-salowey-guam-00 (work in progress),
              June 2005.

   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
              Protocol", RFC 2716, October 1999.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos



Salowey                 Expires December 27, 2006              [Page 24]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005.

   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
              Simple and Protected Generic Security Service Application
              Program Interface (GSS-API) Negotiation Mechanism",
              RFC 4178, October 2005.


Author's Address

   Joseph Salowey
   Cisco Systems

   Email: jsalowey@cisco.com



































Salowey                 Expires December 27, 2006              [Page 25]


Internet-Draft          GUAM Mechanism Guidelines              June 2006


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 (2006).  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.




Salowey                 Expires December 27, 2006              [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/