Subject: [radext] Comments draft-ietf-radext-dtls-02

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 21 Nov 2012 05:10:19 +0000

The document has a few issues that need to be resolved:

1. What is the expected behavior if the request authenticator or message authenticator verification fails?  I believe the behavior is that the RADIUS layer silently ignores the message and the DTLS session is torn down, but I think this should be more explicitly stated. 

2.  The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong.  

- Section 2.2 in the RADIUS/TLS spec does not discuss cipher suites, but section 2.3 does.   
- Section 2.3 does apply to radius, except  
-- bullet 1 I'm not sure if this applies
-- bullet 2 applies except for TLS_RSA_WITH_RC4_128_SHA as already noted
-- bullet 3 applies
-- bullet 4 applies except the secret is different
- section 2.4 applies to RADIUS/DTLS
- section 2.5 probably does not apply;  as noted in draft for section 2.4
- Section 3.3 should reference 3.4

Section 2.2.2 looks like it references the correct sections, but this should be validated.  

3.  Implementation specifics are mixed in with the normative text throughout the document.  There should be a separate informative section in implementation.   THis includes

- Section 3 Discussions of connected UDP sockets
- Section 3 DIscussion of local proxy
- Section 4.1 Discussion of connected sockets
- Section 4.1 and 4.1.1 seems a bit implementation specific, I believe it should discus DTLS session/state Management instead of Table management.  an informative description of the table is fine, but most of the text can be described without reference to a table. 

Here is some text that I think is more implementation neutral:

"  DTLS implementations are subject to Denial of Service (DoS) attacks due
   to the ability of an attacker to forge UDP traffic.  RADIUS/DTLS
   servers SHOULD use the stateless cookie tracking technique described
   in [RFC6347] Section 4.2.1.  the server SHOULD NOT allocate state
   until a ClientHello packet has been received with an
   appropriate Cookie value."

"  DTLS state MUST deleted when a TLS Closure Alert
   ([RFC5246] Section 7.2.1) or a Fatal TLS Error Alert ([RFC5246] Section
   7.2.2) is received."

The following text tries to clarify some ambiguity around the silent discard behavior (I'm not convinced that this is the right behavior, but that is a separate issue). 

   "Where the RADIUS specifications require that a packet
   received via a DTLS session be "silently discarded", such as a failed message authenticator validation, the DTLS session MUST 
   be closed, and any TLS session
   resumption parameters for that session MUST be discarded.  The
   implementation MAY provide the capability of logging the error,
   including the contents of the silently discarded packet, and SHOULD
   record the event in a statistics counter."

" As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
   MUST also maintain a "Last Packet" timestamp per DTLS session.  The
   timestamp SHOULD be updated on reception of a valid DTLS packet.  The
   timestamp MUST NOT be updated in other situations.  When a session
   has not received a packet for a period of time, it is labelled
   "idle".  The server SHOULD delete idle DTLS sessions after an "idle timeout". 
   The server MAY cache the TLS session
   parameters, in order to provide for fast session resumption."

" This session "idle timeout" SHOULD be exposed to the administrator as
   a configurable setting.  It SHOULD NOT be set to less than 60
   seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).
   The minimum value useful value for this timer is determined by the
   application-layer watchdog mechanism defined in the following
   section."

"RADIUS/DTLS servers SHOULD also keep track of the total number of
   DTLS sessions  They SHOULD stop the creating of new
   sessions when a large number are already being tracked.  This
   "maximum sessions" number SHOULD be exposed to administrators as a
   configurable setting."

5.  Section 4.1.3

I'm not convinced that tearing down the DTLS session when there is an upper layer discard is the right thing to do.   For example its possible that a packet is discard because of EAP processing.  In this case the DTLS session would be torn down.  I would be possible for a network access client to cause the DTLS session between the RADIUS client and server to be torn down.  This doesn't seem like a good thing.  

6.  Section 4.2

The discussion of connected sockets is implementation specific. 

Should the client always initiate DTLS if it supports it?  What will a legacy RADIUS server do if it receives a type code of 22? Will the client switch over after a timeout? 

THere also is a DTLS heartbeat that can be used, which could be an alternative.  The DTLS heartbeat can go in the reverse direction as well. 

It might be useful for servers to support RFC 5077 stateless session resumption. 

7 Section 7.1

Should note that TLS-PSK is not resistant to dictionary attacks.

Its not clear to me why you are recommending hashing the output of the CSPRNG.  I think it would be better to recommend that PSKs be at least 16 octets (or 32 if you prefer) generated from a strong random number generator.  Randomness recommendations are provided in BCP106(RFC4086)

---

From: Alan DeKok <[email-masked]>
Date: Sun, 25 Nov 2012 09:35:55 -0500

> 1. What is the expected behavior if the request authenticator or message authenticator verification fails?  I believe the behavior is that the RADIUS layer silently ignores the message and the DTLS…

  That was the intention.  I will clarify that in the document.

