CA Trust for RADIUS/(D)TLS Clients

[ethan-thompson]

Added blurb on how CA trust for RADIUS/(D)TLS clients should be configured (from RFC 7360 Section 10.4)

[alandekok]

Looks good to me.

[alandekok]

On Oct 4, 2024, at 9:07 AM, Jan-Frederik Rieckers ***@***.***> wrote: ⬇️ Suggested change

Looks good.

[jimdigriz]

I would suggest amending this to reflect should not be pre-configured as already trusted for the client.

I could perceive an onboarding process that assists the administrator to know which CA to add as a trust anchor for the given client; it would show the chain but the administrator would still be expected to approve it.

[Janfred]

Suggested change

	If this model is implemented, RADIUS/(D)TLS clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.
	The goal of RADIUS/(D)TLS is to securely communicate with only a small set of well-known peers.
	These peers will use specific certificates, potentially even from a private purpose-specific CA.
	This scenario is different from a common use case of PKIX where an entity wants to communicate securely with unknown remote entities (i.e. web browsing), that use the public CAs to establish a trust path to this unknown entity.
	If this model is implemented, RADIUS/(D)TLS peers SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer that are enabled by default. Instead, the peers SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.
	This does not mean that vendors or manufactures cannot include trust lists in their products, but enabling these lists should always be a conscious decision of the administrator.
	The goal of RADIUS/(D)TLS is to securely communicate with only a small set of well-known peers.
	These peers will use specific certificates, potentially even from a private purpose-specific CA.
	This scenario is different from a common use case of PKIX where an entity wants to communicate securely with unknown remote entities (i.e. web browsing), that use the public CAs to establish a trust path to this unknown entity.

[Janfred]

This is a suggestion to include the feedback from the interim.
Wordsmithing welcome, I'm not completely satisfied with the wording.
Leaving the second should in lowercase was intended. This sentence is just information and not normative.

[jimdigriz]

I like the second part as is, it is helpful in explaining why someone should not just blindly leap and lean pre-trusting the web forum certs (which I probably would have done myself as an implementer), so my bike shedding suggestion is really only for the first part:

"If this model is implemented, RADIUS/(D)TLS peers SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer that are enabled by default. Instead, the peers SHOULD begin untrusted (ie. an empty CA list) and the process of trusting a given CA SHOULD be a manually step performed by an administrator.

This does not preclude vendors or manufactures including trust lists in their products, but the enabling of those lists should be a conscious decision by an administrator."

[Janfred]

I don't like the "should begin untrusted". The peers themselves are not untrusted, they are just untrusting (so to speak).
And shouldn't it be "should be a manual step performed by ..." or "manually performed step"?

[ethan-thompson]

I think a hybrid of the two for the "first chunk" would be good:

"If this model is implemented, RADIUS/(D)TLS peers SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer that are enabled by default. Instead, the peers SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.

This does not preclude vendors or manufactures including trust lists in their products, but the enabling of those lists should be a conscious decision by an administrator."

As for the "second chunk", I would change the wording slightly to something like:

"The goal of RADIUS/(D)TLS is to communicate securely with only a small set of well-known peers.

These peers will use specific certificates, potentially from a private, purpose-specific CA.

This scenario is different from the common use case of PKIX, where the goal is to communicate securely with unknown remote entities (e.g., web browsing) that use public CAs to bootstrap trust."

Though, I'm not in love with saying "specific certificates" since I think that could be a little vague or confusing.