RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Thanks for reviewing the changes. To fix the remaining issues, I've done another revision:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt

This includes:

1. Corrections to the example (hopefully correct this time). Also moved 2.6 to 2.1.4.
2. Rephrasing of the paragraphs as you suggested.
9. Added a statement on mandatory-to-implement TLS v1.0 to Section 2.4.
11. Removed mention of the 'S' bit from Section 3.2.
7. Changed Section 5.2 to the following:

"5.2.  Certificate Usage

  The EAP-TLS peer name (Peer-Id) represents the Network Access
  Identifier (NAI) [RFC4282] to be used for access control and
  accounting purposes.  The Server-Id represents the identity of the
  EAP server.

  In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
  or subjectAltName fields in the peer and server certificates.  As
  noted in [RFC3280] Section 4.1.2.6:

     The subject field identifies the entity associated with the public
     key stored in the subject public key field.  The subject name MAY
     be carried in the subject field and/or the subjectAltName
     extension...  If subject naming information is present only in the
     subjectAltName extension (e.g., a key bound only to an email
     address or URI), then the subject name MUST be an empty sequence
     and the subjectAltName extension MUST be critical.

     Where it is non-empty, the subject field MUST contain an X.500
     distinguished name (DN).

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

  A valid EAP-TLS client certificate SHOULD contain an Extended Key
  Usage field indicating support for Client Authentication
  (1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage.
  A valid EAP-TLS server certificate SHOULD contain an Extended Key
  Usage field indicating support for Server Authentication
  (1.3.6.1.5.5.7.3.1) or the special keyPurposeID anyExtendedKeyUsage.

  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.

  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.

  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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.