Alan: > > On Nov 9, 2019, at 1:00 PM, Russ Housley <hous...@vigilsec.com> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
