Subject: [Gen-art] Gen-ART LC Review of draft-ietf-radext-dtls-11

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Apr 2014 15:39:50 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-radext-dtls-11
Reviewer: Ben Campbell
Review Date: 2014-04-30
IETF LC End Date: 2014-04-30

Summary: This draft is almost ready for publication as an experimental RFC. There are a few minor issues that should be considered prior to publication.

Note: I as assigned version 10, but 11 came out as I was working on the review. This review is for version 11.

Note: This review is incremental to an early (pre-submission) review I did for versions 7 and 8. Any comments from that review not repeated here have been addressed either in the text or in correspondence.

Major Issues:

None.

Minor Issues:

-- 3.2, last paragraph:

I'm still confused about how this is a bid down attack. 

[The author replied that, when secure and insecure packets are allowed from the same client, a
malicious or broken client can choose the insecure one.  That's bad,
when the intent is to use DTLS.]

While I agree that's bad, I don't see how it qualifies as a bid-down attack. One assumes a malicious client already has access to the cleartext messages. Are we talking about an MiTM "client"? Are there attacks where a third party can induce the client or server to send unprotected packets, even with no signaled negotiation? I can imagine one for the specific case where a node falls back to clear text if DTLS packets fail; an attacker could induce failures for DTLS packets, but that is covered elsewhere.
Comment not addressed.

-- 6, 2nd and 3rd paragraph:

The RECOMMENDation to allow administrative entry of keys and to derive keys from a PRNG seem contradictory.

