Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
draft-ietf-radext-dtls-13

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

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

[Ballot comment]

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;-)

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

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

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

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

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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-radext-dtls-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the IANA Action requested in this document.

IANA understands that this document is requesting a change to the Service Name and Transport Protocol Port Number Registry. The change is for the entry corresponding to port service name "radsec", port number "2083".

In particular, IANA understands that for the transport protocol "UDP" the entry is to be updated as follows:

o Assignee: change "Mike McCauley" to "IESG".
o Contact: change ""Mike McCauley" to "IETF Chair"
o Reference: Add this document as a reference
o Assignment Notes: add the text "The UDP port 2083 was already previously assigned by IANA for "RadSec", an early implementation

IANA Question -> Is there a confirmation or acknoledgement from the current assignee and Contact that this modification is acceptable?

IANA understands that this is the only action required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DTLS as a Transport Layer for RADIUS) to Experimental RFC


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'DTLS as a Transport Layer for RADIUS'
  as 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 2014-04-30. 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


  The RADIUS protocol defined in RFC 2865 has limited support for
  authentication and encryption of RADIUS packets.  The protocol
  transports data in the clear, although some parts of the packets can
  have obfuscated content.  Packets may be replayed verbatim by an
  attacker, and client-server authentication is based on fixed shared
  secrets.  This document specifies how the Datagram Transport Layer
  Security (DTLS) protocol may be used as a fix for these problems.  It
  also describes how implementations of this proposal can co-exist with
  current RADIUS systems.




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

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


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Experimental, which is stated in the document header. For a new
  security solution for RADIUS an experimental protocol is the right
  categorization.

(2) 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 specifies how the DTLS protocol may be used as a fix
  for security issues RADIUS has, namely authentication and encryption of
  RADIUS packets.  The document also describes how implementations
  of the solution proposal can co-exist with current RADIUS systems.

Working Group Summary

  The solution is a result of a long process in the WG. One of the last
  sticking issue was multiplexing of DTLS and RADIUS over port 1812.
  WG decided against multiplexing and the DTLS can only be used on
  existing RADSEC port. The WG has reached a consensus on the
  entire documented protocol.

Document Quality

  There are two known implementations and one planned (if not
  done already).

  There is no need for MIB or other experts review.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Benoit Claise (bclaise@cisco.com) is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has reviewed the document during its writing
  and the final -09 version. The shepherd thinks the document quality
  is adequate for publication.  Specifically the shepherd acknowledge
  the good amount of implementations and operational guidance written
  into the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  None. The document has received actually more that usually reviews
  also from people not typically active in the WG.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document has received early reviews (through the dir-coor)
  from Sec-Dir, Ops-Dir and Gen-Art. Comments from both reviews have
  been addressed.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

  None.

  A minor note. The document uses RFC2119 language but the RFC2119
  reference is placed into information references. The shepherd thinks this
  is fine, since the document itself is on an experimental track.
 
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Author has confirmed he is not aware of an IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None.

(9) 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 reached solid agreement of the active part of
  RADEXT WG. Since the document has been around for a long time
  and been also implemented, we can conclude WG and external
  implementers agree with the document.

(10) 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 publicly available.)

  None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits complain about RFC2119  'NOT RECOMMENDED' keyword.
  That keyword is documented in RFC2119 but not part of the automatically
  provided XML2RFC conversion text on RFC2119 keywords.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) 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 plan for their completion?

  Yes.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  None.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  None.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No new IANA registries or code points are needed. However, this
  document uses the existing RFC6614 RADSEC port number for DTLS
  purposes.

  Assignment Notes: add the text "The UDP port 2083 was already
  previously assigned by IANA for "RadSec", an early implementation
  of RADIUS/TLS, prior to issuance of this RFC."

  The shepherd (and the WG) thinks this is a valid action since RADSEC
  only uses and needs the "TCP port 2083". DTLS can use the "UDP
  port 2083".

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  IDnits passed. There are no XML, BNF or MIB definitions.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Experimental, which is stated in the document header. For a new
  security solution for RADIUS an experimental protocol is the right
  categorization.

