[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5448

Network Working Group                                           J. Arkko
Internet-Draft                                             V. Lehtovirta
Updates: 4187 (if approved)                                     Ericsson
Intended status: Informational                                 P. Eronen
Expires: January 8, 2009                                           Nokia
                                                            July 7, 2008


 Improved Extensible Authentication Protocol Method for 3rd Generation
              Authentication and Key Agreement (EAP-AKA')
                       draft-arkko-eap-aka-kdf-00

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 January 8, 2009.















Arkko, et al.            Expires January 8, 2009                [Page 1]


Internet-Draft                  EAP-AKA'                       July 2008


Abstract

   This specification defines a new EAP method, EAP-AKA', a small
   revision of the EAP-AKA method.  The change is a new key derivation
   function that binds the name of the access network to the keys
   derived within the method.  As a result, it becomes possible to
   authenticate the network name.  The new key derivation mechanism has
   been defined in 3GPP.  This specification allows its use in EAP in an
   interoperable manner.

   This specification also updates RFC 4187 EAP-AKA to add support for
   preventing bidding down attacks between itself and EAP-AKA'.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  The AT_KDF_INPUT Attribute . . . . . . . . . . . . . . . .  5
     2.2.  AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
     2.4.  Hash Function Update . . . . . . . . . . . . . . . . . . .  9
   3.  Bidding Down Prevention for EAP-AKA  . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Changes from RFC 4187 . . . . . . . . . . . . . . . . 17
   Appendix B.  Importance of Explicit Negotiation  . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20


















Arkko, et al.            Expires January 8, 2009                [Page 2]


Internet-Draft                  EAP-AKA'                       July 2008


1.  Introduction

   This specification defines a new Extensible Authentication Protocol
   (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA
   method originally defined in [RFC4187].  What is new in EAP-AKA' is
   that it has a new key derivation function specified in [3GPP.33.402].
   This function binds the name of the access network to the keys
   derived within the method.  As a result, it becomes possible to
   authenticate the network name, limiting the effects of compromised
   nodes and keys.  This specification defines the EAP encapsulation for
   AKA when the new key derivation mechanism is in use.

   3GPP has defined a number of applications for the revised AKA
   mechanism, some based on native encapsulation of AKA over 3GPP radio
   access networks and others based on the use of EAP.

   For making the new key derivation mechanisms usable in EAP-AKA
   additional protocol mechanisms are necessary.  Given that RFC 4187
   calls for the use of CK (the encryption key) and IK (the integrity
   key) from AKA directly, existing implementations continue to use
   these.  Any change of the key derivation must be unambiguous to both
   sides in the protocol.  That is, it must not be possible to
   accidentally connect old equipment to new equipment and get the key
   derivation wrong or attempt to use wrong keys without getting a
   proper error message.

   This specification therefore introduces a variant of the EAP-AKA
   method, called EAP-AKA'.  This method can employ the derived keys CK'
   and IK' from the 3GPP specification but it is otherwise equivalent to
   RFC 4187.  Given that a different EAP method Type value is used for
   EAP-AKA and EAP-AKA', a mutually supported method may be negotiated
   using the standard mechanisms in EAP [RFC3748].

      Editor's Note: A number of other possible ways to use the new key
      derivation functions have been proposed.  These include
      configuration and reliance on a particular domain employing only
      the new functions.  Appendix B explains why these approaches lead
      to severe interoperability problems and why it is important to be
      explicit about the change of semantics in protocol design.

   The rest of this specification is structured as follows.  Section 2
   defines the EAP-AKA' method.  Section 3 adds support to EAP-AKA to
   prevent bidding down attacks from EAP-AKA'.  Section 4 explains the
   security differences between EAP-AKA and EAP-AKA'.  Section 5
   describes the IANA considerations and Appendix A explains what
   updates to RFC 4187 EAP-AKA have been made in this specification.





Arkko, et al.            Expires January 8, 2009                [Page 3]


Internet-Draft                  EAP-AKA'                       July 2008


2.  EAP-AKA'

   EAP-AKA' is a new EAP method that follows EAP-AKA specification
   [RFC4187] in all other respects except the following:

   o  It uses the Type code TBD1 BY IANA, not 23 which is used by EAP-
      AKA.

   o  It carries the AT_KDF_INPUT attribute, as defined in Section 2.1
      to ensure that both parties know the name of the access network.

   o  It calculates the Master Key (MK) as defined in Section 2.3, not
      as defined in EAP-AKA.

   o  It uses the optional AT_KDF attribute as defined in Section 2.2 to
      control possible future key derivation function changes.

   Figure 1 shows an example of the authentication process.  Each
   message AKA'-Challenge and so on represents the corresponding message
   from EAP-AKA, but with EAP-AKA' Type code.  The definition of these
   messages, along with the definition of attributes AT_RAND, AT_AUTN,
   AT_MAC, and AT_RES can be found from [RFC4187].





























Arkko, et al.            Expires January 8, 2009                [Page 4]


Internet-Draft                  EAP-AKA'                       July 2008


    Peer                                                    Server
       |                      EAP-Request/Identity             |
       |<------------------------------------------------------|
       |                                                       |
       | EAP-Response/Identity                                 |
       | (Includes user's NAI)                                 |
       |------------------------------------------------------>|
       |                           +-------------------------------+
       |                           | Server runs AKA' algorithms,  |
       |                           | generates AT_RAND and AT_AUTN.|
       |                           | For creating AT_MAC, the      |
       |                           | server employs CK' and IK'.   |
       |                           +-------------------------------+
       |                        EAP-Request/AKA'-Challenge     |
       |               (AT_RAND, AT_AUTN, AT_KDF_INPUT, AT_MAC)|
       |<------------------------------------------------------|
   +-------------------------------------+                     |
   | Peer runs AKA' algorithms,          |                     |
   | verifies AT_AUTN and AT_MAC, derives|                     |
   | AT_RES and session keys. Again, for |                     |
   | verifying AT_MAC and creating       |                     |
   | AT_RES, the peer uses CK' and IK'   |                     |
   +-------------------------------------+                     |
       | EAP-Response/AKA'-Challenge                           |
       | (AT_RES, AT_MAC)                                      |
       |------------------------------------------------------>|
       |                          +--------------------------------+
       |                          | Server checks the given AT_RES,|
       |                          | and MAC and finds them correct.|
       |                          +--------------------------------+
       |                                          EAP-Success  |
       |<------------------------------------------------------|

              Figure 1: EAP-AKA' Authentication Process

2.1.  The AT_KDF_INPUT Attribute

   The format of the AT_KDF_INPUT attribute is shown below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AT_KDF_INPUT  | Length        | Actual Network Name Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                        Network Name                           .
      .                                                               .
      |                                                               |



Arkko, et al.            Expires January 8, 2009                [Page 5]


Internet-Draft                  EAP-AKA'                       July 2008


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields are as follows:

   AT_KDF_INPUT

      This is set to TBD2 BY IANA.

   Length

      The length of the attribute, calculated as defined in [RFC4187]
      Section 8.1.

   Actual Network Name Length

      This a 2-byte actual length field, needed due to the requirement
      that previous field is expressed in multiples of 4 bytes per the
      usual EAP-SIM and EAP rules.  The Actual Network Name Length field
      provides the length of the Network Name in bytes.

   Network Name

      This field contains the network name of the access network for
      which the authentication is being performed.  The name does not
      include any terminating null characters.  Because the length of
      the entire attribute must be a multiple of 4 bytes, the sender
      pads the name with zero bytes when necessary.

   Only the server sends the AT_KDF_INPUT attribute.  The peer SHOULD
   check the received value against its own understanding of the network
   name.  Upon detecting a discrepancy, the peer MAY either log an error
   and continue, or fail the authentication process.

   The Network Name field contains an octet string.  This string MUST be
   constructed as specified in [3GPP.23.003].  For network types where
   this reference does not provide an instruction on how to construct
   the name, the empty octet string SHOULD be used.

      Editor's Note: This 3GPP specification is still being worked on.
      It is assumed that the specification ensures that conflicts
      potentially arising from using the same name in different types of
      networks are avoided.  It is also assumed that the 3GPP
      specification will have detailed rules about how a client can
      determine these based on information available to the client, such
      as the type of protocol used to attach to the network, beacons
      sent out by the network, and so on.  Information that the client
      cannot directly observe (such as the type or version of the home



Arkko, et al.            Expires January 8, 2009                [Page 6]


Internet-Draft                  EAP-AKA'                       July 2008


      network) should not be used by this algorithm.

2.2.  AT_KDF

   AT_KDF is an optional attribute that the server MAY use when it
   wishes to employ a specific key derivation function.  This is useful
   for future evolution of the key derivation functions.

   The format of the AT_KDF attribute is shown below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AT_KDF        | Length        |    Key Derivation Function    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields are as follows:

   AT_KDF

      This is set to TBD3 BY IANA.

   Length

      The length of the attribute, MUST be set to 1.

   Key Derivation Function

      An enumerated value representing the key derivation function that
      the server (or peer) wishes to use.  Value 1 represents RFC 4187
      key derivation, i.e., fallback to EAP-AKA functionality.  Value 2
      represents the default key derivation function for EAP-AKA', i.e.,
      employing CK' and IK' as defined in Section 2.3.

   Servers MAY choose to send one or more AT_KDF attributes in the EAP-
   Request/AKA'-Challenge message.  The first of these attributes
   represents the desired function and the other ones are acceptable
   alternatives, the most desired alternative being the second
   attribute.

   Upon receiving this attribute, if the peer supports and is willing to
   use the key derivation function indicated by the first attribute, the
   function is taken into use and no further action is necessary.
   However, if the peer does not support this function or is unwilling
   to use it, it responds with the EAP-Response/AKA'-Challenge message
   that contains only one attribute, AT_KDF with the value set to the
   selected alternative.  If there is no suitable alternative, the peer



Arkko, et al.            Expires January 8, 2009                [Page 7]


Internet-Draft                  EAP-AKA'                       July 2008


   behaves as if AT_MAC had been incorrect and authentication fails.

   Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the
   peer, the server checks that the alternative was in its offer.  If
   not, it behaves as if AT_MAC of the response had been incorrect and
   fails the authentication.  Otherwise, the server re-sends the EAP-
   Response/AKA'-Challenge message, but moves the selected alternative
   to the beginning of the list of AT_KDF attributes.

   When the peer receives the new EAP-Request/AKA'-Challenge message, it
   MUST check that requested change, and only the requested change
   occurred in the list of AT_KDF attributes.  If yes, it continues.  If
   not, it behaves as if AT_MAC had been incorrect and fails the
   authentication.

2.3.  Key Generation

   Both the peer and server MUST derive the Master Key (MK) from
   underlying AKA values and the identity, as follows.

   AT_KDF set to 1

      MK is as defined in [RFC4187].

   AT_KDF not present or set to 2

      MK is as follows:


         MK = SHA1(Identity|IK'|CK')

      Here SHA1 and Identity are as specified in [RFC4187] and IK' and
      CK' are derived as specified in [3GPP.33.402].  The functions that
      derive IK' and CK' take the following parameters: CK and IK
      produced by the AKA algorithm and value of the Network Name field
      (without length or padding) from AT_KDF_INPUT as the access
      network identity.

   AT_KDF is present and has any other value

      Future variations of key derivation functions may be defined, and
      they will be represented by new values of AT_KDF.  If the peer
      does not recognize the value it cannot calculate the keys and
      behaves as explained in Section 2.2.

   If the peer supports a given key derivation function but is unwilling
   to perform it for policy reasons, it refuses to calculate the keys
   and behaves as explained in Section 2.2.



Arkko, et al.            Expires January 8, 2009                [Page 8]


Internet-Draft                  EAP-AKA'                       July 2008


2.4.  Hash Function Update

   Given that we are defining a new method, it would potentially be a
   convenient time to introduce a change of the hash functions from
   those used in EAP-AKA (SHA1) to SHA256 which is used in new 3GPP
   systems.  Would this be desirable?













































Arkko, et al.            Expires January 8, 2009                [Page 9]


Internet-Draft                  EAP-AKA'                       July 2008


3.  Bidding Down Prevention for EAP-AKA

   As discussed in [RFC3748], negotiation of methods within EAP is
   insecure.  That is, a man-in-the-middle attacker may force the
   endpoints to use a method that is not the strongest one they both
   support.  This is a problem, as we expect EAP-AKA and EAP-AKA' to be
   negotiated via EAP.

   In order to prevent such attacks, this specification specifies a new
   mechanism for EAP-AKA that allows the endpoints to securely discover
   the capabilities of each other.  This mechanism comes in the form of
   the AT_BIDDING attribute.  This allows both endpoints to communicate
   their desire and support for EAP-AKA' when exchanging EAP-AKA
   messages.  This attribute is not included in EAP-AKA' messages as
   defined in this RFC.  If during the authentication process it is
   discovered that both endpoints would have been able to use EAP-AKA',
   the authentication process SHOULD be aborted, as a bidding down
   attack may have happened.

   The format of the AT_BIDDING attribute is shown below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AT_BIDDING    | Length        |D|          Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields are as follows:

   AT_BIDDING

      This is set to TBD4 BY IANA.

   Length

      The length of the attribute, MUST be set to 1.

   D

      This bit is set to 1 if the sender does support EAP-AKA', is
      willing to use it, and prefers it over EAP-AKA.  Otherwise it
      should be set to 0.

   Reserved

      This field MUST be set to zero when sent and ignored on receipt.




Arkko, et al.            Expires January 8, 2009               [Page 10]


Internet-Draft                  EAP-AKA'                       July 2008


   The server sends this attribute in the EAP-Request/AKA-Challenge
   message.  The peer compares the received value to its own
   capabilities.  If it turns out that both the server and peer would
   have been able to use EAP-AKA' and preferred it over EAP-AKA, the
   peer behaves as if AT_MAC had been incorrect, and fails the
   authentication.













































Arkko, et al.            Expires January 8, 2009               [Page 11]


Internet-Draft                  EAP-AKA'                       July 2008


4.  Security Considerations

   A summary of the security properties of EAP-AKA' follows.  As there
   has been only a minor change in the method, most of the security
   properties are unchanged from EAP-AKA.

   Protected ciphersuite negotiation

      The ciphersuite negotiation mechanisms of EAP-AKA are also present
      in EAP-AKA'.  Refer to [RFC4187] Section 12 for further details.
      However, EAP-AKA' adds a new negotiation mechanism for selecting
      the key derivation function that feeds CK' and IK' into MK.  This
      mechanism is secure against bidding down attacks.

   Mutual authentication

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Integrity protection

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Replay protection

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Confidentiality

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Key derivation

      The key derivation mechanisms of EAP-AKA are also present in EAP-
      AKA'.  Refer to [RFC4187] Section 12 for further details.
      However, EAP-AKA' adds an additional layer of key derivation
      functions within itself.  This does not affect the type of keys
      the method exports.  However, the additional functions make it
      harder to use compromised keys in a different context.

   Key strength

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect, on the assumption that key derivation functions do not
      change the strength of the keys.  This is currently the case with



Arkko, et al.            Expires January 8, 2009               [Page 12]


Internet-Draft                  EAP-AKA'                       July 2008


      the functions defined in [3GPP.33.402].  Refer to [RFC4187]
      Section 12 for further details.

   Dictionary attack resistance

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Fast reconnect

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.  Note
      that implementations MUST prevent performing a fast reconnect
      across method types.

   Cryptographic binding

      Note that this term refers to a very specific form of binding,
      something that is performed between two layers of authentication.
      It is not the same as the binding to a particular network name.
      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect, i.e., as it is not a tunnel method this property is not
      applicable to it.  Refer to [RFC4187] Section 12 for further
      details.

   Session independence

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Fragmentation

      The properties of EAP-AKA' are exactly as those of EAP-AKA in this
      respect.  Refer to [RFC4187] Section 12 for further details.

   Channel binding

      EAP-AKA' provides a simple form of channel binding.













Arkko, et al.            Expires January 8, 2009               [Page 13]


Internet-Draft                  EAP-AKA'                       July 2008


5.  IANA Considerations

   EAP-AKA' has the EAP Type value TBD1 BY IANA.  Per [RFC3748] Section
   6.2, this allocation can be made with Designated Expert and
   Specification Required.

   EAP-AKA' shares its attribute space and message Subtypes, with EAP-
   SIM [RFC4186] and EAP-AKA [RFC4186].

   However, a new Attribute Type value (TBD2) in the non-skippable range
   needs to be assigned for AT_KDF_INPUT (Section 2.1).

   Also, a new Attribute Type value (TBD3) in the non-skippable range
   needs to be assigned for AT_KDF (Section 2.2).  IANA also needs to
   create a registry for EAP-AKA' KDF Type values.  The initial contents
   of this registry are given below; new values can be created through
   Specification Required policy [RFC5226].

   Value      Description              Reference
   ---------  ----------------------   ---------------
   0          Reserved
   1          EAP-AKA with CK/IK       [this document]
   2          EAP-AKA' with CK'/IK'    [this document]
   3-65535    Unassigned

   Finally, a new Attribute Type value (TBD4) in the skippable range
   needs to be assigned for AT_BIDDING (Section 3).
























Arkko, et al.            Expires January 8, 2009               [Page 14]


Internet-Draft                  EAP-AKA'                       July 2008


6.  Acknowledgments

   The authors would like to thank Guenther Horn, Joe Salowey, Mats
   Naslund, and Stefan Rommer for interesting discussions in this
   problem space.














































Arkko, et al.            Expires January 8, 2009               [Page 15]


Internet-Draft                  EAP-AKA'                       July 2008


7.  References

7.1.  Normative References

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

   [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
              Protocol Method for 3rd Generation Authentication and Key
              Agreement (EAP-AKA)", RFC 4187, January 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [3GPP.23.003]
              3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; Numbering,
              addressing and identification (Release 8)", 3GPP Draft
              Technical Specification 23.003 v 8.0.0, June 2008.

   [3GPP.33.402]
              3GPP, "3GPP System Architecture Evolution (SAE); Security
              aspects of non-3GPP accesses; Release 8", 3GPP Draft
              Technical Specification 33.402 v 8.0.0, June 2008.

7.2.  Informative References

   [RFC4186]  Haverinen, H. and J. Salowey, "Extensible Authentication
              Protocol Method for Global System for Mobile
              Communications (GSM) Subscriber Identity Modules (EAP-
              SIM)", RFC 4186, January 2006.

   [RFC4284]  Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
              Selection Hints for the Extensible Authentication Protocol
              (EAP)", RFC 4284, January 2006.

   [RFC5113]  Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network
              Discovery and Selection Problem", RFC 5113, January 2008.











Arkko, et al.            Expires January 8, 2009               [Page 16]


Internet-Draft                  EAP-AKA'                       July 2008


Appendix A.  Changes from RFC 4187

   The changes to RFC 4187 relate only to the bidding down prevention
   support defined Section 3.















































Arkko, et al.            Expires January 8, 2009               [Page 17]


Internet-Draft                  EAP-AKA'                       July 2008


Appendix B.  Importance of Explicit Negotiation

   Choosing between the traditional and revised AKA key derivation
   functions is easy when their use is unambiguously tied to a
   particular radio access network, e.g LTE as defined by 3GPP or eHRPD
   as defined by 3GPP2.  There is no possibility for interoperability
   problems if this radio access network is always used in conjunction
   with new protocols that cannot be mixed with the old ones; clients
   will always know whether they are connecting to the old or new
   system.

   However, using the new key derivation functions over EAP introduces
   several degrees of separation, making the choice of the correct key
   derivation functions much harder.  Many different types of networks
   employ EAP.  Most of these networks have no means to carry any
   information about what is expected from the authentication process.
   EAP itself is severely limited in carrying any additional
   information, as noted in [RFC4284] [RFC5113].  Even if these networks
   or EAP were extended to carry additional information, it would not
   affect millions of deployed access networks and clients attaching to
   them.

   Simply changing the key derivation functions that EAP-AKA [RFC4187]
   uses would cause interoperability problems with all of the existing
   implementations.  Perhaps it would be possible to employ strict
   separation into domain names that should be used by the new clients
   and networks.  Only these new devices would then employ the new key
   derivation mechanism.  While this can be made to work for specific
   cases, it would be an extremely brittle mechanism, ripe to result in
   problems whenever client configuration, routing of authentication
   requests, or server configuration does not match expectations.  It
   also does not help to assume that the EAP client and server are
   running a particular release of 3GPP network specifications.  Network
   vendors often provide features from the future releases early or do
   not provide all features of the current release.  And obviously,
   there are many EAP and even some EAP-AKA implementations that are not
   bundled with the 3GPP network offerings.  In general, these
   approaches are expected to lead to hard-to-diagnose problems and
   increased support calls.












Arkko, et al.            Expires January 8, 2009               [Page 18]


Internet-Draft                  EAP-AKA'                       July 2008


Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@piuha.net


   Vesa Lehtovirta
   Ericsson
   Jorvas  02420
   Finland

   Email: vesa.lehtovirta@ericsson.com


   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

   Email: pasi.eronen@nokia.com


























Arkko, et al.            Expires January 8, 2009               [Page 19]


Internet-Draft                  EAP-AKA'                       July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.











Arkko, et al.            Expires January 8, 2009               [Page 20]


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