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

["Bernard Aboba" <bernard_aboba at hotmail.com>]

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

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.

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

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

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."



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