Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 21, 2019, at 7:39 PM, Dan Harkins wrote: > I think we have made progress and closure. No. The word "unverifiable" is not a magic wan that you can use to win any argument. Your description of what I'm proposing does not match what I'm actually proposing. 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
On 11/20/19 8:07 AM, Alan DeKok wrote: On Nov 20, 2019, at 9:58 AM, Dan Harkins wrote: The use-case of the document is that an individual is issued a client certificate. That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store. The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use. Since it's selected a client cert, it can also verify the certificate chain back to the root. [snip] I've never seen a client check it's own certificate chain during authentication. Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing. Above you refer to a client checking its own certificate in order to find an appropriate one to use for an SSID. And now this is the use case you claim is ludicrous. EXACTLY! Asking a CA to certify something that is ambiguous and unverifiable in order to use it yourself is ludicrous. I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used. As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify: Yea, and that's why I gave you the list of actions a client takes and asked you to point out where in the list this happens. You deleted the list. Yes. Because I gave an explanation of how it works. I want to be sure that the explanation is understood before going into further details. If my explanation makes no sense, then there's no point in me discussing technical details. It doesn't make sense because it's too late. You can't use unverifiable information in a certificate you have not yet obtained in order to make a network connection decision. So this unverifiable and ambiguous nonsense you want to put in a certificate is for a client certificate and that use case is, as you note, ludicrous. I'm not proposing to prevent you from doing anything. I'm asking what's the point and why. You didn't really provide one. And good luck getting a public CA to put ambiguous and unverifiable information in a certificate for you. I've already addressed these points. Please see my previous messages. I think this horse has been beaten to death. I don't see any point in continuing it, unless there is progress. I think we have made progress and closure. The use case for unverifiable and ambiguous nonsense in a certificate is ludicrous. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 20, 2019, at 9:58 AM, Dan Harkins wrote: >> The use-case of the document is that an individual is issued a client >> certificate. That certificate contains an OID about the expected use-case >> (EAPoL), and also a list of SSIDs used to perform EAP. When a client system >> is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees >> with SSIDs in it's certificate store. The client system can then select an >> appropriate authentication method (EAP versus WPA-PSK), and also a client >> certificate to use. Since it's selected a client cert, it can also verify >> the certificate chain back to the root. > > So you asked for imprecise, ambiguous, and unverified information to be put > in your own certificate for you to use later. Just because something is in an > RFC doesn't make it right. And appeal to RFC is another form of appeal to > authority fallacy. You asked how it worked. I pointed you to the RFC. You now claim I *can't* refer to the RFC, because it's an appeal to authority. To recap: appeals to authority are logical fallacies where someone says "I'm right because of this authority". I'm not saying that. I'm saying that some people find it *useful*. I'm pointing to the RFC as evidence that people find it useful. I'm pointing to the RFC as an explanation of how it works. I think some of this back and forth could have been avoided with a careful reading of the RFC. > Oh, and what's the point of verifying the chain of your own certificate > prior > to connecting to a network? Do you do OCSP responses to see if your > certificate > has been revoked? I had hoped my explanation was unclear. I guess not. The point was that when a client connects, it can check the *server* certificate chain back to the *same* CA which was used to issue the client cert. I've never seen a client check it's own certificate chain during authentication. Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing. >> I would *also* argue that this information can be placed in a server >> certificate, for situations when client certificates are not being used. As >> discussed extensively previously on this list, a client can connect to an >> SSID, obtain the server cert, and then verify: > > Yea, and that's why I gave you the list of actions a client takes and asked > you to point out where in the list this happens. You deleted the list. Yes. Because I gave an explanation of how it works. I want to be sure that the explanation is understood before going into further details. If my explanation makes no sense, then there's no point in me discussing technical details. >> a) the server cert is intended for EAPoL (and is not just a cert taken from >> a web server) >> b) the SSIDs in the cert match the SSID used to authenticate >> c) the NAIRealm in the cert matches a user identifier stored in the client >> system >> >> In which case the client has *more* information than what is available to >> it today, and can thus make better decisions about whether or not to accept >> the cert. > > If the information is ambiguous and unverified why would you use it in a > decision > to accept a certificate or not? Well we're going in circles. I've given explanations. You reject them whole-sale, and keep asking me for more explanations. > I'm not proposing to prevent you from doing anything. I'm asking what's the > point > and why. You didn't really provide one. And good luck getting a public CA to > put > ambiguous and unverifiable information in a certificate for you. I've already addressed these points. Please see my previous messages. I think this horse has been beaten to death. I don't see any point in continuing it, unless there is progress. 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
On 11/20/19 4:11 AM, Alan DeKok wrote: On Nov 20, 2019, at 5:23 AM, Dan Harkins wrote: I am asking for ambiguous data to be certified and placed in my certificate for my own use? If this attribute is in a certificate I receive then what does it mean to "select the correct certificate for authentication in a particular WLAN"? The text explains this in detail. I'll summarize. The use-case of the document is that an individual is issued a client certificate. That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store. The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use. Since it's selected a client cert, it can also verify the certificate chain back to the root. So you asked for imprecise, ambiguous, and unverified information to be put in your own certificate for you to use later. Just because something is in an RFC doesn't make it right. And appeal to RFC is another form of appeal to authority fallacy. Oh, and what's the point of verifying the chain of your own certificate prior to connecting to a network? Do you do OCSP responses to see if your certificate has been revoked? I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used. As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify: Yea, and that's why I gave you the list of actions a client takes and asked you to point out where in the list this happens. You deleted the list. a) the server cert is intended for EAPoL (and is not just a cert taken from a web server) b) the SSIDs in the cert match the SSID used to authenticate c) the NAIRealm in the cert matches a user identifier stored in the client system In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert. If the information is ambiguous and unverified why would you use it in a decision to accept a certificate or not? This attribute seems useless to me and its ambiguity and therefore unverifiability is a large reason why. I would suggest not using it for your own purposes then. I would also suggest allowing *others* to use it, if they find it useful. I'm not proposing to prevent you from doing anything. I'm asking what's the point and why. You didn't really provide one. And good luck getting a public CA to put ambiguous and unverifiable information in a certificate for you. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 20, 2019, at 5:23 AM, Dan Harkins wrote: >> See RFC 4334 and its discussion of SSIDs. > > Is this _my_ certificate that has this attribute in it or is it in a > certificate I receive? The Introduction of RFC 4334 says: Automated selection of client certificates for use with PPP and IEEE 802.1X is highly desirable. Which seems clear. > If it's my certificate then what is the point of putting it in my certificate? See the text in the document, which explains this in detail. > I am asking for > ambiguous data to be certified and placed in my certificate for my own use? > If this attribute > is in a certificate I receive then what does it mean to "select the correct > certificate for > authentication in a particular WLAN"? The text explains this in detail. I'll summarize. The use-case of the document is that an individual is issued a client certificate. That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store. The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use. Since it's selected a client cert, it can also verify the certificate chain back to the root. I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used. As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify: a) the server cert is intended for EAPoL (and is not just a cert taken from a web server) b) the SSIDs in the cert match the SSID used to authenticate c) the NAIRealm in the cert matches a user identifier stored in the client system In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert. > This attribute seems useless to me and its ambiguity and therefore > unverifiability is a > large reason why. I would suggest not using it for your own purposes then. I would also suggest allowing *others* to use it, if they find it useful. 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
On 11/19/19 4:17 AM, Alan DeKok wrote: On Nov 18, 2019, at 7:39 PM, Dan Harkins wrote: [snip] Then what you can infer from a domain name in a certificate issued by such a CA is that the holder of the corresponding private key controls that domain. Nothing more, nothing less. But you can't infer anything from other attributes that have not been validated (again, using a word you used yourself) Certificates contain serial numbers. They haven't been validated by a CA. The lack of validation therefore means that you can't infer anything from that field? I would argue that you *can* make inferences from that field. What do you mean that certificate serial numbers haven't been validated by the CA? They originate from the CA. They are, by definition, a valid statement from the CA. The same applies for telephone numbers. Do CAs call the numbers? Do they check that the person answering is the same person who made the request? Maybe. You tell me if a CA "calls the numbers". If it doesn't then what can you infer from a telephone number in a certificate it signs? This isn't difficult. It means that the certificate owner has claimed he can be reached at that number. And the CA has signed the statement, agreeing that it's a statement made by the certificate owner. These issues can't be answered with simple black & white statements. If the data in a certificate is imperfect, it might still be useful. OK, convince me of its utility. See RFC 4334 and its discussion of SSIDs. Is this _my_ certificate that has this attribute in it or is it in a certificate I receive? If it's my certificate then what is the point of putting it in my certificate? I am asking for ambiguous data to be certified and placed in my certificate for my own use? If this attribute is in a certificate I receive then what does it mean to "select the correct certificate for authentication in a particular WLAN"?Fit this check into the network connection process: 1. service discovery 2. 802.11 authentication 3. 802.11 association 4. EAP-ID req/resp 5. EAP authentication Which numbered step is this attribute used in and how? This attribute seems useless to me and its ambiguity and therefore unverifiability is a large reason why. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 18, 2019, at 7:39 PM, Dan Harkins wrote: >> What happens if the CA checks some things, and not others? > > Then it means the CA is certifying things it shouldn't. Well, that's what happens with most CA's. >> Define "validation" :) > > I'll pass on playing that game. We have a good "feel" for what validation means in casual conversation. We're less clear what it means as a *process*. How does a CA validate a field? The answer is too often "it validates the field", which seems a bit circular. My point is that validation isn't black and white. There are various kinds of validation, each of which give you different kinds of information. My goal is to understand what those are, and to find out how we can use that information. Your position seems to be "it's either perfectly validated or perfectly useless". >> My point for SSIDs is that validation means whatever we define it to mean. >> So long as everyone agrees that the SSID field is a hint and is not >> validated by the CA, it's OK to use it. > > Use it how? What value do you put in an attribute that hasn't been > validated (and > don't ask me what that word means since you used it)? RFC 4334 describes this in some detail. See section 3 for discussion on SSIDs. >> In addition, CAs currently validate *control* of a domain. But they don't >> (and can't) really validate *ownership* as such. i.e. if I own a company, I >> can tell an employee to ask a CA for certificates for that domain. He may >> be making that request, even if he doesn't "own" the domain. He can >> convince the CA that he controls the domain. I'm not sure how the CA would >> check that the owner of the domain has properly delegated the certificate >> request to the employee. > > Then what you can infer from a domain name in a certificate issued by such > a CA > is that the holder of the corresponding private key controls that domain. > Nothing > more, nothing less. But you can't infer anything from other attributes that > have not > been validated (again, using a word you used yourself) Certificates contain serial numbers. They haven't been validated by a CA. The lack of validation therefore means that you can't infer anything from that field? I would argue that you *can* make inferences from that field. >> The same applies for telephone numbers. Do CAs call the numbers? Do they >> check that the person answering is the same person who made the request? >> Maybe. > > You tell me if a CA "calls the numbers". If it doesn't then what can you > infer > from a telephone number in a certificate it signs? This isn't difficult. It means that the certificate owner has claimed he can be reached at that number. And the CA has signed the statement, agreeing that it's a statement made by the certificate owner. >> These issues can't be answered with simple black & white statements. If >> the data in a certificate is imperfect, it might still be useful. > > OK, convince me of its utility. See RFC 4334 and its discussion of SSIDs. 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
On 11/18/19 3:42 PM, Alan DeKok wrote: On Nov 18, 2019, at 6:22 PM, Dan Harkins wrote: On 11/12/19 3:40 PM, Alan DeKok wrote: On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: How does a public CA prove ownership of an SSID? Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? Do public CAs verify that email addresses in the certificate work? Do public CAs verify that the OIDs in the certificate match the intended use-cases? Is there a global registry of SSIDs which the public CA could use to verify the SSID? I'm taking these as rhetorical questions with an implied "no". If that is not the correct way of taking them then please let me know. The implication is that many of them are "no". Some are "yes". Some *should* be "yes", and are in practice often "no". So the issue is, if the CA does not check any of these things then you cannot trust them in the certificate. What happens if the CA checks some things, and not others? Then it means the CA is certifying things it shouldn't. The reason you trust the contents of a certificate is because you trust the CA has done the appropriate due diligence to validate the stuff it is certifying. If a CA doesn't do the due diligence on any of the above stuff and still issues a certificate containing that stuff then I would question the integrity of the CA and probably not trust other things it is certifying. In other words, I'd probably remove that CA's cert from my TADB. That's up to you. Let me put it another way. There is no reason to trust a CA that does not perform due diligence on the things it certifies. Convince me otherwise. To put it another way, I'm not sure why this question is being posed. Here's one: Why would you trust an attribute that was not validated? Define "validation" :) I'll pass on playing that game. If the certificate contains an NAIRealm OID, then I know how the CA should validate it: check that the realm matches the domain. For SSIDs, since there's no registry, it's not possible to "validate" it against a registry. So "validation" here means... what, exactly? My point for SSIDs is that validation means whatever we define it to mean. So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it. Use it how? What value do you put in an attribute that hasn't been validated (and don't ask me what that word means since you used it)? In addition, CAs currently validate *control* of a domain. But they don't (and can't) really validate *ownership* as such. i.e. if I own a company, I can tell an employee to ask a CA for certificates for that domain. He may be making that request, even if he doesn't "own" the domain. He can convince the CA that he controls the domain. I'm not sure how the CA would check that the owner of the domain has properly delegated the certificate request to the employee. Then what you can infer from a domain name in a certificate issued by such a CA is that the holder of the corresponding private key controls that domain. Nothing more, nothing less. But you can't infer anything from other attributes that have not been validated (again, using a word you used yourself) The same applies for telephone numbers. Do CAs call the numbers? Do they check that the person answering is the same person who made the request? Maybe. You tell me if a CA "calls the numbers". If it doesn't then what can you infer from a telephone number in a certificate it signs? These issues can't be answered with simple black & white statements. If the data in a certificate is imperfect, it might still be useful. OK, convince me of its utility. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 18, 2019, at 6:22 PM, Dan Harkins wrote: > > On 11/12/19 3:40 PM, Alan DeKok wrote: >> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: >>> How does a public CA prove ownership of an SSID? >> Do public CAs *always* verify addresses and/or telephone numbers, which >> are normally included in certificates? >> >> Do public CAs verify that email addresses in the certificate work? >> >> Do public CAs verify that the OIDs in the certificate match the intended >> use-cases? >> >> Is there a global registry of SSIDs which the public CA could use to >> verify the SSID? > > I'm taking these as rhetorical questions with an implied "no". If that is > not the correct way of taking them then please let me know. The implication is that many of them are "no". Some are "yes". Some *should* be "yes", and are in practice often "no". > So the issue is, if the CA does not check any of these things then you > cannot > trust them in the certificate. What happens if the CA checks some things, and not others? > The reason you trust the contents of a certificate > is because you trust the CA has done the appropriate due diligence to validate > the stuff it is certifying. If a CA doesn't do the due diligence on any of the > above stuff and still issues a certificate containing that stuff then I would > question the integrity of the CA and probably not trust other things it is > certifying. In other words, I'd probably remove that CA's cert from my TADB. That's up to you. >> To put it another way, I'm not sure why this question is being posed. > > Here's one: Why would you trust an attribute that was not validated? Define "validation" :) If the certificate contains an NAIRealm OID, then I know how the CA should validate it: check that the realm matches the domain. For SSIDs, since there's no registry, it's not possible to "validate" it against a registry. So "validation" here means... what, exactly? My point for SSIDs is that validation means whatever we define it to mean. So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it. In addition, CAs currently validate *control* of a domain. But they don't (and can't) really validate *ownership* as such. i.e. if I own a company, I can tell an employee to ask a CA for certificates for that domain. He may be making that request, even if he doesn't "own" the domain. He can convince the CA that he controls the domain. I'm not sure how the CA would check that the owner of the domain has properly delegated the certificate request to the employee. The same applies for telephone numbers. Do CAs call the numbers? Do they check that the person answering is the same person who made the request? Maybe. These issues can't be answered with simple black & white statements. If the data in a certificate is imperfect, it might still be useful. 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
Hi Alan, On 11/12/19 3:40 PM, Alan DeKok wrote: On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: How does a public CA prove ownership of an SSID? Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? Do public CAs verify that email addresses in the certificate work? Do public CAs verify that the OIDs in the certificate match the intended use-cases? Is there a global registry of SSIDs which the public CA could use to verify the SSID? I'm taking these as rhetorical questions with an implied "no". If that is not the correct way of taking them then please let me know. So the issue is, if the CA does not check any of these things then you cannot trust them in the certificate. The reason you trust the contents of a certificate is because you trust the CA has done the appropriate due diligence to validate the stuff it is certifying. If a CA doesn't do the due diligence on any of the above stuff and still issues a certificate containing that stuff then I would question the integrity of the CA and probably not trust other things it is certifying. In other words, I'd probably remove that CA's cert from my TADB. To put it another way, I'm not sure why this question is being posed. Here's one: Why would you trust an attribute that was not validated? Dan. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
-Original Message- From: Alan DeKok Sent: 16 November 2019 14:29 To: Owen Friel (ofriel) Cc: Jan-Frederik Rieckers ; emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) wrote: > [ofriel] this seems like something reasonable, but that's more a general > deployment recommendation: ensure that the identity/realm of EAP servers is > different from the identity/domain of webservers within an org. Therefore in > the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert, clients > can still distinguish between the two. Users point their Browser clients > point to 'example.org' and wi-fi supplications are configured to look for > 'radius.exampe.org'. > > The supplicant logic for verifying EAP server identity (assuming it already > knows the root CA and a realm/domain string) could be check for NAIRealm > first, then check for id-kp-eapOverLAN, then check for a dnsName. There is currently no document which offers guidance for implementors. There's just common practice, and various standards. Which are unfortunately different. Even worse, it's not clear how these practices interact, or how we should migrate from existing practice to using the standards. I think it would be useful for this WG to have a document which gives these guidelines. [ofriel] Happy to help put a strawman for that together, along with some recommendations for the other PSK ambiguity. Aln DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) wrote: > [ofriel] this seems like something reasonable, but that's more a general > deployment recommendation: ensure that the identity/realm of EAP servers is > different from the identity/domain of webservers within an org. Therefore in > the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert, clients > can still distinguish between the two. Users point their Browser clients > point to 'example.org' and wi-fi supplications are configured to look for > 'radius.exampe.org'. > > The supplicant logic for verifying EAP server identity (assuming it already > knows the root CA and a realm/domain string) could be check for NAIRealm > first, then check for id-kp-eapOverLAN, then check for a dnsName. There is currently no document which offers guidance for implementors. There's just common practice, and various standards. Which are unfortunately different. Even worse, it's not clear how these practices interact, or how we should migrate from existing practice to using the standards. I think it would be useful for this WG to have a document which gives these guidelines. Aln DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
The CA/Browser forum has concrete guidelines on address, email, domain
verification outlined here.
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf
All public CAs should follow these, or face blacklisting. CAs don’t want to
risk being the next Symantec.
" 3.2.2.1. Identity
If the Subject Identity Information is to include the name or address of an
organization, the CA SHALL verify the identity and address of the organization
and that the address is the Applicant’s address of existence or operation. The
CA SHALL verify the identity and address of the Applicant using documentation
provided by, or through communication with, at least one of the following:
1. A government agency in the jurisdiction of the Applicant’s legal creation,
existence, or recognition;
2. A third party database that is periodically updated and considered a
Reliable Data Source;
3. A site visit by the CA or a third party who is acting as an agent for the
CA; or
4. An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4
above to verify both the Applicant’s identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the
identity of the Applicant) using a utility bill, bank statement, credit card
statement, government-issued tax document, or other form of identification that
the CA determines to be reliable. "
" 3.2.2.3. Verification of Country
If the subject:countryName field is present, then the CA SHALL verify the
country associated with the Subject using one of the following: (a) the IP
Address range assignment by country for either (i) the web site’s IP address,
as indicated by the DNS record for the web site or (ii) the Applicant’s IP
address; (b) the ccTLD of the requested Domain Name; (c) information provided
by the Domain Name Registrar; or (d) a method identified in Section 3.2.2.1.
The CA SHOULD implement a process to screen proxy servers in order to prevent
reliance upon IP addresses assigned in countries other than where the Applicant
is actually located. "
There is also a bunch of stuff in there about emails including:
" 3.2.2.4.4 Constructed Email to Domain Contact
Confirm the Applicant's control over the FQDN by (i) sending an email to one or
more addresses created by using 'admin', 'administrator', 'webmaster',
'hostmaster', or 'postmaster' as the local part, followed by the at-sign ("@"),
followed by an Authorization Domain Name, (ii) including a Random Value in the
email, and (iii) receiving a confirming response utilizing the Random Value. "
-Original Message-
From: Emu On Behalf Of Michael Richardson
Sent: 13 November 2019 23:27
To: emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 2019-11-13 7:40 a.m., Alan DeKok wrote:
> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote:
>> How does a public CA prove ownership of an SSID?
> Do public CAs *always* verify addresses and/or telephone numbers, which are
> normally included in certificates?
They are? I've rarely seen it.
I think that if it's in the certificate, then they have verified them.
I can remember in the bad old days providing CAs with notorized articles of
incorporation, etc.
I haven't done that this decade though, and I haven't seen that kind of info.
CAs won't include anything they can't verify.
> Do public CAs verify that email addresses in the certificate work?
yes, they do by sending a challenge to it.
> Do public CAs verify that the OIDs in the certificate match the intended
> use-cases?
Most won't include OIDs.
> Is there a global registry of SSIDs which the public CA could use to verify
> the SSID?
No, SSIDs are a local matter.
One could (and I do), use FQDNs as the SSID.
That's the only way I can see this working.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
-Original Message- From: Emu On Behalf Of Alan DeKok Sent: 12 November 2019 16:32 To: Jan-Frederik Rieckers Cc: emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS > > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). They're also domain names, not realms. A particular certificate may be valid for authenticating uses to the realm "example.org". That same certificate may not be valid for the main web site for "example.org". This means that domain names are a hint, but not authoritative. Only the NAIRealm field would be authoritative. i.e. "this certificate really is for users authenticating to a realm". > There would be the possibility to define a specific prefix to bind it > to a Realm without having the certificate being valid for the HTTPS > host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. A common short-hand is for certificates to use the "radius" subdomain. e.g. "radius.example.org". While not perfect, it's something. [ofriel] this seems like something reasonable, but that's more a general deployment recommendation: ensure that the identity/realm of EAP servers is different from the identity/domain of webservers within an org. Therefore in the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert, clients can still distinguish between the two. Users point their Browser clients point to 'example.org' and wi-fi supplications are configured to look for 'radius.exampe.org'. The supplicant logic for verifying EAP server identity (assuming it already knows the root CA and a realm/domain string) could be check for NAIRealm first, then check for id-kp-eapOverLAN, then check for a dnsName. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
-Original Message-
From: Emu On Behalf Of Michael Richardson
Sent: 12 November 2019 09:20
To: emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote:
> This is also related to ongoing anima discussions about RFC 8366, and how it
> can bootstrap trust when the pinned domain cert is a public PKI CA, and not a
> private CA, and hence additional domain (or realm or FQDN) info is also
> needed in order for the peer to verify the identity of the server.
While I'm familiar with this conversation, which I'm right now inspired to call
the the "Maria" problem ("How do solve a problem like Maria. How do you a
cloud certificate and pin it down?")
I don't really understand what it has to do with the problem of an EAP client,
**which is not doing initial onboarding**, to validate a certificate that it
has received as part of EAP-TLS*.
[ofriel] whether its first time bootstrap or subsequent EAP authentication, the
EAP server is going to present the same identity cert to the client, and that
could be signed by a public CA, and in both scenarios (bootstrap and
reauthenticate) the client needs to know what identity to look for in the
server cert.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 2019-11-14 7:59 p.m., Alan DeKok wrote: > On Nov 13, 2019, at 6:23 PM, Michael Richardson wrote: >> I think that the issue isn't, can we find or define a OID that has the >> right semantics. >> I think that the issue whether or not any public CAs are willing to >> include that into a certificate. > That's less relevant than it may be. > > The common practice for years has been to recommend self-signed or > "internal" CAs. The original reason was that supplicants didn't do > certificate pinning. So if they were configured to trust a root CA, they > would send user credentials to *any* EAP authentication server which had a > certificate signed by that CA. With certificate pinning, they now warn if > the server certificate changes. > > The other reason is that supplicant configuration is still largely a manual > process. If admins need a complex process to configure the supplicant, then > adding a self-signed CA to the mix has near-zero cost. And supplicant > vendors seem entirely disinterested in a standard way to configure them. I understand. If the authentication server is manually configured, then it matters not in the last what OIDs might be in the certificate. We believe that TEAP-BRSKI (or BRSKI-WIFI) will result in supplicants being configured during an automated process. This would involve getting the organizational root CA, and it could pin the authentication server certificate, or it could pin just a DN, TBD. The OIDs might be be useful that point, but I would generally find them not interesting. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 13, 2019, at 6:23 PM, Michael Richardson wrote: > > I think that the issue isn't, can we find or define a OID that has the > right semantics. > I think that the issue whether or not any public CAs are willing to > include that into a certificate. That's less relevant than it may be. The common practice for years has been to recommend self-signed or "internal" CAs. The original reason was that supplicants didn't do certificate pinning. So if they were configured to trust a root CA, they would send user credentials to *any* EAP authentication server which had a certificate signed by that CA. With certificate pinning, they now warn if the server certificate changes. The other reason is that supplicant configuration is still largely a manual process. If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has near-zero cost. And supplicant vendors seem entirely disinterested in a standard way to configure them. The other benefit of self-signed CAs is that they're free. No verification is required. Since the admin controls both the CA and the end user machine, he's free to do whatever he wants, when he wants. As to why self-signed CAs are appealing, here's an example. I've had "interesting" times trying to renew a simple certificate for HTTPS usage. The CA was happy to take my money and "verify" ownership of a domain. But they were entirely uninterested in sending me an actual certificate. Their support system was similarly unhelpful. In the end, I went with a simpler approach. And I can't be the only person that this happened too. The gating issue for me is supplicants. It's easy to update Open Source supplicants to check new OIDs. The larger vendors might upgrade. Eventually. Maybe. On a technical front, a major issue is also *how* to upgrade. What do supplicants do? Allow both OIDs? When do they start rejecting certificates with the "TLS web server" OIDs? 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
On 2019-11-13 7:40 a.m., Alan DeKok wrote: > On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: >> How does a public CA prove ownership of an SSID? > Do public CAs *always* verify addresses and/or telephone numbers, which are > normally included in certificates? They are? I've rarely seen it. I think that if it's in the certificate, then they have verified them. I can remember in the bad old days providing CAs with notorized articles of incorporation, etc. I haven't done that this decade though, and I haven't seen that kind of info. CAs won't include anything they can't verify. > Do public CAs verify that email addresses in the certificate work? yes, they do by sending a challenge to it. > Do public CAs verify that the OIDs in the certificate match the intended > use-cases? Most won't include OIDs. > Is there a global registry of SSIDs which the public CA could use to verify > the SSID? No, SSIDs are a local matter. One could (and I do), use FQDNs as the SSID. That's the only way I can see this working. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 2019-11-13 4:07 a.m., Alan DeKok wrote: > On Nov 12, 2019, at 11:43 AM, Russ Housley wrote: >> Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve >> this for you? It is defined in RFC 4334. A certificate for Web PKI should >> not include this extended key usage. >> >> RFC 4334 also offers a certificate extension that lists the SSIDs that are >> associated with the server. > That does sound relevant. I wasn't even aware of that document. > > While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone > using it. Even Microsoft supplicants still require the TLS web server auth > OID (1.3.6.1.5.5.7.3.1). I think that the issue isn't, can we find or define a OID that has the right semantics. I think that the issue whether or not any public CAs are willing to include that into a certificate. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
There has been some discussion about this idea. I don't have any experience in IETF work yet, so I don't know how this discussion can go on. I would be happy to present my deployment experiences from eduroam and the basic idea in Singapore. (Since I won't attend the meeting in person, I would join from remote) Is there room for that? Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 12, 2019, at 6:59 PM, Cappalli, Tim (Aruba) wrote: > > Regardless of validation levels, it is not possible to own an ESSID. It is > possible, however, to own a domain, email address, physical address, etc. > That's the difference. I think that's largely begging the question. Your comment seems to be that it's OK for a certificate to include incorrect a physical address, because that address is "owned" by someone. Even if the owner of that address knows nothing about the certificate request. I don't see how that's useful. Which is why I asked about validation. If the CA doesn't validate addresses, why should it validate SSIDs? Even worse, the CAs verify *control* of domain names. They don't verify *ownership* of the domain name. They're not quite the same thing. Is the person requesting the certificate the "owner" of the domain name? If not, is the certificate request authorized by the owner? None of this is checked by CAs right now. > Putting an ESSID in a certificate is a slippery slope. I doubt any public CA > or OS vendor would ever entertain this. Both are well known to do "surprising" things with certificates. I'm not sure why they would care about additional fields in a certificate. My point is that we have loose rules around the subjects of "ownership" and "validation". Simplistic statements are easy to make, but aren't particularly helpful. In my view, if something is useful, practical and can be shown to be not harmful, then I think it can be used. Putting SSIDs into a certificate seems useful, and (at least) the PKIX WG seemed to have agreed. Further, RFC 4334 in fact contains no text about "ownership" of the SSID. i.e. inclusion of an SSID in a certificate is *not* a statement about "ownership" of that SSID. So your comments seem to be against an issue that doesn't exist. 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
Regardless of validation levels, it is not possible to own an ESSID. It is possible, however, to own a domain, email address, physical address, etc. That's the difference. Putting an ESSID in a certificate is a slippery slope. I doubt any public CA or OS vendor would ever entertain this. Tim From: Alan DeKok Sent: Tuesday, November 12, 2019 18:40 To: Cappalli, Tim (Aruba) Cc: Russ Housley; emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: > > How does a public CA prove ownership of an SSID? Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? Do public CAs verify that email addresses in the certificate work? Do public CAs verify that the OIDs in the certificate match the intended use-cases? Is there a global registry of SSIDs which the public CA could use to verify the SSID? To put it another way, I'm not sure why this question is being posed. 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
On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: > > How does a public CA prove ownership of an SSID? Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? Do public CAs verify that email addresses in the certificate work? Do public CAs verify that the OIDs in the certificate match the intended use-cases? Is there a global registry of SSIDs which the public CA could use to verify the SSID? To put it another way, I'm not sure why this question is being posed. 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
How does a public CA prove ownership of an SSID? From: Emu Date: Tuesday, November 12, 2019 at 3:08 PM To: Russ Housley Cc: emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 12, 2019, at 11:43 AM, Russ Housley wrote: > > Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve this > for you? It is defined in RFC 4334. A certificate for Web PKI should not > include this extended key usage. > > RFC 4334 also offers a certificate extension that lists the SSIDs that are > associated with the server. That does sound relevant. I wasn't even aware of that document. While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone using it. Even Microsoft supplicants still require the TLS web server auth OID (1.3.6.1.5.5.7.3.1). So yes, RFC 4334 is absolutely relevant here. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 12, 2019, at 11:43 AM, Russ Housley wrote: > > Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve this > for you? It is defined in RFC 4334. A certificate for Web PKI should not > include this extended key usage. > > RFC 4334 also offers a certificate extension that lists the SSIDs that are > associated with the server. That does sound relevant. I wasn't even aware of that document. While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone using it. Even Microsoft supplicants still require the TLS web server auth OID (1.3.6.1.5.5.7.3.1). So yes, RFC 4334 is absolutely relevant here. 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
> On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers > wrote: > > Signed PGP part > On 12.11.19 00:15, Owen Friel (ofriel) wrote: >> One deployment consideration is if an operator wants to use a public PKI >> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, >> before these extensions could be supported (as Alan alludes to), so it would >> also be good to define how this could work with standard RFC 6125 DNS-IDs / >> RFC 5280 dNSNames. > > I had a lot of thoughts about this topic. > I am experimenting with certificates in EAP-TLS contexts and experienced > the problems with getting a certificate with specific extension > properties from our public PKI. (In my case a test certificate with a > critical MustStaple extension) > > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). There would be the possibility to define a specific > prefix to bind it to a Realm without having the certificate being valid > for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. > > My deployment experience shows, that the certificate check is the main > security problem in WPA2-Enterprise networks. I have seen instructions > for installing WPA2-Enterprise networks where they have explicitly > suggested switching off the certificate check, probably because it was > too complicated for the users and would lead to people complaining at > the IT department about the complicated setup. > > A setup of WPA2-Enterprise can be secure if all devices are part of a > centralized Device Management, but especially in eduroam this isn't > possible. We have a lot of people who don't really care about security. Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve this for you? It is defined in RFC 4334. A certificate for Web PKI should not include this extended key usage. RFC 4334 also offers a certificate extension that lists the SSIDs that are associated with the server. Russ signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers wrote: > > Signed PGP part > On 12.11.19 00:15, Owen Friel (ofriel) wrote: >> One deployment consideration is if an operator wants to use a public PKI >> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, >> before these extensions could be supported (as Alan alludes to), so it would >> also be good to define how this could work with standard RFC 6125 DNS-IDs / >> RFC 5280 dNSNames. > > I had a lot of thoughts about this topic. > I am experimenting with certificates in EAP-TLS contexts and experienced > the problems with getting a certificate with specific extension > properties from our public PKI. (In my case a test certificate with a > critical MustStaple extension) > > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). They're also domain names, not realms. A particular certificate may be valid for authenticating uses to the realm "example.org". That same certificate may not be valid for the main web site for "example.org". This means that domain names are a hint, but not authoritative. Only the NAIRealm field would be authoritative. i.e. "this certificate really is for users authenticating to a realm". > There would be the possibility to define a specific > prefix to bind it to a Realm without having the certificate being valid > for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. A common short-hand is for certificates to use the "radius" subdomain. e.g. "radius.example.org". While not perfect, it's something. > My deployment experience shows, that the certificate check is the main > security problem in WPA2-Enterprise networks. I have seen instructions > for installing WPA2-Enterprise networks where they have explicitly > suggested switching off the certificate check, probably because it was > too complicated for the users and would lead to people complaining at > the IT department about the complicated setup. Exactly. > A setup of WPA2-Enterprise can be secure if all devices are part of a > centralized Device Management, but especially in eduroam this isn't > possible. We have a lot of people who don't really care about security. What's worse is that there's no cross-platform way to set up 802.1X. It would be nice if a user could visit an HTTPS secured web site for example.com, and then download a supplicant configuration. Stefan Winter has a draft: https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 But it received little support from vendors. Security should be simple, and it should be the default. Users don't care about security because it's hard, and because it too often prevents them from getting things done. If security is useful, they will use it. 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
On 12.11.19 10:28, Michael Richardson wrote: > You were trying to do a CSR with some extra attributes with a CA (using > ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't > verify? No, it was a direct request to the CA of our research network. The problem here was, that the CA itself would have had to clarify this with their CA (Telekom Trust Center), because it would mean to set up a new certificate profile. And that wasn't possible for this one usecase. > So, as I understand it, the enrollment process for laptops/phones into > WPA-Enterprise does not include retrieving a set of anchors for that > connection. Or that it is just too hard to do. It works fine if the > devices are compelled by their corporate masters, but this fails for > BYOD, and it fails for cross-realm (which eduroam is). It doesn't. In eduroam this has lead to cat.eduroam.org, where the installers can be downloaded. As Carsten Borman and I already have written in a submission for the IAB DEDR workshop[1], with the need of this tool we also could have used client certificates instead of username/password combinations. For a long time it was easy to connect to eduroam without certificate checking. Especially Android had a very insecure default setting and most of our users just typed in their username and password and connected to eduroam without any certificate check. And if the inner authentication then defaults to PAP an attacker could get many credentials just by setting up a rogue access point in a crowded place. And many universities in Germany use PAP because they don't want a NT-Hashed password in their database. With the expiry of the old Root CA all clients had to change their configuration, because (if set up correctly) the root ca was in fact pinned. We used this rollover to force all our users to use a specific outer identity, to encourage the use of the CAT. Since the expiry we also deny all requests with any other outer identity before the EAP-TLS handshake, to prevent certificate warnings on the user devices. Jan-Frederik --- 1: https://www.iab.org/wp-content/IAB-uploads/2019/05/p16-bormann-wifi.txt signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 2019-11-12 3:53 p.m., Jan-Frederik Rieckers wrote: > On 12.11.19 00:15, Owen Friel (ofriel) wrote: >> One deployment consideration is if an operator wants to use a public PKI >> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, >> before these extensions could be supported (as Alan alludes to), so it would >> also be good to define how this could work with standard RFC 6125 DNS-IDs / >> RFC 5280 dNSNames. > I had a lot of thoughts about this topic. > I am experimenting with certificates in EAP-TLS contexts and experienced > the problems with getting a certificate with specific extension > properties from our public PKI. (In my case a test certificate with a > critical MustStaple extension) You were trying to do a CSR with some extra attributes with a CA (using ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't verify? > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). There would be the possibility to define a specific > prefix to bind it to a Realm without having the certificate being valid > for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. I think you are saying that the problem with dNSNames is that web servers use them/pay-attention to them, so CAs are careful what they put in. That's a reason to avoid that SAN in my opinion. Toerless, in draft-ietf-anima-autonomic-control-plane went the other direction, and argued that only dNSNames have good interoperability, and so we have to use only them. > My deployment experience shows, that the certificate check is the main > security problem in WPA2-Enterprise networks. I have seen instructions > for installing WPA2-Enterprise networks where they have explicitly > suggested switching off the certificate check, probably because it was > too complicated for the users and would lead to people complaining at > the IT department about the complicated setup. So, as I understand it, the enrollment process for laptops/phones into WPA-Enterprise does not include retrieving a set of anchors for that connection. Or that it is just too hard to do. It works fine if the devices are compelled by their corporate masters, but this fails for BYOD, and it fails for cross-realm (which eduroam is). signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote:
> This is also related to ongoing anima discussions about RFC 8366, and how it
> can bootstrap trust when the pinned domain cert is a public PKI CA, and not a
> private CA, and hence additional domain (or realm or FQDN) info is also
> needed in order for the peer to verify the identity of the server.
While I'm familiar with this conversation, which I'm right now inspired
to call the the "Maria" problem
("How do solve a problem like Maria. How do you a cloud certificate and
pin it down?")
I don't really understand what it has to do with the problem of an EAP
client, **which is not doing initial onboarding**, to validate a
certificate that it has received as part of EAP-TLS*.
> Its also relevant for ongoing Wi-Fi Alliance DPP discussions about
> bootstrapping a supplicant onto an 802.1X network - after a supplicant
> completes DPP and gets provisioned with a trust anchor - what if that trust
> anchor is a public PKI? It’s the same problem.
I agree that this is the Maria problem, because the client has to pin
*a* CA and a SubjectDN (specifically a dnsName SubjectAltName), and you
want to allow the server to change public CAs.
>> -Original Message-
>> From: Emu On Behalf Of Jan-Frederik Rieckers
>>
>> Thank you for your feedback.
>>
>> I was unaware of RFC 7585. I had a brief look on it and it seems that the
>> certificate part could be used for the goal I try to achieve.
>>
>> I'm not quite sure if the naiRealm should be used for validation on
>> supplicants
>> for EAP-TLS. I would assume it would not be a security issue, but I don't
>> have
>> enough experience to be sure about that.
>>
>> The main reason why I submitted this draft is my experience from the
>> deployment of eduroam at University Bremen.
>> With expiry of the used root CA and the needed migration, we have forced all
>> our users to use one specific outer Identity, to be sure the users configure
>> their
>> devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org)
>> instead of a manual configuration, because in our experience manual
>> configured
>> devices almost always lacked configuration for certificate checking.
>> But I just have experience in local deployment, the federation connections
>> are
>> done at higher levels (country research networks), I don't have an insight
>> there.
I skimmed your document before and I didn't understand it based upon my
quick read. Your text here helps me a bit.
In eduroam, the supplicant sees the TLSServerCertificate of the local
institution's Authentication Server, correct?
Is it not the case that for this to be validated that there needs to be
a path to the eduroam's root certificate,
which the client would have pinned?
You need to set the NAI correctly, because we have essentially an
SNI-like issue, in that the Authentication Server
needs to answer with it's eduroam certificate for eduroam clients, and
it might use a different certificate for other clients?
As I understand it, your ran into an issue because the root certificate
expired, and clients had pinned it, but they could find a new
certificate in DNS?
signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On 12.11.19 00:15, Owen Friel (ofriel) wrote: > One deployment consideration is if an operator wants to use a public PKI > (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, > before these extensions could be supported (as Alan alludes to), so it would > also be good to define how this could work with standard RFC 6125 DNS-IDs / > RFC 5280 dNSNames. I had a lot of thoughts about this topic. I am experimenting with certificates in EAP-TLS contexts and experienced the problems with getting a certificate with specific extension properties from our public PKI. (In my case a test certificate with a critical MustStaple extension) The Problem with dNSNames is that they are also used in other contexts (mainly HTTPS). There would be the possibility to define a specific prefix to bind it to a Realm without having the certificate being valid for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm uni-bremen.de) but I don't see the advantage in that. This will probably don't really lead to a change in the supplicants implementations. My deployment experience shows, that the certificate check is the main security problem in WPA2-Enterprise networks. I have seen instructions for installing WPA2-Enterprise networks where they have explicitly suggested switching off the certificate check, probably because it was too complicated for the users and would lead to people complaining at the IT department about the complicated setup. A setup of WPA2-Enterprise can be secure if all devices are part of a centralized Device Management, but especially in eduroam this isn't possible. We have a lot of people who don't really care about security. Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 11, 2019, at 6:15 PM, Owen Friel (ofriel) wrote: > > This is also related to ongoing anima discussions about RFC 8366, and how it > can bootstrap trust when the pinned domain cert is a public PKI CA, and not a > private CA, and hence additional domain (or realm or FQDN) info is also > needed in order for the peer to verify the identity of the server. > > Its also relevant for ongoing Wi-Fi Alliance DPP discussions about > bootstrapping a supplicant onto an 802.1X network - after a supplicant > completes DPP and gets provisioned with a trust anchor - what if that trust > anchor is a public PKI? It’s the same problem. > > One deployment consideration is if an operator wants to use a public PKI > (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, > before these extensions could be supported (as Alan alludes to), so it would > also be good to define how this could work with standard RFC 6125 DNS-IDs / > RFC 5280 dNSNames. That sounds reasonable. Certificates for 802.1X authentication already use DNS names. It's not wide-spread, but it's not rare. There's no *meaning* to these names, as nothing checks them. It would be useful to suggest how a supplicant can use these fields to further verify a server certificate. And for servers, what these fields should contain. 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
This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (or realm or FQDN) info is also needed in order for the peer to verify the identity of the server. Its also relevant for ongoing Wi-Fi Alliance DPP discussions about bootstrapping a supplicant onto an 802.1X network - after a supplicant completes DPP and gets provisioned with a trust anchor - what if that trust anchor is a public PKI? It’s the same problem. One deployment consideration is if an operator wants to use a public PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, before these extensions could be supported (as Alan alludes to), so it would also be good to define how this could work with standard RFC 6125 DNS-IDs / RFC 5280 dNSNames. > -Original Message- > From: Emu On Behalf Of Jan-Frederik Rieckers > Sent: 11 November 2019 09:42 > To: Alan DeKok ; Russ Housley > > Cc: emu@ietf.org > Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS > > Hi, > Thank you for your feedback. > > I was unaware of RFC 7585. I had a brief look on it and it seems that the > certificate part could be used for the goal I try to achieve. > > I'm not quite sure if the naiRealm should be used for validation on > supplicants > for EAP-TLS. I would assume it would not be a security issue, but I don't have > enough experience to be sure about that. > > The main reason why I submitted this draft is my experience from the > deployment of eduroam at University Bremen. > With expiry of the used root CA and the needed migration, we have forced all > our users to use one specific outer Identity, to be sure the users configure > their > devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org) > instead of a manual configuration, because in our experience manual configured > devices almost always lacked configuration for certificate checking. > But I just have experience in local deployment, the federation connections are > done at higher levels (country research networks), I don't have an insight > there. > > Greetings, > Jan-Frederik Rieckers ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
Hi, Thank you for your feedback. I was unaware of RFC 7585. I had a brief look on it and it seems that the certificate part could be used for the goal I try to achieve. I'm not quite sure if the naiRealm should be used for validation on supplicants for EAP-TLS. I would assume it would not be a security issue, but I don't have enough experience to be sure about that. The main reason why I submitted this draft is my experience from the deployment of eduroam at University Bremen. With expiry of the used root CA and the needed migration, we have forced all our users to use one specific outer Identity, to be sure the users configure their devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org) instead of a manual configuration, because in our experience manual configured devices almost always lacked configuration for certificate checking. But I just have experience in local deployment, the federation connections are done at higher levels (country research networks), I don't have an insight there. Greetings, Jan-Frederik Rieckers signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
On Nov 10, 2019, at 11:16 AM, Russ Housley wrote: > Thanks for the overview. It was very helpful. Glad to help. > 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. I agree. TBH, I like this proposal for securing EAP-TLS. It may take time to deploy, but adding more clarity to certificates is always useful. I'd be in favour of WG adoption of a document based on this. FWIW, a configuration file that creates certificates with the NAIRealm is located here: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/certs/server.cnf 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
Alan: > > 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. 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
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
