Subject: [Fwd: New Version Notification for draft-dekok-radext-dtls-02]

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Mar 2010 09:24:03 -0700

Subject: New Version Notification for draft-dekok-radext-dtls-02
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Date: Mon, 22 Mar 2010 08:59:57 -0700 (PDT)

A new version of I-D, draft-dekok-radext-dtls-02.txt has been successfully submitted by Alan DeKok and posted to the IETF repository.

Filename:	 draft-dekok-radext-dtls
Revision:	 02
Title:		 DTLS as a Transport Layer for RADIUS
Creation_date:	 2010-03-22
WG ID:		 Independent Submission
Number_of_pages: 17

Abstract:
The RADIUS protocol [RFC2865] 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 "hidden"
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 IETF Secretariat.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 22 Mar 2010 13:28:28 -0700 (Pacific Daylight Time)

Sec 8.1 -

"The previous RADIUS practice of using shared secrets that are minor
    variations of words is NOT RECOMMENDED, as it would negate nearly all
    of the security of DTLS."

I think any statements WRT secret key strength should to be generalized 
and take into account the properties of the underlying PSK suite as some 
systems may or may not be subject to offline attack.

"Any shared
    secret used for RADIUS MUST NOT be used for DTLS.  Reusing a shared
    secret between RADIUS and DTLS would negate all of the benefits found
    by using DTLS."

I wonder if a more general warning about the possibility of 
down-negotiation would be a better fit.  I can see the same concept 
applying to administrative selection of cipher-suites.

Sec 4.1.1 -

"Where the RADIUS specifications require that a
    RADIUS packet received via the DTLS session is to be "silently
    discarded", the entry in the tracking table corresponding to that
    DTLS session MUST also be deleted, the DTLS session MUST be closed,
    and any TLS session resumption parameters for that session MUST be
    discarded."

Why is this still done when DTLS is used for a transport?  IIRC in the TCP 
mapped drafts this was done to mitigate possibility of loss of protocol 
synchronization - not possible WRT DTLS.

My concern as with the TCP map is silently discarded messages can take 
down other unrelated exchanges.  The inner RADIUS should speak up while 
the transport is being established if there is no intention on honoring 
the established channel.

There is an additional concern in that DTLS closure messages have no 
retransmission timers and are not guaranteed to be delivered.  When this 
occurs future messages will be discarded by the peers DTLS stack until the 
clients "lifetime" timer expires and the DTLS session is reestablished.

Sec 4.2 -

"RDTLS clients SHOULD NOT send both normal RADIUS and RDTLS packets
    from the same source socket."

" and increases the potential for
    security breaches due to implementation issues."

WRT security only it seems to me servers must know better if not 
explicitly forbidden whether this is done or not.  Encouraging (change 
SHOULD NOT to MAY) can only shine light on the issue and force 
implementors to address appropriately.

regards,
Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Mar 2010 14:00:14 -0700

> systems may or may not be subject to offline attack.

  Do you have suggested text?

> applying to administrative selection of cipher-suites.

  Do you have suggested text?

  Also, an *explicit* note that secrets should not be re-used is
required, in my opinion.  This forbids one "obvious" class of
implementations, where there's only one secret for RADIUS && RDTLS.

> Why is this still done when DTLS is used for a transport?  IIRC in the
> TCP mapped drafts this was done to mitigate possibility of loss of
> protocol synchronization - not possible WRT DTLS.

  In DTLS, the crypto layer ensures that packets have not been modified.
 Therefore, the only time that packets are malformed is when the sender
has sent bad data.  When that happens, they should no longer be trusted
to do *anything*.

> the transport is being established if there is no intention on honoring

  A counter point is that systems not implementing RADIUS should not
talk to RADIUS servers.  It's not really appropriate to add negotiation
to RADIUS where implementations indicate whether or not they support RADIUS.

> occurs future messages will be discarded by the peers DTLS stack until
> the clients "lifetime" timer expires and the DTLS session is reestablished.

  Yes.  Too bad.  If someone can't be bothered to implement RADIUS
properly, their software won't work that well.

> implementors to address appropriately.

  Hmm... allowing potentially bad behavior to highlight the fact that
bad behavior needs fixing.  I'm not sure I agree with that.

  Another argument is that allowing this increases the server processing
requirements for *every* packet.  Instead of doing RADIUS / DTLS
detection on the first packet from a new socket, it has to be done for
*every* packet.  This increases the number of cases that have to be
examined for potential RADIUS / DTLS overlap.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 22 Mar 2010 14:25:43 -0700 (Pacific Daylight Time)

> has sent bad data.  When that happens, they should no longer be trusted

I understand DTLS provides encryption and integrity protection.  I don't 
understand why the peer should no longer be trusted?  When this occurs is 
the client trusted to reestablish a DTLS session?  If so why?  Where is 
this trust defined? Administratively?

> properly, their software won't work that well.

There are valid reasons to ignore a request.  See RFC2138 Sec 3. 
"Unrecognized packet codes are silently discarded"  If a server does not 
recognize a packet code sent by its peer does that mean the DTLS session 
needs to be dropped?

If so how does one implement new packet codes in the future or co-exist 
with systems that do not support all currently allocated packet codes?

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Mar 2010 14:40:44 -0700

Peter Deacon wrote:
> understand why the peer should no longer be trusted?

  If the peer manifestly fails to implement RADIUS, then it can no
longer be trusted to implement RADIUS.

>  When this occurs
> is the client trusted to reestablish a DTLS session?  If so why?  Where
> is this trust defined? Administratively?

  So long as the client implements RADIUS, it can be trusted.  Since
more than one implementation may live at a particular IP address, *new*
connections from that IP cannot be forbidden if one misbehaves.

> recognize a packet code sent by its peer does that mean the DTLS session

  Why is the client sending non-RADIUS packets to a RADIUS server?

> with systems that do not support all currently allocated packet codes?

  RADIUS has traditionally had a strong relationship between destination
port and packet codes.  The list of packets allowed to be sent to port
1812 hasn't really changed in 15 years.  When new codes are defined
(e.g. CoA), new ports are defined, too.  RDTLS follows this practice.

  This practice also means that servers *not* implementing a packet code
simply ignore *all* packets sent to a port... including DTLS connection
requests.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 22 Mar 2010 15:03:39 -0700 (Pacific Daylight Time)

> (e.g. CoA), new ports are defined, too.  RDTLS follows this practice.

Well I have already said everything I wanted to.  WRT port allocations 
don't say that too loud the IANA might hear you :-)

regards,
Peter