Internet DRAFT - draft-ohba-eap-aaakey-binding

draft-ohba-eap-aaakey-binding






EAP Working Group                                                Y. Ohba
Internet-Draft                                                   Toshiba
Expires: December 3, 2005                                    M. Yanagiya
                                                                     NTT
                                                                Jun 2005


         AAA-Key Derivation with Lower-Layer Parameter Binding
                    draft-ohba-eap-aaakey-binding-01

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 3, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes an alternative method for deriving a AAA-Key.
   The method cryptographically binds EAP lower-layer parameters to the
   AAA-Key without need to carry those parameters in EAP methods.







Ohba & Yanagiya         Expires December 3, 2005                [Page 1]

Internet-Draft               AAA-Key Binding                    Jun 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Specification of Requirements  . . . . . . . . . . . . . .   3
   2.   Problem Description  . . . . . . . . . . . . . . . . . . . .   4
   3.   Prerequisites  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1  Trust Relationship . . . . . . . . . . . . . . . . . . . .   5
     3.2  Securty Association  . . . . . . . . . . . . . . . . . . .   5
   4.   Solution Framework . . . . . . . . . . . . . . . . . . . . .   7
     4.1  Key Binding Blob for Lower-Layer Parameters  . . . . . . .   7
     4.2  AAA-Key Derivation Algorithm . . . . . . . . . . . . . . .   7
     4.3  AAA-Key Scope  . . . . . . . . . . . . . . . . . . . . . .   7
     4.4  AAA-Key Name . . . . . . . . . . . . . . . . . . . . . . .   7
     4.5  Key Binding Procedure  . . . . . . . . . . . . . . . . . .   8
   5.   Validating Key Binding Blob  . . . . . . . . . . . . . . . .   9
   6.   AAA Protocol Consideration . . . . . . . . . . . . . . . . .  10
   7.   Co-existence with Legacy AAA-Key Derivation Algorithm  . . .  12
   8.   Discussion . . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  14
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  15
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1   Normative References . . . . . . . . . . . . . . . . . .  16
     11.2   Informative References . . . . . . . . . . . . . . . . .  16
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
        Intellectual Property and Copyright Statements . . . . . . .  18


























Ohba & Yanagiya         Expires December 3, 2005                [Page 2]

Internet-Draft               AAA-Key Binding                    Jun 2005


1.  Introduction

   EAP (Extensible Authentication Protocol) is an authentication
   framework which supports multiple authentication algorithms known as
   "EAP methods" [RFC3748].  EAP lower- layers use a key generated and
   exported by an EAP method to bootstrap their ciphersuites.  This key
   is referred to as AAA-Key.  A framework for the generation, transport
   and usage of AAA-Key is described in [I-D.ietf-eap-keying].

   Each EAP lower-layer has its own parameters that are carried at the
   lower-layer.  EAP lower-layer end-point identifiers are one of such
   parameters.  Those parameters would need to be cryptographically
   bound to the AAA-Key to avoid possible security flaws.

   A mechanism that is described in [RFC3748] to create such a binding
   is based on communicating lower-layer parameters over a protected
   channel of an EAP method to help the EAP peer and the EAP server
   detect a mismatch between the parameters exchanged over the protected
   channel and the ones advertised at an unprotected lower-layer.  There
   have been several solutions [I-D.arkko-eap-service-identity-auth]
   [I-D.tschofenig-eap-ikev2] that are based on this mechanism.

   This document describes an alternate mechanism for creating a binding
   between a AAA-Key and EAP lower-layer parameters without need for an
   EAP method to carry the EAP lower-layer parameters.

1.1  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].


















Ohba & Yanagiya         Expires December 3, 2005                [Page 3]

Internet-Draft               AAA-Key Binding                    Jun 2005


2.  Problem Description

   When an authentication and authorization procedure for a network
   access service succeeds using EAP with an EAP authentication method
   that is capable of generating a Master Session Key (MSK), a AAA-Key
   is derived from the MSK and transferred from the EAP server and the
   EAP authenticator [I-D.ietf-eap-keying] for use by the EAP lower
   layer to further derive keys used for protecting the lower layer.
   However, if the AAA-Key is not bound to EAP lower layer parameters,
   the key may be used for a different context of the EAP lower layer or
   even for a different EAP lower layer.  Detailed examples on this
   problem is described in section 2 of [I-D.arkko-eap-service-identity-
   auth].

   The problem has been originally known as channel binding problem
   [RFC3748] [I-D.ietf-eap-keying].  However, the solution that is
   suggested in those documents is to use EAP methods that can carry EAP
   lower layer parameters and expecting the EAP server and EAP peer to
   validate them by comparing with the EAP lower layer parameters
   carried via the EAP lower layer protocol between the EAP peer and EAP
   authenticator or a AAA protocol between the EAP authenticator or the
   EAP server.  The solution, however, requires each EAP method to carry
   EAP lower layer parameters, which is not actually needed for a
   standalone EAP authenticator while binding the EAP lower layer
   parameters to the AAA-Key is still somehow needed for both standalone
   and pass-through EAP authenticators.  This leads to a need for a more
   generic key binding mechanism that does not require any change in
   existing EAP methods and can work with both standalone and pass-
   through EAP authenticators in the same way.






















Ohba & Yanagiya         Expires December 3, 2005                [Page 4]

Internet-Draft               AAA-Key Binding                    Jun 2005


3.  Prerequisites

   There are following prerequisites for the solution proposed in this
   document to work.

3.1  Trust Relationship

   In this document, trust relationship is characterized with a "trust
   level" to cover a wide range of scenarios including roaming
   scenarios.  A full level of trust relationship between two or more
   entities is defined where each entity trusts whatever other entities
   claim.  There are following prerequisites with regard to trust
   relationship between an EAP peer, an EAP authenticator and an EAP
   server involving in an EAP conversation.

   o  There is a full level of trust relationship between the EAP peer
      and the EAP server.

   o  There is a trust relationship between the EAP server and the EAP
      authenticator.  The trust level between them may vary depending on
      the deployment.  For example, if they are implemented on the same
      physical box, it is highly likely that there is a full level of
      trust relationship between them.  On the other hand, if they are
      implemented on different physical boxes belonging to different
      service providers, there may not be a full level of trust
      relationship between them, even if there is some sort of roaming
      agreement between the service providers.  In this case, the EAP
      server does not always trust what the EAP authenticator claims.

   o  There is a trust relationship between the EAP peer and the EAP
      authenticator, but most likely the trust relationship is not a
      full level.  The level of the trust relationship is high enough
      for the EAP peer to use the AAA-Key in the service provided by the
      EAP lower-layer.


3.2  Securty Association

   In general, a security association is a relationship established
   between two or more entities to enable them to protect data they
   exchange [RFC2828].  A security association needs to be established
   between such entities unless the underlying communication path is
   already protected by some other mechanism.  The following security
   associations needs to be established prior to execute EAP.

   o  A security association between the EAP peer and the EAP server in
      order to establish an MSK (Master Session Key) [I-D.ietf-eap-
      keying].



Ohba & Yanagiya         Expires December 3, 2005                [Page 5]

Internet-Draft               AAA-Key Binding                    Jun 2005


   o  A security association between the EAP authenticator and the EAP
      server in case an untrusted third party may interfere the
      communication between them.
















































Ohba & Yanagiya         Expires December 3, 2005                [Page 6]

Internet-Draft               AAA-Key Binding                    Jun 2005


4.  Solution Framework

   In the proposed solution, it is the EAP lower-layer entities that
   make final decision as to whether the the lower-layer parameters are
   successfully bound to the AAA-Key, regardless of the location of the
   EAP server.  To this end, the EAP server that has a trust
   relationship with both the EAP peer and the EAP authenticator needs
   to involve in the process of binding the EAP lower-layer parameters
   to the AAA-Key.  The proposed solution, however, does not require EAP
   and EAP methods to carry EAP lower-layer parameters.  The proposed
   solution is designed such that the AAA-Key derivation algorithm is
   agnostic to specific EAP lower-layer parameters.

4.1  Key Binding Blob for Lower-Layer Parameters

   Each EAP lower-layer must define a blob that is an octet-string used
   for carrying lower-layer parameters that need to be bound to the AAA-
   Key. Such a blob is referred to as a "key-binding-blob".  A key-
   binding-blob contains parameters that persist long-term such as the
   identification of the EAP authenticator.  It is the responsibility of
   each EAP lower-layer to define how the EAP lower-layer parameters are
   encoded in the blob.

   When the EAP authenticator and the EAP server are implemented in
   different physical boxes, a key-binding-blob is carried in a AAA
   protocol as described in Section 6.

4.2  AAA-Key Derivation Algorithm

   As a result of successful authentication, the EAP peer and EAP server
   derives a AAA-Key from the MSK [I-D.ietf-eap-keying] exported by the
   EAP method as follows.

   AAA-Key = KDF(MSK, AAA-Key-name|key-binding-blob)

   KDF is a key derivation function.  The definition of KDF is TBD.
   AAA-Key-name is the name of the AAA-Key.  The format of the name of
   AAA-Key is described in Section 4.4

4.3  AAA-Key Scope

   The scope of a AAA-Key is between the pair of a particular EAP peer
   and a particular EAP authenticator.  The AAA-Key MUST NOT be shared
   among multiple EAP authenticators or multiple EAP peers.

4.4  AAA-Key Name

   TBD.



Ohba & Yanagiya         Expires December 3, 2005                [Page 7]

Internet-Draft               AAA-Key Binding                    Jun 2005


4.5  Key Binding Procedure

   During an EAP authentication run, the EAP authenticator constructs a
   key-binding-blob from the EAP lower-layer parameters and sends the
   key-binding-blob to the EAP server.  When the EAP authenticator is
   acting as a pass-through authenticator, a AAA protocol would be used
   for communicating the key-binding-blob to the EAP server.

   Depending on the level of the trust relationship between the EAP
   authenticator and EAP server, the EAP server MAY validate the key-
   binding-blob as described in Section 5 and the authentication
   procedure MUST fail when the validation fails.

   Upon successful EAP authentication, the EAP peer and the EAP server
   are expected to compute the AAA-Key using the above algorithm.  The
   computed AAA-Key is delivered from the EAP server to the EAP
   authenticator.

   Finally, the EAP peer and the EAP authenticator verify the possession
   of the AAA-Key via a secure association protocol to establish a
   secure association.  For the verification process to succeed, it is
   required for the EAP authenticator to have obtained the same AAA-Key
   from the EAP server as the EAP peer has.  This actually requires the
   EAP authenticator to have sent the same key-binding-blob to the EAP
   server as the one the EAP peer constructs from the lower-layer
   parameters obtained via the lower-layer protocol.

























Ohba & Yanagiya         Expires December 3, 2005                [Page 8]

Internet-Draft               AAA-Key Binding                    Jun 2005


5.  Validating Key Binding Blob

   As described in Section 3.1, the level of trust relationship between
   an EAP authenticator and an EAP server may vary depending on the
   deployment.  When there is a full level of trust relationship between
   the EAP authenticator and EAP server, the EAP server can trust
   information sent by the EAP authenticator and thus it is not
   necessary for the EAP server to verify the EAP lower-layer parameters
   encoded in the key-binding-blob.

   On the other hand, when there is not a full level of trust
   relationship between the EAP authenticator and EAP server, the EAP
   server may not fully trust information sent by the EAP authenticator
   and thus it would need to verify the EAP lower-layer parameters
   encoded in the key-binding-blob.  The verification of the key-
   binding-blob can be performed based on simple string comparison with
   the expected value that may be pre-configured on the EAP server,
   meaning that the EAP server would need to know the structure and
   semantics of the key-binding-blob when the key-binding-blob is pre-
   configured.  However, the EAP server can still be agnostic to the
   structure and semantics of the key-binding-blob during the execution
   of the verification procedure.





























Ohba & Yanagiya         Expires December 3, 2005                [Page 9]

Internet-Draft               AAA-Key Binding                    Jun 2005


6.  AAA Protocol Consideration

   When a AAA protocol such as RADIUS [RFC2865] and Diameter [RFC3588]
   is used for carrying EAP messages between an EAP authenticator and
   the EAP server, a key-binding-blob is carried in a AAA protocol.  The
   Key-Binding-Blob attribute, which is a new RADIUS attribute, is
   defined for this purpose.  Since Diameter has a backward
   compatibility with RADIUS, it is possible to automatically convert
   one or more RADIUS Key-Binding-Blob attribute to a corresponding
   Diameter AVP and vise versa.  The Key-Binding-Blob attribute MUST NOT
   be modified by an intermediary AAA node such as a AAA proxy.

   Considering that the maximum size of a RADIUS attribute value is 253
   octets and that the size of the key-binding-blob can exceed 253
   octets, the Key-Binding-Blob attribute is defined to allow
   fragmentation in the following way.

   When the size of the key-binding-blob is X octets (X>0) and RADIUS is
   used for carrying the key-binding-blob, the key-binding-blob is split
   into (X div 253) octet-strings, where each octet-string is carried in
   a separate RADIUS Key-Binding-Blob attribute with a distinct fragment
   identifier (Fragment ID) which starts from zero (0) and incremented
   by one (1).  A Key-Binding-Blob attribute also has a flag (L-flag) to
   indicate the last fragment.  The L-flag MUST be set for a Key-
   Binding-Blob attribute carrying the last fragment, otherwise it MUST
   be unset.

   When Diameter is used for carrying the key-binding-blob, the entire
   key-binding-blob is carried in a single Key-Binding-Blob AVP, with
   the L-flag set and the Fragment ID set to zero (0).

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |L| Fragment ID |    String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: TBD

      Represents Key-Binding-Blob.

   Length: >=4

   L(ast flagment):








Ohba & Yanagiya         Expires December 3, 2005               [Page 10]

Internet-Draft               AAA-Key Binding                    Jun 2005


      Indicates whether this is the last fragment.  If there is only one
      fragment, the L-flag MUST be set.

   Fragment ID:

      Fragment identifier used for identifying a fragment of a key-
      binding-blob.  The identifier starts from zero (0) and incremented
      by one (1).

   String:

      Contains a fragment of a key-binding-blob.







































Ohba & Yanagiya         Expires December 3, 2005               [Page 11]

Internet-Draft               AAA-Key Binding                    Jun 2005


7.  Co-existence with Legacy AAA-Key Derivation Algorithm

   The following consideration is needed in order to interwork with EAP
   lower layers that use the legacy AAA-Key derivation algorithm (i.e.,
   AAA-Key=MSK(0,63) [I-D.ietf-eap-keying]) instead of the algorithm
   described in Section 4.2.

   An EAP authenticator for an EAP lower layer using the legacy AAA-Key
   derivation algorithm is allowed to not send a key-binding-blob to the
   EAP server.  If an EAP authenticator does not send a key-binding-blob
   to the EAP server, and the EAP server is configured to use the legacy
   AAA-Key derivation algorithm for the EAP authenticator, a AAA-Key is
   derived based on the algorithm described in [I-D.ietf-eap-keying].
   If an EAP authenticator does not send a key-binding-blob to the EAP
   server and the EAP server is configured to use the AAA-Key derivation
   algorithm described in Section 4.2 for the EAP authenticator, the
   authentication procedure MUST fail.  If an EAP authenticator sends a
   key-binding-blob to the EAP server and the EAP server is configured
   to use the legacy AAA-Key derivation algorithm for the EAP
   authenticator, the authentication procedure MUST fail.































Ohba & Yanagiya         Expires December 3, 2005               [Page 12]

Internet-Draft               AAA-Key Binding                    Jun 2005


8.  Discussion

   The solution described in this document makes EAP methods totally
   agnostic to EAP lower-layers.  EAP methods do not need to carry EAP
   lower-layer parameters even in the form of a blob.

   The solution does not require the the EAP server to know about the
   structure and the semantics of the key-binding-blob during the
   execution of the EAP authentication.  However, the EAP server may
   need to identify at least the type of the EAP lower layer in order to
   avoid the situation where the EAP authenticator sends a key-binding-
   blob for an EAP lower layer that is different from what is expected
   by the EAP server, but the content of the key-binding-blob happens to
   match the expected value.  How the EAP lower layer type information
   is carried from the EAP authenticator to the EAP peer (e.g., carrying
   it in the key-binding-blob or in the AAA-Key-name or by some other
   means) is an open issue.

   The solution works regardless of whether an EAP authenticator is
   acting as a pass-through authenticator or not.

   Although the solution requires a change in the AAA-Key derivation
   algorithm described in section 2.3 of [I-D.ietf-eap-keying], the
   solution can co-exist with the legacy AAA-Key derivation algorithm as
   described in Section 7.


























Ohba & Yanagiya         Expires December 3, 2005               [Page 13]

Internet-Draft               AAA-Key Binding                    Jun 2005


9.  Security Considerations

   The solution described in this document improves the security
   characteristics of the EAP key management framework in that a secure
   association is never established if there is a difference in EAP
   lower-layer parameters recognized by the EAP peer and the EAP
   authenticator.  This is in contrast to existing parameter binding
   methods described in [I-D.arkko-eap-service-identity-auth]
   [I-D.tschofenig-eap-ikev2] in which an EAP peer can still establish a
   secure association even when a mismatch in EAP lower-layer parameters
   is detected by the EAP peer, as the EAP peer can ignore the mismatch
   and continue the EAP conversation to succeed.







































Ohba & Yanagiya         Expires December 3, 2005               [Page 14]

Internet-Draft               AAA-Key Binding                    Jun 2005


10.  Acknowledgments

   The authors would like to thank Jari Arkko and Bernard Aboba for
   discussing this issue on the EAP mailing list and giving insights.
   The authors would like to thank Rafa Marin Lopez and Julien Bournelle
   for reviewing the document.













































Ohba & Yanagiya         Expires December 3, 2005               [Page 15]

Internet-Draft               AAA-Key Binding                    Jun 2005


11.  References

11.1  Normative References

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

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

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

11.2  Informative References

   [RFC2828]  Shirey, R., "Internet Security Glossary", RFC 2828,
              May 2000.

   [I-D.arkko-eap-service-identity-auth]
              Arkko, J. and P. Eronen, "Authenticated Service
              Information for the Extensible Authentication Protocol
              (EAP)", draft-arkko-eap-service-identity-auth-02 (work in
              progress), May 2005.

   [I-D.tschofenig-eap-ikev2]
              Tschofenig, H., "EAP IKEv2 Method (EAP-IKEv2)",
              draft-tschofenig-eap-ikev2-06 (work in progress),
              May 2005.













Ohba & Yanagiya         Expires December 3, 2005               [Page 16]

Internet-Draft               AAA-Key Binding                    Jun 2005


Authors' Addresses

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscateway, NJ  08854
   USA

   Phone: +1 732 699 5365
   Email: yohba@tari.toshiba.com


   Mayumi Yanagiya
   NTT Network service systems laboratories, NTT Corporation
   9-11, Midori-Cho, 3-Chome
   Musashino-Shi, Tokyo 180-8585
   Japan

   Email: yanagiya.mayumi@lab.ntt.co.jp
































Ohba & Yanagiya         Expires December 3, 2005               [Page 17]

Internet-Draft               AAA-Key Binding                    Jun 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Ohba & Yanagiya         Expires December 3, 2005               [Page 18]