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
