From emu-bounces@ietf.org Mon Jun 04 13:26:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGKT-000394-On; Mon, 04 Jun 2007 13:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGKS-00038y-Jt for emu@ietf.org; Mon, 04 Jun 2007 13:26:52 -0400 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 1HvGKR-0006Q3-9D for emu@ietf.org; Mon, 04 Jun 2007 13:26:52 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 04 Jun 2007 10:26:51 -0700 X-IronPort-AV: i="4.16,381,1175497200"; d="scan'208"; a="377054385:sNHT42346530" 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 l54HQoNA001907; Mon, 4 Jun 2007 10:26:50 -0700 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 l54HQotV012760; Mon, 4 Jun 2007 17:26:50 GMT 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); Mon, 4 Jun 2007 10:26:50 -0700 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: Mon, 4 Jun 2007 10:26:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Liaison statement from IEEE 802.11u on "EAP emergency method" Thread-Index: AcemzYoMZHyQoK3zTH2WNtnP7r4ZFg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 04 Jun 2007 17:26:50.0413 (UTC) FILETIME=[8939EDD0:01C7A6CD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=311; t=1180978010; x=1181842010; 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:=20Liaison=20statement=20from=20IEEE=20802.11u=20on=20=22EAP=20e mergency=20method=22 |Sender:=20; bh=/mqwRWobw35ySXHkmY7+7YxVGTXBfkd9EnpSPE9YvkM=; b=PnMSGzhkcq+9DDM0jwsmR4AvrKg2o0RaxOp60OUsyiAD0XyZhvmZ+XFmmHxoweLR2XSYMPj2 mOT1EBu/fe02NvkRIMY0EMVWQHQ+8UxTcQr21w1dMnRPAk91y6abn3J74pP0l3cdLFEy+U3Uut OTGUJFiUKC5Tx2bHKhs1kih7U=; 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: 08e48e05374109708c00c6208b534009 Cc: eap@frascone.com Subject: [Emu] Liaison statement from IEEE 802.11u on "EAP emergency method" 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 liaison statement from the IEEE 802.11u on "EAP emergency Method" is now available at https://datatracker.ietf.org/public/liaisons.cgi. =20 One of the documents on requirements appears to be missing on the liaison page (the requirements presentation). I will work on getting this updated.=20 Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 06 00:41:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvnLC-0003wh-IM; Wed, 06 Jun 2007 00:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvnLC-0003tm-5q for emu@ietf.org; Wed, 06 Jun 2007 00:41:50 -0400 Received: from bay0-omc2-s25.bay0.hotmail.com ([65.54.246.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvnLA-0005Yh-Rz for emu@ietf.org; Wed, 06 Jun 2007 00:41:50 -0400 Received: from BAY117-W15 ([207.46.8.50]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 5 Jun 2007 21:41:48 -0700 Message-ID: X-Originating-IP: [208.54.15.129] From: Bernard Aboba To: Date: Tue, 5 Jun 2007 21:41:48 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2007 04:41:48.0502 (UTC) FILETIME=[FE61A760:01C7A7F4] X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Emu] Issue: Validation of server certificates in Section 5.3 of RFC 2716bis 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="===============0885869461==" Errors-To: emu-bounces@ietf.org --===============0885869461== Content-Type: multipart/alternative; boundary="_f6f7769d-3d8d-4655-853d-30f8a14760ce_" --_f6f7769d-3d8d-4655-853d-30f8a14760ce_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was looking at Section 5.3 in RFC 2716bis, and I noticed that while RFC 3= 280 conformant path validation is recommended for EAP-TLS servers, there is= no such recommendation for EAP-TLS peers. This seems odd. For example, Se= ction 5.3 states: Since the EAP-TLS server is typically connected to the = Internet, it SHOULD support validating the peer certificate using RFC 328= 0 [RFC3280] conformant path validation, including the ability to retrie= ve intermediate certificates that may be necessary to validate the peer c= ertificate. For details, see [RFC3280] Section 4.2.2.1.There is no equivale= nt statement for EAP-TLS peers. I would propose the insert the following se= ntence in Section 5.3: The EAP-TLS peer SHOULD support validating the s= erver certificate using RFC 3280 [RFC3280] conformant path validation.= --_f6f7769d-3d8d-4655-853d-30f8a14760ce_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was looking at Section 5.3 in RFC 2716bis, and I noticed that while RFC 3= 280 conformant path validation is recommended for EAP-TLS servers, there is= no such recommendation for EAP-TLS peers.  This seems odd.

Fo= r example, Section 5.3 states:

   Since the EAP-TLS server= is typically connected to the Internet, it
   SHOULD support = validating the peer certificate using RFC 3280
   [RFC3280] co= nformant 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.

= There is no equivalent statement for EAP-TLS peers.

I would propose= the insert the following sentence in Section 5.3:

   The = EAP-TLS peer SHOULD support validating
   the server certifica= te using RFC 3280 [RFC3280] conformant path
   validation.
=
= --_f6f7769d-3d8d-4655-853d-30f8a14760ce_-- --===============0885869461== 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 --===============0885869461==-- From emu-bounces@ietf.org Wed Jun 06 00:45:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvnOt-0005rr-4G; Wed, 06 Jun 2007 00:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvnOr-0005op-HI for emu@ietf.org; Wed, 06 Jun 2007 00:45:37 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvnOr-0005pf-6V for emu@ietf.org; Wed, 06 Jun 2007 00:45:37 -0400 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.700.0; Tue, 5 Jun 2007 21:44:37 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.726.0; Tue, 5 Jun 2007 21:45:34 -0700 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.3959); Tue, 5 Jun 2007 21:45:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Issue: Validation of server certificates in Section 5.3 of RFC 2716bis Date: Tue, 5 Jun 2007 21:44:52 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004C9AB1E@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Validation of server certificates in Section 5.3 of RFC 2716bis Thread-Index: Acen9Qau39adaix7QHG3Fvbo2gCMEQAAGU0H References: From: Ryan Hurst To: Bernard Aboba , X-OriginalArrivalTime: 06 Jun 2007 04:45:33.0761 (UTC) FILETIME=[84A57310:01C7A7F5] 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="===============0748504956==" Errors-To: emu-bounces@ietf.org --===============0748504956== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A7F5.77D1A90C" ------_=_NextPart_001_01C7A7F5.77D1A90C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I noticed this recently too; I think thats a good addition. =20 Ryan ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Tue 6/5/2007 9:41 PM To: emu@ietf.org Subject: [Emu] Issue: Validation of server certificates in Section 5.3 = of RFC 2716bis I was looking at Section 5.3 in RFC 2716bis, and I noticed that while = RFC 3280 conformant path validation is recommended for EAP-TLS servers, = there is no such recommendation for EAP-TLS peers. This seems odd.=20 For example, Section 5.3 states: 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. There is no equivalent statement for EAP-TLS peers.=20 I would propose the insert the following sentence in Section 5.3: The EAP-TLS peer SHOULD support validating the server certificate using RFC 3280 [RFC3280] conformant path validation. ------_=_NextPart_001_01C7A7F5.77D1A90C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Yes, I = noticed this recently too; I think thats a good addition.
=0A=
 
=0A=
Ryan
=0A=

=0A=
=0A= From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]
Sent: Tue 6/5/2007 9:41 = PM
To: emu@ietf.org
Subject: [Emu] Issue: Validation = of server certificates in Section 5.3 of RFC 2716bis

=0A=
I was looking at Section 5.3 in RFC 2716bis, and I noticed that = while RFC 3280 conformant path validation is recommended for EAP-TLS = servers, there is no such recommendation for EAP-TLS peers.  This = seems odd.

For example, Section 5.3 states:

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

There is no equivalent = statement for EAP-TLS peers.

I would propose the insert the = following sentence in Section 5.3:

   The EAP-TLS peer = SHOULD support validating
   the server certificate using = RFC 3280 [RFC3280] conformant path
   = validation.

------_=_NextPart_001_01C7A7F5.77D1A90C-- --===============0748504956== 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 --===============0748504956==-- From emu-bounces@ietf.org Wed Jun 06 01:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvnha-0001jH-T6; Wed, 06 Jun 2007 01:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvnha-0001jB-0m for emu@ietf.org; Wed, 06 Jun 2007 01:04:58 -0400 Received: from bay0-omc2-s13.bay0.hotmail.com ([65.54.246.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvnhY-0001uC-My for emu@ietf.org; Wed, 06 Jun 2007 01:04:58 -0400 Received: from BAY117-W10 ([207.46.8.45]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 5 Jun 2007 22:04:56 -0700 Message-ID: X-Originating-IP: [208.54.15.129] From: Bernard Aboba To: Date: Tue, 5 Jun 2007 22:04:56 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2007 05:04:56.0364 (UTC) FILETIME=[399C96C0:01C7A7F8] X-Spam-Score: 4.5 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue 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="===============1316828525==" Errors-To: emu-bounces@ietf.org --===============1316828525== Content-Type: multipart/alternative; boundary="_7f085abf-e88d-4a0e-8757-be3248c6d6ca_" --_7f085abf-e88d-4a0e-8757-be3248c6d6ca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It has been pointed out that an EAP-TLS certificate can contain multiple su= bject or subjectAltName fields. To address this, I propose that we add the= following text to Section 5.2:It is possible for more than one subjectAltN= ame field to be presentin a peer or server certificate. Where more than on= e subjectAltNamefield is present in a certificate, EAP-TLS implementations = SHOULDexport all the subjectAltName fields within Peer-Ids orServer-Ids; al= l of the exported Peer-Ids and Server-Ids are considered valid. Simila= rly, if more than one subject field is present in a peer orserver certifica= te, and no subjectAltName field is present, thenEAP-TLS implementations SHO= ULD export all of the subject fieldswithin Peer-Ids and Server-Ids; all o= f the exported Peer-Ids and Server-Ids are considered valid.= --_7f085abf-e88d-4a0e-8757-be3248c6d6ca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It has been pointed out that an EAP-TLS certificate can contain multiple su= bject or subjectAltName fields. 

To address this, I propose th= at we add the following text to Section 5.2:

It is possible for more= than one subjectAltName field to be present
in a peer or server certifi= cate.  Where more than one subjectAltName
field is present in a cer= tificate, EAP-TLS implementations SHOULD
export all the subjectAltName f= ields within Peer-Ids or
Server-Ids; all of the exported Peer-Ids and&nb= sp;   
Server-Ids are considered valid. 

Si= milarly, if more than one subject field is present in a peer or
server c= ertificate, and no subjectAltName field is present, then
EAP-TLS impleme= ntations SHOULD export all of the subject fields
within Peer-Ids and Ser= ver-Ids;   all of the exported Peer-Ids and
Server-Ids are co= nsidered valid.
= --_7f085abf-e88d-4a0e-8757-be3248c6d6ca_-- --===============1316828525== 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 --===============1316828525==-- From emu-bounces@ietf.org Wed Jun 06 14:10:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvzy3-0005aQ-U9; Wed, 06 Jun 2007 14:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvzy3-0005Xr-3w for emu@ietf.org; Wed, 06 Jun 2007 14:10:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvzy1-0007Cg-M4 for emu@ietf.org; Wed, 06 Jun 2007 14:10:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2007 11:10:44 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="159957542:sNHT44435889" 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 l56IAi53001491; Wed, 6 Jun 2007 11:10:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l56IAitb001020; Wed, 6 Jun 2007 18:10:44 GMT 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, 6 Jun 2007 11:10:41 -0700 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] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Date: Wed, 6 Jun 2007 11:10:40 -0700 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004C9AB1E@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Thread-Index: Acen9Qau39adaix7QHG3Fvbo2gCMEQAAGU0HABwZnyA= From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 18:10:41.0432 (UTC) FILETIME=[FE431180:01C7A865] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1645; t=1181153444; x=1182017444; 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]=20Issue=3A=20Validation=20of=20server=20certifi cates=20in=20Section=205.3=20ofRFC=202716bis |Sender:=20; bh=8wGDZpRLju2LUfjdSLiOOAUZ45itvm8h+9zsAHTGl7Q=; b=h0O+jC4pnpvl7JwV5pTcZLRa1bWlL8VcmXUgV2xJzaX2SG9o5M7sTlpKnNGeNBIh0vtTmXoo +gvFQq0NseKyicJ3MGGMpm/osLMiN4GHQ/PZjGdJCt/sxYfjiKRI+pIGAe1HvUO1QC6rP1h8qk aWWLxK+Kj/F4GPHZOB4bgkf/E=; 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: 0ddefe323dd869ab027dbfff7eff0465 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 Looks fine to me. Any particular reason why we emphasize 4.2.2.1? Thanks, Joe > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Tuesday, June 05, 2007 9:45 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Issue: Validation of server certificates=20 > in Section 5.3 ofRFC 2716bis >=20 > Yes, I noticed this recently too; I think thats a good addition. > =20 > Ryan >=20 > ________________________________ >=20 > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tue 6/5/2007 9:41 PM > To: emu@ietf.org > Subject: [Emu] Issue: Validation of server certificates in=20 > Section 5.3 of RFC 2716bis >=20 >=20 > I was looking at Section 5.3 in RFC 2716bis, and I noticed=20 > that while RFC 3280 conformant path validation is recommended=20 > for EAP-TLS servers, there is no such recommendation for=20 > EAP-TLS peers. This seems odd.=20 >=20 > For example, Section 5.3 states: >=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 > There is no equivalent statement for EAP-TLS peers.=20 >=20 > I would propose the insert the following sentence in Section 5.3: >=20 > The EAP-TLS peer SHOULD support validating > the server certificate using RFC 3280 [RFC3280] conformant path > validation. >=20 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 06 15:33:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Fn-0000qZ-RM; Wed, 06 Jun 2007 15:33:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Fm-0000qT-Jf for emu@ietf.org; Wed, 06 Jun 2007 15:33:10 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hw1Fl-0004iw-6w for emu@ietf.org; Wed, 06 Jun 2007 15:33:10 -0400 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.700.0; Wed, 6 Jun 2007 12:32:04 -0700 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.726.0; Wed, 6 Jun 2007 12:32:49 -0700 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.3959); Wed, 6 Jun 2007 12:32:49 -0700 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] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Date: Wed, 6 Jun 2007 12:32:16 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80055BCF81@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Thread-Index: Acen9Qau39adaix7QHG3Fvbo2gCMEQAAGU0HABwZnyAAAkK4MA== References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004C9AB1E@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 19:32:49.0420 (UTC) FILETIME=[77925CC0:01C7A871] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 4.2.2.1 reference is in support of "including the ability to retrieve intermediate certificates that may be necessary to validate"; this is particularly important in cases where a server sends only its certificate, sends a incomplete chain or sends a incorrect chain but the right leaf. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, June 06, 2007 11:11 AM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Looks fine to me. Any particular reason why we emphasize 4.2.2.1? Thanks, Joe > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Tuesday, June 05, 2007 9:45 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Issue: Validation of server certificates=20 > in Section 5.3 ofRFC 2716bis >=20 > Yes, I noticed this recently too; I think thats a good addition. > =20 > Ryan >=20 > ________________________________ >=20 > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tue 6/5/2007 9:41 PM > To: emu@ietf.org > Subject: [Emu] Issue: Validation of server certificates in=20 > Section 5.3 of RFC 2716bis >=20 >=20 > I was looking at Section 5.3 in RFC 2716bis, and I noticed=20 > that while RFC 3280 conformant path validation is recommended=20 > for EAP-TLS servers, there is no such recommendation for=20 > EAP-TLS peers. This seems odd.=20 >=20 > For example, Section 5.3 states: >=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 > There is no equivalent statement for EAP-TLS peers.=20 >=20 > I would propose the insert the following sentence in Section 5.3: >=20 > The EAP-TLS peer SHOULD support validating > the server certificate using RFC 3280 [RFC3280] conformant path > validation. >=20 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 06 16:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1kX-0008VJ-Ox; Wed, 06 Jun 2007 16:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1kW-0008VD-8z for emu@ietf.org; Wed, 06 Jun 2007 16:04:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw1kU-0005wv-SX for emu@ietf.org; Wed, 06 Jun 2007 16:04:56 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2007 13:04:54 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="161324980:sNHT51631227" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l56K4sKX011423; Wed, 6 Jun 2007 13:04:54 -0700 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 l56K4sV1009303; Wed, 6 Jun 2007 20:04:54 GMT 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, 6 Jun 2007 13:04:54 -0700 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] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Date: Wed, 6 Jun 2007 13:04:54 -0700 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80055BCF81@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis Thread-Index: Acen9Qau39adaix7QHG3Fvbo2gCMEQAAGU0HABwZnyAAAkK4MAABwudg From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 20:04:54.0047 (UTC) FILETIME=[F2BD22F0:01C7A875] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2704; t=1181160294; x=1182024294; 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]=20Issue=3A=20Validation=20of=20server=20certifi cates=20in=20Section=205.3=20ofRFC=202716bis |Sender:=20; bh=MFVmxZz+kj9FEPWPmUxcfawrRbm4HUqBuI58BPdNKLE=; b=aoW1x+QVEiALzZPvK2bPr+h4XyBlqr8jQih3DET42tJDhGy2fiiRLqDaiwMLUmK/ScVXBvG6 ms0ovNDmuFl+Nbi0FZ2w3jE0uCl12W8VgrBX1Ylt7nSNXRPY7FvkM0qJ; 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: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Excellent!=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Wednesday, June 06, 2007 12:32 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Issue: Validation of server certificates=20 > in Section 5.3 ofRFC 2716bis >=20 > The 4.2.2.1 reference is in support of "including the ability=20 > to retrieve intermediate certificates that may be necessary=20 > to validate"; this is particularly important in cases where a=20 > server sends only its certificate, sends a incomplete chain=20 > or sends a incorrect chain but the right leaf. >=20 > Ryan > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, June 06, 2007 11:11 AM > To: Ryan Hurst; Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Issue: Validation of server certificates in Section > 5.3 ofRFC 2716bis >=20 > Looks fine to me. Any particular reason why we emphasize 4.2.2.1? >=20 > Thanks, >=20 > Joe >=20 > > -----Original Message----- > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > Sent: Tuesday, June 05, 2007 9:45 PM > > To: Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] Issue: Validation of server certificates=20 > in Section=20 > > 5.3 ofRFC 2716bis > >=20 > > Yes, I noticed this recently too; I think thats a good addition. > > =20 > > Ryan > >=20 > > ________________________________ > >=20 > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tue 6/5/2007 9:41 PM > > To: emu@ietf.org > > Subject: [Emu] Issue: Validation of server certificates in=20 > Section 5.3=20 > > of RFC 2716bis > >=20 > >=20 > > I was looking at Section 5.3 in RFC 2716bis, and I noticed=20 > that while=20 > > RFC 3280 conformant path validation is recommended for EAP-TLS=20 > > servers, there is no such recommendation for EAP-TLS peers. This=20 > > seems odd. > >=20 > > For example, Section 5.3 states: > >=20 > > Since the EAP-TLS server is typically connected to the=20 > 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=20 > > validate > > the peer certificate. For details, see [RFC3280] Section 4.2.2.1. > >=20 > > There is no equivalent statement for EAP-TLS peers.=20 > >=20 > > I would propose the insert the following sentence in Section 5.3: > >=20 > > The EAP-TLS peer SHOULD support validating > > the server certificate using RFC 3280 [RFC3280] conformant path > > validation. > >=20 > >=20 > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 06 17:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw2wR-0002IH-Iz; Wed, 06 Jun 2007 17:21:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw2wQ-0002IC-E0 for emu@ietf.org; Wed, 06 Jun 2007 17:21:18 -0400 Received: from bay0-omc2-s12.bay0.hotmail.com ([65.54.246.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw2wO-0007ZQ-4i for emu@ietf.org; Wed, 06 Jun 2007 17:21:18 -0400 Received: from BAY117-W15 ([207.46.8.50]) by bay0-omc2-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 6 Jun 2007 14:21:15 -0700 Message-ID: X-Originating-IP: [208.54.15.129] From: Bernard Aboba To: Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 14:21:15 -0700 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2007 21:21:15.0465 (UTC) FILETIME=[9D7A0B90:01C7A880] X-Spam-Score: 2.1 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Also, it has been pointed out that the purpose of the Peer-Id/Server-Id may= not be fully explained, so that the following sentence may also need to be= added to Section 5.2: =20 "Together the Peer-Id and Server-Id name the entities involved in deriving the MSK/EMSK. " ________________________________ > From: bernard_aboba@hotmail.com > To: emu@ietf.org > Date: Tue, 5 Jun 2007 22:04:56 -0700 > Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue >=20 > It has been pointed out that an EAP-TLS certificate can contain multiple = subject or subjectAltName fields. > To address this, I propose that we add the following text to Section 5.2: > It is possible for more than one subjectAltName field to be present > in a peer or server certificate. Where more than one subjectAltName > field is present in a certificate, EAP-TLS implementations SHOULD > export all the subjectAltName fields within Peer-Ids or > Server-Ids; all of the exported Peer-Ids and > Server-Ids are considered valid. > Similarly, if more than one subject field is present in a peer or > server certificate, and no subjectAltName field is present, then > EAP-TLS implementations SHOULD export all of the subject fields > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and > Server-Ids are considered valid. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 06 17:22:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw2xM-0004IG-Tw; Wed, 06 Jun 2007 17:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw2xL-0004Hu-Pn for emu@ietf.org; Wed, 06 Jun 2007 17:22:15 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw2xJ-0007hx-EQ for emu@ietf.org; Wed, 06 Jun 2007 17:22:15 -0400 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.700.0; Wed, 6 Jun 2007 14:21:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.726.0; Wed, 6 Jun 2007 14:22:12 -0700 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.3959); Wed, 6 Jun 2007 14:22:12 -0700 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] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 14:22:10 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80055BD0BD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Thread-Index: AceogKzG5clShKXYQSO9NNaKpapWNwAAA0Sg References: From: Ryan Hurst To: "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 21:22:12.0123 (UTC) FILETIME=[BF3F5EB0:01C7A880] 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 I think this is a good clarification. -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, June 06, 2007 2:21 PM To: emu@ietf.org Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Also, it has been pointed out that the purpose of the Peer-Id/Server-Id may not be fully explained, so that the following sentence may also need to be added to Section 5.2: =20 "Together the Peer-Id and Server-Id name the entities involved in deriving the MSK/EMSK. " ________________________________ > From: bernard_aboba@hotmail.com > To: emu@ietf.org > Date: Tue, 5 Jun 2007 22:04:56 -0700 > Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue >=20 > It has been pointed out that an EAP-TLS certificate can contain multiple subject or subjectAltName fields. > To address this, I propose that we add the following text to Section 5.2: > It is possible for more than one subjectAltName field to be present > in a peer or server certificate. Where more than one subjectAltName > field is present in a certificate, EAP-TLS implementations SHOULD > export all the subjectAltName fields within Peer-Ids or > Server-Ids; all of the exported Peer-Ids and > Server-Ids are considered valid. > Similarly, if more than one subject field is present in a peer or > server certificate, and no subjectAltName field is present, then > EAP-TLS implementations SHOULD export all of the subject fields > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and > Server-Ids are considered valid. _______________________________________________ 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 Jun 06 18:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4N2-00067c-KE; Wed, 06 Jun 2007 18:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4N1-00061X-Kz for emu@ietf.org; Wed, 06 Jun 2007 18:52:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4N0-000798-BD for emu@ietf.org; Wed, 06 Jun 2007 18:52:51 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2007 15:52:50 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="160091009:sNHT46698165" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l56Mqnp7032126; Wed, 6 Jun 2007 15:52:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l56MqNu3018542; Wed, 6 Jun 2007 22:52:49 GMT 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, 6 Jun 2007 15:52:48 -0700 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] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 15:52:48 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Thread-Index: Acen+D7UmjuYjQf0Qjiw9ClcNUv/VgAlGD8Q From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 22:52:48.0296 (UTC) FILETIME=[67758A80:01C7A88D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1807; t=1181170369; x=1182034369; 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]=20Proposed=20Resolution=20to=20multiple=20Peer- Id/Server-Id=20Issue |Sender:=20; bh=PS7hjta3CZsFcq+3TvMh5OEl1L9AkqLNWlUtFm1pzSU=; b=k1TTRVgxtbBZqOCFqvUlOLBqLn/R1MPoIhiHKlLOVKGUDNsMbH4SeIn4mvsZMzeKNq1koVvd QT3ziO4z+5C158DRQJbCVUSDAVOSUnL/2hdfiqOokr2EJP9Rl4jfBG2o; 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: 21c69d3cfc2dd19218717dbe1d974352 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 Bernard, I don't think a valid certificate can have multiple subject distinguished names. I think it would be more in line with RFC 3280 to treat the subject distinguished name as part of the valid name set if it is non-empty. =20 "It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to a non-empty subject distinguished name. EAP-TLS implementations SHOULD export a non-empty Subject distinguished name along with all the subjectAltName fields within Peer-Ids or Server-Ids; all of the exported Peer-Ids and Server-Ids are considered valid. " Joe=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, June 05, 2007 10:05 PM > To: emu@ietf.org > Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue >=20 > It has been pointed out that an EAP-TLS certificate can=20 > contain multiple subject or subjectAltName fields. =20 >=20 > To address this, I propose that we add the following text to=20 > Section 5.2: >=20 > It is possible for more than one subjectAltName field to be=20 > present in a peer or server certificate. Where more than one=20 > subjectAltName field is present in a certificate, EAP-TLS=20 > implementations SHOULD export all the subjectAltName fields=20 > within Peer-Ids or > Server-Ids; all of the exported Peer-Ids and =20 > Server-Ids are considered valid. =20 >=20 > Similarly, if more than one subject field is present in a=20 > peer or server certificate, and no subjectAltName field is=20 > present, then EAP-TLS implementations SHOULD export all of=20 > the subject fields > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and=20 > Server-Ids are considered valid. >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jun 06 18:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4Qa-0002FR-0d; Wed, 06 Jun 2007 18:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4QX-0002FM-Tp for emu@ietf.org; Wed, 06 Jun 2007 18:56:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4QW-00087E-I8 for emu@ietf.org; Wed, 06 Jun 2007 18:56:29 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2007 15:56:28 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="4438736:sNHT21454092" 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 l56MuRe8011650; Wed, 6 Jun 2007 15:56:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l56MuGtd021563; Wed, 6 Jun 2007 22:56:27 GMT 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, 6 Jun 2007 15:56:25 -0700 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] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 15:56:25 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Thread-Index: AceogKKWR985kFMESk2pTYJbJtKzUgADPiSw From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 22:56:25.0316 (UTC) FILETIME=[E8D02A40:01C7A88D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1953; t=1181170587; x=1182034587; 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]=20Proposed=20Resolution=20to=20multiple=20Peer- Id/Server-Id=20Issue |Sender:=20; bh=rcEphrtPpwroxbCKOGjoCrF3hfrekjPJmBmDkoVfU18=; b=cHV4aE53vrpdVzh3GyjaUMqxEn07OzInkMcPGoITKeecxlkKABMmfDJhjybYHYFi874FuQDr GBv9tGtGU8vOgGLdbnEiSaGwXs4NugTvRWQlbNRtF7GbF3MnQEAKjB/x; 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: 4d87d2aa806f79fed918a62e834505ca 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 believe this is accurate. Is there a particular ambiguity this is clearing up? Thanks, Joe=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, June 06, 2007 2:21 PM > To: emu@ietf.org > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id Issue >=20 >=20 > Also, it has been pointed out that the purpose of the=20 > Peer-Id/Server-Id may not be fully explained, so that the=20 > following sentence may also need to be added to Section 5.2: =20 >=20 > "Together the Peer-Id and Server-Id name the entities=20 > involved in deriving the MSK/EMSK. " >=20 >=20 >=20 > ________________________________ > > From: bernard_aboba@hotmail.com > > To: emu@ietf.org > > Date: Tue, 5 Jun 2007 22:04:56 -0700 > > Subject: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id Issue > >=20 > > It has been pointed out that an EAP-TLS certificate can=20 > contain multiple subject or subjectAltName fields. > > To address this, I propose that we add the following text=20 > to Section 5.2: > > It is possible for more than one subjectAltName field to be=20 > present in=20 > > a peer or server certificate. Where more than one subjectAltName=20 > > field is present in a certificate, EAP-TLS implementations SHOULD=20 > > export all the subjectAltName fields within Peer-Ids or Server-Ids;=20 > > all of the exported Peer-Ids and Server-Ids are considered valid. > > Similarly, if more than one subject field is present in a peer or=20 > > server certificate, and no subjectAltName field is present, then=20 > > EAP-TLS implementations SHOULD export all of the subject fields > > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and > > Server-Ids are considered valid. >=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 Jun 06 19:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4ka-000850-Hf; Wed, 06 Jun 2007 19:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4kY-00084v-RD for emu@ietf.org; Wed, 06 Jun 2007 19:17:11 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4kW-0004k4-FE for emu@ietf.org; Wed, 06 Jun 2007 19:17:10 -0400 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.700.0; Wed, 6 Jun 2007 16:16:07 -0700 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.726.0; Wed, 6 Jun 2007 16:17:07 -0700 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.3959); Wed, 6 Jun 2007 16:17:06 -0700 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] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 16:16:33 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800564519B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Thread-Index: Acen+D7UmjuYjQf0Qjiw9ClcNUv/VgAlGD8QAABb+pA= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , X-OriginalArrivalTime: 06 Jun 2007 23:17:06.0547 (UTC) FILETIME=[CCA4FC30:01C7A890] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Your right, there can be only one distinguished name. However there are also cases where there are more than one subjectAltName may be present with a empty DN also; I don't think mandating a DN is a good idea since 3280 doesn't do that. Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, June 06, 2007 3:53 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Hi Bernard, I don't think a valid certificate can have multiple subject distinguished names. I think it would be more in line with RFC 3280 to treat the subject distinguished name as part of the valid name set if it is non-empty. =20 "It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to a non-empty subject distinguished name. EAP-TLS implementations SHOULD export a non-empty Subject distinguished name along with all the subjectAltName fields within Peer-Ids or Server-Ids; all of the exported Peer-Ids and Server-Ids are considered valid. " Joe=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, June 05, 2007 10:05 PM > To: emu@ietf.org > Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue >=20 > It has been pointed out that an EAP-TLS certificate can=20 > contain multiple subject or subjectAltName fields. =20 >=20 > To address this, I propose that we add the following text to=20 > Section 5.2: >=20 > It is possible for more than one subjectAltName field to be=20 > present in a peer or server certificate. Where more than one=20 > subjectAltName field is present in a certificate, EAP-TLS=20 > implementations SHOULD export all the subjectAltName fields=20 > within Peer-Ids or > Server-Ids; all of the exported Peer-Ids and =20 > Server-Ids are considered valid. =20 >=20 > Similarly, if more than one subject field is present in a=20 > peer or server certificate, and no subjectAltName field is=20 > present, then EAP-TLS implementations SHOULD export all of=20 > the subject fields > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and=20 > Server-Ids are considered valid. >=20 >=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 Wed Jun 06 19:37:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw542-0004wc-2Y; Wed, 06 Jun 2007 19:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw541-0004wX-4U for emu@ietf.org; Wed, 06 Jun 2007 19:37:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw540-0000Fx-MM for emu@ietf.org; Wed, 06 Jun 2007 19:37:17 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2007 16:37:16 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="161394183:sNHT53750853" 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 l56NbGsi026691; Wed, 6 Jun 2007 16:37:16 -0700 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 l56Nat2O008967; Wed, 6 Jun 2007 23:37:16 GMT 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, 6 Jun 2007 16:37:07 -0700 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] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Wed, 6 Jun 2007 16:37:08 -0700 Message-ID: In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800564519B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Thread-Index: Acen+D7UmjuYjQf0Qjiw9ClcNUv/VgAlGD8QAABb+pAAASg4sA== From: "Joseph Salowey \(jsalowey\)" To: "Ryan Hurst" , "Bernard Aboba" , X-OriginalArrivalTime: 06 Jun 2007 23:37:07.0406 (UTC) FILETIME=[986986E0:01C7A893] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3473; t=1181173036; x=1182037036; 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]=20Proposed=20Resolution=20to=20multiple=20Peer- Id/Server-Id=20Issue |Sender:=20; bh=XA1FbCGfpSrR/w4gnX9Ld1k1VUQM3Q0Kq95Tey/tiCI=; b=dAdiY79Dyw2wqfoe3EoA1JH2zxBI4YUUj9yFx/aM1KomDrzdNrR+ixbVCX/ffFz8puMBmEg1 OklcYNJFMyfdO+7S9s0iVmC0/ip5+w+Zz2A3vNTPF0o9yjjfHn0mPG3U; 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: 386e0819b1192672467565a524848168 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 agree, my intent wasn't to mandate a DN, my text needs to be improved. Does this help? "It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids. If the Subject distinguished name is non-empty then it SHOULD be exported within the Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid. " =20 Thanks, Joe > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Wednesday, June 06, 2007 4:17 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id Issue >=20 > Your right, there can be only one distinguished name. >=20 > However there are also cases where there are more than one=20 > subjectAltName may be present with a empty DN also; I don't=20 > think mandating a DN is a good idea since 3280 doesn't do that. >=20 > Ryan >=20 >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, June 06, 2007 3:53 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id Issue >=20 > Hi Bernard, >=20 > I don't think a valid certificate can have multiple subject=20 > distinguished names. I think it would be more in line with=20 > RFC 3280 to treat the subject distinguished name as part of=20 > the valid name set if it is non-empty. =20 >=20 > "It is possible for more than one subjectAltName field to be=20 > present in a peer or server certificate in addition to a=20 > non-empty subject distinguished name. EAP-TLS=20 > implementations SHOULD export a non-empty Subject=20 > distinguished name along with all the subjectAltName fields=20 > within Peer-Ids or Server-Ids; all of the exported Peer-Ids=20 > and Server-Ids are considered valid. " >=20 > Joe=20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, June 05, 2007 10:05 PM > > To: emu@ietf.org > > Subject: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id Issue > >=20 > > It has been pointed out that an EAP-TLS certificate can contain=20 > > multiple subject or subjectAltName fields. > >=20 > > To address this, I propose that we add the following text=20 > to Section=20 > > 5.2: > >=20 > > It is possible for more than one subjectAltName field to be=20 > present in=20 > > a peer or server certificate. Where more than one subjectAltName=20 > > field is present in a certificate, EAP-TLS implementations SHOULD=20 > > export all the subjectAltName fields within Peer-Ids or > > Server-Ids; all of the exported Peer-Ids and =20 > > Server-Ids are considered valid. =20 > >=20 > > Similarly, if more than one subject field is present in a peer or=20 > > server certificate, and no subjectAltName field is present, then=20 > > EAP-TLS implementations SHOULD export all of the subject fields > > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and=20 > > Server-Ids are considered valid. > >=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 Thu Jun 07 10:40:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJ9p-0006SC-PU; Thu, 07 Jun 2007 10:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJ9o-0006S7-Pr for emu@ietf.org; Thu, 07 Jun 2007 10:40:12 -0400 Received: from bay0-omc2-s1.bay0.hotmail.com ([65.54.246.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJ9o-0008G0-Al for emu@ietf.org; Thu, 07 Jun 2007 10:40:12 -0400 Received: from BAY117-W16 ([207.46.8.51]) by bay0-omc2-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 07:40:11 -0700 Message-ID: X-Originating-IP: [24.16.66.58] From: Bernard Aboba To: , Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Thu, 7 Jun 2007 07:40:11 -0700 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 14:40:11.0791 (UTC) FILETIME=[C0D289F0:01C7A911] X-Spam-Score: 2.1 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: rmh@microsoft.com 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 RFC 3280 says: " In addition, legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name as an EmailAddress attribute. The attribute value for EmailAddress is of type IA5String to permit inclusion of the character '@', which is not part of the PrintableString character set. EmailAddress attribute values are not case sensitive (e.g., "fanfeedback@redsox.com" is the same as "FANFEEDBACK@REDSOX.COM"). Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted." Based on this, if the certificate is encoding an NAI as a name, then the su= bject alternative name field MUST be used. Simultaneous inclusion of the N= AI within an EmailAddress attribute in the subject distinguished name is de= precated, but permitted.=20 So in the case where an NAI is encoded in the subjectAltName field, the sub= ject DN would be a duplicate, no? =20 ---------------------------------------- > Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issu= e > Date: Wed, 6 Jun 2007 16:37:08 -0700 > From: jsalowey@cisco.com > To: Ryan.Hurst@microsoft.com; bernard_aboba@hotmail.com; emu@ietf.org > CC:=20 >=20 > I agree, my intent wasn't to mandate a DN, my text needs to be improved. >=20 >=20 > Does this help? >=20 > "It is possible for more than one subjectAltName field to be present in > a peer or server certificate in addition to an empty or non-empty > subject distinguished name. EAP-TLS implementations SHOULD export all > the subjectAltName fields within Peer-Ids or Server-Ids. If the Subject > distinguished name is non-empty then it SHOULD be exported within the > Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are > considered valid. " > =20 > Thanks, >=20 > Joe >=20 > > -----Original Message----- > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > > Sent: Wednesday, June 06, 2007 4:17 PM > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] Proposed Resolution to multiple=20 > > Peer-Id/Server-Id Issue > >=20 > > Your right, there can be only one distinguished name. > >=20 > > However there are also cases where there are more than one=20 > > subjectAltName may be present with a empty DN also; I don't=20 > > think mandating a DN is a good idea since 3280 doesn't do that. > >=20 > > Ryan > >=20 > >=20 > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Wednesday, June 06, 2007 3:53 PM > > To: Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] Proposed Resolution to multiple=20 > > Peer-Id/Server-Id Issue > >=20 > > Hi Bernard, > >=20 > > I don't think a valid certificate can have multiple subject=20 > > distinguished names. I think it would be more in line with=20 > > RFC 3280 to treat the subject distinguished name as part of=20 > > the valid name set if it is non-empty. =20 > >=20 > > "It is possible for more than one subjectAltName field to be=20 > > present in a peer or server certificate in addition to a=20 > > non-empty subject distinguished name. EAP-TLS=20 > > implementations SHOULD export a non-empty Subject=20 > > distinguished name along with all the subjectAltName fields=20 > > within Peer-Ids or Server-Ids; all of the exported Peer-Ids=20 > > and Server-Ids are considered valid. " > >=20 > > Joe=20 > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, June 05, 2007 10:05 PM > > > To: emu@ietf.org > > > Subject: [Emu] Proposed Resolution to multiple=20 > > Peer-Id/Server-Id Issue > > >=20 > > > It has been pointed out that an EAP-TLS certificate can contain=20 > > > multiple subject or subjectAltName fields. > > >=20 > > > To address this, I propose that we add the following text=20 > > to Section=20 > > > 5.2: > > >=20 > > > It is possible for more than one subjectAltName field to be=20 > > present in=20 > > > a peer or server certificate. Where more than one subjectAltName=20 > > > field is present in a certificate, EAP-TLS implementations SHOULD=20 > > > export all the subjectAltName fields within Peer-Ids or > > > Server-Ids; all of the exported Peer-Ids and =20 > > > Server-Ids are considered valid. =20 > > >=20 > > > Similarly, if more than one subject field is present in a peer or=20 > > > server certificate, and no subjectAltName field is present, then=20 > > > EAP-TLS implementations SHOULD export all of the subject fields > > > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and=20 > > > Server-Ids are considered valid. > > >=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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 07 10:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJNV-0005Cv-00; Thu, 07 Jun 2007 10:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJNT-0005Cq-EE for emu@ietf.org; Thu, 07 Jun 2007 10:54:19 -0400 Received: from bay0-omc2-s10.bay0.hotmail.com ([65.54.246.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJNS-0003Re-5t for emu@ietf.org; Thu, 07 Jun 2007 10:54:19 -0400 Received: from BAY117-W9 ([207.46.8.44]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 07:54:17 -0700 Message-ID: X-Originating-IP: [24.16.66.58] From: Bernard Aboba To: Date: Thu, 7 Jun 2007 07:54:17 -0700 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 14:54:17.0675 (UTC) FILETIME=[B90231B0:01C7A913] X-Spam-Score: 2.1 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates 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 RFC 3280 Section 4.1.2.6 says: Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. This leads me to believe that the statement below from Section 5.2 isn't qu= ite right:=20 "Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. " An RFC 3280-equivalent statement would be: "Conforming implementations generating new certificates with network access identifiers MUST use the rfc822Name in the subject alternative name field to describe such identities."= _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 07 11:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKHp-0004Zt-1p; Thu, 07 Jun 2007 11:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKHn-0004VX-SF for emu@ietf.org; Thu, 07 Jun 2007 11:52:31 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKHm-0007cl-5Y for emu@ietf.org; Thu, 07 Jun 2007 11:52:31 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 08:52:29 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="160542387:sNHT58479039" 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 l57FqTO5011387; Thu, 7 Jun 2007 08:52:29 -0700 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 l57FqG2I007742; Thu, 7 Jun 2007 15:52:29 GMT 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); Thu, 7 Jun 2007 08:52:26 -0700 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] Proposed Resolution to multiple Peer-Id/Server-Id Issue Date: Thu, 7 Jun 2007 08:52:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue Thread-Index: AcepEmjFfPCqrsvaSVeoauKtf7fk7AACRwJw From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2007 15:52:26.0895 (UTC) FILETIME=[D8BEE9F0:01C7A91B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6114; t=1181231549; x=1182095549; 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]=20Proposed=20Resolution=20to=20multiple=20Peer- Id/Server-Id=20Issue |Sender:=20; bh=crTYSj+mGO3whjzE7msK1L+2ysZT84XnUrCd4TG8b3E=; b=PmaT7+kjAFZmPavqUHIG8AKJPszTWSxHnqsJjiC05iYY3evnSGqnNTyt7+BpRbQ8fr0vFEDo xPgiyqBsJnCXKVfAXhoRWvarOQKONSJpADN9eHJgjfGF3NEG5FMX8qs/KkRPh48rCyp1i1dw+a CbM1Jezc6wojuIYkd1bAr40g0=; 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: e472ca43d56132790a46d9eefd95f0a5 Cc: rmh@microsoft.com 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: Thursday, June 07, 2007 7:40 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Cc: rmh@microsoft.com > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id Issue >=20 >=20 > RFC 3280 says: >=20 > " In addition, legacy implementations exist where an RFC 822 name is > embedded in the subject distinguished name as an EmailAddress > attribute. The attribute value for EmailAddress is of=20 > type IA5String > to permit inclusion of the character '@', which is not part of the > PrintableString character set. EmailAddress attribute=20 > values are not > case sensitive (e.g., "fanfeedback@redsox.com" is the same as > "FANFEEDBACK@REDSOX.COM"). >=20 > Conforming implementations generating new certificates with > electronic mail addresses MUST use the rfc822Name in the subject > alternative name field (section 4.2.1.7) to describe such=20 > identities. > Simultaneous inclusion of the EmailAddress attribute in the subject > distinguished name to support legacy implementations is deprecated > but permitted." >=20 > Based on this, if the certificate is encoding an NAI as a=20 > name, then the subject alternative name field MUST be used. =20 > Simultaneous inclusion of the NAI within an EmailAddress=20 > attribute in the subject distinguished name is deprecated,=20 > but permitted.=20 >=20 > So in the case where an NAI is encoded in the subjectAltName=20 > field, the subject DN would be a duplicate, no? =20 >=20 [Joe] No, the EmailAddress RDN may not be included in the Subject DN.=20 >=20 >=20 >=20 >=20 > ---------------------------------------- > > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id=20 > > Issue > > Date: Wed, 6 Jun 2007 16:37:08 -0700 > > From: jsalowey@cisco.com > > To: Ryan.Hurst@microsoft.com; bernard_aboba@hotmail.com;=20 > emu@ietf.org > > CC:=20 > >=20 > > I agree, my intent wasn't to mandate a DN, my text needs to=20 > be improved. > >=20 > >=20 > > Does this help? > >=20 > > "It is possible for more than one subjectAltName field to=20 > be present=20 > > in a peer or server certificate in addition to an empty or=20 > non-empty=20 > > subject distinguished name. EAP-TLS implementations SHOULD=20 > export all=20 > > the subjectAltName fields within Peer-Ids or Server-Ids. If the=20 > > Subject distinguished name is non-empty then it SHOULD be exported=20 > > within the Peer-Ids or Server-Ids. All of the exported=20 > Peer-Ids and=20 > > Server-Ids are considered valid. " > > =20 > > Thanks, > >=20 > > Joe > >=20 > > > -----Original Message----- > > > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] > > > Sent: Wednesday, June 06, 2007 4:17 PM > > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > > > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id=20 > > > Issue > > >=20 > > > Your right, there can be only one distinguished name. > > >=20 > > > However there are also cases where there are more than one=20 > > > subjectAltName may be present with a empty DN also; I don't think=20 > > > mandating a DN is a good idea since 3280 doesn't do that. > > >=20 > > > Ryan > > >=20 > > >=20 > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Wednesday, June 06, 2007 3:53 PM > > > To: Bernard Aboba; emu@ietf.org > > > Subject: RE: [Emu] Proposed Resolution to multiple=20 > Peer-Id/Server-Id=20 > > > Issue > > >=20 > > > Hi Bernard, > > >=20 > > > I don't think a valid certificate can have multiple subject=20 > > > distinguished names. I think it would be more in line=20 > with RFC 3280=20 > > > to treat the subject distinguished name as part of the valid name=20 > > > set if it is non-empty. > > >=20 > > > "It is possible for more than one subjectAltName field to=20 > be present=20 > > > in a peer or server certificate in addition to a=20 > non-empty subject=20 > > > distinguished name. EAP-TLS implementations SHOULD export a=20 > > > non-empty Subject distinguished name along with all the=20 > > > subjectAltName fields within Peer-Ids or Server-Ids; all of the=20 > > > exported Peer-Ids and Server-Ids are considered valid. " > > >=20 > > > Joe > > >=20 > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, June 05, 2007 10:05 PM > > > > To: emu@ietf.org > > > > Subject: [Emu] Proposed Resolution to multiple > > > Peer-Id/Server-Id Issue > > > >=20 > > > > It has been pointed out that an EAP-TLS certificate can contain=20 > > > > multiple subject or subjectAltName fields. > > > >=20 > > > > To address this, I propose that we add the following text > > > to Section > > > > 5.2: > > > >=20 > > > > It is possible for more than one subjectAltName field to be > > > present in > > > > a peer or server certificate. Where more than one=20 > subjectAltName=20 > > > > field is present in a certificate, EAP-TLS=20 > implementations SHOULD=20 > > > > export all the subjectAltName fields within Peer-Ids or > > > > Server-Ids; all of the exported Peer-Ids and =20 > > > > Server-Ids are considered valid. =20 > > > >=20 > > > > Similarly, if more than one subject field is present in=20 > a peer or=20 > > > > server certificate, and no subjectAltName field is=20 > present, then=20 > > > > EAP-TLS implementations SHOULD export all of the subject fields > > > > within Peer-Ids and Server-Ids; all of the exported=20 > Peer-Ids and=20 > > > > Server-Ids are considered valid. > > > >=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 From emu-bounces@ietf.org Thu Jun 07 11:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKN0-0000WY-51; Thu, 07 Jun 2007 11:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKMz-0000Uz-CS for emu@ietf.org; Thu, 07 Jun 2007 11:57:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKMy-0001ew-1T for emu@ietf.org; Thu, 07 Jun 2007 11:57:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2007 08:57:51 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="161526060:sNHT51361938" 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 l57FvpJ1022857; Thu, 7 Jun 2007 08:57:51 -0700 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 l57FvnaI025965; Thu, 7 Jun 2007 15:57:51 GMT 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); Thu, 7 Jun 2007 08:57:48 -0700 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] Issue: Encoding of NAIs within EAP-TLS certificates Date: Thu, 7 Jun 2007 08:57:49 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Thread-Index: AcepE70W/oA/w6dPR6uzbPlXu8czzwACDQSg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2007 15:57:48.0883 (UTC) FILETIME=[98AA6230:01C7A91C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1636; t=1181231871; x=1182095871; 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]=20Issue=3A=20Encoding=20of=20NAIs=20within=20EA P-TLS=20certificates |Sender:=20; bh=aZXsSnf/lg4Ss3VDB41lb5ON2TBh9p6rEXihuPwHfts=; b=IS2kQMSbxZQDiS2hMZPr2X9PNIZe8CrWxbxuVSgcOlSSFDhLy1ABzpOYc6WYY3ep8FH0wH+U KBf3ct8zwhCPb108/jE3dTSaNkv+/ZWUoi+eOeVaJRbRdGmshmC5tp3Q; 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: 8b30eb7682a596edff707698f4a80f7d 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 Not all identities are an RFC822 Name so using an RFC822 name is not always appropriate. If you are going to include an RFC822 name in the certificate then it should be in the RFC822 SubjecAltName. The Subject distinguished name may include other name elements. > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, June 07, 2007 7:54 AM > To: emu@ietf.org > Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates >=20 >=20 > RFC 3280 Section 4.1.2.6 says: >=20 > Conforming implementations generating new certificates with > electronic mail addresses MUST use the rfc822Name in the subject > alternative name field (section 4.2.1.7) to describe such=20 > identities. > Simultaneous inclusion of the EmailAddress attribute in the subject > distinguished name to support legacy implementations is deprecated > but permitted. >=20 > This leads me to believe that the statement below from=20 > Section 5.2 isn't quite right:=20 >=20 > "Although the use of the subject name field is existing=20 > practice, its use in EAP-TLS is deprecated and Certification=20 > Authorities are encouraged to use the subjectAltName field instead. " >=20 > An RFC 3280-equivalent statement would be: >=20 > "Conforming implementations generating new certificates with=20 > network access identifiers MUST use the rfc822Name in the=20 > subject alternative name field to describe such identities." > _______________________________________________ > 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 Thu Jun 07 13:48:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM5Z-0001nI-NP; Thu, 07 Jun 2007 13:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM5Y-0001nC-Qh for emu@ietf.org; Thu, 07 Jun 2007 13:48:00 -0400 Received: from bay0-omc2-s2.bay0.hotmail.com ([65.54.246.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwM5Y-0002mY-Dh for emu@ietf.org; Thu, 07 Jun 2007 13:48:00 -0400 Received: from BAY117-W20 ([207.46.8.55]) by bay0-omc2-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 10:48:00 -0700 Message-ID: X-Originating-IP: [131.107.0.77] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Thu, 7 Jun 2007 10:47:59 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 17:48:00.0027 (UTC) FILETIME=[FD36E6B0:01C7A92B] X-Spam-Score: 2.6 (++) 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="===============1087368687==" Errors-To: emu-bounces@ietf.org --===============1087368687== Content-Type: multipart/alternative; boundary="_5cca9107-b8a7-4056-bea5-9d1936b5261e_" --_5cca9107-b8a7-4056-bea5-9d1936b5261e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right. The RFC 3280 statement only applies to RFC 822 names. That's why I= think that the text should focus on those names. > Subject: RE: [Emu] Issu= e: Encoding of NAIs within EAP-TLS certificates> Date: Thu, 7 Jun 2007 08:5= 7:49 -0700> From: jsalowey@cisco.com> To: bernard_aboba@hotmail.com; emu@ie= tf.org> > Not all identities are an RFC822 Name so using an RFC822 name is = not> always appropriate. If you are going to include an RFC822 name in the>= certificate then it should be in the RFC822 SubjecAltName. The Subject> di= stinguished name may include other name elements.> > > -----Original Messag= e-----> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: = Thursday, June 07, 2007 7:54 AM> > To: emu@ietf.org> > Subject: [Emu] Issue= : Encoding of NAIs within EAP-TLS certificates> > > > > > RFC 3280 Section = 4.1.2.6 says:> > > > Conforming implementations generating new certificates= with> > electronic mail addresses MUST use the rfc822Name in the subject> = > alternative name field (section 4.2.1.7) to describe such > > identities.= > > Simultaneous inclusion of the EmailAddress attribute in the subject> > = distinguished name to support legacy implementations is deprecated> > but p= ermitted.> > > > This leads me to believe that the statement below from > >= Section 5.2 isn't quite right: > > > > "Although the use of the subject na= me field is existing > > practice, its use in EAP-TLS is deprecated and Cer= tification > > Authorities are encouraged to use the subjectAltName field i= nstead. "> > > > An RFC 3280-equivalent statement would be:> > > > "Conform= ing implementations generating new certificates with > > network access ide= ntifiers MUST use the rfc822Name in the > > subject alternative name field = to describe such identities."> > __________________________________________= _____> > Emu mailing list> > Emu@ietf.org> > https://www1.ietf.org/mailman/= listinfo/emu> > = --_5cca9107-b8a7-4056-bea5-9d1936b5261e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right.  The RFC 3280 statement only applies to RFC 822 names.  Th= at's why I think that the text should focus on those names.

> Su= bject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
>= ; Date: Thu, 7 Jun 2007 08:57:49 -0700
> From: jsalowey@cisco.com
= > To: bernard_aboba@hotmail.com; emu@ietf.org
>
> Not all i= dentities are an RFC822 Name so using an RFC822 name is not
> always = appropriate. If you are going to include an RFC822 name in the
> cert= ificate then it should be in the RFC822 SubjecAltName. The Subject
> = distinguished name may include other name elements.
>
> > -= ----Original Message-----
> > From: Bernard Aboba [mailto:bernard_= aboba@hotmail.com]
> > Sent: Thursday, June 07, 2007 7:54 AM
&= gt; > To: emu@ietf.org
> > Subject: [Emu] Issue: Encoding of NA= Is within EAP-TLS certificates
> >
> >
> > RFC= 3280 Section 4.1.2.6 says:
> >
> > Conforming implement= ations generating new certificates with
> > electronic mail addres= ses MUST use the rfc822Name in the subject
> > alternative name fi= eld (section 4.2.1.7) to describe such
> > identities.
> &g= t; Simultaneous inclusion of the EmailAddress attribute in the subject
&= gt; > distinguished name to support legacy implementations is deprecated=
> > but permitted.
> >
> > This leads me to be= lieve that the statement below from
> > Section 5.2 isn't quite r= ight:
> >
> > "Although the use of the subject name fie= ld is existing
> > practice, its use in EAP-TLS is deprecated and= Certification
> > Authorities are encouraged to use the subjectA= ltName field instead. "
> >
> > An RFC 3280-equivalent s= tatement would be:
> >
> > "Conforming implementations g= enerating new certificates with
> > network access identifiers MU= ST use the rfc822Name in the
> > subject alternative name field t= o describe such identities."
> > _________________________________= ______________
> > Emu mailing list
> > Emu@ietf.org
&= gt; > https://www1.ietf.org/mailman/listinfo/emu
> >
= --_5cca9107-b8a7-4056-bea5-9d1936b5261e_-- --===============1087368687== 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 --===============1087368687==-- From emu-bounces@ietf.org Thu Jun 07 15:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNIZ-0006H3-4W; Thu, 07 Jun 2007 15:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNIY-0006Gr-8m for emu@ietf.org; Thu, 07 Jun 2007 15:05:30 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwNIR-00068b-Az for emu@ietf.org; Thu, 07 Jun 2007 15:05:30 -0400 Received: from BAY117-W20 ([207.46.8.55]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 12:05:23 -0700 Message-ID: X-Originating-IP: [131.107.0.77] From: Bernard Aboba To: Date: Thu, 7 Jun 2007 12:05:22 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 19:05:23.0183 (UTC) FILETIME=[CCC047F0:01C7A936] X-Spam-Score: 2.2 (++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [Emu] Issue with RFC 2716bis key generation 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="===============0568728896==" Errors-To: emu-bounces@ietf.org --===============0568728896== Content-Type: multipart/alternative; boundary="_06005a11-eee3-4274-b892-a9bd2ce6e0b3_" --_06005a11-eee3-4274-b892-a9bd2ce6e0b3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It has been pointed out by Paul Funk that the key generation formula specif= ied in RFC 2716bis could cause backward compatibility problems once TLS v1.= 2 is introduced.=20 =20 The formula in -09 is as follows: =20 MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", = client.random || server.random) EMSK(0,63) =3D second 64 octets of: = TLS-PRF-128(TMS, "client EAP encryption", = client.random || server.random) IV(0,63) =3D TLS-PRF-64("", "client= EAP encryption", client.random || server.random) The issue here is that RFC 2716 Section 3.5 specifies a different approach: =20 MSK(0,63) =3D first 64 octets of: TLS-PRF-128(TMS, "c= lient EAP encryption", client.random || server.random) = EMSK(0,63) =3D second 64 octets of: TLS-PRF-128(TMS, "c= lient EAP encryption", client.random || server.random) = IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", = client.random || server.random) =20 With the current TLS PRF, these two approaches are identical. However, thi= s is not necessarily true for all PRFs that could conceivably be negotiated= within TLS v1.2. =20 =20 The text from RFC 2716 Section 3.5 reads as follows: =20 Since the normal TLS keys are used in the handshake, and therefore sho= uld not be used in a different context, new encryption keys must be deriv= ed from the TLS master secret for use with PPP encryption. For both peer = and EAP server, the derivation proceeds as follows: given the master secr= et negotiated by the TLS handshake, the pseudorandom function (PRF) defin= ed in the specification for the version of TLS in use, and the value rand= om defined as the concatenation of the handshake message fields client_he= llo.random and server_hello.random (in that order), the value PRF(master = secret, "client EAP encryption", random) is computed up to 128 bytes, and= the value PRF("", "client EAP encryption", random) is computed up to 64 = bytes (where "" is an empty string). The peer encryption key (the one = used for encrypting data from peer to EAP server) is obtained by truncati= ng to the correct length the first 32 bytes of the first PRF of these two= output strings. The EAP server encryption key (the one used for encrypt= ing data from EAP server to peer), if different from the client encryptio= n key, is obtained by truncating to the correct length the second 32 byte= s of this same PRF output string. The client authentication key (the one= used for computing MACs for messages from peer to EAP server), if used, = is obtained by truncating to the correct length the third 32 bytes of thi= s same PRF output string. The EAP server authentication key (the one use= d for computing MACs for messages from EAP server to peer), if used, and = if different from the peer authentication key, is obtained by truncating = to the correct length the fourth 32 bytes of this same PRF output strin= g. The peer initialization vector (IV), used for messages from peer to E= AP server if a block cipher has been specified, is obtained by truncating= to the cipher's block size the first 32 bytes of the second PRF output s= tring mentioned above. Finally, the server initialization vector (IV), u= sed for messages from peer to EAP server if a block cipher has been speci= fied, is obtained by truncating to the cipher's block size the second 32 = bytes of this second PRF output.= --_06005a11-eee3-4274-b892-a9bd2ce6e0b3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It has been pointed out by Paul Funk that the key generation formula s= pecified in RFC 2716bis could cause backward compatibility problems once TL= S v1.2 is introduced.
 
The formula in -09 is as follows:
 
MSK(0,63)    =3D TLS-PRF-64(TMS, "client EAP encryption",            &n= bsp;       client.random || server.random)   EMSK(0,63)   =3D second 64 octets of:
 &nbs= p;            &= nbsp;   TLS-PRF-128(TMS, "client EAP encryption",
  =             &nb= sp;     client.random || server.random)
  = IV(0,63)     =3D TLS-PRF-64("", "client EAP encryption= ",
           &nb= sp;        client.random || server.rando= m)

The issue here is that RFC 2716 Section 3.5 specifies a different approach:=
 
   MSK(0,63)   =3D first 64 octets of:
 &n= bsp;            = ;    TLS-PRF-128(TMS, "client EAP encryption",
 &nbs= p;            &= nbsp;     client.random || server.random)
 &nbs= p; EMSK(0,63)   =3D second 64 octets of:
   &nb= sp;            =   TLS-PRF-128(TMS, "client EAP encryption",
    = ;            &n= bsp;   client.random || server.random)
   IV(0,63)&n= bsp;    =3D TLS-PRF-64("", "client EAP encryption",
 = ;            &n= bsp;      client.random || server.random)
 
With the current TLS PRF, these two approaches are identical.  However= , this is not necessarily true for all PRFs that could conceivably be negot= iated within TLS v1.2. 
 
The text from RFC 2716 Section 3.5 reads as follows:
 
   Since the normal TLS keys are used in the handshake, and there= fore
   should not be used in a different context, new encrypt= ion keys must
   be derived from the TLS master secret for use= with PPP encryption.
   For both peer and EAP server, the der= ivation proceeds as follows:
   given the master secret negoti= ated by the TLS handshake, the
   pseudorandom function (PRF) = defined in the specification for the
   version of TLS in use,= and the value random defined as the
   concatenation of the h= andshake message fields client_hello.random and
   server_hell= o.random (in that order), the value PRF(master secret,
   "cli= ent EAP encryption", random) is computed up to 128 bytes, and the
 =   value PRF("", "client EAP encryption", random) is computed up to 64<= BR>   bytes (where "" is an empty string).  The peer encrypt= ion key (the
   one used for encrypting data from peer to EAP = server) is obtained by
   truncating to the correct length the= first 32 bytes of the first PRF
   of these two output string= s.  The EAP server encryption key (the one
   used for en= crypting data from EAP server to peer), if different from
   t= he client encryption key, is obtained by truncating to the correct
 = ;  length the second 32 bytes of this same PRF output string.  Th= e
   client authentication key (the one used for computing MAC= s for
   messages from peer to EAP server), if used, is obtain= ed by truncating
   to the correct length the third 32 bytes o= f this same PRF output
   string.  The EAP server authent= ication key (the one used for
   computing MACs for messages f= rom EAP server to peer), if used, and if
   different from the= peer authentication key, is obtained by truncating
   to the = correct length the fourth 32 bytes of this same PRF output
   = string.  The peer initialization vector (IV), used for messages from   peer to EAP server if a block cipher has been specified, is = obtained
   by truncating to the cipher's block size the first= 32 bytes of the
   second PRF output string mentioned above.&= nbsp; Finally, the server
   initialization vector (IV), used = for messages from peer to EAP server
   if a block cipher has = been specified, is obtained by truncating to
   the cipher's b= lock size the second 32 bytes of this second PRF
   output.
= --_06005a11-eee3-4274-b892-a9bd2ce6e0b3_-- --===============0568728896== 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 --===============0568728896==-- From emu-bounces@ietf.org Thu Jun 07 17:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPNV-0005RU-59; Thu, 07 Jun 2007 17:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPNT-0005Ov-3s for emu@ietf.org; Thu, 07 Jun 2007 17:18:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwP83-0000nl-4m for emu@ietf.org; Thu, 07 Jun 2007 17:02:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2007 14:02:46 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208,217"; a="161580625:sNHT103671612" 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 l57L2kBw001224; Thu, 7 Jun 2007 14:02:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57L2h28022422; Thu, 7 Jun 2007 21:02:46 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 17:02:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 17:02:40 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B70490D520@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue with RFC 2716bis key generation Thread-Index: AcepNtYpNIbs6kq+T7WxMmXH1OSlbgAD6fgg References: From: "Hao Zhou \(hzhou\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2007 21:02:42.0064 (UTC) FILETIME=[30404900:01C7A947] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11189; t=1181250166; x=1182114166; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Issue=20with=20RFC=202716bis=20key=20generati on |Sender:=20; bh=N4iaQwYGJY0C42NvhIkuBwH8QnaZ6hwfuxKkxKI5HN8=; b=fkrGe0dj/Mr937rkSOTIkr4b9ACJWV+k535N9m3p5VUC1+j5TFtbFNrJ/Fgsae+z7QW+Vjla +EL1fx+I1M2TjeMcvgosFObd1nh4fxa7ysjryyBBpmMmAaosL9AIufZZ; Authentication-Results: sj-dkim-3; header.From=hzhou@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 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="===============2098499662==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============2098499662== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A947.30174FBD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A947.30174FBD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there any reason not to use the approach in RFC2716Bis? This guarantees backward compatibility and require less computation. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Thursday, June 07, 2007 3:05 PM To: emu@ietf.org Subject: [Emu] Issue with RFC 2716bis key generation =09 =09 It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced.=20 =20 The formula in -09 is as follows: =20 MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", client.random || server.random) EMSK(0,63) =3D second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", client.random || server.random) =09 The issue here is that RFC 2716 Section 3.5 specifies a different approach: =20 MSK(0,63) =3D first 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) EMSK(0,63) =3D second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", client.random || server.random) =20 With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. =20 =20 The text from RFC 2716 Section 3.5 reads as follows: =20 Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, "client EAP encryption", random) is computed up to 128 bytes, and the value PRF("", "client EAP encryption", random) is computed up to 64 bytes (where "" is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output. =09 =09 ------_=_NextPart_001_01C7A947.30174FBD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Is there any reason not to use the approach in = RFC2716Bis? This=20 guarantees backward compatibility and require less=20 computation.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, June 07, = 2007=20 3:05 PM
To: emu@ietf.org
Subject: [Emu] Issue with = RFC=20 2716bis key generation

It has been pointed out by Paul Funk that the key = generation=20 formula specified in RFC 2716bis could cause backward compatibility = problems=20 once TLS v1.2 is introduced.
 
The formula in -09 is as=20 follows:
 
MSK(0,63)    =3D TLS-PRF-64(TMS, = "client=20 EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
   EMSK(0,63)   = =3D=20 second 64 octets=20 = of:
           =       =20 TLS-PRF-128(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
  =20 IV(0,63)     =3D TLS-PRF-64("", "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)

The issue here is that RFC 2716 = Section=20 3.5 specifies a different approach:
 
  =20 MSK(0,63)   =3D first 64 octets=20 = of:
           =       =20 TLS-PRF-128(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
   EMSK(0,63)   = =3D=20 second 64 octets=20 = of:
           =       =20 TLS-PRF-128(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
  =20 IV(0,63)     =3D TLS-PRF-64("", "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
 
With the current TLS PRF, = these=20 two approaches are identical.  However, this is not necessarily = true for=20 all PRFs that could conceivably be negotiated within TLS v1.2. =20
 
The text from RFC 2716 Section 3.5 reads as=20 follows:
 
   Since the normal TLS keys are used = in the=20 handshake, and therefore
   should not be used in a = different=20 context, new encryption keys must
   be derived from the = TLS=20 master secret for use with PPP encryption.
   For both = peer and=20 EAP server, the derivation proceeds as follows:
   given = the=20 master secret negotiated by the TLS handshake, the
  =20 pseudorandom function (PRF) defined in the specification for=20 the
   version of TLS in use, and the value random = defined as=20 the
   concatenation of the handshake message fields=20 client_hello.random and
   server_hello.random (in that = order),=20 the value PRF(master secret,
   "client EAP encryption", = random)=20 is computed up to 128 bytes, and the
   value PRF("", = "client EAP=20 encryption", random) is computed up to 64
   bytes (where = "" is=20 an empty string).  The peer encryption key (the
   = one used=20 for encrypting data from peer to EAP server) is obtained = by
  =20 truncating to the correct length the first 32 bytes of the first=20 PRF
   of these two output strings.  The EAP server=20 encryption key (the one
   used for encrypting data from = EAP=20 server to peer), if different from
   the client = encryption key,=20 is obtained by truncating to the correct
   length the = second 32=20 bytes of this same PRF output string.  The
   client = authentication key (the one used for computing MACs = for
  =20 messages from peer to EAP server), if used, is obtained by=20 truncating
   to the correct length the third 32 bytes of = this=20 same PRF output
   string.  The EAP server = authentication=20 key (the one used for
   computing MACs for messages from = EAP=20 server to peer), if used, and if
   different from the = peer=20 authentication key, is obtained by truncating
   to the = correct=20 length the fourth 32 bytes of this same PRF output
  =20 string.  The peer initialization vector (IV), used for messages=20 from
   peer to EAP server if a block cipher has been = specified,=20 is obtained
   by truncating to the cipher's block size = the first=20 32 bytes of the
   second PRF output string mentioned=20 above.  Finally, the server
   initialization vector = (IV),=20 used for messages from peer to EAP server
   if a block = cipher=20 has been specified, is obtained by truncating to
   the = cipher's=20 block size the second 32 bytes of this second PRF
  =20 output.

------_=_NextPart_001_01C7A947.30174FBD-- --===============2098499662== 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 --===============2098499662==-- From emu-bounces@ietf.org Thu Jun 07 17:29:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPXh-0002Rx-3L; Thu, 07 Jun 2007 17:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPXf-0002Rs-TJ for emu@ietf.org; Thu, 07 Jun 2007 17:29:15 -0400 Received: from bay0-omc1-s2.bay0.hotmail.com ([65.54.246.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPXf-0003fa-8P for emu@ietf.org; Thu, 07 Jun 2007 17:29:15 -0400 Received: from BAY117-W17 ([207.46.8.52]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 14:29:14 -0700 Message-ID: X-Originating-IP: [131.107.0.104] From: Bernard Aboba To: "Hao Zhou (hzhou)" , Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 14:29:14 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 21:29:14.0870 (UTC) FILETIME=[E5A33160:01C7A94A] X-Spam-Score: 2.2 (++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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="===============1232655579==" Errors-To: emu-bounces@ietf.org --===============1232655579== Content-Type: multipart/alternative; boundary="_ca99b7ae-1ea5-4cbb-b565-4eeeb78bc9ab_" --_ca99b7ae-1ea5-4cbb-b565-4eeeb78bc9ab_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that RFC 2716 specifies the use of TLS-PRF-128. If TLS v1.2= negotiates a PRF where PRF-64 is not the same as the first 64 octets of PR= F-128 (the IKEv2 PRF is an example of such a PRF), then RFC 2716bis impleme= ntations will not interoperate with RFC 2716 implementations. =20 Subject: RE: [Emu] Issue with RFC 2716bis key generationDate: Thu, 7 Jun 20= 07 17:02:40 -0400From: hzhou@cisco.comTo: bernard_aboba@hotmail.com; emu@ie= tf.orgCC:=20 Is there any reason not to use the approach in RFC2716Bis? This guarantees = backward compatibility and require less computation. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Thursday, June= 07, 2007 3:05 PMTo: emu@ietf.orgSubject: [Emu] Issue with RFC 2716bis key = generation It has been pointed out by Paul Funk that the key generation formula specif= ied in RFC 2716bis could cause backward compatibility problems once TLS v1.= 2 is introduced. The formula in -09 is as follows: MSK(0,63) =3D TLS-PR= F-64(TMS, "client EAP encryption", client.random || serv= er.random) EMSK(0,63) =3D second 64 octets of: TLS-PRF= -128(TMS, "client EAP encryption", client.random || serv= er.random) IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", = client.random || server.random)The issue here is that RFC 271= 6 Section 3.5 specifies a different approach: MSK(0,63) =3D first 64 o= ctets of: TLS-PRF-128(TMS, "client EAP encryption", = client.random || server.random) EMSK(0,63) =3D second 64 o= ctets of: TLS-PRF-128(TMS, "client EAP encryption", = client.random || server.random) IV(0,63) =3D TLS-PRF-64(= "", "client EAP encryption", client.random || server.ran= dom) With the current TLS PRF, these two approaches are identical. However= , this is not necessarily true for all PRFs that could conceivably be negot= iated within TLS v1.2. The text from RFC 2716 Section 3.5 reads as follow= s: Since the normal TLS keys are used in the handshake, and therefore = should not be used in a different context, new encryption keys must be de= rived from the TLS master secret for use with PPP encryption. For both pe= er and EAP server, the derivation proceeds as follows: given the master s= ecret negotiated by the TLS handshake, the pseudorandom function (PRF) de= fined in the specification for the version of TLS in use, and the value r= andom defined as the concatenation of the handshake message fields client= _hello.random and server_hello.random (in that order), the value PRF(mast= er secret, "client EAP encryption", random) is computed up to 128 bytes, = and the value PRF("", "client EAP encryption", random) is computed up to = 64 bytes (where "" is an empty string). The peer encryption key (the o= ne used for encrypting data from peer to EAP server) is obtained by trunc= ating to the correct length the first 32 bytes of the first PRF of these = two output strings. The EAP server encryption key (the one used for encr= ypting data from EAP server to peer), if different from the client encryp= tion key, is obtained by truncating to the correct length the second 32 b= ytes of this same PRF output string. The client authentication key (the = one used for computing MACs for messages from peer to EAP server), if use= d, is obtained by truncating to the correct length the third 32 bytes of = this same PRF output string. The EAP server authentication key (the one = used for computing MACs for messages from EAP server to peer), if used, a= nd if different from the peer authentication key, is obtained by truncati= ng to the correct length the fourth 32 bytes of this same PRF output st= ring. The peer initialization vector (IV), used for messages from peer t= o EAP server if a block cipher has been specified, is obtained by truncat= ing to the cipher's block size the first 32 bytes of the second PRF outpu= t string mentioned above. Finally, the server initialization vector (IV)= , used for messages from peer to EAP server if a block cipher has been sp= ecified, is obtained by truncating to the cipher's block size the second = 32 bytes of this second PRF output.= --_ca99b7ae-1ea5-4cbb-b565-4eeeb78bc9ab_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that RFC 2716 specifies the use of TLS-PRF-128.  If TLS= v1.2 negotiates a PRF where PRF-64 is not the same as the first 64 octets = of PRF-128 (the IKEv2 PRF is an example of such a PRF), then RFC 2716b= is implementations will not interoperate with RFC 2716 implementations. &nb= sp;

Subject: RE: [Emu] Issue with RFC 2716bis key generation
Date: Thu, 7 Ju= n 2007 17:02:40 -0400
From: hzhou@cisco.com
To: bernard_aboba@hotmail= .com; emu@ietf.org
CC:

Is there any reason not to use the approach in RFC= 2716Bis? This guarantees backward compatibility and require less computatio= n.

From: Bernard Aboba [mailto:bernard_aboba@hotmai= l.com]
Sent: Thursday, June 07, 2007 3:05 PM
To: emu@i= etf.org
Subject: [Emu] Issue with RFC 2716bis key generation
<= /FONT>
It has been pointed out by Paul Funk that the key generatio= n formula specified in RFC 2716bis could cause backward compatibility probl= ems once TLS v1.2 is introduced.
 
The formula in -09 is as fol= lows:
 
MSK(0,63)    =3D TLS-PRF-64(TMS, "client = EAP encryption",
         &= nbsp;          client.random |= | server.random)
   EMSK(0,63)   =3D second 64 octet= s of:
           =        TLS-PRF-128(TMS, "client EAP encryptio= n",
           &n= bsp;        client.random || server.rand= om)
   IV(0,63)     =3D TLS-PRF-64("", "cl= ient EAP encryption",
        &n= bsp;           client.ran= dom || server.random)

The issue here is that RFC 2716 Section 3.5 sp= ecifies a different approach:
 
   MSK(0,63) &nbs= p; =3D first 64 octets of:
      &nbs= p;           TLS-PRF-128(= TMS, "client EAP encryption",
       =              cl= ient.random || server.random)
   EMSK(0,63)   =3D se= cond 64 octets of:
         = ;         TLS-PRF-128(TMS, "client = EAP encryption",
         &= nbsp;          client.random |= | server.random)
   IV(0,63)     =3D TLS-P= RF-64("", "client EAP encryption",
      &= nbsp;           &nbs= p; client.random || server.random)
 
With the current TLS PRF, t= hese two approaches are identical.  However, this is not necessarily t= rue for all PRFs that could conceivably be negotiated within TLS v1.2. = ;
 
The text from RFC 2716 Section 3.5 reads as follows:
&nb= sp;
   Since the normal TLS keys are used in the handshake, an= d therefore
   should not be used in a different context, new = encryption keys must
   be derived from the TLS master secret = for use with PPP encryption.
   For both peer and EAP server, = the derivation proceeds as follows:
   given the master secret= negotiated by the TLS handshake, the
   pseudorandom function= (PRF) defined in the specification for the
   version of TLS = in use, and the value random defined as the
   concatenation o= f the handshake message fields client_hello.random and
   serv= er_hello.random (in that order), the value PRF(master secret,
 &nbs= p; "client EAP encryption", random) is computed up to 128 bytes, and the   value PRF("", "client EAP encryption", random) is computed up= to 64
   bytes (where "" is an empty string).  The peer = encryption key (the
   one used for encrypting data from peer = to EAP server) is obtained by
   truncating to the correct len= gth the first 32 bytes of the first PRF
   of these two output= strings.  The EAP server encryption key (the one
   used= for encrypting data from EAP server to peer), if different from
 &= nbsp; the client encryption key, is obtained by truncating to the correct   length the second 32 bytes of this same PRF output string.&n= bsp; The
   client authentication key (the one used for comput= ing MACs for
   messages from peer to EAP server), if used, is= obtained by truncating
   to the correct length the third 32 = bytes of this same PRF output
   string.  The EAP server = authentication key (the one used for
   computing MACs for mes= sages from EAP server to peer), if used, and if
   different f= rom the peer authentication key, is obtained by truncating
   = to the correct length the fourth 32 bytes of this same PRF output
 =   string.  The peer initialization vector (IV), used for messages= from
   peer to EAP server if a block cipher has been specifi= ed, is obtained
   by truncating to the cipher's block size th= e first 32 bytes of the
   second PRF output string mentioned = above.  Finally, the server
   initialization vector (IV)= , used for messages from peer to EAP server
   if a block ciph= er has been specified, is obtained by truncating to
   the cip= her's block size the second 32 bytes of this second PRF
   out= put.

= --_ca99b7ae-1ea5-4cbb-b565-4eeeb78bc9ab_-- --===============1232655579== 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 --===============1232655579==-- From emu-bounces@ietf.org Thu Jun 07 17:37:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPfD-0000O4-Sn; Thu, 07 Jun 2007 17:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPfC-0000IH-6M for emu@ietf.org; Thu, 07 Jun 2007 17:37:02 -0400 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 1HwPfA-0007R0-Nw for emu@ietf.org; Thu, 07 Jun 2007 17:37:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2007 14:36:56 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="377924654:sNHT55096568" 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 l57Lau8s029475; Thu, 7 Jun 2007 14:36:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57Lak2W021025; Thu, 7 Jun 2007 21:36:56 GMT 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, 7 Jun 2007 14:36:52 -0700 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] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 14:36:52 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue with RFC 2716bis key generation Thread-Index: AcepNtW8QfgTk1o5TsOY2SXma12C2QAEjD4Q From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2007 21:36:52.0529 (UTC) FILETIME=[F66C6A10:01C7A94B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4266; t=1181252216; x=1182116216; 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]=20Issue=20with=20RFC=202716bis=20key=20generati on |Sender:=20; bh=y0qSxtXmEfGMJg+ZVlxRqkC99trjrKojllSn12LVpDE=; b=qynd+11ec1O2VSQc+bR6YGfaSMdTtbzOs5YowLP8zX5u58TCFn+JQxOl5f5GbRtiWxteFqTs +7QmbrGVi3Kzq1paUeXCsxED4degVkDkLtKpsv1lq/OpJJRTtaVg++s+; 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: b5d20af10c334b36874c0264b10f59f1 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 Is there a reason why we changed to TLS-PRF-128 for the MSK?=20 Is this a huge issue given that there are not likely any existing implementations of EAP-TLS using TLS 1.2? Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, June 07, 2007 12:05 PM > To: emu@ietf.org > Subject: [Emu] Issue with RFC 2716bis key generation >=20 > It has been pointed out by Paul Funk that the key generation=20 > formula specified in RFC 2716bis could cause backward=20 > compatibility problems once TLS v1.2 is introduced.=20 > =20 > The formula in -09 is as follows: > =20 > MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", > client.random || server.random) > EMSK(0,63) =3D second 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", > client.random || server.random) >=20 > The issue here is that RFC 2716 Section 3.5 specifies a=20 > different approach: > =20 > MSK(0,63) =3D first 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > EMSK(0,63) =3D second 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", > client.random || server.random) > =20 > With the current TLS PRF, these two approaches are identical.=20 > However, this is not necessarily true for all PRFs that=20 > could conceivably be negotiated within TLS v1.2. =20 > =20 > The text from RFC 2716 Section 3.5 reads as follows: > =20 > Since the normal TLS keys are used in the handshake, and therefore > should not be used in a different context, new encryption keys must > be derived from the TLS master secret for use with PPP encryption. > For both peer and EAP server, the derivation proceeds as follows: > given the master secret negotiated by the TLS handshake, the > pseudorandom function (PRF) defined in the specification for the > version of TLS in use, and the value random defined as the > concatenation of the handshake message fields=20 > client_hello.random and > server_hello.random (in that order), the value PRF(master secret, > "client EAP encryption", random) is computed up to 128=20 > bytes, and the > value PRF("", "client EAP encryption", random) is computed up to 64 > bytes (where "" is an empty string). The peer encryption key (the > one used for encrypting data from peer to EAP server) is=20 > obtained by > truncating to the correct length the first 32 bytes of the=20 > first PRF > of these two output strings. The EAP server encryption=20 > key (the one > used for encrypting data from EAP server to peer), if=20 > different from > the client encryption key, is obtained by truncating to the correct > length the second 32 bytes of this same PRF output string. The > client authentication key (the one used for computing MACs for > messages from peer to EAP server), if used, is obtained by=20 > truncating > to the correct length the third 32 bytes of this same PRF output > string. The EAP server authentication key (the one used for > computing MACs for messages from EAP server to peer), if=20 > used, and if > different from the peer authentication key, is obtained by=20 > truncating > to the correct length the fourth 32 bytes of this same PRF output > string. The peer initialization vector (IV), used for=20 > messages from > peer to EAP server if a block cipher has been specified,=20 > is obtained > by truncating to the cipher's block size the first 32 bytes of the > second PRF output string mentioned above. Finally, the server > initialization vector (IV), used for messages from peer to=20 > EAP server > if a block cipher has been specified, is obtained by truncating to > the cipher's block size the second 32 bytes of this second PRF > output. >=20 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 07 17:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPtg-0004oA-Ju; Thu, 07 Jun 2007 17:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPtg-0004o5-5c for emu@ietf.org; Thu, 07 Jun 2007 17:52:00 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPtf-0003cV-HS for emu@ietf.org; Thu, 07 Jun 2007 17:52:00 -0400 Received: from BAY117-W21 ([207.46.8.56]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 14:51:59 -0700 Message-ID: X-Originating-IP: [131.107.0.77] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 14:51:58 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 21:51:59.0040 (UTC) FILETIME=[12BF0400:01C7A94E] X-Spam-Score: 2.6 (++) 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: , Content-Type: multipart/mixed; boundary="===============1937379248==" Errors-To: emu-bounces@ietf.org --===============1937379248== Content-Type: multipart/alternative; boundary="_db894312-d895-4aa1-ab2c-eab251ee6aea_" --_db894312-d895-4aa1-ab2c-eab251ee6aea_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis is using TLS-= PRF-64. =20 =20 > Subject: RE: [Emu] Issue with RFC 2716bis key generation> Date: Thu, 7 Ju= n 2007 14:36:52 -0700> From: jsalowey@cisco.com> To: bernard_aboba@hotmail.= com; emu@ietf.org> CC: > > Is there a reason why we changed to TLS-PRF-128 = for the MSK? > Is this a huge issue given that there are not likely any exi= sting> implementations of EAP-TLS using TLS 1.2?> > Joe> > > > -----Origina= l Message-----> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > = > Sent: Thursday, June 07, 2007 12:05 PM> > To: emu@ietf.org> > Subject: [E= mu] Issue with RFC 2716bis key generation> > > > It has been pointed out by= Paul Funk that the key generation > > formula specified in RFC 2716bis cou= ld cause backward > > compatibility problems once TLS v1.2 is introduced. >= > > > The formula in -09 is as follows:> > > > MSK(0,63) =3D TLS-PRF-64(TM= S, "client EAP encryption",> > client.random || server.random)> > EMSK(0,63= ) =3D second 64 octets of:> > TLS-PRF-128(TMS, "client EAP encryption",> > = client.random || server.random)> > IV(0,63) =3D TLS-PRF-64("", "client EAP = encryption",> > client.random || server.random)> > > > The issue here is th= at RFC 2716 Section 3.5 specifies a > > different approach:> > > > MSK(0,63= ) =3D first 64 octets of:> > TLS-PRF-128(TMS, "client EAP encryption",> > c= lient.random || server.random)> > EMSK(0,63) =3D second 64 octets of:> > TL= S-PRF-128(TMS, "client EAP encryption",> > client.random || server.random)>= > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",> > client.random ||= server.random)> > > > With the current TLS PRF, these two approaches are i= dentical. > > However, this is not necessarily true for all PRFs that > > c= ould conceivably be negotiated within TLS v1.2. > > > > The text from RFC 2= 716 Section 3.5 reads as follows:> > > > Since the normal TLS keys are used= in the handshake, and therefore> > should not be used in a different conte= xt, new encryption keys must> > be derived from the TLS master secret for u= se with PPP encryption.> > For both peer and EAP server, the derivation pro= ceeds as follows:> > given the master secret negotiated by the TLS handshak= e, the> > pseudorandom function (PRF) defined in the specification for the>= > version of TLS in use, and the value random defined as the> > concatenat= ion of the handshake message fields > > client_hello.random and> > server_h= ello.random (in that order), the value PRF(master secret,> > "client EAP en= cryption", random) is computed up to 128 > > bytes, and the> > value PRF(""= , "client EAP encryption", random) is computed up to 64> > bytes (where "" = is an empty string). The peer encryption key (the> > one used for encryptin= g data from peer to EAP server) is > > obtained by> > truncating to the cor= rect length the first 32 bytes of the > > first PRF> > of these two output = strings. The EAP server encryption > > key (the one> > used for encrypting = data from EAP server to peer), if > > different from> > the client encrypti= on key, is obtained by truncating to the correct> > length the second 32 by= tes of this same PRF output string. The> > client authentication key (the o= ne used for computing MACs for> > messages from peer to EAP server), if use= d, is obtained by > > truncating> > to the correct length the third 32 byte= s of this same PRF output> > string. The EAP server authentication key (the= one used for> > computing MACs for messages from EAP server to peer), if >= > used, and if> > different from the peer authentication key, is obtained = by > > truncating> > to the correct length the fourth 32 bytes of this same= PRF output> > string. The peer initialization vector (IV), used for > > me= ssages from> > peer to EAP server if a block cipher has been specified, > >= is obtained> > by truncating to the cipher's block size the first 32 bytes= of the> > second PRF output string mentioned above. Finally, the server> >= initialization vector (IV), used for messages from peer to > > EAP server>= > if a block cipher has been specified, is obtained by truncating to> > th= e cipher's block size the second 32 bytes of this second PRF> > output.> > = > > > > > > _______________________________________________> Emu mailing li= st> Emu@ietf.org> https://www1.ietf.org/mailman/listinfo/emu= --_db894312-d895-4aa1-ab2c-eab251ee6aea_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis is using TLS-= PRF-64. 
 


> Subject: RE: [Emu] Issue with RFC 2716bis key generation
&g= t; Date: Thu, 7 Jun 2007 14:36:52 -0700
> From: jsalowey@cisco.com> To: bernard_aboba@hotmail.com; emu@ietf.org
> CC:
>
= > Is there a reason why we changed to TLS-PRF-128 for the MSK?
> = Is this a huge issue given that there are not likely any existing
> i= mplementations of EAP-TLS using TLS 1.2?
>
> Joe
>
&= gt;
> > -----Original Message-----
> > From: Bernard Abo= ba [mailto:bernard_aboba@hotmail.com]
> > Sent: Thursday, June 07= , 2007 12:05 PM
> > To: emu@ietf.org
> > Subject: [Emu] I= ssue with RFC 2716bis key generation
> >
> > It has been= pointed out by Paul Funk that the key generation
> > formula spe= cified in RFC 2716bis could cause backward
> > compatibility prob= lems once TLS v1.2 is introduced.
> >
> > The formula i= n -09 is as follows:
> >
> > MSK(0,63) =3D TLS-PRF-64(TM= S, "client EAP encryption",
> > client.random || server.random)> > EMSK(0,63) =3D second 64 octets of:
> > TLS-PRF-128(TMS= , "client EAP encryption",
> > client.random || server.random)
= > > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",
> >= client.random || server.random)
> >
> > The issue here = is that RFC 2716 Section 3.5 specifies a
> > different approach:<= BR>> >
> > MSK(0,63) =3D first 64 octets of:
> > T= LS-PRF-128(TMS, "client EAP encryption",
> > client.random || serv= er.random)
> > EMSK(0,63) =3D second 64 octets of:
> > TL= S-PRF-128(TMS, "client EAP encryption",
> > client.random || serve= r.random)
> > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",=
> > client.random || server.random)
> >
> > Wi= th the current TLS PRF, these two approaches are identical.
> > H= owever, this is not necessarily true for all PRFs that
> > could = conceivably be negotiated within TLS v1.2.
> >
> > The = text from RFC 2716 Section 3.5 reads as follows:
> >
> >= Since the normal TLS keys are used in the handshake, and therefore
>= > should not be used in a different context, new encryption keys must> > be derived from the TLS master secret for use with PPP encrypti= on.
> > For both peer and EAP server, the derivation proceeds as f= ollows:
> > given the master secret negotiated by the TLS handshak= e, the
> > pseudorandom function (PRF) defined in the specificatio= n for the
> > version of TLS in use, and the value random defined = as the
> > concatenation of the handshake message fields
> = > client_hello.random and
> > server_hello.random (in that orde= r), the value PRF(master secret,
> > "client EAP encryption", rand= om) is computed up to 128
> > bytes, and the
> > value P= RF("", "client EAP encryption", random) is computed up to 64
> > b= ytes (where "" is an empty string). The peer encryption key (the
> &g= t; one used for encrypting data from peer to EAP server) is
> > o= btained by
> > truncating to the correct length the first 32 bytes= of the
> > first PRF
> > of these two output strings. T= he EAP server encryption
> > key (the one
> > used for e= ncrypting data from EAP server to peer), if
> > different from> > the client encryption key, is obtained by truncating to the corr= ect
> > length the second 32 bytes of this same PRF output string.= The
> > client authentication key (the one used for computing MAC= s for
> > messages from peer to EAP server), if used, is obtained = by
> > truncating
> > to the correct length the third 32= bytes of this same PRF output
> > string. The EAP server authenti= cation key (the one used for
> > computing MACs for messages from = EAP server to peer), if
> > used, and if
> > different f= rom the peer authentication key, is obtained by
> > truncating> > to the correct length the fourth 32 bytes of this same PRF outpu= t
> > string. The peer initialization vector (IV), used for
&g= t; > messages from
> > peer to EAP server if a block cipher has= been specified,
> > is obtained
> > by truncating to th= e cipher's block size the first 32 bytes of the
> > second PRF out= put string mentioned above. Finally, the server
> > initialization= vector (IV), used for messages from peer to
> > EAP server
&g= t; > if a block cipher has been specified, is obtained by truncating to<= BR>> > the cipher's block size the second 32 bytes of this second PRF=
> > output.
> >
> >
> >
> > _______________________________________________
> Emu mailing l= ist
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu=

= --_db894312-d895-4aa1-ab2c-eab251ee6aea_-- --===============1937379248== 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 --===============1937379248==-- From emu-bounces@ietf.org Thu Jun 07 17:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ0u-0001TC-J2; Thu, 07 Jun 2007 17:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ0s-0001T5-Pz for emu@ietf.org; Thu, 07 Jun 2007 17:59:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQ0s-0006eI-FV for emu@ietf.org; Thu, 07 Jun 2007 17:59:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2007 14:59:25 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="4520480:sNHT25434426" 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 l57LxPx9027703; Thu, 7 Jun 2007 14:59:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l57Lwnaq019990; Thu, 7 Jun 2007 21:59:25 GMT 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, 7 Jun 2007 14:59:22 -0700 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] Issue: Encoding of NAIs within EAP-TLS certificates Date: Thu, 7 Jun 2007 14:59:23 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Thread-Index: AcepLAT8AgeEq7AER4WjZXmMIeqXIQAIOAXQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2007 21:59:22.0443 (UTC) FILETIME=[1B08F1B0:01C7A94F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2853; t=1181253565; x=1182117565; 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]=20Issue=3A=20Encoding=20of=20NAIs=20within=20EA P-TLS=20certificates |Sender:=20; bh=NS1yvgY6lA7wxq3c/tM0G6k567c8KBFKhzf3b94aHv4=; b=dQBkPBK/he/bDp8EzSOkx5I6OkKbPq9oTXSvzRJl9+BYGvhMCtVvd3NZCw+Or1Uj2RntygfM J8Gf7cyK/fumgSZS9E3Yddud2TetOzZkQwuABjt6KrFQjPwsA6018Tzh; 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: d8ae4fd88fcaf47c1a71c804d04f413d 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 Ok the text below seems to mandate rfc822 SubjectAltName in all cases. How about just removing the reference to the emailAddress RDN from that paragraph. Perhaps replacing it by: "If subject naming information is present only in the subject name field and the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or serialNumber RDN. It is RECOMMENDED that when the peer identity represents a user the Subject distinguished name should not contain an emailAddress RDN, but rather use the rfc822 SubjectAltName as described above."=20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, June 07, 2007 10:48 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates >=20 > Right. The RFC 3280 statement only applies to RFC 822 names.=20 > That's why I think that the text should focus on those names.=20 >=20 > > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS=20 > certificates > > Date: Thu, 7 Jun 2007 08:57:49 -0700 > > From: jsalowey@cisco.com > > To: bernard_aboba@hotmail.com; emu@ietf.org > >=20 > > Not all identities are an RFC822 Name so using an RFC822=20 > name is not=20 > > always appropriate. If you are going to include an RFC822=20 > name in the=20 > > certificate then it should be in the RFC822 SubjecAltName.=20 > The Subject=20 > > distinguished name may include other name elements. > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Thursday, June 07, 2007 7:54 AM > > > To: emu@ietf.org > > > Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates > > >=20 > > >=20 > > > RFC 3280 Section 4.1.2.6 says: > > >=20 > > > Conforming implementations generating new certificates with=20 > > > electronic mail addresses MUST use the rfc822Name in the subject=20 > > > alternative name field (section 4.2.1.7) to describe such=20 > > > identities. > > > Simultaneous inclusion of the EmailAddress attribute in=20 > the subject=20 > > > distinguished name to support legacy implementations is=20 > deprecated=20 > > > but permitted. > > >=20 > > > This leads me to believe that the statement below from=20 > Section 5.2=20 > > > isn't quite right: > > >=20 > > > "Although the use of the subject name field is existing practice,=20 > > > its use in EAP-TLS is deprecated and Certification=20 > Authorities are=20 > > > encouraged to use the subjectAltName field instead. " > > >=20 > > > An RFC 3280-equivalent statement would be: > > >=20 > > >=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 Thu Jun 07 18:10:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQBm-0001Aa-6c; Thu, 07 Jun 2007 18:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQBk-0001AS-Oq for emu@ietf.org; Thu, 07 Jun 2007 18:10:40 -0400 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 1HwQBj-00012z-41 for emu@ietf.org; Thu, 07 Jun 2007 18:10:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2007 15:10:39 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="377932094:sNHT53093344" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l57MAcwf014590; Thu, 7 Jun 2007 15:10:38 -0700 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 l57MATaU029613; Thu, 7 Jun 2007 22:10:38 GMT 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); Thu, 7 Jun 2007 15:10:21 -0700 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] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 15:10:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue with RFC 2716bis key generation Thread-Index: AcepThRKXUK52ruTT1yjzd/18STj9QAASKOQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 07 Jun 2007 22:10:21.0653 (UTC) FILETIME=[A3F46850:01C7A950] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5530; t=1181254238; x=1182118238; 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]=20Issue=20with=20RFC=202716bis=20key=20generati on |Sender:=20; bh=IjBJvA45HFpTpjYAwTt5nicAM6TdB6BN9tKz7j+VBW8=; b=AlmMscKJXAKWbKicEA/mHdMYaR/gwJ0r2L3iwHLTaoo8LKb5TBz3UzdHVwSmTtQbRbdN+SHy EofvVDjfXib9uRi68keFVZuXOsZKd0t3I5xMlSKkW91jlvbjEOpqVW10Q7w/XniGzQkotJkNdf 890Qb60zEQkdk6xlBxJCH3KVk=; 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: 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: , Errors-To: emu-bounces@ietf.org So TLS 1.2 won't change the PRF for TLS 1.1-. =20 Shouldn't existing implementations based on RFC2716 interoperate with RFC2716bis implementations using TLS 1.1 and 1.0? =20 What we define in 2716bis is what EAP-TLS implementations based on TLS 1.2 will use. These implementations should interoperate with one another. =20 I'm not sure where the problem is.=20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, June 07, 2007 2:52 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Issue with RFC 2716bis key generation >=20 > RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis=20 > is using TLS-PRF-64. =20 > =20 >=20 >=20 > > Subject: RE: [Emu] Issue with RFC 2716bis key generation > > Date: Thu, 7 Jun 2007 14:36:52 -0700 > > From: jsalowey@cisco.com > > To: bernard_aboba@hotmail.com; emu@ietf.org > > CC:=20 > >=20 > > Is there a reason why we changed to TLS-PRF-128 for the MSK?=20 > > Is this a huge issue given that there are not likely any existing=20 > > implementations of EAP-TLS using TLS 1.2? > >=20 > > Joe > >=20 > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Thursday, June 07, 2007 12:05 PM > > > To: emu@ietf.org > > > Subject: [Emu] Issue with RFC 2716bis key generation > > >=20 > > > It has been pointed out by Paul Funk that the key=20 > generation formula=20 > > > specified in RFC 2716bis could cause backward=20 > compatibility problems=20 > > > once TLS v1.2 is introduced. > > >=20 > > > The formula in -09 is as follows: > > >=20 > > > MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption",=20 > client.random=20 > > > || server.random) > > > EMSK(0,63) =3D second 64 octets of: > > > TLS-PRF-128(TMS, "client EAP encryption", client.random ||=20 > > > server.random) > > > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",=20 > client.random ||=20 > > > server.random) > > >=20 > > > The issue here is that RFC 2716 Section 3.5 specifies a different=20 > > > approach: > > >=20 > > > MSK(0,63) =3D first 64 octets of: > > > TLS-PRF-128(TMS, "client EAP encryption", client.random ||=20 > > > server.random) > > > EMSK(0,63) =3D second 64 octets of: > > > TLS-PRF-128(TMS, "client EAP encryption", client.random ||=20 > > > server.random) > > > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",=20 > client.random ||=20 > > > server.random) > > >=20 > > > With the current TLS PRF, these two approaches are identical.=20 > > > However, this is not necessarily true for all PRFs that could=20 > > > conceivably be negotiated within TLS v1.2. > > >=20 > > > The text from RFC 2716 Section 3.5 reads as follows: > > >=20 > > > Since the normal TLS keys are used in the handshake, and=20 > therefore=20 > > > should not be used in a different context, new encryption=20 > keys must=20 > > > be derived from the TLS master secret for use with PPP encryption. > > > For both peer and EAP server, the derivation proceeds as follows: > > > given the master secret negotiated by the TLS handshake, the=20 > > > pseudorandom function (PRF) defined in the specification for the=20 > > > version of TLS in use, and the value random defined as the=20 > > > concatenation of the handshake message fields client_hello.random=20 > > > and server_hello.random (in that order), the value PRF(master=20 > > > secret, "client EAP encryption", random) is computed up to 128=20 > > > bytes, and the value PRF("", "client EAP encryption", random) is=20 > > > computed up to 64 bytes (where "" is an empty string). The peer=20 > > > encryption key (the one used for encrypting data from peer to EAP=20 > > > server) is obtained by truncating to the correct length=20 > the first 32=20 > > > bytes of the first PRF of these two output strings. The=20 > EAP server=20 > > > encryption key (the one used for encrypting data from EAP=20 > server to=20 > > > peer), if different from the client encryption key, is=20 > obtained by=20 > > > truncating to the correct length the second 32 bytes of this same=20 > > > PRF output string. The client authentication key (the one=20 > used for=20 > > > computing MACs for messages from peer to EAP server), if used, is=20 > > > obtained by truncating to the correct length the third 32=20 > bytes of=20 > > > this same PRF output string. The EAP server=20 > authentication key (the=20 > > > one used for computing MACs for messages from EAP server=20 > to peer),=20 > > > if used, and if different from the peer authentication key, is=20 > > > obtained by truncating to the correct length the fourth=20 > 32 bytes of=20 > > > this same PRF output string. The peer initialization vector (IV),=20 > > > used for messages from peer to EAP server if a block=20 > cipher has been=20 > > > specified, is obtained by truncating to the cipher's=20 > block size the=20 > > > first 32 bytes of the second PRF output string mentioned above.=20 > > > Finally, the server initialization vector (IV), used for messages=20 > > > from peer to EAP server if a block cipher has been specified, is=20 > > > obtained by truncating to the cipher's block size the second 32=20 > > > bytes of this second PRF output. > > >=20 > > >=20 > > >=20 > >=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 Thu Jun 07 19:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRZS-000513-S9; Thu, 07 Jun 2007 19:39:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRZR-00050g-7H for emu@ietf.org; Thu, 07 Jun 2007 19:39:13 -0400 Received: from bay0-omc2-s2.bay0.hotmail.com ([65.54.246.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwRZQ-0005XA-EA for emu@ietf.org; Thu, 07 Jun 2007 19:39:13 -0400 Received: from BAY117-W22 ([207.46.8.57]) by bay0-omc2-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 16:39:12 -0700 Message-ID: X-Originating-IP: [131.107.0.77] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 16:39:11 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2007 23:39:12.0005 (UTC) FILETIME=[0D179350:01C7A95D] X-Spam-Score: 2.6 (++) 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: , Content-Type: multipart/mixed; boundary="===============1987379616==" Errors-To: emu-bounces@ietf.org --===============1987379616== Content-Type: multipart/alternative; boundary="_b7466c5e-b0ca-4776-8fb9-b141f0d735e4_" --_b7466c5e-b0ca-4776-8fb9-b141f0d735e4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that some PRFs generate a different stream if asked to provi= de 64 octets of output than they do if asked to provide 128 bytes of output= . As a result, the first 64 octets of TLS-PRF-128 (used in RFC 2716) is no= t the same as TLS-PRF-64 (what was used in RFC2716bis-09).=20 =20 Given this, an RFC 2716 implementation that utilizes TLS v1.2 will not inte= roperate with an RFC 2716bis implementation that utilizes TLS v1.2 if such = a PRF is negotiated. > Subject: RE: [Emu] Issue with RFC 2716bis key genera= tion> Date: Thu, 7 Jun 2007 15:10:22 -0700> From: jsalowey@cisco.com> To: b= ernard_aboba@hotmail.com; emu@ietf.org> > So TLS 1.2 won't change the PRF f= or TLS 1.1-. > > Shouldn't existing implementations based on RFC2716 intero= perate with> RFC2716bis implementations using TLS 1.1 and 1.0? > > What we = define in 2716bis is what EAP-TLS implementations based on TLS> 1.2 will us= e. These implementations should interoperate with one> another. > > I'm not= sure where the problem is. > > Joe> > > -----Original Message-----> > From= : Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Thursday, June= 07, 2007 2:52 PM> > To: Joseph Salowey (jsalowey); emu@ietf.org> > Subject= : RE: [Emu] Issue with RFC 2716bis key generation> > > > RFC 2716 used TLS-= PRF-128, so the question is why RFC 2716bis > > is using TLS-PRF-64. > > > = > > > > > > Subject: RE: [Emu] Issue with RFC 2716bis key generation> > > D= ate: Thu, 7 Jun 2007 14:36:52 -0700> > > From: jsalowey@cisco.com> > > To: = bernard_aboba@hotmail.com; emu@ietf.org> > > CC: > > > > > > Is there a rea= son why we changed to TLS-PRF-128 for the MSK? > > > Is this a huge issue g= iven that there are not likely any existing > > > implementations of EAP-TL= S using TLS 1.2?> > > > > > Joe> > > > > > > > > > -----Original Message---= --> > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]> > > > Sen= t: Thursday, June 07, 2007 12:05 PM> > > > To: emu@ietf.org> > > > Subject:= [Emu] Issue with RFC 2716bis key generation> > > > > > > > It has been poi= nted out by Paul Funk that the key > > generation formula > > > > specified= in RFC 2716bis could cause backward > > compatibility problems > > > > onc= e TLS v1.2 is introduced.> > > > > > > > The formula in -09 is as follows:>= > > > > > > > MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", > > c= lient.random > > > > || server.random)> > > > EMSK(0,63) =3D second 64 octe= ts of:> > > > TLS-PRF-128(TMS, "client EAP encryption", client.random || > = > > > server.random)> > > > IV(0,63) =3D TLS-PRF-64("", "client EAP encrypt= ion", > > client.random || > > > > server.random)> > > > > > > > The issue = here is that RFC 2716 Section 3.5 specifies a different > > > > approach:> = > > > > > > > MSK(0,63) =3D first 64 octets of:> > > > TLS-PRF-128(TMS, "cl= ient EAP encryption", client.random || > > > > server.random)> > > > EMSK(0= ,63) =3D second 64 octets of:> > > > TLS-PRF-128(TMS, "client EAP encryptio= n", client.random || > > > > server.random)> > > > IV(0,63) =3D TLS-PRF-64(= "", "client EAP encryption", > > client.random || > > > > server.random)> >= > > > > > > With the current TLS PRF, these two approaches are identical. = > > > > However, this is not necessarily true for all PRFs that could > > >= > conceivably be negotiated within TLS v1.2.> > > > > > > > The text from = RFC 2716 Section 3.5 reads as follows:> > > > > > > > Since the normal TLS = keys are used in the handshake, and > > therefore > > > > should not be use= d in a different context, new encryption > > keys must > > > > be derived f= rom the TLS master secret for use with PPP encryption.> > > > For both peer= and EAP server, the derivation proceeds as follows:> > > > given the maste= r secret negotiated by the TLS handshake, the > > > > pseudorandom function= (PRF) defined in the specification for the > > > > version of TLS in use, = and the value random defined as the > > > > concatenation of the handshake = message fields client_hello.random > > > > and server_hello.random (in that= order), the value PRF(master > > > > secret, "client EAP encryption", rand= om) is computed up to 128 > > > > bytes, and the value PRF("", "client EAP = encryption", random) is > > > > computed up to 64 bytes (where "" is an emp= ty string). The peer > > > > encryption key (the one used for encrypting da= ta from peer to EAP > > > > server) is obtained by truncating to the correc= t length > > the first 32 > > > > bytes of the first PRF of these two outpu= t strings. The > > EAP server > > > > encryption key (the one used for encr= ypting data from EAP > > server to > > > > peer), if different from the cli= ent encryption key, is > > obtained by > > > > truncating to the correct le= ngth the second 32 bytes of this same > > > > PRF output string. The client= authentication key (the one > > used for > > > > computing MACs for messag= es from peer to EAP server), if used, is > > > > obtained by truncating to = the correct length the third 32 > > bytes of > > > > this same PRF output s= tring. The EAP server > > authentication key (the > > > > one used for comp= uting MACs for messages from EAP server > > to peer), > > > > if used, and = if different from the peer authentication key, is > > > > obtained by trunc= ating to the correct length the fourth > > 32 bytes of > > > > this same PR= F output string. The peer initialization vector (IV), > > > > used for mess= ages from peer to EAP server if a block > > cipher has been > > > > specifi= ed, is obtained by truncating to the cipher's > > block size the > > > > fi= rst 32 bytes of the second PRF output string mentioned above. > > > > Final= ly, the server initialization vector (IV), used for messages > > > > from p= eer to EAP server if a block cipher has been specified, is > > > > obtained= by truncating to the cipher's block size the second 32 > > > > bytes of th= is second PRF output.> > > > > > > > > > > > > > > > > > __________________= _____________________________> > > Emu mailing list> > > Emu@ietf.org> > > = https://www1.ietf.org/mailman/listinfo/emu> > > > > > = --_b7466c5e-b0ca-4776-8fb9-b141f0d735e4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that some PRFs generate a different stream if asked to = provide 64 octets of output than they do if asked to provide 128 bytes of o= utput.  As a result, the first 64 octets of TLS-PRF-128 (used in RFC 2= 716) is not the same as TLS-PRF-64 (what was used in RFC2716bis-09).
 
Given this, an RFC 2716 implementation that utilizes TLS v1.2 will not inte= roperate with an RFC 2716bis implementation that utilizes TLS v1.2 if such = a PRF is negotiated.

> Subject: RE: [Emu] Issue with RFC 2716bis= key generation
> Date: Thu, 7 Jun 2007 15:10:22 -0700
> From: = jsalowey@cisco.com
> To: bernard_aboba@hotmail.com; emu@ietf.org
&= gt;
> So TLS 1.2 won't change the PRF for TLS 1.1-.
>
>= ; Shouldn't existing implementations based on RFC2716 interoperate with
= > RFC2716bis implementations using TLS 1.1 and 1.0?
>
> Wh= at we define in 2716bis is what EAP-TLS implementations based on TLS
>= ; 1.2 will use. These implementations should interoperate with one
> = another.
>
> I'm not sure where the problem is.
>
= > Joe
>
> > -----Original Message-----
> > From= : Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > Sent: Thur= sday, June 07, 2007 2:52 PM
> > To: Joseph Salowey (jsalowey); emu= @ietf.org
> > Subject: RE: [Emu] Issue with RFC 2716bis key genera= tion
> >
> > RFC 2716 used TLS-PRF-128, so the question = is why RFC 2716bis
> > is using TLS-PRF-64.
> >
>= ; >
> >
> > > Subject: RE: [Emu] Issue with RFC 2= 716bis key generation
> > > Date: Thu, 7 Jun 2007 14:36:52 -070= 0
> > > From: jsalowey@cisco.com
> > > To: bernard_= aboba@hotmail.com; emu@ietf.org
> > > CC:
> > > > > > Is there a reason why we changed to TLS-PRF-128 for the MS= K?
> > > Is this a huge issue given that there are not likely = any existing
> > > implementations of EAP-TLS using TLS 1.2?> > >
> > > Joe
> > >
> > >= ;
> > > > -----Original Message-----
> > > >= From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > > &= gt; Sent: Thursday, June 07, 2007 12:05 PM
> > > > To: emu@i= etf.org
> > > > Subject: [Emu] Issue with RFC 2716bis key ge= neration
> > > >
> > > > It has been pointed= out by Paul Funk that the key
> > generation formula
> &g= t; > > specified in RFC 2716bis could cause backward
> > co= mpatibility problems
> > > > once TLS v1.2 is introduced.> > > >
> > > > The formula in -09 is as foll= ows:
> > > >
> > > > MSK(0,63) =3D TLS-PRF-6= 4(TMS, "client EAP encryption",
> > client.random
> > &= gt; > || server.random)
> > > > EMSK(0,63) =3D second 64 = octets of:
> > > > TLS-PRF-128(TMS, "client EAP encryption",= client.random ||
> > > > server.random)
> > > = > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",
> > cli= ent.random ||
> > > > server.random)
> > > >=
> > > > The issue here is that RFC 2716 Section 3.5 specif= ies a different
> > > > approach:
> > > > > > > > MSK(0,63) =3D first 64 octets of:
> > > &= gt; TLS-PRF-128(TMS, "client EAP encryption", client.random ||
> >= ; > > server.random)
> > > > EMSK(0,63) =3D second 64 = octets of:
> > > > TLS-PRF-128(TMS, "client EAP encryption",= client.random ||
> > > > server.random)
> > > = > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption",
> > cli= ent.random ||
> > > > server.random)
> > > >=
> > > > With the current TLS PRF, these two approaches are= identical.
> > > > However, this is not necessarily true f= or all PRFs that could
> > > > conceivably be negotiated wi= thin TLS v1.2.
> > > >
> > > > The text from= RFC 2716 Section 3.5 reads as follows:
> > > >
> >= ; > > Since the normal TLS keys are used in the handshake, and
&g= t; > therefore
> > > > should not be used in a different= context, new encryption
> > keys must
> > > > be= derived from the TLS master secret for use with PPP encryption.
> &g= t; > > For both peer and EAP server, the derivation proceeds as follo= ws:
> > > > given the master secret negotiated by the TLS ha= ndshake, the
> > > > pseudorandom function (PRF) defined in= the specification for the
> > > > version of TLS in use, a= nd the value random defined as the
> > > > concatenation of= the handshake message fields client_hello.random
> > > > a= nd server_hello.random (in that order), the value PRF(master
> > = > > secret, "client EAP encryption", random) is computed up to 128 > > > > bytes, and the value PRF("", "client EAP encryption",= random) is
> > > > computed up to 64 bytes (where "" is an= empty string). The peer
> > > > encryption key (the one us= ed for encrypting data from peer to EAP
> > > > server) is = obtained by truncating to the correct length
> > the first 32 > > > > bytes of the first PRF of these two output strings. Th= e
> > EAP server
> > > > encryption key (the one = used for encrypting data from EAP
> > server to
> > >= ; > peer), if different from the client encryption key, is
> >= obtained by
> > > > truncating to the correct length the s= econd 32 bytes of this same
> > > > PRF output string. The = client authentication key (the one
> > used for
> > >= ; > computing MACs for messages from peer to EAP server), if used, is > > > > obtained by truncating to the correct length the thir= d 32
> > bytes of
> > > > this same PRF output st= ring. The EAP server
> > authentication key (the
> > &g= t; > one used for computing MACs for messages from EAP server
> &= gt; to peer),
> > > > if used, and if different from the pe= er authentication key, is
> > > > obtained by truncating to= the correct length the fourth
> > 32 bytes of
> > >= > this same PRF output string. The peer initialization vector (IV), > > > > used for messages from peer to EAP server if a block <= BR>> > cipher has been
> > > > specified, is obtained= by truncating to the cipher's
> > block size the
> > &= gt; > first 32 bytes of the second PRF output string mentioned above. > > > > Finally, the server initialization vector (IV), used = for messages
> > > > from peer to EAP server if a block cip= her has been specified, is
> > > > obtained by truncating t= o the cipher's block size the second 32
> > > > bytes of th= is second PRF output.
> > > >
> > > >
&g= t; > > >
> > >
> > > ___________________= ____________________________
> > > Emu mailing list
> >= ; > Emu@ietf.org
> > > https://www1.ietf.org/mailman/listinf= o/emu
> >
> >
> >

= --_b7466c5e-b0ca-4776-8fb9-b141f0d735e4_-- --===============1987379616== 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 --===============1987379616==-- From emu-bounces@ietf.org Thu Jun 07 20:42:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwSYG-0008DW-4p; Thu, 07 Jun 2007 20:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwSYE-0008DK-Sh for emu@ietf.org; Thu, 07 Jun 2007 20:42:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwSYE-0000Q0-8q for emu@ietf.org; Thu, 07 Jun 2007 20:42:02 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2007 17:42:01 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="161648753:sNHT55118214" 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 l580g11x008826; Thu, 7 Jun 2007 17:42:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l580g1tZ012010; Fri, 8 Jun 2007 00:42:01 GMT 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); Thu, 7 Jun 2007 17:42:01 -0700 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] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 17:42:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue with RFC 2716bis key generation Thread-Index: AcepXQ2EgZDNBu2RTN+yo5YkXLOhBAACJhog From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 08 Jun 2007 00:42:01.0466 (UTC) FILETIME=[D3DDADA0:01C7A965] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7115; t=1181263321; x=1182127321; 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]=20Issue=20with=20RFC=202716bis=20key=20generati on |Sender:=20; bh=1FMZe2Panqq6jqS8J9g9aOEnKHlNpu5/sV1TmdhqJrk=; b=ep6Dh6JMVyuZiGyvSTMdyh6ZTm914/JVvEiAw7FZiFEqlTmjCbUU12UL1hCK+wF6CfgkhYNr ZWUyfoT/FK4MRdasJC/DIFVVrsxju2dek5qg6bqf7bv9L87BJ9+4qxyWZIAgXmbYCjperlNI4Z C+W2wlQpRDPnLj2kzCe8k/Vx0=; 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: 202a3ece0492a8c7e7c8672d5214398f 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 Doesn't 2716bis obsolete RFC2716? Why would someone implement RFC2716 with TLS 1.2? =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, June 07, 2007 4:39 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Issue with RFC 2716bis key generation >=20 > The problem is that some PRFs generate a different stream if=20 > asked to provide 64 octets of output than they do if asked to=20 > provide 128 bytes of output. As a result, the first 64=20 > octets of TLS-PRF-128 (used in RFC 2716) is not the same as=20 > TLS-PRF-64 (what was used in RFC2716bis-09).=20 > =20 > Given this, an RFC 2716 implementation that utilizes TLS v1.2=20 > will not interoperate with an RFC 2716bis implementation that=20 > utilizes TLS v1.2 if such a PRF is negotiated.=20 >=20 > > Subject: RE: [Emu] Issue with RFC 2716bis key generation > > Date: Thu, 7 Jun 2007 15:10:22 -0700 > > From: jsalowey@cisco.com > > To: bernard_aboba@hotmail.com; emu@ietf.org > >=20 > > So TLS 1.2 won't change the PRF for TLS 1.1-.=20 > >=20 > > Shouldn't existing implementations based on RFC2716=20 > interoperate with=20 > > RFC2716bis implementations using TLS 1.1 and 1.0? > >=20 > > What we define in 2716bis is what EAP-TLS implementations=20 > based on TLS > > 1.2 will use. These implementations should interoperate with one=20 > > another. > >=20 > > I'm not sure where the problem is.=20 > >=20 > > Joe > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Thursday, June 07, 2007 2:52 PM > > > To: Joseph Salowey (jsalowey); emu@ietf.org > > > Subject: RE: [Emu] Issue with RFC 2716bis key generation > > >=20 > > > RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis is=20 > > > using TLS-PRF-64. > > >=20 > > >=20 > > >=20 > > > > Subject: RE: [Emu] Issue with RFC 2716bis key generation > > > > Date: Thu, 7 Jun 2007 14:36:52 -0700 > > > > From: jsalowey@cisco.com > > > > To: bernard_aboba@hotmail.com; emu@ietf.org > > > > CC:=20 > > > >=20 > > > > Is there a reason why we changed to TLS-PRF-128 for the MSK?=20 > > > > Is this a huge issue given that there are not likely=20 > any existing=20 > > > > implementations of EAP-TLS using TLS 1.2? > > > >=20 > > > > Joe > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > > Sent: Thursday, June 07, 2007 12:05 PM > > > > > To: emu@ietf.org > > > > > Subject: [Emu] Issue with RFC 2716bis key generation > > > > >=20 > > > > > It has been pointed out by Paul Funk that the key > > > generation formula > > > > > specified in RFC 2716bis could cause backward > > > compatibility problems > > > > > once TLS v1.2 is introduced. > > > > >=20 > > > > > The formula in -09 is as follows: > > > > >=20 > > > > > MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", > > > client.random > > > > > || server.random) > > > > > EMSK(0,63) =3D second 64 octets of: > > > > > TLS-PRF-128(TMS, "client EAP encryption", client.random || > > > > > server.random) > > > > > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", > > > client.random || > > > > > server.random) > > > > >=20 > > > > > The issue here is that RFC 2716 Section 3.5 specifies a=20 > > > > > different > > > > > approach: > > > > >=20 > > > > > MSK(0,63) =3D first 64 octets of: > > > > > TLS-PRF-128(TMS, "client EAP encryption", client.random || > > > > > server.random) > > > > > EMSK(0,63) =3D second 64 octets of: > > > > > TLS-PRF-128(TMS, "client EAP encryption", client.random || > > > > > server.random) > > > > > IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", > > > client.random || > > > > > server.random) > > > > >=20 > > > > > With the current TLS PRF, these two approaches are identical.=20 > > > > > However, this is not necessarily true for all PRFs that could=20 > > > > > conceivably be negotiated within TLS v1.2. > > > > >=20 > > > > > The text from RFC 2716 Section 3.5 reads as follows: > > > > >=20 > > > > > Since the normal TLS keys are used in the handshake, and > > > therefore > > > > > should not be used in a different context, new encryption > > > keys must > > > > > be derived from the TLS master secret for use with=20 > PPP encryption. > > > > > For both peer and EAP server, the derivation proceeds=20 > as follows: > > > > > given the master secret negotiated by the TLS handshake, the=20 > > > > > pseudorandom function (PRF) defined in the=20 > specification for the=20 > > > > > version of TLS in use, and the value random defined as the=20 > > > > > concatenation of the handshake message fields=20 > > > > > client_hello.random and server_hello.random (in that=20 > order), the=20 > > > > > value PRF(master secret, "client EAP encryption", random) is=20 > > > > > computed up to 128 bytes, and the value PRF("", "client EAP=20 > > > > > encryption", random) is computed up to 64 bytes=20 > (where "" is an=20 > > > > > empty string). The peer encryption key (the one used for=20 > > > > > encrypting data from peer to EAP > > > > > server) is obtained by truncating to the correct length > > > the first 32 > > > > > bytes of the first PRF of these two output strings. The > > > EAP server > > > > > encryption key (the one used for encrypting data from EAP > > > server to > > > > > peer), if different from the client encryption key, is > > > obtained by > > > > > truncating to the correct length the second 32 bytes of this=20 > > > > > same PRF output string. The client authentication key (the one > > > used for > > > > > computing MACs for messages from peer to EAP server),=20 > if used,=20 > > > > > is obtained by truncating to the correct length the third 32 > > > bytes of > > > > > this same PRF output string. The EAP server > > > authentication key (the > > > > > one used for computing MACs for messages from EAP server > > > to peer), > > > > > if used, and if different from the peer=20 > authentication key, is=20 > > > > > obtained by truncating to the correct length the fourth > > > 32 bytes of > > > > > this same PRF output string. The peer initialization vector=20 > > > > > (IV), used for messages from peer to EAP server if a block > > > cipher has been > > > > > specified, is obtained by truncating to the cipher's > > > block size the > > > > > first 32 bytes of the second PRF output string=20 > mentioned above.=20 > > > > > Finally, the server initialization vector (IV), used for=20 > > > > > messages from peer to EAP server if a block cipher has been=20 > > > > > specified, is obtained by truncating to the cipher's=20 > block size=20 > > > > > the second 32 bytes of this second PRF output. > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Emu mailing list > > > > Emu@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/emu > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jun 07 23:08:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUpm-0002bz-5h; Thu, 07 Jun 2007 23:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUpk-0002Zq-Py for emu@ietf.org; Thu, 07 Jun 2007 23:08:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUpk-0002Pd-0R for emu@ietf.org; Thu, 07 Jun 2007 23:08:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2007 20:08:15 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208,217"; a="160883293:sNHT140843808" 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 l5838Fo7014028; Thu, 7 Jun 2007 20:08:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5838EtV002248; Fri, 8 Jun 2007 03:08:15 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 23:08:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 23:08:12 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B70490D5F2@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue with RFC 2716bis key generation Thread-Index: AcepSu5lYfXJrqACTdKt2LwuS2hmeAALxtwA References: From: "Hao Zhou \(hzhou\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 08 Jun 2007 03:08:14.0527 (UTC) FILETIME=[41048CF0:01C7A97A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14191; t=1181272095; x=1182136095; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20\(hzhou\)=22=20 |Subject:=20RE=3A=20[Emu]=20Issue=20with=20RFC=202716bis=20key=20generati on |Sender:=20; bh=vReILKOVHpeHKNrQUfx0R/kbCnDHD9wNYuAlLKeVY9E=; b=CSgPksJZdAkBmKJibT6ePc4KdbhmKdEsB30rBDhxhyGdwKSwVO3mUWy6cjzZf5VzDvzjObVM ELPiQWA4pbdTNqKfzgMpsWJ4bW+qbMnoY3REfZ9RKp7HtMTO4R2M7b5EYuXs+YgxRFzt2ElpO1 AO3oINg99KTJXKkdbagRKrR9o=; Authentication-Results: sj-dkim-1; header.From=hzhou@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 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="===============0187942027==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0187942027== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A97A.40D207D9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A97A.40D207D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, I mistyped. I meant to say why not keep the approach used in RFC2716? What's the reason for the change in 2716Bis? ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Thursday, June 07, 2007 5:29 PM To: Hao Zhou (hzhou); emu@ietf.org Subject: RE: [Emu] Issue with RFC 2716bis key generation =09 =09 The problem is that RFC 2716 specifies the use of TLS-PRF-128. If TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first 64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF), then RFC 2716bis implementations will not interoperate with RFC 2716 implementations. =20 =09 =09 ________________________________ Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 17:02:40 -0400 From: hzhou@cisco.com To: bernard_aboba@hotmail.com; emu@ietf.org CC:=20 =09 =09 Is there any reason not to use the approach in RFC2716Bis? This guarantees backward compatibility and require less computation. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Thursday, June 07, 2007 3:05 PM To: emu@ietf.org Subject: [Emu] Issue with RFC 2716bis key generation =09 =09 It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced.=20 =20 The formula in -09 is as follows: =20 MSK(0,63) =3D TLS-PRF-64(TMS, "client EAP encryption", client.random || server.random) EMSK(0,63) =3D second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", client.random || server.random) =09 The issue here is that RFC 2716 Section 3.5 specifies a different approach: =20 MSK(0,63) =3D first 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) EMSK(0,63) =3D second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) IV(0,63) =3D TLS-PRF-64("", "client EAP encryption", client.random || server.random) =20 With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. =20 =20 The text from RFC 2716 Section 3.5 reads as follows: =20 Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, "client EAP encryption", random) is computed up to 128 bytes, and the value PRF("", "client EAP encryption", random) is computed up to 64 bytes (where "" is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output. =09 =09 ------_=_NextPart_001_01C7A97A.40D207D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry, I mistyped. I meant to say why not keep the = approach=20 used in RFC2716? What's the reason for the change in=20 2716Bis?

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, June 07, = 2007=20 5:29 PM
To: Hao Zhou (hzhou); = emu@ietf.org
Subject: RE:=20 [Emu] Issue with RFC 2716bis key generation

The problem is that RFC 2716 specifies the use of=20 TLS-PRF-128.  If TLS v1.2 negotiates a PRF where PRF-64 is not = the same=20 as the first 64 octets of PRF-128 (the IKEv2 PRF is an example of = such a=20 PRF), then RFC 2716bis implementations will not interoperate with RFC = 2716=20 implementations.  

Subject: RE: [Emu] Issue with RFC 2716bis key generation
Date: = Thu, 7 Jun=20 2007 17:02:40 -0400
From: hzhou@cisco.com
To:=20 bernard_aboba@hotmail.com; emu@ietf.org
CC:

Is there any reason not to use the approach in = RFC2716Bis?=20 This guarantees backward compatibility and require less=20 computation.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, June = 07,=20 2007 3:05 PM
To: emu@ietf.org
Subject: [Emu] = Issue=20 with RFC 2716bis key generation

It has been pointed out by Paul Funk that the key=20 generation formula specified in RFC 2716bis could cause backward=20 compatibility problems once TLS v1.2 is introduced. =
 
The=20 formula in -09 is as = follows:
 
MSK(0,63)    =3D=20 TLS-PRF-64(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
   = EMSK(0,63)   =3D=20 second 64 octets=20 = of:
           =       =20 TLS-PRF-128(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
  =20 IV(0,63)     =3D TLS-PRF-64("", "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)

The issue here is that RFC = 2716=20 Section 3.5 specifies a different = approach:
 
  =20 MSK(0,63)   =3D first 64 octets=20 = of:
           =       =20 TLS-PRF-128(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
   = EMSK(0,63)   =3D=20 second 64 octets=20 = of:
           =       =20 TLS-PRF-128(TMS, "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
  =20 IV(0,63)     =3D TLS-PRF-64("", "client EAP=20 = encryption",
         &nb= sp;         =20 client.random || server.random)
 
With the current TLS = PRF,=20 these two approaches are identical.  However, this is not = necessarily=20 true for all PRFs that could conceivably be negotiated within TLS=20 v1.2. 
 
The text from RFC 2716 Section 3.5 reads = as=20 follows:
 
   Since the normal TLS keys are = used in=20 the handshake, and therefore
   should not be used in = a=20 different context, new encryption keys must
   be = derived=20 from the TLS master secret for use with PPP = encryption.
  =20 For both peer and EAP server, the derivation proceeds as=20 follows:
   given the master secret negotiated by the = TLS=20 handshake, the
   pseudorandom function (PRF) defined = in the=20 specification for the
   version of TLS in use, and = the value=20 random defined as the
   concatenation of the = handshake=20 message fields client_hello.random and
   = server_hello.random=20 (in that order), the value PRF(master secret,
   = "client EAP=20 encryption", random) is computed up to 128 bytes, and = the
  =20 value PRF("", "client EAP encryption", random) is computed up to=20 64
   bytes (where "" is an empty string).  The = peer=20 encryption key (the
   one used for encrypting data = from peer=20 to EAP server) is obtained by
   truncating to the = correct=20 length the first 32 bytes of the first PRF
   of = these two=20 output strings.  The EAP server encryption key (the=20 one
   used for encrypting data from EAP server to = peer), if=20 different from
   the client encryption key, is = obtained by=20 truncating to the correct
   length the second 32 = bytes of=20 this same PRF output string.  The
   client=20 authentication key (the one used for computing MACs = for
  =20 messages from peer to EAP server), if used, is obtained by=20 truncating
   to the correct length the third 32 = bytes of=20 this same PRF output
   string.  The EAP server=20 authentication key (the one used for
   computing = MACs for=20 messages from EAP server to peer), if used, and if
   = different from the peer authentication key, is obtained by=20 truncating
   to the correct length the fourth 32 = bytes of=20 this same PRF output
   string.  The peer = initialization=20 vector (IV), used for messages from
   peer to EAP = server if=20 a block cipher has been specified, is obtained
   by=20 truncating to the cipher's block size the first 32 bytes of=20 the
   second PRF output string mentioned = above. =20 Finally, the server
   initialization vector (IV), = used for=20 messages from peer to EAP server
   if a block cipher = has=20 been specified, is obtained by truncating to
   the = cipher's=20 block size the second 32 bytes of this second PRF
  =20 = output.

------_=_NextPart_001_01C7A97A.40D207D9-- --===============0187942027== 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 --===============0187942027==-- From emu-bounces@ietf.org Fri Jun 08 00:21:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVyO-0006sj-8b; Fri, 08 Jun 2007 00:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVyM-0006ek-Ss for emu@ietf.org; Fri, 08 Jun 2007 00:21:14 -0400 Received: from bay0-omc2-s35.bay0.hotmail.com ([65.54.246.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwVyL-0008Rh-K2 for emu@ietf.org; Fri, 08 Jun 2007 00:21:14 -0400 Received: from BAY117-W18 ([207.46.8.53]) by bay0-omc2-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 21:21:13 -0700 Message-ID: X-Originating-IP: [208.54.15.129] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Thu, 7 Jun 2007 21:21:13 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jun 2007 04:21:13.0155 (UTC) FILETIME=[72E22930:01C7A984] X-Spam-Score: 2.2 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============1410179524==" Errors-To: emu-bounces@ietf.org --===============1410179524== Content-Type: multipart/alternative; boundary="_25323b07-8587-4682-b9ca-6973467541f1_" --_25323b07-8587-4682-b9ca-6973467541f1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Most existing RFC 2716 implementations are TLS version agnostic, and so man= y already support TLS v1.1 and will also automatically support TLS v1.2 whe= n that is implemented in the underlying SSL/TLS code. =20 While RFC 2716bis will obsolete RFC 2716, this doesn't mean that existing E= AP-TLS implementations will become obsolete or will change; almost all of t= hem should be compliant with the new spec. =20 =20 =20 =20 = --_25323b07-8587-4682-b9ca-6973467541f1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Most existing RFC 2716 implementations are TLS version agnostic, and so man= y already support TLS v1.1 and will also automatically support TLS v1.2 whe= n that is implemented in the underlying SSL/TLS code.
 
While RFC 2716bis will obsolete RFC 2716, this doesn't mean that existing E= AP-TLS implementations will become obsolete or will change; almost all of t= hem should be compliant with the new spec. 
 
 
 

 
= --_25323b07-8587-4682-b9ca-6973467541f1_-- --===============1410179524== 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 --===============1410179524==-- From emu-bounces@ietf.org Fri Jun 08 05:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbG3-0004vu-Sd; Fri, 08 Jun 2007 05:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbG3-0004vm-2W for emu@ietf.org; Fri, 08 Jun 2007 05:59:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwbG1-0002Mr-Jx for emu@ietf.org; Fri, 08 Jun 2007 05:59:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l589xOhE024588; Fri, 8 Jun 2007 12:59:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:59:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:59:34 +0300 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] Issue with RFC 2716bis key generation Date: Fri, 8 Jun 2007 12:59:33 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue with RFC 2716bis key generation Thread-Index: AcepSun5zI+HFHq5T/iC3aA8bdpG/QAaCgOg References: From: To: , X-OriginalArrivalTime: 08 Jun 2007 09:59:34.0593 (UTC) FILETIME=[B77BC310:01C7A9B3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Aboba wrote: > The problem is that RFC 2716 specifies the use of TLS-PRF-128. If > TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first > 64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF), > then RFC 2716bis implementations will not interoperate with RFC 2716 > implementations. I think this cannot happen in (current drafts of) TLS 1.2. We decided that all PRFs for TLS 1.2 must use the same "API" as the current PRF (arbitrary-length secret/label/seed as input, sufficiently long byte string out). And as far as I can tell, this cannot happen in IKEv2 either: the=20 output bytes are calculated one block at a time, and the "amount=20 of bytes (or blocks) needed" is not used in the calculation.=20 Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 11 17:31:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrTl-0007Sf-4J; Mon, 11 Jun 2007 17:31:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrTW-0007FK-5B for emu@ietf.org; Mon, 11 Jun 2007 17:30:58 -0400 Received: from bay0-omc1-s7.bay0.hotmail.com ([65.54.246.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxrQK-0006gy-Ei for emu@ietf.org; Mon, 11 Jun 2007 17:27:43 -0400 Received: from BAY117-W14 ([207.46.8.49]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Jun 2007 14:27:40 -0700 Message-ID: X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: "Hao Zhou (hzhou)" , Subject: RE: [Emu] Issue with RFC 2716bis key generation Date: Mon, 11 Jun 2007 14:27:40 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2007 21:27:40.0049 (UTC) FILETIME=[56C5A810:01C7AC6F] X-Spam-Score: 2.2 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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="===============0709624250==" Errors-To: emu-bounces@ietf.org --===============0709624250== Content-Type: multipart/alternative; boundary="_77ea44a1-eddb-4a6f-b33e-b8c9ec06bf80_" --_77ea44a1-eddb-4a6f-b33e-b8c9ec06bf80_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hao said: Sorry, I mistyped. I meant to say why not keep the approach used in RFC2716= ? What's the reason for the change in 2716Bis? =20 [BA] I would agree that the approach used in RFC 2716 is preferrable. As = to how the change got into RFC 2716bis, it appears to have been introduced = in -01; -00 Section 2.5 contained the original text from RFC 2716.=20 =20 The text inserted into -01 appears to have been taken from the EAP Key Mana= gement Framework document, which included similar text in Appendix C in -00= , and included an Appendix A on EAP-TLS key management up to version -09 (e= .g. see http://www.watersprings.org/pub/id/draft-ietf-eap-keying-09.txt).=20 =20 As you noted, the formula in RFC 2716bis appears to imply that two PRFs nee= d to be computed (TLS-PRF-64 and TLS-PRF-128) when in fact only one is need= ed (a single TLS-PRF-128). = --_77ea44a1-eddb-4a6f-b33e-b8c9ec06bf80_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hao said:

Sorry, I mistyped. I meant to say why not keep&nbs= p;the approach used in RFC2716? What's the reason for the change in 27= 16Bis?
 
[BA]  I would agree that the approach used in= RFC 2716 is preferrable.  As to how the change got into RFC 2716bis, = it appears to have been introduced in -01; -00 Section 2.5 contained the or= iginal text from RFC 2716.
 
The text inserted into -01 appears to have been ta= ken from the EAP Key Management Framework document, which included similar = text in Appendix C in -00, and included an Appendix A on EAP-TLS key manage= ment up to version -09 (e.g. see http://www.watersprings.org/pub/id/draft-= ietf-eap-keying-09.txt).
 
As you noted, the formula in RFC 2716bis appears t= o imply that two PRFs need to be computed (TLS-PRF-64 and TLS-PRF-128) when= in fact only one is needed (a single TLS-PRF-128). 
= --_77ea44a1-eddb-4a6f-b33e-b8c9ec06bf80_-- --===============0709624250== 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 --===============0709624250==-- From emu-bounces@ietf.org Mon Jun 11 17:46:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxriJ-0002Oz-MT; Mon, 11 Jun 2007 17:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxriJ-0002Op-0g for emu@ietf.org; Mon, 11 Jun 2007 17:46:15 -0400 Received: from bay0-omc2-s27.bay0.hotmail.com ([65.54.246.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxriH-00024s-Nc for emu@ietf.org; Mon, 11 Jun 2007 17:46:14 -0400 Received: from BAY117-W16 ([207.46.8.51]) by bay0-omc2-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Jun 2007 14:46:13 -0700 Message-ID: X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Mon, 11 Jun 2007 14:46:12 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2007 21:46:13.0331 (UTC) FILETIME=[EE570230:01C7AC71] X-Spam-Score: 2.2 (++) 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="===============0144862349==" Errors-To: emu-bounces@ietf.org --===============0144862349== Content-Type: multipart/alternative; boundary="_22c58df4-6d39-4810-a720-14ae9f2678a0_" --_22c58df4-6d39-4810-a720-14ae9f2678a0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey said: =20 > Not all identities are an RFC822 Name so using an RFC822 name is not> alw= ays appropriate. If you are going to include an RFC822 name in the> certifi= cate then it should be in the RFC822 SubjecAltName. The Subject> distinguis= hed name may include other name elements. That makes sense to me (assuming we substitute 'NAI' for RFC822 Name). =20 =20 = --_22c58df4-6d39-4810-a720-14ae9f2678a0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey said:
 
> Not all identities are an RFC822 Name so using an RFC822 name is not> always appropriate. If you are going to include an RFC822 name in th= e
> certificate then it should be in the RFC822 SubjecAltName. The Su= bject
> distinguished name may include other name elements.

That makes sense to me (assuming we substitute 'NAI' for RFC822 Name). = ;
 
 
= --_22c58df4-6d39-4810-a720-14ae9f2678a0_-- --===============0144862349== 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 --===============0144862349==-- From emu-bounces@ietf.org Mon Jun 11 17:46:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxriJ-0002P4-QZ; Mon, 11 Jun 2007 17:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxriJ-0002Ou-CV for emu@ietf.org; Mon, 11 Jun 2007 17:46:15 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxriI-00024u-3z for emu@ietf.org; Mon, 11 Jun 2007 17:46:15 -0400 Received: from BAY117-W7 ([207.46.8.42]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Jun 2007 14:46:13 -0700 Message-ID: X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Mon, 11 Jun 2007 14:46:12 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2007 21:46:13.0961 (UTC) FILETIME=[EEB72390:01C7AC71] X-Spam-Score: 2.2 (++) 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="===============0599191861==" Errors-To: emu-bounces@ietf.org --===============0599191861== Content-Type: multipart/alternative; boundary="_a7c9e45f-433b-4a6b-95bb-1a2293366b1a_" --_a7c9e45f-433b-4a6b-95bb-1a2293366b1a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey said: =20 > Not all identities are an RFC822 Name so using an RFC822 name is not> alw= ays appropriate. If you are going to include an RFC822 name in the> certifi= cate then it should be in the RFC822 SubjecAltName. The Subject> distinguis= hed name may include other name elements. That makes sense to me (assuming we substitute 'NAI' for RFC822 Name). =20 =20 = --_a7c9e45f-433b-4a6b-95bb-1a2293366b1a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey said:
 
> Not all identities are an RFC822 Name so using an RFC822 name is not> always appropriate. If you are going to include an RFC822 name in th= e
> certificate then it should be in the RFC822 SubjecAltName. The Su= bject
> distinguished name may include other name elements.

That makes sense to me (assuming we substitute 'NAI' for RFC822 Name). = ;
 
 
= --_a7c9e45f-433b-4a6b-95bb-1a2293366b1a_-- --===============0599191861== 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 --===============0599191861==-- From emu-bounces@ietf.org Mon Jun 11 18:01:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxrws-0004dl-7J; Mon, 11 Jun 2007 18:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxrwr-0004df-Mi for emu@ietf.org; Mon, 11 Jun 2007 18:01:17 -0400 Received: from bay0-omc2-s31.bay0.hotmail.com ([65.54.246.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxrwq-0003q4-Bo for emu@ietf.org; Mon, 11 Jun 2007 18:01:17 -0400 Received: from BAY117-W12 ([207.46.8.47]) by bay0-omc2-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Jun 2007 15:01:15 -0700 Message-ID: X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Mon, 11 Jun 2007 15:01:15 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2007 22:01:15.0935 (UTC) FILETIME=[085572F0:01C7AC74] X-Spam-Score: 2.4 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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="===============0268834952==" Errors-To: emu-bounces@ietf.org --===============0268834952== Content-Type: multipart/alternative; boundary="_4cceddee-4961-4010-9d53-1bb50521f940_" --_4cceddee-4961-4010-9d53-1bb50521f940_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe Salowey > Ok the text below seems to mandate rfc822 SubjectAltName in all cases.> H= ow about just removing the reference to the emailAddress RDN from that> par= agraph. Perhaps replacing it by:> > "If subject naming information is prese= nt only in the subject name field> and the peer identity represents a host = or device the subject name field> SHOULD contain a CN RDN or serialNumber R= DN." =20 This looks ok. I think the analog for the server side is as follows: =20 "If subject naming information is present only in the subject namefield of = a server certificate, then the subject name fieldMUST contain a CN RDN or s= erialNumber RDN." =20 > It is RECOMMENDED that> when the peer identity represents a user the Subj= ect distinguished name> should not contain an emailAddress RDN, but rather = use the rfc822> SubjectAltName as described above."=20 Are we saying that the Subject DN should contain something other than an emailAddress RDN, or are we saying that it should not be present at all?=20 =20 The analog of the RFC 3280 language would appear to be the following: =20 "Conforming implementations generating new certificateswith network access = identifiers MUST use the rfc822Name in thesubject alternative name field to= describe such identities. Theuse of the subject name field to contain an = emailAddress RDNis deprecated, and MUST NOT be used." =20 This says that new certificates utilizing rfc822Names always use the subjec= tAltName field, rather than the subject DN. = --_4cceddee-4961-4010-9d53-1bb50521f940_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Joe Salowey

> Ok the text below seems to mandate rfc822 SubjectAltName in all ca= ses.
> How about just removing the reference to the emailAddress RDN = from that
> paragraph. Perhaps replacing it by:
>
> "If = subject naming information is present only in the subject name field
>= ; and the peer identity represents a host or device the subject name field<= BR>> SHOULD contain a CN RDN or serialNumber RDN."
 
This looks ok.  I think the analog for the server side is as follows:<= BR>  
"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 serialNumber RDN."
 
> It is RECOMMENDED that
> when the peer identity represents a use= r the Subject distinguished name
> should not contain an emailAddress= RDN, but rather use the rfc822
> SubjectAltName as described above."=

Are we saying that the Subject DN should contain something other than an emailAddress RDN, or are we saying that it should not be present at all?  
The analog of the RFC 3280 language would appear to be the following:
 
"Conforming implementations generating new certificates
with network acc= ess identifiers MUST use the rfc822Name in the
subject alternative name = field to describe such identities.  The
use of the subject name fie= ld to contain an emailAddress RDN
is deprecated, and MUST NOT be used."<= BR>  
This says that new certificates utilizing rfc822Names always use the subjec= tAltName field,
rather than the subject DN.

= --_4cceddee-4961-4010-9d53-1bb50521f940_-- --===============0268834952== 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 --===============0268834952==-- From emu-bounces@ietf.org Tue Jun 12 00:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxy0H-0006eF-Pu; Tue, 12 Jun 2007 00:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxy0G-0006eA-JJ for emu@ietf.org; Tue, 12 Jun 2007 00:29:12 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxy0G-0006L3-9I for emu@ietf.org; Tue, 12 Jun 2007 00:29:12 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2007 21:29:11 -0700 X-IronPort-AV: i="4.16,410,1175497200"; d="scan'208"; a="162924182:sNHT48842649" 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 l5C4TBmI014410; Mon, 11 Jun 2007 21:29:11 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5C4TB20018958; Tue, 12 Jun 2007 04:29:11 GMT 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); Mon, 11 Jun 2007 21:29:11 -0700 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] Issue: Encoding of NAIs within EAP-TLS certificates Date: Mon, 11 Jun 2007 21:29:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Thread-Index: AcesdAn/HO3ncXWmT822PxcI2hoPrwAAQO8A From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 12 Jun 2007 04:29:11.0476 (UTC) FILETIME=[39A32740:01C7ACAA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2164; t=1181622551; x=1182486551; 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]=20Issue=3A=20Encoding=20of=20NAIs=20within=20EA P-TLS=20certificates |Sender:=20; bh=29zbYbtURFu/Ku4L6t2qi4p8KXYoHHxHRU7Xh8iiGMA=; b=dQkHRIVdfgDQh0W2Mj3eZvC2NlUiqjqhpqDnOKjVvR20j1kbA0JwIP7aMX6zsNkIyTwCfhR/ oGD43mPHdTP87FejaWwFyLefiyDkE0LXlhZ+fIhmBZO/3V6P5XIX53Xs; 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: Monday, June 11, 2007 3:01 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates >=20 >=20 > Joe Salowey >=20 > > Ok the text below seems to mandate rfc822 SubjectAltName in=20 > all cases. > > How about just removing the reference to the emailAddress RDN from=20 > > that paragraph. Perhaps replacing it by: > >=20 > > "If subject naming information is present only in the subject name=20 > > field and the peer identity represents a host or device the subject=20 > > name field SHOULD contain a CN RDN or serialNumber RDN." > =20 > This looks ok. I think the analog for the server side is as follows: > =20 > "If subject naming information is present only in the subject=20 > name field of a server certificate, then the subject name=20 > field MUST contain a CN RDN or serialNumber RDN." > =20 [Joe] Should this be 'MUST' or 'SHOULD'? > > It is RECOMMENDED that > > when the peer identity represents a user the Subject distinguished=20 > > name should not contain an emailAddress RDN, but rather use=20 > the rfc822=20 > > SubjectAltName as described above." >=20 > Are we saying that the Subject DN should contain something=20 > other than an emailAddress RDN, or are we saying that it=20 > should not be present at all?=20 > =20 > The analog of the RFC 3280 language would appear to be the following: > =20 > "Conforming implementations generating new certificates with=20 > network access identifiers MUST use the rfc822Name in the=20 > subject alternative name field to describe such identities. =20 > The use of the subject name field to contain an emailAddress=20 > RDN is deprecated, and MUST NOT be used." > =20 > This says that new certificates utilizing rfc822Names always=20 > use the subjectAltName field, rather than the subject DN.=20 >=20 [Joe] OK this is for NAI. How about adding a sentence for non NAI identities. =20 "The subject name field MAY contain Runs for representing non-NAI identities." =20 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 12 00:31:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxy2o-0001Or-GO; Tue, 12 Jun 2007 00:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxy2n-0001Om-0d for emu@ietf.org; Tue, 12 Jun 2007 00:31:49 -0400 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 1Hxy2m-0006ds-La for emu@ietf.org; Tue, 12 Jun 2007 00:31:49 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2007 21:31:49 -0700 X-IronPort-AV: i="4.16,410,1175497200"; d="scan'208"; a="378585223:sNHT48714726" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5C4Vmkn025702; Mon, 11 Jun 2007 21:31:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5C4VmtV021745; Tue, 12 Jun 2007 04:31:48 GMT 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); Mon, 11 Jun 2007 21:31:47 -0700 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] Issue: Encoding of NAIs within EAP-TLS certificates Date: Mon, 11 Jun 2007 21:31:48 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Thread-Index: AcesdAn/HO3ncXWmT822PxcI2hoPrwAAQO8AAA1S6aA= From: "Joseph Salowey \(jsalowey\)" To: "Joseph Salowey \(jsalowey\)" , "Bernard Aboba" , X-OriginalArrivalTime: 12 Jun 2007 04:31:47.0803 (UTC) FILETIME=[96D0C2B0:01C7ACAA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2764; t=1181622708; x=1182486708; 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]=20Issue=3A=20Encoding=20of=20NAIs=20within=20EA P-TLS=20certificates |Sender:=20; bh=k2toaUce7rEmeU1MxFc0rJn0wjhbngJw9AORa0EyEGM=; b=0ncPraU1gE597m7iGRLZLjm9WdaIuHiQlN/n5WKyCTYpeInLs22iaiLGvwx8fHLdUWvAY/vz Qky+NGQsPLa/mgw5y8rzp/ZqMiecQdKv2fR5SAz4dKXP9tqSAKDxQ4T1; 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: c3a18ef96977fc9bcc21a621cbf1174b 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 Correcting error in text below:=20 > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > Sent: Monday, June 11, 2007 9:29 PM > To: Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates >=20 > =20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Monday, June 11, 2007 3:01 PM > > To: Joseph Salowey (jsalowey); emu@ietf.org > > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS=20 > certificates > >=20 > >=20 > > Joe Salowey > >=20 > > > Ok the text below seems to mandate rfc822 SubjectAltName in > > all cases. > > > How about just removing the reference to the emailAddress=20 > RDN from=20 > > > that paragraph. Perhaps replacing it by: > > >=20 > > > "If subject naming information is present only in the=20 > subject name=20 > > > field and the peer identity represents a host or device=20 > the subject=20 > > > name field SHOULD contain a CN RDN or serialNumber RDN." > > =20 > > This looks ok. I think the analog for the server side is=20 > as follows: > > =20 > > "If subject naming information is present only in the subject name=20 > > field of a server certificate, then the subject name field MUST=20 > > contain a CN RDN or serialNumber RDN." > > =20 > [Joe] Should this be 'MUST' or 'SHOULD'? >=20 > > > It is RECOMMENDED that > > > when the peer identity represents a user the Subject=20 > distinguished=20 > > > name should not contain an emailAddress RDN, but rather use > > the rfc822 > > > SubjectAltName as described above." > >=20 > > Are we saying that the Subject DN should contain something=20 > other than=20 > > an emailAddress RDN, or are we saying that it should not be=20 > present at=20 > > all? > > =20 > > The analog of the RFC 3280 language would appear to be the=20 > following: > > =20 > > "Conforming implementations generating new certificates=20 > with network=20 > > access identifiers MUST use the rfc822Name in the subject=20 > alternative=20 > > name field to describe such identities. > > The use of the subject name field to contain an emailAddress RDN is=20 > > deprecated, and MUST NOT be used." > > =20 > > This says that new certificates utilizing rfc822Names=20 > always use the=20 > > subjectAltName field, rather than the subject DN. > >=20 > [Joe] OK this is for NAI. How about adding a sentence for=20 > non NAI identities. =20 >=20 > "The subject name field MAY contain Runs for representing=20 > non-NAI identities." =20 >=20 s/Runs/RDNs > >=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 Jun 12 01:54:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxzKl-0002Ds-C4; Tue, 12 Jun 2007 01:54:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxzKj-0002Dh-Op for emu@ietf.org; Tue, 12 Jun 2007 01:54:25 -0400 Received: from bay0-omc2-s24.bay0.hotmail.com ([65.54.246.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxzKi-0001zu-6t for emu@ietf.org; Tue, 12 Jun 2007 01:54:25 -0400 Received: from BAY117-W8 ([207.46.8.43]) by bay0-omc2-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Jun 2007 22:54:23 -0700 Message-ID: X-Originating-IP: [24.16.66.58] From: Bernard Aboba To: Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Mon, 11 Jun 2007 22:54:23 -0700 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2007 05:54:23.0759 (UTC) FILETIME=[20CBA1F0:01C7ACB6] X-Spam-Score: 2.1 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 looks ok. I think the analog for the server side is as follows: > > =20 > > "If subject naming information is present only in the subject=20 > > name field of a server certificate, then the subject name=20 > > field MUST contain a CN RDN or serialNumber RDN." > > =20 > [Joe] Should this be 'MUST' or 'SHOULD'? Are there alternatives to the CN or serialNumber RDN? If so, then it proba= bly should be a 'SHOULD'. =20 > > > It is RECOMMENDED that > > > when the peer identity represents a user the Subject distinguished=20 > > > name should not contain an emailAddress RDN, but rather use=20 > > the rfc822=20 > > > SubjectAltName as described above." > >=20 > > Are we saying that the Subject DN should contain something=20 > > other than an emailAddress RDN, or are we saying that it=20 > > should not be present at all?=20 > > =20 > > The analog of the RFC 3280 language would appear to be the following: > > =20 > > "Conforming implementations generating new certificates with=20 > > network access identifiers MUST use the rfc822Name in the=20 > > subject alternative name field to describe such identities. =20 > > The use of the subject name field to contain an emailAddress=20 > > RDN is deprecated, and MUST NOT be used." > > =20 > > This says that new certificates utilizing rfc822Names always=20 > > use the subjectAltName field, rather than the subject DN.=20 > >=20 > [Joe] OK this is for NAI. How about adding a sentence for non NAI > identities. =20 >=20 > "The subject name field MAY contain RDNs for representing non-NAI > identities." =20 I think this raises the question of what a "non-NAI" identity is. Would th= is be an identity not expressible in the NAI syntax defined in RFC 4282? = I ask because a serialNumber RDN might well be expressable within the NAI s= yntax (e.g. if it only contains numbers, but no realm, that would be a vali= d NAI). =20 How about this?=20 Conforming implementations generating new certificates with network access identifiers MUST use the rfc822Name in the subject alternative name field to describe such identities. The use of the subject name field to contain an emailAddress RDN is deprecated, and MUST NOT be used. The subject name field MAY contain RDNs for representing identities not expressible using the NAI syntax defined in [RFC4282].=20 Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). If subject naming information is present only in the subject name field of a peer certificate and the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or serialNumber RDN. If subject naming information is present only in the subject name field of a server certificate, then the subject name field SHOULD contain a CN RDN or serialNumber RDN. It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids. If the Subject distinguished name is non-empty then it SHOULD be exported within the Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 12 14:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBUI-0006Pp-P6; Tue, 12 Jun 2007 14:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBUI-0006Pi-4o for emu@ietf.org; Tue, 12 Jun 2007 14:53:06 -0400 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 1HyBUH-0000nV-Ks for emu@ietf.org; Tue, 12 Jun 2007 14:53:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2007 11:53:05 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208"; a="493036324:sNHT59709166" 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 l5CIr4rq027341; Tue, 12 Jun 2007 11:53:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5CIr4tV024631; Tue, 12 Jun 2007 18:53:04 GMT 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, 12 Jun 2007 11:53:04 -0700 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] Issue: Encoding of NAIs within EAP-TLS certificates Date: Tue, 12 Jun 2007 11:53:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Thread-Index: AcestiffuUQggzFuTHCrCVCYM1bZNQAAWUow From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 12 Jun 2007 18:53:04.0472 (UTC) FILETIME=[E882AD80:01C7AD22] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4541; t=1181674384; x=1182538384; 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]=20Issue=3A=20Encoding=20of=20NAIs=20within=20EA P-TLS=20certificates |Sender:=20; bh=JxnG4NG8xajUvRqyNTuqVbL7Qv4MSbu7NcTVRNh4VW8=; b=o3qxIOc8LiqsOvHXPM9LP+K8Zjc2SPmWD1e48NGpsHPFoSgGSIWisCem8CflxRmmInFrHqdH YhdMl4fQ/ehGpWmM+SghFxC22bzOJe7gguSP4bxuzZyWXoEAjVszWN44; 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: 7fa173a723009a6ca8ce575a65a5d813 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: Monday, June 11, 2007 10:54 PM > To: emu@ietf.org > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates >=20 >=20 > > > This looks ok. I think the analog for the server side=20 > is as follows: > > > =20 > > > "If subject naming information is present only in the=20 > subject name=20 > > > field of a server certificate, then the subject name field MUST=20 > > > contain a CN RDN or serialNumber RDN." > > > =20 > > [Joe] Should this be 'MUST' or 'SHOULD'? >=20 > Are there alternatives to the CN or serialNumber RDN? If so,=20 > then it probably should be a 'SHOULD'. =20 >=20 > > > > It is RECOMMENDED that > > > > when the peer identity represents a user the Subject=20 > distinguished=20 > > > > name should not contain an emailAddress RDN, but rather use > > > the rfc822 > > > > SubjectAltName as described above." > > >=20 > > > Are we saying that the Subject DN should contain something other=20 > > > than an emailAddress RDN, or are we saying that it should not be=20 > > > present at all? > > > =20 > > > The analog of the RFC 3280 language would appear to be=20 > the following: > > > =20 > > > "Conforming implementations generating new certificates=20 > with network=20 > > > access identifiers MUST use the rfc822Name in the subject=20 > > > alternative name field to describe such identities. > > > The use of the subject name field to contain an=20 > emailAddress RDN is=20 > > > deprecated, and MUST NOT be used." > > > =20 > > > This says that new certificates utilizing rfc822Names=20 > always use the=20 > > > subjectAltName field, rather than the subject DN. > > >=20 > > [Joe] OK this is for NAI. How about adding a sentence for non NAI=20 > > identities. > >=20 > > "The subject name field MAY contain RDNs for representing non-NAI=20 > > identities." >=20 > I think this raises the question of what a "non-NAI" identity=20 > is. Would this be an identity not expressible in the NAI=20 > syntax defined in RFC 4282? I ask because a serialNumber=20 > RDN might well be expressable within the NAI syntax (e.g. if=20 > it only contains numbers, but no realm, that would be a valid NAI). =20 >=20 [Joe] An NAI represents a specific type of identity. A certificate may contain other types of identities that may not be NAIs. Just because it fits a particular format does not mean that it is an NAI.=20 > How about this?=20 >=20 > Conforming implementations generating new certificates > with network access identifiers MUST use the rfc822Name in the > subject alternative name field to describe such=20 > identities. The use > of the subject name field to contain an emailAddress RDN is > deprecated, and MUST NOT be used. The subject name field > MAY contain RDNs for representing identities not expressible > using the NAI syntax defined in [RFC4282].=20 >=20 [Joe] I think the main issue is emailAddress should not be used and anything that you would put in the emailAddress RDN should go in the SubjectaltName of type rfc822Name instead. Other parts of the subject name should be allowed. =20 "The subject name field MAY contain other RDNs for representing the subject's identity."=20 > Where it is non-empty, the subject name field MUST contain an X.500 > distinguished name (DN). If subject naming information is present > only in the subject name field of a peer certificate and the peer > identity represents a host or device the subject name field SHOULD > contain a CN RDN or serialNumber RDN. If subject naming=20 > information > is present only in the subject name field of a server certificate, > then the subject name field SHOULD contain a CN RDN or serialNumber > RDN. >=20 > It is possible for more than one subjectAltName field to be present > in a peer or server certificate in addition to an empty or=20 > non-empty > subject distinguished name. EAP-TLS implementations SHOULD export > all the subjectAltName fields within Peer-Ids or=20 > Server-Ids. If the > Subject distinguished name is non-empty then it SHOULD be exported > within the Peer-Ids or Server-Ids. All of the exported=20 > Peer-Ids and > Server-Ids are considered valid. >=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 Jun 12 18:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyFIQ-0003Wh-QS; Tue, 12 Jun 2007 18:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyFIP-0003Wc-Ez for emu@ietf.org; Tue, 12 Jun 2007 18:57:05 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyFIO-0005WQ-5i for emu@ietf.org; Tue, 12 Jun 2007 18:57:05 -0400 Received: from BAY117-W2 ([207.46.8.37]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 12 Jun 2007 15:57:03 -0700 Message-ID: X-Originating-IP: [131.107.0.74] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Date: Tue, 12 Jun 2007 15:57:03 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2007 22:57:03.0778 (UTC) FILETIME=[FE378020:01C7AD44] X-Spam-Score: 2.6 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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="===============1695419424==" Errors-To: emu-bounces@ietf.org --===============1695419424== Content-Type: multipart/alternative; boundary="_b9ae3755-28e4-4eac-a9a9-b825e5fd41e2_" --_b9ae3755-28e4-4eac-a9a9-b825e5fd41e2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > [Joe] I think the main issue is emailAddress should not be used and> anyt= hing that you would put in the emailAddress RDN should go in the> Subjectal= tName of type rfc822Name instead. Other parts of the subject> name should b= e allowed. > > "The subject name field MAY contain other RDNs for represent= ing the> subject's identity."=20 =20 This seems unambiguous, because an emailAddress RDN is required to include = both a username and realm portion.=20 =20 So effectively we are saying that an NAI needs to include both username and= realm to qualify; a serial number, for example, would not qualify. = --_b9ae3755-28e4-4eac-a9a9-b825e5fd41e2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > [Joe] I think the main issue is emailAddress should not be used and> anything that you would put in the emailAddress RDN should go in the<= BR>> SubjectaltName of type rfc822Name instead. Other parts of the subje= ct
> name should be allowed.
>
> "The subject name fiel= d MAY contain other RDNs for representing the
> subject's identity." =
 
This seems unambiguous, because an emailAddress RDN is required to include = both a username and realm portion.
 
So effectively we are saying that an NAI needs to include both username and= realm to qualify;  a serial number, for example, would not qualify. <= BR> = --_b9ae3755-28e4-4eac-a9a9-b825e5fd41e2_-- --===============1695419424== 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 --===============1695419424==-- From emu-bounces@ietf.org Wed Jun 13 00:15:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyKGp-0003y3-Kj; Wed, 13 Jun 2007 00:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyKGo-0003pR-Gx for emu@ietf.org; Wed, 13 Jun 2007 00:15:46 -0400 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 1HyKGn-0007sL-56 for emu@ietf.org; Wed, 13 Jun 2007 00:15:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2007 21:15:45 -0700 X-IronPort-AV: i="4.16,414,1175497200"; d="scan'208"; a="378875066:sNHT47281370" 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 l5D4FirJ031691; Tue, 12 Jun 2007 21:15:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5D4FiaI013338; Wed, 13 Jun 2007 04:15:44 GMT 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); Tue, 12 Jun 2007 21:15:44 -0700 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] Issue: Encoding of NAIs within EAP-TLS certificates Date: Tue, 12 Jun 2007 21:15:46 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates Thread-Index: AcetRP+JTNgs6q6iRiiis97Se+N1NgALA1/Q From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 13 Jun 2007 04:15:44.0392 (UTC) FILETIME=[82FDA880:01C7AD71] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1185; t=1181708144; x=1182572144; 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]=20Issue=3A=20Encoding=20of=20NAIs=20within=20EA P-TLS=20certificates |Sender:=20; bh=sMa/bl8kKPRfgIBQEl3VTYlHxmVyJaki10pGx39P5jk=; b=HGCSxNPKnh+zA7nbu7wz0V8L2oEBuuHnSxaIMap0MGR4eIgaUZOZbx0/LiET7VEQSchTjJDr as+8Os5CoOfVmQOWGHYkZk8d+h/3ijwX/nQLJqX8C+/g+SWrH5/5GudG; 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: e5ba305d0e64821bf3d8bc5d3bb07228 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: Tuesday, June 12, 2007 3:57 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates >=20 > > [Joe] I think the main issue is emailAddress should not be used and=20 > > anything that you would put in the emailAddress RDN should=20 > go in the=20 > > SubjectaltName of type rfc822Name instead. Other parts of=20 > the subject=20 > > name should be allowed. > >=20 > > "The subject name field MAY contain other RDNs for representing the=20 > > subject's identity." > =20 > This seems unambiguous, because an emailAddress RDN is=20 > required to include both a username and realm portion.=20 > =20 > So effectively we are saying that an NAI needs to include=20 > both username and realm to qualify; a serial number, for=20 > example, would not qualify.=20 >=20 [Joe] In general, yes. Also a certificate may have identities representing the same entity for different purposes some of which may use an NAI, some that may be related to an NAI and some that are independent of NAI. =20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Jun 15 03:18:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz64W-0004Q3-IT; Fri, 15 Jun 2007 03:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz64V-0004Px-Ki for emu@ietf.org; Fri, 15 Jun 2007 03:18:15 -0400 Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hz64S-0004l5-8x for emu@ietf.org; Fri, 15 Jun 2007 03:18:15 -0400 Received: (qmail 61503 invoked by uid 60001); 15 Jun 2007 07:18:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=TV32M/yIiW/cLp3+fq7v8dqzf56KZOgzUtk2VYhr4MqSn6cmSCWZ77Q5sBcrtjQx3kA8boSz0dA5rhR+bkM+4nThxwLEIGcimMMMadb0WSVW7s+ombaL9jxYXpnLPOggqQ57AvpwuLGzz4UJvig6GwrhSsly3pTNVCbHJ1Ey5Cs=; X-YMail-OSG: ic6oSRMVM1nUtomEm5F6Ww4MFqyR672Bt9oi7D6qgcUslCDn06u2tBcCF4v3LgjE6qJOxjEpj4Epl8gdpupCejg4H2qRM2Y1Ud.d5PXz1du_bT0- Received: from [24.16.90.95] by web81903.mail.mud.yahoo.com via HTTP; Fri, 15 Jun 2007 00:18:11 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.14 Date: Fri, 15 Jun 2007 00:18:11 -0700 (PDT) From: gabriel montenegro To: emu@ietf.org MIME-Version: 1.0 Message-ID: <835656.59480.qm@web81903.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Bernard Aboba Subject: [Emu] Multiple Peer-IDs and Server-IDs 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="===============0335863222==" Errors-To: emu-bounces@ietf.org --===============0335863222== Content-Type: multipart/alternative; boundary="0-819490596-1181891891=:59480" --0-819490596-1181891891=:59480 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Looking at http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-10.= txt=0AI have some comments.=0A=0AI think that the whole discussion about mu= ltiple Peer and Server-IDs could be reflected better in =0Asection 5.2 (las= t paragraph):=0A =0AOLD:=0A It is possible for more than one subjectAltNa= me field to be present=0A in a peer or server certificate in addition to = an empty or non-empty=0A subject distinguished name. EAP-TLS implementat= ions SHOULD export=0A all the subjectAltName fields within Peer-Ids or Se= rver-Ids. If the=0A Subject distinguished name is non-empty then it SHOU= LD be exported=0A within the Peer-Ids or Server-Ids. All of the exported= Peer-Ids and=0A Server-Ids are considered valid.=0A =0AIt=A2s good that = all available the IDs are being exported, but perhaps=0Awe should impose a = canonical ordering of those multiple =0Aidentities. For example by adding "= ...in the same order in which they=0Aappear within the certificate":=0A =0A= NEW:=0A It is possible for more than one subjectAltName field to be prese= nt=0A in a peer or server certificate in addition to an empty or non-empt= y=0A subject distinguished name. EAP-TLS implementations SHOULD export= =0A all the subjectAltName fields within Peer-Ids or Server-Ids in the sa= me =0A order in which they appear within the certificate. If the=0A Su= bject distinguished name is non-empty then it SHOULD be exported=0A withi= n the Peer-Ids or Server-Ids. All of the exported Peer-Ids and=0A Server= -Ids are considered valid.=0A =0ASuch canonical ordering would aid in compa= rison operations and would enable using =0Athose IDs for key derivation if = that is deemed useful later on.=0A =0A-gabriel=0A --0-819490596-1181891891=:59480 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Looking at http://www.drizzle.c= om/~aboba/EMU/draft-simon-emu-rfc2716bis-10.txt
I have some c= omments.

I think that the whole discussion about multiple Peer and S= erver-IDs could be reflected better in
section 5.2 (last paragraph): 
OLD:
   It is possible for more than one subjectAlt= Name field to be present
   in a peer or server certificate in= addition to an empty or non-empty
   subject distinguished na= me.  EAP-TLS implementations SHOULD export
   all the sub= jectAltName fields within Peer-Ids or Server-Ids.  If the
 &nb= sp; Subject distinguished name is non-empty then it SHOULD be exported
&= nbsp;  within the Peer-Ids or Server-Ids.  All of the exported Peer-Ids and
&nbs= p;  Server-Ids are considered valid.
 
It=A2s good that all= available the IDs are being exported, but perhaps
we should impose a ca= nonical ordering of those multiple
identities. For example by adding ".= ..in the same order in which they
appear within the certificate":
&nb= sp;
NEW:
   It is possible for more than one subjectAltName= field to be present
   in a peer or server certificate in add= ition to an empty or non-empty
   subject distinguished name.&= nbsp; EAP-TLS implementations SHOULD export
   all the subject= AltName fields within Peer-Ids or Server-Ids in the same
   o= rder in which they appear within the certificate.  If the
 &nb= sp; Subject distinguished name is non-empty then it SHOULD be exported
&= nbsp;  within the Peer-Ids or Server-Ids.  All of the exported Pe= er-Ids and
   Server-Ids are considered valid.
 
Such can= onical ordering would aid in comparison operations and would enable using <= br>those IDs for key derivation if that is deemed useful later on.
 = ;
-gabriel
 
--0-819490596-1181891891=:59480-- --===============0335863222== 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 --===============0335863222==-- From emu-bounces@ietf.org Mon Jun 18 22:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Tn9-0003Pw-Cu; Mon, 18 Jun 2007 22:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Tn8-0003Pr-8a for emu@ietf.org; Mon, 18 Jun 2007 22:50:02 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Tn7-0007I1-Nn for emu@ietf.org; Mon, 18 Jun 2007 22:50:02 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2007 04:50:01 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5J2o1tD028781 for ; Tue, 19 Jun 2007 04:50:01 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5J2o0DR001475 for ; Tue, 19 Jun 2007 02:50:00 GMT Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 04:50:00 +0200 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); Mon, 18 Jun 2007 19:49:58 -0700 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: Mon, 18 Jun 2007 19:50:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2007-8: First Call for Volunteers Thread-Index: AcenCSqc62IAXsvAReuC7Bq54Gv9MgLEydJQ From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 19 Jun 2007 02:49:58.0020 (UTC) FILETIME=[85FE1C40:01C7B21C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3916; t=1182221401; x=1183085401; c=relaxed/simple; s=amsdkim1002; 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:=20FW=3A=20Nomcom=202007-8=3A=20First=20Call=20for=20Volunteers |Sender:=20; bh=2lm6hYajVs8Rp4P7M+20ghZqEEIAKqdkgH/lQ2JoYMM=; b=Psfq4H8fwzjsS4xtfNmo9wdnypi7RGnlXVOntKQaHZbblBvIaU/doyrln+2w7V6suJoEvy53 xn/x9FapOHOtiv5D2EballQPlyMtgxwF27lTCKp98JyO6QsMKvgDg88i; Authentication-Results: ams-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Emu] FW: Nomcom 2007-8: First Call for Volunteers 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 Please consider participating in the Nomcom process.=20 -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 Sent: Monday, June 04, 2007 5:32 PM To: ietf-announce@ietf.org Subject: Nomcom 2007-8: First Call for Volunteers Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 19 13:58:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hyl-0001Nt-CK; Tue, 19 Jun 2007 13:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hyj-0001No-PU for emu@ietf.org; Tue, 19 Jun 2007 13:58:57 -0400 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 1I0hyi-0003Na-FX for emu@ietf.org; Tue, 19 Jun 2007 13:58:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2007 10:58:56 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="495762343:sNHT41512858" 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 l5JHwt3T021054 for ; Tue, 19 Jun 2007 10:58:55 -0700 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 l5JHwf2Y025933 for ; Tue, 19 Jun 2007 17:58:55 GMT 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); Tue, 19 Jun 2007 10:58:47 -0700 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: Tue, 19 Jun 2007 10:58:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Corrected 802.11u liaison documents now available Thread-Index: Aceym31X1vfbhj/5RXicYlMY+gEtrw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 19 Jun 2007 17:58:47.0623 (UTC) FILETIME=[7C2B3570:01C7B29B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=365; t=1182275935; x=1183139935; 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:=20Corrected=20802.11u=20liaison=20documents=20now=20available |Sender:=20; bh=guF3W2OiCDwiaOFLXme48Wt7G34gHfA96+4CWMtpNxc=; b=mkKhm3zahmtalxdF9tXYfDU2RLGr55J00d8CmDzXw6pSnKukQN8gydPox4af6Nck9M4q6J0J XzFb9glLnFz8okWievjy26rEdQ2ThyO4BZvDxxK7dEYSa/vpmaD9c/tU; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Emu] Corrected 802.11u liaison documents now available 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 documents for the May 802.11u liaison statement are now available on the IETF liaison web site: https://datatracker.ietf.org/public/liaisons.cgi In particular the requirements presentation is now correct: https://datatracker.ietf.org/documents/LIAISON/file446.ppt Liaison Attachment: EAP Method Requirements for Emergency Services Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 19 14:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iVu-0004Hw-Az; Tue, 19 Jun 2007 14:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iVs-0004Gy-TS for emu@ietf.org; Tue, 19 Jun 2007 14:33:12 -0400 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 1I0iVr-00025K-I4 for emu@ietf.org; Tue, 19 Jun 2007 14:33:12 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2007 11:33:10 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="495777996:sNHT58257330" 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 l5JIXAKa012193; Tue, 19 Jun 2007 11:33:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5JIX5aO004851; Tue, 19 Jun 2007 18:33:06 GMT 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); Tue, 19 Jun 2007 11:33:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs Date: Tue, 19 Jun 2007 11:33:08 -0700 Message-ID: In-Reply-To: <835656.59480.qm@web81903.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple Peer-IDs and Server-IDs Thread-Index: AcevHV5PAdplgtYmSB+9goiX4I0oBgDgaFzg From: "Joseph Salowey \(jsalowey\)" To: "gabriel montenegro" , X-OriginalArrivalTime: 19 Jun 2007 18:33:05.0656 (UTC) FILETIME=[46DA1F80:01C7B2A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2773; t=1182277990; x=1183141990; 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]=20Multiple=20Peer-IDs=20and=20Server-IDs |Sender:=20; bh=+FMXwwFtmH6Ccz4//D6cFTDxpIp/sMfGqMmTOMLbOOE=; b=NWVjHo5oUVkQzzw/4j+E9a2mEznAepw7U+z32N+FianeGZK3PVF6SJQDMO1UD4FZHPHaIt82 dSdeG7jsyUJ4B7gZpAKApnxJ76AWWOrecflc5xP/OLGj/y0MGuF3CUdm; 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: 92df29fa99cf13e554b84c8374345c17 Cc: Bernard Aboba 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'm not so sure that it is a good idea to rely upon the order of = attributes in a cert. The default behavior is that all names are valid. = If you are looking for different behavior then you need more information = than ordering to account for cases where an expected name is missing or = the CA does not impose a particular order. =20 I agree that order may be useful if you are using this information in = key derivation. =20 If we include this text we should explicitly define where the subject = name goes in the list (at the end?) and caution against depending on = order for access control.=20 Cheers, Joe > -----Original Message----- > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com]=20 > Sent: Friday, June 15, 2007 12:18 AM > To: emu@ietf.org > Cc: Bernard Aboba > Subject: [Emu] Multiple Peer-IDs and Server-IDs >=20 > Looking at=20 > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1 > 0.txt=20 > s-10.txt> > I have some comments. >=20 > I think that the whole discussion about multiple Peer and=20 > Server-IDs could be reflected better in section 5.2 (last paragraph): > =20 > OLD: > It is possible for more than one subjectAltName field to be present > in a peer or server certificate in addition to an empty or=20 > non-empty > subject distinguished name. EAP-TLS implementations SHOULD export > all the subjectAltName fields within Peer-Ids or=20 > Server-Ids. If the > Subject distinguished name is non-empty then it SHOULD be exported > within the Peer-Ids or Server-Ids. All of the exported=20 > Peer-Ids and > Server-Ids are considered valid. > =20 > It=A2s good that all available the IDs are being exported, but=20 > perhaps we should impose a canonical ordering of those=20 > multiple identities. For example by adding "...in the same=20 > order in which they appear within the certificate": > =20 > NEW: > It is possible for more than one subjectAltName field to be present > in a peer or server certificate in addition to an empty or=20 > non-empty > subject distinguished name. EAP-TLS implementations SHOULD export > all the subjectAltName fields within Peer-Ids or=20 > Server-Ids in the same=20 > order in which they appear within the certificate. If the > Subject distinguished name is non-empty then it SHOULD be exported > within the Peer-Ids or Server-Ids. All of the exported=20 > Peer-Ids and > Server-Ids are considered valid. > =20 > Such canonical ordering would aid in comparison operations=20 > and would enable using those IDs for key derivation if that=20 > is deemed useful later on. > =20 > -gabriel > =20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jun 19 15:01:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ixL-0006Nv-Fw; Tue, 19 Jun 2007 15:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ixK-0006Nm-DX for emu@ietf.org; Tue, 19 Jun 2007 15:01:34 -0400 Received: from bay0-omc2-s29.bay0.hotmail.com ([65.54.246.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ixI-0006am-Om for emu@ietf.org; Tue, 19 Jun 2007 15:01:34 -0400 Received: from BAY117-W22 ([207.46.8.57]) by bay0-omc2-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Jun 2007 12:01:32 -0700 Message-ID: X-Originating-IP: [131.107.0.72] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , gabriel montenegro , Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs Date: Tue, 19 Jun 2007 12:01:32 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2007 19:01:32.0171 (UTC) FILETIME=[4003A5B0:01C7B2A4] X-Spam-Score: 2.4 (++) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Bernard Aboba 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="===============0808757150==" Errors-To: emu-bounces@ietf.org --===============0808757150== Content-Type: multipart/alternative; boundary="_43a466ba-4edb-4043-9fb3-06d64b78205f_" --_43a466ba-4edb-4043-9fb3-06d64b78205f_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable I'm not sure about defining the location of the subject name field, beyond = what is covered in RFC 3280. I agree about the caution on utilizing orderi= ng for access control. How about: =20 "It is possible for more than one subjectAltName field to be presentin a pe= er or server certificate in addition to an empty or non-emptysubject distin= guished name. EAP-TLS implementations SHOULD exportall the subjectAltName f= ields within Peer-Ids or Server-Ids in the same order in which they appear = within the certificate. If theSubject distinguished name is non-empty then = it SHOULD be exportedwithin the Peer-Ids or Server-Ids. All of the exported= Peer-Ids andServer-Ids are considered valid. Such canonical ordering would= aid in comparison operations and would enable using those IDs for key deri= vation if that is deemed useful later on. However, the ordering of fields = within the certificate SHOULD NOT be used for access control." =20 > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs> Date: Tue, 19 Jun 20= 07 11:33:08 -0700> From: jsalowey@cisco.com> To: g_e_montenegro@yahoo.com; = emu@ietf.org> CC: aboba@internaut.com> > I'm not so sure that it is a good = idea to rely upon the order of attributes in a cert. The default behavior i= s that all names are valid. If you are looking for different behavior then = you need more information than ordering to account for cases where an expec= ted name is missing or the CA does not impose a particular order. > > I agr= ee that order may be useful if you are using this information in key deriva= tion. > > If we include this text we should explicitly define where the sub= ject name goes in the list (at the end?) and caution against depending on o= rder for access control. > > Cheers,> > Joe> > > -----Original Message-----= > > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > > Sent: Fr= iday, June 15, 2007 12:18 AM> > To: emu@ietf.org> > Cc: Bernard Aboba> > Su= bject: [Emu] Multiple Peer-IDs and Server-IDs> > > > Looking at > > http://= www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1> > 0.txt > > > s-10.txt>> > I = have some comments.> > > > I think that the whole discussion about multiple= Peer and > > Server-IDs could be reflected better in section 5.2 (last par= agraph):> > > > OLD:> > It is possible for more than one subjectAltName fie= ld to be present> > in a peer or server certificate in addition to an empty= or > > non-empty> > subject distinguished name. EAP-TLS implementations SH= OULD export> > all the subjectAltName fields within Peer-Ids or > > Server-= Ids. If the> > Subject distinguished name is non-empty then it SHOULD be ex= ported> > within the Peer-Ids or Server-Ids. All of the exported > > Peer-I= ds and> > Server-Ids are considered valid.> > > > It=A2s good that all avai= lable the IDs are being exported, but > > perhaps we should impose a canoni= cal ordering of those > > multiple identities. For example by adding "...in= the same > > order in which they appear within the certificate":> > > > NE= W:> > It is possible for more than one subjectAltName field to be present> = > in a peer or server certificate in addition to an empty or > > non-empty>= > subject distinguished name. EAP-TLS implementations SHOULD export> > all= the subjectAltName fields within Peer-Ids or > > Server-Ids in the same > = > order in which they appear within the certificate. If the> > Subject dist= inguished name is non-empty then it SHOULD be exported> > within the Peer-I= ds or Server-Ids. All of the exported > > Peer-Ids and> > Server-Ids are co= nsidered valid.> > > > Such canonical ordering would aid in comparison oper= ations > > and would enable using those IDs for key derivation if that > > = is deemed useful later on.> > > > -gabriel> > > > > > _____________________= __________________________> Emu mailing list> Emu@ietf.org> https://www1.ie= tf.org/mailman/listinfo/emu= --_43a466ba-4edb-4043-9fb3-06d64b78205f_ Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable I'm not sure about defining the location of the subject name field, beyond = what is covered in RFC 3280.  I agree about the caution on utilizing o= rdering for access control.  How about:
 
"It is possible for more than one subjectAltName field to be present
in = a peer or server certificate in addition to an empty or non-empty
subjec= t distinguished name. EAP-TLS implementations SHOULD export
all the subj= ectAltName fields within Peer-Ids or Server-Ids in the same
order in wh= ich they appear within the certificate. If the
Subject distinguished nam= e is non-empty then it SHOULD be exported
within the Peer-Ids or Server-= Ids. All of the exported Peer-Ids and
Server-Ids are considered valid. 
Such canonical ordering would aid in comparison operations
= and would enable using those IDs for key derivation if that
is deemed u= seful later on.  However, the ordering of fields within
the certificate SHOULD NOT be used for access control."

 


> Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
> Da= te: Tue, 19 Jun 2007 11:33:08 -0700
> From: jsalowey@cisco.com
>= ; To: g_e_montenegro@yahoo.com; emu@ietf.org
> CC: aboba@internaut.co= m
>
> I'm not so sure that it is a good idea to rely upon the = order of attributes in a cert. The default behavior is that all names are v= alid. If you are looking for different behavior then you need more informat= ion than ordering to account for cases where an expected name is missing or= the CA does not impose a particular order.
>
> I agree that = order may be useful if you are using this information in key derivation. >
> If we include this text we should explicitly define where t= he subject name goes in the list (at the end?) and caution against dependin= g on order for access control.
>
> Cheers,
>
> J= oe
>
> > -----Original Message-----
> > From: gabr= iel montenegro [mailto:g_e_montenegro@yahoo.com]
> > Sent: Friday= , June 15, 2007 12:18 AM
> > To: emu@ietf.org
> > Cc: Ber= nard Aboba
> > Subject: [Emu] Multiple Peer-IDs and Server-IDs
= > >
> > Looking at
> > http://www.drizzle.com/~ab= oba/EMU/draft-simon-emu-rfc2716bis-1
> > 0.txt
> > <h= ttp://www.drizzle.com/%7Eaboba/EMU/draft-simon-emu-rfc2716bi
> > s= -10.txt>
> > I have some comments.
> >
> > I= think that the whole discussion about multiple Peer and
> > Serv= er-IDs could be reflected better in section 5.2 (last paragraph):
> &= gt;
> > OLD:
> > It is possible for more than one subjec= tAltName field to be present
> > in a peer or server certificate i= n addition to an empty or
> > non-empty
> > subject dist= inguished name. EAP-TLS implementations SHOULD export
> > all the = subjectAltName fields within Peer-Ids or
> > Server-Ids. If the> > Subject distinguished name is non-empty then it SHOULD be expor= ted
> > within the Peer-Ids or Server-Ids. All of the exported > > Peer-Ids and
> > Server-Ids are considered valid.
&g= t; >
> > It=A2s good that all available the IDs are being expo= rted, but
> > perhaps we should impose a canonical ordering of th= ose
> > multiple identities. For example by adding "...in the sam= e
> > order in which they appear within the certificate":
>= >
> > NEW:
> > It is possible for more than one subj= ectAltName field to be present
> > in a peer or server certificate= in addition to an empty or
> > non-empty
> > subject di= stinguished name. EAP-TLS implementations SHOULD export
> > all th= e subjectAltName fields within Peer-Ids or
> > Server-Ids in the = same
> > order in which they appear within the certificate. If th= e
> > Subject distinguished name is non-empty then it SHOULD be ex= ported
> > within the Peer-Ids or Server-Ids. All of the exported =
> > Peer-Ids and
> > Server-Ids are considered valid.> >
> > Such canonical ordering would aid in comparison op= erations
> > and would enable using those IDs for key derivation = if that
> > is deemed useful later on.
> >
> >= -gabriel
> >
> >
>
> ____________________= ___________________________
> Emu mailing list
> Emu@ietf.org> https://www1.ietf.org/mailman/listinfo/emu

= --_43a466ba-4edb-4043-9fb3-06d64b78205f_-- --===============0808757150== 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 --===============0808757150==-- From emu-bounces@ietf.org Tue Jun 19 16:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kBt-0008IE-NH; Tue, 19 Jun 2007 16:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kBs-0008HE-4i for emu@ietf.org; Tue, 19 Jun 2007 16:20:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kBo-0006WF-Tf for emu@ietf.org; Tue, 19 Jun 2007 16:20:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2007 13:20:36 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="168253293:sNHT64639503" 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 l5JKKamf016347; Tue, 19 Jun 2007 13:20:36 -0700 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 l5JKK52Y011314; Tue, 19 Jun 2007 20:20:36 GMT 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, 19 Jun 2007 13:20:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs Date: Tue, 19 Jun 2007 13:20:31 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple Peer-IDs and Server-IDs Thread-Index: AceypECrWYtkG979RhizoU2wGyPDlAABm1kQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , "gabriel montenegro" , X-OriginalArrivalTime: 19 Jun 2007 20:20:29.0306 (UTC) FILETIME=[479115A0:01C7B2AF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5102; t=1182284436; x=1183148436; 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]=20Multiple=20Peer-IDs=20and=20Server-IDs |Sender:=20; bh=7EnpPYrcn0GdHM3dAzguOLIqyGdBfzI6K96/Bne2Ars=; b=ku0ClU30cW3qZIqspQ4pdzjuFxGlimccjYfo/ZSAc4B4PFBkQdxOF+Yuw3T/Fj8twi0LReJU vR6/lD2r5us416se2NOEQhb51L6s34dpIMmFWftHIXpvqsMwMX/OwavE+GFvdUSwf6eapFCdAR 4rJ9aiA0QbytYvWRSC+2HZUMI=; 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: 2beba50d0fcdeee5f091c59f204d4365 Cc: Bernard Aboba 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: Tuesday, June 19, 2007 12:02 PM > To: Joseph Salowey (jsalowey); gabriel montenegro; emu@ietf.org > Cc: Bernard Aboba > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs >=20 > I'm not sure about defining the location of the subject name=20 > field, beyond what is covered in RFC 3280. I agree about the=20 > caution on utilizing ordering for access control. How about: > =20 [Joe] OK, but in the text below the ordering seems to apply to the = subjectAltNames and is ambiguous as to whether it applies to = SubjectAltName. Maybe the bit about the order should be at the end of = the paragraph: "Peer and Server IDs SHOULD be exported in the same order in which they = appear in the certificate." > "It is possible for more than one subjectAltName field to be=20 > present in a peer or server certificate in addition to an=20 > empty or non-empty subject distinguished name. EAP-TLS=20 > implementations SHOULD export all the subjectAltName fields=20 > within Peer-Ids or Server-Ids in the same order in which they=20 > appear within the certificate. If the Subject distinguished=20 > name is non-empty then it SHOULD be exported within the=20 > Peer-Ids or Server-Ids. All of the exported Peer-Ids and=20 > Server-Ids are considered valid. > =20 > Such canonical ordering would aid in comparison operations=20 > and would enable using those IDs for key derivation if that=20 > is deemed useful later on. However, the ordering of fields=20 > within the certificate SHOULD NOT be used for access control." >=20 [Joe] sounds good. > =20 >=20 >=20 > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > Date: Tue, 19 Jun 2007 11:33:08 -0700 > > From: jsalowey@cisco.com > > To: g_e_montenegro@yahoo.com; emu@ietf.org > > CC: aboba@internaut.com > >=20 > > I'm not so sure that it is a good idea to rely upon the=20 > order of attributes in a cert. The default behavior is that=20 > all names are valid. If you are looking for different=20 > behavior then you need more information than ordering to=20 > account for cases where an expected name is missing or the CA=20 > does not impose a particular order.=20 > >=20 > > I agree that order may be useful if you are using this=20 > information in key derivation.=20 > >=20 > > If we include this text we should explicitly define where=20 > the subject name goes in the list (at the end?) and caution=20 > against depending on order for access control.=20 > >=20 > > Cheers, > >=20 > > Joe > >=20 > > > -----Original Message----- > > > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com]=20 > > > Sent: Friday, June 15, 2007 12:18 AM > > > To: emu@ietf.org > > > Cc: Bernard Aboba > > > Subject: [Emu] Multiple Peer-IDs and Server-IDs > > >=20 > > > Looking at=20 > > > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1 > > > 0.txt=20 > > > > > s-10.txt> > > > I have some comments. > > >=20 > > > I think that the whole discussion about multiple Peer and=20 > > > Server-IDs could be reflected better in section 5.2 (last=20 > paragraph): > > >=20 > > > OLD: > > > It is possible for more than one subjectAltName field to=20 > be present > > > in a peer or server certificate in addition to an empty or=20 > > > non-empty > > > subject distinguished name. EAP-TLS implementations SHOULD export > > > all the subjectAltName fields within Peer-Ids or=20 > > > Server-Ids. If the > > > Subject distinguished name is non-empty then it SHOULD be exported > > > within the Peer-Ids or Server-Ids. All of the exported=20 > > > Peer-Ids and > > > Server-Ids are considered valid. > > >=20 > > > It=A2s good that all available the IDs are being exported, but=20 > > > perhaps we should impose a canonical ordering of those=20 > > > multiple identities. For example by adding "...in the same=20 > > > order in which they appear within the certificate": > > >=20 > > > NEW: > > > It is possible for more than one subjectAltName field to=20 > be present > > > in a peer or server certificate in addition to an empty or=20 > > > non-empty > > > subject distinguished name. EAP-TLS implementations SHOULD export > > > all the subjectAltName fields within Peer-Ids or=20 > > > Server-Ids in the same=20 > > > order in which they appear within the certificate. If the > > > Subject distinguished name is non-empty then it SHOULD be exported > > > within the Peer-Ids or Server-Ids. All of the exported=20 > > > Peer-Ids and > > > Server-Ids are considered valid. > > >=20 > > > Such canonical ordering would aid in comparison operations=20 > > > and would enable using those IDs for key derivation if that=20 > > > is deemed useful later on. > > >=20 > > > -gabriel > > >=20 > > >=20 > >=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 Jun 19 17:08:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kwV-00048V-Hn; Tue, 19 Jun 2007 17:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kwU-00048Q-OA for emu@ietf.org; Tue, 19 Jun 2007 17:08:50 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kwL-0003Wc-Df for emu@ietf.org; Tue, 19 Jun 2007 17:08:50 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 19 Jun 2007 14:07:16 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.726.0; Tue, 19 Jun 2007 14:08:35 -0700 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.3959); Tue, 19 Jun 2007 14:08:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs Date: Tue, 19 Jun 2007 14:07:28 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004C9AB57@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple Peer-IDs and Server-IDs Thread-Index: AceypECrWYtkG979RhizoU2wGyPDlAABm1kQAALKiW4= References: From: Ryan Hurst To: "Joseph Salowey (jsalowey)" , Bernard Aboba , gabriel montenegro , X-OriginalArrivalTime: 19 Jun 2007 21:08:35.0249 (UTC) FILETIME=[FFB90A10:01C7B2B5] X-Spam-Score: 0.5 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: Bernard Aboba 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="===============1569737002==" Errors-To: emu-bounces@ietf.org --===============1569737002== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B2B5.E8E38808" ------_=_NextPart_001_01C7B2B5.E8E38808 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think these changes are good. ________________________________ From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Tue 6/19/2007 1:20 PM To: Bernard Aboba; gabriel montenegro; emu@ietf.org Cc: Bernard Aboba Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, June 19, 2007 12:02 PM > To: Joseph Salowey (jsalowey); gabriel montenegro; emu@ietf.org > Cc: Bernard Aboba > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > I'm not sure about defining the location of the subject name > field, beyond what is covered in RFC 3280. I agree about the > caution on utilizing ordering for access control. How about: >=20 [Joe] OK, but in the text below the ordering seems to apply to the = subjectAltNames and is ambiguous as to whether it applies to = SubjectAltName. Maybe the bit about the order should be at the end of = the paragraph: "Peer and Server IDs SHOULD be exported in the same order in which they = appear in the certificate." > "It is possible for more than one subjectAltName field to be > present in a peer or server certificate in addition to an > empty or non-empty subject distinguished name. EAP-TLS > implementations SHOULD export all the subjectAltName fields > within Peer-Ids or Server-Ids in the same order in which they > appear within the certificate. If the Subject distinguished > name is non-empty then it SHOULD be exported within the > Peer-Ids or Server-Ids. All of the exported Peer-Ids and > Server-Ids are considered valid. >=20 > Such canonical ordering would aid in comparison operations > and would enable using those IDs for key derivation if that > is deemed useful later on. However, the ordering of fields > within the certificate SHOULD NOT be used for access control." > [Joe] sounds good. >=20 > > > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > Date: Tue, 19 Jun 2007 11:33:08 -0700 > > From: jsalowey@cisco.com > > To: g_e_montenegro@yahoo.com; emu@ietf.org > > CC: aboba@internaut.com > > > > I'm not so sure that it is a good idea to rely upon the > order of attributes in a cert. The default behavior is that > all names are valid. If you are looking for different > behavior then you need more information than ordering to > account for cases where an expected name is missing or the CA > does not impose a particular order. > > > > I agree that order may be useful if you are using this > information in key derivation. > > > > If we include this text we should explicitly define where > the subject name goes in the list (at the end?) and caution > against depending on order for access control. > > > > Cheers, > > > > Joe > > > > > -----Original Message----- > > > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > > > Sent: Friday, June 15, 2007 12:18 AM > > > To: emu@ietf.org > > > Cc: Bernard Aboba > > > Subject: [Emu] Multiple Peer-IDs and Server-IDs > > > > > > Looking at > > > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1 > > > 0.txt > > > > > s-10.txt> > > > I have some comments. > > > > > > I think that the whole discussion about multiple Peer and > > > Server-IDs could be reflected better in section 5.2 (last > paragraph): > > > > > > OLD: > > > It is possible for more than one subjectAltName field to > be present > > > in a peer or server certificate in addition to an empty or > > > non-empty > > > subject distinguished name. EAP-TLS implementations SHOULD export > > > all the subjectAltName fields within Peer-Ids or > > > Server-Ids. If the > > > Subject distinguished name is non-empty then it SHOULD be exported > > > within the Peer-Ids or Server-Ids. All of the exported > > > Peer-Ids and > > > Server-Ids are considered valid. > > > > > > It's good that all available the IDs are being exported, but > > > perhaps we should impose a canonical ordering of those > > > multiple identities. For example by adding "...in the same > > > order in which they appear within the certificate": > > > > > > NEW: > > > It is possible for more than one subjectAltName field to > be present > > > in a peer or server certificate in addition to an empty or > > > non-empty > > > subject distinguished name. EAP-TLS implementations SHOULD export > > > all the subjectAltName fields within Peer-Ids or > > > Server-Ids in the same > > > order in which they appear within the certificate. If the > > > Subject distinguished name is non-empty then it SHOULD be exported > > > within the Peer-Ids or Server-Ids. All of the exported > > > Peer-Ids and > > > Server-Ids are considered valid. > > > > > > Such canonical ordering would aid in comparison operations > > > and would enable using those IDs for key derivation if that > > > is deemed useful later on. > > > > > > -gabriel > > > > > > > > > > _______________________________________________ > > 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 ------_=_NextPart_001_01C7B2B5.E8E38808 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] Multiple Peer-IDs and = Server-IDs=0A= =0A= =0A= =0A=
=0A=
I think these = changes are good.
=0A=

=0A=
=0A= From: Joseph Salowey (jsalowey) = [mailto:jsalowey@cisco.com]
Sent: Tue 6/19/2007 1:20 = PM
To: Bernard Aboba; gabriel montenegro; = emu@ietf.org
Cc: Bernard Aboba
Subject: RE: [Emu] = Multiple Peer-IDs and Server-IDs

=0A=
=0A=



> -----Original Message-----
> From: = Bernard Aboba [mailto:bernard_aboba@hotmail.co= m]
> Sent: Tuesday, June 19, 2007 12:02 PM
> To: Joseph = Salowey (jsalowey); gabriel montenegro; emu@ietf.org
> Cc: Bernard = Aboba
> Subject: RE: [Emu] Multiple Peer-IDs and = Server-IDs
>
> I'm not sure about defining the location of = the subject name
> field, beyond what is covered in RFC = 3280.  I agree about the
> caution on utilizing ordering for = access control.  How about:
> 
[Joe] OK, but in the = text below the ordering seems to apply to the subjectAltNames and is = ambiguous as to whether it applies to SubjectAltName. Maybe the bit = about the order should be at the end of the paragraph:

"Peer and = Server IDs SHOULD be exported in the same order in which they appear in = the certificate."

> "It is possible for more than one = subjectAltName field to be
> present in a peer or server = certificate in addition to an
> empty or non-empty subject = distinguished name. EAP-TLS
> implementations SHOULD export all = the subjectAltName fields
> within Peer-Ids or Server-Ids in the = same order in which they
> appear within the certificate. If the = Subject distinguished
> name is non-empty then it SHOULD be = exported within the
> Peer-Ids or Server-Ids. All of the exported = Peer-Ids and
> Server-Ids are considered = valid.
> 
> Such canonical ordering would aid in = comparison operations
> and would enable using those IDs for key = derivation if that
> is deemed useful later on.  However, the = ordering of fields
> within the certificate SHOULD NOT be used for = access control."
>
[Joe] sounds = good.

> 
>
>
> > Subject: RE: [Emu] = Multiple Peer-IDs and Server-IDs
> > Date: Tue, 19 Jun 2007 = 11:33:08 -0700
> > From: jsalowey@cisco.com
> > To: = g_e_montenegro@yahoo.com; emu@ietf.org
> > CC: = aboba@internaut.com
> >
> > I'm not so sure that it is = a good idea to rely upon the
> order of attributes in a cert. The = default behavior is that
> all names are valid. If you are looking = for different
> behavior then you need more information than = ordering to
> account for cases where an expected name is missing = or the CA
> does not impose a particular order.
> = >
> > I agree that order may be useful if you are using = this
> information in key derivation.
> >
> > If = we include this text we should explicitly define where
> the = subject name goes in the list (at the end?) and caution
> against = depending on order for access control.
> >
> > = Cheers,
> >
> > Joe
> >
> > > = -----Original Message-----
> > > From: gabriel montenegro = [mailto:g_e_montenegro@yahoo.com<= /A>]
> > > Sent: Friday, June 15, 2007 12:18 AM
> > = > To: emu@ietf.org
> > > Cc: Bernard Aboba
> > = > Subject: [Emu] Multiple Peer-IDs and Server-IDs
> > = >
> > > Looking at
> > > h= ttp://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1
>= > > 0.txt
> > > = <http://www.drizzle.com/%7Eaboba/EMU/draft-simon-emu-rfc2716bi
>= > > s-10.txt>
> > > I have some comments.
> = > >
> > > I think that the whole discussion about = multiple Peer and
> > > Server-IDs could be reflected better = in section 5.2 (last
> paragraph):
> > >
> > = > OLD:
> > > It is possible for more than one = subjectAltName field to
> be present
> > > in a peer = or server certificate in addition to an empty or
> > > = non-empty
> > > subject distinguished name. EAP-TLS = implementations SHOULD export
> > > all the subjectAltName = fields within Peer-Ids or
> > > Server-Ids. If the
> = > > Subject distinguished name is non-empty then it SHOULD be = exported
> > > within the Peer-Ids or Server-Ids. All of the = exported
> > > Peer-Ids and
> > > Server-Ids are = considered valid.
> > >
> > > Itʼs good = that all available the IDs are being exported, but
> > > = perhaps we should impose a canonical ordering of those
> > > = multiple identities. For example by adding "...in the same
> > = > order in which they appear within the certificate":
> > = >
> > > NEW:
> > > It is possible for more = than one subjectAltName field to
> be present
> > > in = a peer or server certificate in addition to an empty or
> > = > non-empty
> > > subject distinguished name. EAP-TLS = implementations SHOULD export
> > > all the subjectAltName = fields within Peer-Ids or
> > > Server-Ids in the = same
> > > order in which they appear within the = certificate. If the
> > > Subject distinguished name is = non-empty then it SHOULD be exported
> > > within the = Peer-Ids or Server-Ids. All of the exported
> > > Peer-Ids = and
> > > Server-Ids are considered valid.
> > = >
> > > Such canonical ordering would aid in comparison = operations
> > > and would enable using those IDs for key = derivation if that
> > > is deemed useful later on.
> = > >
> > > -gabriel
> > >
> > = >
> >
> > = _______________________________________________
> > 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

------_=_NextPart_001_01C7B2B5.E8E38808-- --===============1569737002== 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 --===============1569737002==-- From emu-bounces@ietf.org Wed Jun 20 13:26:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13wz-0006fw-3I; Wed, 20 Jun 2007 13:26:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13wx-0006fq-Ir for emu@ietf.org; Wed, 20 Jun 2007 13:26:35 -0400 Received: from bay0-omc3-s3.bay0.hotmail.com ([65.54.246.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I13wv-0001lJ-Lc for emu@ietf.org; Wed, 20 Jun 2007 13:26:35 -0400 Received: from BAY117-W21 ([207.46.8.56]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Jun 2007 10:26:32 -0700 Message-ID: X-Originating-IP: [24.16.66.58] From: Bernard Aboba To: Ryan Hurst , "Joseph Salowey (jsalowey)" , gabriel montenegro , Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs Date: Wed, 20 Jun 2007 10:26:29 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2007 17:26:32.0976 (UTC) FILETIME=[25714100:01C7B360] X-Spam-Score: 4.5 (++++) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: Bernard Aboba 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="===============0306419606==" Errors-To: emu-bounces@ietf.org --===============0306419606== Content-Type: multipart/alternative; boundary="_e2444e07-b3eb-4eee-bf37-93f6cb1bc665_" --_e2444e07-b3eb-4eee-bf37-93f6cb1bc665_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Here is the modified text. I also made it clear that these requirements only apply to implementations exporting the Peer-Id or Server-Id.=20 =20 "It is possible for more than one subjectAltName field to be presentin a pe= er or server certificate in addition to an empty or non-emptysubject distin= guished name. EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOU= LD exportall the subjectAltName fields within Peer-Ids or Server-Ids, and S= HOULD alsoexport a non-empty subject distinguished name field within the Pe= er-Ids or Server-Ids.All of the exported Peer-Ids and Server-Ids are consid= ered valid. =20 EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOU= LD exportPeer-Ids and Server-Ids in the same order in which they appear wit= hin the certificate.Such canonical ordering would aid in comparison operati= onsand would enable using those IDs for key derivation if thatis deemed use= ful. However, the ordering of fields withinthe certificate SHOULD NOT be u= sed for access control." Subject: RE: [Emu] Multiple Peer-IDs and Server-IDsDate: Tue, 19 Jun 2007 1= 4:07:28 -0700From: Ryan.Hurst@microsoft.comTo: jsalowey@cisco.com; bernard_= aboba@hotmail.com; g_e_montenegro@yahoo.com; emu@ietf.orgCC: aboba@internau= t.com I think these changes are good. From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]Sent: Tue 6/19/2= 007 1:20 PMTo: Bernard Aboba; gabriel montenegro; emu@ietf.orgCc: Bernard A= bobaSubject: RE: [Emu] Multiple Peer-IDs and Server-IDs > -----Original Message-----> From: Bernard Aboba [mailto:bernard_aboba@hot= mail.com]> Sent: Tuesday, June 19, 2007 12:02 PM> To: Joseph Salowey (jsalo= wey); gabriel montenegro; emu@ietf.org> Cc: Bernard Aboba> Subject: RE: [Em= u] Multiple Peer-IDs and Server-IDs>> I'm not sure about defining the locat= ion of the subject name> field, beyond what is covered in RFC 3280. I agre= e about the> caution on utilizing ordering for access control. How about:>= [Joe] OK, but in the text below the ordering seems to apply to the subject= AltNames and is ambiguous as to whether it applies to SubjectAltName. Maybe= the bit about the order should be at the end of the paragraph:"Peer and Se= rver IDs SHOULD be exported in the same order in which they appear in the c= ertificate."> "It is possible for more than one subjectAltName field to be>= present in a peer or server certificate in addition to an> empty or non-em= pty subject distinguished name. EAP-TLS> implementations SHOULD export all = the subjectAltName fields> within Peer-Ids or Server-Ids in the same order = in which they> appear within the certificate. If the Subject distinguished>= name is non-empty then it SHOULD be exported within the> Peer-Ids or Serve= r-Ids. All of the exported Peer-Ids and> Server-Ids are considered valid.> = > Such canonical ordering would aid in comparison operations> and would ena= ble using those IDs for key derivation if that> is deemed useful later on. = However, the ordering of fields> within the certificate SHOULD NOT be used= for access control.">[Joe] sounds good.> >>> > Subject: RE: [Emu] Multiple= Peer-IDs and Server-IDs> > Date: Tue, 19 Jun 2007 11:33:08 -0700> > From: = jsalowey@cisco.com> > To: g_e_montenegro@yahoo.com; emu@ietf.org> > CC: abo= ba@internaut.com> >> > I'm not so sure that it is a good idea to rely upon = the> order of attributes in a cert. The default behavior is that> all names= are valid. If you are looking for different> behavior then you need more i= nformation than ordering to> account for cases where an expected name is mi= ssing or the CA> does not impose a particular order.> >> > I agree that ord= er may be useful if you are using this> information in key derivation.> >> = > If we include this text we should explicitly define where> the subject na= me goes in the list (at the end?) and caution> against depending on order f= or access control.> >> > Cheers,> >> > Joe> >> > > -----Original Message---= --> > > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com]> > > Sen= t: Friday, June 15, 2007 12:18 AM> > > To: emu@ietf.org> > > Cc: Bernard Ab= oba> > > Subject: [Emu] Multiple Peer-IDs and Server-IDs> > >> > > Looking = at> > > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1> > >= 0.txt> > > = > > s-10.txt>> > > I have some comments.> > >> > > I think that the whole = discussion about multiple Peer and> > > Server-IDs could be reflected bette= r in section 5.2 (last> paragraph):> > >> > > OLD:> > > It is possible for = more than one subjectAltName field to> be present> > > in a peer or server = certificate in addition to an empty or> > > non-empty> > > subject distingu= ished name. EAP-TLS implementations SHOULD export> > > all the subjectAltNa= me fields within Peer-Ids or> > > Server-Ids. If the> > > Subject distingui= shed name is non-empty then it SHOULD be exported> > > within the Peer-Ids = or Server-Ids. All of the exported> > > Peer-Ids and> > > Server-Ids are co= nsidered valid.> > >> > > It=A2s good that all available the IDs are being = exported, but> > > perhaps we should impose a canonical ordering of those> = > > multiple identities. For example by adding "...in the same> > > order i= n which they appear within the certificate":> > >> > > NEW:> > > It is poss= ible for more than one subjectAltName field to> be present> > > in a peer o= r server certificate in addition to an empty or> > > non-empty> > > subject= distinguished name. EAP-TLS implementations SHOULD export> > > all the sub= jectAltName fields within Peer-Ids or> > > Server-Ids in the same> > > orde= r in which they appear within the certificate. If the> > > Subject distingu= ished name is non-empty then it SHOULD be exported> > > within the Peer-Ids= or Server-Ids. All of the exported> > > Peer-Ids and> > > Server-Ids are c= onsidered valid.> > >> > > Such canonical ordering would aid in comparison = operations> > > and would enable using those IDs for key derivation if that= > > > is deemed useful later on.> > >> > > -gabriel> > >> > >> >> > _______= ________________________________________> > Emu mailing list> > Emu@ietf.or= g> > https://www1.ietf.org/mailman/listinfo/emu>>>_________________________= ______________________Emu mailing listEmu@ietf.orghttps://www1.ietf.org/mai= lman/listinfo/emu= --_e2444e07-b3eb-4eee-bf37-93f6cb1bc665_ Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Here is the modified text.  I also made it clear that these requiremen= ts
only apply to implementations exporting the Peer-Id or Server-Id.
 
"It is possible for more than one subjectAltName field to be present
in = a peer or server certificate in addition to an empty or non-empty
subjec= t distinguished name.

EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOU= LD export
all the subjectAltName fields within Peer-Ids or Server-Ids, a= nd SHOULD also
export a non-empty subject distinguished name field withi= n the Peer-Ids or Server-Ids.
All of the exported Peer-Ids and Server-Id= s are considered valid.
 
EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOU= LD export
Peer-Ids and Server-Ids in the same order in which they appear= within the certificate.
Such canonical ordering would aid in comparison= operations
and would enable using those IDs for key derivation if that<= BR>is deemed useful.  However, the ordering of fields within
the ce= rtificate SHOULD NOT be used for access control."



Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
Date: Tue, 19 Jun 20= 07 14:07:28 -0700
From: Ryan.Hurst@microsoft.com
To: jsalowey@cisco.c= om; bernard_aboba@hotmail.com; g_e_montenegro@yahoo.com; emu@ietf.org
CC= : aboba@internaut.com

I think these ch= anges are good.

From: Joseph Salowey (jsalowey) [mailto= :jsalowey@cisco.com]
Sent: Tue 6/19/2007 1:20 PM
To: Be= rnard Aboba; gabriel montenegro; emu@ietf.org
Cc: Bernard AbobaSubject: RE: [Emu] Multiple Peer-IDs and Server-IDs

=


> -----Original Message-----
> From: Bernar= d Aboba [mailto:bernard_aboba@= hotmail.com]
> Sent: Tuesday, June 19, 2007 12:02 PM
> To: = Joseph Salowey (jsalowey); gabriel montenegro; emu@ietf.org
> Cc: Ber= nard Aboba
> Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
&= gt;
> I'm not sure about defining the location of the subject name> field, beyond what is covered in RFC 3280.  I agree about the> caution on utilizing ordering for access control.  How about:> 
[Joe] OK, but in the text below the ordering seems to apply = to the subjectAltNames and is ambiguous as to whether it applies to Subject= AltName. Maybe the bit about the order should be at the end of the paragrap= h:

"Peer and Server IDs SHOULD be exported in the same order in whic= h they appear in the certificate."

> "It is possible for more tha= n one subjectAltName field to be
> present in a peer or server certif= icate in addition to an
> empty or non-empty subject distinguished na= me. EAP-TLS
> implementations SHOULD export all the subjectAltName fi= elds
> within Peer-Ids or Server-Ids in the same order in which they<= BR>> appear within the certificate. If the Subject distinguished
>= name is non-empty then it SHOULD be exported within the
> Peer-Ids o= r Server-Ids. All of the exported Peer-Ids and
> Server-Ids are consi= dered valid.
> 
> Such canonical ordering would aid in com= parison operations
> and would enable using those IDs for key derivat= ion if that
> is deemed useful later on.  However, the ordering = of fields
> within the certificate SHOULD NOT be used for access cont= rol."
>
[Joe] sounds good.

> 
>
>
&g= t; > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
> > Da= te: Tue, 19 Jun 2007 11:33:08 -0700
> > From: jsalowey@cisco.com> > To: g_e_montenegro@yahoo.com; emu@ietf.org
> > CC: abo= ba@internaut.com
> >
> > I'm not so sure that it is a goo= d idea to rely upon the
> order of attributes in a cert. The default = behavior is that
> all names are valid. If you are looking for differ= ent
> behavior then you need more information than ordering to
>= ; account for cases where an expected name is missing or the CA
> doe= s not impose a particular order.
> >
> > I agree that ord= er may be useful if you are using this
> information in key derivatio= n.
> >
> > If we include this text we should explicitly d= efine where
> the subject name goes in the list (at the end?) and cau= tion
> against depending on order for access control.
> >> > Cheers,
> >
> > Joe
> >
> > = > -----Original Message-----
> > > From: gabriel montenegro = [mailto:g_e_montenegro@yahoo.co= m]
> > > Sent: Friday, June 15, 2007 12:18 AM
> > = > To: emu@ietf.org
> > > Cc: Bernard Aboba
> > >= Subject: [Emu] Multiple Peer-IDs and Server-IDs
> > >
> = > > Looking at
> > > http://www.drizzle.c= om/~aboba/EMU/draft-simon-emu-rfc2716bis-1
> > > 0.txt
&= gt; > > <http://www.drizzle.com/%7Eaboba/EMU/draft-simon-emu-rfc27= 16bi
> > > s-10.txt>
> > > I have some comments.=
> > >
> > > I think that the whole discussion abou= t multiple Peer and
> > > Server-IDs could be reflected better = in section 5.2 (last
> paragraph):
> > >
> > >= ; OLD:
> > > It is possible for more than one subjectAltName fi= eld to
> be present
> > > in a peer or server certificate= in addition to an empty or
> > > non-empty
> > > s= ubject distinguished name. EAP-TLS implementations SHOULD export
> &g= t; > all the subjectAltName fields within Peer-Ids or
> > > = Server-Ids. If the
> > > Subject distinguished name is non-empt= y then it SHOULD be exported
> > > within the Peer-Ids or Serve= r-Ids. All of the exported
> > > Peer-Ids and
> > >= Server-Ids are considered valid.
> > >
> > > It=A2= s good that all available the IDs are being exported, but
> > >= perhaps we should impose a canonical ordering of those
> > > m= ultiple identities. For example by adding "...in the same
> > >= order in which they appear within the certificate":
> > >
&= gt; > > NEW:
> > > It is possible for more than one subje= ctAltName field to
> be present
> > > in a peer or server= certificate in addition to an empty or
> > > non-empty
>= > > subject distinguished name. EAP-TLS implementations SHOULD expor= t
> > > all the subjectAltName fields within Peer-Ids or
>= ; > > Server-Ids in the same
> > > order in which they ap= pear within the certificate. If the
> > > Subject distinguished= name is non-empty then it SHOULD be exported
> > > within the = Peer-Ids or Server-Ids. All of the exported
> > > Peer-Ids and<= BR>> > > Server-Ids are considered valid.
> > >
>= ; > > Such canonical ordering would aid in comparison operations
&= gt; > > and would enable using those IDs for key derivation if that> > > is deemed useful later on.
> > >
> > = > -gabriel
> > >
> > >
> >
> >= _______________________________________________
> > Emu mailing l= ist
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listin= fo/emu
>
>
>

_________________________________= ______________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mai= lman/listinfo/emu

= --_e2444e07-b3eb-4eee-bf37-93f6cb1bc665_-- --===============0306419606== 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 --===============0306419606==-- From emu-bounces@ietf.org Wed Jun 20 14:34:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I150l-0006N5-8L; Wed, 20 Jun 2007 14:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I150j-0006Mz-Jo for emu@ietf.org; Wed, 20 Jun 2007 14:34:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I150h-00013c-Mv for emu@ietf.org; Wed, 20 Jun 2007 14:34:33 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2007 11:34:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH4PeUarR7PEh2dsb2JhbACPHgEBAQgOLA X-IronPort-AV: i="4.16,443,1175497200"; d="scan'208"; a="163556538:sNHT57488481" 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 l5KIYUBH023391; Wed, 20 Jun 2007 11:34:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KIYIaS019319; Wed, 20 Jun 2007 18:34:26 GMT 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, 20 Jun 2007 11:34:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs Date: Wed, 20 Jun 2007 11:34:25 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple Peer-IDs and Server-IDs Thread-Index: AcezYDdBgVpvMrWKTdiwSM6FwOGY+gACVnZg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , "Ryan Hurst" , "gabriel montenegro" , X-OriginalArrivalTime: 20 Jun 2007 18:34:23.0304 (UTC) FILETIME=[9F8C0480:01C7B369] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7663; t=1182364470; x=1183228470; 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]=20Multiple=20Peer-IDs=20and=20Server-IDs |Sender:=20; bh=3sjt+A5R8p+zBgVaBLdGmjT+pDF1hb1PIf5eJa3zzeA=; b=evZY+ZqdWbbWiwEtj4OV+G7dIeaX1YWVO295UAOFFaQGrQ7IDI6ZNhFb9oaPFZepUUznLb0Y S5Z8/d5xycMAI8HV5U3XJWRGTCcl0VyWeeLinT/eVQuLom6hBEsYaiDa; 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: df9edf1223802dd4cf213867a3af6121 Cc: Bernard Aboba 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 looks good. Joe=20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, June 20, 2007 10:26 AM > To: Ryan Hurst; Joseph Salowey (jsalowey); gabriel=20 > montenegro; emu@ietf.org > Cc: Bernard Aboba > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs >=20 > Here is the modified text. I also made it clear that these=20 > requirements only apply to implementations exporting the=20 > Peer-Id or Server-Id.=20 > =20 > "It is possible for more than one subjectAltName field to be=20 > present in a peer or server certificate in addition to an=20 > empty or non-empty subject distinguished name. >=20 > EAP-TLS implementations supporting export of the Peer-Id and=20 > Server-Id SHOULD export all the subjectAltName fields within=20 > Peer-Ids or Server-Ids, and SHOULD also export a non-empty=20 > subject distinguished name field within the Peer-Ids or Server-Ids. > All of the exported Peer-Ids and Server-Ids are considered valid. > =20 > EAP-TLS implementations supporting export of the Peer-Id and=20 > Server-Id SHOULD export Peer-Ids and Server-Ids in the same=20 > order in which they appear within the certificate. > Such canonical ordering would aid in comparison operations=20 > and would enable using those IDs for key derivation if that=20 > is deemed useful. However, the ordering of fields within the=20 > certificate SHOULD NOT be used for access control." >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > Date: Tue, 19 Jun 2007 14:07:28 -0700 > From: Ryan.Hurst@microsoft.com > To: jsalowey@cisco.com; bernard_aboba@hotmail.com;=20 > g_e_montenegro@yahoo.com; emu@ietf.org > CC: aboba@internaut.com > =09 > =09 > I think these changes are good. >=20 > ________________________________ >=20 > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tue 6/19/2007 1:20 PM > To: Bernard Aboba; gabriel montenegro; emu@ietf.org > Cc: Bernard Aboba > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > =09 > =09 > =09 > =09 > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, June 19, 2007 12:02 PM > > To: Joseph Salowey (jsalowey); gabriel montenegro;=20 > emu@ietf.org > > Cc: Bernard Aboba > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > > > I'm not sure about defining the location of the subject name > > field, beyond what is covered in RFC 3280. I agree about the > > caution on utilizing ordering for access control. How about: > >=20 > [Joe] OK, but in the text below the ordering seems to=20 > apply to the subjectAltNames and is ambiguous as to whether=20 > it applies to SubjectAltName. Maybe the bit about the order=20 > should be at the end of the paragraph: > =09 > "Peer and Server IDs SHOULD be exported in the same=20 > order in which they appear in the certificate." > =09 > > "It is possible for more than one subjectAltName field to be > > present in a peer or server certificate in addition to an > > empty or non-empty subject distinguished name. EAP-TLS > > implementations SHOULD export all the subjectAltName fields > > within Peer-Ids or Server-Ids in the same order in which they > > appear within the certificate. If the Subject distinguished > > name is non-empty then it SHOULD be exported within the > > Peer-Ids or Server-Ids. All of the exported Peer-Ids and > > Server-Ids are considered valid. > >=20 > > Such canonical ordering would aid in comparison operations > > and would enable using those IDs for key derivation if that > > is deemed useful later on. However, the ordering of fields > > within the certificate SHOULD NOT be used for access control." > > > [Joe] sounds good. > =09 > >=20 > > > > > > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > > Date: Tue, 19 Jun 2007 11:33:08 -0700 > > > From: jsalowey@cisco.com > > > To: g_e_montenegro@yahoo.com; emu@ietf.org > > > CC: aboba@internaut.com > > > > > > I'm not so sure that it is a good idea to rely upon the > > order of attributes in a cert. The default behavior is that > > all names are valid. If you are looking for different > > behavior then you need more information than ordering to > > account for cases where an expected name is missing or the CA > > does not impose a particular order. > > > > > > I agree that order may be useful if you are using this > > information in key derivation. > > > > > > If we include this text we should explicitly define where > > the subject name goes in the list (at the end?) and caution > > against depending on order for access control. > > > > > > Cheers, > > > > > > Joe > > > > > > > -----Original Message----- > > > > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > > > > Sent: Friday, June 15, 2007 12:18 AM > > > > To: emu@ietf.org > > > > Cc: Bernard Aboba > > > > Subject: [Emu] Multiple Peer-IDs and Server-IDs > > > > > > > > Looking at > > > >=20 > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1 > > > > 0.txt > > > >=20 > > > > s-10.txt> > > > > I have some comments. > > > > > > > > I think that the whole discussion about multiple Peer and > > > > Server-IDs could be reflected better in section 5.2 (last > > paragraph): > > > > > > > > OLD: > > > > It is possible for more than one subjectAltName field to > > be present > > > > in a peer or server certificate in addition to an empty or > > > > non-empty > > > > subject distinguished name. EAP-TLS=20 > implementations SHOULD export > > > > all the subjectAltName fields within Peer-Ids or > > > > Server-Ids. If the > > > > Subject distinguished name is non-empty then it=20 > SHOULD be exported > > > > within the Peer-Ids or Server-Ids. All of the exported > > > > Peer-Ids and > > > > Server-Ids are considered valid. > > > > > > > > It=A2s good that all available the IDs are being=20 > exported, but > > > > perhaps we should impose a canonical ordering of those > > > > multiple identities. For example by adding "...in the same > > > > order in which they appear within the certificate": > > > > > > > > NEW: > > > > It is possible for more than one subjectAltName field to > > be present > > > > in a peer or server certificate in addition to an empty or > > > > non-empty > > > > subject distinguished name. EAP-TLS=20 > implementations SHOULD export > > > > all the subjectAltName fields within Peer-Ids or > > > > Server-Ids in the same > > > > order in which they appear within the certificate. If the > > > > Subject distinguished name is non-empty then it=20 > SHOULD be exported > > > > within the Peer-Ids or Server-Ids. All of the exported > > > > Peer-Ids and > > > > Server-Ids are considered valid. > > > > > > > > Such canonical ordering would aid in comparison operations > > > > and would enable using those IDs for key=20 > derivation if that > > > > is deemed useful later on. > > > > > > > > -gabriel > > > > > > > > > > > > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > > =09 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > =09 > =09 >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Jun 22 03:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dwR-0004Wk-JM; Fri, 22 Jun 2007 03:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dwR-0004We-28 for emu@ietf.org; Fri, 22 Jun 2007 03:52:27 -0400 Received: from web81912.mail.mud.yahoo.com ([68.142.207.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1dwO-000233-2w for emu@ietf.org; Fri, 22 Jun 2007 03:52:27 -0400 Received: (qmail 75126 invoked by uid 60001); 22 Jun 2007 07:52:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fdQacrpfWHJmAsZD/XxuTkxJCmOj0peRGdejd4QpKbR2ONrPRR9Tkwc8F1m61fBBEMNbXNJPLnhA9qAgykMWL2E6nQF3z1wpIBdauQzs1yoij2LHu18Fy/eQuEJyEW6+41fQ9AGeUhFTExbLvOD9tuslNWwGtbREAEZ2BHgkO98=; X-YMail-OSG: aB5xZjEVM1lXZn19S9eDnEP0u3KPYHEhg3zLe3ZPjKzMmRu1zOK7PBrBbObx8DBLcNBMzMLYWCirX9dQ142K_Xfxg0wPJuwqTdv3Zjod0cTa9xo- Received: from [195.55.76.26] by web81912.mail.mud.yahoo.com via HTTP; Fri, 22 Jun 2007 00:52:22 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Fri, 22 Jun 2007 00:52:22 -0700 (PDT) From: g_e_montenegro@yahoo.com Subject: Re: [Emu] Multiple Peer-IDs and Server-IDs To: "Joseph Salowey \(jsalowey\)" , Bernard Aboba , Ryan Hurst , emu@ietf.org MIME-Version: 1.0 Message-ID: <150118.68769.qm@web81912.mail.mud.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: Bernard Aboba 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="===============0896430697==" Errors-To: emu-bounces@ietf.org --===============0896430697== Content-Type: multipart/alternative; boundary="0-1667797845-1182498742=:68769" --0-1667797845-1182498742=:68769 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable +1=0A=0A----- Original Message ----=0AFrom: Joseph Salowey (jsalowey) =0ATo: Bernard Aboba ; Ryan Hurst= ; gabriel montenegro ;= emu@ietf.org=0ACc: Bernard Aboba =0ASent: Wednesday, = June 20, 2007 8:34:25 PM=0ASubject: RE: [Emu] Multiple Peer-IDs and Server-= IDs=0A=0AThis looks good.=0A=0AJoe =0A=0A> -----Original Message-----=0A> F= rom: Bernard Aboba [mailto:bernard_aboba@hotmail.com] =0A> Sent: Wednesday,= June 20, 2007 10:26 AM=0A> To: Ryan Hurst; Joseph Salowey (jsalowey); gabr= iel =0A> montenegro; emu@ietf.org=0A> Cc: Bernard Aboba=0A> Subject: RE: [E= mu] Multiple Peer-IDs and Server-IDs=0A> =0A> Here is the modified text. I= also made it clear that these =0A> requirements only apply to implementati= ons exporting the =0A> Peer-Id or Server-Id. =0A> =0A> "It is possible for= more than one subjectAltName field to be =0A> present in a peer or server = certificate in addition to an =0A> empty or non-empty subject distinguished= name.=0A> =0A> EAP-TLS implementations supporting export of the Peer-Id an= d =0A> Server-Id SHOULD export all the subjectAltName fields within =0A> Pe= er-Ids or Server-Ids, and SHOULD also export a non-empty =0A> subject disti= nguished name field within the Peer-Ids or Server-Ids.=0A> All of the expor= ted Peer-Ids and Server-Ids are considered valid.=0A> =0A> EAP-TLS impleme= ntations supporting export of the Peer-Id and =0A> Server-Id SHOULD export = Peer-Ids and Server-Ids in the same =0A> order in which they appear within = the certificate.=0A> Such canonical ordering would aid in comparison operat= ions =0A> and would enable using those IDs for key derivation if that =0A> = is deemed useful. However, the ordering of fields within the =0A> certific= ate SHOULD NOT be used for access control."=0A> =0A> =0A> =0A> =0A> =0A> __= ______________________________=0A> =0A> Subject: RE: [Emu] Multiple Pee= r-IDs and Server-IDs=0A> Date: Tue, 19 Jun 2007 14:07:28 -0700=0A> = From: Ryan.Hurst@microsoft.com=0A> To: jsalowey@cisco.com; bernard_abob= a@hotmail.com; =0A> g_e_montenegro@yahoo.com; emu@ietf.org=0A> CC: abob= a@internaut.com=0A> =0A> =0A> I think these changes are good.= =0A> =0A> ________________________________=0A> =0A> From: Joseph Salowe= y (jsalowey) [mailto:jsalowey@cisco.com]=0A> Sent: Tue 6/19/2007 1:20 P= M=0A> To: Bernard Aboba; gabriel montenegro; emu@ietf.org=0A> Cc: B= ernard Aboba=0A> Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs=0A= > =0A> =0A> =0A> =0A> > -----Original Message-----=0A> = > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=0A> > Sent= : Tuesday, June 19, 2007 12:02 PM=0A> > To: Joseph Salowey (jsalowey); = gabriel montenegro; =0A> emu@ietf.org=0A> > Cc: Bernard Aboba=0A> >= Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs=0A> >=0A> > I'= m not sure about defining the location of the subject name=0A> > field,= beyond what is covered in RFC 3280. I agree about the=0A> > caution o= n utilizing ordering for access control. How about:=0A> > =0A> [Jo= e] OK, but in the text below the ordering seems to =0A> apply to the subjec= tAltNames and is ambiguous as to whether =0A> it applies to SubjectAltName.= Maybe the bit about the order =0A> should be at the end of the paragraph:= =0A> =0A> "Peer and Server IDs SHOULD be exported in the same =0A> = order in which they appear in the certificate."=0A> =0A> > "It is p= ossible for more than one subjectAltName field to be=0A> > present in a= peer or server certificate in addition to an=0A> > empty or non-empty = subject distinguished name. EAP-TLS=0A> > implementations SHOULD export= all the subjectAltName fields=0A> > within Peer-Ids or Server-Ids in t= he same order in which they=0A> > appear within the certificate. If the= Subject distinguished=0A> > name is non-empty then it SHOULD be export= ed within the=0A> > Peer-Ids or Server-Ids. All of the exported Peer-Id= s and=0A> > Server-Ids are considered valid.=0A> > =0A> > Such = canonical ordering would aid in comparison operations=0A> > and would e= nable using those IDs for key derivation if that=0A> > is deemed useful= later on. However, the ordering of fields=0A> > within the certificat= e SHOULD NOT be used for access control."=0A> >=0A> [Joe] sounds go= od.=0A> =0A> > =0A> >=0A> >=0A> > > Subject: RE: [Emu] = Multiple Peer-IDs and Server-IDs=0A> > > Date: Tue, 19 Jun 2007 11:33:0= 8 -0700=0A> > > From: jsalowey@cisco.com=0A> > > To: g_e_montenegro= @yahoo.com; emu@ietf.org=0A> > > CC: aboba@internaut.com=0A> > >=0A= > > > I'm not so sure that it is a good idea to rely upon the=0A> >= order of attributes in a cert. The default behavior is that=0A> > all = names are valid. If you are looking for different=0A> > behavior then y= ou need more information than ordering to=0A> > account for cases where= an expected name is missing or the CA=0A> > does not impose a particul= ar order.=0A> > >=0A> > > I agree that order may be useful if you a= re using this=0A> > information in key derivation.=0A> > >=0A> = > > If we include this text we should explicitly define where=0A> > the= subject name goes in the list (at the end?) and caution=0A> > against = depending on order for access control.=0A> > >=0A> > > Cheers,=0A> = > >=0A> > > Joe=0A> > >=0A> > > > -----Original Message----= -=0A> > > > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com]= =0A> > > > Sent: Friday, June 15, 2007 12:18 AM=0A> > > > To: emu@i= etf.org=0A> > > > Cc: Bernard Aboba=0A> > > > Subject: [Emu] Multip= le Peer-IDs and Server-IDs=0A> > > >=0A> > > > Looking at=0A> >= > > =0A> http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1=0A= > > > > 0.txt=0A> > > > =0A> > > > s-10.txt>=0A> > > > I have some = comments.=0A> > > >=0A> > > > I think that the whole discussion abo= ut multiple Peer and=0A> > > > Server-IDs could be reflected better in = section 5.2 (last=0A> > paragraph):=0A> > > >=0A> > > > OLD:=0A= > > > > It is possible for more than one subjectAltName field to=0A> = > be present=0A> > > > in a peer or server certificate in addition to= an empty or=0A> > > > non-empty=0A> > > > subject distinguished na= me. EAP-TLS =0A> implementations SHOULD export=0A> > > > all the subjec= tAltName fields within Peer-Ids or=0A> > > > Server-Ids. If the=0A> = > > > Subject distinguished name is non-empty then it =0A> SHOULD be expor= ted=0A> > > > within the Peer-Ids or Server-Ids. All of the exported=0A= > > > > Peer-Ids and=0A> > > > Server-Ids are considered valid.=0A>= > > >=0A> > > > It=A2s good that all available the IDs are being = =0A> exported, but=0A> > > > perhaps we should impose a canonical order= ing of those=0A> > > > multiple identities. For example by adding "...i= n the same=0A> > > > order in which they appear within the certificate"= :=0A> > > >=0A> > > > NEW:=0A> > > > It is possible for more th= an one subjectAltName field to=0A> > be present=0A> > > > in a peer= or server certificate in addition to an empty or=0A> > > > non-empty= =0A> > > > subject distinguished name. EAP-TLS =0A> implementations SHO= ULD export=0A> > > > all the subjectAltName fields within Peer-Ids or= =0A> > > > Server-Ids in the same=0A> > > > order in which they app= ear within the certificate. If the=0A> > > > Subject distinguished name= is non-empty then it =0A> SHOULD be exported=0A> > > > within the Peer= -Ids or Server-Ids. All of the exported=0A> > > > Peer-Ids and=0A> = > > > Server-Ids are considered valid.=0A> > > >=0A> > > > Such can= onical ordering would aid in comparison operations=0A> > > > and would = enable using those IDs for key =0A> derivation if that=0A> > > > is dee= med useful later on.=0A> > > >=0A> > > > -gabriel=0A> > > >=0A>= > > >=0A> > >=0A> > > ________________________________________= _______=0A> > > Emu mailing list=0A> > > Emu@ietf.org=0A> > > h= ttps://www1.ietf.org/mailman/listinfo/emu=0A> >=0A> >=0A> >=0A>= =0A> _______________________________________________=0A> Emu m= ailing list=0A> Emu@ietf.org=0A> https://www1.ietf.org/mailman/list= info/emu=0A> =0A> =0A> =0A> =0A=0A=0A=0A=0A --0-1667797845-1182498742=:68769 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
+1

----- Original Message ----
From:= Joseph Salowey (jsalowey) <jsalowey@cisco.com>
To: Bernard Aboba = <bernard_aboba@hotmail.com>; Ryan Hurst <ryan.hurst@microsoft.com&= gt;; gabriel montenegro <g_e_montenegro@yahoo.com>; emu@ietf.org
C= c: Bernard Aboba <aboba@internaut.com>
Sent: Wednesday, June 20, 2= 007 8:34:25 PM
Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
This looks good.

Joe

> -----Original Message-----<= br>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sen= t: Wednesday, June 20, 2007 10:26 AM
> To: Ryan Hurst; Joseph Salowey= (jsalowey); gabriel
> montenegro; emu@ietf.org
> Cc: Bernard Aboba
> Subjec= t: RE: [Emu] Multiple Peer-IDs and Server-IDs
>
> Here is the = modified text.  I also made it clear that these
> requirem= ents only apply to implementations exporting the
> Peer-Id or Server= -Id.
>  
> "It is possible for more than one subject= AltName field to be
> present in a peer or server certificate in add= ition to an
> empty or non-empty subject distinguished name.
>=
> EAP-TLS implementations supporting export of the Peer-Id and
= > Server-Id SHOULD export all the subjectAltName fields within
> = Peer-Ids or Server-Ids, and SHOULD also export a non-empty
> subject= distinguished name field within the Peer-Ids or Server-Ids.
> All of= the exported Peer-Ids and Server-Ids are considered valid.
> &n= bsp;
> EAP-TLS implementations supporting export of the Peer-Id and <= br>> Server-Id SHOULD export Peer-Ids and Server-Ids in the same
> order= in which they appear within the certificate.
> Such canonical orderi= ng would aid in comparison operations
> and would enable using those= IDs for key derivation if that
> is deemed useful.  Howev= er, the ordering of fields within the
> certificate SHOULD NOT be us= ed for access control."
>
>
>
>
>
>= ; ________________________________
>
>     = ;Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
>   &n= bsp; Date: Tue, 19 Jun 2007 14:07:28 -0700
>    &= nbsp;From: Ryan.Hurst@microsoft.com
>     To: jsa= lowey@cisco.com; bernard_aboba@hotmail.com;
> g_e_montenegro@yahoo.c= om; emu@ietf.org
>     CC: aboba@internaut.com>     
>     
>     I think these changes are good.
>
> _= _______________________________
>
>     Fr= om: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
>  &nb= sp;  Sent: Tue 6/19/2007 1:20 PM
>     = To: Bernard Aboba; gabriel montenegro; emu@ietf.org
>   &nb= sp; Cc: Bernard Aboba
>     Subject: RE: [Em= u] Multiple Peer-IDs and Server-IDs
>     
>= ;     
>     
>  &= nbsp;  
>     > -----Original Messag= e-----
>     > From: Bernard Aboba [mailto:ber= nard_aboba@hotmail.com]
>     > Sent: Tuesday,= June 19, 2007 12:02 PM
>     > To: Joseph Sal= owey (jsalowey); gabriel montenegro;
> emu@ietf.org
>     > Cc: Bernard Aboba
>    &= nbsp;> Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
>  = ;   >
>     > I'm not sure a= bout defining the location of the subject name
>    &n= bsp;> field, beyond what is covered in RFC 3280.  I agree abou= t the
>     > caution on utilizing ordering fo= r access control.  How about:
>     >= ;
>     [Joe] OK, but in the text below the orde= ring seems to
> apply to the subjectAltNames and is ambiguous as to = whether
> it applies to SubjectAltName. Maybe the bit about the orde= r
> should be at the end of the paragraph:
>    = ; 
>     "Peer and Server IDs SHOULD be expo= rted in the same
> order in which they appear in the certificate.">     
>     > "It is possi= ble for more than one subjectAltName field to be
>    =  > present in a peer or server certificate in addition to an
>= ;     > empty or non-empty subject distinguished nam= e. EAP-TLS
>     > implementations SHOULD expo= rt all the subjectAltName fields
>     > withi= n Peer-Ids or Server-Ids in the same order in which they
>  &nbs= p;  > appear within the certificate. If the Subject distinguis= hed
>     > name is non-empty then it SHOULD b= e exported within the
>     > Peer-Ids or Serv= er-Ids. All of the exported Peer-Ids and
>     &g= t; Server-Ids are considered valid.
>     > >     > Such canonical ordering would aid in co= mparison operations
>     > and would enable using tho= se IDs for key derivation if that
>     > is d= eemed useful later on.  However, the ordering of fields
> &= nbsp;   > within the certificate SHOULD NOT be used for a= ccess control."
>     >
>   &n= bsp; [Joe] sounds good.
>     
>  = ;   >
>     >
>  = ;   >
>     > > Subject: = RE: [Emu] Multiple Peer-IDs and Server-IDs
>     = > > Date: Tue, 19 Jun 2007 11:33:08 -0700
>    &= nbsp;> > From: jsalowey@cisco.com
>     >= ; > To: g_e_montenegro@yahoo.com; emu@ietf.org
>    = ; > > CC: aboba@internaut.com
>     &g= t; >
>     > > I'm not so sure that it is = a good idea to rely upon the
>     > order of = attributes in a cert. The default behavior is that
>   &nbs= p; > all names are valid. If you are looking for different
> =     > behavior then you need more information than o= rdering to
>     > account for cases where an = expected name is missing or the CA
>     > doe= s not impose a particular order.
>     > ><= br>>     > > I agree that order may be useful = if you are using this
>     > information in k= ey derivation.
>     > >
>  &nbs= p;  > > If we include this text we should explicitly define= where
>     > the subject name goes in the li= st (at the end?) and caution
>     > against depending o= n order for access control.
>     > >
&g= t;     > > Cheers,
>    &nbs= p;> >
>     > > Joe
>  &nb= sp;  > >
>     > > > ---= --Original Message-----
>     > > > From= : gabriel montenegro [mailto:g_e_montenegro@yahoo.com]
>   =   > > > Sent: Friday, June 15, 2007 12:18 AM
> &nb= sp;   > > > To: emu@ietf.org
>   &n= bsp; > > > Cc: Bernard Aboba
>     = > > > Subject: [Emu] Multiple Peer-IDs and Server-IDs
> &nbs= p;   > > >
>     > >= ; > Looking at
>     > > >
> <= a target=3D"_blank" href=3D"http://www.drizzle.com/%7Eaboba/EMU/draft-simon-= emu-rfc2716bis-1">http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716= bis-1
>     > > > 0.txt
> &nbs= p;   > > >
> <http://w= ww.drizzle.com/%7Eaboba/EMU/draft-simon-emu-rfc2716bi
>  &nb= sp;  > > > s-10.txt>
>     = > > > I have some comments.
>     > &= gt; >
>     > > > I think that the wh= ole discussion about multiple Peer and
>     >= > > Server-IDs could be reflected better in section 5.2 (last
>= ;     > paragraph):
>     = > > >
>     > > > OLD:
>     > > > It is possible for more than one su= bjectAltName field to
>     > be present
&g= t;     > > > in a peer or server certificate i= n addition to an empty or
>     > > > no= n-empty
>     > > > subject distinguishe= d name. EAP-TLS
> implementations SHOULD export
>   =   > > > all the subjectAltName fields within Peer-Ids or=
>     > > > Server-Ids. If the
> =     > > > Subject distinguished name is non-em= pty then it
> SHOULD be exported
>     >= ; > > within the Peer-Ids or Server-Ids. All of the exported
> =     > > > Peer-Ids and
>   &nb= sp; > > > Server-Ids are considered valid.
>     > > >
>     >= ; > > It=A2s good that all available the IDs are being
> expor= ted, but
>     > > > perhaps we should i= mpose a canonical ordering of those
>     > &g= t; > multiple identities. For example by adding "...in the same
> =     > > > order in which they appear within th= e certificate":
>     > > >
> &nbs= p;   > > > NEW:
>     >= ; > > It is possible for more than one subjectAltName field to
>= ;     > be present
>     &= gt; > > in a peer or server certificate in addition to an empty or>     > > > non-empty
>   =   > > > subject distinguished name. EAP-TLS
> imp= lementations SHOULD export
>     > > > all the subje= ctAltName fields within Peer-Ids or
>     > &g= t; > Server-Ids in the same
>     > > &g= t; order in which they appear within the certificate. If the
>  =    > > > Subject distinguished name is non-empty th= en it
> SHOULD be exported
>     > >= > within the Peer-Ids or Server-Ids. All of the exported
>  =    > > > Peer-Ids and
>    &nb= sp;> > > Server-Ids are considered valid.
>   &nbs= p; > > >
>     > > > Such = canonical ordering would aid in comparison operations
>   &= nbsp; > > > and would enable using those IDs for key
>= derivation if that
>     > > > is deeme= d useful later on.
>     > > >
>  &nb= sp;  > > > -gabriel
>     >= > >
>     > > >
>  &nb= sp;  > >
>     > > ________= _______________________________________
>     >= ; > Emu mailing list
>     > > Emu@ietf.= org
>     > > https://www1.ietf.org/mailman/l= istinfo/emu
>     >
>   &n= bsp; >
>     >
>   &nb= sp; 
>     _________________________________= ______________
>     Emu mailing list
> &nb= sp;   Emu@ietf.org
>     https://www1.ietf.org/= mailman/listinfo/emu
>     
>  &nb= sp;  
>
>

--0-1667797845-1182498742=:68769-- --===============0896430697== 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 --===============0896430697==-- From emu-bounces@ietf.org Sun Jun 24 03:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MgR-0006ip-Ut; Sun, 24 Jun 2007 03:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MgR-0006hf-2A for emu@ietf.org; Sun, 24 Jun 2007 03:38:55 -0400 Received: from web59214.mail.re1.yahoo.com ([66.196.101.40]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2MgP-0007Pm-P4 for emu@ietf.org; Sun, 24 Jun 2007 03:38:55 -0400 Received: (qmail 73229 invoked by uid 60001); 24 Jun 2007 07:38:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TDuV+wx6Yf9tVLc/wVeUBvV3QvSI9iWnJ9C+JGdqxio7h/OwunnY0FBDDS6ZS09tF0vaOClobdNCdwdtkmm/dQwB21HFbD4iPW8RIZ5yeIskSUvLw9Bbz3pDOXq+/h0UoUu/9xWGqgRvH1oeY/Nziw2AM2CDoOpvJdpI8DC6NFY=; X-YMail-OSG: NHHScMYVM1lYB9kR_l_ybQLr47CdjOiElmhLSFZpbAuLOzHDibtFrsGsWCUkQtZiZ.2Mu.SLBj7nzzzKg.eMlGP7atCHhkej4QFWA.qPoxh8_wZhiDbmeKUMre5qZUM- Received: from [75.26.156.247] by web59214.mail.re1.yahoo.com via HTTP; Sun, 24 Jun 2007 00:38:53 PDT Date: Sun, 24 Jun 2007 00:38:53 -0700 (PDT) From: Abhijit Rao To: emu@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <548372.73207.qm@web59214.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Emu] Server Authentication in EAP-TLS/802.11i 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 Hello, If EAP-TLS is in effect, how is the 802.11i client expected to authenticate the Server certificate when the client does not have access to "internet". I thought one way is for the client to assume that it is a "safe" TLS - Server and finish the key generation ... and once the "internet" access is available then validate the server certificate. Is this the recommended way? Also this does not work if it is a closed network - please help. Your insight into this matter is appreciated sincerely. I read the most recent draft regarding EAP-TLS I did not see any recommendation being made. Am I missing something here? Regards Abhi ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jun 25 11:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qsP-0003s0-R9; Mon, 25 Jun 2007 11:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qsP-0003ru-8m for emu@ietf.org; Mon, 25 Jun 2007 11:53:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qsO-0000XN-Sc for emu@ietf.org; Mon, 25 Jun 2007 11:53:17 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 08:53:16 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="171619530:sNHT46673424" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PFrGji027822; Mon, 25 Jun 2007 08:53:16 -0700 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 l5PFr7Gk002194; Mon, 25 Jun 2007 15:53:16 GMT 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); Mon, 25 Jun 2007 08:53:14 -0700 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] Server Authentication in EAP-TLS/802.11i Date: Mon, 25 Jun 2007 08:53:17 -0700 Message-ID: In-Reply-To: <548372.73207.qm@web59214.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Server Authentication in EAP-TLS/802.11i Thread-Index: Ace2MrunySupltuiSk+DKVy1jLZgoABDLg9w From: "Joseph Salowey \(jsalowey\)" To: "Abhijit Rao" , X-OriginalArrivalTime: 25 Jun 2007 15:53:14.0180 (UTC) FILETIME=[F05D8840:01C7B740] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1884; t=1182786796; x=1183650796; 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]=20Server=20Authentication=20in=20EAP-TLS/802.11 i |Sender:=20; bh=SQf4UBv3GT0oDabA0JNIpNl0qovYBvhtoKvYnCRZ36o=; b=wolrsfJkLp8eIPljzUqTUE93euReH7bIL68lekJhcWnA+VqZVI59hXNPQ4Hh2I03z/2BRA8T miQHjBIxw1jUW03UjdN1UR0zumn/0B5k7NTki4WoWCqi5IlImcplyT+5; 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: 8b431ad66d60be2d47c7bfeb879db82c 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 Abhijit, In section 5.3 it is assumed that the trust roots required for validation are configured in the client. If the client is also performing revocation section 5.4 provides two possible mechanisms; one is to check for revocation lists after access has been granted and the other is to use the OCSP extensions to TLS to obtain and OCSP response from the server prior to completing the key exchange. The OCSP method does not require the client to have a direct connection to an OCSP server. Joe > -----Original Message----- > From: Abhijit Rao [mailto:abhijit_rao.mailinglist@yahoo.com]=20 > Sent: Sunday, June 24, 2007 12:39 AM > To: emu@ietf.org > Subject: [Emu] Server Authentication in EAP-TLS/802.11i >=20 > Hello, >=20 > If EAP-TLS is in effect, how is the 802.11i client expected=20 > to authenticate the Server certificate when the client does=20 > not have access to "internet".=20 > I thought one way is for the client to assume that it is a=20 > "safe" TLS - Server and finish the key generation ... and=20 > once the "internet" access is available then validate the=20 > server certificate. Is this the recommended way?=20 > Also this does not work if it is a closed network - please help.=20 > Your insight into this matter is appreciated sincerely. I=20 > read the most recent draft regarding EAP-TLS I did not see=20 > any recommendation being made. > Am I missing something here? > Regards > Abhi >=20 >=20 >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > Yahoo! oneSearch: Finally, mobile search=20 > that gives answers, not web links.=20 > http://mobile.yahoo.com/mobileweb/onesearch?refer=3D1ONXIC >=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 Jun 27 15:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dWs-0004px-E5; Wed, 27 Jun 2007 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dWp-0004pM-Hn; Wed, 27 Jun 2007 15:50:15 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3dWc-0003W9-Hp; Wed, 27 Jun 2007 15:50:15 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6020626E7B; Wed, 27 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3dWc-0001Dq-4V; Wed, 27 Jun 2007 15:50:02 -0400 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, 27 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: emu@ietf.org Subject: [Emu] I-D ACTION:draft-simon-emu-rfc2716bis-10.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-10.txt Pages : 31 Date : 2007-6-27 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. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-10.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-10.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-10.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-6-27135733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-27135733.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--