Re: Last Call: draft-arkko-eap-aka-kdf (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')) to Informational RFC
Hi Jari, Thanks for your response. I am sorry I am still slow to respond. I agree we are better off standardizing a new method at the IETF. I think we should get rid of the AKA KDF in AKA' so that these are two separate methods. Method-level negotiation is easier IMO. However, if you are after the idea of having a single EAP method implementation in mobiles (just AKA' with support for AKA inside it), please let me know. I would prefer that. That would require a bit of coordination with 3GPP and 3GPP2 folks however. thanks, Lakshminath On 10/13/2008 6:35 AM, Jari Arkko wrote: Hi Lakshminath, and thanks for your review. After some conversations and thought, I think that the goal of "limiting the effects of compromised access network nodes and keys" (should that be clarified?) can be achieved with fewer changes to AKA. Fewer is better, lets talk about this. I like that we are trying to define a new method. I guess I can appreciate the move to SHA-256 (although are we claiming that HMAC-SHA-1 is a problem?). We are not. It is merely an engineering decision. If we are changing the behavior and specification for other reasons, updating the hash functions to newer ones is easy at the same time. Updating them at another time would be significantly more painful, e.g., possibly involving another new EAP Type code, backwards compatibility problems, etc. However, it is quite confusing in that the new method AKA's tries to be backward compatible and forward compatible (KDF negotiation). AKA' with old KDF, AT_KDF set to 1, seems to cause quite a bit of confusion by raising the issue of how would the backward compatibility really work. Why is the old KDF needed with AKA'? This is a feature of EAP-AKA' that we do not strictly speaking require in any of the uses cases that I'm aware of. So if you have some evidence that it is causing significant confusion, we could re-consider whether it needs to stay in the document. But let me explain the rationale. We designed EAP-AKA' not just because 3GPP wanted to use new key derivation functions, but also because EAP-AKA had no ability to negotiate key derivation functions to begin with. (I predict that we have not seen the last update to the key derivation functions.) Once you have this ability, EAP-AKA' is merely a superset of EAP-AKA, capable of using EAP-AKA KDF (KDF=1), the new KDF (KDF=2), or some future KDF. Again, choosing to use plain old EAP-AKA is also possible by negotiating it at the EAP method level. So you could argue that its superfluous to do this. However, if there is confusion I want to understand if its because of the ability to use EAP-AKA within EAP-AKA' or because the negotiation mechanism itself is confusingly described. If its the former, we can reconsider. If its the latter, we need to fix the text. Please see -06 that was posted today, as it includes some additional explanation of the negotiation mechanism, based on last call input we have gotten. The channel bindings and the CK' and IK' stuff seems also to be confusing. It was interpreted at least in one context as using key derivation to enforce EAP channel bindings (which is really not necessary). As it is, we are talking about method-level channel bindings, which then seems to be confusing elsewhere. I am wondering whether we can fix this all up before going forward with approval. For simplicity, I believe, we should just specify AKA' as a new method with no attempt at backward compatibility. Next, I think we should work on channel bindings at EAP level and not at the method level, especially given that AKA is used so widely. If you think removing KDF=1 helps, we can do that, but its a very small part of the specification. I agree that the IETF should work on EAP channel bindings, but as someone who has trying to do that for 5-6 years I do not think we should hold our breath. I think we may actually make some progress on that, but EAP-AKA' binding model is a very limited one compared to what a generalized channel binding mechanism would do. You could even argue that its a different concept, see what Pasi said in EMU discussion about this: http://www.ietf.org/mail-archive/web/emu/current/msg00929.html The use of CK' and IK' is central to the entire idea of 3GPP's new authentication model for AKA. What I want to ensure is that we have an interoperable IETF specification for running AKA in EAP under their new system. I did not design AKA or the new system, but I do want to ensure that the use of the new system does not break EAP. If we do not deliver a spec that is capable of doing this, there is a ready made set of hacks that some people want to use instead of a new EAP method. Of course, those hacks would destroy interoperability with RFC 4187. I do not want that to happen, so perhaps you understand why I want to make the minimal change to a method that we can change, and move on. Jari __
Re: Last Call: draft-arkko-eap-aka-kdf (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')) to Informational RFC
Hi Lakshminath, and thanks for your review. After some conversations and thought, I think that the goal of "limiting the effects of compromised access network nodes and keys" (should that be clarified?) can be achieved with fewer changes to AKA. Fewer is better, lets talk about this. I like that we are trying to define a new method. I guess I can appreciate the move to SHA-256 (although are we claiming that HMAC-SHA-1 is a problem?). We are not. It is merely an engineering decision. If we are changing the behavior and specification for other reasons, updating the hash functions to newer ones is easy at the same time. Updating them at another time would be significantly more painful, e.g., possibly involving another new EAP Type code, backwards compatibility problems, etc. However, it is quite confusing in that the new method AKA's tries to be backward compatible and forward compatible (KDF negotiation). AKA' with old KDF, AT_KDF set to 1, seems to cause quite a bit of confusion by raising the issue of how would the backward compatibility really work. Why is the old KDF needed with AKA'? This is a feature of EAP-AKA' that we do not strictly speaking require in any of the uses cases that I'm aware of. So if you have some evidence that it is causing significant confusion, we could re-consider whether it needs to stay in the document. But let me explain the rationale. We designed EAP-AKA' not just because 3GPP wanted to use new key derivation functions, but also because EAP-AKA had no ability to negotiate key derivation functions to begin with. (I predict that we have not seen the last update to the key derivation functions.) Once you have this ability, EAP-AKA' is merely a superset of EAP-AKA, capable of using EAP-AKA KDF (KDF=1), the new KDF (KDF=2), or some future KDF. Again, choosing to use plain old EAP-AKA is also possible by negotiating it at the EAP method level. So you could argue that its superfluous to do this. However, if there is confusion I want to understand if its because of the ability to use EAP-AKA within EAP-AKA' or because the negotiation mechanism itself is confusingly described. If its the former, we can reconsider. If its the latter, we need to fix the text. Please see -06 that was posted today, as it includes some additional explanation of the negotiation mechanism, based on last call input we have gotten. The channel bindings and the CK' and IK' stuff seems also to be confusing. It was interpreted at least in one context as using key derivation to enforce EAP channel bindings (which is really not necessary). As it is, we are talking about method-level channel bindings, which then seems to be confusing elsewhere. I am wondering whether we can fix this all up before going forward with approval. For simplicity, I believe, we should just specify AKA' as a new method with no attempt at backward compatibility. Next, I think we should work on channel bindings at EAP level and not at the method level, especially given that AKA is used so widely. If you think removing KDF=1 helps, we can do that, but its a very small part of the specification. I agree that the IETF should work on EAP channel bindings, but as someone who has trying to do that for 5-6 years I do not think we should hold our breath. I think we may actually make some progress on that, but EAP-AKA' binding model is a very limited one compared to what a generalized channel binding mechanism would do. You could even argue that its a different concept, see what Pasi said in EMU discussion about this: http://www.ietf.org/mail-archive/web/emu/current/msg00929.html The use of CK' and IK' is central to the entire idea of 3GPP's new authentication model for AKA. What I want to ensure is that we have an interoperable IETF specification for running AKA in EAP under their new system. I did not design AKA or the new system, but I do want to ensure that the use of the new system does not break EAP. If we do not deliver a spec that is capable of doing this, there is a ready made set of hacks that some people want to use instead of a new EAP method. Of course, those hacks would destroy interoperability with RFC 4187. I do not want that to happen, so perhaps you understand why I want to make the minimal change to a method that we can change, and move on. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-eap-aka-kdf (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')) to Informational RFC
Sorry for the last minute nature of this email, but I was checking with folks active in the standards bodies that use EAP-AKA. After some conversations and thought, I think that the goal of "limiting the effects of compromised access network nodes and keys" (should that be clarified?) can be achieved with fewer changes to AKA. I like that we are trying to define a new method. I guess I can appreciate the move to SHA-256 (although are we claiming that HMAC-SHA-1 is a problem?). However, it is quite confusing in that the new method AKA's tries to be backward compatible and forward compatible (KDF negotiation). AKA' with old KDF, AT_KDF set to 1, seems to cause quite a bit of confusion by raising the issue of how would the backward compatibility really work. Why is the old KDF needed with AKA'? The channel bindings and the CK' and IK' stuff seems also to be confusing. It was interpreted at least in one context as using key derivation to enforce EAP channel bindings (which is really not necessary). As it is, we are talking about method-level channel bindings, which then seems to be confusing elsewhere. I am wondering whether we can fix this all up before going forward with approval. For simplicity, I believe, we should just specify AKA' as a new method with no attempt at backward compatibility. Next, I think we should work on channel bindings at EAP level and not at the method level, especially given that AKA is used so widely. thanks, Lakshminath On 9/15/2008 7:50 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-10-13. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arkko-eap-aka-kdf-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17483&rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
