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

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 8 Jan 2007 12:00:35 -0800

Hi Bernard,

I'm not sure I understand some of the text below:

<snip>
>    The peer MUST verify the validity of the EAP server 
> certificate, and
>    SHOULD also examine the Server-id in order to determine whether the
>    EAP server can be trusted.  Even though a server certificate chains
>    to a trust anchor, this does not necessarily imply that it is valid
>    for connection to a particular network.
> 
>    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.  

>    The peer MAY also 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."
> 
> --------------------------------------------------------------
> -----------------------------------------
> >From: <[email-masked]>
> >To: <[email-masked]>, <[email-masked]>
> >Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
> >Date: Wed, 13 Dec 2006 09:52:13 +0200
> >
> >Thanks for handling my comments so quickly! (If every author 
> had this 
> >fast turnaround times, IETF would get documents to RFCs in a 
> fraction 
> >of current time... :-)
> >
> >About 1: the figure in 2.6 is not quite right yet. There should be a 
> >finished message after the first change_cipher_spec sent by 
> the server, 
> >and the certificate/server_key_exchange messages after the second 
> >server_hello are not optional.
> >
> >About 2: I'd further suggest rephrasing the last two paragraphs of
> >2.1.1 along these lines (basic case first, session 
> resumption second):
> >
> >    If the peer supports EAP-TLS and is configured to use it, it MUST
> >    respond to the EAP-Request with an EAP-Response packet of EAP-
> >    Type=EAP-TLS.  If the preceding server_hello message sent by the
> >    EAP server in the preceeding EAP-Request packet did not indicate
> >    the resumption of a previous session, the data field of 
> this packet
> >    MUST encapsulate one or more TLS records containing a TLS
> >    client_key_exchange, change_cipher_spec and finished 
> messages.  If
> >    the EAP server sent a certificate_request message in the 
> preceding
> >    EAP-Request packet, then unless the peer is configured 
> for privacy
> >    (see Section 2.6) the peer MUST send, in addition, 
> certificate and
> >    certificate_verify messages.  The former contains a 
> certificate for
> >    the peer's signature public key, while the latter contains the
> >    peer's signed authentication response to the EAP server.  After
> >    receiving this packet, the EAP server will verify the peer's
> >    certificate and digital signature, if requested.
> >
> >    If the preceding server_hello message sent by the EAP 
> server in the
> >    preceding EAP-Request packet indicated the resumption of 
> a previous
> >    session, then the peer MUST send only the change_cipher_spec and
> >    finished handshake messages.  The finished message contains the
> >    peer's authentication response to the EAP server.
> >
> >(And maybe Section 2.6 could be moved to 2.1.4?)
> >
> >About 7: This one is not there yet.
> >
> >About 9: The document still doesn't specify 
> mandatory-to-implement TLS 
> >version (which is required in addition to 
> mandatory-to-implement cipher 
> >suite to get interoperability).
> >
> >About 11: The S bit was removed from the bit diagram, but 
> the text "The 
> >S bit (EAP-TLS start) is set in an EAP-TLS Start message" is still 
> >there.
> >
> >Best regards,
> >Pasi
> >
> > > -----Original Message-----
> > > From: ext Bernard Aboba [mailto:[email-masked]]
> > > Sent: 13 December, 2006 01:55
> > > To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> > > Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
> > >
> > > I think I have now incorporated most of these comments into a 
> > > strawman -06 document:
> > > 
> http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt
> > >
> > > Let me know if I've missed something.
> >
> >_______________________________________________
> >Emu mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 Jan 2007 19:41:07 -0800

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

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.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 9 Jan 2007 12:20:42 -0800

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