Hi Jari, This discussion has prompted me to look at the spec again. Is there a need to fall back to the AKA derivation? It seems that the AAA providing AKA or AKA' support would know what is supported by the infrastructure. Having the fallback to AKA is confusing. If you chose the alternate approach of using the same EAP ID then it would be necessary. I have a another comment on the AT_KDF_INPUT field. Are the contents of this field dependent upon the value of AT_KDF? It seems that they should be, in the future perhaps there would need to be additional information as input to the KDF. I think the document should either make the AT_KDF_INPUT specific to the AKA' KDF by changing it to AT_NETWORK_NAME or AT_KDF_INPUT attribute should be defined more generically so it can handle changes in KDF in the future (this would probably be just to define the attribute as an octet string whose contents is defined by the AT_KDF and more the network name to a section defining the input for KDF 2). Also, how does the peer know what the value of the network name should be? Is this a parameter that needs to be configured on the peer? It seems that the protocol should allow for the peer's notion of the network name to be sent to the server so the server is also informed if there is a mismatch. Troubleshooting problems would be easier on the server side instead of relying on obtaining peer logs or relying upon inconsistent client behavior. Actually verifying the name is just a SHOULD so some peers may fail and others may not. Joe > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Lakshminath Dondeti > Sent: Tuesday, October 14, 2008 3:22 PM > To: Jari Arkko > Cc: Pasi Eronen; ietf@xxxxxxxx; 'iesg@xxxxxxxx' > Subject: Re: Last Call: draft-arkko-eap-aka-kdf > (ImprovedExtensible AuthenticationProtocol Method for 3rd > Generation Authentication and KeyAgreement (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 > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf