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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf