Hi Ben, Please see inline... -- Avi Lior --Bridgewater Systems >>eview Date: 2011-06-03 >> IETF LC End Date: 2011-06-03 >> >> >> Summary: >> >> This draft is almost ready for publication as a proposed standard. I >>have a question concerning the procedure for generating PSKs, and a >>number of minor and editorial comments. >> >> >> Major issues: >> >> 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? >> [VC] Indeed the IKEv2 initiator needs to understand the procedure. >>However, this draft focuses on IKEv2 server, as a Diameter client, to >>the Diameter server communication for IKEv2 with pre-shared key based >>authentication, and specifies Diameter application for this >>communication. It is left to specifications that make use of this >>Diameter application to specify where the PSK comes from and how it is >>generated. There are two 3GPP2 specs that make use of this Diameter >>application and both of those specs specify generation of the PSK. >>Statements to clarify this are added in v8. > >The effect of this is that this spec, as written, cannot be implemented >in an interoperable way. I don't think that meets the usual expectations >for a proposed standard. Now, I realize there are some situations where >the IETF has chosen this approach, and deliberately created a standards >track RFC that must be profiled for actual use--but hopefully that's the >exception rather than the rule. I guess it's up to the IESG to decide if >that is reasonable in this instance. (I'm explicitly not counting >situations where the IETF puts out a standard as a series of modular >RFCs, since I gather there's no immediate intent to publish PSK >generation RFCs.) > >Additionally, whether or not PSK generation mechanisms are specified in >the IETF vs somewhere else, how does an implementation (that might >support more than one such mechanism) know which to use for any given SA? >Is there a negotiation mechanism? I agree with your comments in general. What we need to keep in mind though is the intent of this draft, which is to deliver the PSK key to the IKEv2 server. The issues you discuss relating to PSK are issues that are there with or without this document. The document uses all the information that is available in IKEv2 to fetch that PSK and to allow a PSK to be derived (via the nonces). > >> >> >> Minor issues: >> > >[...] >[...] > >> >> -- section 10, 1st paragraph: "Furthermore, any agents that process >>IKEv2-PSK-Answer messages can see the contents of the Key AVP. For this >>reason, this specification strongly recommends avoiding Diameter agents >>when they cannot be trusted to keep the keys secret." >> >> Should that be normative? Is there no way to protect the PSK AVP from >>diameter agents? E.g. can it be encrypted? >> [VC] It is hard to use normative text here as this application can be >>used for many uses cases. Depending on the use case it may be possible >>to encrypt the PSK, however it is not possible to make it a requirement. > >I don't see why a "SHOULD" or "RECOMMENDED" would cause problems here, >along with some short explanation of why it might not always be possible. >Otherwise, the text says "strongly recommends", when, without normative >text, such recommendation is really pretty weak. I may be okay with using stronger terms (SHOULD or RECOMMEND). I actually wish now that this entire paragraph be deleted. The reason being is that the security issues relating to multi-hop Diameter communication is well understood and documented in 3588 (and we already make a reference to that document). I don't see a need for recommendation. [...] >> Nits/editorial comments: >> > >[...] > >> -- section 8, first paragraph: "whether the AVP MAY be encrypted." >> >> I don't see anything about encryption in the table. >> [VC] The text referring to encryption is deleted. >> > >So how does an implementor know if it can be encrypted? We used an old style of table which is not really used. There is no end to end encryption mechanisms in Diameter. And Diameter provides transport level security (integrity and privacy protection). If the end to end encryption that is between the Diameter Client (IKEv2 Server) and the Diameter Server (where the PSK is stored/generated) is needed it would have to be built on-top of this document - so the implementor will know. > >[...] _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf