Subject: [radext] WGLC #2 for draft-ietf-radext-dtls-04

From: Jouni <[email-masked]>
Date: Tue, 2 Apr 2013 23:38:12 +0300

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

---

From: Peter Deacon <[email-masked]>
Date: Tue, 2 Apr 2013 18:14:38 -0700 (Pacific Daylight Time)

On Tue, 2 Apr 2013, Jouni wrote:

> 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.

2.1 says min and max packet length MUST be unchanged when using 
RADIUS/DTLS.

Section 2.1 continues:

"We note that the DTLS encapsulation of RADIUS means that RADIUS
    packets have an additional overhead due to DTLS.  Implementations
    MUST support DTLS packets totalling 4096 octets in length, with a
    corrsponding decrease in the maximum size of the encapsulated
    packets.  Implementations SHOULD support encapsulated RADIUS packets
    of 4096 in length, with a corresponding increase in the maximum size
    of the encapsulated DTLS packets."

s/corrsponding/corresponding/
s/totalling/totaling/

It is confusing to say decrease is allowed while also previously saying 
min/max packet lengths MUST be unchanged.  Would expect there be no 
difference in min/max size of RADIUS payload within DTLS period.

2.2.2 "We re-iterate that much of [RFC6614] applies to this document.
    Specifically, Section 4 and Section 6 of that document are applicable
    in their entirety to RADIUS/DTLS."

RFC 6614 section 6 dedicates a few sentences to TCP specific properties 
which do not apply to RADIUS/DTLS.

4. "Adding these
    parameters means that the client MUST start using DTLS to the server
    for all new requests.  The client MUST, however, accept RADIUS/UDP
    responses to any outstanding requests."

MUST does not seem appropriate.  We have no business in what client elect 
to do with outstanding requests after a security configuration change.

5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate
    detection cache.  The connection tracking described below can be seen
    as an extension of that cache, where entries contain DTLS sessions
    instead of RADIUS/UDP packets."

I think bringing this up is likely to cause more confusion than necessary. 
Tuples and authenticator usage are different, session lifecycle is 
different and state logic is different (You would not ignore anything 
while a response is pending)

I think it might be helpful to note RFC5080 in the context of continuing 
to support this mechanism and to continue to do it at the RADIUS packet 
layer rather than DTLS or you're likely to end up on the wrong side of the 
DTLS sequence window.

5.1 "Last Packet
      A variable containing a timestamp which indicates when the last
      valid packet was received for this connection.  Packets which are
      "silently discarded" MUST NOT update this variable."

As long as the packet was valid while being silently discarded it should 
count for the purpose of last packet.

5.1.1 - I still think we can do better on the UDP / DTLS disambiguation 
using the 4 byte header I described earlier or by explicitly requiring a 
server knob to declare what protocol would be accepted from a given source 
address.

    "Sessions (both key and entry) MUST deleted when a TLS Closure Alert
    ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section
    7.2.2) is received.  When a session is deleted due to failed
    security, the DTLS session MUST be closed, and any TLS session
    resumption parameters for that session MUST be discarded, and all
    tracking information MUST be deleted."

Not all TLS Error Alerts are fatal.  Recommend "or a fatal TLS Error 
Alert"

    "Sessions MUST also be deleted when a RADIUS packet fails validation
    due to a packet being malformed, or when it has an invalid Message-
    Authenticator, or invalid Request Authenticator.  There are other
    cases when the specifications require that a packet received via a
    DTLS session be "silently discarded".  In those cases,
    implementations MAY delete the underlying session as described above.
    There are few reasons to communicate with a NAS which is not
    implementing RADIUS.

    The above paragraph can be rephrased more generically.  A session
    MUST be deleted when non-RADIUS traffic is received over it.  This
    specification is for RADIUS, and there is no reason to allow non-
    RADIUS traffic over a RADIUS/DTLS connection.  A session MUST be
    deleted when RADIUS traffic fails to pass security checks.  There is
    no reason to permit insecure networks.  A session SHOULD NOT be
    deleted when a well-formed, but "unexpected" RADIUS packet is
    received over it.  Future specifications may extend RADIUS/DTLS, and
    we do not want to forbid those specifications."

This is redundant.

    "Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
    DTLS Heartbeats [RFC6520] to determine connectivity between the two
    servers."

s/server(s)/peer(s)/ ?

   "A server may also use watchdog packets from the client to
    determine that the connection is still active."

    "The
    timestamp SHOULD be updated on reception of a valid RADIUS/DTLS
    packet.  The timestamp MUST NOT be updated in other situations."

The RADIUS packet layer does not see heartbeats. Should this cause a 
change in Last Packet?  Do you intent for sessions to idle out and expire 
even with active DTLS layer keepalives?

    "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."

The recommended maximum idle timeout is too low in my view.  Resetting 
connections should be as rare as possible as clients now have the added 
burden of correctly guessing whether packets were dropped on wire or 
dropped on DTLS stack in addition to possibility server may not be alive.

There are no timing guidelines provided for transition to "idle" state.

Mismatch of idle expectations between client and server could trigger 
unnecessary delay which could be mitigated by separating client and server 
expectations so there is no overlap in the recommended settings. Clients 
severely outnumber servers.

5.1.3

    "For RADIUS/DTLS, any RADIUS packets which are subsequently silently
    discarded MUST result in the removal of the associated entry and key."

5.1.1

    "There are other
    cases when the specifications require that a packet received via a
    DTLS session be "silently discarded".  In those cases,
    implementations MAY delete the underlying session as described above."

These statements appear to conflict with MUST vs MAY language.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 03 Apr 2013 10:00:36 -0400

> 2.1 says min and max packet length MUST be unchanged when using
...
> s/corrsponding/corresponding/

  Fixed.

> difference in min/max size of RADIUS payload within DTLS period.

  It's a trade-off with implementations.  The specs say max 4K RADIUS
packets.  However, implementations may interpret this as max 4K buffer
for UDP application data.  In which case the DTLS overhead requires that
the encapsulated RADIUS packet is smaller.

  Any choice here isn't perfect.  Do you have suggestions for better text?

> which do not apply to RADIUS/DTLS.

  Do you have suggested text for the draft?

> MUST does not seem appropriate.  We have no business in what client
> elect to do with outstanding requests after a security configuration
> change.

  Yes, we do.  We're writing the standards here, which means we must
address security, migration, implementation cost, etc.

  In this case, there are no known issues with a client accepting
responses to packets it previously sent.  The goal here is to ensure a
safe and productive transition between RADIUS/UDP and RADIUS/DTLS.

> I think bringing this up is likely to cause more confusion than
> necessary. Tuples and authenticator usage are different, session
> lifecycle is different and state logic is different (You would not
> ignore anything while a response is pending)

  Do you have suggested text for the draft?

> layer rather than DTLS or you're likely to end up on the wrong side of
> the DTLS sequence window.

  I'm not sure what that means.

> count for the purpose of last packet.

  Why?  What benefit does that offer?

> server knob to declare what protocol would be accepted from a given
> source address.

  The draft already defines a "DTLS Required" flag.  Servers use it to
decide which protocol is accepted from a given client.

> Not all TLS Error Alerts are fatal.  Recommend "or a fatal TLS Error Alert"

  OK.

>    we do not want to forbid those specifications."

  As is noted in the text.

>    DTLS Heartbeats [RFC6520] to determine connectivity between the two

  Maybe "systems".

