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

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

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: <Pasi.Eronen at nokia.com>
> >To: <bernard_aboba at hotmail.com>, <emu at ietf.org>
> >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:bernard_aboba at hotmail.com]
> > > Sent: 13 December, 2006 01:55
> > > To: Eronen Pasi (Nokia-NRC/Helsinki); emu at ietf.org
> > > 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
> >Emu at ietf.org
> >https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

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