This is a followup on my previous gen-art reviews of draft-ietf-dime-ikev2-psk-diameter based on version 09. I realize that came out a couple of weeks ago, and this followup may be overtaken by events. I am sending it anyway on the off chance it's still meaningful. This version partially addresses my concerns (below), in that it now specifies a default mechanism for PSK generation. If I understand correctly, use of this mechanism is completely optional. That is, the actual mechanism chosen is still a matter of out-of-band agreement between the HAAA and the IKEv2 peer. And if I read correctly, there is still no way for either to declare or negotiate what mechanism they plan to use. I realize the draft assumes that this will be used in the context of a "protocol leveraging this diameter application", and that said protocol should specify the key derivation mechanism to be used. I interpret (perhaps incorrectly) to mean that a given IKEv2 peer and a given HAAA are expected to be implemented for a particular context, and that the authors do not expect an IKEv2 peer from one context to work with an HAAA from another. Furthermore, it appears to me that if 2 such mismatched peers tried to communicate, the only way they could determine they were incompatible would be through authentication failures due to a key mismatch. I'm not sure that's an appropriate assumption for an IETF proposed standard. Ideally, I think things would be improved if the included key derivation procedure was promoted to MUST implement, and a mechanism were added where the peers can declare or negotiate the intent to use some other procedure if they choose to do so. At the minimum, it would be good to have a way where two peers could detect a key derivation mismatch early in the process. On Jun 17, 2011, at 5:10 PM, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-dime-ikev2-psk-diameter-08 > Reviewer: Ben Campbell > Review Date: 2011-06-17 > IESG Telechat date: 2011-06-23 > > Summary: This draft is almost ready for publication as a proposed standard. I still have a concern about the generation of the PSK. > > Major issues: > > In my initial Gen-ART review, I made the following comment: The draft says that the procedure that the HAAA follows to generate the PSK is out of scope. But doesn't the IKE2 initiator need to understand the procedure? If the procedure is not defined somewhere, how you achieve any degree of interoperability? > > The author responded that the PSK generation was in fact important for interoperability, but that the specific procedures have been intentionally left to other specifications. It is up to specifications that use this Diameter application to define the PSK generation mechanism. Further, the author indicated 2 3GPP2 specs that have done this. > > I am still concerned that this means that this specification cannot be implemented in an interoperable way without effectively profiling it. There is no apparent coordination on how such profiling may be done, and by whom. I think this is likely to result in implementation islands that can't talk to each other. I recognize that there is precedent for doing this, but I think it is something that should not be done without careful consideration, particularly in a standards track RFC. I leave it to the IESG to confirm whether it is appropriate in this circumstance. > > I further note that there is no apparent way to negotiate or declare what PSK generation mechanism might be used, if an implementation supports more than one. > > Minor Issues: None > Editorial Comments: None > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf