Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 14, 2021, at 1:29 PM, Tim Cappalli  wrote:
> 
> The equivalent to HTTPS with EAP would be if the ESSID was a subject name in 
> the certificate and ESSIDs could be registered and validated. That doesn't 
> exist today and wouldn't ever really work (or scale). The closest thing to it 
> is server certificates for Passpoint OSU, which have their own issues and 
> aren't feasible for most deployments.

  Configuring known ESSIDs is good, but I'm not sure how they're relevant for 
security.

  At a high level, if the certificates are OK, then TLS protects you from 
whatever is going on in the underlying transport layer.

  Having "known SSIDs" only matters for subsequent traffic flow, I think.  At 
that point, channel bindings (RFC 6677) become more useful.

> Given the significant changes required in both EAP clients and EAP servers 
> for TLS 1.3, I think the time is appropriate for making the server 
> certificate requirements more strict. This is likely the last chance for a 
> long time.

  I strongly suspect that there's no consensus here, and this really isn't the 
document to do it in.  The issues are much larger than for just EAP-TLS.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Tim Cappalli]

The equivalent to HTTPS with EAP would be if the ESSID was a subject name in 
the certificate and ESSIDs could be registered and validated. That doesn't 
exist today and wouldn't ever really work (or scale). The closest thing to it 
is server certificates for Passpoint OSU, which have their own issues and 
aren't feasible for most deployments.

Given the significant changes required in both EAP clients and EAP servers for 
TLS 1.3, I think the time is appropriate for making the server certificate 
requirements more strict. This is likely the last chance for a long time.

tim

From: Alan DeKok 
Sent: Wednesday, April 14, 2021 13:21
To: Tim Cappalli 
Cc: mcr+i...@sandelman.ca ; emu@ietf.org 
Subject: Re: [Emu] Issue 47 Certificate identity checks

On Apr 14, 2021, at 10:56 AM, Tim Cappalli  wrote:
>
> Honestly, no information in an EAP server certificate is good enough for a 
> user to make a "walk up" informed decision.

  I'm curious how this is different from say, HTTPS.  The use-cases seem pretty 
similar.

> At least requiring an EAP-specific EKU or OID would require operating systems 
> to separate out the EAP trust store.

  I agree 100% there.

> TLS Web Server Certificate should not be acceptable for EAP.

  Well, yes.  The question is how do we get there from here.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 14, 2021, at 10:56 AM, Tim Cappalli  wrote:
> 
> Honestly, no information in an EAP server certificate is good enough for a 
> user to make a "walk up" informed decision.

  I'm curious how this is different from say, HTTPS.  The use-cases seem pretty 
similar.

> At least requiring an EAP-specific EKU or OID would require operating systems 
> to separate out the EAP trust store.

  I agree 100% there.

> TLS Web Server Certificate should not be acceptable for EAP.

  Well, yes.  The question is how do we get there from here.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Tim Cappalli]

Honestly, no information in an EAP server certificate is good enough for a user 
to make a "walk up" informed decision. If the supplicant is not properly 
pre-configured, all bets are off. TOFU is not acceptable.

At least requiring an EAP-specific EKU or OID would require operating systems 
to separate out the EAP trust store.

TLS Web Server Certificate should not be acceptable for EAP.

tim

From: Emu  on behalf of Alan DeKok 

Sent: Wednesday, April 14, 2021 07:23
To: Michael Richardson 
Cc: EMU WG 
Subject: Re: [Emu] Issue 47 Certificate identity checks

On Apr 13, 2021, at 8:17 PM, Michael Richardson  wrote:
> Why did you need the HTTPS server cert?
> Did you need the OIDs, and stuff out of it?  Why wasn't the realm name enough
> to make the imposter cert from the non-authorized CA?
>
> I'm just trying to understand how the HTTPS cert is involved here.

  The HTTPS cert contains a wealth of information which makes it look "real" to 
the average person.  All of that information can be cloned into the imposter 
cert.  So the only differences between the imposter cert and real one are (a) 
signing CA, and (b) key data that most people don't understand.

  What any mere mortal looking at the imposter cert will see "Yup, it has the 
right addresses, phone numbers, names, etc.".  For all intents and purposes, it 
appears to be real.

  This imposter process worked better years ago when supplicants would show the 
entire cert to the user.  Now, many don't even do that.  Some just show a 
fingerprint in a pop-up dialog, and ask the user "is this OK?".

  How that's useful to anyone is beyond me.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=04%7C01%7Ctim.cappalli%40microsoft.com%7C03fdb74ac18749ebdc6608d8ff37c2da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539962261663872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=boROVAFgSky1v93Iu1jzrthBVbvAhNgKa5TVZ9h0zQA%3Dreserved=0
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 13, 2021, at 8:17 PM, Michael Richardson  wrote:
> Why did you need the HTTPS server cert?
> Did you need the OIDs, and stuff out of it?  Why wasn't the realm name enough
> to make the imposter cert from the non-authorized CA?
> 
> I'm just trying to understand how the HTTPS cert is involved here.

  The HTTPS cert contains a wealth of information which makes it look "real" to 
the average person.  All of that information can be cloned into the imposter 
cert.  So the only differences between the imposter cert and real one are (a) 
signing CA, and (b) key data that most people don't understand.

  What any mere mortal looking at the imposter cert will see "Yup, it has the 
right addresses, phone numbers, names, etc.".  For all intents and purposes, it 
appears to be real.

  This imposter process worked better years ago when supplicants would show the 
entire cert to the user.  Now, many don't even do that.  Some just show a 
fingerprint in a pop-up dialog, and ask the user "is this OK?".

  How that's useful to anyone is beyond me.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Michael Richardson]

Alan DeKok  wrote:
> One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years
> ago.  It would pretend to be a WiFI hotspot.  Then when systems tried
> to do EAP, it would strip the realm from the EAP identity.  It would
> then, use HTTPS to connect to a web server for that realm, and download
> that HTTPS server cert.  That cert would then be cloned under a new
> "self signed" CA, and the cloned cert presented to the user.

Why did you need the HTTPS server cert?
Did you need the OIDs, and stuff out of it?  Why wasn't the realm name enough
to make the imposter cert from the non-authorized CA?

I'm just trying to understand how the HTTPS cert is involved here.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Eliot Lear]

> On 12 Apr 2021, at 18:25, Joseph Salowey  > wrote:
> 
>> 
>>  I would agure there that the federation should have it's own CA.
> 
> That’s what I’m thinking.  But I could imagine hardcoded devices that make 
> use of it.  That’s all.
> 
> 
> [Joe] Relying on a burned in certificate this way seems like a really bad 
> idea.  What happens when that certificate expires?
> 

Separate the cert from the cert selection.  Don’t burn the cert in, but imagine 
a device that communicates out of the box with a federation service.  This is 
already done at higher layers.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 12, 2021, at 2:15 PM, Tim Cappalli  wrote:
> 
> Pinning the server certificate is unrealistic. A properly configured 
> supplicant with a trusted private root and subject match is adequate and 
> allows good security hygiene with server cert rotation.

  While I agree, many customers don't.  The only way to convince them otherwise 
is to present a "fait accompli" that all of the vendors now forbid this 
behaviour.

> I believe the id-kp-eapOverLAN EKU should be a MUST.

  I think we can't use it.  It's defined for client certs.  We don't want 
client certs to pretend to be server certs.  Using id-kp-eapOverLAN for both 
will allow this.

> Public CAs should not be issuing server certificates for EAP in the first 
> place. I feel like this debate comes up every few years. Any public CA-signed 
> TLS web server certificate that is used for EAP can be requested to be 
> revoked for misuse.

  Replace EAP with EAP, SMTPS, XMPP, etc.

  i.e. any protocol using TLS.

  There was a long thread about this on EMU a year ago.  Maybe it is the case 
that certificate authorities MUST revoke such mis-used certs.  If so, I could 
write a script which would scan the net, find such certs, and report them.  I 
suspect that it could take down 10% to 25% of TLS-enabled services.

  Is this a good idea?  Probably not.

  Is it possible?  According to multiple people, yes.

  What should we do about it?  I don't know.

  But my $0.02 is that if it is true, then we should admit that the real-world 
use-cases for certs don't match how certificate authorities work.  We should 
then likely change the definition of "id-kp-serverAuth" to mean "any 
TLS-enabled service", instead of "TLS WWW servers".

> If an organization cannot ensure proper configuration of a supplicant, they 
> should not be using EAP.

  Or, they should rely on experts to ensure that systems can't be configured 
incorrectly.  This is where the IETF has spent two decades not addressing these 
use-cases.

  Given the time frame for the EAP-TLS document, I suspect it's best to just 
say "here be dragons", and leave it at that.  Any attempt to define new 
behavior may be time consuming.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Tim Cappalli]

Pinning the server certificate is unrealistic. A properly configured supplicant 
with a trusted private root and subject match is adequate and allows good 
security hygiene with server cert rotation.

I believe the id-kp-eapOverLAN EKU should be a MUST. Public CAs should not be 
issuing server certificates for EAP in the first place. I feel like this debate 
comes up every few years. Any public CA-signed TLS web server certificate that 
is used for EAP can be requested to be revoked for misuse.

If an organization cannot ensure proper configuration of a supplicant, they 
should not be using EAP.

tim

From: Emu  on behalf of Eliot Lear 

Sent: Monday, April 12, 2021 14:07
To: Alan DeKok 
Cc: EMU WG 
Subject: Re: [Emu] Issue 47 Certificate identity checks



> On 12 Apr 2021, at 19:54, Alan DeKok  wrote:
>
> On Apr 12, 2021, at 12:22 PM, Joseph Salowey  wrote:
>> [Joe]  without some sort of name matching using certs from a public CA is 
>> unwise.
>
>  The only other alternative is to "pin" the server cert.  Many systems 
> support this.  Perhaps mentioning [Trust On] First Use (TOFU) would help here.
>

That won’t work for headless wireless.

Yes, we have kicked that hornet’s nest.  I hope everyone is wearing appropriate 
netting.

Eliot

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Eliot Lear]

> On 12 Apr 2021, at 19:54, Alan DeKok  wrote:
> 
> On Apr 12, 2021, at 12:22 PM, Joseph Salowey  wrote:
>> [Joe]  without some sort of name matching using certs from a public CA is 
>> unwise.
> 
>  The only other alternative is to "pin" the server cert.  Many systems 
> support this.  Perhaps mentioning [Trust On] First Use (TOFU) would help here.
> 

That won’t work for headless wireless.

Yes, we have kicked that hornet’s nest.  I hope everyone is wearing appropriate 
netting.

Eliot



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 12, 2021, at 12:22 PM, Joseph Salowey  wrote:
> [Joe]  without some sort of name matching using certs from a public CA is 
> unwise.  

  The only other alternative is to "pin" the server cert.  Many systems support 
this.  Perhaps mentioning Time of First Use (TOFU) would help here.

  i.e. if the peer pins both the CA and the server cert, then the contents of 
the server cert matter less.  All that matters is that the peer detects if/when 
the server cert changes.

  If we rely on names, then which one?  There are many fields in a certificate 
which could be used.

>   After looking into this in some depth, the only real thing you can depend 
> on is the CA.  If the CA is trusted, nothing else matters.  If the CA is not 
> trusted, then nothing else matters.
> 
> [Joe] In this case we would have to rule out CAs that are not under the 
> organizations control (public CAs)

  Only if the peer doesn't notice if the server cert changes.

  I think it's safe to recommend that clients pin both the server cert and the 
CA cert.  Anything else is "there be dragons".

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Joseph Salowey]

On Mon, Apr 12, 2021 at 6:02 AM Eliot Lear  wrote:

> Hi Alan,
>
> On 12 Apr 2021, at 14:52, Alan DeKok  wrote:
>
>
> EAP TLS peer implementations MUST allow for configuration of a unique
> trust root to validate the server's certificate.
>
>
> This statement seems independent of the previous one, and may be overly
> broad.  Let me give you an example: a device may be designed only to
> operate as part of a federation.
>
>
>  I would agure there that the federation should have it's own CA.
>
>
> That’s what I’m thinking.  But I could imagine hardcoded devices that make
> use of it.  That’s all.
>
>
[Joe] Relying on a burned in certificate this way seems like a really bad
idea.  What happens when that certificate expires?


> Eliot
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Joseph Salowey]

On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok 
wrote:

> On Apr 11, 2021, at 11:19 PM, Joseph Salowey  wrote:
> > RFC 5216 lacks guidance on how to validate the EAP server's certificate
> especially with respect to identities.
>
>   Yes.  :)
>
> > RFC 5216 recommends validating the certificate path is valid and that
> the extended key usage attributes are either not present, allow for any
> usage or allow for TLS server usage.   This creates an issue that if the
> same truest root is used for EAP TLS and for other TLS server usage that
> any TLS server will be able to extend its privilege and behave as an EAP
> server.   The following recommendations are made for implementations and
> deployments to avoid this problem.
>
>   One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years
> ago.  It would pretend to be a WiFI hotspot.  Then when systems tried to do
> EAP, it would strip the realm from the EAP identity.  It would then, use
> HTTPS to connect to a web server for that realm, and download that HTTPS
> server cert.  That cert would then be cloned under a new "self signed" CA,
> and the cloned cert presented to the user.
>
>   The only real difference between the "real" and "fake" certs was the
> root CA / trust anchor.
>
>   So yes, this is a real issue.  Even in a trusted environment, a web
> server admin can set up a WiFi hotspot using the HTTPS server cert.  This
> seems wrong.
>
> > 1. EAP TLS Peer implementations SHOULD allow for configuration of names
> to match against SANs of type DNS name that are authorized to act as
> EAP-TLS servers.
>
>   Given the above attacks, I'm not sure that this helps.
>
>
[Joe] You would need to use the name matching in conjunction with
validation to a trusted root.


> > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN
> EKU specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for
> the configuration to require the id-kp-eapOverLAN EKU for validation of EAP
> server certificates.
>
>   That's good, but as discussed previously on this list, it's essentially
> impossible to get those certs from public CAs.  Claims of "just start your
> own public CA" notwithstanding, the only practical way to do it is with a
> private CA.
>
>
[Joe]  without some sort of name matching using certs from a public CA is
unwise.


> > 3. If the above options are not available then separate trust roots need
> to be used to issue certificates for EAP-TLS server and for TLS servers.
> EAP TLS peer implementations MUST allow for configuration of a unique trust
> root to validate the server's certificate.
> >
> > EAP-TLS peer implementations SHOULD provide ways to automate the
> configuration of the information necessary for the validation of the
> certificate.
>
>   After looking into this in some depth, the only real thing you can
> depend on is the CA.  If the CA is trusted, nothing else matters.  If the
> CA is not trusted, then nothing else matters.
>
> [Joe] In this case we would have to rule out CAs that are not under the
organizations control (public CAs)


>   i.e. for any kind of increased security you'd like to add to EAP-TLS,
> you can almost always find a scenario where that security forbids
> real-world use-cases we'd like to support

  Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 11, 2021, at 11:19 PM, Joseph Salowey  wrote:
> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU 
> specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the 
> configuration to require the id-kp-eapOverLAN EKU for validation of EAP 
> server certificates.  

  Just one final note on id-kp-eapOverLAN.

  RFC 3770 describes that as being used for client certs.  If we allow it for 
server certs, then how can we tell them apart?

  i.e. a client could take it's cert, set itself up as a WiFi hotspot, and no 
*other* client could tell the difference between the "fake" server cert, and a 
real one.

  As a result, it looks like id-kp-eapOverLAN is not appropriate for server 
certs.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Eliot Lear]

Hi Alan,

> On 12 Apr 2021, at 14:52, Alan DeKok  wrote:
> 
>>> 
>>> EAP TLS peer implementations MUST allow for configuration of a unique trust 
>>> root to validate the server's certificate.
>> 
>> This statement seems independent of the previous one, and may be overly 
>> broad.  Let me give you an example: a device may be designed only to operate 
>> as part of a federation.
> 
>  I would agure there that the federation should have it's own CA.

That’s what I’m thinking.  But I could imagine hardcoded devices that make use 
of it.  That’s all.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 12, 2021, at 3:54 AM, Eliot Lear  wrote:
> “EAP peers need to have some basis to decide which networks are authorized.  
> A key signal for this purpose is the validation of the server certificate.  
> To prevent use of the wrong server, the peer SHOULD have some means to select 
> and update appropriate trust anchors.  How this happens is beyond the scope 
> of this memo."

  Yes.

  Many existing systems won't allow users to select trust anchors.  Many 
existing systems won't even "pin" trust anchors.  If the root CA used by an 
EAP-TLS server changes, they might notify the user.  Or they might just send 
over the new credentials.  It's all really bad.

>> EAP TLS peer implementations MUST allow for configuration of a unique trust 
>> root to validate the server's certificate.
> 
> This statement seems independent of the previous one, and may be overly 
> broad.  Let me give you an example: a device may be designed only to operate 
> as part of a federation.

  I would agure there that the federation should have it's own CA. 

  I'm not sure what it means to have a federation where someone else controls 
who is a member of the federation.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Alan DeKok]

On Apr 11, 2021, at 11:19 PM, Joseph Salowey  wrote:
> RFC 5216 lacks guidance on how to validate the EAP server's certificate 
> especially with respect to identities.

  Yes.  :)

> RFC 5216 recommends validating the certificate path is valid and that the 
> extended key usage attributes are either not present, allow for any usage or 
> allow for TLS server usage.   This creates an issue that if the same truest 
> root is used for EAP TLS and for other TLS server usage that any TLS server 
> will be able to extend its privilege and behave as an EAP server.   The 
> following recommendations are made for implementations and deployments to 
> avoid this problem.

  One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years ago.  
It would pretend to be a WiFI hotspot.  Then when systems tried to do EAP, it 
would strip the realm from the EAP identity.  It would then, use HTTPS to 
connect to a web server for that realm, and download that HTTPS server cert.  
That cert would then be cloned under a new "self signed" CA, and the cloned 
cert presented to the user.

  The only real difference between the "real" and "fake" certs was the root CA 
/ trust anchor.

  So yes, this is a real issue.  Even in a trusted environment, a web server 
admin can set up a WiFi hotspot using the HTTPS server cert.  This seems wrong.

> 1. EAP TLS Peer implementations SHOULD allow for configuration of names to 
> match against SANs of type DNS name that are authorized to act as EAP-TLS 
> servers. 

  Given the above attacks, I'm not sure that this helps.

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU 
> specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the 
> configuration to require the id-kp-eapOverLAN EKU for validation of EAP 
> server certificates.  

  That's good, but as discussed previously on this list, it's essentially 
impossible to get those certs from public CAs.  Claims of "just start your own 
public CA" notwithstanding, the only practical way to do it is with a private 
CA.

> 3. If the above options are not available then separate trust roots need to 
> be used to issue certificates for EAP-TLS server and for TLS servers.  EAP 
> TLS peer implementations MUST allow for configuration of a unique trust root 
> to validate the server's certificate.  
> 
> EAP-TLS peer implementations SHOULD provide ways to automate the 
> configuration of the information necessary for the validation of the 
> certificate.  

  After looking into this in some depth, the only real thing you can depend on 
is the CA.  If the CA is trusted, nothing else matters.  If the CA is not 
trusted, then nothing else matters.

  i.e. for any kind of increased security you'd like to add to EAP-TLS, you can 
almost always find a scenario where that security forbids real-world use-cases 
we'd like to support.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue 47 Certificate identity checks

[Eliot Lear]

Hi Joe,

I’m okay with most of this text except for as follows:

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU 
> specified in RFC 3770.

The above sentence is unnecessary.  Of COURSE CAs can issue certs with that EKU 
or any other.  What I think you mean is this:

CAs issuing certificates intended for use by EAP servers SHOULD specify the 
id-kp-eapOverLAN EKU specified in RFC 3770.

[I am even tempted to say MUST, but I don’t think we ca go that far.]

[…]


>  3. If the above options are not available then separate trust roots need to 
> be used to issue certificates for EAP-TLS server and for TLS servers.

I don’t think this is sufficient.  Rather, I would discuss the logic behind it. 
 In particular, I would state quite clearly something along the following lines:

“EAP peers need to have some basis to decide which networks are authorized.  A 
key signal for this purpose is the validation of the server certificate.  To 
prevent use of the wrong server, the peer SHOULD have some means to select and 
update appropriate trust anchors.  How this happens is beyond the scope of this 
memo."


> EAP TLS peer implementations MUST allow for configuration of a unique trust 
> root to validate the server's certificate.

This statement seems independent of the previous one, and may be overly broad.  
Let me give you an example: a device may be designed only to operate as part of 
a federation.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Issue 47 Certificate identity checks

[Joseph Salowey]

Please review the following proposal and discuss it on this thread.

RFC 5216 lacks guidance on how to validate the EAP server's certificate
especially with respect to identities.

RFC 5216 recommends validating the certificate path is valid and that the
extended key usage attributes are either not present, allow for any usage
or allow for TLS server usage.   This creates an issue that if the same
truest root is used for EAP TLS and for other TLS server usage that any TLS
server will be able to extend its privilege and behave as an EAP server.
The following recommendations are made for implementations and
deployments to avoid this problem.

1. EAP TLS Peer implementations SHOULD allow for configuration of names to
match against SANs of type DNS name that are authorized to act as EAP-TLS
servers.

2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU
specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the
configuration to require the id-kp-eapOverLAN EKU for validation of EAP
server certificates.

3. If the above options are not available then separate trust roots need to
be used to issue certificates for EAP-TLS server and for TLS servers.  EAP
TLS peer implementations MUST allow for configuration of a unique trust
root to validate the server's certificate.

EAP-TLS peer implementations SHOULD provide ways to automate the
configuration of the information necessary for the validation of the
certificate.

Cheers,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu