Subject: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 16 Jan 2007 14:22:01 -0800

It seems that most of the issues brought up in last call are resolved or
nearly resolved in draft-simon-emu-rfc2716bis-06.txt.  The one area
where we need more discussion is section 5.2 on certificate usage.
Below are the remaining open issue I have tracked with this section,
please indicate if there are others with this section or other sections
that I have missed.  

1. Use of TLS-WWW EKU 

The question was raised that the TLS WWW EKU may not be appropriate for
EAP-TLS.  The suggestion was made to remove the text on EKU.  Are
members of the working group in favor of removing this text? 

2. Discussion of naming

This section recommends

"Where the subjectAltName field is present, the Peer-Id or Server-Id
is set to the contents of the subjectAltName.  If subject naming
information is present only in the subject field, then the Peer-Id or
Server-Id is set to the Distinguished Name (DN)." 

It is possible that more than one subjectAltName may be present in a
certificate.  Are there any rules as to how this is represented as a
Peer name?  Also would it be more consistent to use the DN unless it is
empty?  

3. Discussion of authorization

The later part of this section seems to discuss authorization.  A
suggestion for revised text was made in
http://www1.ietf.org/mail-archive/web/emu/current/msg00309.html.  Does
the suggested text convey the necessary information? 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Jan 2007 19:41:20 -0800

>members of the working group in favor of removing this text?

There are a number of EAP-TLS implementations that require TLS WWW EKUs (or 
any).  So in practice an implementation needs to understand that or it may 
not interoperate.  It also occurs to me that there could be some security 
issues that would surface.  For example, if there is no indication that an 
EAP-TLS server is authorized for that function (e.g. if it doesn't contain a 
TLS WWW server EKU or any), then any machine possessing an EAP-TLS client 
certificate chaining to a trust anchor could use that certiciate to act as 
an EAP-TLS server (assuming that the NASes were configured to trust it).  It 
seems like this could make it easier to put up a rogue NAS.

With respect to the RFC 4334 OIDs, I'm ok with removing mention of them.  
There are no existing implementations, and as a result, there should be no 
expectation that EAP-TLS clients or servers will understand these 
extensions.  It seems like these OIDs are problematic since they don't 
correspond to values of the NAS-Port-Type attribute, and therefore can't be 
compared to NAS-Port-Type values by implementations that don't understand 
them.

>Peer name?  Also would it be more consistent to use the DN unless it is

Can someone descirbe a case where there would be more than one 
subjectAltName in a certificate?
I'm having a hard time wrapping my head around this case.

>the suggested text convey the necessary information?

I'd suggest that the rest of the section include the following text (missing 
the RFC 4334 discussion):

"Once the endpoints of the EAP-TLS conversation have been authenticated
and have had their certificates validated they then must be authorized.
The authorization process makes use of the contents of the certificates
as well as other contextual information.  While authorization
requirements will vary from deployment to deployment it is RECOMMENDED
that implementations be able to authorize based on the EAP Peer and EAP
Server identities defined above.

Since authorization based on specific identities may not scale well in a
large environment implementations may make use of other fields in the
certificate.  For example an implementation may be configured to accept
all certificates issued by a CA with a certain name format as trusted.
In another example the peer may test whether the EAP server certificate
is signed by a CA controlling the destination network and whether the
Server-Id matches the format expected for that network.  For example, an
EAP peer connecting to the "EXAMPLE" SSID may check whether the
Server-Id matches the regular expression "*.example.com", in addition to
checking whether the server certificate chains to the example.com CA.
However, it is important to realize that any certificate matching the
above criteria will be authorized, so this method should only be used in
environments where this is guaranteed to be accurate."

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 17 Jan 2007 12:06:10 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, January 16, 2007 7:41 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt
> 
> >1. Use of TLS-WWW EKU
> >
> There are a number of EAP-TLS implementations that require 
> TLS WWW EKUs (or any).  So in practice an implementation 
> needs to understand that or it may not interoperate.  It also 
> occurs to me that there could be some security issues that 
> would surface.  For example, if there is no indication that 
> an EAP-TLS server is authorized for that function (e.g. if it 
> doesn't contain a TLS WWW server EKU or any), then any 
> machine possessing an EAP-TLS client certificate chaining to 
> a trust anchor could use that certiciate to act as an EAP-TLS 
> server (assuming that the NASes were configured to trust it). 
>  It seems like this could make it easier to put up a rogue NAS.
> 

[Joe] It also seems that there are the same type of security issues with
using the TLS WWW EKUs.  There are the same certificates that are issued
to web servers.   However the TLS WWW server EKU at least differentiates
between the server and client role.  How about including:

"Some deployments may require the presence of client and server
authentication extended key usage extensions in certificates.  Client
implementations wishing to interoperate in these environments SHOULD
check the server's certificate for an Extended Key Usage field
implementations id-kp-serverAuth (1.3.6.1.5.5.7.3.1) or the special
keyPurposeID anyExtendedKeyUsage.  Server implementations wishing to
interoperate in this environment SHOULD check the client's certificate
for an Extended Key Usage field containing id-kp-clientAuth
(1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage.
Note that these key usage extension identifiers for server and client
authentication are somewhat generic and may not be sufficient to
authorize an entity's role specifically as an EAP-TLS client or server."

> There are no existing implementations, and as a result, there 
> should be no expectation that EAP-TLS clients or servers will 
> understand these extensions.  It seems like these OIDs are 
> problematic since they don't correspond to values of the 
> NAS-Port-Type attribute, and therefore can't be compared to 
> NAS-Port-Type values by implementations that don't understand them.
> 
[Joe] OK 

> >2. Discussion of naming
> >
> >This section recommends
> >
> >"Where the subjectAltName field is present, the Peer-Id or 
> Server-Id is 
> >set to the contents of the subjectAltName.  If subject naming 
> Can someone descirbe a case where there would be more than 
> one subjectAltName in a certificate?
[Joe] The subjectAltName may contain a host name as DNSName and a
manufacturing serial number as an OtherName or perhaps it may contain a
UPN and a SIP URI. 

> I'd suggest that the rest of the section include the 
> following text (missing the RFC 4334 discussion):
> 
> "Once the endpoints of the EAP-TLS conversation have been 
> authenticated and have had their certificates validated they 
> then must be authorized.
> The authorization process makes use of the contents of the 
> certificates as well as other contextual information.  While 
> authorization requirements will vary from deployment to 
> deployment it is RECOMMENDED that implementations be able to 
> authorize based on the EAP Peer and EAP Server identities 
> defined above.
> 
> Since authorization based on specific identities may not 
> scale well in a large environment implementations may make 
> use of other fields in the certificate.  For example an 
> implementation may be configured to accept all certificates 
> issued by a CA with a certain name format as trusted.
> In another example the peer may test whether the EAP server 
> certificate is signed by a CA controlling the destination 
> network and whether the Server-Id matches the format expected 
> for that network.  For example, an EAP peer connecting to the 
> "EXAMPLE" SSID may check whether the Server-Id matches the 
> regular expression "*.example.com", in addition to checking 
> whether the server certificate chains to the example.com CA.
> However, it is important to realize that any certificate 
> matching the above criteria will be authorized, so this 
> method should only be used in environments where this is 
> guaranteed to be accurate."
> 

[Joe] OK

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 18 Jan 2007 23:02:09 -0800

On the EAP WG list, Lakshminath Dondeti has pointed out the problems with 
including a copy of the RFC 3766 Key Strength table in another document:

"Section 3.7 has a copy of the attack resistance table from RFC 3766.  It
is sufficient to provide a reference to that RFC.  There is no need to
reproduce the table in the eap-keying document.  In fact, if 3766 is
updated, the eap keying draft also needs to be updated; if 3766 is
simply referenced, the problem goes away."

This same argument can be made to remove the key strength table from RFC 
2716bis.  My recommendation is to change Note [3] in Section 5.1 to the 
following, removing the table:

   [3] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or
   DH module and DSA subgroup size in bits, for a given level of attack
   resistance in bits.  For example, a 2048-bit RSA key is recommended to 
provide
   128-bit equivalent key strength.  The National Institute for
   Standards and Technology (NIST) also offers advice on appropriate key
   sizes in [SP800-57].

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 19 Jan 2007 10:11:34 -0800

>How about including:

Looks good.

>manufacturing serial number as an OtherName or perhaps it may contain a

Any recommendations on what we should say about this?

---

From: Charles Clancy <[email-masked]>
Date: Sat, 20 Jan 2007 22:53:51 -0500

>> authorize an entity's role specifically as an EAP-TLS client or server."

What about RFC 4334?

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 21 Jan 2007 09:30:23 -0800

>What about RFC 4334?

As far as I know, no EAP-TLS implementation supports RFC 4334 and I don't 
think we should be encouraging implementers to support it.

The OIDs defined in RFC 4334 do not correspond to values of the 
NAS-Port-Type attribute, so the backend authentication server certificate 
handling code would need to be updated everytime a new value were to be 
assigned; the AAA server can't just check that the NAS-Port-Type attribute 
includes a value that matches one of the OIDs in the client certificate.  
Similarly, client code would need to be updated every time a new EAP lower 
layer was defined, since the client would need to check if the server 
certificate contained an OID allowing it to be used to authorize a given EAP 
lower layer.

As a result, I think that RFC 4334 compromises the ability of EAP-TLS to run 
over any suitable lower layer without code changes.

---

From: "Charles Clancy" <[email-masked]>
Date: Mon, 22 Jan 2007 12:14:44 -0500 (EST)

> certificate contained an OID allowing it to be used to authorize a given

So your objection is that essentially different lower layers have been
hard-coded into 4334 (PPP and EAPoL), and consequently into the cert
handling code, such that new RFCs and new code would be required to
support EAP over different L2/L3 technologies?

I can see that as an objection to the fundamental approach, and a reason
to possibly not support future EKUs for other lower layers, but not as a
reason to not support the currently-defined EKUs.  If implementers are
rev-ing their EAP-TLS code for 2716bis compliance, this would be a good
time to roll in these changes.

I'd think a statement like "When EAP-TLS is used with WLANs, support for
WLAN-specific EKUs [RFC 4334] is RECOMMENDED to improve certificiate-based
authorization of EAP clients and servers" would be appropriate.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 22 Jan 2007 15:01:28 -0800

>support EAP over different L2/L3 technologies?

The problem is that the RFC 4334 lower layer number space is not 
synchronized with the existing RADIUS NAS-Port-Type space.   On the server 
side, this means that a AAA server could not just compare the NAS-Port-Type 
attribute value with the OIDs in the cert;  it has to have a table mapping 
one to the other.  This would require addition of an OID mapping table to 
the AAA server.  So far, no servers have implemented this, and I suspect 
that they will not do so in the near future.

>time to roll in these changes.

If the approach is not good for the long-term, why should implementers be 
encouraged to embrace it?  This is likely to encourage further requests for 
allocation of RFC 4334 OIDs, creating interoperability problems where none 
existed previously.

>authorization of EAP clients and servers" would be appropriate.

RFC 4334 doesn't improve authorization of clients.  Today AAA servers can 
check the NAS-Port-Type attribute and send a Reject if the client is not 
authorized for that medium.  Adding lower layer OIDs to the client 
certificate will not provide more authorization functionality than we 
already have, but will add complexity.

In terms of server authorization, the benefit is unclear to me.  Assuming a 
server is authenticated and appears authorized along other dimensions 
(chains to a trust anchor, has an appropriate name), should a client reject 
it because it lacks the OIDs for the particular form of access involved?  
>From an architectural point of view, EAP-TLS implementations typically leave 
certificate selection to the TLS implementation.  RFC 4334 support could 
require changes to the certificate selection code.

Overall, given the lack of RFC 4334 implementation and the cost/benefit 
ratio going forward, it's probably best to let this "sleeping dog" RFC lie.

---

From: "Charles Clancy" <[email-masked]>
Date: Tue, 23 Jan 2007 01:24:39 -0500 (EST)

> In terms of server authorization, the benefit is unclear to me.  Assuming
> a server is authenticated and appears authorized along other dimensions
> (chains to a trust anchor, has an appropriate name), should a client
> reject it because it lacks the OIDs for the particular form of access
> involved?  From an architectural point of view, EAP-TLS implementations
> typically leave certificate selection to the TLS implementation.  RFC
> 4334 support could require changes to the certificate selection code.

I don't care about client authorization -- there should be server-side
ACLs for this.

I guess for EAP-TLS, server authorization isn't a huge deal.  If an
unauthorized server is giving you access to the network, what difference
does it make to a client?  The only compromise is maybe that of user
confidentiality.  What worries me are improperly authorized servers for
something like PEAP+MSCHAPv2, where a dictionary attack against a client's
password might be possible.

My biggest worry is that someone, for example, hacks a web server, steals
the key pair, fires up a rogue AP+AAA, and starts stealing client
passwords.  The user is never presented with a dialog box saying "by the
way, you're talking to CN=www.domain.net, not CN=aaa.domain.net".  Oh, and
be sure to check the CRL to see if it's been revoked or not.

I definitely understand the deployment issues.  I just wish there was some
way to fix this without client-side ACLs for server authorization.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 23 Jan 2007 07:51:05 -0800

>I don't care about client authorization -- there should be server-side ACLs 
>for this.

Right.

>passwords.

They wouldn't even have to steal the key pair.  All they'd have to do is 
start a modified RADIUS service and get a rogue AP to point to it.

>The user is never presented with a dialog box saying "by the

Typically the client will not check for a particular FQDN in the 
subjectAltName field in the server cert, only a pattern (e.g. *.domain.net). 
  CRL checking has to occur after the fact, unless the client already has 
connectivity; most implementations don't seem to do the checks at all.