Hi Jari,
-----Original Message-----
From: Jari Arkko [mailto:jari(_dot_)arkko(_at_)piuha(_dot_)net]
Sent: Thursday, October 16, 2008 2:24 AM
To: Joseph Salowey (jsalowey)
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
Joe,
First, after some discussion with some of the users of this
spec from 3GPP, we have decided that AT_KDF=1 or the AKA
fallback mode should be removed.
AT_KDF_INPUT field values would indeed be dependent on which
KDF is used. I will make the second change you suggested to fix this.
[Joe] Thanks.
On the network name: the client and the network execute the
same algorithm to determine the network name. It has to be
done by both, as otherwise we could not compare the two and
the key derivation would not be very useful. There are
obviously several ways in which the comparison could be
carried out, transporting information in one or the other
direction or both. The authors have chosen a particular model
which is simple from a protocol perspective and gives more
responsibility for the end host to deal with policy decisions
upon a mismatch. There are different tradeoffs with other
models, but I'm not necessarily convinced that they would be
superior. I do note as well that centralized policy and other
management tools blur the distinctions a bit. I will,
however, change the text because the intent was to require
that the check be always made, but allow a policy driven
decision on whether to abort or to continue with a warning.
[Joe]Its not clear to me that the peer will have access to the
information for verification, however it seems that the server side
will. This would increase the management burden on the peer. If
centralized management is in place then I guess this is not as much of a
problem. The management protocol can be used to provide the client with
information to determine the network name and inform the server if there
is a mismatch encountered on the client. It would be good to state some
of these assumptions on the reliance on an external system to handle
this.
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf