RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

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

> > >    Comparing the Server-Id in the certificate to the 
> expected server
> > >    name limits the damage that will result from an 
> attacker compromising
> > >    a server private key.  If the peer does not check the 
> Server-Id, then
> > >    the peer would accept a compromised server certificate 
> chaining to
> > >    any of the configured trust anchors.
> > >
> >
> >[Joe] If the server key is compromised then it seems checking the 
> >server-ID will not help discover this or limit damage.
> 
> Maybe this should have been "compromising a trust anchor 
> private key".  I think the idea was to prevent a compromise 
> of a trust anchor from enabling attackers to carry out "rogue 
> authenticator" attacks across the board.

[Joe] I don't think so, since a compromised trust anchor is a bigger
problem.  This text appears to mostly deal with authorization issues.
Here is a proposal for some modifications to the text:

In section 5.2, we may want to rethink the recommendation to use the TLS
WWW EKU, I'm not sure it is appropriate. Right now I suggest we remove
this paragraph. The text for the rest of the section could be replaced
by the following text. 

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

Certificate extensions for use with EAP-TLS are discussed in
"Certificate Extensions and Attributes Supporting Authentication in
Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)"
[RFC4334].  These extensions enable certificate usage to be restricted
to use with lower layers such as PPP or IEEE 802.11.  An EAP-TLS
implementation MAY make these and other certificate fields available to
the lower layer.

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