Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@xxxxxxxxx] > Sent: Thursday, October 16, 2008 2:24 AM > To: Joseph Salowey (jsalowey) > 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 > > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf