Re: [radext] Review of draft-ietf-radext-radiusdtls

[Jan-Frederik Rieckers <[e-mail]>]

Here the next replies on the comments.

On 11.03.24 23:57, Alan DeKok wrote:
> 	... When the configured trust base changes (e.g., removal of a CA from the list of trusted CAs; issuance of a new CRL for a given CA), implementations SHOULD renegotiate the TLS session to reassess the connecting peer's continued authorization
> 
>    I'd say this is a MUST.   If a CA is removed from the list of trusted CAs, then every connection using that CA should be torn down.
> 
>   Similarly, if a client certificate is revoked, then any connection using that certificate should be torn down.
> 
>    The main problem here is tracking that information.  It may be difficult and/or expensive to do.  The naive approach would be to simply tear down all connections and let the clients re-authenticate.  But that can cause outages.

Well, the question is: is it really absolutely necessary? CRLs may be 
issued frequently, and maybe more frequently than we'd like, so the 
renegotiation load becomes to high.
Some CAs don't even issue CRLs, but only do OCSP.

Additionally: Didn't TLS1.3 remove the possibility for renegotiation? 
This basically means that we would have to tear down every session and 
make the peer re-authenticate.

It may be reasonable to assume that if a certificate was valid at the 
time of negotiation, it may be considered valid for a period of time, 
even if the corresponding CA has issued a new CRL.
Another option would be to have a (configurable) max-lifetime per 
connection, so the session gets torn down and re-authenticated regularly.

I'd say this is a perfect example for a review by UTA.

> 
> 4.3
> 
>    All of this is good, but it's also good to add text on IP filtering, as per TLS-PSK Section 6.2.1.

I've added a TODO and will add some text after the meeting.

> 4.4.
> 
> 	... When an unwanted packet of type 'Accounting-Request' is received, the RADIUS/(D)TLS server SHOULD reply with an Accounting-Response ...
> 
>    Perhaps Protocol-Error would be better here?  The temptation for proxies would be to simply return any Accounting-Response packet without examining it.  Which does not meet the goal of hop-by-hop signalling.

This would mean a deviation from the original spec.
I'm not familiar with Accounting (since it is not used in eduroam), I'll 
have a closer look at it.

For now I've added a TODO

> 5.1
> 
> 	...  Similarly, if there is no response to a RADIUS packet over one RADIUS/TLS connection, implementations MUST NOT retransmit that packet over a different connection to the same destination IP address and port
> 
>    Perhaps "to the same server"?  6613 was written before 7585, and therefore doesn't include provisions for dynamic lookups.

Well, then we need to have a section about identifying "the same server"
We have the "Client Identity" section, but nothing on the server's 
identity yet.

I've added a TODO.


>    It's also worth noting that accounting packets may be re-transmitted according to the provisions of RFC 5080, but only if the Acct-Delay-Time is updated, which means it's a different packet.
> 
> 
> 5.3
> 
>    One thing missed from earlier specifications is the issue of retransmissions when proxies accept packets over TCP, but forward packets over UDP.  The packets aren't retransmitted over the TCP connection.  So the proxy likely has generate the retransmissions itself over any UDP connections.
> 
>   Except for Accounting packets with Acct-Delay-Time.  :(
> 
>    This is an issue we've mostly avoided for now by just using RADIUS/TLS everywhere.  But as DTLS gets more widely used, this issue will crop up more often.  So it needs to be resolved.
> 

*sigh*
"This is a retransmission. Unless it's not....."

I think, a separate sub-section "Receiving via TCP and forwarding with 
UDP" is warranted to deal with these issues and closely explain which 
steps and implementation needs to take when a packet was received over a 
reliable channel, but forwarded over an unreliable one.

> 
> 6.1
> 
> 	... The DTLS encryption adds an additional overhead to each packet sent. RADIUS/DTLS implementations MUST support sending and receiving RADIUS packets of 4096 bytes in length,
> 
>    What about RFC 7499 (fragmentation)?  It provides for a way to negotiate (or at least signal) support for larger packets.

So what would be your suggested change?
"of at least 4096 bytes"

> 
> 
> 6.2.
> 
>    More discussion of IP filtering would be useful here.
> 
> 
> 6.4.1.1
> 
> 	... Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert ([RFC5246], Section 7.2.2) is received
> 
>    Perhaps note that sessions must be deleted when the TLS connection is closed for any reason.  And then enumerate the reasons as per the existing text.	

I've added a TODO to look into this, I want to look at the DTLS spec first.

> 
> 	... Sessions MUST also be deleted when a non-RADIUS packet is received,
> 
>    add "over the DTLS connection".  Otherwise people might close DTLS sessions when a forged UDP packet is sent to the server.
Added.

> 
>    And then the following text can be deleted, and replaced with a reference to the "invalid packet" text earlier in the document.

I'd leave it in, because handling invalid packets is different from TCP 
and UDP, and the previous section was TCP-specific.

> 
> 	... The timestamp MUST NOT be updated in other situations
> 
>    for clarity:  The timestamp MUST NOT be updated in other situations, such as when packets are "silently discarded"
Added.
> 
> 	... The server MAY cache the TLS session parameters, in order to provide for fast session resumption
> 
>    Delete this text.  The later paragraphs talk more about resumption.
Deleted.
> 6.4.2
> 
> 	... RADIUS/DTLS clients SHOULD use PMTU discovery
> 
>    Perhaps add a note that UDP fragmentation still doesn't work across the wider Internet.
> 
>    Also we need to add somewhere a discussion of UDP fragmentation issues.  i.e. if the typical PTMU for UDP is (say) 576 bytes, then some of that is taken up by the IP / UDP / *and* DTLS headers.  Which leaves less for RADIUS.
> 
>    It's perhaps worth noting at the start of Section 6 that sending UDP over the wider Internet is a bad idea, and generally doesn't work.  RADIUS/DTLS is largely for local networks where PMTU is less of an issue.
> 
>    That being said, I have seen sites which have "local" networks where the practical MTU was much less than the default ethernet MTU.  Most commonly due to having multiple layers of VPNs / MPLS.  This could be explained as something that people should watch out for.
> 
>    It may also be worth adding a section on "TLS vs DTLS applicability".  That section can then explain the pros and cons of using TLS or DTLS, and where you would want to use them.
> 
>    Some of the text on session management here is redundant with 6.4.1.1.  Perhaps unify them into a section on session management, as many of the issues are the same for both client and server.

That's a rather big change, I'll work on that after the meeting.

> 
> 7.1
> 
>    Perhaps also mention 7585, and suggest that this issue is best resolved by limiting the use of proxies.  The TLS-PSK document has some text on this.

I have tried to leave 7585 mostly out of this (as it was not mentioned 
in 6614). It's still experimental (do we want a 7585bis?)
But keeping dynamic discovery in mind is a good idea.

> 7.3
> 
>    Perhaps also discussion IP filtering, and how it can affect DoS.  Though the use of 7585 makes this more difficult.
> 
>   And suggest that RADIUS servers should generally not be exposed to the wider Internet.
> 
> 	... RADIUS/DTLS servers MUST limit the number of partially open DTLS sessions and SHOULD expose this limit as configurable option to the administrator.
> 
>    Perhaps also suggest much lower idle timeouts for partially open TLS sessions.  i.e. if a connection isn't established within 3-5s, then it's likely bad.  In contrast, an authenticated session might not send packets for 30s, and that's fine.

I'll add that text after the meeting, it's a good suggestion.

Cheers,
Janfred

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822