It's not really the "key derivation approach" as is, because the key
derivation is happening outside EAP -- it's part of the revised AKA'
algorithms that are used for other things than EAP.  (This is why the
"information exchange" approach was not possible.)

Also note this text in Section 5:

   "Channel binding

      EAP-AKA', like EAP-AKA, does not provide channel bindings as
      they're defined in [RFC3748] and [RFC5247].  New skippable
      attributes can be used to add channel binding support in the
      future, if required.

      However, including the network name field in the AKA' algorithms
      (which are also used for other purposes than EAP-AKA') does
      provide a form of cryptographic separation between different
      network names, which resembles channel bindings.  However, the
      network name does not typically identify the EAP (pass-through)
      authenticator.  See the following section for more discussion."

(RFC 3748 and 5247 currently define "channel bindings" as something
slightly different from what's here; e.g. the bindings here are not
endpoint identifiers, and they're not treated as purely opaque
blobs imported/exported by the EAP method.)

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: 29 August, 2008 09:11
> To: emu@ietf.org
> Subject: [Emu] Channel Bindings and draft-arkko-eap-aka-kdf
> 
> 
> A new version of "Improved EAP Method for 3rd Generation AKA" has 
> been posted:
> http://www.ietf.org/internet-drafts/draft-arkko-eap-aka-kdf-02.txt
>  
> This draft is interesting, because it may be a first step toward the
> deployment of channel bindings -- and also because utilizes the key
> derivation approach, as opposed to the information exchange
> approach, as discussed in Section 4 of the channel bindings
> document:
> (http://www.ietf.org/internet-drafts/draft-clancy-emu-chbind-01.txt)
>  
> To quote from Section 1 of "Improved EAP Method for 3rd Generation AKA":
> 
> "  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 keys derived within the method to the name of
>    the access network.  This limits the effects of compromised access
>    network nodes and keys.  This specification defines the EAP
>    encapsulation for AKA when the new key derivation mechanism is in
>    use."
> Section 5.1 analyzes the security aspects:
> "
> 5.1.  Security Properties of Binding Network Names
> 
>    The ability of EAP-AKA' to bind the network name into the used keys
>    provides some additional protection against key leakage to
>    inappropriate parties.  The keys used in the protocol are specific to
>    a particular network name.  If key leakage occurs due to an accident,
>    access node compromise, or another attack, the leaked keys are only
>    useful when providing access with that name.  For instance, a
>    malicious access point cannot claim to be network Y if has stolen
>    keys from network X. Obviously, if an access point is compromised,
>    the malicious node can still represent the compromised node.  As a
>    result, neither EAP-AKA' or any other extension can prevent such
>    attacks, but the binding to a particular name limits the attacker's
>    choices, allows better tracking of attacks, makes it possible to
>    identify compromised networks, and applies good cryptographic
>    hygiene.
> 
>    The peer verifies that its own observations about the access network
>    name are consistent with the server's observations.  The server
>    receives the EAP transaction from a given access network, and can
>    either trust the name claim the access network made over AAA
>    protocols, or it may additionally verify that this corresponds to the
>    name that this access network should be using.  Where such
>    verification is implemented, it becomes impossible for an access
>    network to claim to the peer that it is another access network.  This
>    prevents some "lying NAS" (Network Access Server) attacks.  For
>    instance, a roaming partner, R, might claim that it is the home
>    network H in an effort to lure peers to connect to itself.  Such an
>    attack would be beneficial for the roaming partner if it can attract
>    more users, and damaging for the users if their access costs in R are
>    higher than those in other alternative networks, such as H.
> 
>    Any attacker who gets hold of the keys CK, IK produced by the AKA
>    algorithm can compute the keys CK', IK' and hence the master key MK
>    according to the rules in Section 3.3.  The attacker could then act
>    as a lying NAS.  In 3GPP systems in general, the keys CK and IK have
>    been distributed to, for instance, nodes in visited access network
>    where they may be vulnerable.  In order to reduce this risk this
>    specification mandates that the AKA algorithm must be computed with
>    the AMF separation bit set to 1, and that the peer checks that this
>    is indeed the case whenever it runs EAP-AKA'.  Furthermore,
>    [3GPP.33.402] requires that no keys computed in this way ever leave
>    the home subscriber system.
> 
>    The additional security benefits obtained from the binding depend
>    obviously on the way names are assigned to different access networks.
>    This is specified in [3GPP.23.003].  Ideally, the names allow
>    separating each different access technology, each different access
>    network, and each different NAS within a domain.  If this is not
>    possible, the full benefits may not be achieved.  For instance, if
>    the names identify just an access technology, use of compromised keys
>    in a different technology can be prevented, but it is not possible to
>    prevent their use by other domains or devices using the same
>    technology."
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu