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

["Joseph Salowey \(jsalowey\)" <jsalowey at cisco.com>]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba at hotmail.com] 
> Sent: Tuesday, January 16, 2007 7:41 PM
> To: Joseph Salowey (jsalowey); emu at ietf.org
> Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt
> 
> >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?
> 
> 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."



> 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.
> 
[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 
> >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?
> 
> 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.
> 
[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. 

> >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.ht
> ml.  Does 
> >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."
> 

[Joe] OK

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu