Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Russ Housley <[e-mail]>]

Alan:
> 
> On Nov 9, 2019, at 1:00 PM, Russ Housley <[e-mail]> wrote:
>> 
>> With a very quick skim, it appears that you are trying to do the same thing as RFC 7585.
> 
>  I think there's overlap, but it's not quite the same thing.
> 
>  Both proposals add a "known realm" as an X.509 certificate property.  They differ in their usage, and in who is checking the fields.  I'll quickly recap:
> 
>  RFC 7585 allows for RADIUS clients to dynamically discover RADIUS servers via DNS.  As a sanity check, the discovered RADIUS server should induce the "known realm" in its server certificate.  The RADIUS client verifies that the "known realm" field matches the domain it was looking for.  Note that this verification is done by a RADIUS client, and is independent of the authentication mechanism carried inside of RADIUS.  (PAP, CHAP, EAP, etc.)
> 
>  In this proposal, the supplicant is the component which is checking the "known realm" field.  The supplicant verifies that the NAI it's sending matches the "known realm" sent by the server.
> 
>  It is common practice today for server certificates to include a contact email address in the common name field.  However, there's no requirement that this is done.  No one checks the domain of that email address against the NAI being used by the supplicant.
> 
>  I think that this proposal may be useful.  Given that the parties who check this field do so for different purposes, it may be useful to have two separate OIDs.
> 
>  On the other hand, RCC 7585 uses the OID for TLS connections which then carry RADIUS packets.  This draft would use an OID for EAP-TLS authentications, which are carried inside of RADIUS, and then inside of UDP / TCP / TLS / DTLS.  The uses-cases may be different enough to warrant re-use of the same OID.

Thanks for the overview.  It was very helpful.

RFC 7586 define the NAIRealm as an otherName in the SubjectAltName of a certificate.  It seems that the NAIRealm name form works equally well, regardless of the role that the certificate holder is performing in the protocol.

Russ