-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Lakshminath Dondeti
Sent: Tuesday, October 14, 2008 3:22 PM
To: Jari Arkko
Cc: Pasi Eronen; ietf(_at_)ietf(_dot_)org; 'iesg(_at_)ietf(_dot_)org'
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf