Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
RFC 6738
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
(Dan Romascanu; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
Regarding other Discusses, I am actually fine with the document otherwise except the above point, and with some documentation of the security assumptions and implications it should be possible to publish it. However, I do have one additional concern that should be discussed. I'm not too happy about the decision to leave the PSK generation algorithm outside the scope of this specification. It basically means that there is no interoperability.
(Pete Resnick; former steering group member) No Objection
I am neither an IKE person nor a Diameter person. That said, the following sentence, which appears in the Abstract and Introduction, is completely incomprehensible to me: This document specifies IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre- shared key based authentication. If IKE and Diameter people will understand that sentence, you can feel free to ignore me, but I have no idea what that means.
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
I support Russ' discuss. I also encourage stating more clearly that there is no mechanism for negotiating/detecting which PSK derivation algorithm is in use - that this is entirely manually managed configuration. Is it realistic that this would be run-time configuration, or is it expected that it would be set at manufacture or compile?
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
"It is expected..." in the security considerations is no longer correct. If you're using the Key AVP then draft-ietf-dime-keytran (which is now at -14 btw) then that says that you MUST only send via TLS or IPsec if the Key AVP isn't self-protecting which applies here, at least for the default. I think this fact means that some of the other text in these security considerations is no longer needed. There's no change required here really but I wanted to point it out since its a post-WG change to keytran that was made since I first reviewed this document.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection