From emu-bounces@ietf.org Thu Feb 01 12:55:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCg9I-0002jo-AG; Thu, 01 Feb 2007 12:55:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCg9H-0002jj-Iq for emu@ietf.org; Thu, 01 Feb 2007 12:55:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCg9F-0000kp-VO for emu@ietf.org; Thu, 01 Feb 2007 12:55:03 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2007 09:55:01 -0800 X-IronPort-AV: i="4.13,268,1167638400"; d="scan'208"; a="384785951:sNHT239990504" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l11HswqN027168; Thu, 1 Feb 2007 09:54:58 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l11Hsqnf000320; Thu, 1 Feb 2007 09:54:59 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:54:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Date: Thu, 1 Feb 2007 09:54:52 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt Thread-Index: Acc79USARgG0BvTdQ4eo+K/I/dVGmQKNCdAQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 01 Feb 2007 17:54:54.0176 (UTC) FILETIME=[14048600:01C7462A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1522; t=1170352498; x=1171216498; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Open=20issues=20with=20draft-simon-emu-rfc271 6bis-06.txt |Sender:=20; bh=0ibTgIldKAfMBfX2dMxBUgVBpigpDLk6TH6t37q5dUY=; b=fbVsNmFosCgqQLmJiCLZ6FropNTY7iTX6ln3tSN0GTY1PVeF2CwPHJ0/gaXkAXfhhYEOXHLT E2PTLlS6h+3GRWr2Z59yyhQWTnWOs++1GZjNIbRXq/QXvHoRBlNQfjLn; Authentication-Results: sj-dkim-8; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Friday, January 19, 2007 10:12 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt >=20 > > > Can someone descirbe a case where there would be more than one=20 > > > subjectAltName in a certificate? > > > I'm having a hard time wrapping my head around this case. > > > > >[Joe] The subjectAltName may contain a host name as DNSName and a=20 > >manufacturing serial number as an OtherName or perhaps it=20 > may contain a=20 > >UPN and a SIP URI. >=20 > Any recommendations on what we should say about this? >=20 [Joe] There is no one field in all certificate that unequivocally represents the "identity" for all EAP-TLS uses. =20 For the mapping of certificate fields to name: "If the peer's or server's certificate contains a non-empty subject name then it is the peer or server name respectively. If the subject name is empty then the peer name maps to a subjectAltName. Since the subjectAltName may contain more than one instance of subjectAltName an implementation should provide a means to choose which subjectAltName type is used. An implementation may also provide configuration controls to allow a particular subjectAltName type to override the subject name when present." I'm not sure that this maps sufficiently well to NAI as described in the opening sentence of the first paragraph. =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 01 15:35:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCidz-0001o2-G3; Thu, 01 Feb 2007 15:34:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCidy-0001nt-Sw for emu@ietf.org; Thu, 01 Feb 2007 15:34:54 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCidt-0002wL-Rc for emu@ietf.org; Thu, 01 Feb 2007 15:34:54 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 1 Feb 2007 12:34:49 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.24; Thu, 1 Feb 2007 12:34:48 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Thu, 1 Feb 2007 12:34:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Feb 2007 12:34:47 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8003FB75A6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-simon-emu-rfc2716bis-07.txt thread-index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQ== From: Ryan Hurst To: X-OriginalArrivalTime: 01 Feb 2007 20:34:48.0622 (UTC) FILETIME=[6AC0CCE0:01C74640] X-Spam-Score: 0.1 (/) X-Scan-Signature: d3308915082aec5bdcb405956a0eb0ae Subject: [Emu] draft-simon-emu-rfc2716bis-07.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689037312==" Errors-To: emu-bounces@ietf.org --===============1689037312== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74640.6A6FF78A" ------_=_NextPart_001_01C74640.6A6FF78A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-simon-emu-rfc2716bis-07.txt and believe that compared with the -06 text, this version has taken a step backwards. My read of the -07 changes are that they remove obligations for RFC conformant certificate validation and authorization, making RFC 2716bis less secure than RFC 2716 combined with RFC 3280. For this reason I believe that draft -07 is not suitable for advancement as a Proposed Standard. =20 To address the issues, I propose that the current Sections 5.2 and 5.3 be replaced with the following text: =20 "5.2 Peer and Server Identities =20 The EAP-TLS peer name (Peer-Id) represents the identity to be=20 used for access control and accounting purposes. The Server-Id=20 represents the identity of the EAP server. =20 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. =20 Where the subjectAltName field is present in the peer or server=20 certificate, the Peer-Id or Server-Id MUST be set to the contents=20 of the subjectAltName as per Section 5.3. =20 =20 If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a E RDN containing the Peer-Id and the Subject Field of the server certificate MUST contain the CN RDN containing the Server-ID. If subject naming information is present only in the subjectAltName extension then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical.=20 =20 Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use=20 the subjectAltName field instead. =20 Where the peer identity represents a host, a subjectAltName of type=20 dNSName SHOULD be present in the peer certificate. Where the peer=20 identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 =20 A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. A subjectAltName of type iPAdress MAY be used in the server certificate.=20 =20 5.3. Certificate Validation =20 Since the EAP-TLS server is typically connected to the Internet, it SHOULD support validating the peer certificate using=20 RFC 3280 [RFC3280] conformant path validation, including the=20 ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details,=20 see [RFC3280] Section 4.2.2.1. =20 Where the EAP-TLS server is unable to retrieve intermediate certificates, it must be pre-configured with the necessary=20 intermediate certificates to complete path validation or=20 rely on the EAP-TLS peer to provide this information as=20 part of the TLS Handshake (see [RFC4346] section 7.4.6). =20 In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore the EAP-TLS server=20 SHOULD provide its entire certificate chain minus the root to=20 facilitate certificate validation by the peer. =20 Once a TLS session is established EAP-TLS peer and server=20 implementations MUST validate that the identities represented=20 in the certificate are appropriate and authorized for=20 use with EAP-TLS. The authorization process makes=20 use of the contents of the certificates as well=20 as other contextual information. While authorization=20 requirements will vary from deployment to deployment=20 it is RECOMMENDED that implementations be able to=20 authorize based on the EAP-TLS Peer-Id and Server-Id=20 determined as described in Section 5.2.=20 =20 In the case of the EAP-TLS peer this involves ensuring=20 that the certificate presented by the EAP-TLS server was=20 intended to be used as a server certificate. Implementations SHOULD use the Extended Key=20 Usage (see [RFC3280] section 4.2.1.13)=20 extension and ensure that at least one of the=20 following is true: =20 1) The certificate issuer included no Extended Key Usage=20 identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier=20 in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-serverAuth identifier=20 in the certificate (See [RFC3280] section 4.2.1.13). When performing this comparison implementations MUST follow the=20 validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate=20 presented by the EAP-TLS peer was intended to be used as a=20 client certificate. Implementations SHOULD use the Extended=20 Key Usage (see [RFC3280] Section 4.2.1.13) extension and=20 ensure that at least one of the following is true: =20 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate=20 (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate=20 (see [RFC3280] section 4.2.1.13). =20 5.4. Certificate revocation =20 Certificates are long lived assertions of identity.=20 Therefore it is important for EAP-TLS implementations to=20 be capable of checking whether these assertions have been=20 revoked.=20 =20 EAP-TLS peer and server implementations MUST support the=20 use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server=20 implementations SHOULD also support the Online=20 Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten=20 connection times especially in bandwidth constrained environments. While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes.=20 In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. =20 However, in the case where the EAP-TLS peer is attempting to obtain network access, it will not have network connectivity and is therefore not capable of checking for certificate revocation until after authentication completes and network connectivity is available. =20 For this reason EAP-TLS peers and servers SHOULD implement=20 Certificate Status Request messages, as described in [RFC3546]=20 section 3.6. To enable revocation checking in situations=20 where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer=20 implementations SHOULD also support checking for certificate=20 revocation after authentication completes and network connectivity=20 is available, and SHOULD utilize this capability. " =20 Ryan M. Hurst Sr. Program Manager Windows Enterprise Networking rmh@microsoft.com ------_=_NextPart_001_01C74640.6A6FF78A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-simon-emu-rfc2716bis-07.txt and believe that = compared with the -06 text, this version has taken a step backwards.  My read of = the -07 changes are that they remove obligations for RFC conformant certificate validation and authorization, making RFC 2716bis less secure than RFC = 2716 combined with RFC 3280.  For this reason I believe that draft -07 = is not suitable for advancement as a Proposed Standard.

 

To address the issues, I propose that the current Sections 5.2 and 5.3 = be replaced with the following text:

 

"5.2 Peer and Server Identities

 

   The EAP-TLS peer name (Peer-Id) represents the identity 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.

  

   Where the subjectAltName field is present in the peer or server
   certificate, the Peer-Id or Server-Id MUST be set to the = contents
   of the subjectAltName as per Section = 5.3.  

 

   If subject naming information is present in only in the subject name = field

   then the Subject Field of the peer certificate SHOULD contain a E = RDN

   containing the Peer-Id and the Subject Field of the server certificate = MUST

   contain the CN RDN containing the Server-ID.  If subject = naming

   information is present only in the subjectAltName extension then the = subject

   field MUST be an empty sequence and the subjectAltName = extension

   MUST be critical.

 

   Although the use of  the subject field is existing practice, its = use in EAP-TLS

   is deprecated and Certification Authorities are encouraged to use
   the subjectAltName field instead.

 

   Where the peer identity represents a host, a subjectAltName of type
   dNSName SHOULD be present in the peer certificate.  = Where the peer
   identity represents a user and not a resource, a = subjectAltName of type
   rfc822Name SHOULD be used, conforming to the grammar for = the
   Network Access Identifier (NAI) defined in [RFC4282] = Section 2.1.
   If the peer identity represents neither a host nor a user, = another field

   type (for example a subjectAltName of type iPAddress
   or uniformResourceIdentifier) MAY be used. =

 

   A server identity will typically represent a host, not a user or
   a resource.  As a result, a subjectAltName of type = dNSName SHOULD be
   present in the server certificate.  A subjectAltName = of type
   iPAdress MAY be used in the server certificate. =

 

5.3.  Certificate Validation

 

   Since the EAP-TLS server is typically connected to the Internet,
   it SHOULD support validating the  peer certificate = using
   RFC 3280 [RFC3280] conformant path validation, including = the
   ability to retrieve intermediate certificates that may = be
   necessary to validate the peer certificate. For details, =
   see [RFC3280] Section 4.2.2.1.

 

   Where the EAP-TLS server is unable to retrieve intermediate
   certificates, it must = be pre-configured with the necessary
   intermediate certificates to complete path validation or =
   rely on the EAP-TLS peer to provide this information as =
   part of the TLS Handshake (see [RFC4346] section = 7.4.6).

   

   In contrast to the EAP-TLS server, the EAP-TLS peer may
   not have Internet connectivity. Therefore the EAP-TLS = server
   SHOULD provide its entire certificate chain minus the root = to
   facilitate certificate validation by the = peer.

 

   Once a TLS session is established EAP-TLS peer and server
   implementations MUST validate that the identities = represented
   in the certificate are appropriate and authorized for
   use with EAP-TLS.  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-TLS Peer-Id and Server-Id
   determined as described in Section 5.2. =

 

   In the case of the EAP-TLS peer this involves ensuring
   that the certificate presented by the EAP-TLS server was =
   intended to be used as a server certificate.
   Implementations SHOULD use the Extended Key
   Usage (see [RFC3280] section 4.2.1.13)
   extension and ensure that at least one of the
   following is true:

 

   1) The certificate issuer included no Extended Key Usage
        identifiers in the = certificate.
   2) The issuer included the anyExtendedKeyUsage = identifier
       in the certificate (see [RFC3280] = section 4.2.1.13).
   3) The issuer included the id-kp-serverAuth identifier =
       in the certificate (See [RFC3280] = section 4.2.1.13).


   When performing this comparison implementations MUST follow = the
   validation rules specified in [RFC2818] Section = 3.1.

   In the case of the server this involves ensuring the certificate
   presented by the EAP-TLS peer was intended to be used as a =
   client certificate. Implementations SHOULD use the Extended =
   Key Usage (see [RFC3280] Section 4.2.1.13) extension and =
   ensure that at least one of the following is = true:

 

   1) The certificate issuer included no Extended Key Usage = identifiers in the certificate.
   2) The issuer included the anyExtendedKeyUsage = identifier in the certificate
       (see [RFC3280] section = 4.2.1.13).
   3) The issuer included the id-kp-clientAuth identifier = in the certificate
      (see [RFC3280] section = 4.2.1.13).

 

5.4.  Certificate revocation

 

   Certificates are long lived assertions of identity.
   Therefore it is important for EAP-TLS implementations to =
   be capable of checking whether these assertions have been =
   revoked.
 
   EAP-TLS peer and server implementations MUST support the =
   use of Certificate Revocation Lists (CRLs); for = details,
   see [RFC3280] section 3.3.  EAP-TLS peer and server =
   implementations SHOULD also support the Online
   Certificate Status Protocol (OCSP), described in = [RFC2560].
   OCSP messages are typically much smaller than CRLs which = can shorten
   connection times especially in bandwidth constrained = environments.

   While EAP-TLS servers are typically connected to the Internet during
   the EAP conversation, an EAP-TLS peer may not have = Internet
   connectivity until authentication completes. =


   In the case where the peer is initiating a voluntary Layer = 2 tunnel
   using PPTP [RFC2637] or L2TP [RFC2661], the peer will = typically
   already have a PPP interface and Internet connectivity = established at
   the time of tunnel initiation.

 

   However, in the case where the EAP-TLS peer is attempting to obtain = network
   access, it will not have network connectivity and is = therefore not
   capable of checking for certificate revocation until = after
   authentication completes and network connectivity is available. 

   For this reason EAP-TLS peers and servers SHOULD implement
   Certificate Status Request messages, as described in = [RFC3546]
   section 3.6.  To enable revocation checking in = situations
   where servers do not support Certificate
   Status Request messages and network connectivity is not
   available prior to authentication completion,  peer =
   implementations SHOULD also support checking for = certificate
   revocation after authentication completes and network = connectivity
   is available, and SHOULD utilize this = capability.

“

 

Ryan M. Hurst

Sr. Program Manager

Windows Enterprise Networking

rmh@microsoft.com

------_=_NextPart_001_01C74640.6A6FF78A-- --===============1689037312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1689037312==-- From emu-bounces@ietf.org Thu Feb 01 17:12:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkAK-0002il-Oy; Thu, 01 Feb 2007 17:12:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkAK-0002iZ-7i for emu@ietf.org; Thu, 01 Feb 2007 17:12:24 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkAH-0002gl-Jh for emu@ietf.org; Thu, 01 Feb 2007 17:12:24 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Feb 2007 14:12:21 -0800 X-IronPort-AV: i="4.13,269,1167638400"; d="scan'208"; a="461627811:sNHT62908098" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l11MCLuX009134; Thu, 1 Feb 2007 14:12:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l11MCKGk006200; Thu, 1 Feb 2007 14:12:20 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 14:12:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] draft-simon-emu-rfc2716bis-07.txt Date: Thu, 1 Feb 2007 14:12:17 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8003FB75A6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQAB/nyg From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , X-OriginalArrivalTime: 01 Feb 2007 22:12:20.0576 (UTC) FILETIME=[0ACA1E00:01C7464E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9563; t=1170367941; x=1171231941; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=awBsvgEs/YTRxDtQIOcArzzXlfwSTjxP/97O3PQe9BI=; b=QaFSRSzncPfNFkgXJIq9hoW+r9+xWcsZ3ia6XMIqucjBHTnPqxLR9ZNoObHJO/KueTkjhao5 UI685KCDxnLFOnis1G75wlrrUQJA1k4j4EWcuKR1fZCKrZuKzx/0+LRb; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Ryan, =20 Thanks for posting this, I think it is very helpful. I have some questions in-line below: ________________________________ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Thursday, February 01, 2007 12:35 PM To: emu@ietf.org Subject: [Emu] draft-simon-emu-rfc2716bis-07.txt =09 =09 I have reviewed draft-simon-emu-rfc2716bis-07.txt and believe that compared with the -06 text, this version has taken a step backwards. My read of the -07 changes are that they remove obligations for RFC conformant certificate validation and authorization, making RFC 2716bis less secure than RFC 2716 combined with RFC 3280. For this reason I believe that draft -07 is not suitable for advancement as a Proposed Standard. =20 To address the issues, I propose that the current Sections 5.2 and 5.3 be replaced with the following text: =20 "5.2 Peer and Server Identities =20 The EAP-TLS peer name (Peer-Id) represents the identity to be used for access control and accounting purposes. The Server-Id=20 represents the identity of the EAP server. =20 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. =20 Where the subjectAltName field is present in the peer or server=20 certificate, the Peer-Id or Server-Id MUST be set to the contents=20 of the subjectAltName as per Section 5.3. =20 =20 [Joe] Why subjectAltName and not Subject? =20 =20 If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a E RDN containing the Peer-Id and the Subject Field of the server certificate MUST contain the CN RDN containing the Server-ID. If subject naming information is present only in the subjectAltName extension then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical.=20 =20 [Joe] What is E RDN? =20 =20 Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use=20 the subjectAltName field instead. =20 [Joe] Are there other standards that are deprecating the use of subject field as well? (This is related to my first question above.) =20 Where the peer identity represents a host, a subjectAltName of type=20 dNSName SHOULD be present in the peer certificate. Where the peer=20 identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 [Joe] There may be hosts which do not have a DNSName or Ipaddress (L2 entities), so I think we need to clarify the above text. =20 A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. A subjectAltName of type iPAdress MAY be used in the server certificate.=20 =20 [Joe] We probably need to allow various name types for the server as well. I think there still needs to be some discussion on how subjectAltNames map to peer and server names in the case where there are multiple subjectAltNames. =20 =20 5.3. Certificate Validation =20 Since the EAP-TLS server is typically connected to the Internet, it SHOULD support validating the peer certificate using=20 RFC 3280 [RFC3280] conformant path validation, including the=20 ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details,=20 see [RFC3280] Section 4.2.2.1. =20 Where the EAP-TLS server is unable to retrieve intermediate certificates, it must be pre-configured with the necessary=20 intermediate certificates to complete path validation or=20 rely on the EAP-TLS peer to provide this information as=20 part of the TLS Handshake (see [RFC4346] section 7.4.6). =20 In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore the EAP-TLS server=20 SHOULD provide its entire certificate chain minus the root to facilitate certificate validation by the peer. =20 Once a TLS session is established EAP-TLS peer and server=20 implementations MUST validate that the identities represented in the certificate are appropriate and authorized for=20 use with EAP-TLS. The authorization process makes=20 use of the contents of the certificates as well=20 as other contextual information. While authorization=20 requirements will vary from deployment to deployment=20 it is RECOMMENDED that implementations be able to=20 authorize based on the EAP-TLS Peer-Id and Server-Id=20 determined as described in Section 5.2.=20 =20 In the case of the EAP-TLS peer this involves ensuring=20 that the certificate presented by the EAP-TLS server was=20 intended to be used as a server certificate. Implementations SHOULD use the Extended Key=20 Usage (see [RFC3280] section 4.2.1.13)=20 extension and ensure that at least one of the=20 following is true: =20 1) The certificate issuer included no Extended Key Usage=20 identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier=20 in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-serverAuth identifier=20 in the certificate (See [RFC3280] section 4.2.1.13). =09 When performing this comparison implementations MUST follow the=20 validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate=20 presented by the EAP-TLS peer was intended to be used as a=20 client certificate. Implementations SHOULD use the Extended=20 Key Usage (see [RFC3280] Section 4.2.1.13) extension and=20 ensure that at least one of the following is true: =20 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate=20 (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate=20 (see [RFC3280] section 4.2.1.13). =20 5.4. Certificate revocation =20 Certificates are long lived assertions of identity.=20 Therefore it is important for EAP-TLS implementations to=20 be capable of checking whether these assertions have been=20 revoked.=20 =20 EAP-TLS peer and server implementations MUST support the=20 use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server=20 implementations SHOULD also support the Online=20 Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten=20 connection times especially in bandwidth constrained environments. While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes.=20 =20 [Joe] This is somewhat different than what the current draft has specified up until now. I am a little uneasy with OCSP as a SHOULD, are there other specifications which have such a strong recommendation for OCSP? =20 =20 In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. =20 However, in the case where the EAP-TLS peer is attempting to obtain network access, it will not have network connectivity and is therefore not capable of checking for certificate revocation until after authentication completes and network connectivity is available. =20 For this reason EAP-TLS peers and servers SHOULD implement=20 Certificate Status Request messages, as described in [RFC3546]=20 section 3.6. To enable revocation checking in situations=20 where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer=20 implementations SHOULD also support checking for certificate=20 revocation after authentication completes and network connectivity=20 is available, and SHOULD utilize this capability.=20 =20 [Joe] A strong recommendation for TLS extensions is somewhat counter to some of the discussions we have had in the past about keeping EAP-TLS as bare bones as possible. I would like to hear other's opinion on this.=20 =20 =20 Ryan M. Hurst Sr. Program Manager Windows Enterprise Networking rmh@microsoft.com _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Feb 03 13:37:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDPkq-0002e1-0J; Sat, 03 Feb 2007 13:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDPkp-0002dw-FD for emu@ietf.org; Sat, 03 Feb 2007 13:36:51 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HDPkl-0007kM-Ji for emu@ietf.org; Sat, 03 Feb 2007 13:36:51 -0500 Received: (qmail invoked by alias); 03 Feb 2007 18:36:45 -0000 Received: from p54984A30.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.74.48] by mail.gmx.net (mp039) with SMTP; 03 Feb 2007 19:36:45 +0100 X-Authenticated: #29516787 Message-ID: <45C4D63A.7050604@gmx.net> Date: Sat, 03 Feb 2007 13:36:42 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jouni Malinen Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt References: <20070109033906.GB6653@jm.kir.nu> In-Reply-To: <20070109033906.GB6653@jm.kir.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: emu@ietf.org, clancy@ltsnet.net X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Jouni, I am currently working on the draft update. A few short responses below: Jouni Malinen wrote: > On Mon, Jan 08, 2007 at 03:50:02PM -0500, Internet-Drafts@ietf.org wrote: > > >> Title : EAP Generalized Pre-Shared Key (EAP-GPSK) >> Author(s) : C. Clancy, H. Tschofenig >> Filename : draft-ietf-emu-eap-gpsk-02.txt >> > > Some comments.. > > General > > - How long are the random values? 16 octets? 32 octets? > As indicated by Charlesthis is a bug. > * I assumed they were 32 octets (256 bits), but the draft is in > conflict with itself.. > * 2. Terminology: 16 octets (this was 256 bits in -00) > changed to 32 octets > * 7.3. Payload Formatting: 32 octets > Untouched. > * 9.4. Replay Protection: 16 octets > changed to 32 octets > * 9.8. Denial of Service Resistance: 16 octets > changed to 32 octets > changed to 32 octets > > 2. Terminology > > - MSK and EMSK were changed from 512 bits (64 octets) to 32 octets > * Why? > * Other EAP methods use 64 octet MSK and EMSK, so I hope this was > just an accident and the purpose was only to move from bits to > octets: s/32 octets/64 octets/ > Changed to 64 octets. > * Similar change in 4. Key Derivation (though, that section is also > using 64 octets.. only Figure 2 is incorrect; s/32-octet/64-octet/) > > Changed figure. > 3. Overview > > - Order of CSuite_Sel and CSuite_List in GPSK-2 was reversed > * Why? > No clue. > * 7.3. Payload Formatting is still using the previous order, i.e., > CSuite_List before CSuite_Sel; in other words, there is now conflict > between sections 3 and 7.3 on the order of these fields > > Changed the order in Section 3. > 5. Ciphersuites > > - definitions of GKDF-X(Y, Z) was changed, but some cleanup missing > * 'X' is not used anymore as an input to hash function and because > of this, there is no need to say that it is repredsented as a > 2-octet value in network byte order: > s/'i' and 'X' in M_i are represented as 2-octet values/ > 'i' is represented as 2-octet value/ > > Here is the definition of GKDF-X(Y, Z): ------------ GKDF-X (Y, Z) { n = ceiling integer of ( X / hashlen ); /* determine number of output blocks */ M_0 = ""; result = ""; for i = 1 to n { M_i = Hash-Function (i || y || Z); result = result || M_i; } return truncate (result; X) } ------------ The value of X is used to compute n. I suggest not to change anything. > 6.1.1. Encryption > > - CBC is mentioned to require an IV > * However, there is no definition on where this IV is coming from or > how it is to be transmitted to the other party > * How exactly is this supposed to work? > > > That's a good point. More text is indeed needed. > 8. Packet Processing Rules > > - typo: s/receving/receiving/ > > Fixed. > - "(i.e. an EAP client receiving GPSK-3 before receving GPSK-1 or before > transmitting GPSK-2)" > * isn't that more of an example (e.g.) than the only possible case > (i.e.)? > * s/i.e./e.g./ > You are right. This is an example. > - "GPSK-1 contains no MAC protection, so provided it properly parses, it > MUST be accepted by the client." > * MUST?? > * What if CSuite_List in GPSK-1 does not include any supported > cipher? > The mandatory-to-implement ciphersuite will always have to be included. > - s/EAP-NACK/EAP-Nak/ to match with "Nak" spelling in RFC 3748 > > Fixed. > - "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in > response to a GPSK-2 message MUST either transmit an EAP-Failure > message and end the session" > * Success and Failure messages are sent by authenticator, not > peer > * This should probably be changed to say that client (peer) is sending > back GPSK-Fail / GPSK-Protected-Fail, not EAP-Failure, to > acknowledge failure; this will be followed by the authenticator > sending EAP-Failure > Fixed. Victor made the same comment. > - "For GPSK-3, a client MUST silently discard any packet containing > whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those > transmitted in GPSK-2." > * There's something wrong with this sentence.. > s/whose // > s/do match/that do not match/ > Fixed. > > 9.4. Replay Protection > > - typo: s/RAND_P/RAND_Client/ > > Fixed. > 9.8. Denial of Service Resistance > > - typo: s/RAND_S/RAND_Server/ > > Fixed. Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Feb 05 16:03:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEB04-0006Qv-6B; Mon, 05 Feb 2007 16:03:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEB02-0006Qp-H8 for emu@ietf.org; Mon, 05 Feb 2007 16:03:42 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEAzz-0000Ju-BQ for emu@ietf.org; Mon, 05 Feb 2007 16:03:42 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 5 Feb 2007 13:03:38 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.24; Mon, 5 Feb 2007 13:03:37 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Mon, 5 Feb 2007 13:03:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Feb 2007 13:03:36 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800403D769@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-simon-emu-rfc2716bis-07.txt thread-index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQBeWv2A From: Ryan Hurst To: X-OriginalArrivalTime: 05 Feb 2007 21:03:37.0067 (UTC) FILETIME=[1AA393B0:01C74969] X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a5a4a09549c7cc239b767c425e1a62 Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1146563816==" Errors-To: emu-bounces@ietf.org --===============1146563816== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74969.1A2B1FB6" ------_=_NextPart_001_01C74969.1A2B1FB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe - For some reason I didn't get your email, I found it on the archives; bellow are the questions from that mail and my answers: =20 Where the subjectAltName field is present in the peer or Server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as per Section 5.3. =20 =20 [Joe] Why subjectAltName and not Subject? =20 [rmh] The use of the subject name was intended to represent a directory location, directory locations may or may not include the a value that would reasonable map to the subject id (eg a E rdn). its bad form to require people to change their directory layout to deploy a application, therefore standards that take a dependency on a specific name form being present in a certificate should do so by specifying that name form exist in the subjectAltName. =20 If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a E RDN containing the Peer-Id. =20 [Joe] What is E RDN? =20 [rmh] RDN is a relative distinguished name, DNs are made up of these; There is a RDN is for the email address, I don't have the X.500 documents handy but its defined in there. I remember the name being just E; however I did some googling and looks like I was wrong its emailAddress. =20 Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. =20 [Joe] Are there other standards that are deprecating the use of subject field as well? (This is related to my first question above.) =20 [rmh] uid is the only other RDN that a peer-id like value that might be used in [rmh] however in practice I have never seen this used; see my other comment as [rmh] to why. This is one of the reasons other rfcs like TLS deprecate use of the [rmh] subject dn for subjectAltName instead (see 3.1 of http://www.ietf.org/rfc/rfc2818.txt) =20 =20 Where the peer identity represents a host, a subjectAltName of type dNSName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 =20 [Joe] There may be hosts which do not have a DNSName or Ipaddress (L2 entities), so I think we need to clarify the above text. =20 [rmh] This text does not preclude the inclusion of other name forms=20 [rmh] it even allows for it by saying other types can be included. [rmh] It is important to encourage a name form be included for interop sake [rmh] dnsName and rfc822 is clearly the most common in existing deployments=20 [rmh] so including it seems appropriate. =20 [rmh] There should be some text in the security consideration section [rmh] about the MITM risks associated with making a trust decision [rmh] on unauthenticated values you have at L2. =20 A server identity will typically represent a host, not a user Or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. A subjectAltName of Type iPAdress MAY be used in the server certificate.=20 =20 [Joe] We probably need to allow various name types for the server as well. I think there still needs to be some discussion on how subjectAltNames map to peer and server names in the case where there are multiple subjectAltNames. =20 [rmh] How about we change "A subjectAltName of type iPAdress MAY be used [rmh] in the server certificate." To "If a dnsName is not available other [rmh] field types (for example a subjectAltName of type iPAdress or [rmh] uniformResourceIdentifier) MAY be used. =20 5.4. Certificate revocation =20 Certificates are long lived assertions of identity.=20 Therefore it is important for EAP-TLS implementations to=20 be capable of checking whether these assertions have been=20 revoked.=20 =20 EAP-TLS peer and server implementations MUST support the=20 use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server=20 implementations SHOULD also support the Online=20 Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten connection times especially in bandwidth constrained environments. =20 While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes.=20 =20 =20 [Joe] This is somewhat different than what the current draft has specified up until now. I am a little uneasy with OCSP as a SHOULD, are there other specifications which have such a strong recommendation for OCSP? =20 [rmh] I know of no other RFC that uses SHOULD for OCSP, however I know of [rmh] no other protocol in which its primary use case prevents a client from [rmh] checking the revocation status of the server. The use of OCSP and TLS [rmh] extensions enables this client to do this check. =20 [rmh] The SHOULD is a response to this security risk, weaker wording would be [rmh] the same as saying MAY choose to be vulnerable to these attacks, SHOULD [rmh] allows vendors to choose not to do so while encouraging them to address [rmh] these risks. =20 [rmh] There are also the latency and timing issues associated with network connections [rmh] make the download of 800k CRLs before a connect can happen is a deal breaker, [rmh] a few K (as little as 400 bytes) for a OCSP response is a much better deal. =20 [rmh] I feel strongly the RFC needs to provide guidance on how to use certificates [rmh] securely and in a deployable way. [rmh] I appreciate that not all implementations do this but that is why its [rmh] not a MUST. =20 For this reason EAP-TLS peers and servers SHOULD implement=20 Certificate Status Request messages, as described in [RFC3546]=20 section 3.6. To enable revocation checking in situations=20 where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer=20 implementations SHOULD also support checking for certificate=20 revocation after authentication completes and network connectivity=20 is available, and SHOULD utilize this capability.=20 =20 [Joe] A strong recommendation for TLS extensions is somewhat counter to some of the discussions we have had in the past about keeping EAP-TLS as bare bones as possible. I would like to hear other's opinion on this.=20 =20 [rmh] See my earlier comment on the security risks associated with the use [rmh] scenarios for this protocol, its dependency on certificates at layer 2, [rmh] and the clients inability to perform revocation checking. [rmh] The use of OCSP and the TLS extension addresses this risk. =20 =20 ------_=_NextPart_001_01C74969.1A2B1FB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joe – For some reason I didn’t get your email, I found it on the archives; bellow are the questions from that mail and my = answers:

 

        Where the subjectAltName field is present in the peer = or

        Server certificate, the Peer-Id or Server-Id MUST be = set

        to the contents of the subjectAltName as per Section 5.3.  =

 

        [Joe] Why subjectAltName and not Subject? 

        [rmh] The use of the subject name was intended to represent a directory location, directory locations may or

           &= nbsp;  may not include the a value that would reasonable map to the subject id = (eg a E rdn).

           &= nbsp;  its bad form to require people to change their directory layout to = deploy a application, therefore

           &= nbsp;  standards that take a dependency on a specific name form being present = in a certificate should do so

           &= nbsp;  by specifying that name form exist in the = subjectAltName.

 

           If subject naming information is present in only in = the

           subject name field then the Subject Field of the = peer

           certificate SHOULD contain a E RDN containing the = Peer-Id.

         

        [Joe] What is E RDN? 

        [rmh] RDN is a relative distinguished name, DNs are made up of = these;

           &= nbsp;  There is a RDN is for the email address, I don’t have the = X.500

              documents handy but its defined in there. = I remember the name being

              just E; however I did some googling and = looks like I was wrong its

              emailAddress.

 

           Although the use of  the subject field is existing = practice,

           its use in EAP-TLS is deprecated and Certification = Authorities

           are encouraged to use the subjectAltName field = instead.

 

        [Joe] Are there other standards that are deprecating the use of = subject

        field as well?  (This is related to my first question = above.)

 

        [rmh] uid is the only other RDN that a peer-id like value that might be = used in

        [rmh] however in practice I have never seen this used; see my other = comment as

        [rmh] to why. This is one of the reasons other rfcs like TLS deprecate = use of the

        [rmh] subject dn for subjectAltName instead (see 3.1 of http://www.ietf.org/rfc/rfc2818.txt)

    

 

        Where the peer identity represents a host, a = subjectAltName

        of type dNSName SHOULD be present in the peer certificate.  Where = the

        peer identity represents a user and not a resource, a subjectAltName of = type

        rfc822Name SHOULD be used, conforming to the grammar for = the

        Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. =

        If the peer identity represents neither a host nor a = user,

        another field type (for example a subjectAltName of type = iPAddress

        or uniformResourceIdentifier) MAY be used.

 

        [Joe] There may be hosts which do not have a DNSName or Ipaddress = (L2

         entities), so I think we need to clarify the above = text.

 

        [rmh] This text does not preclude the inclusion of other name forms =

        [rmh] it even allows for it by saying other types can be = included.

        [rmh] It is important to encourage a name form be included for interop = sake

        [rmh] dnsName and rfc822 is clearly the most common in existing = deployments

        [rmh] so including it seems appropriate.

 

        [rmh] There should be some text in the security consideration = section

        [rmh] about the MITM risks associated with making a trust = decision

        [rmh] on unauthenticated values you have at L2.

 

        A server identity will typically represent a host, not a = user

        Or a resource.  As a result, a subjectAltName of type = dNSName

        SHOULD be present in the server certificate.  A subjectAltName = of

        Type iPAdress MAY be used in the server certificate. =

 

        [Joe] We probably need to allow various name types for the server = as

        well.  I think there still needs to be some discussion on = how

        subjectAltNames map to peer and server names in the case where there = are

        multiple subjectAltNames.

 

        [rmh] How about we change “A subjectAltName of type iPAdress MAY = be used

        [rmh] in the server certificate.” To “If a dnsName is not = available other

        [rmh] field types (for example a subjectAltName of type iPAdress = or

        [rmh] uniformResourceIdentifier) MAY be used.

 

        5.4.  Certificate revocation

 

           Certificates are long lived assertions of identity. =

           Therefore it is important for EAP-TLS implementations to =

           be capable of checking whether these assertions have been =

           revoked.

         

           EAP-TLS peer and server implementations MUST support the =

           use of Certificate Revocation Lists (CRLs); for = details,

           see [RFC3280] section 3.3.  EAP-TLS peer and server =

           implementations SHOULD also support the Online =

           Certificate Status Protocol (OCSP), described in = [RFC2560].

           OCSP messages are typically much smaller than CRLs which = can

           shorten connection times especially in bandwidth = constrained

           environments.

 

           While EAP-TLS servers are typically connected to the = Internet

           during the EAP conversation, an EAP-TLS peer may not = have

           Internet connectivity until authentication completes. =

         

 

        [Joe]  This is somewhat different than what the current draft = has

        specified up until now.   I am a little uneasy with OCSP as a = SHOULD,

        are there other specifications which have such a strong = recommendation

        for OCSP?

 

        [rmh] I know of no other RFC that uses SHOULD for OCSP, however I know = of

        [rmh] no other protocol in which its primary use case prevents a client = from

        [rmh] checking the revocation status of the server. The use of OCSP and = TLS

        [rmh] extensions enables this client to do this = check.

 

        [rmh] The SHOULD is a response to this security risk, weaker wording = would be

        [rmh] the same as saying MAY choose to be vulnerable to these attacks, = SHOULD

        [rmh] allows vendors to choose not to do so while encouraging them to = address

        [rmh] these risks.

 

        [rmh] There are also the latency and timing issues associated with = network connections

        [rmh] make the download of 800k CRLs before a connect can happen is a = deal breaker,

        [rmh] a few K (as little as 400 bytes) for a OCSP response is a much = better deal.

 

        [rmh] I feel strongly the RFC needs to provide guidance on how to use certificates

        [rmh] securely and in a deployable way.

        [rmh] I appreciate that not all implementations do this but that is why = its

        [rmh] not a MUST.

 

        For this reason EAP-TLS peers and servers SHOULD implement =

        Certificate Status Request messages, as described in [RFC3546] =

        section 3.6.  To enable revocation checking in situations =

        where servers do not support Certificate

        Status Request messages and network connectivity is = not

        available prior to authentication completion,  peer =

        implementations SHOULD also support checking for certificate =

        revocation after authentication completes and network connectivity =

        is available, and SHOULD utilize this capability.

         

        [Joe] A strong recommendation for TLS extensions is somewhat counter = to

        some of the discussions we have had in the past about keeping EAP-TLS = as

        bare bones as possible.   I would like to hear other's opinion = on this.

 

        [rmh] See my earlier comment on the security risks associated with the = use

        [rmh] scenarios for this protocol, its dependency on certificates at = layer 2,

        [rmh] and the clients inability to perform revocation = checking.

        [rmh] The use of OCSP and the TLS extension addresses this = risk.

         

 

------_=_NextPart_001_01C74969.1A2B1FB6-- --===============1146563816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1146563816==-- From emu-bounces@ietf.org Tue Feb 06 11:35:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETHk-0007EF-9T; Tue, 06 Feb 2007 11:35:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETHj-0007EA-NY for emu@ietf.org; Tue, 06 Feb 2007 11:35:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HETHh-0004fg-Lu for emu@ietf.org; Tue, 06 Feb 2007 11:35:11 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2007 08:35:09 -0800 X-IronPort-AV: i="4.13,291,1167638400"; d="scan'208"; a="761882885:sNHT274634702" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l16GZ7qc015319; Tue, 6 Feb 2007 08:35:07 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l16GZ7Dk011715; Tue, 6 Feb 2007 08:35:07 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:35:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 6 Feb 2007 08:34:56 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800403D769@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQBeWv2AAJMb1cA= From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , X-OriginalArrivalTime: 06 Feb 2007 16:35:07.0354 (UTC) FILETIME=[C2EA33A0:01C74A0C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10514; t=1170779707; x=1171643707; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=AQjo9u1N2KDlBKibOZexGaTyVQl2J7jntkAxkK5fkQo=; b=TNITiqLqVgF+9xphEVWCghiIsbi95+9ebCnCC2ZUCfN8tYGzykMOmiUTrYD9wzTzuDvmiTcg nBasCM92u28iyH5D9J8U+KE7ullJYpHxQk/WWTSrYTIo67hJ8OsIEQju; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Ryan, I understand the deprecation of subjectName in favor of SubjectAltName, this makes sense to me now. =20 =20 I'm still struggling a little with mapping subjectAltName and subjectName certificate fields to peer and server identities. I think the text you suggested for the server name subjectAltName mapping is good: =20 [rmh] How about we change "A subjectAltName of type iPAdress MAY be used [rmh] in the server certificate." To "If a dnsName is not available other [rmh] field types (for example a subjectAltName of type iPAdress or [rmh] uniformResourceIdentifier) MAY be used. I think we should have similar text for the peer name. There are cases where either or both the EAP peer and EAP server may be devices that do not have an RFC822 name or dnsName. =20 I am a bit concerned with the text for the subject DN. Why not use the same field for both server and peer certificates? In my experience the email address in a certificate subject DN is not always the best identifier. Could CN be used instead of email address? =20 With regard to usage of OCSP, I understand the concern you raise. However, the current practice of retrieving a CRL when attached to the network and validating the accepted certificate seems to provide decent protection. The OCSP in TLS approach is a better approach, but how much better is it? A SHOULD is a fairly strong requirement and its use here may affect how quickly this document can move through the standards track. I want to make sure we are getting significant benefit from this added requirement.=20 Joe ________________________________ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Monday, February 05, 2007 1:04 PM To: emu@ietf.org Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =09 =09 Joe - For some reason I didn't get your email, I found it on the archives; bellow are the questions from that mail and my answers: =20 Where the subjectAltName field is present in the peer or Server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as per Section 5.3. =20 =20 [Joe] Why subjectAltName and not Subject? =20 [rmh] The use of the subject name was intended to represent a directory location, directory locations may or may not include the a value that would reasonable map to the subject id (eg a E rdn). its bad form to require people to change their directory layout to deploy a application, therefore standards that take a dependency on a specific name form being present in a certificate should do so by specifying that name form exist in the subjectAltName. =20 If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a E RDN containing the Peer-Id. =20 [Joe] What is E RDN? =20 [rmh] RDN is a relative distinguished name, DNs are made up of these; There is a RDN is for the email address, I don't have the X.500 documents handy but its defined in there. I remember the name being just E; however I did some googling and looks like I was wrong its emailAddress. =20 Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. =20 [Joe] Are there other standards that are deprecating the use of subject field as well? (This is related to my first question above.) =20 [rmh] uid is the only other RDN that a peer-id like value that might be used in [rmh] however in practice I have never seen this used; see my other comment as [rmh] to why. This is one of the reasons other rfcs like TLS deprecate use of the [rmh] subject dn for subjectAltName instead (see 3.1 of http://www.ietf.org/rfc/rfc2818.txt) =20 =20 Where the peer identity represents a host, a subjectAltName of type dNSName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 =20 [Joe] There may be hosts which do not have a DNSName or Ipaddress (L2 entities), so I think we need to clarify the above text. =20 [rmh] This text does not preclude the inclusion of other name forms=20 [rmh] it even allows for it by saying other types can be included. [rmh] It is important to encourage a name form be included for interop sake [rmh] dnsName and rfc822 is clearly the most common in existing deployments=20 [rmh] so including it seems appropriate. =20 [rmh] There should be some text in the security consideration section [rmh] about the MITM risks associated with making a trust decision [rmh] on unauthenticated values you have at L2. =20 A server identity will typically represent a host, not a user Or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. A subjectAltName of Type iPAdress MAY be used in the server certificate.=20 =20 [Joe] We probably need to allow various name types for the server as well. I think there still needs to be some discussion on how subjectAltNames map to peer and server names in the case where there are multiple subjectAltNames. =20 [rmh] How about we change "A subjectAltName of type iPAdress MAY be used [rmh] in the server certificate." To "If a dnsName is not available other [rmh] field types (for example a subjectAltName of type iPAdress or [rmh] uniformResourceIdentifier) MAY be used. =20 5.4. Certificate revocation =20 Certificates are long lived assertions of identity.=20 Therefore it is important for EAP-TLS implementations to=20 be capable of checking whether these assertions have been=20 revoked.=20 =20 EAP-TLS peer and server implementations MUST support the=20 use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server=20 implementations SHOULD also support the Online=20 Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten connection times especially in bandwidth constrained environments. =20 While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes. =20 =20 [Joe] This is somewhat different than what the current draft has specified up until now. I am a little uneasy with OCSP as a SHOULD, are there other specifications which have such a strong recommendation for OCSP? =20 [rmh] I know of no other RFC that uses SHOULD for OCSP, however I know of [rmh] no other protocol in which its primary use case prevents a client from [rmh] checking the revocation status of the server. The use of OCSP and TLS [rmh] extensions enables this client to do this check. =20 [rmh] The SHOULD is a response to this security risk, weaker wording would be [rmh] the same as saying MAY choose to be vulnerable to these attacks, SHOULD [rmh] allows vendors to choose not to do so while encouraging them to address [rmh] these risks. =20 [rmh] There are also the latency and timing issues associated with network connections [rmh] make the download of 800k CRLs before a connect can happen is a deal breaker, [rmh] a few K (as little as 400 bytes) for a OCSP response is a much better deal. =20 [rmh] I feel strongly the RFC needs to provide guidance on how to use certificates [rmh] securely and in a deployable way. [rmh] I appreciate that not all implementations do this but that is why its [rmh] not a MUST. =20 For this reason EAP-TLS peers and servers SHOULD implement=20 Certificate Status Request messages, as described in [RFC3546]=20 section 3.6. To enable revocation checking in situations=20 where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer=20 implementations SHOULD also support checking for certificate=20 revocation after authentication completes and network connectivity=20 is available, and SHOULD utilize this capability.=20 =20 [Joe] A strong recommendation for TLS extensions is somewhat counter to some of the discussions we have had in the past about keeping EAP-TLS as bare bones as possible. I would like to hear other's opinion on this.=20 =20 [rmh] See my earlier comment on the security risks associated with the use [rmh] scenarios for this protocol, its dependency on certificates at layer 2, [rmh] and the clients inability to perform revocation checking. [rmh] The use of OCSP and the TLS extension addresses this risk. =20 =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 06 15:52:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEXIg-0002l6-6i; Tue, 06 Feb 2007 15:52:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEXId-0002kX-9K for emu@ietf.org; Tue, 06 Feb 2007 15:52:24 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEXIc-0006qP-1H for emu@ietf.org; Tue, 06 Feb 2007 15:52:23 -0500 Received: (qmail invoked by alias); 06 Feb 2007 20:52:20 -0000 Received: from p54984C11.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.76.17] by mail.gmx.net (mp037) with SMTP; 06 Feb 2007 21:52:20 +0100 X-Authenticated: #29516787 Message-ID: <45C8EA84.3060409@gmx.net> Date: Tue, 06 Feb 2007 21:52:20 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Emu] EAP-GPSK Draft Update X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, based on the feedback of Victor and Jouni we have updated the draft. Please find the updated draft here: http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-03.txt We believe that the draft is ready for WGLC. Ciao Hannes _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 07 15:50:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkC-0003VM-Cm; Wed, 07 Feb 2007 15:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtjv-0003Rg-Ia; Wed, 07 Feb 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEtjv-0003Sm-7R; Wed, 07 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2256E32982; Wed, 7 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001be-Vy; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : EAP Generalized Pre-Shared Key (EAP-GPSK) Author(s) : C. Clancy, H. Tschofenig Filename : draft-ietf-emu-eap-gpsk-03.txt Pages : 36 Date : 2007-2-7 This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-emu-eap-gpsk-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-emu-eap-gpsk-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7113852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-emu-eap-gpsk-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-emu-eap-gpsk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7113852.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Wed Feb 07 22:52:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF0KX-0000X8-L0; Wed, 07 Feb 2007 22:52:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF0KV-0000Wv-UZ for emu@ietf.org; Wed, 07 Feb 2007 22:52:15 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF0KT-0001m6-7z for emu@ietf.org; Wed, 07 Feb 2007 22:52:15 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2007 19:52:12 -0800 X-IronPort-AV: i="4.13,298,1167638400"; d="scan'208"; a="359968468:sNHT145071454" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l183qC4F005781 for ; Wed, 7 Feb 2007 19:52:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l183qCUw001018 for ; Wed, 7 Feb 2007 19:52:12 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 19:52:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Feb 2007 19:52:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-emu-eap-gpsk-03.txt Thread-Index: AcdLNIKdemdZee24TfyfmDwUTsaVaw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 08 Feb 2007 03:52:11.0640 (UTC) FILETIME=[834A0F80:01C74B34] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=325; t=1170906732; x=1171770732; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20WG=20Last=20Call=3A=20draft-ietf-emu-eap-gpsk-03.txt |Sender:=20 |To:=20 |Content-Type:=20text/plain=3B=0A=09charset=3D=22us-ascii=22 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=/vNrU2C+O5q/VMUuxC7HCh011pFJdvzXOZP+Zd1VwB8=; b=IkFVulmR4rbKt55kQOKkmxJI4i4N+0kMLhnu4oydl2LRe3aKHi8Fqg/kqoEXl+b2HT9W5S14 jwWe5S5u3zIlHXCaPGwl1+uHqLovPKAyc1iaLQR9g2Mwn9y+RgPu7u1zLv0JAWAfwPc1d1RvVZ UjEpW+KGWv3RWfCXYNf3Bd9p0=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Emu] WG Last Call: draft-ietf-emu-eap-gpsk-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This is a working group last call for draft-ietf-emu-eap-gpsk-03.=20 Send your comments to the EMU list by March 7, 2007. Please respond to this call even if you have reviewed the draft and found no problems. =20 The document can be accessed here: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 07 23:07:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF0Zd-0008Ti-F0; Wed, 07 Feb 2007 23:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF0Zc-0008TX-Cy for emu@ietf.org; Wed, 07 Feb 2007 23:07:52 -0500 Received: from mail7.sea5.speakeasy.net ([69.17.117.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF0Zb-00055O-3a for emu@ietf.org; Wed, 07 Feb 2007 23:07:52 -0500 Received: (qmail 24223 invoked from network); 8 Feb 2007 04:07:43 -0000 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net (HELO jm) ([69.17.49.110]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Feb 2007 04:07:43 -0000 Received: by jm (sSMTP sendmail emulation); Wed, 7 Feb 2007 20:07:42 -0800 Date: Wed, 7 Feb 2007 20:07:42 -0800 From: Jouni Malinen To: clancy@ltsnet.net, Hannes.Tschofenig@siemens.com Subject: Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-03.txt Message-ID: <20070208040742.GD6652@jm.kir.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Wed, Feb 07, 2007 at 03:50:02PM -0500, Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt This is starting to look quite good. Just couple of minor editorial comments at this point: 1. Introduction - s/I-D.vanderveen-eap-sake/RFC4763/ (and matching update for 14. References to move this into the normative list) 4. Key Derivation - s/needs to instantiated/needs to be instantiated/ -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 08 18:11:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIPo-0002vA-5c; Thu, 08 Feb 2007 18:10:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIPn-0002v0-PC for emu@ietf.org; Thu, 08 Feb 2007 18:10:55 -0500 Received: from web54405.mail.yahoo.com ([206.190.49.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFIPQ-0004g0-Hu for emu@ietf.org; Thu, 08 Feb 2007 18:10:55 -0500 Received: (qmail 8676 invoked by uid 60001); 8 Feb 2007 23:10:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=yJfiH9cO92gdRnDKW6waTw7iEKhfLtC/2E/wRbT5KYbOapJ8a9KMdu1vBmMCcxG3447YGceto82U9VpdUmepOTEULfcMse2fgR54knov++4iqpoH2m6RrbVti0emkUOK+suCEEFFwnTBO223Jw9a2yo0H9ff3jkWN6hxHoWp+ng= ; Message-ID: <20070208231032.8674.qmail@web54405.mail.yahoo.com> Received: from [67.181.83.189] by web54405.mail.yahoo.com via HTTP; Thu, 08 Feb 2007 15:10:32 PST X-Mailer: YahooMailRC/368.7 YahooMailWebService/0.6.132.7 Date: Thu, 8 Feb 2007 15:10:32 -0800 (PST) From: "M. Vanderveen" Subject: Re: [Emu] WG Last Call: draft-ietf-emu-eap-gpsk-03.txt To: "Joseph Salowey \(jsalowey\)" , emu@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1484625763==" Errors-To: emu-bounces@ietf.org --===============1484625763== Content-Type: multipart/alternative; boundary="0-424326384-1170976232=:8665" --0-424326384-1170976232=:8665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed the draft and found no problems.=0AMichaela=0A=0A=0A----- O= riginal Message ----=0AFrom: Joseph Salowey (jsalowey) = =0ATo: emu@ietf.org=0ASent: Wednesday, February 7, 2007 7:52:10 PM=0ASubjec= t: [Emu] WG Last Call: draft-ietf-emu-eap-gpsk-03.txt=0A=0A=0AThis is a wor= king group last call for draft-ietf-emu-eap-gpsk-03. =0A=0ASend your commen= ts to the EMU list by March 7, 2007. Please respond to=0Athis call even if= you have reviewed the draft and found no problems. =0A=0AThe document can= be accessed here:=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-emu-eap= -gpsk-03.txt=0A=0A_______________________________________________=0AEmu mai= ling list=0AEmu@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/emu=0A=0A= =0A =0A____________________________________________________________________= ________________=0AFinding fabulous fares is fun. =0ALet Yahoo! FareChase = search your favorite travel sites to find flight and hotel bargains.=0Ahttp= ://farechase.yahoo.com/promo-generic-14795097 --0-424326384-1170976232=:8665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed the draft and found no problems.
=0A
Michaela
=0A
----- Original Message ----
From: Joseph Salowey (js= alowey) <jsalowey@cisco.com>
To: emu@ietf.org
Sent: Wednesday, = February 7, 2007 7:52:10 PM
Subject: [Emu] WG Last Call: draft-ietf-emu-= eap-gpsk-03.txt

=0A
This is a working group last call for draft-= ietf-emu-eap-gpsk-03.

Send your comments to the EMU list by March 7= , 2007.  Please respond to
this call even if you have reviewed= the draft and found no problems.  

The document can be ac= cessed here:
http://www.ietf.org/internet-drafts/dra= ft-ietf-emu-eap-gpsk-03.txt

____________________________________= ___________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailma= n/listinfo/emu
=0A


=0A=0A
Don'= t pick lemons.
=0ASee all the new 2007 cars at Yahoo! Autos. --0-424326384-1170976232=:8665-- --===============1484625763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1484625763==-- From emu-bounces@ietf.org Fri Feb 09 09:23:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWev-0007zL-4L; Fri, 09 Feb 2007 09:23:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWet-0007zG-WA for emu@ietf.org; Fri, 09 Feb 2007 09:23:28 -0500 Received: from bay0-omc1-s31.bay0.hotmail.com ([65.54.246.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFWep-0000bd-L9 for emu@ietf.org; Fri, 09 Feb 2007 09:23:27 -0500 Received: from hotmail.com ([207.46.8.86]) by bay0-omc1-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 9 Feb 2007 06:23:23 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Feb 2007 06:23:22 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Fri, 09 Feb 2007 14:23:20 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20070208231032.8674.qmail@web54405.mail.yahoo.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Fri, 09 Feb 2007 06:23:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Feb 2007 14:23:22.0478 (UTC) FILETIME=[DA7B18E0:01C74C55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Emu] Review of draft-ietf-emu-eap-gpsk-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Review of draft-ietf-emu-eap-gpsk-03.txt Section 1 " At present, several pre-shared key EAP methods are specified, most notably o EAP-PAX [RFC4746] o EAP-PSK [I-D.bersani-eap-psk] o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and o EAP-SAKE [I-D.vanderveen-eap-sake]. Each method has its particular benefits but also its particular deficiencies. EAP-GPSK is a new EAP method that tries to combine the most valuable characteristics of each of these methods and therefore attempts to address a broad range of usage scenarios." I would delete this discussion since it doesn't really relate to the design goals of EAP-GPSK. As it stands, this statement is too vague to motivate the design, and discussion of "deficiencies" without providing justification is problematic. " EAP-GPSK should be easy to implement and therefore quickly available." I would leave out "and therefore quickly available". You might also provide some more info on what makes a method easy to implement, such as single purpose (PSK), use of commonly available algorithms, etc. " Wide applicability: EAP-GPSK has been designed in a threat model where the attacker has full control over the communication channel. This is the EAP threat model that is presented in Section 7.1 of [RFC3748]." I think a more appropriate title would be "Security model". Efficiency You might mention round-trips here. This section should also mention that Privacy is not supported. Section 4 In addition to the Method-Id, this section should define the Peer-Id (ID_Client), Server-Id (ID-Server) and Session-Id (Type-Code || MID). Section 5 SHA-1 is on a path to deprecation by NIST, so I am concerned about including this algorithm. The KDFs do not appear to comply with the NIST KDF recommendation included in this draft: http://www.watersprings.org/pub/id/draft-dang-nistkdf-01.txt Or am I not reading it correctly? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 13 13:36:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2VF-0004DY-N3; Tue, 13 Feb 2007 13:35:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2VE-0004DT-NR for emu@ietf.org; Tue, 13 Feb 2007 13:35:44 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2V8-00017F-Ub for emu@ietf.org; Tue, 13 Feb 2007 13:35:44 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 13 Feb 2007 10:35:38 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.24; Tue, 13 Feb 2007 10:35:38 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Tue, 13 Feb 2007 10:35:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 13 Feb 2007 10:35:24 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80037DB14B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQBeWv2AAJMb1cABOscogA== References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800403D769@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 13 Feb 2007 18:35:37.0487 (UTC) FILETIME=[C14D31F0:01C74F9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Comments in-line -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Tuesday, February 06, 2007 8:35 AM To: Ryan Hurst; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Hi Ryan, I understand the deprecation of subjectName in favor of SubjectAltName, this makes sense to me now. =20 =20 I'm still struggling a little with mapping subjectAltName and subjectName certificate fields to peer and server identities. I think the text you suggested for the server name subjectAltName mapping is good: =20 [rmh] How about we change "A subjectAltName of type iPAdress MAY be used [rmh] in the server certificate." To "If a dnsName is not available other [rmh] field types (for example a subjectAltName of type iPAdress or [rmh] uniformResourceIdentifier) MAY be used. I think we should have similar text for the peer name. There are cases where either or both the EAP peer and EAP server may be devices that do not have an RFC822 name or dnsName. =20 [rmh] Could you propose some text that would address your concern? [rmh] It was my hope that the following (from the original proposal) [rmh] would address this concern: =20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used. I am a bit concerned with the text for the subject DN. Why not use the same field for both server and peer certificates? In my experience the email address in a certificate subject DN is not always the best identifier. Could CN be used instead of email address? [rmh] CNs contain common names, for example my CN in the directory is Ryan Hurst, [rmh] this is the appropriate use of CN and as you can see this is not non-ambiguous [rmh] (there is a actor with the same name BTW). [rmh] Since servers do not have "common names" it is has become standard to put the [rmh] DNS name in the common name field instead of using a dNSName RDN (I am not even sure [rmh] one exists).=20 [rmh] In the case of user certificates clearly users have common names, and applications almost [rmh] universally expect this field to be present for display purposes. It's this reason the eMail=20 [rmh] address (when present in a DN) is put into its own RDN. [rmh] The proposed text is consistent with all certificate mapping implementations I have ever encountered, [rmh] and it should also be consistent with the HTTP over SSL RFC that prescribes much of the same. [rmh] In the end applications have one of two choices when doing mapping, map on the full subject DN or [rmh] map on the email address and we should not specify anything inconsistent with that as it will lead [rmh] to problems. =20 With regard to usage of OCSP, I understand the concern you raise. However, the current practice of retrieving a CRL when attached to the network and validating the accepted certificate seems to provide decent protection. The OCSP in TLS approach is a better approach, but how much better is it? A SHOULD is a fairly strong requirement and its use here may affect how quickly this document can move through the standards track. I want to make sure we are getting significant benefit from this added requirement.=20 [rmh] I understand the concern, and it's certainly a tricky balance trying to [rmh] do what is right for security and keeping the process streamlined but I would [rmh] think it would be best for us to lean towards security vs. process when crafting. [rmh] documents like this. OCSP is nearly a decade old, there are a dozen interoperable [rmh] implementations out there TLS 1.1 (also several years old now) which this document [rmh] takes a normative reference to supports the exchange of OCSP messages for this=20 [rmh] exact case.=20 [rmh] As for the OCSP stapling approach vs the post connect revocation (CRL or OCSP)=20 [rmh] check approach, the difference is that with the OCSP approach you get to know if [rmh] your at risk before you present your credentials, etc but with the post check approach [rmh] you only know once the damage is done. Joe ________________________________ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Monday, February 05, 2007 1:04 PM To: emu@ietf.org Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =09 =09 Joe - For some reason I didn't get your email, I found it on the archives; bellow are the questions from that mail and my answers: =20 Where the subjectAltName field is present in the peer or Server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as per Section 5.3. =20 =20 [Joe] Why subjectAltName and not Subject? =20 [rmh] The use of the subject name was intended to represent a directory location, directory locations may or may not include the a value that would reasonable map to the subject id (eg a E rdn). its bad form to require people to change their directory layout to deploy a application, therefore standards that take a dependency on a specific name form being present in a certificate should do so by specifying that name form exist in the subjectAltName. =20 If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a E RDN containing the Peer-Id. =20 [Joe] What is E RDN? =20 [rmh] RDN is a relative distinguished name, DNs are made up of these; There is a RDN is for the email address, I don't have the X.500 documents handy but its defined in there. I remember the name being just E; however I did some googling and looks like I was wrong its emailAddress. =20 Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. =20 [Joe] Are there other standards that are deprecating the use of subject field as well? (This is related to my first question above.) =20 [rmh] uid is the only other RDN that a peer-id like value that might be used in [rmh] however in practice I have never seen this used; see my other comment as [rmh] to why. This is one of the reasons other rfcs like TLS deprecate use of the [rmh] subject dn for subjectAltName instead (see 3.1 of http://www.ietf.org/rfc/rfc2818.txt) =20 =20 Where the peer identity represents a host, a subjectAltName of type dNSName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 =20 [Joe] There may be hosts which do not have a DNSName or Ipaddress (L2 entities), so I think we need to clarify the above text. =20 [rmh] This text does not preclude the inclusion of other name forms=20 [rmh] it even allows for it by saying other types can be included. [rmh] It is important to encourage a name form be included for interop sake [rmh] dnsName and rfc822 is clearly the most common in existing deployments=20 [rmh] so including it seems appropriate. =20 [rmh] There should be some text in the security consideration section [rmh] about the MITM risks associated with making a trust decision [rmh] on unauthenticated values you have at L2. =20 A server identity will typically represent a host, not a user Or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. A subjectAltName of Type iPAdress MAY be used in the server certificate.=20 =20 [Joe] We probably need to allow various name types for the server as well. I think there still needs to be some discussion on how subjectAltNames map to peer and server names in the case where there are multiple subjectAltNames. =20 [rmh] How about we change "A subjectAltName of type iPAdress MAY be used [rmh] in the server certificate." To "If a dnsName is not available other [rmh] field types (for example a subjectAltName of type iPAdress or [rmh] uniformResourceIdentifier) MAY be used. =20 5.4. Certificate revocation =20 Certificates are long lived assertions of identity.=20 Therefore it is important for EAP-TLS implementations to=20 be capable of checking whether these assertions have been=20 revoked.=20 =20 EAP-TLS peer and server implementations MUST support the=20 use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server=20 implementations SHOULD also support the Online=20 Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten connection times especially in bandwidth constrained environments. =20 While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes. =20 =20 [Joe] This is somewhat different than what the current draft has specified up until now. I am a little uneasy with OCSP as a SHOULD, are there other specifications which have such a strong recommendation for OCSP? =20 [rmh] I know of no other RFC that uses SHOULD for OCSP, however I know of [rmh] no other protocol in which its primary use case prevents a client from [rmh] checking the revocation status of the server. The use of OCSP and TLS [rmh] extensions enables this client to do this check. =20 [rmh] The SHOULD is a response to this security risk, weaker wording would be [rmh] the same as saying MAY choose to be vulnerable to these attacks, SHOULD [rmh] allows vendors to choose not to do so while encouraging them to address [rmh] these risks. =20 [rmh] There are also the latency and timing issues associated with network connections [rmh] make the download of 800k CRLs before a connect can happen is a deal breaker, [rmh] a few K (as little as 400 bytes) for a OCSP response is a much better deal. =20 [rmh] I feel strongly the RFC needs to provide guidance on how to use certificates [rmh] securely and in a deployable way. [rmh] I appreciate that not all implementations do this but that is why its [rmh] not a MUST. =20 For this reason EAP-TLS peers and servers SHOULD implement=20 Certificate Status Request messages, as described in [RFC3546]=20 section 3.6. To enable revocation checking in situations=20 where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer=20 implementations SHOULD also support checking for certificate=20 revocation after authentication completes and network connectivity=20 is available, and SHOULD utilize this capability.=20 =20 [Joe] A strong recommendation for TLS extensions is somewhat counter to some of the discussions we have had in the past about keeping EAP-TLS as bare bones as possible. I would like to hear other's opinion on this.=20 =20 [rmh] See my earlier comment on the security risks associated with the use [rmh] scenarios for this protocol, its dependency on certificates at layer 2, [rmh] and the clients inability to perform revocation checking. [rmh] The use of OCSP and the TLS extension addresses this risk. =20 =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 13 13:59:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2rj-0007TH-8M; Tue, 13 Feb 2007 13:58:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2ri-0007TC-4A for emu@ietf.org; Tue, 13 Feb 2007 13:58:58 -0500 Received: from bay0-omc1-s2.bay0.hotmail.com ([65.54.246.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2rf-0003Or-R6 for emu@ietf.org; Tue, 13 Feb 2007 13:58:58 -0500 Received: from hotmail.com ([207.46.8.90]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 13 Feb 2007 10:58:55 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Feb 2007 10:58:55 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 13 Feb 2007 18:58:51 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80037DB14B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 13 Feb 2007 10:58:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Feb 2007 18:58:55.0027 (UTC) FILETIME=[024CE030:01C74FA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Question: What about a device that has a MAC address as a name? Use of EAP-TLS with MAC certificates is being discussed in WiMAX Forum and IEEE 802.1AR. Where should the MAC address be placed (subject vs. subjectAltName) and what field type should it have? Is there a reference that defines the formatting of field types? Is there guidance on how to format the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs. 00:03:7B:5F:CE:73 in IEEE 802.1AR). _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 13 15:18:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH46F-00055R-Fh; Tue, 13 Feb 2007 15:18:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH46D-000552-KI for emu@ietf.org; Tue, 13 Feb 2007 15:18:01 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH46C-0003XR-4p for emu@ietf.org; Tue, 13 Feb 2007 15:18:01 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Feb 2007 12:17:58 -0800 X-IronPort-AV: i="4.14,163,1170662400"; d="scan'208"; a="112259898:sNHT46652373" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1DKHwdT023925; Tue, 13 Feb 2007 12:17:58 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1DKHnGo006443; Tue, 13 Feb 2007 12:17:58 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 12:17:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 13 Feb 2007 12:17:55 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 13 Feb 2007 20:17:56.0595 (UTC) FILETIME=[0C7EBC30:01C74FAC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1160; t=1171397878; x=1172261878; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=j/eGHjfOQTKKvvRyiNYzYi4CWyunfQHFipn+L+K5sPE=; b=BXiwypIY7UWz6TBshmhXXjdfCEjrGl0oFaQY8W+Nca+nE99UV6yiz96RBj+bWKhWJ8rNur/N OkWWiZ3FDJ62anrscy6KOy6NV63773N8j6S4JY9Q7po+tv3COwEJwceC; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org 802.1AR is not specifying that a device identity within a certificate has to be a MAC address. It can be any identifier that is unique within a manufacturer's domain. The current thinking is that the identity would go in the common name of the subject name.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, February 13, 2007 10:59 AM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Question: >=20 > What about a device that has a MAC address as a name? Use of=20 > EAP-TLS with MAC certificates is being discussed in WiMAX=20 > Forum and IEEE 802.1AR. Where should the MAC address be=20 > placed (subject vs. subjectAltName) and what field type=20 > should it have? Is there a reference that defines the=20 > formatting of field types? Is there guidance on how to format=20 > the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs.=20 > 00:03:7B:5F:CE:73 in IEEE 802.1AR). >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 13 16:40:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5OJ-0003QV-4P; Tue, 13 Feb 2007 16:40:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5OH-0003Py-2b for emu@ietf.org; Tue, 13 Feb 2007 16:40:45 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5OD-0000Za-7j for emu@ietf.org; Tue, 13 Feb 2007 16:40:45 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 13 Feb 2007 13:40:40 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.24; Tue, 13 Feb 2007 13:40:40 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Tue, 13 Feb 2007 13:40:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 13 Feb 2007 13:38:02 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423F5AA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/A= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 13 Feb 2007 21:40:39.0691 (UTC) FILETIME=[9ABB15B0:01C74FB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I am not sure the MAC address is directly relevant to this effort, as long as we allow for alternate bindings to be used (I think the text I proposed does this) then these problems can be dealt with in other documents. As for the MAC address as a identifier, I actually am not a fan; from what I can tell it has been added to facilitate better certificate selection but there are much better ways to achieve that; I have been tempted to write a informational on how proper certificate selection is done but have not had the time. The problem with a MAC address is that certificates normally contain bindings of entitlements or constraints, these are all assertions that the CA can stand behind (I have verified that the holder of this key has the rights to this fqdn, I have verified he is entitled to represent that FQDN for server TLS transactions, etc.). You just can't do that with a MAC address, not in any reasonable way; now device identity is a SUPER important thing without it we will continue to take dependencies on weak identifiers like MAC addresses to perform exceptions and entitlements (which essentially throw out any security value modern isolation solutions provide) so the work being done by AR is important. As for where AR puts the identity, generally speaking you should be able to tell what is in a RDN given a certificate usage; so if AR has a EKU for Device Authentication I suppose its fine for it to say when this EKU is present the RDN CN has special meaning, otherwise it should go elsewhere. Actually now that I think about it I would suggest that they go in subjectAltName; again the general thinking about Subject DNs is they map to a directory entity; this isn't always the case and its likely not the case with a device certificate (many assumptions in this statement so be kind), in such cases its probably more appropriate to have a empty Subject DN and use a existing name form (urn, etc.) in subjectAltName or define a new name form for the subjectAltName extension. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Tuesday, February 13, 2007 12:18 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt 802.1AR is not specifying that a device identity within a certificate has to be a MAC address. It can be any identifier that is unique within a manufacturer's domain. The current thinking is that the identity would go in the common name of the subject name.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, February 13, 2007 10:59 AM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Question: >=20 > What about a device that has a MAC address as a name? Use of=20 > EAP-TLS with MAC certificates is being discussed in WiMAX=20 > Forum and IEEE 802.1AR. Where should the MAC address be=20 > placed (subject vs. subjectAltName) and what field type=20 > should it have? Is there a reference that defines the=20 > formatting of field types? Is there guidance on how to format=20 > the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs.=20 > 00:03:7B:5F:CE:73 in IEEE 802.1AR). >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 13 17:31:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6Bo-00011V-92; Tue, 13 Feb 2007 17:31:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6Bm-0000x8-TJ for emu@ietf.org; Tue, 13 Feb 2007 17:31:54 -0500 Received: from mail709.megamailservers.com ([69.49.98.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH6Bk-0007IU-3i for emu@ietf.org; Tue, 13 Feb 2007 17:31:54 -0500 X-Authenticated-User: ray.grid-net.com Received: from RBLAPTOP (h-68-167-203-99.snfccasy.covad.net [68.167.203.99]) (authenticated bits=0) by mail709.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id l1DMVk8j009810; Tue, 13 Feb 2007 17:31:49 -0500 From: "Ray Bell" To: "'Ryan Hurst'" , "'Joseph Salowey \(jsalowey\)'" , "'Bernard Aboba'" , Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 13 Feb 2007 14:31:42 -0800 Message-ID: <001f01c74fbe$bd9eccf0$63cba744@RBLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/AAAgRu4A== In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423F5AA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The CableLabs Device PKI process should be considered... http://www.cablelabs.com/certqual/security/ Ray -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] Sent: Tuesday, February 13, 2007 1:38 PM To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt I am not sure the MAC address is directly relevant to this effort, as long as we allow for alternate bindings to be used (I think the text I proposed does this) then these problems can be dealt with in other documents. As for the MAC address as a identifier, I actually am not a fan; from what I can tell it has been added to facilitate better certificate selection but there are much better ways to achieve that; I have been tempted to write a informational on how proper certificate selection is done but have not had the time. The problem with a MAC address is that certificates normally contain bindings of entitlements or constraints, these are all assertions that the CA can stand behind (I have verified that the holder of this key has the rights to this fqdn, I have verified he is entitled to represent that FQDN for server TLS transactions, etc.). You just can't do that with a MAC address, not in any reasonable way; now device identity is a SUPER important thing without it we will continue to take dependencies on weak identifiers like MAC addresses to perform exceptions and entitlements (which essentially throw out any security value modern isolation solutions provide) so the work being done by AR is important. As for where AR puts the identity, generally speaking you should be able to tell what is in a RDN given a certificate usage; so if AR has a EKU for Device Authentication I suppose its fine for it to say when this EKU is present the RDN CN has special meaning, otherwise it should go elsewhere. Actually now that I think about it I would suggest that they go in subjectAltName; again the general thinking about Subject DNs is they map to a directory entity; this isn't always the case and its likely not the case with a device certificate (many assumptions in this statement so be kind), in such cases its probably more appropriate to have a empty Subject DN and use a existing name form (urn, etc.) in subjectAltName or define a new name form for the subjectAltName extension. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Tuesday, February 13, 2007 12:18 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt 802.1AR is not specifying that a device identity within a certificate has to be a MAC address. It can be any identifier that is unique within a manufacturer's domain. The current thinking is that the identity would go in the common name of the subject name. > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, February 13, 2007 10:59 AM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > Question: > > What about a device that has a MAC address as a name? Use of > EAP-TLS with MAC certificates is being discussed in WiMAX > Forum and IEEE 802.1AR. Where should the MAC address be > placed (subject vs. subjectAltName) and what field type > should it have? Is there a reference that defines the > formatting of field types? Is there guidance on how to format > the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs. > 00:03:7B:5F:CE:73 in IEEE 802.1AR). > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 10:37:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMCf-0002ov-VW; Wed, 14 Feb 2007 10:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMCc-0002oW-Q8 for emu@ietf.org; Wed, 14 Feb 2007 10:37:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHMCb-00048z-7Q for emu@ietf.org; Wed, 14 Feb 2007 10:37:50 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2007 07:37:48 -0800 X-IronPort-AV: i="4.14,169,1170662400"; d="scan'208"; a="39446768:sNHT58402890" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1EFbmSj014485; Wed, 14 Feb 2007 07:37:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1EFbmnF011917; Wed, 14 Feb 2007 07:37:48 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 07:37:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 14 Feb 2007 07:37:47 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80037DB14B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQBeWv2AAJMb1cABOscogABWV8PA From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , X-OriginalArrivalTime: 14 Feb 2007 15:37:48.0371 (UTC) FILETIME=[146D0A30:01C7504E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7174; t=1171467468; x=1172331468; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=8QFyomG6At9idv/svFYfVcbEAs9Rg8PGLVnwFCZ+8Jc=; b=kmEiO5BjqbSFadfmXhmzsbpk9i6Z+XGkzuV06eiqczerWYqSZGXefmb5zLLEHlfPgYo3lE9q QPfEBqNSFZvIRxfLkO1+hTotbMFwjzw+EloyNJgsLryK8tE2NsU4Fl1c; Authentication-Results: sj-dkim-8; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Comments inline below. > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Tuesday, February 13, 2007 10:35 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Comments in-line >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Tuesday, February 06, 2007 8:35 AM > To: Ryan Hurst; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Hi Ryan, >=20 > I understand the deprecation of subjectName in favor of=20 > SubjectAltName, > this makes sense to me now. =20 > =20 > I'm still struggling a little with mapping subjectAltName and > subjectName certificate fields to peer and server identities. I think > the text you suggested for the server name subjectAltName mapping is > good: > =20 > [rmh] How about we change "A subjectAltName of type=20 > iPAdress MAY > be used > [rmh] in the server certificate." To "If a dnsName is not > available other > [rmh] field types (for example a subjectAltName of=20 > type iPAdress > or > [rmh] uniformResourceIdentifier) MAY be used. >=20 > I think we should have similar text for the peer name. There=20 > are cases > where either or both the EAP peer and EAP server may be=20 > devices that do > not have an RFC822 name or dnsName. =20 >=20 > [rmh] Could you propose some text that would address your > concern? > [rmh] It was my hope that the following (from the original > proposal) > [rmh] would address this concern: > =20 > If the peer identity represents neither a host nor a > user, another field > type (for example a subjectAltName of type iPAddress > or uniformResourceIdentifier) MAY be used. >=20 [Joe] OK, I think it does. Here is what I have for the text around SubjectAltName "Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use=20 the subjectAltName field instead. Where the peer identity represents a host, a subjectAltName of type=20 dNSName SHOULD be present in the peer certificate. Where the peer=20 identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used." >=20 > I am a bit concerned with the text for the subject DN. Why=20 > not use the > same field for both server and peer certificates? In my=20 > experience the > email address in a certificate subject DN is not always the best > identifier. Could CN be used instead of email address? >=20 > [rmh] CNs contain common names, for example my CN in the > directory is Ryan Hurst, > [rmh] this is the appropriate use of CN and as you can see this > is not non-ambiguous > [rmh] (there is a actor with the same name BTW). >=20 > [rmh] Since servers do not have "common names" it is has become > standard to put the > [rmh] DNS name in the common name field instead of using a > dNSName RDN (I am not even sure > [rmh] one exists).=20 >=20 > [rmh] In the case of user certificates clearly users have common > names, and applications almost > [rmh] universally expect this field to be present for display > purposes. It's this reason the eMail=20 > [rmh] address (when present in a DN) is put into its own RDN. >=20 > [rmh] The proposed text is consistent with all certificate > mapping implementations I have ever encountered, > [rmh] and it should also be consistent with the HTTP over SSL > RFC that prescribes much of the same. >=20 [Joe] With certificates embedded in device the email address portion of the DN is not used so consistently, it does not typically refer to the email address of the device but rather of an organization.=20 > [rmh] In the end applications have one of two choices when doing > mapping, map on the full subject DN or > [rmh] map on the email address and we should not specify > anything inconsistent with that as it will lead > [rmh] to problems. >=20 [Joe] It seems that mapping on the full subject DN may be more appropriate in this case since the processor may not know if the peer cert represents a device or user identity.=20 =20 >=20 > With regard to usage of OCSP, I understand the concern you raise. > However, the current practice of retrieving a CRL when attached to the > network and validating the accepted certificate seems to=20 > provide decent > protection. The OCSP in TLS approach is a better approach,=20 > but how much > better is it? A SHOULD is a fairly strong requirement and=20 > its use here > may affect how quickly this document can move through the standards > track. I want to make sure we are getting significant=20 > benefit from this > added requirement.=20 >=20 > [rmh] I understand the concern, and it's certainly a tricky balance > trying to > [rmh] do what is right for security and keeping the process=20 > streamlined > but I would > [rmh] think it would be best for us to lean towards security=20 > vs. process > when crafting. > [rmh] documents like this. OCSP is nearly a decade old, there are a > dozen interoperable > [rmh] implementations out there TLS 1.1 (also several years old now) > which this document > [rmh] takes a normative reference to supports the exchange of OCSP > messages for this=20 > [rmh] exact case.=20 >=20 > [rmh] As for the OCSP stapling approach vs the post connect revocation > (CRL or OCSP)=20 > [rmh] check approach, the difference is that with the OCSP=20 > approach you > get to know if > [rmh] your at risk before you present your credentials, etc=20 > but with the > post check approach > [rmh] you only know once the damage is done. >=20 [Joe] With EAP-TLS the peer credentials are certificate based credentials, I don't see much risk in using these. With EAP-TLS you can defer presenting other credentials or performing operations that are a higher risk until after you have obtained the latest CRL. This is different than something like PEAP or TTLS which presents weak credentials before the network connection is available. I don't think we should bring in new requirements into EAP-TLS unless they are absolutely necessary. I think it may be appropriate to have a stronger requirement for an enhanced TLS method or a password based method that uses TLS.=20 I think we probably need to start a separate thread on this topic.=20 >=20 > Joe >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 13:47:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPAJ-0005xP-0d; Wed, 14 Feb 2007 13:47:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPAH-0005xD-Id for emu@ietf.org; Wed, 14 Feb 2007 13:47:37 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHPAC-0005NE-Vp for emu@ietf.org; Wed, 14 Feb 2007 13:47:37 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 14 Feb 2007 10:47:32 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Wed, 14 Feb 2007 10:47:31 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 14 Feb 2007 10:47:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 14 Feb 2007 10:46:28 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FA73@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdGQGoMIROVKjSxRKSiWHsnAxWBPQBeWv2AAJMb1cABOscogABWV8PAAAaP0dA= References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80037DB14B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 14 Feb 2007 18:47:31.0360 (UTC) FILETIME=[95375200:01C75068] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, even more comments in-line: -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, February 14, 2007 7:38 AM To: Ryan Hurst; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Comments inline below. > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Tuesday, February 13, 2007 10:35 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Comments in-line >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Tuesday, February 06, 2007 8:35 AM > To: Ryan Hurst; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Hi Ryan, >=20 > I understand the deprecation of subjectName in favor of=20 > SubjectAltName, > this makes sense to me now. =20 > =20 > I'm still struggling a little with mapping subjectAltName and > subjectName certificate fields to peer and server identities. I think > the text you suggested for the server name subjectAltName mapping is > good: > =20 > [rmh] How about we change "A subjectAltName of type=20 > iPAdress MAY > be used > [rmh] in the server certificate." To "If a dnsName is not > available other > [rmh] field types (for example a subjectAltName of=20 > type iPAdress > or > [rmh] uniformResourceIdentifier) MAY be used. >=20 > I think we should have similar text for the peer name. There=20 > are cases > where either or both the EAP peer and EAP server may be=20 > devices that do > not have an RFC822 name or dnsName. =20 >=20 > [rmh] Could you propose some text that would address your > concern? > [rmh] It was my hope that the following (from the original > proposal) > [rmh] would address this concern: > =20 > If the peer identity represents neither a host nor a > user, another field > type (for example a subjectAltName of type iPAddress > or uniformResourceIdentifier) MAY be used. >=20 [Joe] OK, I think it does. Here is what I have for the text around SubjectAltName "Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use=20 the subjectAltName field instead. Where the peer identity represents a host, a subjectAltName of type=20 dNSName SHOULD be present in the peer certificate. Where the peer=20 identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used.=20 A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used." [rmh] OK, after this mail I will create a revised block of text that incorporates all the changes we have discussed up until this point and send it to the list. >=20 > I am a bit concerned with the text for the subject DN. Why=20 > not use the > same field for both server and peer certificates? In my=20 > experience the > email address in a certificate subject DN is not always the best > identifier. Could CN be used instead of email address? >=20 > [rmh] CNs contain common names, for example my CN in the > directory is Ryan Hurst, > [rmh] this is the appropriate use of CN and as you can see this > is not non-ambiguous > [rmh] (there is a actor with the same name BTW). >=20 > [rmh] Since servers do not have "common names" it is has become > standard to put the > [rmh] DNS name in the common name field instead of using a > dNSName RDN (I am not even sure > [rmh] one exists).=20 >=20 > [rmh] In the case of user certificates clearly users have common > names, and applications almost > [rmh] universally expect this field to be present for display > purposes. It's this reason the eMail=20 > [rmh] address (when present in a DN) is put into its own RDN. >=20 > [rmh] The proposed text is consistent with all certificate > mapping implementations I have ever encountered, > [rmh] and it should also be consistent with the HTTP over SSL > RFC that prescribes much of the same. >=20 [Joe] With certificates embedded in device the email address portion of the DN is not used so consistently, it does not typically refer to the email address of the device but rather of an organization.=20 [rmh] this should be fine since it is not MUST and the text explicitly allows for alternate name forms to be used; you just can't have interoperability in the mainline case without recommending at least one name form per role; we clearly don't want to exclude other scenarios but we want to encourage interoperability. > [rmh] In the end applications have one of two choices when doing > mapping, map on the full subject DN or > [rmh] map on the email address and we should not specify > anything inconsistent with that as it will lead > [rmh] to problems. >=20 [Joe] It seems that mapping on the full subject DN may be more appropriate in this case since the processor may not know if the peer cert represents a device or user identity.=20 [rmh] It actually depends on the scenario, but both the full dn and email model are legitimate (as are a few others, for example we have a UPN and a SPN we can plausibly do mapping on also) we shouldn't prevent other models from being used; I would just trying to explain why a different model is used for server vs client. =20 >=20 > With regard to usage of OCSP, I understand the concern you raise. > However, the current practice of retrieving a CRL when attached to the > network and validating the accepted certificate seems to=20 > provide decent > protection. The OCSP in TLS approach is a better approach,=20 > but how much > better is it? A SHOULD is a fairly strong requirement and=20 > its use here > may affect how quickly this document can move through the standards > track. I want to make sure we are getting significant=20 > benefit from this > added requirement.=20 >=20 > [rmh] I understand the concern, and it's certainly a tricky balance > trying to > [rmh] do what is right for security and keeping the process=20 > streamlined > but I would > [rmh] think it would be best for us to lean towards security=20 > vs. process > when crafting. > [rmh] documents like this. OCSP is nearly a decade old, there are a > dozen interoperable > [rmh] implementations out there TLS 1.1 (also several years old now) > which this document > [rmh] takes a normative reference to supports the exchange of OCSP > messages for this=20 > [rmh] exact case.=20 >=20 > [rmh] As for the OCSP stapling approach vs the post connect revocation > (CRL or OCSP)=20 > [rmh] check approach, the difference is that with the OCSP=20 > approach you > get to know if > [rmh] your at risk before you present your credentials, etc=20 > but with the > post check approach > [rmh] you only know once the damage is done. >=20 [Joe] With EAP-TLS the peer credentials are certificate based credentials, I don't see much risk in using these. With EAP-TLS you can defer presenting other credentials or performing operations that are a higher risk until after you have obtained the latest CRL. This is different than something like PEAP or TTLS which presents weak credentials before the network connection is available. I don't think we should bring in new requirements into EAP-TLS unless they are absolutely necessary. I think it may be appropriate to have a stronger requirement for an enhanced TLS method or a password based method that uses TLS.=20 [rmh] First the text does not mandate it only suggests (SHOULD vs MUST); to your point about client certificates somehow mitigating this issue it's not true, the 3280 hierarchical PKI trust model presumes that revocation checking is done by the relying party before trust decisions are made about the credential, this is due to the fact that these certificates are long lived and are subject to compromise post issuance (the older a cert is the less trust that should be placed in it); not doing this check so or doing post checking exposes you this risk while checking before you believe the credential does not. [rmh] I would agree that as a bis it would be inappropriate for us to mandate something new like this (for interop reasons) but providing a strong recommendation seems to be appropriate. I think we probably need to start a separate thread on this topic.=20 >=20 > Joe >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 15:27:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQio-0002JS-82; Wed, 14 Feb 2007 15:27:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQim-0002Iw-Aa for emu@ietf.org; Wed, 14 Feb 2007 15:27:20 -0500 Received: from bay0-omc3-s8.bay0.hotmail.com ([65.54.246.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQij-00074v-0h for emu@ietf.org; Wed, 14 Feb 2007 15:27:20 -0500 Received: from hotmail.com ([207.46.8.99]) by bay0-omc3-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 14 Feb 2007 12:27:16 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Feb 2007 12:27:15 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 14 Feb 2007 20:27:11 GMT X-Originating-IP: [71.112.18.224] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FA73@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 14 Feb 2007 12:27:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Feb 2007 20:27:15.0798 (UTC) FILETIME=[84381760:01C75076] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org If possible, I'd like to include text arising from this thread in the -08 version of the document, submitted by the IETF 68 deadline. To make it easier for me to figure out what that text is, it would be helpful for someone to post the suggested changes in their entirety, with modifications agreed to during the discussion. Further comments can then refer to that text, suggesting specific changes. Having that record on the mailing list will make it a lot easier for me to figure out what changes to make to the document. Thanks in advance, Bernard _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 16:12:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRQU-0003e1-Mt; Wed, 14 Feb 2007 16:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRQT-0003dm-Sz for emu@ietf.org; Wed, 14 Feb 2007 16:12:29 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHRPz-0004EN-Di for emu@ietf.org; Wed, 14 Feb 2007 16:12:29 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 14 Feb 2007 13:11:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 14 Feb 2007 13:11:39 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 14 Feb 2007 13:11:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 14 Feb 2007 13:11:36 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FC3F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmog References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FA73@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: Bernard Aboba , X-OriginalArrivalTime: 14 Feb 2007 21:11:38.0030 (UTC) FILETIME=[B70874E0:01C7507C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I will do this before I go home today. -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, February 14, 2007 12:27 PM To: emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt If possible, I'd like to include text arising from this thread in the -08=20 version of the document, submitted by the IETF 68 deadline. To make it easier for me to figure out what that text is, it would be=20 helpful for someone to post the suggested changes in their entirety, with=20 modifications agreed to during the discussion. Further comments can then=20 refer to that text, suggesting specific changes. Having that record on the mailing list will make it a lot easier for me to=20 figure out what changes to make to the document. Thanks in advance, Bernard _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 18:01:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHT7U-0006LF-4D; Wed, 14 Feb 2007 18:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHT7T-0006L9-Hm for emu@ietf.org; Wed, 14 Feb 2007 18:00:59 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHT7P-00017v-VI for emu@ietf.org; Wed, 14 Feb 2007 18:00:59 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 14 Feb 2007 15:00:55 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 14 Feb 2007 15:00:55 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 14 Feb 2007 15:00:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 14 Feb 2007 15:00:15 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FD48@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FC3F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmogAALnjJA= References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FA73@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FC3F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: Ryan Hurst , Bernard Aboba , X-OriginalArrivalTime: 14 Feb 2007 23:00:54.0649 (UTC) FILETIME=[FB151E90:01C7508B] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard - I believe this block of text represents the changes we have discussed in the thread, I would use it in your next release. "5.2 Peer and Server Identities =20 The EAP-TLS peer name (Peer-Id) represents the identity to be=20 used for access control and accounting purposes. The Server-Id=20 represents the identity of the EAP server. =20 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. =20 Where the subjectAltName field is present in the peer or server=20 certificate, the Peer-Id or Server-Id MUST be set to the contents=20 of the subjectAltName as per Section 5.3. =20 =20 If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a emailAddress RDN containing the Peer-Id and the Subject Field of the server certificate MUST contain the CN RDN containing the Server-ID. If subject naming information is present only in the subjectAltName extension then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical.=20 =20 Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use=20 the subjectAltName field instead. =20 Where the peer identity represents a host, a subjectAltName of type=20 dNSName SHOULD be present in the peer certificate. Where the peer=20 identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.=20 If a dnsName or rfc822Name are not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used.=20 5.3. Certificate Validation =20 Since the EAP-TLS server is typically connected to the Internet, it SHOULD support validating the peer certificate using=20 RFC 3280 [RFC3280] conformant path validation, including the=20 ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details,=20 see [RFC3280] Section 4.2.2.1. =20 Where the EAP-TLS server is unable to retrieve intermediate certificates, it must be pre-configured with the necessary=20 intermediate certificates to complete path validation or=20 rely on the EAP-TLS peer to provide this information as=20 part of the TLS Handshake (see [RFC4346] section 7.4.6). =20 In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore the EAP-TLS server=20 SHOULD provide its entire certificate chain minus the root to=20 facilitate certificate validation by the peer. =20 Once a TLS session is established EAP-TLS peer and server=20 implementations MUST validate that the identities represented=20 in the certificate are appropriate and authorized for=20 use with EAP-TLS. The authorization process makes=20 use of the contents of the certificates as well=20 as other contextual information. While authorization=20 requirements will vary from deployment to deployment=20 it is RECOMMENDED that implementations be able to=20 authorize based on the EAP-TLS Peer-Id and Server-Id=20 determined as described in Section 5.2.=20 =20 In the case of the EAP-TLS peer this involves ensuring=20 that the certificate presented by the EAP-TLS server was=20 intended to be used as a server certificate. Implementations SHOULD use the Extended Key=20 Usage (see [RFC3280] section 4.2.1.13)=20 extension and ensure that at least one of the=20 following is true: =20 1) The certificate issuer included no Extended Key Usage=20 identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier=20 in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-serverAuth identifier=20 in the certificate (See [RFC3280] section 4.2.1.13). When performing this comparison implementations MUST follow the=20 validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate=20 presented by the EAP-TLS peer was intended to be used as a=20 client certificate. Implementations SHOULD use the Extended=20 Key Usage (see [RFC3280] Section 4.2.1.13) extension and=20 ensure that at least one of the following is true: =20 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate=20 (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate=20 (see [RFC3280] section 4.2.1.13). =20 5.4. Certificate revocation =20 Certificates are long lived assertions of identity.=20 Therefore it is important for EAP-TLS implementations to=20 be capable of checking whether these assertions have been=20 revoked.=20 =20 EAP-TLS peer and server implementations MUST support the=20 use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server=20 implementations SHOULD also support the Online=20 Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten=20 connection times especially in bandwidth constrained environments. While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes.=20 In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. =20 However, in the case where the EAP-TLS peer is attempting to obtain network access, it will not have network connectivity and is therefore not capable of checking for certificate revocation until after authentication completes and network connectivity is available. =20 For this reason EAP-TLS peers and servers SHOULD implement=20 Certificate Status Request messages, as described in [RFC3546]=20 section 3.6. To enable revocation checking in situations=20 where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer=20 implementations SHOULD also support checking for certificate=20 revocation after authentication completes and network connectivity=20 is available, and SHOULD utilize this capability. " -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Wednesday, February 14, 2007 1:12 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt I will do this before I go home today. -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, February 14, 2007 12:27 PM To: emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt If possible, I'd like to include text arising from this thread in the -08=20 version of the document, submitted by the IETF 68 deadline. To make it easier for me to figure out what that text is, it would be=20 helpful for someone to post the suggested changes in their entirety, with=20 modifications agreed to during the discussion. Further comments can then=20 refer to that text, suggesting specific changes. Having that record on the mailing list will make it a lot easier for me to=20 figure out what changes to make to the document. Thanks in advance, Bernard _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 18:08:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTF3-0000lS-5D; Wed, 14 Feb 2007 18:08:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTF2-0000lN-E7 for emu@ietf.org; Wed, 14 Feb 2007 18:08:48 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTF1-0002cj-49 for emu@ietf.org; Wed, 14 Feb 2007 18:08:48 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2007 15:08:46 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="360991438:sNHT319219292" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1EN8klV014488 for ; Wed, 14 Feb 2007 15:08:46 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1EN8XEK021856 for ; Wed, 14 Feb 2007 15:08:46 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 15:08:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Feb 2007 15:08:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP-TLS and OCSP Thread-Index: AcdQjRJOnw0bOYUcSvGgENsPxK15lg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 14 Feb 2007 23:08:45.0276 (UTC) FILETIME=[139919C0:01C7508D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=941; t=1171494526; x=1172358526; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20EAP-TLS=20and=20OCSP |Sender:=20; bh=EXl6A7rlfY2lto9IkvRCTimPLqDfVibMDtmffcBBSac=; b=KW61TvLUCXZUGQzZFyr5/roF9lC8ny/sy/nFKP/s3R8EwsSqHlCx/0djTvXnMRq0DgvpV6+p NELPnf8CeVTNvTyS3Lr92RNf2Ae2Dp8WJ/JvmMaHl8Lp9BZ5vgkn8cai; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Emu] EAP-TLS and OCSP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Currently EAP-TLS does not require OCSP. Ryan has requested that we make support for the OCSP TLS (RFC4366 - section 3.6) extension a SHOULD implement in EAP-TLS. =20 The benefit of this is that it allows the peer to check for certificate revocation before it has access to the network. Without this if the peer does not have an up to date CRL it must defer revocation checking until it has network access and can receive an up to date CRL. The peer must limit its trust of the security of its network connection until it can access the CRL. =20 The downside of this is that it places a new requirement on EAP-TLS implementations. Even though it is a SHOULD and not a MUST it is important to realize that a SHOULD is a requirement to implement unless there are circumstances which make this requirement not apply to a particular situation. =20 I would like to here views from the working group on this topic. Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 18:25:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTVc-0006J3-IZ; Wed, 14 Feb 2007 18:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTVb-0006FL-C4 for emu@ietf.org; Wed, 14 Feb 2007 18:25:55 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTVY-0004r7-9C for emu@ietf.org; Wed, 14 Feb 2007 18:25:55 -0500 Received: by ug-out-1314.google.com with SMTP id 72so378144ugd for ; Wed, 14 Feb 2007 15:25:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Z29gy3DnRCuK8r2I13tWsII5C7fE2F+uMXCpPYlJ89DckzMV+0TSPDjyrr/0bB7EoAlwMGM4dH1gZonxbgnCTRGHFIrWY2tsRaH/kN7bL+8NDBCLFN2YxHAT/gft1R4nT9T2F8UqMCZcspFebGtYDdPCS1CSf0iyBGCP3fkVqiA= Received: by 10.78.172.20 with SMTP id u20mr87576hue.1171495535378; Wed, 14 Feb 2007 15:25:35 -0800 (PST) Received: by 10.78.37.12 with HTTP; Wed, 14 Feb 2007 15:25:35 -0800 (PST) Message-ID: Date: Thu, 15 Feb 2007 00:25:35 +0100 From: Badra To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] EAP-TLS and OCSP In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0900496368==" Errors-To: emu-bounces@ietf.org --===============0900496368== Content-Type: multipart/alternative; boundary="----=_Part_96977_15955714.1171495535311" ------=_Part_96977_15955714.1171495535311 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Joe, IMO, it is nice to have a SHOULD or MAY regarding EAP-TLS with OCSP. The particular situation in which this requirement does not apply may be related the interoperability issues described indraft-ietf-tls-interoperability-00. Best regards, Badra On 2/15/07, Joseph Salowey (jsalowey) wrote: > > Currently EAP-TLS does not require OCSP. Ryan has requested that we > make support for the OCSP TLS (RFC4366 - section 3.6) extension a SHOULD > implement in EAP-TLS. > > The benefit of this is that it allows the peer to check for certificate > revocation before it has access to the network. Without this if the > peer does not have an up to date CRL it must defer revocation checking > until it has network access and can receive an up to date CRL. The peer > must limit its trust of the security of its network connection until it > can access the CRL. > > The downside of this is that it places a new requirement on EAP-TLS > implementations. Even though it is a SHOULD and not a MUST it is > important to realize that a SHOULD is a requirement to implement unless > there are circumstances which make this requirement not apply to a > particular situation. > > I would like to here views from the working group on this topic. > > Joe > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > ------=_Part_96977_15955714.1171495535311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Joe,
 
IMO, it is nice to have a SHOULD or MAY regarding EAP-TLS with OCSP.
 
The particular situation in which this requirement does not apply may be related the interoperability issues described indraft-ietf-tls-interoperability-00.

Best regards,
Badra
 
On 2/15/07, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
Currently EAP-TLS does not require OCSP.  Ryan has requested that we
make support for the OCSP TLS (RFC4366 - section 3.6) extension a SHOULD
implement in EAP-TLS.

The benefit of this is that it allows the peer to check for certificate
revocation before it has access to the network.  Without this if the
peer does not have an up to date CRL it must defer revocation checking
until it has network access and can receive an up to date CRL.  The peer
must limit its trust of the security of its network connection until it
can access the CRL.

The downside of this is that it places a new requirement on EAP-TLS
implementations.  Even though it is a SHOULD and not a MUST it is
important to realize that a SHOULD is a requirement to implement unless
there are circumstances which make this requirement not apply to a
particular situation.

I would like to here views from the working group on this topic.

Joe

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

------=_Part_96977_15955714.1171495535311-- --===============0900496368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0900496368==-- From emu-bounces@ietf.org Wed Feb 14 18:41:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTl5-0006uV-L5; Wed, 14 Feb 2007 18:41:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTl3-0006tg-Rm for emu@ietf.org; Wed, 14 Feb 2007 18:41:53 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTl2-0007CF-Ex for emu@ietf.org; Wed, 14 Feb 2007 18:41:53 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 14 Feb 2007 15:41:52 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Wed, 14 Feb 2007 15:41:51 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 14 Feb 2007 15:41:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-TLS and OCSP Date: Wed, 14 Feb 2007 15:41:30 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FDC2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-TLS and OCSP Thread-Index: AcdQjRJOnw0bOYUcSvGgENsPxK15lgAAdfqA References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 14 Feb 2007 23:41:52.0152 (UTC) FILETIME=[B3DE5180:01C75091] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Since I am new to this list and don't know the PKI background here I thought I would provide a few links to help with this discussion: OCSP - http://www.ietf.org/rfc/rfc2560.txt TLS Extensions - http://www.ietf.org/rfc/rfc4366.txt Additionally I wanted to talk about the rationale behind this (although it has some coverage in the other thread), X.509 certificates are long lived assertions that are made by their issuers that bind entitlements and constraints to a key (no surprise here). The thing is that as a long lived assertion the older it is the less likely it is trustworthy, this is especially true for server certificates that are typically just used in software cryptographic implementations where these keys can be stolen from memory, or disk (this is especially true in datacenters where key material needs to be distributed broadly). I guess this brings us to why certificates get revoked, there are lots of reasons they most common being key compromise (which I describe above) others include issuance errors, ca compromise, affiliation change, suspension of roles, etc. NIST has a nice paper by David Cooper on the topic available here: http://csrc.nist.gov/nissc/1998/proceedings/paperG2.pdf As a practical matter revocation happens allot, just take a look at the many VeriSign CRLs associated with their public SSL issuance (several have CRLs approaching 1MB) and the multi-megabyte CRLs in the DoD. There are other reliability and performance benefits as well, with CRLs commonly being very large it can take a long time over high latency links to download and validate which negatively effects the user (often times downloads actually fail due to timeouts). As for doing the check after the fact, this can certainly be done however this means that you may have already exchanged confidential information with a hostile entity and the damage is done. As for my logic associated with this being a SHOULD, RFC2119 (http://www.ietf.org/rfc/rfc2119.txt) defines SHOULD as follows: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. This seems appropriate given the issues at hand, this label allows the implementer to ignore this requirement if appropriate for their particular situation thus providing appropriate guidance but enabling implementers to do what's right for their given situation. OK, that's my 2 bits :) Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, February 14, 2007 3:09 PM To: emu@ietf.org Subject: [Emu] EAP-TLS and OCSP Currently EAP-TLS does not require OCSP. Ryan has requested that we make support for the OCSP TLS (RFC4366 - section 3.6) extension a SHOULD implement in EAP-TLS. =20 The benefit of this is that it allows the peer to check for certificate revocation before it has access to the network. Without this if the peer does not have an up to date CRL it must defer revocation checking until it has network access and can receive an up to date CRL. The peer must limit its trust of the security of its network connection until it can access the CRL. =20 The downside of this is that it places a new requirement on EAP-TLS implementations. Even though it is a SHOULD and not a MUST it is important to realize that a SHOULD is a requirement to implement unless there are circumstances which make this requirement not apply to a particular situation. =20 I would like to here views from the working group on this topic. Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 14 20:53:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVoC-00051a-J5; Wed, 14 Feb 2007 20:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVoA-00050i-QS for emu@ietf.org; Wed, 14 Feb 2007 20:53:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHVo9-0006N4-7Z for emu@ietf.org; Wed, 14 Feb 2007 20:53:14 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2007 17:53:12 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="39581034:sNHT57521556" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1F1rClr011022; Wed, 14 Feb 2007 17:53:12 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1F1rCnF004723; Wed, 14 Feb 2007 17:53:12 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 17:53:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 14 Feb 2007 17:53:10 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FD48@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmogAALnjJAABiBe8A== From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 15 Feb 2007 01:53:12.0020 (UTC) FILETIME=[0CA2C140:01C750A4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4796; t=1171504392; x=1172368392; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=0ubsQta9qBHFOy3Gz0oy7RYUemqEAozdrZKi1cUvSHA=; b=VilUEI2nVjsO3ztRS0xDN8Ub1+4kCIbMi8wCCbQ7cNNQfu58mqqU5h3TRrQq485LjftSCCCz JfawDScGXPV+kJitbehCLRtCf0H8pfnAerVg60HzywXjgCYcLJFqH9zw; Authentication-Results: sj-dkim-8; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Ryan, Looks pretty good, two comments inline below. Joe=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Wednesday, February 14, 2007 3:00 PM > To: Ryan Hurst; Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Bernard - I believe this block of text represents the changes=20 > we have discussed in the thread, I would use it in your next release. >=20 > "5.2 Peer and Server Identities > =20 > The EAP-TLS peer name (Peer-Id) represents the identity to be=20 > used for access control and accounting purposes. The Server-Id=20 > represents the identity of the EAP server. > =20 > In EAP-TLS, the Peer-Id and Server-Id are determined from=20 > the subject > or subjectAltName fields in the peer and server certificates. As > noted in [RFC3280] Section 4.1.2.6. > =20 > Where the subjectAltName field is present in the peer or server=20 > certificate, the Peer-Id or Server-Id MUST be set to the contents=20 > of the subjectAltName as per Section 5.3. =20 > =20 > If subject naming information is present in only in the=20 > subject name field > then the Subject Field of the peer certificate SHOULD=20 > contain a emailAddress RDN > containing the Peer-Id=20 [Joe] Can we qualify this with user and device as we did with subjectAltName? "If subject naming information is present in only in the subject name field then the Subject Field of and the peer identity represents a user the certificate SHOULD contain a emailAddress RDN. If the peer identity represents a host or device the certificate SHOULD contain a CN RDN or Serial Number RDN. The Subject Field of the server certificate MUST contain the CN RDN or Serial Number RDN containing the Server-ID. =20 > If subject naming > information is present only in the subjectAltName=20 > extension then the subject > field MUST be an empty sequence and the subjectAltName extension > MUST be critical.=20 > =20 > However, in the case where the EAP-TLS peer is attempting=20 > to obtain network > access, it will not have network connectivity and is therefore not > capable of checking for certificate revocation until after > authentication completes and network connectivity is available. =20 > For this reason EAP-TLS peers and servers SHOULD implement=20 > Certificate Status Request messages, as described in [RFC3546]=20 > section 3.6. To enable revocation checking in situations=20 > where servers do not support Certificate > Status Request messages and network connectivity is not > available prior to authentication completion, peer=20 > implementations SHOULD also support checking for certificate=20 > revocation after authentication completes and network connectivity=20 > is available, and SHOULD utilize this capability. [Joe] OK, if we go with OCSP as a SHOULD then I think checking for certificate revocation after network authentication completes should be MUST to implement for the peer since there is a possibility that OCSP will not be available in the server implementation.=20 > " >=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > Sent: Wednesday, February 14, 2007 1:12 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > I will do this before I go home today. >=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Wednesday, February 14, 2007 12:27 PM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > If possible, I'd like to include text arising from this thread in the > -08 > version of the document, submitted by the IETF 68 deadline. >=20 > To make it easier for me to figure out what that text is, it=20 > would be helpful for someone to post the suggested changes in=20 > their entirety, with modifications agreed to during the=20 > discussion. Further comments can then refer to that text,=20 > suggesting specific changes. >=20 > Having that record on the mailing list will make it a lot=20 > easier for me to figure out what changes to make to the document. >=20 > Thanks in advance, >=20 > Bernard >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 13:25:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI7la-0001Ng-7f; Fri, 16 Feb 2007 13:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI7lY-0001Mk-V8 for emu@ietf.org; Fri, 16 Feb 2007 13:25:04 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI7jO-0000Bs-L9 for emu@ietf.org; Fri, 16 Feb 2007 13:22:54 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Feb 2007 10:22:50 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Feb 2007 10:22:49 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Feb 2007 10:22:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 10:22:44 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C86CC@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <001f01c74fbe$bd9eccf0$63cba744@RBLAPTOP> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/AAAgRu4ACOCJMQ References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423F5AA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <001f01c74fbe$bd9eccf0$63cba744@RBLAPTOP> From: Ryan Hurst To: Ray Bell , "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 16 Feb 2007 18:22:49.0727 (UTC) FILETIME=[76EB90F0:01C751F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Ray - I am familiar with the cable labs stuff, they put the MAC in the CN although if I recall they don't specify how the value should be represented which really limits its value IMHO. I have looked at 802.1ar and from what I can tell they have not decided where the value should go in their certificate profile, from the various revisions it looks like they have considered many locations from the CN, certificate Serial Number, subject serial number to a SAN othernames. I have spoken to Bernard off-line and he has convinced me that it would be useful for there to be a appendix discussing how one would include this value in a certificate if it's to be used within EAP-TLS.=20 I want to ping a few people for their opinions on location, my initial take is that specifying a consistent format to represent the value as and putting it in the CN or the subjectAltName:OtherName:PI are probably the best bests but I need to think about it more. Ryan -----Original Message----- From: Ray Bell [mailto:ray@grid-net.com]=20 Sent: Tuesday, February 13, 2007 2:32 PM To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba'; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt The CableLabs Device PKI process should be considered... http://www.cablelabs.com/certqual/security/ Ray -----Original Message----- From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Tuesday, February 13, 2007 1:38 PM To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt I am not sure the MAC address is directly relevant to this effort, as long as we allow for alternate bindings to be used (I think the text I proposed does this) then these problems can be dealt with in other documents. As for the MAC address as a identifier, I actually am not a fan; from what I can tell it has been added to facilitate better certificate selection but there are much better ways to achieve that; I have been tempted to write a informational on how proper certificate selection is done but have not had the time. The problem with a MAC address is that certificates normally contain bindings of entitlements or constraints, these are all assertions that the CA can stand behind (I have verified that the holder of this key has the rights to this fqdn, I have verified he is entitled to represent that FQDN for server TLS transactions, etc.). You just can't do that with a MAC address, not in any reasonable way; now device identity is a SUPER important thing without it we will continue to take dependencies on weak identifiers like MAC addresses to perform exceptions and entitlements (which essentially throw out any security value modern isolation solutions provide) so the work being done by AR is important. As for where AR puts the identity, generally speaking you should be able to tell what is in a RDN given a certificate usage; so if AR has a EKU for Device Authentication I suppose its fine for it to say when this EKU is present the RDN CN has special meaning, otherwise it should go elsewhere. Actually now that I think about it I would suggest that they go in subjectAltName; again the general thinking about Subject DNs is they map to a directory entity; this isn't always the case and its likely not the case with a device certificate (many assumptions in this statement so be kind), in such cases its probably more appropriate to have a empty Subject DN and use a existing name form (urn, etc.) in subjectAltName or define a new name form for the subjectAltName extension. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Tuesday, February 13, 2007 12:18 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt 802.1AR is not specifying that a device identity within a certificate has to be a MAC address. It can be any identifier that is unique within a manufacturer's domain. The current thinking is that the identity would go in the common name of the subject name.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, February 13, 2007 10:59 AM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Question: >=20 > What about a device that has a MAC address as a name? Use of=20 > EAP-TLS with MAC certificates is being discussed in WiMAX=20 > Forum and IEEE 802.1AR. Where should the MAC address be=20 > placed (subject vs. subjectAltName) and what field type=20 > should it have? Is there a reference that defines the=20 > formatting of field types? Is there guidance on how to format=20 > the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs.=20 > 00:03:7B:5F:CE:73 in IEEE 802.1AR). >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 13:42:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI82J-0007u5-C3; Fri, 16 Feb 2007 13:42:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI82I-0007tz-IO for emu@ietf.org; Fri, 16 Feb 2007 13:42:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI82F-0003wN-TE for emu@ietf.org; Fri, 16 Feb 2007 13:42:22 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2007 10:42:19 -0800 X-IronPort-AV: i="4.14,181,1170662400"; d="scan'208"; a="389904412:sNHT57998556" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1GIgJiY026642; Fri, 16 Feb 2007 10:42:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1GIgInJ021074; Fri, 16 Feb 2007 10:42:19 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 10:42:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 10:42:12 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C86CC@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/AAAgRu4ACOCJMQAADtTsA= From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Ray Bell" , "Bernard Aboba" , X-OriginalArrivalTime: 16 Feb 2007 18:42:14.0439 (UTC) FILETIME=[2D248370:01C751FA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6288; t=1171651339; x=1172515339; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=ZN3yZffoUvuqhJFH1W4ppv7OFcv7deDqedPj0r/noW8=; b=aR8Wkyh+WSgYB36dHCh7FAuPsdGLAOtYzz6S+ZKIZ7nMEO+DHNl7qEEXrvGm6C/kyaKfLCZs gBBOTb0uoly3UW8xvHI3Y89d7shsbNOxdgNNkg5vLjJv9fVWKWKjE8OW; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Friday, February 16, 2007 10:23 AM > To: Ray Bell; Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Ray - I am familiar with the cable labs stuff, they put the=20 > MAC in the CN although if I recall they don't specify how the=20 > value should be represented which really limits its value IMHO. >=20 > I have looked at 802.1ar and from what I can tell they have=20 > not decided where the value should go in their certificate=20 > profile, from the various revisions it looks like they have=20 > considered many locations from the CN, certificate Serial=20 > Number, subject serial number to a SAN othernames. >=20 [Joe] The identifier in AR is not necessarily a MAC address. The identifier format is determined by the manufacturuer.=20 > I have spoken to Bernard off-line and he has convinced me=20 > that it would be useful for there to be a appendix discussing=20 > how one would include this value in a certificate if it's to=20 > be used within EAP-TLS.=20 >=20 [Joe] What value? > I want to ping a few people for their opinions on location,=20 > my initial take is that specifying a consistent format to=20 > represent the value as and putting it in the CN or the=20 > subjectAltName:OtherName:PI are probably the best bests but I=20 > need to think about it more. >=20 [Joe] I'm not quite sure what value you are talking about, but if it is a device identity then why not the SN RDN. =20 > Ryan >=20 > -----Original Message----- > From: Ray Bell [mailto:ray@grid-net.com] > Sent: Tuesday, February 13, 2007 2:32 PM > To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba';=20 > emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > The CableLabs Device PKI process should be considered... >=20 > http://www.cablelabs.com/certqual/security/ >=20 > Ray >=20 >=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > Sent: Tuesday, February 13, 2007 1:38 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > I am not sure the MAC address is directly relevant to this=20 > effort, as long as we allow for alternate bindings to be used=20 > (I think the text I proposed does this) then these problems=20 > can be dealt with in other documents. >=20 > As for the MAC address as a identifier, I actually am not a=20 > fan; from what I can tell it has been added to facilitate=20 > better certificate selection but there are much better ways=20 > to achieve that; I have been tempted to write a informational=20 > on how proper certificate selection is done but have not had the time. >=20 > The problem with a MAC address is that certificates normally=20 > contain bindings of entitlements or constraints, these are=20 > all assertions that the CA can stand behind (I have verified=20 > that the holder of this key has the rights to this fqdn, I=20 > have verified he is entitled to represent that FQDN for=20 > server TLS transactions, etc.). >=20 > You just can't do that with a MAC address, not in any=20 > reasonable way; now device identity is a SUPER important=20 > thing without it we will continue to take dependencies on=20 > weak identifiers like MAC addresses to perform exceptions and=20 > entitlements (which essentially throw out any security value=20 > modern isolation solutions provide) so the work being done by=20 > AR is important. >=20 > As for where AR puts the identity, generally speaking you=20 > should be able to tell what is in a RDN given a certificate=20 > usage; so if AR has a EKU for Device Authentication I suppose=20 > its fine for it to say when this EKU is present the RDN CN=20 > has special meaning, otherwise it should go elsewhere. >=20 > Actually now that I think about it I would suggest that they=20 > go in subjectAltName; again the general thinking about=20 > Subject DNs is they map to a directory entity; this isn't=20 > always the case and its likely not the case with a device=20 > certificate (many assumptions in this statement so be kind),=20 > in such cases its probably more appropriate to have a empty=20 > Subject DN and use a existing name form (urn, etc.) in=20 > subjectAltName or define a new name form for the=20 > subjectAltName extension. >=20 > Ryan > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, February 13, 2007 12:18 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > 802.1AR is not specifying that a device identity within a=20 > certificate has to be a MAC address. It can be any=20 > identifier that is unique within a manufacturer's domain. =20 > The current thinking is that the identity would go in the=20 > common name of the subject name.=20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, February 13, 2007 10:59 AM > > To: emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > Question: > >=20 > > What about a device that has a MAC address as a name? Use=20 > of EAP-TLS=20 > > with MAC certificates is being discussed in WiMAX Forum and IEEE=20 > > 802.1AR. Where should the MAC address be placed (subject vs.=20 > > subjectAltName) and what field type should it have? Is there a=20 > > reference that defines the formatting of field types? Is there=20 > > guidance on how to format the MAC address consistently? (e.g.=20 > > 00037B5FCE73 in WiMAX vs. > > 00:03:7B:5F:CE:73 in IEEE 802.1AR). > >=20 > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 13:56:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8GE-0001Mj-J0; Fri, 16 Feb 2007 13:56:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8GB-0001DP-TV for emu@ietf.org; Fri, 16 Feb 2007 13:56:43 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI8Bi-0006eN-Qc for emu@ietf.org; Fri, 16 Feb 2007 13:52:08 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Feb 2007 10:52:06 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Feb 2007 10:52:05 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Feb 2007 10:52:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 10:51:51 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C8703@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/AAAgRu4ACOCJMQAADtTsAAAFTD8A== References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C86CC@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Ray Bell , Bernard Aboba , X-OriginalArrivalTime: 16 Feb 2007 18:52:05.0204 (UTC) FILETIME=[8D441940:01C751FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org In-line -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Friday, February 16, 2007 10:42 AM To: Ryan Hurst; Ray Bell; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Friday, February 16, 2007 10:23 AM > To: Ray Bell; Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Ray - I am familiar with the cable labs stuff, they put the=20 > MAC in the CN although if I recall they don't specify how the=20 > value should be represented which really limits its value IMHO. >=20 > I have looked at 802.1ar and from what I can tell they have=20 > not decided where the value should go in their certificate=20 > profile, from the various revisions it looks like they have=20 > considered many locations from the CN, certificate Serial=20 > Number, subject serial number to a SAN othernames. >=20 [Joe] The identifier in AR is not necessarily a MAC address. The identifier format is determined by the manufacturuer.=20 [rmh] Your right, in the early versions of the document it read as if it were a MAC, later revisions generalized it to a permanent identifier; yet it still uses the MAC as a example but doesn't provide guidance on format or limit its usage to a generalized identifier where format wouldn't be relevant. > I have spoken to Bernard off-line and he has convinced me=20 > that it would be useful for there to be a appendix discussing=20 > how one would include this value in a certificate if it's to=20 > be used within EAP-TLS.=20 >=20 [Joe] What value? [rmh] MAC. > I want to ping a few people for their opinions on location,=20 > my initial take is that specifying a consistent format to=20 > represent the value as and putting it in the CN or the=20 > subjectAltName:OtherName:PI are probably the best bests but I=20 > need to think about it more. >=20 [Joe] I'm not quite sure what value you are talking about, but if it is a device identity then why not the SN RDN. =20 [rmh] The problem with just saying SN RDN is that you can have many RDNs in a given DN, plus by putting in the DN you potentially require directory schemas to change to accommodate; the PI RFC (http://www.ietf.org/rfc/rfc4043.txt) documents how one handles the multiple RDN situation and specifies a othername name-form for subjectAltName which allows you to specify the value without the directory hit. [rmh] Problem with PI is its intended for people not devices, however from my read it has all the right properties to deal with a device id such as a MAC address. > Ryan >=20 > -----Original Message----- > From: Ray Bell [mailto:ray@grid-net.com] > Sent: Tuesday, February 13, 2007 2:32 PM > To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba';=20 > emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > The CableLabs Device PKI process should be considered... >=20 > http://www.cablelabs.com/certqual/security/ >=20 > Ray >=20 >=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > Sent: Tuesday, February 13, 2007 1:38 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > I am not sure the MAC address is directly relevant to this=20 > effort, as long as we allow for alternate bindings to be used=20 > (I think the text I proposed does this) then these problems=20 > can be dealt with in other documents. >=20 > As for the MAC address as a identifier, I actually am not a=20 > fan; from what I can tell it has been added to facilitate=20 > better certificate selection but there are much better ways=20 > to achieve that; I have been tempted to write a informational=20 > on how proper certificate selection is done but have not had the time. >=20 > The problem with a MAC address is that certificates normally=20 > contain bindings of entitlements or constraints, these are=20 > all assertions that the CA can stand behind (I have verified=20 > that the holder of this key has the rights to this fqdn, I=20 > have verified he is entitled to represent that FQDN for=20 > server TLS transactions, etc.). >=20 > You just can't do that with a MAC address, not in any=20 > reasonable way; now device identity is a SUPER important=20 > thing without it we will continue to take dependencies on=20 > weak identifiers like MAC addresses to perform exceptions and=20 > entitlements (which essentially throw out any security value=20 > modern isolation solutions provide) so the work being done by=20 > AR is important. >=20 > As for where AR puts the identity, generally speaking you=20 > should be able to tell what is in a RDN given a certificate=20 > usage; so if AR has a EKU for Device Authentication I suppose=20 > its fine for it to say when this EKU is present the RDN CN=20 > has special meaning, otherwise it should go elsewhere. >=20 > Actually now that I think about it I would suggest that they=20 > go in subjectAltName; again the general thinking about=20 > Subject DNs is they map to a directory entity; this isn't=20 > always the case and its likely not the case with a device=20 > certificate (many assumptions in this statement so be kind),=20 > in such cases its probably more appropriate to have a empty=20 > Subject DN and use a existing name form (urn, etc.) in=20 > subjectAltName or define a new name form for the=20 > subjectAltName extension. >=20 > Ryan > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, February 13, 2007 12:18 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > 802.1AR is not specifying that a device identity within a=20 > certificate has to be a MAC address. It can be any=20 > identifier that is unique within a manufacturer's domain. =20 > The current thinking is that the identity would go in the=20 > common name of the subject name.=20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, February 13, 2007 10:59 AM > > To: emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > Question: > >=20 > > What about a device that has a MAC address as a name? Use=20 > of EAP-TLS=20 > > with MAC certificates is being discussed in WiMAX Forum and IEEE=20 > > 802.1AR. Where should the MAC address be placed (subject vs.=20 > > subjectAltName) and what field type should it have? Is there a=20 > > reference that defines the formatting of field types? Is there=20 > > guidance on how to format the MAC address consistently? (e.g.=20 > > 00037B5FCE73 in WiMAX vs. > > 00:03:7B:5F:CE:73 in IEEE 802.1AR). > >=20 > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 14:25:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8hh-0004Sk-Bh; Fri, 16 Feb 2007 14:25:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8hf-0004SU-Jn for emu@ietf.org; Fri, 16 Feb 2007 14:25:07 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI8hd-0007nJ-0a for emu@ietf.org; Fri, 16 Feb 2007 14:25:07 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2007 11:25:04 -0800 X-IronPort-AV: i="4.14,181,1170662400"; d="scan'208"; a="763200775:sNHT54224444" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1GJP4UX011162; Fri, 16 Feb 2007 11:25:04 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1GJOxDw012981; Fri, 16 Feb 2007 11:25:04 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 11:25:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 11:25:02 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C8703@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/AAAgRu4ACOCJMQAADtTsAAAFTD8AAAqjDg From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Ray Bell" , "Bernard Aboba" , X-OriginalArrivalTime: 16 Feb 2007 19:25:04.0283 (UTC) FILETIME=[28E396B0:01C75200] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6338; t=1171653904; x=1172517904; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=lUv0QaMN89eMDLb03z17xZ6Hfe3fzEQx4gdWS2uhynE=; b=F7tRGlHQvmfaxtCXace9QObpb+6ULboC84xuVjp7kknaNItjGp+DRLTCopIH7UgacvV2bAxq 1YillZfPQCa3vQip4Te/5CIKbULKOLb5agmoC6Wj9hmQMB/bniKpU0zV; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > > I want to ping a few people for their opinions on location,=20 > my initial=20 > > take is that specifying a consistent format to represent=20 > the value as=20 > > and putting it in the CN or the subjectAltName:OtherName:PI are=20 > > probably the best bests but I need to think about it more. > >=20 > [Joe] I'm not quite sure what value you are talking about,=20 > but if it is a device identity then why not the SN RDN. =20 > [rmh] The problem with just saying SN RDN is that you can=20 > have many RDNs in a given DN, plus by putting in the DN you=20 > potentially require directory schemas to change to=20 > accommodate; the PI RFC > (http://www.ietf.org/rfc/rfc4043.txt) documents how one=20 > handles the multiple RDN situation and specifies a othername=20 > name-form for subjectAltName which allows you to specify the=20 > value without the directory hit. > [rmh] Problem with PI is its intended for people not devices,=20 > however from my read it has all the right properties to deal=20 > with a device id such as a MAC address. >=20 [Joe] OK, got it. A consistent place to find a MAC address in a cert. If this is the case I don't think CN is appropriate since it is used for all sorts of random stuff. I agree that subjectAltName:OtherName:PI looks promising. I support we could also define a MAC address OID.=20 > > Ryan > >=20 > > -----Original Message----- > > From: Ray Bell [mailto:ray@grid-net.com] > > Sent: Tuesday, February 13, 2007 2:32 PM > > To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba';=20 > > emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > The CableLabs Device PKI process should be considered... > >=20 > > http://www.cablelabs.com/certqual/security/ > >=20 > > Ray > >=20 > >=20 > > -----Original Message----- > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > Sent: Tuesday, February 13, 2007 1:38 PM > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > I am not sure the MAC address is directly relevant to this=20 > effort, as=20 > > long as we allow for alternate bindings to be used (I think=20 > the text I=20 > > proposed does this) then these problems can be dealt with in other=20 > > documents. > >=20 > > As for the MAC address as a identifier, I actually am not a=20 > fan; from=20 > > what I can tell it has been added to facilitate better certificate=20 > > selection but there are much better ways to achieve that; I=20 > have been=20 > > tempted to write a informational on how proper certificate=20 > selection=20 > > is done but have not had the time. > >=20 > > The problem with a MAC address is that certificates=20 > normally contain=20 > > bindings of entitlements or constraints, these are all=20 > assertions that=20 > > the CA can stand behind (I have verified that the holder of=20 > this key=20 > > has the rights to this fqdn, I have verified he is entitled to=20 > > represent that FQDN for server TLS transactions, etc.). > >=20 > > You just can't do that with a MAC address, not in any=20 > reasonable way;=20 > > now device identity is a SUPER important thing without it we will=20 > > continue to take dependencies on weak identifiers like MAC=20 > addresses=20 > > to perform exceptions and entitlements (which essentially throw out=20 > > any security value modern isolation solutions provide) so the work=20 > > being done by AR is important. > >=20 > > As for where AR puts the identity, generally speaking you should be=20 > > able to tell what is in a RDN given a certificate usage; so=20 > if AR has=20 > > a EKU for Device Authentication I suppose its fine for it=20 > to say when=20 > > this EKU is present the RDN CN has special meaning, otherwise it=20 > > should go elsewhere. > >=20 > > Actually now that I think about it I would suggest that they go in=20 > > subjectAltName; again the general thinking about Subject=20 > DNs is they=20 > > map to a directory entity; this isn't always the case and=20 > its likely=20 > > not the case with a device certificate (many assumptions in this=20 > > statement so be kind), in such cases its probably more=20 > appropriate to=20 > > have a empty Subject DN and use a existing name form (urn, etc.) in=20 > > subjectAltName or define a new name form for the subjectAltName=20 > > extension. > >=20 > > Ryan > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Tuesday, February 13, 2007 12:18 PM > > To: Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > 802.1AR is not specifying that a device identity within a=20 > certificate=20 > > has to be a MAC address. It can be any identifier that is unique=20 > > within a manufacturer's domain. > > The current thinking is that the identity would go in the=20 > common name=20 > > of the subject name. > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, February 13, 2007 10:59 AM > > > To: emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > >=20 > > > Question: > > >=20 > > > What about a device that has a MAC address as a name? Use > > of EAP-TLS > > > with MAC certificates is being discussed in WiMAX Forum and IEEE=20 > > > 802.1AR. Where should the MAC address be placed (subject vs. > > > subjectAltName) and what field type should it have? Is there a=20 > > > reference that defines the formatting of field types? Is there=20 > > > guidance on how to format the MAC address consistently? (e.g. > > > 00037B5FCE73 in WiMAX vs. > > > 00:03:7B:5F:CE:73 in IEEE 802.1AR). > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 14:32:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8oc-0003mQ-2W; Fri, 16 Feb 2007 14:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8oY-0003mI-H6 for emu@ietf.org; Fri, 16 Feb 2007 14:32:14 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI8oW-0001TT-SM for emu@ietf.org; Fri, 16 Feb 2007 14:32:14 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2007 11:32:12 -0800 X-IronPort-AV: i="4.14,181,1170662400"; d="scan'208"; a="763203308:sNHT241470894" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1GJWBBD022994; Fri, 16 Feb 2007 11:32:11 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1GJVvH4005598; Fri, 16 Feb 2007 11:32:09 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 11:32:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 11:32:02 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdPoRBSv3T2slx5TY6hdgbhmpjuTgACpAQAAAJyy/AAAgRu4ACOCJMQAADtTsAAAFTD8AAAqjDgAADA4FA= From: "Joseph Salowey \(jsalowey\)" To: "Joseph Salowey \(jsalowey\)" , "Ryan Hurst" , "Ray Bell" , "Bernard Aboba" , X-OriginalArrivalTime: 16 Feb 2007 19:32:04.0587 (UTC) FILETIME=[2368E3B0:01C75201] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7060; t=1171654331; x=1172518331; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=WWW7hqbs7PHSqw7ib8K7m+wI0RoJCMYb3gVXfXlN3pk=; b=VLccBuX2oY/65jKdgsDRFlxyGGueAD6bp6y8hqSR3kZpcCEo2jzD+ZLHe8DP00qmJJ24pskB 9Z8BXSwq6utQnO8sC0lXTmBRYcVQfvZeKmumyYb5ozEf76JlyTwIQk7u; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > Sent: Friday, February 16, 2007 11:25 AM > To: Ryan Hurst; Ray Bell; Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 >=20 >=20 > > > I want to ping a few people for their opinions on location, > > my initial > > > take is that specifying a consistent format to represent > > the value as > > > and putting it in the CN or the subjectAltName:OtherName:PI are=20 > > > probably the best bests but I need to think about it more. > > >=20 > > [Joe] I'm not quite sure what value you are talking about,=20 > but if it=20 > > is a device identity then why not the SN RDN. > > [rmh] The problem with just saying SN RDN is that you can have many=20 > > RDNs in a given DN, plus by putting in the DN you=20 > potentially require=20 > > directory schemas to change to accommodate; the PI RFC > > (http://www.ietf.org/rfc/rfc4043.txt) documents how one handles the=20 > > multiple RDN situation and specifies a othername name-form for=20 > > subjectAltName which allows you to specify the value without the=20 > > directory hit. > > [rmh] Problem with PI is its intended for people not=20 > devices, however=20 > > from my read it has all the right properties to deal with a=20 > device id=20 > > such as a MAC address. > >=20 > [Joe] OK, got it. A consistent place to find a MAC address in a cert. > If this is the case I don't think CN is appropriate since it=20 > is used for all sorts of random stuff. I agree that =20 > subjectAltName:OtherName:PI looks promising. I support we=20 > could also define a MAC address OID.=20 [Joe] Should be "I suppose" instead of "I support"=20 >=20 > > > Ryan > > >=20 > > > -----Original Message----- > > > From: Ray Bell [mailto:ray@grid-net.com] > > > Sent: Tuesday, February 13, 2007 2:32 PM > > > To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba';=20 > > > emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > >=20 > > > The CableLabs Device PKI process should be considered... > > >=20 > > > http://www.cablelabs.com/certqual/security/ > > >=20 > > > Ray > > >=20 > > >=20 > > > -----Original Message----- > > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > > Sent: Tuesday, February 13, 2007 1:38 PM > > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > >=20 > > > I am not sure the MAC address is directly relevant to this > > effort, as > > > long as we allow for alternate bindings to be used (I think > > the text I > > > proposed does this) then these problems can be dealt with=20 > in other=20 > > > documents. > > >=20 > > > As for the MAC address as a identifier, I actually am not a > > fan; from > > > what I can tell it has been added to facilitate better=20 > certificate=20 > > > selection but there are much better ways to achieve that; I > > have been > > > tempted to write a informational on how proper certificate > > selection > > > is done but have not had the time. > > >=20 > > > The problem with a MAC address is that certificates > > normally contain > > > bindings of entitlements or constraints, these are all > > assertions that > > > the CA can stand behind (I have verified that the holder of > > this key > > > has the rights to this fqdn, I have verified he is entitled to=20 > > > represent that FQDN for server TLS transactions, etc.). > > >=20 > > > You just can't do that with a MAC address, not in any > > reasonable way; > > > now device identity is a SUPER important thing without it we will=20 > > > continue to take dependencies on weak identifiers like MAC > > addresses > > > to perform exceptions and entitlements (which essentially=20 > throw out=20 > > > any security value modern isolation solutions provide) so=20 > the work=20 > > > being done by AR is important. > > >=20 > > > As for where AR puts the identity, generally speaking you=20 > should be=20 > > > able to tell what is in a RDN given a certificate usage; so > > if AR has > > > a EKU for Device Authentication I suppose its fine for it > > to say when > > > this EKU is present the RDN CN has special meaning, otherwise it=20 > > > should go elsewhere. > > >=20 > > > Actually now that I think about it I would suggest that=20 > they go in=20 > > > subjectAltName; again the general thinking about Subject > > DNs is they > > > map to a directory entity; this isn't always the case and > > its likely > > > not the case with a device certificate (many assumptions in this=20 > > > statement so be kind), in such cases its probably more > > appropriate to > > > have a empty Subject DN and use a existing name form=20 > (urn, etc.) in=20 > > > subjectAltName or define a new name form for the subjectAltName=20 > > > extension. > > >=20 > > > Ryan > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Tuesday, February 13, 2007 12:18 PM > > > To: Bernard Aboba; emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > >=20 > > > 802.1AR is not specifying that a device identity within a > > certificate > > > has to be a MAC address. It can be any identifier that is unique=20 > > > within a manufacturer's domain. > > > The current thinking is that the identity would go in the > > common name > > > of the subject name. > > >=20 > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, February 13, 2007 10:59 AM > > > > To: emu@ietf.org > > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > >=20 > > > > Question: > > > >=20 > > > > What about a device that has a MAC address as a name? Use > > > of EAP-TLS > > > > with MAC certificates is being discussed in WiMAX Forum=20 > and IEEE=20 > > > > 802.1AR. Where should the MAC address be placed (subject vs. > > > > subjectAltName) and what field type should it have? Is there a=20 > > > > reference that defines the formatting of field types? Is there=20 > > > > guidance on how to format the MAC address consistently? (e.g. > > > > 00037B5FCE73 in WiMAX vs. > > > > 00:03:7B:5F:CE:73 in IEEE 802.1AR). > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Emu mailing list > > > > Emu@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/emu > > > >=20 > > >=20 > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 18:34:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HICbJ-00082E-5y; Fri, 16 Feb 2007 18:34:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HICbI-000828-0s for emu@ietf.org; Fri, 16 Feb 2007 18:34:48 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HICbE-00046k-G2 for emu@ietf.org; Fri, 16 Feb 2007 18:34:48 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Feb 2007 15:34:43 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Feb 2007 15:34:43 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Feb 2007 15:34:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 15:34:23 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C89AF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmogAALnjJAABiBe8ABgQpjg References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800423FD48@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 16 Feb 2007 23:34:43.0267 (UTC) FILETIME=[090F2930:01C75223] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, February 14, 2007 5:53 PM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Hi Ryan, Looks pretty good, two comments inline below. Joe=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Wednesday, February 14, 2007 3:00 PM > To: Ryan Hurst; Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > Bernard - I believe this block of text represents the changes=20 > we have discussed in the thread, I would use it in your next release. >=20 > "5.2 Peer and Server Identities > =20 > The EAP-TLS peer name (Peer-Id) represents the identity to be=20 > used for access control and accounting purposes. The Server-Id=20 > represents the identity of the EAP server. > =20 > In EAP-TLS, the Peer-Id and Server-Id are determined from=20 > the subject > or subjectAltName fields in the peer and server certificates. As > noted in [RFC3280] Section 4.1.2.6. > =20 > Where the subjectAltName field is present in the peer or server=20 > certificate, the Peer-Id or Server-Id MUST be set to the contents=20 > of the subjectAltName as per Section 5.3. =20 > =20 > If subject naming information is present in only in the=20 > subject name field > then the Subject Field of the peer certificate SHOULD=20 > contain a emailAddress RDN > containing the Peer-Id=20 [Joe] Can we qualify this with user and device as we did with subjectAltName? "If subject naming information is present in only in the subject name field then the Subject Field of and the peer identity represents a user the certificate SHOULD contain a emailAddress RDN. If the peer identity represents a host or device the certificate SHOULD contain a CN RDN or Serial Number RDN. The Subject Field of the server certificate MUST contain the CN RDN or Serial Number RDN containing the Server-ID. =20 [rmh] As I understand it the peer ID always (essentially) looks like a email address so host or otherwise it seems appropriate to use the emailAddress RDN; this also (based on my experience) represents current practice with the Subject DN being deprecated any new name-forms should be proposed in the subjectAltName shouldn't it? =20 > If subject naming > information is present only in the subjectAltName=20 > extension then the subject > field MUST be an empty sequence and the subjectAltName extension > MUST be critical.=20 > =20 > However, in the case where the EAP-TLS peer is attempting=20 > to obtain network > access, it will not have network connectivity and is therefore not > capable of checking for certificate revocation until after > authentication completes and network connectivity is available. =20 > For this reason EAP-TLS peers and servers SHOULD implement=20 > Certificate Status Request messages, as described in [RFC3546]=20 > section 3.6. To enable revocation checking in situations=20 > where servers do not support Certificate > Status Request messages and network connectivity is not > available prior to authentication completion, peer=20 > implementations SHOULD also support checking for certificate=20 > revocation after authentication completes and network connectivity=20 > is available, and SHOULD utilize this capability. [Joe] OK, if we go with OCSP as a SHOULD then I think checking for certificate revocation after network authentication completes should be MUST to implement for the peer since there is a possibility that OCSP will not be available in the server implementation.=20 [rmh] Well this should always be a matter of policy (maybe I have other ways to mitigate this risk in my environment), this is the core issue with the requirement being a MUST. In such situations most specs leave these sorts of requirements as a SHOULD, we could put a MUST in there with some words that still let you choose though; what do you want to do? > " >=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > Sent: Wednesday, February 14, 2007 1:12 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > I will do this before I go home today. >=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Wednesday, February 14, 2007 12:27 PM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > If possible, I'd like to include text arising from this thread in the > -08 > version of the document, submitted by the IETF 68 deadline. >=20 > To make it easier for me to figure out what that text is, it=20 > would be helpful for someone to post the suggested changes in=20 > their entirety, with modifications agreed to during the=20 > discussion. Further comments can then refer to that text,=20 > suggesting specific changes. >=20 > Having that record on the mailing list will make it a lot=20 > easier for me to figure out what changes to make to the document. >=20 > Thanks in advance, >=20 > Bernard >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 19:15:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDEK-0007MJ-GA; Fri, 16 Feb 2007 19:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDEI-0007LI-Ny for emu@ietf.org; Fri, 16 Feb 2007 19:15:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDEH-0002CA-4i for emu@ietf.org; Fri, 16 Feb 2007 19:15:06 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2007 16:15:05 -0800 X-IronPort-AV: i="4.14,182,1170662400"; d="scan'208"; a="389992605:sNHT57248496" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1H0F4QT012355; Fri, 16 Feb 2007 16:15:04 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1H0F4ho024425; Fri, 16 Feb 2007 16:15:04 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:15:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 16:15:02 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C89AF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmogAALnjJAABiBe8ABgQpjgAABunAA= From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 17 Feb 2007 00:15:04.0166 (UTC) FILETIME=[AC070860:01C75228] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5937; t=1171671304; x=1172535304; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=LcXH9bj1Cn38FaD1LkKfzkcS9oUhOwbujA7sJpYsI94=; b=m4yXoSPgtY34u2+Yq9nD8aMx308SZXXgpeZgfbio+drpaZakrvX+8m8kLOwMs7UGSjOHyl0c f89w5be19PxuOfY1qyvUZpfHXVfTP6l6kuGm3qH8vIqSzIg7J4LHGP8Q; Authentication-Results: sj-dkim-7; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > > If subject naming information is present in only in the subject=20 > > name field > > then the Subject Field of the peer certificate SHOULD contain a=20 > > emailAddress RDN > > containing the Peer-Id >=20 > [Joe] Can we qualify this with user and device as we did with=20 > subjectAltName? >=20 > "If subject naming information is present in only in the=20 > subject name field then the Subject Field of and the peer=20 > identity represents a user the certificate SHOULD contain a=20 > emailAddress RDN. If the peer identity represents a host or=20 > device the certificate SHOULD contain a CN RDN or Serial=20 > Number RDN. The Subject Field of the server certificate MUST=20 > contain the CN RDN or Serial Number RDN containing the Server-ID. =20 >=20 > [rmh] As I understand it the peer ID always (essentially)=20 > looks like a email address so host or otherwise it seems=20 > appropriate to use the emailAddress RDN; this also (based on=20 > my experience) represents current practice with the Subject=20 > DN being deprecated any new name-forms should be proposed in=20 > the subjectAltName shouldn't it? > [Joe] The peer name often takes the form of name@realm, but it does not necessarily have to. Another problem is that some existing device implementations use the email address RDN, but it does not have a unique identifier in it.=20 =20 > > If subject naming > > information is present only in the subjectAltName extension then=20 > > the subject > > field MUST be an empty sequence and the subjectAltName extension > > MUST be critical.=20 > > =20 >=20 > >=20 > > However, in the case where the EAP-TLS peer is=20 > attempting to obtain=20 > > network > > access, it will not have network connectivity and is=20 > therefore not > > capable of checking for certificate revocation until after > > authentication completes and network connectivity is available. =20 > > For this reason EAP-TLS peers and servers SHOULD implement=20 > > Certificate Status Request messages, as described in [RFC3546]=20 > > section 3.6. To enable revocation checking in situations=20 > > where servers do not support Certificate > > Status Request messages and network connectivity is not > > available prior to authentication completion, peer=20 > > implementations SHOULD also support checking for certificate=20 > > revocation after authentication completes and network=20 > connectivity=20 > > is available, and SHOULD utilize this capability. >=20 > [Joe] OK, if we go with OCSP as a SHOULD then I think=20 > checking for certificate revocation after network=20 > authentication completes should be MUST to implement for the=20 > peer since there is a possibility that OCSP will not be=20 > available in the server implementation.=20 > [rmh] Well this should always be a matter of policy (maybe I=20 > have other ways to mitigate this risk in my environment),=20 > this is the core issue with the requirement being a MUST. In=20 > such situations most specs leave these sorts of requirements=20 > as a SHOULD, we could put a MUST in there with some words=20 > that still let you choose though; what do you want to do? >=20 [Joe] Right there is a difference between required to implement and required to deploy. In most cases the MUSTs, SHOULDs, etc are required to implement. A particular deployment can often disable a particular feature if it does not work in their environment.=20 I think in this version of the text we have a MUST requirement for certificate revocation checks which is different than the SHOULD in RFC2716. If the peer must be able to perform certificate validation then it needs to have a mechanism to do this. Since OCSP in TLS (RFC 4366) is a SHOULD it may not be implemented in a server the peer is talking to, in which case the peer must be able to fall back to post connection checks. It seems the first SHOULD in the text refers to support in an implementation and the second refers to deployment. It seems inconsistent to have a MUST for revocation and no mandatory way to do it, but perhaps the MUST for CRL support covers it. =20 >=20 > > " > >=20 > > -----Original Message----- > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > Sent: Wednesday, February 14, 2007 1:12 PM > > To: Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > I will do this before I go home today. > >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Wednesday, February 14, 2007 12:27 PM > > To: emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > If possible, I'd like to include text arising from this=20 > thread in the > > -08 > > version of the document, submitted by the IETF 68 deadline. > >=20 > > To make it easier for me to figure out what that text is,=20 > it would be=20 > > helpful for someone to post the suggested changes in their=20 > entirety,=20 > > with modifications agreed to during the discussion. =20 > Further comments=20 > > can then refer to that text, suggesting specific changes. > >=20 > > Having that record on the mailing list will make it a lot=20 > easier for=20 > > me to figure out what changes to make to the document. > >=20 > > Thanks in advance, > >=20 > > Bernard > >=20 > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 16 19:27:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDQZ-00017j-65; Fri, 16 Feb 2007 19:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDQX-000160-M9 for emu@ietf.org; Fri, 16 Feb 2007 19:27:45 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDQW-0004oW-5i for emu@ietf.org; Fri, 16 Feb 2007 19:27:45 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Feb 2007 16:27:43 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Feb 2007 16:27:42 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Feb 2007 16:27:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Fri, 16 Feb 2007 16:26:59 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C8A15@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmogAALnjJAABiBe8ABgQpjgAABunAAAAZJR4A== References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C89AF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 17 Feb 2007 00:27:42.0070 (UTC) FILETIME=[6FC60160:01C7522A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org In-line -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Friday, February 16, 2007 4:15 PM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =20 > > If subject naming information is present in only in the subject=20 > > name field > > then the Subject Field of the peer certificate SHOULD contain a=20 > > emailAddress RDN > > containing the Peer-Id >=20 > [Joe] Can we qualify this with user and device as we did with=20 > subjectAltName? >=20 > "If subject naming information is present in only in the=20 > subject name field then the Subject Field of and the peer=20 > identity represents a user the certificate SHOULD contain a=20 > emailAddress RDN. If the peer identity represents a host or=20 > device the certificate SHOULD contain a CN RDN or Serial=20 > Number RDN. The Subject Field of the server certificate MUST=20 > contain the CN RDN or Serial Number RDN containing the Server-ID. =20 >=20 > [rmh] As I understand it the peer ID always (essentially)=20 > looks like a email address so host or otherwise it seems=20 > appropriate to use the emailAddress RDN; this also (based on=20 > my experience) represents current practice with the Subject=20 > DN being deprecated any new name-forms should be proposed in=20 > the subjectAltName shouldn't it? > [Joe] The peer name often takes the form of name@realm, but it does not necessarily have to. Another problem is that some existing device implementations use the email address RDN, but it does not have a unique identifier in it.=20 [rmh] Could you provide me a example? Is it a "unique" device ID of some sort? =20 > > If subject naming > > information is present only in the subjectAltName extension then=20 > > the subject > > field MUST be an empty sequence and the subjectAltName extension > > MUST be critical.=20 > > =20 >=20 > >=20 > > However, in the case where the EAP-TLS peer is=20 > attempting to obtain=20 > > network > > access, it will not have network connectivity and is=20 > therefore not > > capable of checking for certificate revocation until after > > authentication completes and network connectivity is available. =20 > > For this reason EAP-TLS peers and servers SHOULD implement=20 > > Certificate Status Request messages, as described in [RFC3546]=20 > > section 3.6. To enable revocation checking in situations=20 > > where servers do not support Certificate > > Status Request messages and network connectivity is not > > available prior to authentication completion, peer=20 > > implementations SHOULD also support checking for certificate=20 > > revocation after authentication completes and network=20 > connectivity=20 > > is available, and SHOULD utilize this capability. >=20 > [Joe] OK, if we go with OCSP as a SHOULD then I think=20 > checking for certificate revocation after network=20 > authentication completes should be MUST to implement for the=20 > peer since there is a possibility that OCSP will not be=20 > available in the server implementation.=20 > [rmh] Well this should always be a matter of policy (maybe I=20 > have other ways to mitigate this risk in my environment),=20 > this is the core issue with the requirement being a MUST. In=20 > such situations most specs leave these sorts of requirements=20 > as a SHOULD, we could put a MUST in there with some words=20 > that still let you choose though; what do you want to do? >=20 [Joe] Right there is a difference between required to implement and required to deploy. In most cases the MUSTs, SHOULDs, etc are required to implement. A particular deployment can often disable a particular feature if it does not work in their environment.=20 I think in this version of the text we have a MUST requirement for certificate revocation checks which is different than the SHOULD in RFC2716. If the peer must be able to perform certificate validation then it needs to have a mechanism to do this. Since OCSP in TLS (RFC 4366) is a SHOULD it may not be implemented in a server the peer is talking to, in which case the peer must be able to fall back to post connection checks. It seems the first SHOULD in the text refers to support in an implementation and the second refers to deployment. It seems inconsistent to have a MUST for revocation and no mandatory way to do it, but perhaps the MUST for CRL support covers it. =20 [rmh] OK, I buy this. I am OK with changing the SHOULD to a MUST. >=20 > > " > >=20 > > -----Original Message----- > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > Sent: Wednesday, February 14, 2007 1:12 PM > > To: Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > I will do this before I go home today. > >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Wednesday, February 14, 2007 12:27 PM > > To: emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > >=20 > > If possible, I'd like to include text arising from this=20 > thread in the > > -08 > > version of the document, submitted by the IETF 68 deadline. > >=20 > > To make it easier for me to figure out what that text is,=20 > it would be=20 > > helpful for someone to post the suggested changes in their=20 > entirety,=20 > > with modifications agreed to during the discussion. =20 > Further comments=20 > > can then refer to that text, suggesting specific changes. > >=20 > > Having that record on the mailing list will make it a lot=20 > easier for=20 > > me to figure out what changes to make to the document. > >=20 > > Thanks in advance, > >=20 > > Bernard > >=20 > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Feb 18 12:33:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIpuo-0004YU-A7; Sun, 18 Feb 2007 12:33:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIpum-0004YF-Dq for emu@ietf.org; Sun, 18 Feb 2007 12:33:32 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIpuk-00049s-Pr for emu@ietf.org; Sun, 18 Feb 2007 12:33:32 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 18 Feb 2007 09:33:30 -0800 X-IronPort-AV: i="4.14,187,1170662400"; d="scan'208"; a="40291624:sNHT71111304" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1IHXURF026118; Sun, 18 Feb 2007 09:33:30 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1IHXUUw005114; Sun, 18 Feb 2007 09:33:30 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Feb 2007 09:33:29 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 18 Feb 2007 09:33:28 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80042C8A15@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdQdqiYAP9v0hQaTsqVETjl56e3egABgmogAALnjJAABiBe8ABgQpjgAABunAAAAZJR4ABVo2yg From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 18 Feb 2007 17:33:29.0961 (UTC) FILETIME=[E7969D90:01C75382] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6756; t=1171820010; x=1172684010; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=YlkUzh8iT8kChuKZ6yoWBMJL43OeLVe3us8O7dYqNc0=; b=ZcYoC+8h+wlF2YgxJ0+9poDsAG1sslnQN892wrVpRn7MPQR+cpBzMiHYfSoxsm/pxZ2r7K/8 Zoc7p8jC0fRoWXdurAP/Xp5kbHudM47JfiiRSSDQAFMIlX0LfAmlMTE4nzYxN4lkG2KUtXWr9o j8prcykyQ8T+Nu5Pv2YAcVHsQ=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > > [rmh] As I understand it the peer ID always (essentially)=20 > looks like a=20 > > email address so host or otherwise it seems appropriate to use the=20 > > emailAddress RDN; this also (based on my experience) represents=20 > > current practice with the Subject DN being deprecated any new=20 > > name-forms should be proposed in the subjectAltName shouldn't it? > > > [Joe] The peer name often takes the form of name@realm, but=20 > it does not necessarily have to. Another problem is that=20 > some existing device implementations use the email address=20 > RDN, but it does not have a unique identifier in it.=20 > [rmh] Could you provide me a example? Is it a "unique" device=20 > ID of some sort? [Joe] Manufacturing installed certificates will not have a realm since the realm will not be known at manufacturing time. I have seen manufacturing installed certificates where the email address field of the DN contains a contact address such as "support@example.com". I do see your point about email address having a similar form to NAI. Perhaps something like the following would be better text? " If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a emailAddress RDN containing the Peer-Id and the Subject Field of the server certificate SHOULD contain the CN RDN containing the Server-ID. The peer and server ID MAY appear in a different field such as the serialNumber RDN, especially in the case where the deployment realm or domain of the certificate is not known at the time the certificate is issued (for example at manufacturing time). If subject naming information is present only in the subjectAltName extension then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. " > =20 > > > If subject naming > > > information is present only in the subjectAltName=20 > extension then=20 > > > the subject > > > field MUST be an empty sequence and the subjectAltName=20 > extension > > > MUST be critical.=20 > > > =20 > >=20 > > > >=20 > > > However, in the case where the EAP-TLS peer is > > attempting to obtain > > > network > > > access, it will not have network connectivity and is > > therefore not > > > capable of checking for certificate revocation until after > > > authentication completes and network connectivity is=20 > available. =20 > > > For this reason EAP-TLS peers and servers SHOULD implement=20 > > > Certificate Status Request messages, as described in [RFC3546]=20 > > > section 3.6. To enable revocation checking in situations=20 > > > where servers do not support Certificate > > > Status Request messages and network connectivity is not > > > available prior to authentication completion, peer=20 > > > implementations SHOULD also support checking for certificate=20 > > > revocation after authentication completes and network > > connectivity > > > is available, and SHOULD utilize this capability. > >=20 > > [Joe] OK, if we go with OCSP as a SHOULD then I think checking for=20 > > certificate revocation after network authentication=20 > completes should=20 > > be MUST to implement for the peer since there is a possibility that=20 > > OCSP will not be available in the server implementation. > > [rmh] Well this should always be a matter of policy (maybe I have=20 > > other ways to mitigate this risk in my environment), this=20 > is the core=20 > > issue with the requirement being a MUST. In such situations=20 > most specs=20 > > leave these sorts of requirements as a SHOULD, we could put=20 > a MUST in=20 > > there with some words that still let you choose though; what do you=20 > > want to do? > >=20 > [Joe] Right there is a difference between required to=20 > implement and required to deploy. In most cases the MUSTs,=20 > SHOULDs, etc are required to implement. A particular=20 > deployment can often disable a particular feature if it does=20 > not work in their environment.=20 >=20 > I think in this version of the text we have a MUST=20 > requirement for certificate revocation checks which is=20 > different than the SHOULD in RFC2716. If the peer must be=20 > able to perform certificate validation then it needs to have=20 > a mechanism to do this. Since OCSP in TLS (RFC > 4366) is a SHOULD it may not be implemented in a server the=20 > peer is talking to, in which case the peer must be able to=20 > fall back to post connection checks. It seems the first=20 > SHOULD in the text refers to support in an implementation and=20 > the second refers to deployment. It seems inconsistent to=20 > have a MUST for revocation and no mandatory way to do it, but=20 > perhaps the MUST for CRL support covers it. =20 >=20 > [rmh] OK, I buy this. I am OK with changing the SHOULD to a MUST. > >=20 > > > " > > >=20 > > > -----Original Message----- > > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > > Sent: Wednesday, February 14, 2007 1:12 PM > > > To: Bernard Aboba; emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > >=20 > > > I will do this before I go home today. > > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Wednesday, February 14, 2007 12:27 PM > > > To: emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > >=20 > > > If possible, I'd like to include text arising from this > > thread in the > > > -08 > > > version of the document, submitted by the IETF 68 deadline. > > >=20 > > > To make it easier for me to figure out what that text is, > > it would be > > > helpful for someone to post the suggested changes in their > > entirety, > > > with modifications agreed to during the discussion. =20 > > Further comments > > > can then refer to that text, suggesting specific changes. > > >=20 > > > Having that record on the mailing list will make it a lot > > easier for > > > me to figure out what changes to make to the document. > > >=20 > > > Thanks in advance, > > >=20 > > > Bernard > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 20 01:03:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJO5a-00085x-9w; Tue, 20 Feb 2007 01:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJO5Z-00085s-3L for emu@ietf.org; Tue, 20 Feb 2007 01:02:57 -0500 Received: from bay0-omc3-s24.bay0.hotmail.com ([65.54.246.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJO5X-0007Ag-H8 for emu@ietf.org; Tue, 20 Feb 2007 01:02:57 -0500 Received: from hotmail.com ([207.46.8.94]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 19 Feb 2007 22:02:55 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Feb 2007 22:02:54 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 20 Feb 2007 06:02:50 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Mon, 19 Feb 2007 22:02:50 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 Feb 2007 06:02:54.0948 (UTC) FILETIME=[C338E240:01C754B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >From the discussion it seems that if OCSP is a SHOULD implement, then we need a MUST for revocation checking after authentication, since some servers might not implement OCSP, right? I don't think we can add "MUST use" text for something that is a "SHOULD implement". In terms of usage, it is possible for the Peer-Id to represent a machine name. For example, with EAP-TLS the peer could use a machine certificate for authentication. So I think that the text on subjectAltName as well as the subject name field needs to reflect this. BTW, I'm not entirely clear that the NAI syntax is completely compatible with that of an email address, although they are pretty close. For example, RFC 4282 defines internationalization of the username field in the NAI, but for email addresses we aren't there yet. This has come up in other contexts too (e.g. IKEv2 Identity Payload) where it turned out not to be a big deal, but I thought it was worth pointing out, just in case someone knows otherwise. On the server side, I don't think that the Server-Id is likely to be an NAI, although I'm not sure we can prohibit that. Based on the comments and my own cleanup, here is where I think we are at the moment. Comments welcome. ===================================================== 5.2. Peer and Server Identities The EAP-TLS peer name (Peer-Id) represents the identity 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 in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as per Section 5.3. If subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. Where the peer identity represents a host, a subjectAltName of type dNSName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If a dnsName or rfc822Name are not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used. If subject naming information is present only in the subject name field and the peer identity represents a user, then the subject name field SHOULD contain an emailAddress RDN. If the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or Serial Number RDN. If subject naming information is present only in the subject name field of a server certificate, then the subject name field MUST contain a CN RDN or Serial Number RDN. 5.3. Certificate Validation Since the EAP-TLS server is typically connected to the Internet, it SHOULD support validating the peer certificate using RFC 3280 [RFC3280] conformant path validation, including the ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details, see [RFC3280] Section 4.2.2.1. Where the EAP-TLS server is unable to retrieve intermediate certificates, it must be pre-configured with the necessary intermediate certificates to complete path validation or rely on the EAP-TLS peer to provide this information as part of the TLS Handshake (see [RFC4346] section 7.4.6). In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore the EAP-TLS server SHOULD provide its entire certificate chain minus the root to facilitate certificate validation by the peer. Once a TLS session is established EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS. 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-TLS Peer-Id and Server-Id determined as described in Section 5.2. In the case of the EAP-TLS peer this involves ensuring that the certificate presented by the EAP-TLS server was intended to be used as a server certificate. Implementations SHOULD use the Extended Key Usage (see [RFC3280] section 4.2.1.13) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-serverAuth identifier in the certificate (See [RFC3280] section 4.2.1.13). When performing this comparison implementations MUST follow the validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate presented by the EAP-TLS peer was intended to be used as a client certificate. Implementations SHOULD use the Extended Key Usage (see [RFC3280] Section 4.2.1.13) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate (see [RFC3280] section 4.2.1.13). 5.4. Certificate Revocation Certificates are long lived assertions of identity. Therefore it is important for EAP-TLS implementations to be capable of checking whether these assertions have been revoked. EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server implementations SHOULD also support the Online Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten connection times especially in bandwidth constrained environments. While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes. In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. However, in the case where the EAP-TLS peer is attempting to obtain network access, it will not have network connectivity and is therefore not capable of checking for certificate revocation until after authentication completes and network connectivity is available. For this reason EAP-TLS peers and servers SHOULD implement Certificate Status Request messages, as described in [RFC3546] section 3.6. To enable revocation checking in situations where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 20 14:07:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaKo-00042s-Nr; Tue, 20 Feb 2007 14:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaKn-00042n-Ih for emu@ietf.org; Tue, 20 Feb 2007 14:07:29 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaKk-0005fx-Ts for emu@ietf.org; Tue, 20 Feb 2007 14:07:29 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 20 Feb 2007 11:07:26 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 20 Feb 2007 11:07:26 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Tue, 20 Feb 2007 11:07:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 20 Feb 2007 11:07:08 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004384ACD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4Ng References: From: Ryan Hurst To: Bernard Aboba , X-OriginalArrivalTime: 20 Feb 2007 19:07:25.0755 (UTC) FILETIME=[5B9C08B0:01C75522] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org In-line -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, February 19, 2007 10:03 PM To: emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >From the discussion it seems that if OCSP is a SHOULD implement, then we=20 need a MUST for revocation checking after authentication, since some servers=20 might not implement OCSP, right? I don't think we can add "MUST use" text=20 for something that is a "SHOULD implement". In terms of usage, it is possible for the Peer-Id to represent a machine name. For example, with EAP-TLS the peer could use a machine certificate=20 for authentication. So I think that the text on subjectAltName as well as=20 the subject name field needs to reflect this. BTW, I'm not entirely clear that the NAI syntax is completely compatible with that of an email address, although they are pretty close. For example,=20 RFC 4282 defines internationalization of the username field in the NAI, but=20 for email addresses we aren't there yet. This has come up in other contexts=20 too (e.g. IKEv2 Identity Payload) where it turned out not to be a big deal,=20 but I thought it was worth pointing out, just in case someone knows=20 otherwise. On the server side, I don't think that the Server-Id is likely to be an NAI,=20 although I'm not sure we can prohibit that. Based on the comments and my own cleanup, here is where I think we are at=20 the moment. Comments welcome. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 5.2. Peer and Server Identities The EAP-TLS peer name (Peer-Id) represents the identity 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). [rmh] We do not universally quote deep references in this document, what criteria are being applied to determine which references will warrant a reference + quote vs. just a reference? Where the subjectAltName field is present in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as per Section 5.3. If subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. Where the peer identity represents a host, a subjectAltName of type dNSName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If a dnsName or rfc822Name are not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used. If subject naming information is present only in the subject name field and the peer identity represents a user, then the subject name field SHOULD contain an emailAddress RDN. If the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or Serial Number RDN. [rmh] If you say they can include a serialNumber (not Serial Number) RDN then you have to specify processing symantics when more than one are present, and discuss what sort of value is used here, etc. [rmh] I suggest dropping the " or Serial Number RDN" portion of this text, we can if appropriate work on a appendix or other RFC that discusses these issues; I suspect the right answer will be to reference the Permanent Identifier RFC from the PKIX working group which already deals with these problems. If subject naming information is present only in the subject name field of a server certificate, then the subject name field MUST contain a CN RDN or Serial Number RDN. [rmh] See my prior statements on serialNumber RDN. 5.3. Certificate Validation Since the EAP-TLS server is typically connected to the Internet, it SHOULD support validating the peer certificate using RFC 3280 [RFC3280] conformant path validation, including the ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details, see [RFC3280] Section 4.2.2.1. Where the EAP-TLS server is unable to retrieve intermediate certificates, it must be pre-configured with the necessary intermediate certificates to complete path validation or rely on the EAP-TLS peer to provide this information as part of the TLS Handshake (see [RFC4346] section 7.4.6). In contrast to the EAP-TLS server, the EAP-TLS peer may not have Internet connectivity. Therefore the EAP-TLS server SHOULD provide its entire certificate chain minus the root to facilitate certificate validation by the peer. Once a TLS session is established EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS. 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-TLS Peer-Id and Server-Id determined as described in Section 5.2. In the case of the EAP-TLS peer this involves ensuring that the certificate presented by the EAP-TLS server was intended to be used as a server certificate. Implementations SHOULD use the Extended Key Usage (see [RFC3280] section 4.2.1.13) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-serverAuth identifier in the certificate (See [RFC3280] section 4.2.1.13). When performing this comparison implementations MUST follow the validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate presented by the EAP-TLS peer was intended to be used as a client certificate. Implementations SHOULD use the Extended Key Usage (see [RFC3280] Section 4.2.1.13) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate (see [RFC3280] section 4.2.1.13). 5.4. Certificate Revocation Certificates are long lived assertions of identity. Therefore it is important for EAP-TLS implementations to be capable of checking whether these assertions have been revoked. EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs); for details, see [RFC3280] section 3.3. EAP-TLS peer and server implementations SHOULD also support the Online Certificate Status Protocol (OCSP), described in [RFC2560]. OCSP messages are typically much smaller than CRLs which can shorten connection times especially in bandwidth constrained environments. While EAP-TLS servers are typically connected to the Internet during the EAP conversation, an EAP-TLS peer may not have Internet connectivity until authentication completes. In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. However, in the case where the EAP-TLS peer is attempting to obtain network access, it will not have network connectivity and is therefore not capable of checking for certificate revocation until after authentication completes and network connectivity is available. For this reason EAP-TLS peers and servers SHOULD implement Certificate Status Request messages, as described in [RFC3546] section 3.6. To enable revocation checking in situations where servers do not support Certificate Status Request messages and network connectivity is not available prior to authentication completion, peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 20 23:54:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJjUz-0003Ig-R8; Tue, 20 Feb 2007 23:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJjUy-0003Ib-NJ for emu@ietf.org; Tue, 20 Feb 2007 23:54:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJjUx-0005Ms-CT for emu@ietf.org; Tue, 20 Feb 2007 23:54:36 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2007 20:54:35 -0800 X-IronPort-AV: i="4.14,198,1170662400"; d="scan'208"; a="391534168:sNHT949777404" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1L4sYZX000507; Tue, 20 Feb 2007 20:54:34 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1L4sPDu024390; Tue, 20 Feb 2007 20:54:34 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 20:54:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 20 Feb 2007 20:54:28 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004384ACD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4NgABP+5qA= From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 21 Feb 2007 04:54:29.0928 (UTC) FILETIME=[5EDA4A80:01C75574] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1774; t=1172033674; x=1172897674; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=0gRJTNF3cSDP52Z4Q6m9IfnWMoJtEIUOobWDu9U2/wI=; b=YpVTepBMEJbZGZbUsgINcewBpfueygb80+EDTYlr+RIq8NwthF+MfVVstgF7Y/EWQddQAl9A 5dYzaGrT4lb3FbgEeC4t2r3/x6XLgJCeUtJwHXdCBDG/pgUe2rZh+MpE; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 >=20 > If subject naming information is present only in the subject name > field and the peer identity represents a user, then the=20 > subject name > field SHOULD contain an emailAddress RDN. If the peer identity > represents a host or device the subject name field SHOULD contain a > CN RDN or Serial Number RDN. > [rmh] If you say they can include a serialNumber (not Serial=20 > Number) RDN then you have to specify processing symantics=20 > when more than one are present, and discuss what sort of=20 > value is used here, etc. > [rmh] I suggest dropping the " or Serial Number RDN" portion=20 > of this text, we can if appropriate work on a appendix or=20 > other RFC that discusses these issues; I suspect the right=20 > answer will be to reference the Permanent Identifier RFC from=20 > the PKIX working group which already deals with these problems. >=20 [Joe] Would you not have to do the same with email address or CN? It seems it would be possible for multiple of these to be present. There should not be any semantics associated with a serial number other than it is an identifier. It should not be interpreted as a MAC address or some other value without additional knowledge outside this specification. I agree that this would not be the place to consistently find a MAC address. I would prefer to keep Serial Number as a possibility as it is at least as relevant as the other fields. I would be fine with the previous text I posted with a MAY.=20 > If subject naming information is present only in the subject name > field of a server certificate, then the subject name field MUST > contain a CN RDN or Serial Number RDN. > [rmh] See my prior statements on serialNumber RDN. >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 20 23:55:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJjVm-0003Yr-8q; Tue, 20 Feb 2007 23:55:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJjVl-0003Yj-1g for emu@ietf.org; Tue, 20 Feb 2007 23:55:25 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJjVk-0005RG-B8 for emu@ietf.org; Tue, 20 Feb 2007 23:55:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2007 20:55:22 -0800 X-IronPort-AV: i="4.14,198,1170662400"; d="scan'208"; a="763671179:sNHT59220900" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1L4tLDc010208; Tue, 20 Feb 2007 20:55:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1L4tLGk012474; Tue, 20 Feb 2007 20:55:21 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 20:55:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 20 Feb 2007 20:55:19 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN0P56ibJ/K5TZK2Z0hPblsOngAv5HMQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 21 Feb 2007 04:55:21.0318 (UTC) FILETIME=[7D7BC860:01C75574] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10300; t=1172033721; x=1172897721; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=RH52eP0lLZX9kSUkEleOPk/hg9vv2Z6PLXgi5Wmy/5E=; b=LMZzClijBQ91vedvnQjq2A8oocte6jGFRdhLrzhpPgYOP5m7WxBg0lWX1w4jojZ3Ve8ZfY3J hNrwBeLo7A1Mr2kUwmfaf0wcObgR28ygunRzDxcWcgKJcbssof/ZKuVf; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This text looks fine to me.=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, February 19, 2007 10:03 PM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > >From the discussion it seems that if OCSP is a SHOULD=20 > implement, then=20 > >we > need a MUST for revocation checking after authentication,=20 > since some servers might not implement OCSP, right? I don't=20 > think we can add "MUST use" text for something that is a=20 > "SHOULD implement". >=20 > In terms of usage, it is possible for the Peer-Id to=20 > represent a machine name. For example, with EAP-TLS the peer=20 > could use a machine certificate for authentication. So I=20 > think that the text on subjectAltName as well as the subject=20 > name field needs to reflect this. >=20 > BTW, I'm not entirely clear that the NAI syntax is completely=20 > compatible with that of an email address, although they are=20 > pretty close. For example, RFC 4282 defines=20 > internationalization of the username field in the NAI, but=20 > for email addresses we aren't there yet. This has come up in=20 > other contexts too (e.g. IKEv2 Identity Payload) where it=20 > turned out not to be a big deal, but I thought it was worth=20 > pointing out, just in case someone knows otherwise. >=20 > On the server side, I don't think that the Server-Id is=20 > likely to be an NAI, although I'm not sure we can prohibit that. >=20 > Based on the comments and my own cleanup, here is where I=20 > think we are at the moment. >=20 > Comments welcome. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2. Peer and Server Identities >=20 > The EAP-TLS peer name (Peer-Id) represents the identity to be used > for access control and accounting purposes. The Server-Id=20 > represents > the identity of the EAP server. >=20 > In EAP-TLS, the Peer-Id and Server-Id are determined from=20 > the subject > or subjectAltName fields in the peer and server certificates. As > noted in [RFC3280] Section 4.1.2.6: >=20 > The subject field identifies the entity associated with=20 > the public > key stored in the subject public key field. The=20 > subject name MAY > be carried in the subject field and/or the subjectAltName > extension... If subject naming information is present=20 > 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. >=20 > Where it is non-empty, the subject field MUST contain an X.500 > distinguished name (DN). >=20 > Where the subjectAltName field is present in the peer or server > certificate, the Peer-Id or Server-Id MUST be set to the=20 > contents of > the subjectAltName as per Section 5.3. If subject naming=20 > information > is present only in the subjectAltName extension of a peer or server > certificate, then the subject field MUST be an empty=20 > sequence and the > subjectAltName extension MUST be critical. Although the=20 > use of the > subject field is existing practice, its use in EAP-TLS is=20 > deprecated > and Certification Authorities are encouraged to use the > subjectAltName field instead. >=20 > Where the peer identity represents a host, a subjectAltName of type > dNSName SHOULD be present in the peer certificate. Where the peer > identity represents a user and not a resource, a subjectAltName of > type rfc822Name SHOULD be used, conforming to the grammar for the > Network Access Identifier (NAI) defined in [RFC4282]=20 > Section 2.1. If > a dnsName or rfc822Name are not available other field types (for > example a subjectAltName of type iPAdress or > uniformResourceIdentifier) MAY be used. >=20 > A server identity will typically represent a host, not a user or a > resource. As a result, a subjectAltName of type dNSName SHOULD be > present in the server certificate. If a dnsName is not available > other field types (for example a subjectAltName of type iPAdress or > uniformResourceIdentifier) MAY be used. >=20 > If subject naming information is present only in the subject name > field and the peer identity represents a user, then the=20 > subject name > field SHOULD contain an emailAddress RDN. If the peer identity > represents a host or device the subject name field SHOULD contain a > CN RDN or Serial Number RDN. >=20 > If subject naming information is present only in the subject name > field of a server certificate, then the subject name field MUST > contain a CN RDN or Serial Number RDN. >=20 > 5.3. Certificate Validation >=20 > Since the EAP-TLS server is typically connected to the Internet, it > SHOULD support validating the peer certificate using RFC 3280 > [RFC3280] conformant path validation, including the ability to > retrieve intermediate certificates that may be necessary=20 > to validate > the peer certificate. For details, see [RFC3280] Section 4.2.2.1. >=20 > Where the EAP-TLS server is unable to retrieve intermediate > certificates, it must be pre-configured with the necessary > intermediate certificates to complete path validation or=20 > rely on the > EAP-TLS peer to provide this information as part of the=20 > TLS Handshake > (see [RFC4346] section 7.4.6). >=20 > In contrast to the EAP-TLS server, the EAP-TLS peer may not have > Internet connectivity. Therefore the EAP-TLS server SHOULD provide > its entire certificate chain minus the root to facilitate=20 > certificate > validation by the peer. >=20 > Once a TLS session is established EAP-TLS peer and server > implementations MUST validate that the identities=20 > represented in the > certificate are appropriate and authorized for use with=20 > EAP-TLS. 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-TLS Peer-Id and Server-Id determined as described in=20 > Section 5.2. >=20 > In the case of the EAP-TLS peer this involves ensuring that the > certificate presented by the EAP-TLS server was intended to be used > as a server certificate. Implementations SHOULD use the=20 > Extended Key > Usage (see [RFC3280] section 4.2.1.13) extension and ensure that at > least one of the following is true: >=20 > 1) The certificate issuer included no Extended Key Usage > identifiers in the certificate. > 2) The issuer included the anyExtendedKeyUsage identifier > in the certificate (see [RFC3280] section 4.2.1.13). > 3) The issuer included the id-kp-serverAuth identifier > in the certificate (See [RFC3280] section 4.2.1.13). >=20 > When performing this comparison implementations MUST follow the > validation rules specified in [RFC2818] Section 3.1. In=20 > the case of > the server this involves ensuring the certificate presented by the > EAP-TLS peer was intended to be used as a client certificate. > Implementations SHOULD use the Extended Key Usage (see [RFC3280] > Section 4.2.1.13) extension and ensure that at least one of the > following is true: >=20 > 1) The certificate issuer included no Extended Key Usage > identifiers in the certificate. > 2) The issuer included the anyExtendedKeyUsage identifier in > the certificate (see [RFC3280] section 4.2.1.13). > 3) The issuer included the id-kp-clientAuth identifier in > the certificate (see [RFC3280] section 4.2.1.13). >=20 > 5.4. Certificate Revocation >=20 > Certificates are long lived assertions of identity. =20 > Therefore it is > important for EAP-TLS implementations to be capable of checking > whether these assertions have been revoked. >=20 > EAP-TLS peer and server implementations MUST support the use of > Certificate Revocation Lists (CRLs); for details, see [RFC3280] > section 3.3. EAP-TLS peer and server implementations SHOULD also > support the Online Certificate Status Protocol (OCSP), described in > [RFC2560]. OCSP messages are typically much smaller than=20 > CRLs which > can shorten connection times especially in bandwidth constrained > environments. While EAP-TLS servers are typically connected to the > Internet during the EAP conversation, an EAP-TLS peer may not have > Internet connectivity until authentication completes. >=20 > In the case where the peer is initiating a voluntary Layer 2 tunnel > using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically > already have a PPP interface and Internet connectivity=20 > established at > the time of tunnel initiation. >=20 > However, in the case where the EAP-TLS peer is attempting to obtain > network access, it will not have network connectivity and is > therefore not capable of checking for certificate revocation until > after authentication completes and network connectivity is=20 > available. > For this reason EAP-TLS peers and servers SHOULD implement > Certificate Status Request messages, as described in [RFC3546] > section 3.6. To enable revocation checking in situations where > servers do not support Certificate Status Request messages and > network connectivity is not available prior to authentication > completion, peer implementations MUST also support checking for > certificate revocation after authentication completes and network > connectivity is available, and they SHOULD utilize this=20 > capability by > default. >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 21 00:53:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJkQ7-0005v2-GQ; Wed, 21 Feb 2007 00:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJkQ6-0005q0-5W for emu@ietf.org; Wed, 21 Feb 2007 00:53:38 -0500 Received: from bay0-omc2-s3.bay0.hotmail.com ([65.54.246.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJkQ4-0000UG-NA for emu@ietf.org; Wed, 21 Feb 2007 00:53:38 -0500 Received: from hotmail.com ([207.46.8.94]) by bay0-omc2-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 20 Feb 2007 21:53:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Feb 2007 21:53:35 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 21 Feb 2007 05:53:31 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004384ACD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Bernard Aboba" To: Ryan.Hurst@microsoft.com, emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Tue, 20 Feb 2007 21:53:31 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Feb 2007 05:53:35.0783 (UTC) FILETIME=[A058D370:01C7557C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > 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). > >[rmh] We do not universally quote deep references in this document, what >criteria are being applied to determine which references will warrant a >reference + quote vs. just a reference? [BA] I just realized that the last sentence of the first paragraph is already in the document. I think the quote can be eliminated if we add the sentence "where it is non-empty..." into the text as well. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 21 11:49:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJueW-0004bm-JQ; Wed, 21 Feb 2007 11:49:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJueV-0004bU-BE for emu@ietf.org; Wed, 21 Feb 2007 11:49:11 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJueQ-0003Ho-TB for emu@ietf.org; Wed, 21 Feb 2007 11:49:11 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Feb 2007 08:49:06 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Wed, 21 Feb 2007 08:49:05 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 21 Feb 2007 08:49:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 08:48:48 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622A@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdVfKXRM2vkpJq5Re6mZpjKs3H6vQAW4LcB References: From: Ryan Hurst To: "Bernard Aboba" , X-OriginalArrivalTime: 21 Feb 2007 16:49:05.0168 (UTC) FILETIME=[327CB900:01C755D8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1136238524==" Errors-To: emu-bounces@ietf.org --===============1136238524== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755D8.324722B2" ------_=_NextPart_001_01C755D8.324722B2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sounds like a good compromise. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Tue 2/20/2007 9:53 PM To: Ryan Hurst; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > 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). > >[rmh] We do not universally quote deep references in this document, = what >criteria are being applied to determine which references will warrant a >reference + quote vs. just a reference? [BA] I just realized that the last sentence of the first paragraph is already in the document. I think the quote can be eliminated if we add = the sentence "where it is non-empty..." into the text as well. ------_=_NextPart_001_01C755D8.324722B2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt=0A= =0A= =0A= =0A=
=0A=
Sounds like a = good compromise.
=0A=

=0A=
=0A= From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]
Sent: Tue 2/20/2007 9:53 = PM
To: Ryan Hurst; emu@ietf.org
Subject: RE: [Emu] = RE: draft-simon-emu-rfc2716bis-07.txt

=0A=
=0A=

>       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).
>
>[rmh] We do not universally quote deep references = in this document, what
>criteria are being applied to determine = which references will warrant a
>reference + quote vs. just a = reference?

[BA] I just realized that the last sentence of the = first paragraph is
already in the document.  I think the quote = can be eliminated if we add the
sentence "where it is non-empty..." = into the text as well.


------_=_NextPart_001_01C755D8.324722B2-- --===============1136238524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1136238524==-- From emu-bounces@ietf.org Wed Feb 21 11:55:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJukZ-0005kt-ER; Wed, 21 Feb 2007 11:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJukY-0005kc-IZ for emu@ietf.org; Wed, 21 Feb 2007 11:55:26 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJukX-00054S-2L for emu@ietf.org; Wed, 21 Feb 2007 11:55:26 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Feb 2007 08:55:24 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 21 Feb 2007 08:55:23 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 21 Feb 2007 08:55:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 08:50:21 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4NgABP+5qAAGcIyGg== References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 21 Feb 2007 16:55:22.0676 (UTC) FILETIME=[137FDF40:01C755D9] X-Spam-Score: 0.5 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1157386325==" Errors-To: emu-bounces@ietf.org --===============1157386325== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755D9.0D903A20" ------_=_NextPart_001_01C755D9.0D903A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable in-line ________________________________ From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Tue 2/20/2007 8:54 PM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > If subject naming information is present only in the subject name > field and the peer identity represents a user, then the > subject name > field SHOULD contain an emailAddress RDN. If the peer identity > represents a host or device the subject name field SHOULD contain a > CN RDN or Serial Number RDN. > [rmh] If you say they can include a serialNumber (not Serial > Number) RDN then you have to specify processing symantics > when more than one are present, and discuss what sort of > value is used here, etc. > [rmh] I suggest dropping the " or Serial Number RDN" portion > of this text, we can if appropriate work on a appendix or > other RFC that discusses these issues; I suspect the right > answer will be to reference the Permanent Identifier RFC from > the PKIX working group which already deals with these problems. > [Joe] Would you not have to do the same with email address or CN? It seems it would be possible for multiple of these to be present. There should not be any semantics associated with a serial number other than it is an identifier. It should not be interpreted as a MAC address or some other value without additional knowledge outside this specification. I agree that this would not be the place to consistently find a MAC address. I would prefer to keep Serial Number as a possibility as it is at least as relevant as the other fields. I would be fine with the previous text I posted with a MAY. [rmh] Although your right that the fact that multiple RDNs can be used = to make up a DN universally other RDNs are non-ambiguous while = serialNumber conceptually is not, [rmh] As for the value, EAP is not 802.11 only therefore a device id = should not be a MAC, also a MAC has locally administered and globally = adminstered versions, you would probably want to restrict the use to the = globally issued ones, then there are the privacy issues since the MAC is = used as a source address a attacker can presume if a EAP authentication = is succesfull the MAC used in the source address was authenticated. I = think there are other issues related to it being a MAC address that = should be thought through before it is added; especially if its not even = common practice today which it doesnt apear to be. > If subject naming information is present only in the subject name > field of a server certificate, then the subject name field MUST > contain a CN RDN or Serial Number RDN. > [rmh] See my prior statements on serialNumber RDN. > > ------_=_NextPart_001_01C755D9.0D903A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt=0A= =0A= =0A= =0A=
=0A=
in-line
=0A=

=0A=
=0A= From: Joseph Salowey (jsalowey) = [mailto:jsalowey@cisco.com]
Sent: Tue 2/20/2007 8:54 = PM
To: Ryan Hurst; Bernard Aboba; = emu@ietf.org
Subject: RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt

=0A=
=0A=



>
>    If subject naming information = is present only in the subject name
>    field and = the peer identity represents a user, then the
> subject = name
>    field SHOULD contain an emailAddress = RDN.  If the peer identity
>    represents a = host or device the subject name field SHOULD contain = a
>    CN RDN or Serial Number RDN.
> [rmh] = If you say they can include a serialNumber (not Serial
> Number) = RDN then you have to specify processing symantics
> when more than = one are present, and discuss what sort of
> value is used here, = etc.
> [rmh] I suggest dropping the " or Serial Number RDN" = portion
> of this text, we can if appropriate work on a appendix = or
> other RFC that discusses these issues; I suspect the = right
> answer will be to reference the Permanent Identifier RFC = from
> the PKIX working group which already deals with these = problems.
>

[Joe] Would you not have to do the same with = email address or CN?  It
seems it would be possible for multiple = of these to be present.  There
should not be any semantics = associated with a serial number other than
it is an identifier.  = It should not be interpreted as a MAC address or
some other value = without additional knowledge outside this
specification.  I = agree that this would not be the place to consistently
find a MAC = address. I would prefer to keep Serial Number as a
possibility as it = is at least as relevant as the other fields.  I would
be fine = with the previous text I posted with a MAY.

=0A=

[rmh] Although your right that the fact that multiple RDNs can be = used to make up a DN universally other RDNs are non-ambiguous while = serialNumber conceptually is not,

=0A=

[rmh] As for the value, EAP is not 802.11 only therefore a device id = should not be a MAC, also a MAC has locally administered and globally = adminstered versions, you would probably want to restrict the use to the = globally issued ones, then there are the privacy issues since the MAC is = used as a source address a attacker can presume if a EAP authentication = is succesfull the MAC used in the source address was authenticated. I = think there are other issues related to it being a MAC address that = should be thought through before it is added; especially if its not even = common practice today which it doesnt apear to be.

=0A=


>    If subject naming information is present = only in the subject name
>    field of a server = certificate, then the subject name field MUST
>    = contain a CN RDN or Serial Number RDN.
> [rmh] See my prior = statements on serialNumber = RDN.
>
>

------_=_NextPart_001_01C755D9.0D903A20-- --===============1157386325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1157386325==-- From emu-bounces@ietf.org Wed Feb 21 12:04:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJusz-0007cU-KJ; Wed, 21 Feb 2007 12:04:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJusy-0007cD-Lz for emu@ietf.org; Wed, 21 Feb 2007 12:04:08 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJusw-0007l2-Po for emu@ietf.org; Wed, 21 Feb 2007 12:04:08 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 21 Feb 2007 09:04:06 -0800 X-IronPort-AV: i="4.14,202,1170662400"; d="scan'208,217"; a="114868623:sNHT93589101" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1LH46wV008899; Wed, 21 Feb 2007 09:04:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1LH46ho028078; Wed, 21 Feb 2007 09:04:06 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 09:04:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 09:04:04 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4NgABP+5qAAGcIyGgAAY6Pw From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 21 Feb 2007 17:04:05.0844 (UTC) FILETIME=[4B54F940:01C755DA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7389; t=1172077446; x=1172941446; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=bVGEzo7eMPOCbB5TTXZ8epIddsqjoxbcWzal0IXW6ws=; b=yZ+3PSwPr8rUIPyij2hJCcGceufWAoHiIbznayHVVlsb+uhOxRg2yxR3RqN45cBrILBEOLpB Adwa87/2FP3YCUbV+xLbqn0Tj+S+Kwo3msnoOtMm3Xy38ME/gVFyajln; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1049777741==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1049777741== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755DA.4B1949A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C755DA.4B1949A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 > If subject naming information is present only in the subject name > field and the peer identity represents a user, then the > subject name > field SHOULD contain an emailAddress RDN. If the peer identity > represents a host or device the subject name field SHOULD contain a > CN RDN or Serial Number RDN. > [rmh] If you say they can include a serialNumber (not Serial > Number) RDN then you have to specify processing symantics > when more than one are present, and discuss what sort of > value is used here, etc. > [rmh] I suggest dropping the " or Serial Number RDN" portion > of this text, we can if appropriate work on a appendix or > other RFC that discusses these issues; I suspect the right > answer will be to reference the Permanent Identifier RFC from > the PKIX working group which already deals with these problems. > =09 [Joe] Would you not have to do the same with email address or CN? It seems it would be possible for multiple of these to be present. There should not be any semantics associated with a serial number other than it is an identifier. It should not be interpreted as a MAC address or some other value without additional knowledge outside this specification. I agree that this would not be the place to consistently find a MAC address. I would prefer to keep Serial Number as a possibility as it is at least as relevant as the other fields. I would be fine with the previous text I posted with a MAY. =09 [rmh] Although your right that the fact that multiple RDNs can be used to make up a DN universally other RDNs are non-ambiguous while serialNumber conceptually is not,=20 [Joe] Can you expand upon this? Why is SerialNumber different than other RDNs?=20 [rmh] As for the value, EAP is not 802.11 only therefore a device id should not be a MAC, also a MAC has locally administered and globally adminstered versions, you would probably want to restrict the use to the globally issued ones, then there are the privacy issues since the MAC is used as a source address a attacker can presume if a EAP authentication is succesfull the MAC used in the source address was authenticated. I think there are other issues related to it being a MAC address that should be thought through before it is added; especially if its not even common practice today which it doesnt apear to be. [Joe] I think we are in agreement here. =20 =20 > If subject naming information is present only in the subject name > field of a server certificate, then the subject name field MUST > contain a CN RDN or Serial Number RDN. > [rmh] See my prior statements on serialNumber RDN. > > =09 ------_=_NextPart_001_01C755DA.4B1949A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt
 

>    If subject naming information = is=20 present only in the subject name
>    field and = the peer=20 identity represents a user, then the
> subject=20 name
>    field SHOULD contain an emailAddress = RDN. =20 If the peer identity
>    represents a host or = device the=20 subject name field SHOULD contain a
>    CN RDN = or Serial=20 Number RDN.
> [rmh] If you say they can include a serialNumber = (not=20 Serial
> Number) RDN then you have to specify processing=20 symantics
> when more than one are present, and discuss what = sort=20 of
> value is used here, etc.
> [rmh] I suggest dropping = the " or=20 Serial Number RDN" portion
> of this text, we can if appropriate = work on=20 a appendix or
> other RFC that discusses these issues; I suspect = the=20 right
> answer will be to reference the Permanent Identifier RFC = from
> the PKIX working group which already deals with these=20 problems.
>

[Joe] Would you not have to do the same with = email=20 address or CN?  It
seems it would be possible for multiple of = these to=20 be present.  There
should not be any semantics associated with = a=20 serial number other than
it is an identifier.  It should not = be=20 interpreted as a MAC address or
some other value without additional = knowledge outside this
specification.  I agree that this would = not be=20 the place to consistently
find a MAC address. I would prefer to = keep Serial=20 Number as a
possibility as it is at least as relevant as the other=20 fields.  I would
be fine with the previous text I posted with = a=20 MAY.

[rmh] Although your right that the fact that = multiple RDNs can=20 be used to make up a DN universally other RDNs are non-ambiguous while = serialNumber conceptually is not, 

[Joe] Can you expand upon this? Why is = SerialNumber=20 different than other RDNs? 

[rmh] As for the value, EAP is not 802.11 only = therefore a=20 device id should not be a MAC, also a MAC has locally administered and = globally adminstered versions, you would probably want to restrict the = use to=20 the globally issued ones, then there are the privacy issues since the = MAC is=20 used as a source address a attacker can presume if a EAP = authentication is=20 succesfull the MAC used in the source address was authenticated. I = think there=20 are other issues related to it being a MAC address that should be = thought=20 through before it is added; especially if its not even common practice = today=20 which it doesnt apear to be.

[Joe]  I think we are in agreement here. =  

 
>    If subject naming information is = present only in=20 the subject name
>    field of a server = certificate, then=20 the subject name field MUST
>    contain a CN RDN = or=20 Serial Number RDN.
> [rmh] See my prior statements on = serialNumber=20 RDN.
>
>

------_=_NextPart_001_01C755DA.4B1949A9-- --===============1049777741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1049777741==-- From emu-bounces@ietf.org Wed Feb 21 12:15:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJv4D-0000pL-Gf; Wed, 21 Feb 2007 12:15:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJv4C-0000pA-Ai for emu@ietf.org; Wed, 21 Feb 2007 12:15:44 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJv47-0002if-Nd for emu@ietf.org; Wed, 21 Feb 2007 12:15:44 -0500 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Feb 2007 09:15:39 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Wed, 21 Feb 2007 09:15:38 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 21 Feb 2007 09:15:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 09:15:22 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4NgABP+5qAAGcIyGgAAY6PwAABEifo= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 21 Feb 2007 17:15:38.0309 (UTC) FILETIME=[E812BF50:01C755DB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1614354262==" Errors-To: emu-bounces@ietf.org --===============1614354262== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755DB.DED494A6" ------_=_NextPart_001_01C755DB.DED494A6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable in-line ________________________________ From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wed 2/21/2007 9:04 AM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =20 > If subject naming information is present only in the subject name > field and the peer identity represents a user, then the > subject name > field SHOULD contain an emailAddress RDN. If the peer identity > represents a host or device the subject name field SHOULD contain = a > CN RDN or Serial Number RDN. > [rmh] If you say they can include a serialNumber (not Serial > Number) RDN then you have to specify processing symantics > when more than one are present, and discuss what sort of > value is used here, etc. > [rmh] I suggest dropping the " or Serial Number RDN" portion > of this text, we can if appropriate work on a appendix or > other RFC that discusses these issues; I suspect the right > answer will be to reference the Permanent Identifier RFC from > the PKIX working group which already deals with these problems. > =09 [Joe] Would you not have to do the same with email address or CN? It seems it would be possible for multiple of these to be present. There should not be any semantics associated with a serial number other than it is an identifier. It should not be interpreted as a MAC address or some other value without additional knowledge outside this specification. I agree that this would not be the place to = consistently find a MAC address. I would prefer to keep Serial Number as a possibility as it is at least as relevant as the other fields. I would be fine with the previous text I posted with a MAY. =09 [rmh] Although your right that the fact that multiple RDNs can be used = to make up a DN universally other RDNs are non-ambiguous while = serialNumber conceptually is not,=20 [Joe] Can you expand upon this? Why is SerialNumber different than = other RDNs?=20 [rmh] Conceptually a serial number is a exact match to a entity, for = example no two tivos share the same serial number but they could all = share the same common name of Tivo Series 2. [rmh] In my case case there is a actor who also shares the name Ryan = Hurst (http://www.imdb.com/name/nm0403652/) but we both have unique = ssns. [rmh] Since its CN is not intended to be non-ambiguous its reasonable = for me to have multiple CNs in a certificate all of which are = appropriate as a common name of me; for example I could have one that is = just Ryan, another that is Ryan Hurst, another that is Ryan M Hurst. [rmh] Since a serial number is a exact match, what does it mean if you = have multiple serial numbers? [rmh] As for the value, EAP is not 802.11 only therefore a device id = should not be a MAC, also a MAC has locally administered and globally = adminstered versions, you would probably want to restrict the use to the = globally issued ones, then there are the privacy issues since the MAC is = used as a source address a attacker can presume if a EAP authentication = is succesfull the MAC used in the source address was authenticated. I = think there are other issues related to it being a MAC address that = should be thought through before it is added; especially if its not even = common practice today which it doesnt apear to be. [Joe] I think we are in agreement here. =20 =09 > If subject naming information is present only in the subject name > field of a server certificate, then the subject name field MUST > contain a CN RDN or Serial Number RDN. > [rmh] See my prior statements on serialNumber RDN. > > =09 ------_=_NextPart_001_01C755DB.DED494A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt=0A= =0A= =0A= =0A=
=0A=
in-line
=0A=

=0A=
=0A= From: Joseph Salowey (jsalowey) = [mailto:jsalowey@cisco.com]
Sent: Wed 2/21/2007 9:04 = AM
To: Ryan Hurst; Bernard Aboba; = emu@ietf.org
Subject: RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt

=0A=
=0A=
 
=0A=
=0A=
=0A=

>    If subject naming information = is present only in the subject name
>    field and = the peer identity represents a user, then the
> subject = name
>    field SHOULD contain an emailAddress = RDN.  If the peer identity
>    represents a = host or device the subject name field SHOULD contain = a
>    CN RDN or Serial Number RDN.
> [rmh] = If you say they can include a serialNumber (not Serial
> Number) = RDN then you have to specify processing symantics
> when more than = one are present, and discuss what sort of
> value is used here, = etc.
> [rmh] I suggest dropping the " or Serial Number RDN" = portion
> of this text, we can if appropriate work on a appendix = or
> other RFC that discusses these issues; I suspect the = right
> answer will be to reference the Permanent Identifier RFC = from
> the PKIX working group which already deals with these = problems.
>

[Joe] Would you not have to do the same with = email address or CN?  It
seems it would be possible for multiple = of these to be present.  There
should not be any semantics = associated with a serial number other than
it is an identifier.  = It should not be interpreted as a MAC address or
some other value = without additional knowledge outside this
specification.  I = agree that this would not be the place to consistently
find a MAC = address. I would prefer to keep Serial Number as a
possibility as it = is at least as relevant as the other fields.  I would
be fine = with the previous text I posted with a MAY.

=0A=

[rmh] Although your right that the fact that multiple = RDNs can be used to make up a DN universally other RDNs are = non-ambiguous while serialNumber conceptually is not, 

=0A=

[Joe] Can you expand upon this? Why is SerialNumber = different than other RDNs? 

=0A=

[rmh] Conceptually a serial number is a exact match to = a entity, for example no two tivos share the same serial number but they = could all share the same common name of Tivo Series 2.

=0A=

[rmh] In my case case there is a actor who also shares = the name Ryan Hurst (http://www.imdb.com/name/nm0= 403652/) but we both have unique ssns.

=0A=

[rmh] Since its CN is not intended to be non-ambiguous = its reasonable for me to have multiple CNs in a certificate all of = which are appropriate as a common name of me; for example I could have = one that is just Ryan, another that is Ryan Hurst, another that is Ryan = M Hurst.

=0A=

[rmh]  Since a serial number is a exact match, = what does it mean if you have multiple serial numbers?

=0A=

[rmh] As for the value, EAP is not 802.11 only = therefore a device id should not be a MAC, also a MAC has locally = administered and globally adminstered versions, you would probably want = to restrict the use to the globally issued ones, then there are the = privacy issues since the MAC is used as a source address a attacker can = presume if a EAP authentication is succesfull the MAC used in the source = address was authenticated. I think there are other issues related to it = being a MAC address that should be thought through before it is added; = especially if its not even common practice today which it doesnt apear = to be.

=0A=

[Joe]  I think we are in agreement here. =  

=0A=


>    If subject naming information is present = only in the subject name
>    field of a server = certificate, then the subject name field MUST
>    = contain a CN RDN or Serial Number RDN.
> [rmh] See my prior = statements on serialNumber = RDN.
>
>

------_=_NextPart_001_01C755DB.DED494A6-- --===============1614354262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1614354262==-- From emu-bounces@ietf.org Wed Feb 21 12:55:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvgO-0005bI-So; Wed, 21 Feb 2007 12:55:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvgO-0005b2-21 for emu@ietf.org; Wed, 21 Feb 2007 12:55:12 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvgM-00051R-MM for emu@ietf.org; Wed, 21 Feb 2007 12:55:12 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Feb 2007 09:55:06 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.25; Wed, 21 Feb 2007 09:55:06 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 21 Feb 2007 09:55:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 09:52:57 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622E@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdV4RGxJfuV1vgpQ6WUVkX2uDZ+tAAAA0Od References: From: Ryan Hurst To: Bernard Aboba , , X-OriginalArrivalTime: 21 Feb 2007 17:55:05.0595 (UTC) FILETIME=[6B15ECB0:01C755E1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1035117984==" Errors-To: emu-bounces@ietf.org --===============1035117984== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755E1.59205DA6" ------_=_NextPart_001_01C755E1.59205DA6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I started work on some but it will take me a few days to get to = finishing it, I sugest we leave it out here and include text in a = appendix to cover it. =20 Ryan ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Wed 2/21/2007 9:51 AM To: jsalowey@cisco.com; Ryan Hurst; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > [rmh] As for the value, EAP is not 802.11 only therefore a >device id should not be a MAC, also a MAC has locally administered and >globally adminstered versions, you would probably want to restrict the >use to the globally issued ones, then there are the privacy issues = since >the MAC is used as a source address a attacker can presume if a EAP >authentication is successful the MAC used in the source address was >authenticated. I think there are other issues related to it being a MAC >address that should be thought through before it is added; especially = if >its not even common practice today which it doesnt apear to be. > > [Joe] I think we are in agreement here. Use of the MAC address as an EAP-TLS identity is not yet common = practice. =20 Yet both IEEE 802.1AR and WiMAX documents talk about use of MAC = addresses in certificates (using different formats), so it could be used more widely = in the future. I agree that using a locally administered MAC address as an identity in EAP-TLS does not make sense. Do we have proposed text to deal with this issue? ------_=_NextPart_001_01C755E1.59205DA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt=0A= =0A= =0A= =0A=
=0A=
I started = work on some but it will take me a few days to get to finishing it, I = sugest we leave it out here and include text in a appendix to cover = it.
=0A=
 
=0A=
Ryan
=0A=

=0A=
=0A= From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]
Sent: Wed 2/21/2007 9:51 = AM
To: jsalowey@cisco.com; Ryan Hurst; = emu@ietf.org
Subject: RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt

=0A=
=0A=

>       [rmh] As for = the value, EAP is not 802.11 only therefore a
>device id should = not be a MAC, also a MAC has locally administered and
>globally = adminstered versions, you would probably want to restrict the
>use = to the globally issued ones, then there are the privacy issues = since
>the MAC is used as a source address a attacker can presume = if a EAP
>authentication is successful the MAC used in the source = address was
>authenticated. I think there are other issues related = to it being a MAC
>address that should be thought through before = it is added; especially if
>its not even common practice today = which it doesnt apear to = be.
>
>       [Joe]  I = think we are in agreement here.

Use of the MAC address as an = EAP-TLS identity is not yet common practice.  
Yet both = IEEE 802.1AR and WiMAX documents talk about use of MAC addresses = in
certificates (using different formats), so it could be used more = widely in
the future.

I agree that using a locally = administered MAC address as an identity in
EAP-TLS does not make = sense.

Do we have proposed text to deal with this = issue?


------_=_NextPart_001_01C755E1.59205DA6-- --===============1035117984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1035117984==-- From emu-bounces@ietf.org Wed Feb 21 12:57:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvi4-0005mt-Ke; Wed, 21 Feb 2007 12:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvi1-0005ml-Ra for emu@ietf.org; Wed, 21 Feb 2007 12:56:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvhz-0005Nh-HN for emu@ietf.org; Wed, 21 Feb 2007 12:56:53 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Feb 2007 09:56:52 -0800 X-IronPort-AV: i="4.14,202,1170662400"; d="scan'208"; a="466064425:sNHT47846660" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1LHuoG0024019; Wed, 21 Feb 2007 09:56:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1LHuoGk021145; Wed, 21 Feb 2007 09:56:50 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 09:56:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 09:56:49 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdV4QQrljUXBWRcQx6F9VeBEmZMsgAAGT+Q From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 21 Feb 2007 17:56:50.0769 (UTC) FILETIME=[A9C63410:01C755E1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1644; t=1172080611; x=1172944611; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=1e8YVakC1aZyd6RyczclSbo5euvuTBw/ViZaGJCsl58=; b=e1Nl3GVJoRC51DSIW55bE6/fxuwDH36RncZFlm6SzfQjNJlIZqE846C4CkiLgDUsEKrXXeta FCFqIeBPmxx7RakI98RS3Lq/CMFhHzq0oDHHVLdhiqE50LoAaBkeP3ps; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, February 21, 2007 9:52 AM > To: Joseph Salowey (jsalowey); Ryan.Hurst@microsoft.com; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > > [rmh] As for the value, EAP is not 802.11 only=20 > therefore a device id=20 > >should not be a MAC, also a MAC has locally administered and=20 > globally=20 > >adminstered versions, you would probably want to restrict the use to=20 > >the globally issued ones, then there are the privacy issues=20 > since the=20 > >MAC is used as a source address a attacker can presume if a EAP=20 > >authentication is successful the MAC used in the source address was=20 > >authenticated. I think there are other issues related to it=20 > being a MAC=20 > >address that should be thought through before it is added;=20 > especially=20 > >if its not even common practice today which it doesnt apear to be. > > > > [Joe] I think we are in agreement here. >=20 > Use of the MAC address as an EAP-TLS identity is not yet=20 > common practice. =20 > Yet both IEEE 802.1AR and WiMAX documents talk about use of=20 > MAC addresses in certificates (using different formats), so=20 > it could be used more widely in the future. >=20 [Joe] IEEE802.1AR is going down a different path then using MAC address in certificates. I don't know about WiMAX. =20 > I agree that using a locally administered MAC address as an=20 > identity in EAP-TLS does not make sense. >=20 > Do we have proposed text to deal with this issue? [Joe] What is the issue? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 21 12:58:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvjC-0005y6-8a; Wed, 21 Feb 2007 12:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvjA-0005y1-DT for emu@ietf.org; Wed, 21 Feb 2007 12:58:04 -0500 Received: from bay0-omc1-s23.bay0.hotmail.com ([65.54.246.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvj8-0005fx-4y for emu@ietf.org; Wed, 21 Feb 2007 12:58:04 -0500 Received: from hotmail.com ([207.46.8.98]) by bay0-omc1-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 21 Feb 2007 09:58:01 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Feb 2007 09:58:01 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 21 Feb 2007 17:57:57 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, Ryan.Hurst@microsoft.com, emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 09:57:57 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Feb 2007 17:58:01.0223 (UTC) FILETIME=[D3C4A170:01C755E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >[Joe] What is the issue? I'm not sure. That's why I asked about text :) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 21 13:03:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvoQ-0006kQ-IG; Wed, 21 Feb 2007 13:03:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvoP-0006kL-Ia for emu@ietf.org; Wed, 21 Feb 2007 13:03:29 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvoN-0007Hg-2T for emu@ietf.org; Wed, 21 Feb 2007 13:03:29 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Feb 2007 10:03:26 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Wed, 21 Feb 2007 10:03:25 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 21 Feb 2007 10:03:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 10:01:17 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdV4QQrljUXBWRcQx6F9VeBEmZMsgAAGT+QAAA36fs= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 21 Feb 2007 18:03:24.0916 (UTC) FILETIME=[94B44340:01C755E2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0103078377==" Errors-To: emu-bounces@ietf.org --===============0103078377== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755E2.8EA306C2" ------_=_NextPart_001_01C755E2.8EA306C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I beleive that 802.11AR still allows for the device ID to be a MAC = address, atleast the last version I read did although they have gone = from that being the ID to the ID being one that could be a MAC address. =20 I think the issue is the same one you have been calling out, if I have a = device where should the device identity go. =20 And to that end, if that identity is a MAC address what are the security = concerns. =20 Ryan ________________________________ From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wed 2/21/2007 9:56 AM To: Bernard Aboba; Ryan Hurst; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Wednesday, February 21, 2007 9:52 AM > To: Joseph Salowey (jsalowey); Ryan.Hurst@microsoft.com; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > [rmh] As for the value, EAP is not 802.11 only > therefore a device id > >should not be a MAC, also a MAC has locally administered and > globally > >adminstered versions, you would probably want to restrict the use to > >the globally issued ones, then there are the privacy issues > since the > >MAC is used as a source address a attacker can presume if a EAP > >authentication is successful the MAC used in the source address was > >authenticated. I think there are other issues related to it > being a MAC > >address that should be thought through before it is added; > especially > >if its not even common practice today which it doesnt apear to be. > > > > [Joe] I think we are in agreement here. > > Use of the MAC address as an EAP-TLS identity is not yet > common practice. =20 > Yet both IEEE 802.1AR and WiMAX documents talk about use of > MAC addresses in certificates (using different formats), so > it could be used more widely in the future. > [Joe] IEEE802.1AR is going down a different path then using MAC address in certificates. I don't know about WiMAX.=20 > I agree that using a locally administered MAC address as an > identity in EAP-TLS does not make sense. > > Do we have proposed text to deal with this issue? [Joe] What is the issue? ------_=_NextPart_001_01C755E2.8EA306C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt=0A= =0A= =0A= =0A=
=0A=
I beleive = that 802.11AR still allows for the device ID to be a MAC address, = atleast the last version I read did although they have gone from that = being the ID to the ID being one that could be a MAC = address.
=0A=
 
=0A=
I think the issue is the same = one you have been calling out, if I have a device where should the = device identity go.
=0A=
 
=0A=
And to that end, if that = identity is a MAC address what are the security concerns.
=0A=
 
=0A=
Ryan
=0A=

=0A=
=0A= From: Joseph Salowey (jsalowey) = [mailto:jsalowey@cisco.com]
Sent: Wed 2/21/2007 9:56 = AM
To: Bernard Aboba; Ryan Hurst; = emu@ietf.org
Subject: RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt

=0A=
=0A=



> -----Original Message-----
> From: = Bernard Aboba [mailto:bernard_aboba@hotmail.co= m]
> Sent: Wednesday, February 21, 2007 9:52 AM
> To: = Joseph Salowey (jsalowey); Ryan.Hurst@microsoft.com; = emu@ietf.org
> Subject: RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt
>
> = >     [rmh] As for the value, EAP is not 802.11 = only
> therefore a device id
> >should not be a MAC, also = a MAC has locally administered and
> globally
> = >adminstered versions, you would probably want to restrict the use = to
> >the globally issued ones, then there are the privacy = issues
> since the
> >MAC is used as a source address a = attacker can presume if a EAP
> >authentication is successful = the MAC used in the source address was
> >authenticated. I = think there are other issues related to it
> being a MAC
> = >address that should be thought through before it is added;
> = especially
> >if its not even common practice today which it = doesnt apear to be.
> >
> >     = [Joe]  I think we are in agreement here.
>
> Use of the = MAC address as an EAP-TLS identity is not yet
> common = practice.  
> Yet both IEEE 802.1AR and WiMAX documents = talk about use of
> MAC addresses in certificates (using different = formats), so
> it could be used more widely in the = future.
>
[Joe] IEEE802.1AR is going down a different path then = using MAC address
in certificates.  I don't know about = WiMAX. 

> I agree that using a locally administered MAC = address as an
> identity in EAP-TLS does not make = sense.
>
> Do we have proposed text to deal with this = issue?

[Joe] What is the issue?

------_=_NextPart_001_01C755E2.8EA306C2-- --===============0103078377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0103078377==-- From emu-bounces@ietf.org Wed Feb 21 13:13:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvyQ-0008MA-GC; Wed, 21 Feb 2007 13:13:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvdN-0004tk-Cm for emu@ietf.org; Wed, 21 Feb 2007 12:52:06 -0500 Received: from bay0-omc2-s8.bay0.hotmail.com ([65.54.246.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvdJ-0003pV-NL for emu@ietf.org; Wed, 21 Feb 2007 12:52:03 -0500 Received: from hotmail.com ([207.46.8.118]) by bay0-omc2-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 21 Feb 2007 09:52:01 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Feb 2007 09:52:00 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 21 Feb 2007 17:51:59 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, Ryan.Hurst@microsoft.com, emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 09:51:59 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Feb 2007 17:52:00.0906 (UTC) FILETIME=[FD009EA0:01C755E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > [rmh] As for the value, EAP is not 802.11 only therefore a >device id should not be a MAC, also a MAC has locally administered and >globally adminstered versions, you would probably want to restrict the >use to the globally issued ones, then there are the privacy issues since >the MAC is used as a source address a attacker can presume if a EAP >authentication is successful the MAC used in the source address was >authenticated. I think there are other issues related to it being a MAC >address that should be thought through before it is added; especially if >its not even common practice today which it doesnt apear to be. > > [Joe] I think we are in agreement here. Use of the MAC address as an EAP-TLS identity is not yet common practice. Yet both IEEE 802.1AR and WiMAX documents talk about use of MAC addresses in certificates (using different formats), so it could be used more widely in the future. I agree that using a locally administered MAC address as an identity in EAP-TLS does not make sense. Do we have proposed text to deal with this issue? _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Feb 21 15:11:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxoE-0002P0-2u; Wed, 21 Feb 2007 15:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxoC-0002Oa-68 for emu@ietf.org; Wed, 21 Feb 2007 15:11:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJxoA-0001m3-Fe for emu@ietf.org; Wed, 21 Feb 2007 15:11:24 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 21 Feb 2007 11:57:43 -0800 X-IronPort-AV: i="4.14,202,1170662400"; d="scan'208,217"; a="391840727:sNHT4666845784" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1LJvg6a015546; Wed, 21 Feb 2007 11:57:42 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1LJvUE6013804; Wed, 21 Feb 2007 11:57:40 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 11:57:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 11:57:35 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdV4QQrljUXBWRcQx6F9VeBEmZMsgAAGT+QAAA36fsAABreIA== From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 21 Feb 2007 19:57:38.0461 (UTC) FILETIME=[89BC3CD0:01C755F2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10012; t=1172087862; x=1172951862; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=f3dhQBS9juz5oVIOlnkKGqvwdo9qgCUqxeONioFnuxc=; b=Nh6aCWA+rFatl+wuyE5vGM0C9mY5wgjY3Fh3gWolPFQElJKJLBvb6GLmmsr0mpQSD4g2MW7H df0dbeRPdBNKQjff0cUUdjRXHOTnyO41w4wpUkobTp9KqRH712xw3hN1cyLy9WN/JeWK5fOi1w 37NYKSjr8Gn5FNY7pjWFoslQE=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1898526974==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1898526974== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755F2.89855E21" This is a multi-part message in MIME format. ------_=_NextPart_001_01C755F2.89855E21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In 802.11AR what comprises an identity is up to the manufacturer. They can put whatever they want in their as long as it is unique within their namespace. Right now it is unclear where the device identity will go. Currently, if the identity is placed in the subject name I don't think it will use the email address RDN. It is fairly common practice to use CN and there is some existence of serialNumber since, as you pointed out, CN may contain different less unique information. I don't know of any devices currently that place device identity in subjectAltName fields.=20 =20 Off hand there may be some privacy concerns with using MAC address (although this would probably be true of any "permanent" identifier). I don't think we want EAP-TLS to depend upon knowing about MAC addresses. The security implications of MAC addresses will vary with deployment scenarios. I think these are largely out of scope for EAP-TLS. =20 =20 Joe ________________________________ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Wednesday, February 21, 2007 10:01 AM To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =09 =09 I beleive that 802.11AR still allows for the device ID to be a MAC address, atleast the last version I read did although they have gone from that being the ID to the ID being one that could be a MAC address. =20 I think the issue is the same one you have been calling out, if I have a device where should the device identity go. =20 And to that end, if that identity is a MAC address what are the security concerns. =20 Ryan ________________________________ From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wed 2/21/2007 9:56 AM To: Bernard Aboba; Ryan Hurst; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =09 =09 =09 =09 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Wednesday, February 21, 2007 9:52 AM > To: Joseph Salowey (jsalowey); Ryan.Hurst@microsoft.com; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > [rmh] As for the value, EAP is not 802.11 only > therefore a device id > >should not be a MAC, also a MAC has locally administered and > globally > >adminstered versions, you would probably want to restrict the use to > >the globally issued ones, then there are the privacy issues > since the > >MAC is used as a source address a attacker can presume if a EAP > >authentication is successful the MAC used in the source address was > >authenticated. I think there are other issues related to it > being a MAC > >address that should be thought through before it is added; > especially > >if its not even common practice today which it doesnt apear to be. > > > > [Joe] I think we are in agreement here. > > Use of the MAC address as an EAP-TLS identity is not yet > common practice. =20 > Yet both IEEE 802.1AR and WiMAX documents talk about use of > MAC addresses in certificates (using different formats), so > it could be used more widely in the future. > [Joe] IEEE802.1AR is going down a different path then using MAC address in certificates. I don't know about WiMAX.=20 =09 > I agree that using a locally administered MAC address as an > identity in EAP-TLS does not make sense. > > Do we have proposed text to deal with this issue? =09 [Joe] What is the issue? =09 ------_=_NextPart_001_01C755F2.89855E21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt
In 802.11AR what comprises an identity is up to = the=20 manufacturer.  They can put whatever they want in their as long as = it is=20 unique within their namespace.  Right now it is unclear where the = device=20 identity will go.  Currently, if the identity is placed in the = subject=20 name  I don't think it will use the email address RDN.  It is = fairly=20 common practice to use CN and there is some existence of serialNumber = since, as=20 you pointed out, CN may contain different less unique=20 information.   I don't know of any devices currently that = place device=20 identity in subjectAltName fields.
 
Off hand there may be some privacy concerns = with using MAC=20 address (although this would probably be true of any "permanent"=20 identifier).  I don't think we want EAP-TLS to depend upon knowing = about=20 MAC addresses.  The security implications of MAC addresses will = vary with=20 deployment scenarios.  I think these are largely out of scope for=20 EAP-TLS. 
 
 Joe

From: Ryan Hurst=20 [mailto:Ryan.Hurst@microsoft.com]
Sent: Wednesday, February = 21,=20 2007 10:01 AM
To: Joseph Salowey (jsalowey); Bernard Aboba;=20 emu@ietf.org
Subject: RE: [Emu] RE:=20 draft-simon-emu-rfc2716bis-07.txt

I beleive = that 802.11AR=20 still allows for the device ID to be a MAC address, atleast the last = version I=20 read did although they have gone from that being the ID to the ID = being one=20 that could be a MAC address.
 
I think the issue is the = same one you=20 have been calling out, if I have a device where should the device = identity=20 go.
 
And to that end, if that = identity is a=20 MAC address what are the security concerns.
 
Ryan

From: Joseph Salowey (jsalowey)=20 [mailto:jsalowey@cisco.com]
Sent: Wed 2/21/2007 9:56=20 AM
To: Bernard Aboba; Ryan Hurst; = emu@ietf.org
Subject:=20 RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt



> -----Original Message-----
> = From: Bernard=20 Aboba [mailto:bernard_aboba@hotmail.co= m]
>=20 Sent: Wednesday, February 21, 2007 9:52 AM
> To: Joseph Salowey=20 (jsalowey); Ryan.Hurst@microsoft.com; emu@ietf.org
> Subject: = RE: [Emu]=20 RE: draft-simon-emu-rfc2716bis-07.txt
>
>=20 >     [rmh] As for the value, EAP is not 802.11 = only
> therefore a device id
> >should not be a MAC, = also a MAC=20 has locally administered and
> globally
> >adminstered=20 versions, you would probably want to restrict the use to
> = >the=20 globally issued ones, then there are the privacy issues
> since=20 the
> >MAC is used as a source address a attacker can presume = if a=20 EAP
> >authentication is successful the MAC used in the = source=20 address was
> >authenticated. I think there are other issues = related=20 to it
> being a MAC
> >address that should be thought = through=20 before it is added;
> especially
> >if its not even = common=20 practice today which it doesnt apear to be.
> >
>=20 >     [Joe]  I think we are in agreement=20 here.
>
> Use of the MAC address as an EAP-TLS identity is = not=20 yet
> common practice.  
> Yet both IEEE 802.1AR = and=20 WiMAX documents talk about use of
> MAC addresses in = certificates (using=20 different formats), so
> it could be used more widely in the=20 future.
>
[Joe] IEEE802.1AR is going down a different path = then using=20 MAC address
in certificates.  I don't know about=20 WiMAX. 

> I agree that using a locally administered MAC = address=20 as an
> identity in EAP-TLS does not make sense.
>
> = Do we=20 have proposed text to deal with this issue?

[Joe] What is the=20 issue?

------_=_NextPart_001_01C755F2.89855E21-- --===============1898526974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1898526974==-- From emu-bounces@ietf.org Wed Feb 21 15:18:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxup-0004h1-28; Wed, 21 Feb 2007 15:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxum-0004fe-UP for emu@ietf.org; Wed, 21 Feb 2007 15:18:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJxul-00038w-5z for emu@ietf.org; Wed, 21 Feb 2007 15:18:12 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 21 Feb 2007 12:02:48 -0800 X-IronPort-AV: i="4.14,202,1170662400"; d="scan'208,217"; a="391844224:sNHT4816149280" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1LK2lQt000308; Wed, 21 Feb 2007 12:02:47 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1LK2knT004182; Wed, 21 Feb 2007 12:02:47 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 12:02:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 12:02:43 -0800 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4NgABP+5qAAGcIyGgAAY6PwAABEifoAAPHCIA== From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 21 Feb 2007 20:02:47.0274 (UTC) FILETIME=[41CD5CA0:01C755F3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12591; t=1172088167; x=1172952167; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=VgUjNpNS/FTR8qSlSTdSRwmj8nCWkGOccl+lShq1Pig=; b=S+UWASxzUAy9LAB5PP/Wv0cBcQFJQ+LtHLYqxuAQQGMTA7HDC+Je9rhyKFofcfIwmvWsNR49 UMGW9iz6K7jlGGYExjtRW5JLqpwZcjccEi+Uw1ZTcxdit1Ix+to5Jjel; Authentication-Results: sj-dkim-8; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1992165898==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============1992165898== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C755F3.41A8E2C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C755F3.41A8E2C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 Sent: Wednesday, February 21, 2007 9:15 AM To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =09 =09 in-line ________________________________ From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wed 2/21/2007 9:04 AM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt =09 =09 =20 > If subject naming information is present only in the subject name > field and the peer identity represents a user, then the > subject name > field SHOULD contain an emailAddress RDN. If the peer identity > represents a host or device the subject name field SHOULD contain a > CN RDN or Serial Number RDN. > [rmh] If you say they can include a serialNumber (not Serial > Number) RDN then you have to specify processing symantics > when more than one are present, and discuss what sort of > value is used here, etc. > [rmh] I suggest dropping the " or Serial Number RDN" portion > of this text, we can if appropriate work on a appendix or > other RFC that discusses these issues; I suspect the right > answer will be to reference the Permanent Identifier RFC from > the PKIX working group which already deals with these problems. > =09 [Joe] Would you not have to do the same with email address or CN? It seems it would be possible for multiple of these to be present. There should not be any semantics associated with a serial number other than it is an identifier. It should not be interpreted as a MAC address or some other value without additional knowledge outside this specification. I agree that this would not be the place to consistently find a MAC address. I would prefer to keep Serial Number as a possibility as it is at least as relevant as the other fields. I would be fine with the previous text I posted with a MAY. =09 [rmh] Although your right that the fact that multiple RDNs can be used to make up a DN universally other RDNs are non-ambiguous while serialNumber conceptually is not,=20 [Joe] Can you expand upon this? Why is SerialNumber different than other RDNs?=20 [rmh] Conceptually a serial number is a exact match to a entity, for example no two tivos share the same serial number but they could all share the same common name of Tivo Series 2.=20 [Joe] OK.=20 [rmh] In my case case there is a actor who also shares the name Ryan Hurst (http://www.imdb.com/name/nm0403652/) but we both have unique ssns. [Joe] OK=20 [rmh] Since its CN is not intended to be non-ambiguous its reasonable for me to have multiple CNs in a certificate all of which are appropriate as a common name of me; for example I could have one that is just Ryan, another that is Ryan Hurst, another that is Ryan M Hurst. [Joe] A device could be composed of multiple parts (such as line cards) each with its own serial number. There can also be various formats and representations of a serial number. [rmh] Since a serial number is a exact match, what does it mean if you have multiple serial numbers?=20 [Joe] I don't see any more confusion over having multiple serial numbers than having multiples of any other attribute. =20 [rmh] As for the value, EAP is not 802.11 only therefore a device id should not be a MAC, also a MAC has locally administered and globally adminstered versions, you would probably want to restrict the use to the globally issued ones, then there are the privacy issues since the MAC is used as a source address a attacker can presume if a EAP authentication is succesfull the MAC used in the source address was authenticated. I think there are other issues related to it being a MAC address that should be thought through before it is added; especially if its not even common practice today which it doesnt apear to be. [Joe] I think we are in agreement here. =20 =09 > If subject naming information is present only in the subject name > field of a server certificate, then the subject name field MUST > contain a CN RDN or Serial Number RDN. > [rmh] See my prior statements on serialNumber RDN. > > =09 ------_=_NextPart_001_01C755F3.41A8E2C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: = draft-simon-emu-rfc2716bis-07.txt
 

From: Ryan Hurst=20 [mailto:Ryan.Hurst@microsoft.com]
Sent: Wednesday, February = 21,=20 2007 9:15 AM
To: Joseph Salowey (jsalowey); Bernard Aboba;=20 emu@ietf.org
Subject: RE: [Emu] RE:=20 draft-simon-emu-rfc2716bis-07.txt

in-line

From: Joseph Salowey (jsalowey)=20 [mailto:jsalowey@cisco.com]
Sent: Wed 2/21/2007 9:04=20 AM
To: Ryan Hurst; Bernard Aboba; = emu@ietf.org
Subject:=20 RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

 

>    If subject naming = information is=20 present only in the subject name
>    field and = the=20 peer identity represents a user, then the
> subject=20 name
>    field SHOULD contain an emailAddress=20 RDN.  If the peer identity
>    represents = a host=20 or device the subject name field SHOULD contain = a
>   =20 CN RDN or Serial Number RDN.
> [rmh] If you say they can = include a=20 serialNumber (not Serial
> Number) RDN then you have to = specify=20 processing symantics
> when more than one are present, and = discuss=20 what sort of
> value is used here, etc.
> [rmh] I = suggest=20 dropping the " or Serial Number RDN" portion
> of this text, = we can if=20 appropriate work on a appendix or
> other RFC that discusses = these=20 issues; I suspect the right
> answer will be to reference the=20 Permanent Identifier RFC from
> the PKIX working group which = already=20 deals with these problems.
>

[Joe] Would you not have = to do the=20 same with email address or CN?  It
seems it would be = possible for=20 multiple of these to be present.  There
should not be any = semantics=20 associated with a serial number other than
it is an = identifier.  It=20 should not be interpreted as a MAC address or
some other value = without=20 additional knowledge outside this
specification.  I agree = that this=20 would not be the place to consistently
find a MAC address. I = would prefer=20 to keep Serial Number as a
possibility as it is at least as = relevant as=20 the other fields.  I would
be fine with the previous text I = posted=20 with a MAY.

[rmh] Although your right that the fact that = multiple RDNs=20 can be used to make up a DN universally other RDNs are non-ambiguous = while=20 serialNumber conceptually is not, 

[Joe] Can you expand upon this? Why is = SerialNumber=20 different than other RDNs? 

[rmh] Conceptually a serial number is a exact = match to a=20 entity, for example no two tivos share the same serial number but = they could=20 all share the same common name of Tivo Series 2. 

[Joe] OK.

[rmh] In my case case there is a actor who also = shares the=20 name Ryan Hurst (http://www.imdb.com/name/nm0= 403652/)=20 but we both have unique ssns.

[Joe] OK 

 [rmh] Since its=20 CN is not intended to be non-ambiguous its reasonable for me to have = multiple CNs in a certificate all of which are appropriate as a = common=20 name of me; for example I could have one that is just Ryan, another = that is=20 Ryan Hurst, another that is Ryan M Hurst.

 [Joe] A device could be composed of multiple = parts (such=20 as line cards) each with its own serial number.  There can also = be=20 various formats and representations of a serial=20 number.

 [rmh] =20 Since a serial number is a exact match, what does it mean if you = have=20 multiple serial numbers? 

[Joe] I don't see any more confusion over = having multiple=20 serial numbers than having multiples of any other attribute.=20  

[rmh] As for the value, EAP is not 802.11 only = therefore a=20 device id should not be a MAC, also a MAC has locally administered = and=20 globally adminstered versions, you would probably want to restrict = the use=20 to the globally issued ones, then there are the privacy issues since = the MAC=20 is used as a source address a attacker can presume if a EAP = authentication=20 is succesfull the MAC used in the source address was authenticated. = I think=20 there are other issues related to it being a MAC address that should = be=20 thought through before it is added; especially if its not even = common=20 practice today which it doesnt apear to be.

[Joe]  I think we are in agreement here.=20  


>    If subject naming information is = present only=20 in the subject name
>    field of a server = certificate,=20 then the subject name field MUST
>    contain a = CN RDN=20 or Serial Number RDN.
> [rmh] See my prior statements on = serialNumber=20 = RDN.
>
>

= ------_=_NextPart_001_01C755F3.41A8E2C1-- --===============1992165898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1992165898==-- From emu-bounces@ietf.org Wed Feb 21 16:50:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzM6-0007bw-8V; Wed, 21 Feb 2007 16:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzM4-0007bj-U6 for emu@ietf.org; Wed, 21 Feb 2007 16:50:28 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzM1-0001Dn-J7 for emu@ietf.org; Wed, 21 Feb 2007 16:50:28 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Feb 2007 13:50:24 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.25; Wed, 21 Feb 2007 13:50:23 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 21 Feb 2007 13:50:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 13:49:36 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004385214@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdUtN2o+UAb5VBjS4SlN0ep+E6RhwAbH4NgABP+5qAAGcIyGgAAY6PwAABEifoAAPHCIAAIxGkA References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8001D7622C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 21 Feb 2007 21:50:22.0788 (UTC) FILETIME=[4996A040:01C75602] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0865718115==" Errors-To: emu-bounces@ietf.org --===============0865718115== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75602.2F20479D" ------_=_NextPart_001_01C75602.2F20479D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Joe] I don't see any more confusion over having multiple serial numbers than having multiples of any other attribute. =20 [rmh] The point I have been failing to make is that these other ids are not expected to match a explicit entity, they are really not much more than a friendly name therefore it's not as important if you don't specify the semantics of how to process them. =20 ------_=_NextPart_001_01C75602.2F20479D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

&n= bsp;[Joe] I don't see any more confusion over having multiple serial numbers than = having multiples of any other attribute.  

[rmh] The point I have been failing to make is that these other ids are not = expected to match a explicit entity, they are really not much more than a = friendly name therefore it’s not as important if you don’t specify the semantics of = how to process them.

 

------_=_NextPart_001_01C75602.2F20479D-- --===============0865718115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0865718115==-- From emu-bounces@ietf.org Thu Feb 22 00:43:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK6jh-0003wf-FB; Thu, 22 Feb 2007 00:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK6jf-0003v7-Pg for emu@ietf.org; Thu, 22 Feb 2007 00:43:19 -0500 Received: from bay0-omc3-s40.bay0.hotmail.com ([65.54.246.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK6je-0005UV-FD for emu@ietf.org; Thu, 22 Feb 2007 00:43:19 -0500 Received: from hotmail.com ([207.46.8.99]) by bay0-omc3-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 21 Feb 2007 21:43:18 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Feb 2007 21:43:17 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 22 Feb 2007 05:43:13 GMT X-Originating-IP: [24.16.66.58] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004385214@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Wed, 21 Feb 2007 21:43:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Feb 2007 05:43:17.0664 (UTC) FILETIME=[5A551A00:01C75644] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org [Joe] I don't see any more confusion over having multiple serial numbers than having multiples of any other attribute. Placing multiple identities into a peer certificate represents an assertion that the identities are equivalent. If they are not equivalent, then they should be placed into separate certificates. If the identities are equivalent, then you could put "joe.salowey@cisco.com" and "jsalowey@cisco.com" into a peer certificate, and the server would be free to pick one (e.g. the first one), and use that to obtain the authorizations, assuming that the peer proved possession of the private key. With a serial number or MAC address, I don't think this logic holds. Multiple serial numbers or MAC addresses are not equivalent. For example, the server might take the first MAC address as the peer identity, but then it might expect this to match the Called-Station-Id attribute, and it won't, because that MAC address was the second one. So the server may need to do something different, like check all of the potential identities. That implies that identities really aren't equivalent, and probably belong in separate certificates. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Feb 22 14:09:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJJP-0002tI-Pf; Thu, 22 Feb 2007 14:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJJP-0002tD-Gv for emu@ietf.org; Thu, 22 Feb 2007 14:09:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKJJO-0004VR-2e for emu@ietf.org; Thu, 22 Feb 2007 14:09:03 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2007 11:09:01 -0800 X-IronPort-AV: i="4.14,207,1170662400"; d="scan'208"; a="41677054:sNHT81368757" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1MJ9187000465; Thu, 22 Feb 2007 11:09:01 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1MJ91Uw004482; Thu, 22 Feb 2007 11:09:01 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 11:09:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Date: Thu, 22 Feb 2007 11:09:00 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt Thread-Index: AcdWRGhV25zvPePrRby6KKbPpV8L8gAairnQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 22 Feb 2007 19:09:01.0002 (UTC) FILETIME=[E93512A0:01C756B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2003; t=1172171341; x=1173035341; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20RE=3A=20draft-simon-emu-rfc2716bis-07.txt |Sender:=20; bh=7u9wKFPSDw+Yaz7n+KS23qBZrLTK/aDLaZ+EgfHmKwI=; b=U/PDC7w6+Ty1vDVtpZNynjktFfaiA3OtXMfNYVa7drzIY3dxsh6XFpWmfZ0IyKiTpbbcOjP/ 0ZEl5Ogrn8dRmFS5ZFw+sGs5jXkbtYqqPVD2S+j86eFapRddFkC/6pza; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, February 21, 2007 9:43 PM > To: emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt >=20 > [Joe] I don't see any more confusion over having multiple=20 > serial numbers than having multiples of any other attribute. >=20 > Placing multiple identities into a peer certificate=20 > represents an assertion that the identities are equivalent. =20 > If they are not equivalent, then they should be placed into=20 > separate certificates. If the identities are equivalent,=20 > then you could put "joe.salowey@cisco.com" and=20 > "jsalowey@cisco.com" into a peer certificate, and the server=20 > would be free to pick one (e.g. the first one), and use that=20 > to obtain the authorizations, assuming that the peer proved=20 > possession of the private key. >=20 [Joe] I don't see why this doesn't hold for serial numbers as well. > With a serial number or MAC address, I don't think this logic holds. =20 > Multiple serial numbers or MAC addresses are not equivalent. =20 > For example, the server might take the first MAC address as=20 > the peer identity, but then it might expect this to match the=20 > Called-Station-Id attribute, and it won't, because that MAC=20 > address was the second one. So the server may need to do=20 > something different, like check all of the potential=20 > identities. That implies that identities really aren't=20 > equivalent, and probably belong in separate certificates. >=20 [Joe] The same thing can happing with multiple CN or multiple email addresses. One of the values in the certificate may not match an authorization entry while another one may. Just to reiterate, I am not suggesting that serial number have MAC address semantics. =20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Feb 23 18:50:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkAu-0004xb-3B; Fri, 23 Feb 2007 18:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkAs-0004va-LP; Fri, 23 Feb 2007 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKkAs-0005GY-CF; Fri, 23 Feb 2007 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 513E4328F1; Fri, 23 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HKkAs-000242-5m; Fri, 23 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : The EAP TLS Authentication Protocol Author(s) : D. Simon, B. Aboba Filename : draft-simon-emu-rfc2716bis-08.txt Pages : 31 Date : 2007-2-23 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simon-emu-rfc2716bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-simon-emu-rfc2716bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-23155920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-23155920.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Mon Feb 26 09:01:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLgPX-0002Zc-2V; Mon, 26 Feb 2007 09:01:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLgPV-0002Xk-2N for emu@ietf.org; Mon, 26 Feb 2007 09:01:01 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLgPT-00059L-OR for emu@ietf.org; Mon, 26 Feb 2007 09:01:01 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1927459nfa for ; Mon, 26 Feb 2007 06:00:58 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=pP9MzLDptAcsLSdW6WP2ZzxybZhO/CQVaccLhDgZUfKa8Vr2Pns5+gL/FBXVRcPYYdSKg0vc0PFJ2ARVNlxe3q/1/fNVTO/5HsZbtMz8ypC6wpiw1QAFiQnGw8h1T2gXzwe74wDawvmesq4pFu5b+Wj3X+PmC9Lp9BnU5vVlWFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=jNw3CK/2QKkX203Lt2nkFO5Wv6wC05SZekdqV8Z0NPIX6HoA4Xc+JdAc+66GgaJ/79N/ifpZ2rtpqinAtDLLGY3N9azlsUaif+s3NtrL+HMrlG5H6UmR312exCm32PXio3/ojs06Ncoh/X3R9dsNck1xDKROYlUFzTiz61Hy4KU= Received: by 10.82.188.15 with SMTP id l15mr1681941buf.1172498458541; Mon, 26 Feb 2007 06:00:58 -0800 (PST) Received: from ?10.161.18.202? ( [212.23.126.8]) by mx.google.com with ESMTP id w5sm675635mue.2007.02.26.06.00.56; Mon, 26 Feb 2007 06:00:57 -0800 (PST) Message-ID: <45E2E822.1050901@tu-bs.de> Date: Mon, 26 Feb 2007 15:01:06 +0100 User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: emu@ietf.org, y0013790 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit From: Thomas Otto X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Emu] Diploma thesis about EAP and EAP methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Dear EMU Working Group, I would like to publish my diploma thesis "Extensible Network Access Authentication", which I wrote in year 2006 under guidance of Hannes Tschofenig of Siemens AG. The thesis is available at http://www-public.tu-bs.de:8080/~y0013790/thesis-otto-eapmethods.pdf It might serve as survey of EAP and EAP methods and as a snapshot of their development in mid 2006. In summary, the thesis deals with * EAP * EAP methods * selected applications of EAP and wants to give a comprehensive overview and analysis of them. With much interest I followed the discussions around EAP-GPSK, and I am already very excited of the design of the upcoming password-based EAP method. I'd be glad to get a feedback from you - and I hope this thesis can contribute to the work of the IETF and particularly the EMU Working Group. Best regards, Thomas PS. If you are aware of a challenging job position and think I could be a suitable candiate for applying to it, please don't hesistate to contact me !! My Email is t.otto@tu-bs.de or also thomas.g.otto@googlemail.com !! _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu