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') '
<draft-arkko-eap-aka-kdf-05.txt> 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
