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

Versions: 00 01 02

EAP Working Group                                                Y. Ohba
Internet-Draft                                                   Toshiba
Intended status: Informational                          M. Parthasarathy
Expires: June 6, 2007                                              Nokia
                                                             M. Yanagiya
                                                                     NTT
                                                        December 3, 2006


 Channel Binding Mechanism based on Parameter Binding in Key Derivation
                   draft-ohba-eap-channel-binding-02

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 June 6, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).











Ohba, et al.              Expires June 6, 2007                  [Page 1]


Internet-Draft          Channel Binding Mechanism          December 2006


Abstract

   This document describes a channel binding mechanism based on
   parameter binding in the key derivation procedure.  The method
   cryptographically binds service information to a key without need to
   carry the service information in EAP methods.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Basic Channel Binding Mechanism  . . . . . . . . . . . . . . .  7
     3.1.  Key Derivation Function  . . . . . . . . . . . . . . . . .  7
     3.2.  Key Scope  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Key Name . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.4.  Key Lifetime . . . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Key Caching  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Channel Binding Mechanism Variants . . . . . . . . . . . . . .  9
     4.1.  Multiple CBKs  . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Transferring CBMK  . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Hierarchical Channel Binding . . . . . . . . . . . . . . .  9
   5.  EAP Authenticator Consideration  . . . . . . . . . . . . . . . 10
   6.  Authenticator-Supplicant Protocol Requirements . . . . . . . . 11
   7.  EAP Method Requirements  . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA 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, et al.              Expires June 6, 2007                  [Page 2]


Internet-Draft          Channel Binding Mechanism          December 2006


1.  Introduction

   EAP (Extensible Authentication Protocol) is an authentication
   protocol which supports multiple authentication algorithms known as
   "EAP methods" [RFC3748].  In EAP, an EAP peer and an EAP server
   generates EAP keying material, i.e., MSK (Master Session Key) and
   EMSK (Extended Master Session Key).  A detailed framework for the
   generation, transport and usage of MSK is described in
   [I-D.ietf-eap-keying].

   Each access network has its own set of parameters advertised by the
   EAP authenticator to EAP peers.  The identity of the EAP
   authenticator is one of such parameters.  Such parameters are
   referred to as service information.  The service information should
   be bound to the MSK in a secure way to avoid possible security flaws.

   The Channel Binding mechanism that is described in [RFC3748] to
   create such a binding is based on communicating the service
   information over a protected channel of an EAP method to help the EAP
   peer and the authentication server detect a mismatch between the
   service information exchanged over the protected channel and the one
   advertised by the EAP authenticator to the EAP peer and the
   authentication server.  As the service information needs to be
   explicitly configured on the server, there is not much use for the
   peer to explicitly send it through the EAP method as specified in
   [RFC3748].  Also, this Channel Binding mechanism does not create
   cryptographic binding between the service information and EAP keying
   material.  Therefore, it is possible that no binding is actually made
   if the exchanged service information was not checked by the peer
   and/or the server.

   In any Channel binding solution the authentication server should be
   able to authenticate the service information provided by the EAP
   authenticator.  It is not sufficient if it just ensures that the same
   information is available at both the EAP peer and authentication
   server.  The EAP authenticator can provide the same false information
   to both the EAP peer and authentication server.  For this reason, the
   authentication server needs to be configured with the service
   information of the EAP authenticators (out-of band) for
   authenticating the service information.

   On the other hand, in roaming situations, this becomes difficult if
   there is no direct trust relationship with the visited network.  In
   that case, an intermediary should be able to authenticate the service
   information on behalf of the authentication server.

   This document describes an alternative Channel Binding mechanism to
   create a binding between a key exported by EAP method and the service



Ohba, et al.              Expires June 6, 2007                  [Page 3]


Internet-Draft          Channel Binding Mechanism          December 2006


   information.  The mechanism has the following characteristics:

   o  The mechanism retains EAP invariants, i.e., mode independence,
      media independence, method independence and ciphersuite
      independence.

   o  The mechanism does not necessarily require any change to existing
      EAP authenticators.

   o  The mechanism is scalable to support a large number of EAP
      authenticators.

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, et al.              Expires June 6, 2007                  [Page 4]


Internet-Draft          Channel Binding Mechanism          December 2006


2.  Terminology

   Channel Binding Key (CBK)

      A key that is derived from a Channel Binding Master Key (CBMK) and
      cryptographically bound to a Key Binding Blob (KBB) using a Key
      Derivation Function (KDF).  A CBK is at lest 64 octets in length.

   Channel Binding Master Key (CBMK)

      A key from which a CBK is derived using a KDF.  An MSK or an EMSK
      is a CBMK.  A CBMK is at lest 64 octets in length.

   Key Binding Blob (KBB)

      An octet-string that is constructed from the service information
      advertised by an authenticator using an Authenticator-Supplicant
      Protocol (ASP).

   Key Derivation Function (KDF)

      A function by which a CBK is generated using a CBMK and a KBB as
      input.

   Server

      An entity that creates a CBK and transfers it to the
      authenticator.  An EAP server is a server of this mechanism.

   Authenticator

      A network-side entity that uses a CBK for an Authenticator-
      Supplicant Protocol (SAP).  An authenticator may or may not be co-
      located with the server in the same equipment.  An EAP
      authenticator is an authenticator of this mechanism.

   Supplicant

      A user-side entity that uses a CBK for an Authenticator-Supplicant
      Protocol (SAP).  An EAP peer is a supplicant of this mechanism.

   Authenticator-Supplicant Protocol (ASP)

      A protocol that is executed between an supplicant and an
      authenticator and uses a CBK for binding an authenticated identity
      to the protocol.  The supplicant obtains the service information
      from the authenticator using the ASP where the service information
      is used for constructing a KBB.  The specification of the ASP



Ohba, et al.              Expires June 6, 2007                  [Page 5]


Internet-Draft          Channel Binding Mechanism          December 2006


      defines how to construct a KBB from the service information.  The
      notion of ASP is broader than Secure Association Protocol (SAP)
      [I-D.ietf-eap-keying] in that an ASP is used not only for secure
      association but also for advertising the service information.
      IKEv2, PANA, IEEE 802.11i, IEEE 802.11r and IEEE 802.16e are ASPs.














































Ohba, et al.              Expires June 6, 2007                  [Page 6]


Internet-Draft          Channel Binding Mechanism          December 2006


3.  Basic Channel Binding Mechanism

   The basic channel binding mechanism is described as follows (see
   Figure 1.

          +------------+      +-------------+       +--------------+
          |   Server   |      |Authenticator|       | Supplicant   |
          |            |      |             |       |              |
          |            |      |             |       |  KBB         |
          |  KBB CBMK  |      |             |       | +---+  CBMK  |
          |   |   |    |      |             |       | |   |   |    |
          |   v   v    |      |             |       | |   v   v    |
          |  +-----+   |      |             |       | |  +-----+   |
          |  | KDF |(1)|      |             |       | |  | KDF |(1)|
          |  +-----+   |      |             |       | |  +-----+   |
          |     |      |      |             |       | \    |       |
          |     |      |      |             |       |  \   v CBK   |
          |     | CBK  |  (2) |   +----+    |  (3)  |  +----+      |
          |     +---------------->|ASPI|<------------->|ASPI|      |
          |            |      |   +----+    |       |  +----+      |
          +------------+      +-------------+       +--------------+

                             ASPI: Instance of ASP

                 Figure 1: Basic Channel Binding Mechanism

   1.  CBK Creation: A server and supplicant creates a CBK used for an
       authenticator.  The CBK is derived from a CBMK and bound to a KBB
       associated with the authenticator using a KDF.  The KBB is pre-
       configured on the server.

   2.  CBK Transfer: The server transfers the CBK to the authenticator.

   3.  CBK Verification: The supplicant and authenticator verifies proof
       of possession of the CBK over the ASP.  After successful
       verification of proof of possession of the CBK, the supplicant
       and authenticator are able to use the CBK in the ASP.

3.1.  Key Derivation Function

   A CBK is computed using prf+ defined in IKEv2 [RFC4306] in the
   following way.

   CBK = prf+(CBMK, KBB)







Ohba, et al.              Expires June 6, 2007                  [Page 7]


Internet-Draft          Channel Binding Mechanism          December 2006


3.2.  Key Scope

   The scope of a CBK MUST be within the pair of the supplicant and
   authenticator that use the CBK.

3.3.  Key Name

   The name of a CBK is the string concatenation of the name of the CBMK
   and "CBK".

3.4.  Key Lifetime

   The lifetime of a CBK is determined based on the guidelines on
   exported and calculated key lifetimes described in
   [I-D.ietf-eap-keying].

3.5.  Key Caching

   Where explicitly supported by the ASP, the ASP MAY cache a CBK.
































Ohba, et al.              Expires June 6, 2007                  [Page 8]


Internet-Draft          Channel Binding Mechanism          December 2006


4.  Channel Binding Mechanism Variants

4.1.  Multiple CBKs

   In this scenario, a server creates multiple CBKs from a single CBMK
   for multiple authenticators by using different KBBs for different
   authenticators.

4.2.  Transferring CBMK

   An entity that owns a CBMK MAY transfer the ownership of the CBMK to
   a trusted entity by transferring the CBMK to that entity.  The
   recipient or the new owner of the CBMK MAY then act as the server on
   behalf of the previous owner or further transfer the ownership to
   another trusted entity.

4.3.  Hierarchical Channel Binding

   This channel binding mechanism allows CBKs to form a hierarchy (see
   Figure 2).  As the service information needs to be explicitly
   configured for each authenticator at the server, it may become
   cumbersome to support large number of authenticators.  The
   hierarchical Channel Binding mechanism helps solve the scalability
   problems when such large number of authenticators are present in a
   single visited network domain.

                                   CBMK0
                                  / .. \
                                 /      \
                             CBK0_1     CBK0_n
                           (=CBMK1_1)  (=CBMK1_n)
                            / .. \     / .. \
                           /      \   /      \
                          ..      .. ..      ..


                  Figure 2: Hierarchical Channel Binding

   In hierarchical Channel Binding, CBK verification may be performed at
   each level of the key hierarchy or only at the lowest level of the
   hierarchy.  In the latter case, the lowest level authenticator MUST
   advertise, in the lowest level ASP, the service information necessary
   to construct a KBB at each level of the hierarchy.

   Also, different hash algorithms used for prf+ may be negotiated at
   different levels and different branches of the hierarchy.





Ohba, et al.              Expires June 6, 2007                  [Page 9]


Internet-Draft          Channel Binding Mechanism          December 2006


5.  EAP Authenticator Consideration

   When this mechanism is used, an EAP authenticator will receive and
   process a CBK as if it were an MSK.  This enables the mechanism to
   work with the already deployed EAP authenticators without any
   modifications to them.













































Ohba, et al.              Expires June 6, 2007                 [Page 10]


Internet-Draft          Channel Binding Mechanism          December 2006


6.  Authenticator-Supplicant Protocol Requirements

   Any ASP that claims to support this mechanism MUST define how a KBB
   is constructed from the service information specific to the ASP where
   the KBB construction mechanism MUST satisfy all of the following
   requirements:

   o  Only static service information such as the identity of the
      authenticator is used for constructing KBBs.

   o  Probability of KBB collision in which the same KBB is associated
      with different authenticators of the ASP is either zero or
      reasonably low.  A KBB collision may occur (i) when the KBB is
      computed as a hash of the service information or (ii) if the
      authenticators use different ASPs among which uniqueness of KBB is
      not guaranteed.  A KBB collision may lead to domino effect
      [I-D.housley-aaa-key-mgmt] among authenticators associated with
      the collided KBB.

































Ohba, et al.              Expires June 6, 2007                 [Page 11]


Internet-Draft          Channel Binding Mechanism          December 2006


7.  EAP Method Requirements

   Any EAP method that claims to support the mechanism described in this
   document MUST provide at least all of the following functionalities.

   1.  Negotiation on enabling this mechanism.  The EAP method MUST
       support the following negotiation over a protected channel.

       *  A functionality for the EAP peer to indicate the EAP server
          the desire to use this mechanism.

       *  A functionality to enable this mechanism when the EAP peer
          indicated the desire to use this mechanism and the EAP server
          implements this mechanism.

       *  A functionality to disable this mechanism when the EAP peer
          did not indicate the desire to use this mechanism.

       *  A functionality to fail the EAP method conversation when the
          EAP peer indicated the desire to use this mechanism while the
          EAP server does not implement this mechanism.

   2.  Negotiation on or specification of a hash algorithm.  The EAP
       method MUST either provide, over a protected channel, a mechanism
       for negotiating on a hash algorithm used for prf+, or specify one
       hash algorithm used for prf+.

























Ohba, et al.              Expires June 6, 2007                 [Page 12]


Internet-Draft          Channel Binding Mechanism          December 2006


8.  Security Considerations

   The mechanism described in this document improves the security
   characteristics of the EAP key management framework in the following
   aspects.

   o  A secure association can never be established via the ASP if there
      is a difference in the KBB advertised by the EAP authenticator to
      the EAP peer and the KBB configured on the EAP server.  This means
      that the mechanism can only be applied where EAP methods
      generating key material are used along with lower layers that
      utilize the keying material.  For example, this mechanism would
      not enable verification of Channel Bindings on wired IEEE 802
      networks using IEEE 802.1X, however, if a lower layer does not
      utilize the keying material, various attacks including a man-in-
      the-middle attack is possible.

   o  Even if a CBK is somehow transferred to an authenticator other
      than the intended one, the CBK can never be used by the non-
      intended authenticator as long as the KBB used for deriving the
      CBK does not collide between the intended and unintended
      authenticators.

   The security level of this mechanism depends on probability of KBB
   collision among authenticators of the same ASP and among
   authenticators of different ASPs.

























Ohba, et al.              Expires June 6, 2007                 [Page 13]


Internet-Draft          Channel Binding Mechanism          December 2006


9.  IANA Considerations

   This document has no actions for IANA.
















































Ohba, et al.              Expires June 6, 2007                 [Page 14]


Internet-Draft          Channel Binding Mechanism          December 2006


10.  Acknowledgments

   TBD.
















































Ohba, et al.              Expires June 6, 2007                 [Page 15]


Internet-Draft          Channel Binding Mechanism          December 2006


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.

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

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

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

11.2.  Informative References

   [I-D.housley-aaa-key-mgmt]
              Housley, R. and B. Aboba, "Guidance for AAA Key
              Management", draft-housley-aaa-key-mgmt-06 (work in
              progress), November 2006.


























Ohba, et al.              Expires June 6, 2007                 [Page 16]


Internet-Draft          Channel Binding Mechanism          December 2006


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


   Mohan Parthasarathy
   313 Fairchild Drive
   Mountain View CA  94043
   USA

   Email: mohan.parthasarathy@nokia.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, et al.              Expires June 6, 2007                 [Page 17]


Internet-Draft          Channel Binding Mechanism          December 2006


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

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ohba, et al.              Expires June 6, 2007                 [Page 18]


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