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

[Peter Deacon <[e-mail]>]

On Sat, 6 Apr 2013, Alan DeKok wrote:

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

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

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

>  That won't pass security review.  Having the server *also* handle
> 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.

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

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