> change in Last Packet?

  No.  That is for RADIUS packets, not DTLS heartbeats.

>  Do you intent for sessions to idle out and
> expire even with active DTLS layer keepalives?

  Yes.  If there's no RADIUS traffic for a long time, there are few
reasons to keep the session up.

> dropped on DTLS stack in addition to possibility server may not be alive.

  Did you read the text about RADIUS watchdog packets and DTLS
heartbeats?  No "guessing" is required.

> There are no timing guidelines provided for transition to "idle" state.

  Do you have suggested text for the draft?

> unnecessary delay which could be mitigated by separating client and
> server expectations so there is no overlap in the recommended settings.
> Clients severely outnumber servers.

  Do you have suggested text for the draft?

> These statements appear to conflict with MUST vs MAY language.

  I'll delete the text in 5.1.3.  It's redundant.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Apr 2013 10:45:25 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   It's a trade-off with implementations.  The specs say max 4K
    Alan> RADIUS packets.  However, implementations may interpret this
    Alan> as max 4K buffer for UDP application data.  In which case the
    Alan> DTLS overhead requires that the encapsulated RADIUS packet is
    Alan> smaller.

My preference is that the spec forbid receivers from making this choice.
That is, I'd prefer that receivers MUST support a 4k RADIUS payload and
thus MUST support the necessary room for the DTLS overhead.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 08:59:00 -0400

> thus MUST support the necessary room for the DTLS overhead.

  That's reasonable.  Unless there are objections, I'll update the draft
accordingly.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 10:08:43 -0700

Sam,

While I understand your preference, it does mean that there cannot be a max
4K buffer in a server that supports both DTLS and non-DTLS clients in the
UDP processing code.   The UDP processing code does not know if this is a
DTLS or a non-DTLS message and thus you can end up in a situation where a
>4K buffer is received in the UDP processing code and passed directly to the
non-DTLS processing and have a potential buffer overflow.  Using a maximum
buffer size on the wire does prevent that problem.

On the other hand, I think you might be correct that requiring a 4K buffer
on the data is correct behavior since if you go from a non-DTLS link to a
DTLS link then you go from a 4K data buffer to a less than 4K data buffer
size then leading to delivery problems.

On the whole I do support this but it could be an implementation issue.
Alan do you think this is a major implementation problem?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, April 03, 2013 7:45 AM
> To: Alan DeKok
> Cc: [email-masked]; Peter Deacon; [email-masked]
> Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04
> 
thus
> MUST support the necessary room for the DTLS overhead.
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 13:44:17 -0400

> size then leading to delivery problems.

  Yes.  Any choice is non-optimal.

> Alan do you think this is a major implementation problem?

  It's annoying, but no.  It's pretty easy to change buffer sizes.  If
it's not, you're probably not going to implement any parts of DTLS.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 4 Apr 2013 11:20:00 -0700 (Pacific Daylight Time)

On Thu, 4 Apr 2013, Jim Schaad wrote:

> While I understand your preference, it does mean that there cannot be a 
> max 4K buffer in a server that supports both DTLS and non-DTLS clients 
> in the UDP processing code.  The UDP processing code does not know if 
> this is a DTLS or a non-DTLS message and thus you can end up in a 
> situation where a 4K buffer is received in the UDP processing code and 
> passed directly to the non-DTLS processing and have a potential buffer 
> overflow.  Using a maximum buffer size on the wire does prevent that 
> problem.

Currently you still need to cross check UDP message length with RADIUS 
packet length fields and apply maximum limits before processing anything. 
Not sure how this would be a problem unless an implementation was already 
insecure.

Nothing prevents use of compression within DTLS to create an inner RADIUS 
packet exceeding 4k so these checks are still necessary regardless of where 
they are handed off.

I don't see anything inherently more dangerous in the design of protocol 
with inner packet limits maintained.  I don't see new validation 
requirements that didn't already exist before.

regards,
Peter

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 14:28:11 -0700

Alan,

I am having a problem with the following new text

The client MUST, however, accept RADIUS/UDP
   responses to any outstanding requests.

Under what circumstances do you believe that it would be a good idea to
accept a RADIUS/UDP response to a RADIUS/DTLS request?  This text appears to
imply that there is one but I have a hard time understanding this as
anything but a security problem.

s/practive/practice/

jim

> Of Jouni
> Sent: Tuesday, April 02, 2013 1:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [radext] WGLC #2 for draft-ietf-radext-dtls-04
> 
> Folks,
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 17:49:27 -0400

Jim Schaad wrote:
> accept a RADIUS/UDP response to a RADIUS/DTLS request?

  Never.  The idea was to allow transition from UDP to DTLS.  There will
be outstanding UDP packets, and the client should accept responses to
those packets.

> s/practive/practice/

  Fixed, thanks.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 17:30:52 -0700

> From: Alan DeKok [mailto:[email-masked]]
> Sent: Thursday, April 04, 2013 2:49 PM
> To: Jim Schaad; [email-masked]
> > Under what circumstances do you believe that it would be a good idea
> > to accept a RADIUS/UDP response to a RADIUS/DTLS request?
> 
be
> outstanding UDP packets, and the client should accept responses to those
> packets.

What are you trying to say with this sentence, because I don't understand
it.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Apr 2013 20:35:45 -0400

Consider what happens when you enable support for DTLS between client a
and server b  while both are running and exchanging packets.
Alan wants to permit  packets sent with UDP to be answered  with UDP.

This situation seems to only come up in live upgrades.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 21:51:24 -0400

> What are you trying to say with this sentence, because I don't understand

  What Sam said.  Configuring DTLS on a running RADIUS client.

a) Send Access-Request 1
b) admin configures DTLS
c) Send DTLS encapsulated Access-Request 2
d) Receive Access-Accept 1  ---> do ?????

  I think it should accept the Access-Request 1 from step (d).  After
all, it's a signed response to an Access-Request sent by the client.  It
would be bad to ignore the Access-Request because "DTLS is now configured".

  i.e. When DTLS is configured, it means that *new* Access-Requests
should use DTLS.

  It doesn't mean that all traffic is required to be DTLS.  That will
happen over time as RADIUS/UDP traffic gets responses, or is timed out.

  Suggestions for clear text in the document are welcomed.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Apr 2013 04:38:55 +0000

As I mentioned in the Orlando meeting I am becoming less convinced that multiplexing RADIUS over UDP and RADIUS over DTLS is the appropriate path to take.   It would be better to use multiplexing at the UDP level port instead.   Using UDP ports allows existing network devices to differentiate between encrypted and unencrypted RADIUS and enforce a security policy that allows only encrypted traffic.   Using the same port also increases the probability that there will be more implementation errors that impact the system security.   The overloading of command code 22 is somewhat of a kludge, it is possible that TLS could introduce new message codes that could make new enhancements to TLS incompatible with this specification.    The only argument that I have heard for running insecure and secure on the same port is that you will not have to modify firewall rules, however If you are already using a firewall to filter RADIUS traffic you will want to differentiate between insecure and secure RADIUS.    

Joe

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Apr 2013 00:24:28 -0700 (Pacific Daylight Time)

>  Do you have suggested text for the draft?

Recommend removing "in their entirety"

> address security, migration, implementation cost, etc.

What security, migration or implementation concern does this "MUST" 
address?

I can think of a couple drawbacks..

If an operator is deciding they want to improve the security of their 
system they would be *required* to accept responses with lower security 
after they have declared otherwise.

Increased client implementation complexity as a short term security 
exception has to be made for receiving non DTLS packets including protocol 
disambiguation procedure for clients not specified in draft.

> safe and productive transition between RADIUS/UDP and RADIUS/DTLS.

I am looking for specific technical justifications.  What safety or 
productivity implications does the MUST requirement provide?  If it did 
not exist how would safety or productivity be negatively impacted?

>  Do you have suggested text for the draft?

I would suggest as properties of the state tracking are discussed in 
detail in section 5 removing RFC 5080 paragraph.

>  I'm not sure what that means.

Normally with RFC 5080 replay system an implementation will store a 
response for a given request and simply resend a stored response (UDP 
message) on wire.

With DTLS implementations RADIUS packets must be resent thru new DTLS 
messages rather than storing a previous DTLS response and resending.

The reason for this is DTLS replay protection uses a sequence window where 
only a fixed number of previously unaccepted packets are accepted.  Retry 
timers on orders of seconds on a busy client are likely lead to 
retransmitted messages being too stale to be accepted on DTLS stack unless 
retransmissions are performed by retransmitting stored RADIUS response 
thru DTLS.

Suggest a short text:

Any duplicate detection strategy such as [RFC5080] section 2.2.2 where 
previously transmitted RADIUS packets are replayed MUST be replayed thru 
DTLS creating a new DTLS packet before transmission.  Previously 
transmitted DTLS packets MUST NOT be retransmitted.

>  Why?  What benefit does that offer?

My concern is in minimizing situations where client accounting of idle 
timeout becomes unsynchronized with server view of same.

> decide which protocol is accepted from a given client.

My suggestion the mechanism to automatically migrate clients to DTLS after 
successful DTLS handshake is not necessary.

We already need manual knobs to make this work.  Perhaps simply requiring 
a knob in client and server is the best approach. This would remove 
RADIUS/UDP to RADIUS/DTLS migration and RADIUS/DTLS disambiguation. 
Explicit configuration in client AND server would be necessary to 
successfully speak RADIUS/DTLS.

> reasons to keep the session up.

We see lots of NASes with only a few if any concurrent users.  It is not 
uncommon for new RADIUS traffic to be seen on orders of tens of minutes to 
hours.  Having a connection open hurts nobody and prevents delay including 
possibly additional delay to failover for users coming online.  It also 
prevents state sync problems..(see my comments below)

> heartbeats?  No "guessing" is required.

Heartbeats do not effect last packet and watchdog is for detection of 
server failure rather than communication of compatible session timeout 
parameters.

The following example explains my concern:

RADIUS/DTLS server - 60 second idle timeout.
RADIUS/DTLS client - 90 second idle timeout.

(5.2 "RADIUS/DTLS clients SHOULD pro-actively close sessions when they have been idle for a period of time")

For the sake of this example RADIUS client is connected to a NAS that 
sees only a few concurrent sessions and only sparse activity every few 
minutes...From our experience typical AP in a low traffic environment.

At 75 seconds the client sends a RADIUS request to RADIUS/DTLS server. 
Server promptly ignores this request because the session was torn down due 
to exceeding idle timeout.  The client runs thru all of its retries and 
timeouts IGNORED by the server before it either picks a different RADIUS 
server or tries to open a new RADIUS/DTLS session to the same server.

None of the active probing mechanisms work at these timescales and they 
should not be necessary to prevent this sort of problem from occurring.

TCP TLS provides reliable notification of shutdown DTLS does not.

I recommend that recommended client idle parameters be specified and not 
overlap with recommended server idle parameters.

For example something like clients may close the connection at 60-600 
seconds.  Servers may close the connection after >600 seconds.

Other thoughts to minimize this problem have client enforce an idle 
timeout algorithm based on usage but allow server idle timer to be 
refreshed by DTLS heartbeats.

The server can take other actions if there is pressure on resources to 
manage DTLS sessions but normally it is important to do EVERYTHING 
possible to make sure RADIUS/DTLS is as reliable as RADIUS/UDP with no 
delays for clients to figure out and react to rug being pulled out from 
under them.

>  Do you have suggested text for the draft?

What does the idle state actually do?  What is the difference vs using 
"idle timeout" since last packet without an "idle" transition?

>  Do you have suggested text for the draft?

5.2...

RADIUS/DTLS clients MAY proactively close sessions when they have been 
idle for 60-86400 seconds if DTLS heartbeats or active watchdog probes are 
used.  When unused RADIUS/DTLS client SHOULD close sessions idle for 60 to 
no longer than 600 seconds.

5.1.1...

This session "idle timeout" SHOULD be exposed to the administrator as a 
configurable setting. RADIUS servers SHOULD timeout after at least 600 
seconds.

    As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
    MUST also maintain a "Last Packet" timestamp per DTLS session.  The
    timestamp MUST be updated on reception of a valid RADIUS/DTLS
    packet or DTLS heartbeat.  The timestamp MUST NOT be updated in other
    situations. The server SHOULD delete idle DTLS sessions after
    an "idle timeout".

10.2

While total number of sessions tracked exceeds the configured limit 
servers SHOULD close idle sessions starting with highest idle time until a 
sufficient number of sessions have been closed or lower idle timeout 
threshold of 60 seconds or more has been reached.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Fri, 05 Apr 2013 08:33:15 -0400

I'm confused about the transition issue.
It seems like the draft  is spending a lot of complexity on what's a
very corner case.

As I understand it, the only case where you have to accept both normal
UDP and DTLS responses is the case where you  transition with
outstanding requests.

We're talking about a period of less than a few seconds, right, while
requests are in flight?
So, this issue only comes up in operational environments where a single
NAS or proxy cannot afford  an outage of the maximum lifetime of a
RADIUS request.

Am I missing something?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Apr 2013 08:57:41 -0400

> UDP and DTLS responses is the case where you  transition with

  Yes.

  When a server has a client marked as "DTLS required", it only accepts
DTLS.

> Am I missing something?

  No.

  I'll see if I can come up with some clarifying language.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Apr 2013 09:23:19 -0400

> NAS or proxy cannot afford  an outage of the maximum lifetime of a

  How about this text below.  It clarifies that the transition path is
meant to be temporary.  The text around transition is there only to
ensure we get it right.

3. Transition Path

Transitioning to DTLS is a process which needs to be done carefully.
A poorly handled transition is complex for administrators, and
potentially subject to security downgrade attacks.  It is not
sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS.  That
approach would result in timeouts, lost traffic, and network
instabilities.

The end result of this specification is that nearly all RADIUS/UDP
implementations should transition to using RADIUS/DTLS.  In some
cases, RADIUS/UDP may remain where IPSec is used as a transport, or
where implementation and/or business reasons preclude a change.
However, long-term use of RADIUS/UDP is NOT RECOMMENDED.

This section describes how clients and servers should transition to
DTLS.  There is a fair amount of discussion around this transition, as
it is critical to get it correct.  We expect that once implementations
have transitioned to RADIUS/DTLS, the text in this section will no
longer be relevant.

3.1 Server Transition to DTLS

As this specification permits server implementations to accept both
RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a
method to disambiguate packets between the two protocols.  This method
is applicable only to RADIUS/DTLS servers.

The disambiguation method leverages the RADIUS/UDP requirement that
clients be known by source IP address.  RADIUS/DTLS servers MUST treat
packets from unknown IP addresses as being DTLS.  This requirement
does not mean that the server is required to accept these packets.  It
means that if the server chooses to accept them, they are to be
treated as being DTLS.

For packets from known IP addresses RADIUS/DTLS servers MUST maintain
a boolean "DTLS Required" flag for each client that indicates if it
requires a client to use RADIUS/DTLS.  If the flag is "true" then all
packets from that client MUST be processed as RADIUS/DTLS.

The transition to RADIUS/DTLS is performed only when the "DTLS
Required" flag is "false".  This setting means that the client is
known to support RADIUS/UDP, but may also support RADIUS/DTLS.
Packets from the client need to be examined to see if they are
RADIUS/UDP or RADIUS/DTLS.  The protocol disambiguation method
outlined below in Section 5.1.2 MUST be used to determine how received
packets are treated.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 05 Apr 2013 09:33:44 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Transitioning to DTLS is a process which needs to be done
    Alan> carefully.  A poorly handled transition is complex for
    Alan> administrators, and potentially subject to security downgrade
    Alan> attacks.  It is not sufficient to just disable RADIUS/UDP and
    Alan> enable RADIUS/DTLS.  That approach would result in timeouts,
    Alan> lost traffic, and network instabilities.

Alternative:

MOST clients can transition to RADIUS/DTLS by disabling UDP and enabling
RADIUS/DTLS.
Any UDP requests active during the transition will not receive a
response.

Servers need a way to indicate that a particular client is permitted to
send both UDP and DTLS requests during a transition so that timing of
transitions is not closely coordinated on the server and client.

there 
    Alan> The end result of this specification is that nearly all
    Alan> RADIUS/UDP implementations should transition to using
    Alan> RADIUS/DTLS.  In some cases, RADIUS/UDP may remain where IPSec
    Alan> is used as a transport, or where implementation and/or
    Alan> business reasons preclude a change.  However, long-term use of
    Alan> RADIUS/UDP is NOT RECOMMENDED.

I'm uncomfortable with the above statement.  I'm not sure that
RADIUS/DTLS is better than RADIUS/TLS. It seems a lot more complex, it
doesn't provide a solution to fragmentation, and I'm not convinced by
the arguments RFC 2865 makes against TCP.
So, I'm not sure I'd support a claim about where the world should go
other than to say away from RADIUS/UDP.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Apr 2013 10:12:08 -0400

OK.

> What security, migration or implementation concern does this "MUST"

  It allows a transition.  If you're fine with having a "flag day" with
no RADIUS traffic, you don't need a transition path.

> after they have declared otherwise.

  Uh... they declared that RADIUS/UDP packets were acceptable.  The DTLS
flag is for *new* traffic.

  It makes no sense to send RADIUS/UDP packets, and then ignore the
responses because DTLS is now required.

> exception has to be made for receiving non DTLS packets including
> protocol disambiguation procedure for clients not specified in draft.

  Nonsense.  There is no need for protocol disambiguation on the client.

  Clients already keep track of requests/responses.  The protocol used
by the request is the protocol used by the response.

  The draft never says that clients should accept RADIUS/DTLS responses
to RADIUS/UDP requests.  That would be a horrible idea.

> I am looking for specific technical justifications.

  Allowing people to transition to DTLS isn't a technical justification?

>  What safety or

  Network stability.  The client would have to either time-out all
RADIUS/UDP traffic, or pro-actively re-transmit it all as DTLS.  That
leads to either network instability due to no responses, or network
spikes due to duplicate requests.

> detail in section 5 removing RFC 5080 paragraph.

  We're into competing requirements here.  The text was added to address
concerns of how DTLS session tracking interacted with existing tracking.

> messages rather than storing a previous DTLS response and resending.

  Yes, that's true.

  OK.

> timeout becomes unsynchronized with server view of same.

  There is no mechanism for exchanging idle timeout values.  The server
could be set at 30 seconds, and the client at 10.  So they will always
be unsynchronised.

> My suggestion the mechanism to automatically migrate clients to DTLS
> after successful DTLS handshake is not necessary.

  It also involves changing the protocol, and changing multiple
interoperable implementations.

> We already need manual knobs to make this work.  Perhaps simply
> requiring a knob in client and server is the best approach. This would
> remove RADIUS/UDP to RADIUS/DTLS migration and RADIUS/DTLS
> disambiguation. Explicit configuration in client AND server would be
> necessary to successfully speak RADIUS/DTLS.

  The draft already describes explicit configuration to make RADIUS/DTLS.

  The point of the transition path is to *allow* a transition path.
Otherwise an administrator needs to modify both ends simultaneously.  He
also needs to deal with dropped traffic due to the human "simultaneous"
having a different timescale from the computer "simultaneous".

  i.e. there may be seconds to minutes where the two systems are out of
sync, and *all* RADIUS traffic is dropped.

  For someone who is worried about idle timeout synchronization, it's
surprising that you're OK with having no protocol synchronization.  One
works in the real world and causes no real-world problems.  The other
causes network outages and potentially loss of revenue.

> uncommon for new RADIUS traffic to be seen on orders of tens of minutes
> to hours.  Having a connection open hurts nobody and prevents delay
> including possibly additional delay to failover for users coming
> online.  It also prevents state sync problems..(see my comments below)

  This is related to the RFC2865 issue of "keep alive considered
harmful".  If there's no traffic to the RADIUS server for hours, having
DTLS heartbeats have little benefit.

  I think the arguments against this are best summarized by the 20
year-old argument against keep-alives.

> server failure

  I would guess that both DTLS and watchdog packets are handled by the
same process.  In which case... the same process is responsible for both
heartbeat and watchdog.  It's unclear to me how it would respond to one
and not to the other.

> rather than communication of compatible session timeout
> parameters.

  Well, the draft doesn't propose communication of session timeout
parameters.

> Server promptly ignores this request because the session was torn down
> due to exceeding idle timeout.  The client runs thru all of its retries
> and timeouts IGNORED by the server before it either picks a different
> RADIUS server or tries to open a new RADIUS/DTLS session to the same
> server.

  That is an issue.  It's mitigated by the suggestion to use an
application-layer watchdog.  While keep-alives are harmful, the client
can use the watchdog to ensure that the server is up.

  If the client doesn't use a watchdog, then it can't rely on DTLS
hearbeats.  Or so you say above.

> refreshed by DTLS heartbeats.

  Which is what the draft suggests.

> delays for clients to figure out and react to rug being pulled out from

  Of course.  But if the client isn't sending traffic... there's no
reason for the server to keep the session alive.  I think the only
disagreement here is whether the "idle timeout" values are large or small.

> "idle timeout" since last packet without an "idle" transition?

  That is what I meant by "idle".

> idle for 60-86400 seconds if DTLS heartbeats or active watchdog probes
> are used.  When unused RADIUS/DTLS client SHOULD close sessions idle for
> 60 to no longer than 600 seconds.

  Which still has the problem you noted.  Clients have an idle timeout
of 600s, and servers of 60s.  Changing the suggested timers works around
the problem without solving it.

  Suggesting that the client use the watchdog algorithm solves the problem.

>    situations. The server SHOULD delete idle DTLS sessions after

  Hmm... OK.  I'll work on some text.

> servers SHOULD close idle sessions starting with highest idle time until
> a sufficient number of sessions have been closed or lower idle timeout

  That's not clear to me.  I'll work on some text.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Apr 2013 11:18:18 -0700 (Pacific Daylight Time)

