Subject: [Emu] Channel Bindings and draft-arkko-eap-aka-kdf

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Aug 2008 23:10:59 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/emu