Transport Layer Security (TLS) Encryption for RADIUS
RFC 6614

[Ballot comment]
  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?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two
  concerns.  Please respond to each of them.

  (1) Section 2.4:
      In TLS-X.509 with PKI infrastructure, a client is uniquely
      identified by the serial number of the tuple (presented client
      certificate;Issuer).
      SHOULD BE:
      In TLS-X.509 with PKI infrastructure, a client is uniquely
      identified by the tuple (serial number of presented client
      certificate;Issuer).

  (2) Because RADIUS supports the Disconnect Request (server-to-client)
      message, it seems that there is some requirement to keep the TLS
      session open for the duration of the access that was authorized.
      Otherwise, the server would not be able to send such a packet to
      the client without initiating its own TLS connection which may not
      be possible or desirable.  Is this aspect of the specification
      inherited from the referenced TCP specification?  It may be
      helpful to add a paragraph about this issue.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
(1)  This may be easy to resolve: Do security issues with TCP which are not mitigated by TLS have any bearing on RADIUS, as they do for BGP, LDP, and some other applications?  E.g. spoofing attacks discussed in RFC 4953.

(2)  Layering terminology should be tightened up in a few places to remove confusion between a RADIUS transport profile and what the underlying transport protocol itself actually is (it is not TLS, and the security in this document is not implemented in the transport layer, although it is in the transport profile).  I believe it's clearest to say that this document "RADIUS/TLS" is a transport *profile* for RADIUS using TLS over TCP as the transport *protocol*.  But it's definitely not correct to say that it's using security in the transport layer, as currently done in a few places:
- abstract
- introduction, paragraph 2
- section 6, paragraph 3
- appendix c, paragraph 2

[Ballot comment]
- 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.

[Ballot discuss]
I've a few niggly but worth-fixing points here that should
be easily addressed. A bunch of these overlap with the
two reviews posted to the secdir list [1,2] so please resolve
these comments along with those reviews.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03073.html
  [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03074.html

(1) You don't say what's the input to certificate fingerprint
calculation. I think you want the DER encoded cert octets here,
and not e.g. the subjectPublicKey, right?

(2) You don't say what "acceptable certificate" means. It could
mean "only accept these [EE's|CAs] no matter what the 5280
verification says" or (as I suspect) "always accept these EE's
regardless of what the 5280 validation says" or something else.
I'm (almost certainly) fine with it meaning whatever you
currently want but it needs to be stated.

(3) I think that saying you MUST do verification as per 5280 and
at the same time saying that you SHOULD allow configuration of
acceptable certificates (with the 2nd meaning above) is in
conflict. I'd say the way to resolve that would be to say "SHOULD
do 5280, except if the EE is on your acceptable list" and I'd be
fine with doing that.

(4) As with (2) you need to define what "acceptable
subjectAltName:URI" is for.

(5) I suspect you may be wrong in saying that "radsec" MUST be
used for attribute encryption and MD5 since that means that if
you only turn on TLS and don't modify your RADIUS code then you
won't comply. It also means that if you have to turn off TLS for
some reason for a while (e.g. one end's cert expired, forgot to
have a new one ready beforehand, as happens quite commonly) then
you probably have your trousers even further down than with
current RADIUS if you start operating over UDP again temporarily
and the value "radsec" is configured for RADIUS.  (I just want to
draw attention to this - I'll clear once I've seen a substantive
response to this point, for pretty much all possible substantive
resposes:-)

(6) You don't say if TLS re-negotiation is REQUIRED to be
supported or not. I think it'd be good to say and maybe to
RECOMMEND something for what to do if a long-lived RADIUS/TLS
session outliving a CRL re-issue or public key cert or maybe even
the appropriate amount of data to encrypt with a given
ciphersuite. I don't really mind which way you'd rather handle
that, but I think saying something is needed so surprises don't
happen. In fact, if you want to note the issue and not RECOMMEND
anything that'd be ok too.

IANA has a question about this document.

IANA recognizes that previously, TCP port 2083 was already assigned by IANA for RadSec, an early implementation of RADIUS/TLS. We note that one of the authors is the assignee and contact for that port number. Our question is: do the authors want to make any changes to the registration of port 2083 upon approval of this document (description, assignee, contact, reference)?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TLS encryption for RADIUS) to Experimental RFC


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'TLS encryption for RADIUS'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies security on the transport layer (TLS) for the
  RADIUS protocol when transmitted over TCP.  This enables dynamic
  trust relationships between RADIUS servers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/


No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?
       
    Jouni Korhonen is the Document Shepherd. He has reviewed
    draft-ietf-radext-radsec-10 and believes the document is ready for
    the IESG and publication.
       
  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?
       
    The document has been reviewed by the IETF RADIUS experts community.
    The shepherd has no concerns about the document content nor reviews
    it has received.
       
  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

    No concerns. However both tsv-dir and sec-dir reviews have been
    requested in order to receive comments from security and transport
    experts.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.
       
    No concerns.
       
  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 
       
    The document has a solid WG consensus behind it.
       
  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

    No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

    The ID nits tool reports one comment, which is a result of an
    intentional reference to the obsoleted RFC4346.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

    The document has references split into normative and informative.
    There are no normative references that have an unclear state.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

    The document has no IANA considerations.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
       
    Yes.
       
  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

        This document (draft-ietf-radext-radsec-10) specifies TLS
        use for RADIUS when messages are transmitted over TCP.
        The document specifies the required connection/message
        handling procedures, TLS profile and certificate
        considerations for ensuring interoperable implementations.

    Working Group Summary

        No specific issues during the WG process that would need
        specific noting.

    Document Quality

        The document quality is good and there are several known
        implementations from different vendors, and more
        implementations are expected. Furthermore, there is at
        least one operational world-wide roaming environment with
        multiple involved parties already using the protocol
        specified by this document.