Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models

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

Hi,

just to add my 2ct as well, after reading the arguments, and maybe 
summarize the arguments, to put it as an explanatory text into the spec 
in the end:


My personal opinion is that, with transitioning the RADIUS/(D)TLS spec 
from "Experimental" to "Proposed Standard", it is an important step to 
evaluate the choices that were made at then and adjust the standard to 
the reality.

The experimental RADIUS/TLS is deployed widely, and that's good. But not 
as widely as we hoped, because apparently dealing with certificates is 
much harder than dealing with shared secrets.


So the adjustment we can make now is to say: "Well, the experiment went 
well and the certificate part works wonders for the dynamic routing in 
eduroam on NRO level" (just to give an example) but the experience in 
the NROs is that introducing RADIUS/(D)TLS as transport for connecting 
the local RADIUS instances to the NRO proxy servers is a hard task.

(Speaking from experience: At DFN we mandate RADIUS/TLS as transport for 
several years now and that has created some difficulties and there are a 
number of individuals that had and still have very strong opinions 
against it, especially since it requires a separate piece of software, 
that needs to be maintained in addition to the RADIUS instance).


For the discussion TLS vs DTLS I have no strong opinion and have to rely 
on more experienced people that know the differences and problems 
better, especially since the connections we at DFN run our RADIUS/TLS 
over are very stable, so Head-of-Line-blocking does not seem to be a 
problem in the deployment (at least from what I can observe).


For Certificates vs. TLS-PSK I can say that managing the certificates is 
not an easy task and especially expiring certificates constantly cause 
institutions to loose the connection to the federation.


I can see the additional effort to implement both certificates and 
TLS-PSK on the server side could lead to implementers ignoring the 
mandatory trust models and just implementing one, but as long as this 
one is standard compliant at least there is a chance of compatibility, 
if the client side implements the "SHOULD" trust models as well.

Both trust models (certificates and TLS-PSK) have their legitimate use 
case in several situations.

If we split the document again (one general spec, one for trust model 
"Cert" one for "TLS-PSK") it would quite probably just create a world 
with two ecosystems developing independent from each other with the need 
to put proxies in the middle again, and that's exactly what we (or at 
least I) try to prevent.



 From what I have read on the list, I get the feeling that there is 
support for mandating certificates and TLS-PSK on the server side, so 
I'll start producing some text in that direction, if there are still 
people with a different opinion, please speak up :)


Cheers,

Janfred


On 14.08.23 00:46, Margaret Cullen wrote:
> 
> Okay, I withdraw my concern.  From a “better specification” standpoint, I agree that mandating that servers implement everything and allowing clients to implement only what is needed for their application makes sense.
> 
> Margaret
> 
>> On Aug 13, 2023, at 6:36 PM, Alexander Clouter <[e-mail]> wrote:
>>
>> On Sun, 13 Aug 2023, at 18:38, Margaret Cullen wrote:
>>>> DTLS is a lot more difficult.  I blame some of that on OpenSSL weirdness.  Their DTLS implementation has best been described as "alpha" for a long time.
>>>
>>> This is the reason for my concern with mandating that servers implement DTLS.
>>
>> OpenSSL is not the only TLS library out there. I would be hesitant steering any decisions based on a single (albeit more widely used) library implementation.
>>
>> The telephony world though seems to be quite happy using DTLS, after all no one wants to endure voice/video calls over the WAN via TCP.
>>
>>> I think RADIUS/DTLS is an awful lot to expect, though — especially
>>> because I don’t see any evidence that RADIUS/DTLS will ever be widely
>>> implemented or used.  Do you?
>>
>> Personally I really think this is more due to people not knowing TLS-over-UDP is even a thing.
>>
>> Maybe I am seeing this too simplistically, but the impact of any mandating done here only affects (officially) the labelling available to a vendor?
>>
>> * implementors of TLS *and* DTLS: you get to tout 'RFCwxyz compliance'
>> * implementors of only TLS: "you do not get this scout badge, sorry"
>>
>>> Many protocols that run over TLS don’t have a DTLS equivalent defined,
>>> at all.  Is there some important advantage that RADIUS/DTLS offers that
>>> RADIUS/TLS does not?  Is that advantage sufficient to warrant mandating
>>> both in every server implementation?
>>
>> Head of Line blocking. When a packet is lost, the RADIUS server is unable to do anything but twiddle its fingers until the networking stacks, outside of its control, at both ends figure it out.
>>
>> This means first the packet drop has to be detected, this can take some time anywhere from one to 1000's of milliseconds (~2xRTT), then retransmitted by the TCP layer until it gets through.
>>
>> The RADIUS server meanwhile is unable to get involved in the retransmissions its-self.
>>
>> Making it worse, *all* further authentications are gummed up until the stream starts to flow again.
>>
>> With datagrams, this simply is not a problem. Recovery is much more application orientated, plus it bubbles up to the application so failover opportunities are made available far sooner.
>>
>>>> There's good reason for that, of course.  But I think it's best to document the system we need, rather than the system we have.
>>>
>>> I absolutely agree with this when it comes to documenting good protocol
>>> behavior, ways to avoid known issues, etc.  I don’t think it extends to
>>> mandating the implementation of an entirely separate protocol.
>>
>> I think the wording makes this seem a bigger deal than it is.
>>
>> Transport, not protocol.
>>
>> Trying here to shift the focus that this is about something RADIUS runs *over* and not something that actually has to be implemented by anyone; the TLS libraries do all the work for you.
>>
>> It may be that an implementor has picked a library that is a pain on the DTLS front to work with, but I do not think this should be a reason to strike "MUST do DTLS".
>>
>> Afterall, the hard part of the work is already done. RADIUS servers are already expected to have implemented a datagram transport (ie. UDP) and handle retransmissions.
>>
>> Wiring TLS into that is a lot more straight forward than the hoops an implementator already goes through to handle any of the EAP-TLS method families such as fragments and the need to spoon feed the TLS library *manually*, yikes!
>>
>> No TLS library supports TLS over EAP, but it still works :)
>>
>>>> The alternative is to never fix RADIUS, or to give bad implementations a free pass.
>>>
>>> Is there a reason that you think a RADIUS/TLS-only server would be a
>>> bad implementation, and that it would  become a good implementation if
>>> it also implemented RADIUS/DTLS?
>>
>> The fallout I see is we will never see any DTLS implementations, and the for the most part this would have occurred for no real material reason.
>>
>> Like Alan said, OSS implementations are able to clear these hurdles without making much of a song or dance about it which leaves the only benefactors of weakening this requirement to those with arguably the resources where implementing this likely to be just a budget rounding error.
>>
>> I also suspect requiring DTLS will benefit those Internet cafe hotspot owners with their ropey saturated xDSL uplinks trying to authenticate the users to some hodgepodge WAN hosted RADIUS server federation.
>>
>> For all of these reasons, I really do think servers should be expected to do both. My view is the client can implement whatever it wants...they already do for better or worse...
>>
>> Cheers
>>
>> [1] https://mailarchive.ietf.org/arch/msg/radext/5HB6BTgxA_LqgWDdSIE30u_Ckg8/
>>
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext

-- 
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
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822