[The author responded that it's a requirement that implementors allow administrators to enter
strong keys. but I don't get that from the text, which both RECOMMENDS that the interface allow people to enter human readable hex strings, and that keys should be derived from a PRNG instead of letting administrators make up keys. How can it be both?

I don't see how an interface could prevent administrators from entering better keys. Perhaps the intent is to offer or interface with tools for random generation, or to scan entered keys for things with insufficient entropy?]
 
-- 10.3, 2nd paragraph:

This is redundant and inconsistent with previous normative requirements in 5.1.1. 

[Author replied that it's worth reiterating security issues, and that the sections were now consistent. But there's still conflicting normative statements here. 5.1.1 says implementations SHOULD monitor number of sessions. This section says MUST.

And I still assert that, even if the security issue is worth reiterating, it should not be reiterated _normatively_.  Doing so creates confusion about which text is authoritative, especially when they conflict. Even if they don't conflict now, it's easy for future updates to accidentally create conflicts.]

-- 10.4 5th and 6th paragraphs:

Paragraph 5 says credentials should be manually configured, and strongly tied to a host name. It is not clear to me from the text whether using a certificate (perhaps issued by a trusted CA) to bind the credentials to the hostname is permissible. The use of "manual" would seem to disallow that. But paragraph 6 talks about configuring trusted CAs.

[The author commented that dynamic discovery was out of scope--but I don't think anything about this implies dynamic discovery. (e.g. configuring a client to talk to foo.example.com, then using using a CA to validate that a server certificate to ensure that that server really is foo.example.com is not the same as dynamic discovery.]

-- 10.5, last paragraph:

This seems to be making normative statements about RADIUS/UDP. It's not appropriate to make those statements here unless this draft normatively updates RADIUS/UDP. (Which and experimental rfc shouldn't do.)

Nits and Editorial Comments:

-- idnits reports: The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
     does not include the phrase in its RFC 2119 key words list.

-- 6.1, first paragraph: "subsystem does not need to multiple
   multiple sessions on one socket"

I think one instance of "multiple" was intended as a different word?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 30 Apr 2014 21:38:53 -0400

> While I agree that's bad, I don't see how it qualifies as a bid-down attack. One assumes a malicious client already has access to the cleartext messages. Are we talking about an MiTM "client"? Are…

  The point of DTLS isn't just to protect from malicious clients.  It's
to protect clients and servers from malicious third parties.  Those
parties can read all RADIUS/UDP traffic now.  They will not be able to
read RADIUS/DTLS traffic.

  These third parties could actively cause DTLS to fail, and force the
client and server to use an insecure transport.  This sounds like a
downbidding attack to me.

  Do you have another definition for downbidding which you are using?
Or would another term be acceptable here?

> strong keys. but I don't get that from the text, which both RECOMMENDS that the interface allow people to enter human readable hex strings, and that keys should be derived from a PRNG instead of le…

  Because the administrators have to enter the same key on both the
client and server.  If one machine auto-generated a secure pseudo-random
number, it would still have to be transported to the other, and entered
in an administration UI... via the method suggested in the document.

> I don't see how an interface could prevent administrators from entering better keys. Perhaps the intent is to offer or interface with tools for random generation, or to scan entered keys for things…

  Have you ever entered a password in a poorly designed on-line form?
"special characters like !, %, &, $, etc. are not allowed".  Vendors do
this today with RADIUS systems, for the shared secret.  Such idiocy
should be discouraged.

> And I still assert that, even if the security issue is worth reiterating, it should not be reiterated _normatively_.  Doing so creates confusion about which text is authoritative, especially when t…

  I'll address that.

> [The author commented that dynamic discovery was out of scope--but I don't think anything about this implies dynamic discovery. (e.g. configuring a client to talk to foo.example.com, then using usi…

  I'm not sure what the objection here is.

  The point is that when a client connects to a server, the server uses
the source IP to determine which set of credentials to use.  There is no
"binding" of a certificate to a hostname.  The system is configured to
verify that "when you see packets from IP X, they must be using
certificate C".

  This configuration is independent of the certificate contents.

> This seems to be making normative statements about RADIUS/UDP. It's not appropriate to make those statements here unless this draft normatively updates RADIUS/UDP. (Which and experimental rfc shoul…

  The consensus of the WG was that the text belonged.

>      does not include the phrase in its RFC 2119 key words list.

  OK.  I'll fix that.

> I think one instance of "multiple" was intended as a different word?

  "manage multiple sessions on one socket"

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Apr 2014 21:57:07 -0500

Thanks for the quick response. Comments inline, with sections that do not appear to need further content removed.

> Or would another term be acceptable here?

I tend to think of a bid-down attack as one in which security parameters are negotiated, and an attacker removes a more secure security mechanism to force endpoints to fall back to a less secure. But an outright failure of the DTLS handshake is more likely something less subtle--an outright impersonation attack, or a MiTM modification of content.

> in an administration UI... via the method suggested in the document.

I think it's reasonable to say that good administration practices involve random key generation, and that the interface should not prevent the entry of arbitrary hex strings. But the text says things like 

"When creating keys, it is RECOMMENDED that keys be derived from a cryptographically secure pseudo-random number generator (CSPRNG) instead of allowing administrators to invent "secure" keys on theur  [sic--add that as an editorial comment] own."  

That part seems to say explicitly that the implementation shouldn't let admins enter their own keys. (Which makes the bit about entering the key on the peer seem difficult.)

> this today with RADIUS systems, for the shared secret.  Such idiocy

I accept that, and my real concern is not about allowing the admin to enter arbitrary hex strings. My concern is that it also says the admin should not be able to enter their own keys (see above.) How do you expect the interface to prevent the use of "invented on their own" keys, while allowing arbitrary hex strings?

[...]

> verify that "when you see packets from IP X, they must be using

Are you explicitly recommending against doing client authentication in the DTLS handshake? That seems inconsistent with the 3rd paragraph, that says "Any authentication credentials for that client are then determined solely from the client identity, and not from an IP address."

But, my concern was not just about servers authenticating clients. Paragraph 5 says: 

"authentication credentials for that relationship should also be statically configured.  That is, a client connecting to a DTLS server SHOULD be pre-configured with the servers credentials (e.g. PSK or certificate)."

That seems to exclude the possibility of the client being pre-configured with a host name for the server, then the server presents a certificate issued from a trusted CA that includes that host name. This is a common TLS/DTLS use case.  Now, maybe you consider that to still be static configuration of credentials, since the host name and the trust anchor need to be statically configured. But your statement that there is no (as in never?) binding of a certificate to a host name makes me think otherwise. (Or at least confused me.) I assume you expect to do something with trusted CAs, since paragraph 6 talks about their configuration.

>  The consensus of the WG was that the text belonged.

I think we must be talking past each other. I read this to say that you expect people who are implementing/deploying RADIUS/UDP, who may not have seen any reason to read this experimental spec in the first place, to honor normative statements in this draft? 

In general, it does not make sense for a given protocol to make normative statements about implementations that don't implement that protocol. If the working group wants to make this sort of statement, there are avenues to do so. But I don't think an experimental RFC is the right place.

[...]