Transport Layer Security (TLS) Encryption for RADIUS
RFC 6614
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
(Dan Romascanu; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
Shouldn't there be some considerations of key management in line with RFC 4107?
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
Section 2.3 says the following with respect to use of TLS with PKIX certificates:
* Peer validation always includes a check on whether the locally
configured expected DNS name or IP address of the server that
is contacted matches its presented certificate. DNS names and
IP addresses can be contained in the Common Name (CN) or
subjectAltName entries. For verification, only one of these
entries is to be considered. The following precedence
applies: for DNS name validation, subjectAltName:DNS has
precedence over CN; for IP address validation, subjectAltName:
iPAddr has precedence over CN.
It's good to specify the preference order, but you don't provide a precise definition of what it means to match the expected DNS name (IP address is more straightforward). You might find it helpful to cite RFC 6125 here.
Section 4 states:
Ongoing work in the IETF defines multiple alternative transports to
the classic UDP transport model as defined in [RFC2865], namely
RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS
[I-D.ietf-radext-dtls] and this present document on RADIUS over TLS.
Is there a document that summarizes the experiment with these three technologies and that defines criteria for evaluating the success of each approach?
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two editorial
issues. Please consider them.
(1) Section 2.3:
x.y.z
Did you mean to fill in a real section number here?
(2) Note Section 3.4 (1) )
Missing open paren?
(Sean Turner; former steering group member) No Objection
I agree with Stephen's discuss and Peter's comment positions. Based on the email exchanges it looks like their issues will be resolved in -12.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- I don't get why this is going for experimental rather than PS. I'd prefer the latter really. - You should define dynauth as a term or add a reference. - Seems odd to prefer a 3DES ciphersuite over an AES one. An explaination for that would be good. (Maybe its just existing code?) - Section 3, 1st bullet should I think talk about a list of trust points and say that that includes the CA public key and not just its name. - Please fix x.y.z, I doubt there's that section in 5246. - (Blatent self-promotion:-) Might it be useful to think about using draft-farrell-decade-ni as a(nother) way to represent certificate fingerprints? - Why only allow configuration of URIs for subjectAltName? I don't get why you don't include dNSName for example. - What does it mean to say the client is unique identified by the cert fingerprint? What happens when I get my certificate renewed? - I'm not sure why a reader in ten years will care that "Radiator is compliant to version 2 of RadSec..." (compliant to *this* protocol would be fine of course if those are the same but then why not say that?) - "(link to RFC once issued here)" is not really very finished text is is? - The mandatory TLS ciphersuites listed do not provide PFS.
(Stewart Bryant; former steering group member) No Objection
This document needs a scrub to make sure that all TLAs other than those with a * in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt are expanded on first use and where the definition is contained in another document the term is provided with a reference on first use. radsec seems to have a lot of different spellings.
(Wesley Eddy; former steering group member) (was Discuss) No Objection