Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 9, 2019, at 1:00 PM, Russ Housley 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. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
With a very quick skim, it appears that you are trying to do the same thing as RFC 7585. Russ > On Nov 9, 2019, at 12:33 PM, Jan-Frederik Rieckers > wrote: > > Signed PGP part > Hi to all, > > I have submitted a draft for a new X509v3 extension to improve security > in EAP environments by including information which is implicitly defined > by the communication context in the certificate . > This is done e.g. by including the Realm of the username in the > certificate, to give clients the opportunity to decide if the > certificate can be trusted apart from (user-set) configuration. > > https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/ > > This is a very early working state. I would be happy to get feedback if > this is useful and the draft goes into the right direction. > > If people are interested I would prepare a short presentation about > deployment experiences in the eduroam at the University Bremen, > which have lead to this draft, together with the basic idea how to solve > these problems. > > Probably this draft is not one which can or will be adopted by the EMU > working group, but I think this is the right group of people for a first > feedback. > > Kind regards > > Jan-Frederik Rieckers > > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Idea: New X509 Extension for securing EAP-TLS
Hi to all, I have submitted a draft for a new X509v3 extension to improve security in EAP environments by including information which is implicitly defined by the communication context in the certificate . This is done e.g. by including the Realm of the username in the certificate, to give clients the opportunity to decide if the certificate can be trusted apart from (user-set) configuration. https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/ This is a very early working state. I would be happy to get feedback if this is useful and the draft goes into the right direction. If people are interested I would prepare a short presentation about deployment experiences in the eduroam at the University Bremen, which have lead to this draft, together with the basic idea how to solve these problems. Probably this draft is not one which can or will be adopted by the EMU working group, but I think this is the right group of people for a first feedback. Kind regards Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
