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

[Stefan Paetow <[e-mail]>]

Just as an aside:

We've had this situation with a vendor recently, and I can say that yes, sometimes you have to say "sorry, but not having RADIUS/TLS is not an option". Thankfully, the vendor has the technical skills and our assurance that we wouldn't be jumping ship, so RADIUS/TLS is being implemented. Now TLS-PSK would be an interesting future feature to suggest to them.

With kind regards

Stefan Paetow
Federated Roaming Technical Specialist
eduroam(UK), Jisc

email/teams: [e-mail]
gpg: 0x3FCE5142

For eduroam support, please contact the eduroam team via [e-mail] and mark it for eduroam’s attention.
On Wednesdays and Fridays, I am not available between 12:00 and 15:00.

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB Tel: [phone].





On 13/08/2023, 17:46, "radext on behalf of Alan DeKok" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:


On Aug 12, 2023, at 12:47 PM, Margaret Cullen <[e-mail] <mailto:[e-mail]>> wrote:
> After thinking about this for a while, I am concerned that if we add significant new implementation requirements for RADIUS/TLS servers in this specification, one or both of the following things will happen:
>
> - We will invalidate existing, RFC-compliant implementations of RADIUS/TLS,
>
> and/or
>
> - Implementors will simply ignore us, continue referencing the old RFCs for what they actually implement, and our specification will be irrelevant.


That is a tried and true RADIUS tradition. "I know the RFCs say to do X, but I'll just do something else instead."


> Right now, RADIUS/TLS, RADIUS/DTLS and TLS-PSK are in separate documents. So it is possible to implement an RFC-compliant RADIUS/TLS client or server without RADIUS/DTLS or TLS-PSK. Multiple implementations have done that, and I don’t think the new specification should render those implementations non-compliant or incomplete.


As an implementor, I'm fine with it. I think it's best to document how RADIUS _should_ work. And if implementors decide to ignore that, they can take the heat from their customers.


Another argument is that if an Open Source project (or two) can do it, why not a multi-billion dollar company?


> I’m not sure everyone understands (given what we say about “the D being silent”, etc.) that it takes significant effort to add DTLS support to an existing RADIUS/TLS implementation. UDP is substantially different from TCP, and there is less open source library support for DTLS than TLS. TLS-PSK support is less work, but still not trivial.


TLS-PSK was maybe a few hundred lines of code? (1) implement the various OpenSSL callbacks, and (2) expose PSK identity etc. in the configuration.


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.


> IMO, the point of this effort is to move a widely implemented and used protocol (RADIUS/TLS) from Experimental to Standards Track, while combining and harmonizing the RADIUS/TLS and DTLS specs. I don’t think it is, or should be, our goal to substantially raise the bar for what a minimal RFC-compliant RADIUS/TLS server needs to support.


I don't see why not. Many of the existing RADIUS specs are decades old. This one will last a long time. Why not recommend the system we want, instead of the system we have?


And implementors are not likely to be strongly influenced by the specs. Witness the retransmission timers recommended by RFC 5080. it's 15 years old, and many client implementations ignore it.


> Do we have any reason to believe that if we write a specification that says “all RADIUS/TLS servers MUST support DTLS and TLS-PSK” that implementors will actually do that in the near future? If not, I don’t think we should say that.


They won't, but I would argue it doesn't matter.


> I think we should mandate what actually exists today: “All RADIUS/TLS clients and servers must implement RADIUS/TLS”. I’d go with “servers SHOULD and clients MAY implement DTLS and TLS-PSK”.


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.


The alternative is to never fix RADIUS, or to give bad implementations a free pass.


As someone supporting multiple customers fighting bad implementations, I would prefer to have the ability to push back on those implementations. "I don't like it" is not a very compelling argument for fixing the product. "Your software doesn't follow the RFCs" is a much stronger argument.


Alan DeKok.


_______________________________________________
radext mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/radext <https://www.ietf.org/mailman/listinfo/radext>