> 2.  The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong.  

  I'll go cross-check the document and update the references.

> 3.  Implementation specifics are mixed in with the normative text throughout the document.  There should be a separate informative section in implementation.   THis includes

  I'm of two minds about this.

> - Section 3 Discussions of connected UDP sockets

  That is a bit more implementation, yes.

> - Section 3 DIscussion of local proxy

  That for me is more security related.

> - Section 4.1 and 4.1.1 seems a bit implementation specific, I believe it should discus DTLS session/state Management instead of Table management.  an informative description of the table is fine,…

  The terminology here is less relevant than the requirements.  Whether
it's a table or just "Session management" is basically

> The following text tries to clarify some ambiguity around the silent discard behavior (I'm not convinced that this is the right behavior, but that is a separate issue). 

  Well, I'd appreciate productive discussion on that topic.

  I understand the interest in being graceful under "soft" failures.
(e.g. unknown codes, but well-formed packets).  But for malformed
packets, there is no logical reason to keep speaking RADIUS to a
non-RADIUS client.

  I'll take a look at your text, and try to integrate it into the document.

> I'm not convinced that tearing down the DTLS session when there is an upper layer discard is the right thing to do.   For example its possible that a packet is discard because of EAP processing.  I…

  RADIUS packets are never "silently discarded" by a server due to EAP.
 They RFC3579 says they're silently when there is no Message-Authenticator.

  If this is a sticking point for people, I welcome *specific*
suggestions about what circumstances apply, and what to do in those
circumstances.

  I'm wary of filling this document with "RFC X Section Y says silently
discard, but the DTLS session stays up.  RFC Z Section Q says silently
discard, but the DTLS session should be torn down".

  That makes implementation difficult.

> The discussion of connected sockets is implementation specific. 

  OK.

> Should the client always initiate DTLS if it supports it?  What will a legacy RADIUS server do if it receives a type code of 22? Will the client switch over after a timeout? 

  The document describes a "DTLS Required" flag, which is set by the
administrator.  A legacy server receiving a DTLS packet will silently
discard it independent of the code, as the DTLS packet is not in the
form of a RADIUS packet.

> THere also is a DTLS heartbeat that can be used, which could be an alternative.  The DTLS heartbeat can go in the reverse direction as well. 

  OK.  I'll mention that.

> It might be useful for servers to support RFC 5077 stateless session resumption. 

  OK.

> Should note that TLS-PSK is not resistant to dictionary attacks.

  OK.

> Its not clear to me why you are recommending hashing the output of the CSPRNG.  I think it would be better to recommend that PSKs be at least 16 octets (or 32 if you prefer) generated from a strong…

  Good point.  I'll update the document.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 27 Nov 2012 05:53:30 +0000

>  That for me is more security related.

[Joe] Maybe it would be better in the security considerations.  

> it's a table or just "Session management" is basically

[Joe] The text currently has some normative RFC2119 language that is fairly specific about implementing a table.  I think the section can convey the behavior without the implementation specifics.  If you want help with text let me know and I'll provide more comprehensive text.  

> They RFC3579 says they're silently when there is no Message-Authenticator.

[Joe] OK, but what happens when an EAP method decides to discard a message form the peer/client?  

>  That makes implementation difficult.

[Joe]  My suggestion would be to tear down the session in the following situations (does the client tear down DTLS as well?)
- failure in message authenticator
- failure in response authenticator
- invalid packet length
- invalid attribute length

I'm not sure about these, but I think it would be OK to tear down the session
- invalid code
- invalid identifier

for other cases I'd leave it up to the implementation, but I'm not sure what the other cases may be.  

> discard it independent of the code, as the DTLS packet is not in the

[Joe] Currently, the DTLS required flag refers to the server.  Maybe there should be an equivalent flag for the client? perhaps DTLS require and DTLS optional?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Nov 2012 08:17:37 -0500

Joseph Salowey (jsalowey) wrote:
>>  That for me is more security related
> 

  I'll add a section there.

> [Joe] The text currently has some normative RFC2119 language that is fairly specific about implementing a table.  I think the section can convey the behavior without the implementation specifics.…

  For me, "table" is just a word.  The important thing is that a key
maps to data.  How it's done is less relevant.

  In any case, I've removed the word "table" from the document.  It
makes the text a bit more awkward, but still readable.

> [Joe] OK, but what happens when an EAP method decides to discard a message form the peer/client?  

  Section 2.2 of RFC 3579 is the only situation where that happens.
That's the one case where I agree tearing down the DTLS session is the
wrong thing to do.  I'll update the document.

> - invalid attribute length

  I agree.

  OK.

> for other cases I'd leave it up to the implementation, but I'm not sure what the other cases may be.  

  I've gone over the RFCs.  There don't seem to be too many other cases.

> [Joe] Currently, the DTLS required flag refers to the server.  Maybe there should be an equivalent flag for the client? perhaps DTLS require and DTLS optional? 

  Yes.  I'll add text for the client.

  Alan DeKok.