(2) 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 specifies how the DTLS protocol may be used as a fix
  security issues RADIUS has, namely authentication and encryption of
  RADIUS packets.  The document also describes how implementations
  of the solution proposal can co-exist with current RADIUS systems.

Working Group Summary

  The solution is a result of a long process in the WG. One of the last
  sticking issue was multiplexing of DTLS and RADIUS over port 1812.
  WG decided against multiplexing and the DTLS can only be used on
  existing RADSEC port. The WG has reached a consensus on the
  entire documented protocol.

Document Quality

  There are two known implementations and one planned (if not
  done already).

  There is no need for MIB or other experts review.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Benoit Claise (bclaise@cisco.com) is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has reviewed the document during its writing
  and the final -09 version. The shepherd thinks the document quality
  is adequate for publication.  Specifically the shepherd acknowledge
  the good amount of implementations and operational guidance written
  into the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  None. The document has received actually more that usually reviews
  also from people not typically active in the WG.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document has received early reviews (through the dir-coor)
  from Sec-Dir, Ops-Dir and Gen-Art. Comments from both reviews have
  been addressed.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

  None.

  A minor note. The document uses RFC2119 language but the RFC2119
  reference is placed into information references. The shepherd thinks this
  is fine, since the document itself is on an experimental track.
 
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Author has confirmed he is not aware of an IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None.

(9) 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 reached solid agreement of the active part of
  RADEXT WG. Since the document has been around for a long time
  and been also implemented, we can conclude WG and external
  implementers agree with the document.

(10) 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 publicly available.)

  None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits complain about RFC2119  'NOT RECOMMENDED' keyword.
  That keyword is documented in RFC2119 but not part of the automatically
  provided XML2RFC conversion text on RFC2119 keywords.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) 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 plan for their completion?

  Yes.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  None.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  None.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No new IANA registries or code points are needed. However, this
  document uses the existing RFC6614 RADSEC port number for DTLS
  purposes.

  Assignment Notes: add the text "The UDP port 2083 was already
  previously assigned by IANA for "RadSec", an early implementation
  of RADIUS/TLS, prior to issuance of this RFC."

  The shepherd (and the WG) thinks this is a valid action since RADSEC
  only uses and needs the "TCP port 2083". DTLS can use the "UDP
  port 2083".

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  IDnits passed. There are no XML, BNF or MIB definitions.

WGLC#3 starts 4-Aug-2013 and will end on 18-Aug-2013. The WGLC will last for two weeks since we also solicit reviews from other directorates like security and opsdir.

We can conclude that alternative #1 got most rough consensus to it.
So this is where the I-D will head to. And we already had consensus
earlier that we will use the existing RADSEC port for DTLS.

For #1: Stig, Bernard, Jim, Peter, Diego, (and joe)
For #2: None
Other concerns: none

Original mail: http://www.ietf.org/mail-archive/web/radext/current/msg08538.html

--> going back to WG document.

On Jun 18, 2013, at 12:25 PM, Jouni Korhonen  wrote:


We still have a sticking issue with the DTLS document on protocol
multiplexing raised by Joe, see:
http://www.ietf.org/mail-archive/web/radext/current/msg08459.html

So, in order to progress things and get the (rough) WG consensus
what to include in the document, We ask the WG to pick up their
favourite approach from the two choices below. This poll ends on
Tuesday 25th June EOB (EEST).

1) Forbid the protocol multiplexing i.e.,
require RADIUS over port 1812.

2) Allow protocol multiplexing i.e.,
Allow RADIUS or DTLS over port 1812.

In both cases, DTLS would be allowed on the DTLS-only TBD port.
The DTLS document will then be changed accordingly to reflect
the WG consensus.

Original Mail: http://www.ietf.org/mail-archive/web/radext/current/msg08521.html

Folks,

This email starts a quick one week WGLC #2 for draft-ietf-radext-dtls-04;
"DTLS as a Transport Layer for RADIUS". The WGLC ends on Tuesday, 9th April.

Post your comments to the list and enter them also into Issue Tracker.


- Jouni & Mauricio