Skip to main content

Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
RFC 6738

Yes

(Dan Romascanu)

No Objection

(Adrian Farrel)
(David Harrington)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 11 and is now closed.

(Dan Romascanu; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(David Harrington; former steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2011-06-23)
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

No Objection (2011-06-17)
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

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2011-06-22)
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

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2011-10-29)
"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

No Objection ()

                            

(Wesley Eddy; former steering group member) No Objection

No Objection ()