Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
RFC 7360

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

(Richard Barnes) Yes

Comment (2014-05-15 for -12)
No email
send info
Thanks to the authors for the best and most concise statement of why "use IPsec" is pretty much never the answer for applications: "The requirement that [application] traffic be encrypted and/or authenticated is implicit in the network configuration, and cannot be enforced by the [application]."

(Benoît Claise) Yes

(Stephen Farrell) Yes

Comment (2014-05-15 for -12)
No email
send info
Again, thanks for the good description of the experimental
nature of this and the implementation info.

- Would it not be feasible to require a PFS ciphersuite?
Even that'd be a tricky MUST for current implementations,
it'd be a good RECOMMENDATION. (Since server private key
leakage is probably reasonably likely here over the longer
term in a large deployment.) One option might be to note the
UTA WG and say that its generic recommendations for TLS
ciphersuites ought be tracked by implementers.  A
standards-track version later can probably fix this though,
but good to note that this is a changing part of the (D)TLS
landscape.

- Are you or are you not requiring TLS client auth be
implemented? I think you are but it'd be good to say more
clearly that it MUST be implemented, perhaps esp. for client
proxies.

- If TLS client-auth is used (whether cert based or PSK) and
you have a client-proxy, then I guess the server ought have a
mapping from the TLS client id to the various RADIUS client
identifiers (NAS-Identifier?) that are allowed use that
proxy. Otherwise, the server is depending maybe too much on
the proxy implementation to enforce authorization.

- I'd recommend that (at some point) you think about DANE for
this, it might work well. For now, maybe simply note it as a
possible future option.

- Given Heartbleed, I think you could maybe say some more
about the use of DTLS heartbeat messages, e.g.  to say that
the PMTUD stuff SHOULD be <4096 bytes or something. Would
that be useful? (It might not, if libraries don't provide a
way to control it, but could be worth noting, and heartbleed
probably is worth a note;-)

(Jari Arkko) No Objection

Comment (2014-05-15 for -12)
No email
send info
I have no objection to the approval of the document, but I think several Gen-ART comments have been made that would improve the document if addressed.

I will skip the many ones that were already handled. Thanks for all the work on the reviews and edits, Ben and Alan.

What follows are editorial suggestions that you may take into account if you feel they are useful.

I agree with Alan in that bidding down attacks include the kind of situation that the document is talking about, such as disabling DTLS by a third party.

I would like to add a clarifying sentence to the key generation paragraph to make note of the fact that the generated key must be entered on the other side manually.

Section 10.5 and additional rules for RADIUS/UDP. I agree with the review in the sense that when additional protocol behaviour is mandated then an Updates: -header would be needed in the RFC header. But I read the text mostly as a deployment guideline about situations where you mix RADIUS/UDP and RADIUS/DTLS usage. Although if you want to be even more sure that the reader does not misinterpret this, you could write "As a result, RADIUS/UDP clients can not be located behind a NAT gateway." instead of "As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT gateway."

As I read Section 10.4, the discussion on manual vs. CA-based configuration is pretty clear to me. But I also wondered where text "The above requirements can be met by using a private Certificate Authority (CA)" exactly refers to, to paragraph 5? Not clear if it also applies to server side, for instance. I would probably do this edit if it were my document:

OLD:
The above requirements can be met by using a private Certificate Authority (CA)
NEW:
The requirement for clients to be individually configured with a unique certificate can be met by using a private Certificate Authority (CA)

(Or something else, if your intent was not what I wrote above. But again, these are just suggestions, not requirements from the IESG.)

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2014-05-12 for -12)
No email
send info
I do have some comments. Please consider them along with any other comments you receive.

1.  Introduction

   Another benefit is that RADIUS over DTLS continues to be a User
   Datagram Protocol (UDP) based protocol.  The change from RADIUS/UDP
   is largely only to add TLS support.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this "largely" or "only"? Is this to add TLS support, or DTLS?

   This specification does not, however, solve all of the problems
   associated with RADIUS/UDP.  The DTLS protocol does not add reliable
   or in-order transport to RADIUS.  DTLS also does not support
   fragmentation of application-layer messages, or of the DTLS messages
   themselves.  This specification therefore shares with traditional
   RADIUS the issues of order, reliability, and fragmentation.  These
   issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS
   [RFC6614].

Is the last sentence saying "if in-order reliable delivery of large RADIUS messages matters, you won't get that with RADIUS DTLS"?

1.3.  Document Status

   RADIUS/DTLS allows
   manual distribution of long-term proofs of peer identity as well (by
   using TLS-PSK ciphersuites, or identifying clients by a certificate
   fingerprint), but as a new feature enables use of X.509 certificates
   in a PKIX infrastructure.  

I couldn't parse this sentence. I think the problem is close to "but as", but I'm guessing.

4.  Client Behavior

   Clients may implement "pools" of servers for fail-over or load-
   balancing.  These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS
   servers.

I lack understanding why this is a SHOULD NOT. Is this biddown attack territory? If so, I'm more curious than usual ...

10.  Security Considerations

   For systems which perform protocol-based firewalling and/or
   filtering, it is RECOMMENDED that they be configured to permit only
   DTLS over the RADIUS/DTLS port.  Where deep packet inspection is
   possible, there should be further restrictions to allow only RADIUS
   packets inside of the DTLS session.

Is there an obvious way to know whether deep packet inspection is possible?

10.5.  Network Address Translation

   As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT
                                   ^^^^^^^^^^
I lack understanding how this could be a SHOULD NOT, given that NATs are translating the IP addresses used for security, as the previous paragraphs explain. Why isn't it MUST NOT? The next sentence goes to MUST.

   gateway.  If clients are located behind a NAT gateway, then a secure
   transport such as DTLS MUST be used.  As discussed below, a method
   for uniquely identifying each client MUST be used.

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

Comment (2014-05-13 for -12)
No email
send info
Completely non-blocking comments...

1. I found the information contained in section 1.3 interesting and potentially quite beneficial.  By describing what aspects of the specification need assessment during experimentation, this section not only guides implementers/operators/users but also future IETF participants who would need to determine the spec's viability to move to the standards track.

2. Thanks for section 9.  Knowing who has done some implementation work is quite useful.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-05-13 for -12)
No email
send info
In Section 8, you change the contact person for the port registration to "IETF Chair".  Probably better to use "Network Management Area Director", or something like that.  Not a big deal either way, though.

(Kathleen Moriarty) No Objection

Comment (2014-05-15 for -12)
No email
send info
I support Stephen's comments and would also like to note that security considerations for radius are well detailed here, in RFC6614 and RFC3579.  For other drafts, this makes references tough as the publications are experimental or informational.  If one of these progresses to standard, it would be good to consolidate the relevant threats and considerations into that document.  If not, maybe a document that details the threats and considerations that set the basis for radius over an encrypted protocol would be helpful?  I would hope that would not take too long considering the base materials already exist.

(Martin Stiemerling) No Objection

(Pete Resnick) No Record

Comment (2014-05-14 for -12)
No email
send info
I've not had a chance to give a proper review to this document, so I will not take a formal ballot position (which doesn't have any effect for an Experimental document), but I want to echo Brian's comment and thank you for your well stated experimental description and implementation summary. We don't see enough of these in the IETF, and this will be a great example for future experimental work.