> means that if the server chooses to accept them, they are to be

I don't think this will work for us.  This is data that people use to 
flag/report possible new clients they should have known about, existing 
clients with changed addresses and plain old configuration errors.

It can be a configuration option, done conditionally within the context 
protocol disambiguation or even a recommendation but not something 
unconditionally required.

> outlined below in Section 5.1.2 MUST be used to determine how received

Suggest reversing this.  Have the client maintain the flag.  If DTLS 
handshake has succeeded then client uses DTLS from then on for any 
inquiries without the option of automatically falling back to UDP.

Servers would still maintain flag but it would only be a manually turned 
knob to indicate security level it is willing to accept.

This causes less breakage for the case of multiple clients behind a single 
IP where they can not all be upgraded at once to DTLS.  Whether client or 
server does the enforcement seems moot as the same outcome is realized 
either way.

The more I think about it the more I agree with Joe's points on separate 
UDP ports.

regards,
Peter

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Apr 2013 16:08:07 -0700

> Of Peter Deacon
> Sent: Friday, April 05, 2013 12:24 AM
> To: Alan DeKok
> Cc: [email-masked]; [email-masked]
> >> RFC 6614 section 6 dedicates a few sentences to TCP specific
> >> properties which do not apply to RADIUS/DTLS.
> 
system
> they would be *required* to accept responses with lower security after
they
> have declared otherwise.
productivity
> implications does the MUST requirement provide?  If it did not exist how
> would safety or productivity be negatively impacted?
> 
detail in
> section 5 removing RFC 5080 paragraph.
> 
> >> I think it might be helpful to note RFC5080 in the context of
> >> continuing to support this mechanism and to continue to do it at the
> >> RADIUS packet layer rather than DTLS or you're likely to end up on
> >> the wrong side of the DTLS sequence window.
> 
retransmitted
> messages being too stale to be accepted on DTLS stack unless
retransmissions
> are performed by retransmitting stored RADIUS response thru DTLS.
> 
> 
> Suggest a short text:
> 
transmitted
> DTLS packets MUST NOT be retransmitted.
> 
> >> 5.1 "Last Packet
> >> As long as the packet was valid while being silently discarded it
> >> should count for the purpose of last packet.
> 
timeout
> becomes unsynchronized with server view of same.
> 
> >> 5.1.1 - I still think we can do better on the UDP / DTLS
> >> disambiguation using the 4 byte header I described earlier or by
> >> explicitly requiring a server knob to declare what protocol would be
> >> accepted from a given source address.
> 
a
> knob in client and server is the best approach. This would remove
successfully
> speak RADIUS/DTLS.
> >>  Do you intent for sessions to idle out and expire even with active
> >> DTLS layer keepalives?
> 
prevents
> state sync problems..(see my comments below)
> 
> >> The recommended maximum idle timeout is too low in my view.
> >> Resetting connections should be as rare as possible as clients now
> >> have the added burden of correctly guessing whether packets were
> >> dropped on wire or dropped on DTLS stack in addition to possibility
server
> may not be alive.
server
> failure rather than communication of compatible session timeout
parameters.
> (5.2 "RADIUS/DTLS clients SHOULD pro-actively close sessions when they
have
> been idle for a period of time")
> 
> For the sake of this example RADIUS client is connected to a NAS that sees
> only a few concurrent sessions and only sparse activity every few
timeouts
> IGNORED by the server before it either picks a different RADIUS server or
> tries to open a new RADIUS/DTLS session to the same server.

But you are also going assume that the teardown message on the DTLS link is
also going to be lost.  In the more common case the close_notify alert is
going to get sent from the server to the client (or the other way) and both
sides are going to know that the session has been shut down.   

Jim

> Other thoughts to minimize this problem have client enforce an idle
timeout
> algorithm based on usage but allow server idle timer to be refreshed by
DTLS
> heartbeats.
manage
> DTLS sessions but normally it is important to do EVERYTHING possible to
make
> sure RADIUS/DTLS is as reliable as RADIUS/UDP with no delays for clients
to
> figure out and react to rug being pulled out from under them.
> 
"idle
> timeout" since last packet without an "idle" transition?
> 
idle
> for 60-86400 seconds if DTLS heartbeats or active watchdog probes are
used.
> When unused RADIUS/DTLS client SHOULD close sessions idle for 60 to no
> longer than 600 seconds.
> 
> 5.1.1...
> 
servers
> SHOULD close idle sessions starting with highest idle time until a
sufficient
> number of sessions have been closed or lower idle timeout threshold of 60
> seconds or more has been reached.
> 
> regards,
> Peter

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Apr 2013 17:22:30 -0700 (Pacific Daylight Time)

>> TCP TLS provides reliable notification of shutdown DTLS does not.

Hi Jim,

Apologize if I gave a different impression than intended.  Did not intend 
to exclude or imply no notification only notification is unreliable.

Advocating mitigating with small changes to default settings or idle 
algorithm as in suggested text.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Sat, 6 Apr 2013 00:28:39 -0700 (Pacific Daylight Time)

> flag is for *new* traffic.

It makes a decision for the operator by assuming past configuration is 
still desired or applicable.

> responses because DTLS is now required.

When switching to DTLS clients may no longer be capable or willing to 
touch RADIUS/UDP.  I'm not arguing against the behavior.  I just think the 
MUST requirement is too strong.

> Otherwise an administrator needs to modify both ends simultaneously. 
> He also needs to deal with dropped traffic due to the human 
> "simultaneous" having a different timescale from the computer 
> "simultaneous".

> causes network outages and potentially loss of revenue.

At some point the operator would have had to update firmware or software 
taking the system offline to obtain RADIUS/DTLS functionality.  These 
kinds of things are handled normally within a planned maintenance window.

As draft points out in section 10.3 this automatic scheme causes breakage 
while there are multiple clients behind a single IP.  When just one of 
them upgrades all other clients break causing network outage and potential 
loss of revenue.  The simple manual server knobs without migration 
behavior in this case prevents migration from *causing* an outage.

Having thought about this a bit more perhaps it would be better simply to 
move migration procedure from server to client.  This would fix NAT 
problems and server "flag" would only be used to declare level of security 
it is willing to accept.

> year-old argument against keep-alives.

RFC 2865 makes this argument in context of probing server availability.

DTLS heartbeat communicates DTLS session availability.

Now that there are sessions to be managed and connect first constraints on 
source port usage have to be careful with context of RFC 2865 keepalive 
philosophy.

The main reason I see a need to use heartbeats is to thread the needle 
keeping UDP NAT associations from expiring, letting servers know our 
session is not forgotten and detecting session termination.  None of these 
concerns apply to RADIUS/UDP.

I would be happy if DTLS heartbeats were able to reset server idle 
timeout.  Thats all I want.

In my view the only "application layer" thing that works for purpose of 
determining useful overall systems availability is still passive 
observation of response to client requests in the spirit of RFC 2865.

regards,
Peter

---

From: Dave Nelson <[email-masked]>
Date: Sat, 6 Apr 2013 08:46:09 -0400

On Sat, Apr 6, 2013 at 3:28 AM, Peter Deacon <[email-masked]>wrote:

> taking the system offline to obtain RADIUS/DTLS functionality.  These kinds
> of things are handled normally within a planned maintenance window.
>
> while there are multiple clients behind a single IP.  When just one of them
> upgrades all other clients break causing network outage and potential loss
> of revenue.  The simple manual server knobs without migration behavior in
> this case prevents migration from *causing* an outage.
>

I was wondering why starting up a replacement RADIUS server offering
RADIUS/DTLS on another IP address, and then switching the RADIUS server IP
address on each client as it's upgraded -- it has to be upgraded --
wouldn't accomplish the same overlapped, make-before-break transition as a
single server that supports two modes of operation?

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Sat, 06 Apr 2013 08:52:09 -0400

Dave Nelson wrote:
> RADIUS/DTLS on another IP address, and then switching the RADIUS server
> IP address on each client as it's upgraded -- it has to be upgraded --
> wouldn't accomplish the same overlapped, make-before-break transition as
> a single server that supports two modes of operation?

  Yes.

  Switching ports would work, too.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 06 Apr 2013 09:38:35 -0400

> clients with changed addresses and plain old configuration errors.

  I don't see how that relates to what I said.  The text doesn't
*prevent* you from flagging IP addresses, or warning an admin about
packets from those IPs.

> unconditionally required.

  This is how RADIUS works today.  Clients are keyed by known IP.
Changing that is not an option for RADIUS/UDP.

> inquiries without the option of automatically falling back to UDP.

  The draft already discusses a flag for the client.

> knob to indicate security level it is willing to accept.

  The draft allows it to me administratively configured.

> The more I think about it the more I agree with Joe's points on separate

  It is definitely simpler.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sat, 6 Apr 2013 09:35:09 -0700 (Pacific Daylight Time)

> *prevent* you from flagging IP addresses, or warning an admin about

Requests from unknown IPs by itself is not useful.  Normally access to the 
RADIUS request (NAS-ID) often provides relevant clue.

> Changing that is not an option for RADIUS/UDP.

The comment above was in context of MUST requirement within text quoted. 
I'm not arguing the policy.. only MUST is too strong.  For example 
changing to SHOULD would be fine.

>  The draft already discusses a flag for the client.

I apologize for any misunderstanding.  The migration would be in the 
client rather than server.  They would both have flags but the automatic 
upgrade with memory to prevent downgrade would be handled at the client.

>> Servers would still maintain flag but it would only be a manually 
>> turned knob to indicate security level it is willing to accept.

>  The draft allows it to me administratively configured.

This appears to be restricted by the current text of the draft.  See the 
following from section 3.1.  The server MUST maintain the flag and 
description of "false" value mandates migration using MUST keyword.

    "RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for
    each client that indicates if it requires a client to use
    RADIUS/DTLS.  The interpretation of this flag is as follows. If the
    flag is "true" then the client supports RADIUS/DTLS, and all packets
    from that client MUST be processed as RADIUS/DTLS.  If the flag is
    "false", then the client supports RADIUS/UDP, but may still support
    RADIUS/DTLS. "

    "Once a RADIUS/DTLS server has established a DTLS session with a
    client that previously had the flag set to "false", the server MUST
    set the "DTLS Required" flag to "true".  This change requires all
    subsequent traffic from that client to use DTLS, and prevents
    bidding-down attacks."

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sat, 06 Apr 2013 19:49:38 -0400

> still desired or applicable.

  The point of a specification is to do exactly that: mandate good
decisions where the local admin may make bad ones.

> touch RADIUS/UDP.  I'm not arguing against the behavior.  I just think
> the MUST requirement is too strong.

  You're very concerned about miscommunication for idle timeouts, but
you're unconcerned with miscommunication here.  I'm not sure why.

> kinds of things are handled normally within a planned maintenance window.

  There is no requirement to *use* DTLS when you upgrade the firmware.
Allowing for a gradual migration path is good, in my opinion.

> As draft points out in section 10.3 this automatic scheme causes
> breakage while there are multiple clients behind a single IP.

  Which is not supported by RADIUS/UDP.  This document isn't the place
to standardize that behavior.

>  When just
> one of them upgrades all other clients break causing network outage and
> potential loss of revenue.  The simple manual server knobs without
> migration behavior in this case prevents migration from *causing* an
> outage.

  If people aren't following the specs, then they're responsible for
breaking their own networks.  I don't have a lot of sympathy here.

> Having thought about this a bit more perhaps it would be better simply
> to move migration procedure from server to client.  This would fix NAT
> problems and server "flag" would only be used to declare level of
> security it is willing to accept.

  That results in down-bidding attacks from the clients, which won't
pass a security review.

> session is not forgotten and detecting session termination.  None of
> these concerns apply to RADIUS/UDP.

  If you're going to run multiple RADIUS clients behind one NAT, you're
not really doing RADIUS.

  OK.

> observation of response to client requests in the spirit of RFC 2865.

  Using Status-Server is a reasonable substitute.  Especially when (as
you say) the client may not be sending "normal" packets for long periods
of time.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 06 Apr 2013 20:02:13 -0400

Peter Deacon wrote:
> Requests from unknown IPs by itself is not useful.  Normally access to
> the RADIUS request (NAS-ID) often provides relevant clue.

  That's not part of standard RADIUS.  If you have a proprietary
extension, you're responsible for ensuring it works.  The IETF isn't.

> upgrade with memory to prevent downgrade would be handled at the client.

  That won't pass security review.  Having the server *also* handle
client upgrade is a hard requirement.

> description of "false" value mandates migration using MUST keyword.

  Quoting the text isn't helpful.  I'm sure I've read it.

  The rest of the draft says:

   The "DTLS Required" flag MUST be exposed to administrators of the
   server.  As clients are upgraded, administrators can then manually
   mark them as using RADIUS/DTLS.

  The "automatic" upgrade path is one which doesn't require
administrator intervention.  However, it doesn't *prevent* admins from
manually forcing a client to do DTLS.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 7 Apr 2013 21:23:52 -0700 (Pacific Daylight Time)

> extension, you're responsible for ensuring it works.  The IETF isn't.

What "proprietary extension" is required to log incoming requests?

> client upgrade is a hard requirement.

What is the goal of migration procedure?  This is essentially a simplified 
form of TLS cipher negotiation.

TLS clients communicate a list of acceptable ciphers.  TLS servers check 
server list against the client list.  If there are no mutually acceptable 
ciphers TLS handshake fails.

If there are multiple acceptable ciphers there is no hysteresis 
requirement in TLS to further constrain mutually acceptable cipher lists 
of subsequent sessions between peers.

Lets examine the complete matrix of options for RADIUS/UDP vs RADIUS/DTLS 
clients and servers.

Possible client options: Request sent using RADIUS/UDP or RADIUS/DTLS

Possible server options: Server accepts RADIUS/UDP only, RADIUS/DTLS only 
or RADIUS/UDP and RADIUS/DTLS.

Client           Server               Result
---------------- -------------------- ----------------------
RADIUS/UDP       UDP only             Success - RADIUS/UDP
RADIUS/UDP       UDP or DTLS          Success - RADIUS/UDP
RADIUS/UDP       DTLS only            Fail
RADIUS/DTLS      UDP only             Fail
RADIUS/DTLS      UDP or DTLS          Success - RADIUS/DTLS
RADIUS/DTLS      DTLS only            Success - RADIUS/DTLS

If RADIUS server chooses to indicate support for UDP and DTLS the client 
is able to upgrade to DTLS at any time without server coordination.

If the RADIUS server chooses to indicate support for DTLS only then only 
DTLS connections are accepted.

The only necessary reason for migration flag is to enable RADIUS/UDP and 
RADIUS/DTLS capable clients to automatically probe server to see if it 
supports RADIUS/DTLS.

Section 4 strongly discourages this behavior:

    "RADIUS/DTLS clients SHOULD NOT probe servers to see if they support
    DTLS transport.  Doing so would cause servers to immediately require
    that all new packets from the client use DTLS.  This requirement may
    be difficult for a client to satisfy.  Instead, clients SHOULD use
    DTLS as a transport layer only when administratively configured."

Further I would argue this must NOT be allowed as RADIUS/DTLS capable 
clients would then be sending non RADIUS/UDP messages to RFC 2865 
compliant servers.  I believe the bar should at least be client knob to 
indicate server supports RADIUS/DTLS to minimize RFC 2865 compliant 
servers from receiving non-RFC 2865 compliant messages.

With regards to the security review claim the migration concept is 
susceptible to trivial MITM in the network path simply by filtering out 
the more secure (DTLS) messages.  Whether it is the client that does it or 
the server makes no difference.  This scheme is insecure either way.

>   mark them as using RADIUS/DTLS.

The problem is servers would not have the option of turning off the 
automatic migration behavior.  Side effect of this is that multiple 
clients behind a single IP can not use a mix of UDP and DTLS concurrently.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Apr 2013 09:21:57 -0400

>> I apologize for any misunderstanding.  The migration would be in
    >> the client rather than server.  They would both have flags but
    >> the automatic upgrade with memory to prevent downgrade would be
    >> handled at the client.

    Alan>   That won't pass security review.  Having the server *also*
    Alan> handle client upgrade is a hard requirement.

Can you point to the documentation of the hard requirement for
server-side memory in upgrade?
I'd like to understand how we got there and the discussions/arguments
leading to that.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Apr 2013 09:28:07 -0400

> What "proprietary extension" is required to log incoming requests?

  So... your best option is to lie about what I said?

> Lets examine the complete matrix of options for RADIUS/UDP vs
> RADIUS/DTLS clients and servers.

  Let's not.  Conversations presume that both parties operate in good faith.

> the more secure (DTLS) messages.  Whether it is the client that does it
> or the server makes no difference.  This scheme is insecure either way.

  Nonsense.

> automatic migration behavior.

  You've understood that, at least.

>  Side effect of this is that multiple clients behind a single IP 

  ... is not part of RADIUS.

  Once again, you're ignoring my messages about that topic.  You seem to
think that by simply repeating yourself ad nauseum, you can win a
logical argument.  Logic doesn't work that way.

  IMHO, hell will freeze over before RADIUS/UDP standardizes multiple
clients behind one IP.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Apr 2013 09:29:53 -0400

> I'd like to understand how we got there and the discussions/arguments

  Down-bidding attacks.

  Once a client upgrades to DTLS, allowing plain UDP is a down-bidding
attack.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Apr 2013 09:55:28 -0400

Alan> Sam Hartman wrote:
    >> server-side memory in upgrade?  I'd like to understand how we got
    >> there and the discussions/arguments leading to that.

    Alan>   Down-bidding attacks.

    Alan>   Once a client upgrades to DTLS, allowing plain UDP is a
    Alan> down-bidding attack.

I'm aware of that.
However, gat least sections of the security area I've been involved in
have taken a wide variety of approaches to these types of attacks.

Having the sort of mechanism you describe as a SHOULD is almost
certainly going to be sufficient.  However we can check with Steve and
Sean if desired or bring it up on secdir.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 8 Apr 2013 08:20:53 -0700 (Pacific Daylight Time)

>  Down-bidding attacks.

A bidding down attack requires client or server to be tricked into 
accepting security lower than highest supported by both peers.  See the 
table in my previous message.

>  Once a client upgrades to DTLS, allowing plain UDP is a down-bidding

To be an attack the attack must be successful. With RADIUS/DTLS draft 
there is no negotiation protocol to attack.  Either the nonnegotiable 
demands of both sides are met or it fails.

A client configured to only emit RADIUS/DTLS requests cannot be tricked 
into falling back to a less secure RADIUS/UDP.

Likewise a server willing to accept RADIUS/UDP and RADIUS/DTLS cannot be 
tricked into accepting RADIUS/UDP as RADIUS/UDP has been configured to be 
acceptable to the server.

A server willing to accept only RADIUS/DTLS cannot be tricked into 
accepting RADIUS/UDP.  This is a setting on the server rather than 
negotiation parameter able to be attacked from the protocol.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Apr 2013 11:35:00 -0400

>>>>> "Peter" == Peter Deacon <[email-masked]> writes:

    Peter> On Mon, 8 Apr 2013, Alan DeKok wrote:
    >>> server-side memory in upgrade?  I'd like to understand how we
    >>> got there and the discussions/arguments leading to that.

    >> Down-bidding attacks.

    Peter> A bidding down attack requires client or server to be tricked
    Peter> into accepting security lower than highest supported by both
    Peter> peers.  See the table in my previous message.

OK.
So, RADIUS/UDP is easier to attack than RADIUS/DTLS.
Let's assume a server requires message authenticators for UDP.

If the server forbids UDP-after-DTLS, then once DTLS has happened, an
attacker can no longer attack that particular UDP secret.
However if the client is responsible for enforcing the attack, then an
attacker can try and convince the server to accept a request using the
UDP secret in question.

I don't want to argue about whether it's a bid-down attack or not.
It is a real attack.
It's almost certainly in our threat model.

It's almost certain that a policy control of forbid UDP as the
mandatory-to-implementmechanism combined with Alan's proposal for
latching on use of DTLS as a SHOULD is sufficient to meet security
review.
If you turn off the latching behavior  then  you have a residual risk.

That said, I think I've also convinced myself that having the latching
behavior be mandatory-to-implement but not mandatory-to-use on the
server is also fine.

So,  here's where I stand on this issue:

* we need to do something in this space.

* I'm against mandating that clients or proxies support upgrading from
  UDP to DTLS without a restart/flag day

* I am in favor of requiring servers support clients upgrading without a
  flag day. Alan's latching proposal seems like a fine option to get
  that either as a SHOULD or MUST.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Apr 2013 13:09:14 -0400

> * we need to do something in this space.

  Agreed.

  OK.

  OK.

  Or... we can delete all of the text around upgrade paths, and just use
a different port.

  I really don't care either way.  The upgrade text is there due to WG
consensus on the issue.  If the WG now has consensus on using a new port
instead, that's fine.  I'll have a new draft available tomorrow.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Apr 2013 13:10:16 -0400

Peter Deacon wrote:
> tricked into accepting RADIUS/UDP as RADIUS/UDP has been configured to
> be acceptable to the server.

  See my previous 10 messages for why this reasoning is wrong.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Apr 2013 13:21:17 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   Or... we can delete all of the text around upgrade paths,
    Alan> and just use a different port.

Well,  I'm actually not sure about the security of this.
Even if you use a different port, don't you still have all the bid-down
issues?
I mean what stops an attacker from sending you UDP traffic that's from a
client that should be using DTLS.

I don't mind using a different port, but I don't think it helps much
with this discussion.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Apr 2013 13:32:10 -0400

>>>>> "Arran" == Arran Cudbard-Bell <[email-masked]> writes:

>>>>>> "Alan" == Alan DeKok <[email-masked]> writes:
    Alan> Or... we can delete all of the text around upgrade paths, and
    Alan> just use a different port.
    >> 
    >> Well, I'm actually not sure about the security of this.  Even if
    >> you use a different port, don't you still have all the bid-down
    >> issues?  I mean what stops an attacker from sending you UDP
    >> traffic that's from a client that should be using DTLS.

    Arran> Presumably you would make this a dedicated DTLS port and
    Arran> discard non-DTLS traffic.

Attackers have been known to choose the port that makes their attack
work.
The attacker will send you udp on the udp port and dtls on the dtls
port.
Ports aren't magic.

>From a security standpoint, what the upgrade logic does is reduce the
number of senders who are permitted to send you UDP.
That's most effective if you use a different secret for each UDP sender.
Each time you reduce the number of secrets that you accept for UDP
traffic you increase security.

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 8 Apr 2013 14:50:08 -0400

> The attacker will send you udp on the udp port and dtls on the dtls

True. But a atching mechanism feasible eveywhere. I'd suggest that such a mechanism MUST be implemented, but suggest that it be SHOULD be configurable with high enough granularity to dictate behaviour for individual clients.

What having a dedicated DTLS port gets you, is the ability to mandate that between network boundaries only encrypted RADIUS traffic may pass. This would otherwise be difficult to enforce without DPI. 

> number of senders who are permitted to send you UDP.

It also requires that the RADIUS server be able to persistently store this latching state for this to be effective. This is a new and potentially problematic issue for a RADIUS server which up to now had not had to dynamically modify its own configuration.

Allowing a daemon to modify any part of its configuration is generally considered bad practice, and where systems operate in a 'deep freeze' state provisions would have to be made for storing this information off box.

Whilst this is an implementation issue it may hinder uptake in some cases, which is why the latching should be optional.

> That's most effective if you use a different secret for each UDP sender.

Indeed.

> traffic you increase security.

Agreed. Reducing the number of IP addresses unencrypted traffic is accepted from reduces the range of IPs that can be used for a brute force attack, reducing the number of secrets also makes it less likely that such an attack would be successful. 

As an aside, were still working under the assumption that it's non-trivial to recover the shared secret from unecrypted RADIUS packets, correct?

-Arran

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Apr 2013 15:11:16 -0400

>What having a dedicated DTLS port gets you, is the ability to mandate that between network boundaries only encrypted RADIUS traffic may pass. This would otherwise be difficult to enforce without DPI…

True.
no objection to dedicated dtls port.

>As an aside, were still working under the assumption that it's non-trivial to recover the shared secret from unecrypted RADIUS packets, correct?

I don't know.  Enumerating through I think 96^11 md4s is apparently
trivial given reasonably-priced hardware for cracking.  So probably $10k
investment.  See recent discussions of hash cracking on GPUs.  However,
md5 is a bit slower, and 11 is less than 16.  I think I'd say that I
would be unsurprised if someone broke RADIUS secrets entirely, and would
be entirely unsurprised if brute forcing the secrets anyone is actually
using in practice was easy.
On the other hand I would not commit to being able to brute force a
particular RADIUS secret without more research.

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 8 Apr 2013 13:26:00 -0400

> client that should be using DTLS.

Presumably you would make this a dedicated DTLS port and discard 
non-DTLS traffic.

-Arran

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Apr 2013 15:43:53 -0400

Sam Hartman wrote:
> md5 is a bit slower, and 11 is less than 16.

  http://www.insidepro.com/eng/egb.shtml

  Says that they can do about 500M hashes/s.  Let's assume that's true,
and is the best case.  This is even though other sites claim 100x that
cracking power.

  These numbers are for *password* cracking, which is a bit different
from cracking RADIUS packets.  So maybe RADIUS will be slower.

>  I think I'd say that I

  I agree.  Let's say the MD5 cracking of RADIUS packets was 1% of the
above password cracking speed.  Even with that, brute-forcing all
alphanumerical passwords would take less than a year for one person.

  I have 94 individual characters available on my keyboard.  Let's say I
use them all for shared secrets, and that the cracking speed is 5M
attempts per second.  We have the following crack times, for each length
of shared secret:

4	16 seconds
5 	25 minutes
6	38 hours
7	150 days
8	37 years

  If you assume that the attacker can do 500M attempts per second, then
all shared secrets less than 8 characters long can be trivially broken.
 And it gets MUCH worse than that if people are less rigorous about
using a wide range of ASCII characters.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 8 Apr 2013 21:14:59 -0700 (Pacific Daylight Time)

> behavior be mandatory-to-implement but not mandatory-to-use on the 

This sounds good to me.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 9 Apr 2013 00:41:35 -0700 (Pacific Daylight Time)

>  See my previous 10 messages for why this reasoning is wrong.

To help understand my perspective on this issue here is an example of 
hypothetical bidding down attack against TLS.

TLS Client allows ciphers BAD1,SEC1
TLS Server allows ciphers BAD1,SEC1,SEC2.

Normally this leads to negotiation of the best common cipher (SEC1).

A bidding down attack occurs when a third party is able to trick peers 
into using a lower security cipher (BAD1) than necessary.

If instead a malicious client connects to TLS server directly using BAD1 
cipher this is no longer a bidding down attack.  Neither is it the fault 
of TLS server.  The server operator has elected to make a poor choice in 
allowing BAD1 cipher.  (It's the operators fault)

Switching to RADIUS the same is applicable.  If operator elects to enable 
RADIUS/UDP and RADIUS/DTLS concurrently the operator has made an explicit 
decision to accept the implication of this choice. (It's the operators 
fault)

I support attempts to provide recommendations and give operators more 
options to improve security of their systems such as the migration flag 
however I don't think the bar for mandating protection of operators from 
themselves has been met in this instance.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Apr 2013 06:27:25 -0400

>>>>> "Peter" == Peter Deacon <[email-masked]> writes:

    Peter> Normally this leads to negotiation of the best common cipher
    Peter> (SEC1).

    Peter> A bidding down attack occurs when a third party is able to
    Peter> trick peers into using a lower security cipher (BAD1) than
    Peter> necessary.

    Peter> If instead a malicious client connects to TLS server directly
    Peter> using BAD1 cipher this is no longer a bidding down attack.
    Peter> Neither is it the fault of TLS server.  The server operator
    Peter> has elected to make a poor choice in allowing BAD1 cipher.
    Peter> (It's the operators fault)

Hi.
I said I was not going to argue about whether it's a bidding down attack
mostly because we could get into arguments like the above.

The way to propose looking at this issue is one of the ways that it's
often looked at.

What Alan proposes is another.

However, with your message agreeing to MTI but not mandatory to use, I
think we've found a consensus around here so let's not destroy it with
semantics.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 09 Apr 2013 08:28:22 -0400

Peter Deacon wrote:
> Switching to RADIUS the same is applicable.

  Only if you ignore the migration mechanism which protects against
this.  The draft talks about it in detail.

  I know you're aware of the mechanism.  You mention it below, and
you've previously claimed it would destroy client-server communication.
 Because you were ignoring the watchdog method for keeping connections
active.

  I know you're aware of the watchdog mechanism.  You've previously
claimed that not using it would destroy client-server communication
because of idle timeouts.  Your solution there was to suggest idle
timeouts which wouldn't fix the problem.

> themselves has been met in this instance.

  You haven't said what the "bar" requirements are.

  That which can be asserted without evidence can be dismissed without
evidence.

  Alan DeKok.