From emu-bounces@ietf.org Tue May 01 17:41: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 1Hj064-0003Gx-RQ; Tue, 01 May 2007 17:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj063-0003Gn-Mn for emu@ietf.org; Tue, 01 May 2007 17:41:19 -0400 Received: from bay0-omc2-s27.bay0.hotmail.com ([65.54.246.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj062-0008KI-DP for emu@ietf.org; Tue, 01 May 2007 17:41:19 -0400 Received: from hotmail.com ([207.46.8.94]) by bay0-omc2-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 1 May 2007 14:41:17 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 May 2007 14:41:17 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 01 May 2007 21:41:13 GMT X-Originating-IP: [64.244.67.5] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: emu@ietf.org Bcc: Date: Tue, 01 May 2007 14:41:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 May 2007 21:41:17.0650 (UTC) FILETIME=[7329EB20:01C78C39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: steve.upp@motorola.com Subject: [Emu] RFC 2716bis Issue: Use of rfc822Name 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 following question has come up in the WiMAX Forum with respect to EAP-TLS peer certificate usage: >From RFC 3280: When the subjectAltName extension contains an Internet mail address, the address MUST be included as an rfc822Name. The format of an rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has the form "local-part@domain". Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Note that while upper and lower case letters are allowed in an RFC 822 addr-spec, no significance is attached to the case. The question is whether any NAI as defined in RFC 4282 meets these requirements for inclusion in subjectAltName using the rfc822Name format. For example, what if an NAI does not contain a realm portion? My personal take is that as long as the NAI is legal within RFC 4282, it should be legal for inclusion in the subjectAltName field using the rfc822Name format. This seems preferrable to registering a new type-id. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed May 02 18:34: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 1HjNOd-0004gY-Ja; Wed, 02 May 2007 18:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjNOd-0004gT-7i for emu@ietf.org; Wed, 02 May 2007 18:34:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjNOc-0007vU-PL for emu@ietf.org; Wed, 02 May 2007 18:34:03 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 May 2007 15:34:02 -0700 X-IronPort-AV: i="4.14,482,1170662400"; d="scan'208"; a="57617907:sNHT206861580" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l42MY0qi018910; Wed, 2 May 2007 15:34:00 -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 l42MXQxP001055; Wed, 2 May 2007 22:34:00 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, 2 May 2007 15:33:57 -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] RFC 2716bis Issue: Use of rfc822Name Date: Wed, 2 May 2007 15:33:51 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC 2716bis Issue: Use of rfc822Name Thread-Index: AceMOX4mLzp9DlHHTqSa+Jm8FeShzAAzyUag From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 May 2007 22:33:57.0096 (UTC) FILETIME=[F8C0DE80:01C78D09] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1990; t=1178145240; x=1179009240; c=relaxed/simple; s=sjdkim6002; 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]=20RFC=202716bis=20Issue=3A=20Use=20of=20rfc822N ame |Sender:=20; bh=4DaSP6WwArI0IkzH/scho7YaKYo1qwfbb85FafMBuOc=; b=b8FYJdbaaI3+bw1/FDUfLBvDGs07RcgvSjluqBBJ/rZ77oMLvJw13285AE8yN93QJvxB962V deAv5Tw2x4dz1CmuEStGvFBEmd8GGEnB0n7MzRQZeLHvO34+Cwhn/S62; Authentication-Results: sj-dkim-6; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: steve.upp@motorola.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 RFC4383 is a superset of RFC822. If a name does not conform to RFC822 then it will not be compliant with RFC3280. Within a specific community where everyone has a common understanding of how the extension will be used then this is probably OK. If you plan on using the certificates more generically then it is possible that you will run into problems. =20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 01, 2007 2:41 PM > To: emu@ietf.org > Cc: steve.upp@motorola.com > Subject: [Emu] RFC 2716bis Issue: Use of rfc822Name >=20 > The following question has come up in the WiMAX Forum with=20 > respect to EAP-TLS peer certificate usage: >=20 > >From RFC 3280: > When the subjectAltName extension contains an Internet=20 > mail address, > the address MUST be included as an rfc822Name. The format of an > rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An > addr-spec has the form "local-part@domain". Note that an addr-spec > has no phrase (such as a common name) before it, has no=20 > comment (text > surrounded in parentheses) after it, and is not surrounded=20 > by "<" and > ">". Note that while upper and lower case letters are=20 > allowed in an > RFC 822 addr-spec, no significance is attached to the case. >=20 > The question is whether any NAI as defined in RFC 4282 meets=20 > these requirements for inclusion in subjectAltName using the=20 > rfc822Name format. >=20 > For example, what if an NAI does not contain a realm portion? >=20 > My personal take is that as long as the NAI is legal within=20 > RFC 4282, it should be legal for inclusion in the=20 > subjectAltName field using the rfc822Name format. This seems=20 > preferrable to registering a new type-id. >=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 May 03 03:52: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 1HjW6c-0004Yh-A0; Thu, 03 May 2007 03:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjW6b-0004Yc-AH for emu@ietf.org; Thu, 03 May 2007 03:52:01 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjW6Z-0002J3-SF for emu@ietf.org; Thu, 03 May 2007 03:52:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l437pgSp007849; Thu, 3 May 2007 10:51:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 10:51:50 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 10:51:49 +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] RFC 2716bis Issue: Use of rfc822Name Date: Thu, 3 May 2007 10:51:49 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC 2716bis Issue: Use of rfc822Name Thread-Index: AceMOX4mLzp9DlHHTqSa+Jm8FeShzAAzyUagABNbD3A= References: From: To: , X-OriginalArrivalTime: 03 May 2007 07:51:49.0978 (UTC) FILETIME=[E82553A0:01C78D57] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Joseph Salowey wrote: > RFC4383 is a superset of RFC822. If a name does not conform to > RFC822 then it will not be compliant with RFC3280. Within a > specific community where everyone has a common understanding of how > the extension will be used then this is probably OK. If you plan on > using the certificates more generically then it is possible that you > will run into problems. Actually, RFC 4282 is not a superset of RFC822 addr-spec. There=20 are some weird corner cases that are valid RFC822 addr-spec's but=20 not valid NAIs. For example, RFC822 allows quoting a space with double quotes ("john doe"@example.org), but RFC4282 has only backslash-quoting. I'm sure other similar cases exist, but probably they don't really have any impact on real-world deployments. Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue May 08 17:54: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 1HlXdO-0004lI-3E; Tue, 08 May 2007 17:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXdM-0004l3-VW for emu@ietf.org; Tue, 08 May 2007 17:54:12 -0400 Received: from bay0-omc2-s11.bay0.hotmail.com ([65.54.246.147]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXdK-0002hR-Dg for emu@ietf.org; Tue, 08 May 2007 17:54:12 -0400 Received: from BAY117-W4 ([207.46.8.39]) by bay0-omc2-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 8 May 2007 14:54:09 -0700 Message-ID: X-Originating-IP: [131.107.0.74] From: Bernard Aboba To: Date: Tue, 8 May 2007 14:54:09 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 May 2007 21:54:09.0707 (UTC) FILETIME=[683CB7B0:01C791BB] X-Spam-Score: 2.6 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Emu] Multiple identity 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="===============0250417878==" Errors-To: emu-bounces@ietf.org --===============0250417878== Content-Type: multipart/alternative; boundary="_dbfe3990-e2ff-4e38-a56f-e96883b8ebd3_" --_dbfe3990-e2ff-4e38-a56f-e96883b8ebd3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the EMU WG meeting, we discussed the situation where more than one alts= ubjectName or subject field are present in a certificate. Here is some tex= t which can be added to the end of Section 5.2 to address this issue: =20 "It is possible for more than one subjectAltName field to be presentin a pe= er or server certificate; similarly, it is possible for morethan one subje= ct name field to be present in a peer or servercertificate. In this case, = EAP-TLS may export more than one Peer-Idor more than one Server-Id; all of = the exported Peer-Id(s) and Server-Id(s) are considered valid. "= --_dbfe3990-e2ff-4e38-a56f-e96883b8ebd3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At  the EMU WG meeting, we discussed the situation where more than one= altsubjectName or subject field are present in a certificate.  Here i= s some text which can be added to the end of Section 5.2 to address this is= sue:
 
"It is possible for more than one subjectAltName field to be present
in = a peer or server certificate;  similarly, it is possible for more
t= han one subject name field to be present in a peer or server
certificate= .  In this case, EAP-TLS may export more than one Peer-Id
or more t= han one Server-Id; all of the exported Peer-Id(s) and Server-Id(s) are cons= idered
valid. "
= --_dbfe3990-e2ff-4e38-a56f-e96883b8ebd3_-- --===============0250417878== 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 --===============0250417878==-- From emu-bounces@ietf.org Tue May 08 18:08: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 1HlXrF-0006IQ-Iz; Tue, 08 May 2007 18:08:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXrE-0006IL-SF for emu@ietf.org; Tue, 08 May 2007 18:08:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXrE-00080R-J4 for emu@ietf.org; Tue, 08 May 2007 18:08:32 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 15:08:32 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="419903693:sNHT70811070" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l48M8WXb019975; Tue, 8 May 2007 15:08:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l48M8DAS023216; Tue, 8 May 2007 22:08:31 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, 8 May 2007 15:08: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Multiple identity issue Date: Tue, 8 May 2007 15:08:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple identity issue Thread-Index: AceRu29HnIGKZj24S/aRLf79yeipVQAATNdQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 08 May 2007 22:08:23.0770 (UTC) FILETIME=[654C63A0:01C791BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1347; t=1178662112; x=1179526112; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Multiple=20identity=20issue |Sender:=20; bh=ZlkN5e0BpcXqPMEXpde7kSEBNJQLHrBOEKU/xFzAmVk=; b=LF6I7Iddh1jFkFBgvysF/sjq98pcNqo53k9qYhFIOZ5Eq9bLUyY2Y4moHGtWcgifFl9iIipE /3ePOUKpTAcTkHQ5Z7U87IoUgTdI5ruMUl6C+YI2t4smTjOWQV+XBZsV; Authentication-Results: sj-dkim-8; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org looks good, except I think that there can be only one Subject Name field in a valid certificate. How about something like:=20 "It is possible for more than one subjectAltName field to be present in a peer or server certificate; similarly, it is possible for a non-empty subject name field to also be present in a peer or server certificate. In this case, EAP-TLS may export more than one Peer-Id or more than one Server-Id; all of the exported Peer-Id(s) and Server-Id(s) are considered=20 valid. " =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, May 08, 2007 2:54 PM To: emu@ietf.org Subject: [Emu] Multiple identity issue =09 =09 At the EMU WG meeting, we discussed the situation where more than one altsubjectName or subject field are present in a certificate. Here is some text which can be added to the end of Section 5.2 to address this issue: =20 "It is possible for more than one subjectAltName field to be present in a peer or server certificate; similarly, it is possible for more than one subject name field to be present in a peer or server certificate. In this case, EAP-TLS may export more than one Peer-Id or more than one Server-Id; all of the exported Peer-Id(s) and Server-Id(s) are considered=20 valid. " =09 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue May 08 18:09:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXsY-0006aO-Vb; Tue, 08 May 2007 18:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXsX-0006aI-Vy for emu@ietf.org; Tue, 08 May 2007 18:09:53 -0400 Received: from bay0-omc2-s41.bay0.hotmail.com ([65.54.246.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXsX-0008MY-A2 for emu@ietf.org; Tue, 08 May 2007 18:09:53 -0400 Received: from BAY117-W4 ([207.46.8.39]) by bay0-omc2-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 8 May 2007 15:09:52 -0700 Message-ID: X-Originating-IP: [131.107.0.74] From: Bernard Aboba To: Date: Tue, 8 May 2007 15:09:52 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 May 2007 22:09:52.0958 (UTC) FILETIME=[9A7565E0:01C791BD] X-Spam-Score: 2.6 (++) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [Emu] RFC 2818 reference 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="===============1411811494==" Errors-To: emu-bounces@ietf.org --===============1411811494== Content-Type: multipart/alternative; boundary="_e6b824c5-0acd-403b-ab89-07b531afca82_" --_e6b824c5-0acd-403b-ab89-07b531afca82_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A question has arisen about the reference to RFC 2818 section 3.1 within Se= ction 5.3: =20 When performing this comparison implementations MUST follow the valida= tion rules specified in [RFC2818] Section 3.1. In the case of the server= this involves ensuring the certificate presented by the EAP-TLS peer was= intended to be used as a client certificate. Implementations SHOULD use = the Extended Key Usage (see [RFC3280] Section 4.2.1.13) extension and ens= ure that at least one of the following is true: 1) The certificate issu= er included no Extended Key Usage identifiers in the certificate. 2)= The issuer included the anyExtendedKeyUsage identifier in the certifi= cate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-c= lientAuth identifier in the certificate (see [RFC3280] section 4.2.1.1= 3).=20 =20 Here is the text from that reference: =20 3.1. Server Identity In general, HTTP/TLS requests are generated by dere= ferencing a URI. As a consequence, the hostname for the server is known t= o the client. If the hostname is available, the client MUST check it agai= nst the server's identity as presented in the server's Certificate messag= e, in order to prevent man-in-the-middle attacks. If the client has ext= ernal information as to the expected identity of the server, the hostname= check MAY be omitted. (For instance, a client may be connecting to a mac= hine whose address and hostname are dynamic but the client knows the cert= ificate that the server will present.) In such cases, it is important to = narrow the scope of acceptable certificates as much as possible in order = to prevent man in the middle attacks. In special cases, it may be approp= riate for the client to simply ignore the server's identity, but it must = be understood that this leaves the connection open to active attack. If= a subjectAltName extension of type dNSName is present, that MUST be used= as the identity. Otherwise, the (most specific) Common Name field in the= Subject field of the certificate MUST be used. Although the use of the C= ommon Name is existing practice, it is deprecated and Certification Autho= rities are encouraged to use the dNSName instead. Matching is performed u= sing the matching rules specified by [RFC2459]. If more than one identit= y of a given type is present in the certificate (e.g., more than one dNSN= ame name, a match in any one of the set is considered acceptable.) Names = may contain the wildcard character * which is considered to match any sin= gle domain name component or component fragment. E.g., *.a.com matches fo= o.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. = In some cases, the URI is specified as an IP address rather than a hostna= me. In this case, the iPAddress subjectAltName must be present in the cer= tificate and must exactly match the IP in the URI. If the hostname does n= ot match the identity in the certificate, user oriented clients MUST eith= er notify the user (clients MAY give the user the opportunity to continue= with the connection in any case) or terminate the connection with a bad = certificate error. Automated clients MUST log the error to an appropriate= audit log (if available) and SHOULD terminate the connection (with a bad= certificate error). Automated clients MAY provide a configuration settin= g that disables this check, but MUST provide a setting which enables it. = Note that in many cases the URI itself comes from an untrusted source. = The above-described check provides no protection against attacks where th= is source is compromised. For example, if the URI was obtained by clickin= g on an HTML page which was itself obtained without using HTTP/TLS, a man= in the middle could have replaced the URI. In order to prevent this for= m of attack, users should carefully examine the certificate presented by = the server to determine if it meets their expectations. =20 Overall, this reference does seem to have some relevance to the issues disc= ussed in Section 5.3. In terms of relevance to EAP-TLS, there is typically= no URL. In some cases EAP-TLS server hostname and IP address are not kno= wn before authentication, and so cannot be compared to the Server-Id (e.g. = 802.11), but in other cases this might be possible (e.g. VPN). Paragraphs= 5-6 seem relevant, but paragraph 7 is probably not relevant. Given this, = my inclination is to keep the reference to RFC 2818, but make it normative = (since there is a MUST reference to it). = --_e6b824c5-0acd-403b-ab89-07b531afca82_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A question has arisen about the reference to RFC 2818 section 3.1 withi= n Section 5.3:
 
   When performing this comparison implementations MUST follow th= e
   validation rules specified in [RFC2818] Section 3.1. = ; In the case of
   the server this involves ensuring the cert= ificate presented by the
   EAP-TLS peer was intended to be us= ed as a client certificate.
   Implementations SHOULD use the = Extended Key Usage (see [RFC3280]
   Section 4.2.1.13) extensi= on and ensure that at least one of the
   following is true:
   1) The certificate issuer included no Extended Key Usage=
      identifiers in the certificate.
 = ;  2) The issuer included the anyExtendedKeyUsage identifier in
&nb= sp;     the certificate (see [RFC3280] section 4.2.1.13= ).
   3) The issuer included the id-kp-clientAuth identifier i= n
      the certificate (see [RFC3280] section = 4.2.1.13). 
 
Here is the text from that reference:
 
3.1.  Server Identity

   In general, HTTP/TLS request= s are generated by dereferencing a URI.
   As a consequence, t= he hostname for the server is known to the client.
   If the h= ostname is available, the client MUST check it against the
   = server's identity as presented in the server's Certificate message,
&nbs= p;  in order to prevent man-in-the-middle attacks.

  = If the client has external information as to the expected identity of
&= nbsp;  the server, the hostname check MAY be omitted. (For instance, a=
   client may be connecting to a machine whose address and ho= stname are
   dynamic but the client knows the certificate tha= t the server will
   present.) In such cases, it is important = to narrow the scope of
   acceptable certificates as much as p= ossible in order to prevent man
   in the middle attacks. = ; In special cases, it may be appropriate for
   the client to= simply ignore the server's identity, but it must be
   unders= tood that this leaves the connection open to active attack.

 &n= bsp; If a subjectAltName extension of type dNSName is present, that MUST   be used as the identity. Otherwise, the (most specific) Commo= n Name
   field in the Subject field of the certificate MUST b= e used. Although
   the use of the Common Name is existing pra= ctice, it is deprecated and
   Certification Authorities are e= ncouraged to use the dNSName instead.

   Matching is perfo= rmed using the matching rules specified by
   [RFC2459]. = If more than one identity of a given type is present in
   th= e certificate (e.g., more than one dNSName name, a match in any one
&nbs= p;  of the set is considered acceptable.) Names may contain the wildca= rd
   character * which is considered to match any single doma= in name
   component or component fragment. E.g., *.a.com matc= hes foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com= but not bar.com.

   In some cases, the URI is specified a= s an IP address rather than a
   hostname. In this case, the i= PAddress subjectAltName must be present
   in the certificate = and must exactly match the IP in the URI.

   If the hostna= me does not match the identity in the certificate, user
   ori= ented clients MUST either notify the user (clients MAY give the
 &n= bsp; user the opportunity to continue with the connection in any case) or   terminate the connection with a bad certificate error. Autom= ated
   clients MUST log the error to an appropriate audit log= (if available)
   and SHOULD terminate the connection (with a= bad certificate error).
   Automated clients MAY provide a co= nfiguration setting that disables
   this check, but MUST prov= ide a setting which enables it.

   Note that in many cases= the URI itself comes from an untrusted
   source. The above-d= escribed check provides no protection against
   attacks where= this source is compromised. For example, if the URI was
   ob= tained by clicking on an HTML page which was itself obtained
  = ; without using HTTP/TLS, a man in the middle could have replaced the
&n= bsp;  URI.  In order to prevent this form of attack, users should= carefully
   examine the certificate presented by the server = to determine if it
   meets their expectations.
 
Overall, this reference does seem to have some relevance to the issues disc= ussed in Section 5.3.  In terms of relevance to EAP-TLS, there is typi= cally no URL.  In some cases EAP-TLS server hostname and  IP addr= ess are not known before authentication, and so cannot be compared to = the Server-Id (e.g. 802.11), but in other cases this might be possible (e.g= . VPN).   Paragraphs 5-6 seem relevant, but paragraph 7 is probab= ly not relevant.  Given this, my inclination is to keep the reference = to RFC 2818, but make it normative (since there is a MUST reference to it).=

= --_e6b824c5-0acd-403b-ab89-07b531afca82_-- --===============1411811494== 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 --===============1411811494==-- From emu-bounces@ietf.org Tue May 08 18:51: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 1HlYWL-0002Sq-1F; Tue, 08 May 2007 18:51:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVx-0001oQ-Ti; Tue, 08 May 2007 18:50:37 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlYVx-0007tp-K4; Tue, 08 May 2007 18:50:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8529217606; Tue, 8 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlYVO-0002Eu-8z; Tue, 08 May 2007 18: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: Tue, 08 May 2007 18: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-09.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-09.txt Pages : 31 Date : 2007-5-8 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-09.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-09.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-09.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-5-8150502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simon-emu-rfc2716bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-simon-emu-rfc2716bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-8150502.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --NextPart-- From emu-bounces@ietf.org Tue May 08 18:51:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYWo-0002r3-UI; Tue, 08 May 2007 18:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYWn-0002qZ-U9 for emu@ietf.org; Tue, 08 May 2007 18:51:29 -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 1HlYWm-00036E-W4 for emu@ietf.org; Tue, 08 May 2007 18:51:29 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 May 2007 15:51:28 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208,217"; a="484421682:sNHT105334952" 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 l48MpSl0009475; Tue, 8 May 2007 15:51:28 -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 l48MpFF0020180; Tue, 8 May 2007 22:51:28 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, 8 May 2007 15:51:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Emu] RFC 2818 reference Date: Tue, 8 May 2007 15:51:14 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] RFC 2818 reference Thread-Index: AceRvZ6WF7KBvKzkRIuLWoaBWIA3MQABVtgg From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 08 May 2007 22:51:15.0251 (UTC) FILETIME=[62054030:01C791C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12787; t=1178664688; x=1179528688; 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]=20RFC=202818=20reference |Sender:=20; bh=R7KRGo9q/h2I8G1dlwVF5otlm/aNNZWYXSUpNVuveWQ=; b=p526jBvkHoq33Rv3iolT2QpfKv+09x2nBBfjpTK+KJ1iaCvR7TpMlAbJPLdT1BCCUKGNP+Pm D0w7xcuZ6dxzMLjBhNi5cHqH1rHvlIarA79YLsm9XG9QqP7ZYieo/zVF; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 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="===============0238001811==" Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. --===============0238001811== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C791C3.61CD09D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C791C3.61CD09D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So would the section be revised to clarify when 2818 would be applicable, such as when the hostname and DNS are known ahead of time? ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, May 08, 2007 3:10 PM To: emu@ietf.org Subject: [Emu] RFC 2818 reference =09 =09 A question has arisen about the reference to RFC 2818 section 3.1 within Section 5.3: =20 When performing this comparison implementations MUST follow the validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate presented by the EAP-TLS peer was intended to be used as a client certificate. Implementations SHOULD use the Extended Key Usage (see [RFC3280] Section 4.2.1.13) extension and ensure that at least one of the following is true: =09 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate (see [RFC3280] section 4.2.1.13).=20 =20 Here is the text from that reference: =20 3.1. Server Identity =09 In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. =09 If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack. =09 If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. =09 Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. =09 In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI. =09 If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. =09 Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations. =20 Overall, this reference does seem to have some relevance to the issues discussed in Section 5.3. In terms of relevance to EAP-TLS, there is typically no URL. In some cases EAP-TLS server hostname and IP address are not known before authentication, and so cannot be compared to the Server-Id (e.g. 802.11), but in other cases this might be possible (e.g. VPN). Paragraphs 5-6 seem relevant, but paragraph 7 is probably not relevant. Given this, my inclination is to keep the reference to RFC 2818, but make it normative (since there is a MUST reference to it).=20 =09 =09 ------_=_NextPart_001_01C791C3.61CD09D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So would the section be revised to clarify = when 2818=20 would be applicable, such as when the hostname and DNS are known ahead = of=20 time?

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Tuesday, May 08, = 2007 3:10=20 PM
To: emu@ietf.org
Subject: [Emu] RFC 2818=20 reference


A question has arisen about the reference to RFC 2818 = section=20 3.1 within Section 5.3:
 
   When performing this = comparison implementations MUST follow the
   validation = rules=20 specified in [RFC2818] Section 3.1.  In the case = of
   the=20 server this involves ensuring the certificate presented by = the
  =20 EAP-TLS peer was intended to be used as a client = certificate.
  =20 Implementations SHOULD use the Extended Key Usage (see=20 [RFC3280]
   Section 4.2.1.13) extension and ensure that = at least=20 one of the
   following is true:

   1) = The=20 certificate issuer included no Extended Key=20 Usage
      identifiers in the=20 certificate.
   2) The issuer included the = anyExtendedKeyUsage=20 identifier in
      the certificate (see = [RFC3280]=20 section 4.2.1.13).
   3) The issuer included the = id-kp-clientAuth=20 identifier in
      the certificate (see = [RFC3280]=20 section 4.2.1.13). 
 
Here is the text from that=20 reference:
 
3.1.  Server Identity

   = In=20 general, HTTP/TLS requests are generated by dereferencing a=20 URI.
   As a consequence, the hostname for the server is = known to=20 the client.
   If the hostname is available, the client = MUST=20 check it against the
   server's identity as presented in = the=20 server's Certificate message,
   in order to prevent=20 man-in-the-middle attacks.

   If the client has = external=20 information as to the expected identity of
   the server, = the=20 hostname check MAY be omitted. (For instance, a
   client = may be=20 connecting to a machine whose address and hostname are
   = dynamic=20 but the client knows the certificate that the server = will
  =20 present.) In such cases, it is important to narrow the scope=20 of
   acceptable certificates as much as possible in = order to=20 prevent man
   in the middle attacks.  In special = cases, it=20 may be appropriate for
   the client to simply ignore the = server's identity, but it must be
   understood that this = leaves=20 the connection open to active attack.

   If a = subjectAltName=20 extension of type dNSName is present, that MUST
   be = used as the=20 identity. Otherwise, the (most specific) Common Name
   = field in=20 the Subject field of the certificate MUST be used. = Although
  =20 the use of the Common Name is existing practice, it is deprecated=20 and
   Certification Authorities are encouraged to use = the=20 dNSName instead.

   Matching is performed using the = matching=20 rules specified by
   [RFC2459].  If more than one = identity=20 of a given type is present in
   the certificate (e.g., = more than=20 one dNSName name, a match in any one
   of the set is = considered=20 acceptable.) Names may contain the wildcard
   character = * which=20 is considered to match any single domain name
   = component or=20 component fragment. E.g., *.a.com matches foo.a.com = but
   not=20 bar.foo.a.com. f*.com matches foo.com but not = bar.com.

   In=20 some cases, the URI is specified as an IP address rather than=20 a
   hostname. In this case, the iPAddress subjectAltName = must be=20 present
   in the certificate and must exactly match the = IP in=20 the URI.

   If the hostname does not match the = identity in=20 the certificate, user
   oriented clients MUST either = notify the=20 user (clients MAY give the
   user the opportunity to = continue=20 with the connection in any case) or
   terminate the = connection=20 with a bad certificate error. Automated
   clients MUST = log the=20 error to an appropriate audit log (if available)
   and = SHOULD=20 terminate the connection (with a bad certificate = error).
  =20 Automated clients MAY provide a configuration setting that=20 disables
   this check, but MUST provide a setting which = enables=20 it.

   Note that in many cases the URI itself comes = from an=20 untrusted
   source. The above-described check provides = no=20 protection against
   attacks where this source is = compromised.=20 For example, if the URI was
   obtained by clicking on an = HTML=20 page which was itself obtained
   without using HTTP/TLS, = a man=20 in the middle could have replaced the
   URI.  In = order to=20 prevent this form of attack, users should carefully
   = examine=20 the certificate presented by the server to determine if = it
  =20 meets their expectations.
 
Overall, this reference does = seem to=20 have some relevance to the issues discussed in Section 5.3.  In = terms of=20 relevance to EAP-TLS, there is typically no URL.  In some cases = EAP-TLS=20 server hostname and  IP address are not known before = authentication,=20 and so cannot be compared to the Server-Id (e.g. 802.11), but in other = cases=20 this might be possible (e.g. VPN).   Paragraphs 5-6 seem = relevant,=20 but paragraph 7 is probably not relevant.  Given this, my = inclination is=20 to keep the reference to RFC 2818, but make it normative (since there = is a=20 MUST reference to it).

------_=_NextPart_001_01C791C3.61CD09D0-- --===============0238001811== 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 --===============0238001811==-- From emu-bounces@ietf.org Tue May 08 19:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYvN-0002bt-HQ; Tue, 08 May 2007 19:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYe2-00047g-Jd for emu@ietf.org; Tue, 08 May 2007 18:58:58 -0400 Received: from bay0-omc2-s28.bay0.hotmail.com ([65.54.246.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYac-00068P-W9 for emu@ietf.org; Tue, 08 May 2007 18:55:35 -0400 Received: from BAY117-W21 ([207.46.8.56]) by bay0-omc2-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 8 May 2007 15:55:26 -0700 Message-ID: X-Originating-IP: [131.107.0.106] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Multiple identity issue Date: Tue, 8 May 2007 15:55:26 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 May 2007 22:55:26.0540 (UTC) FILETIME=[F7CCE8C0:01C791C3] X-Spam-Score: 2.4 (++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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="===============0110706357==" Errors-To: emu-bounces@ietf.org --===============0110706357== Content-Type: multipart/alternative; boundary="_ad8788f8-ff5c-488f-a61c-c9f203dbe097_" --_ad8788f8-ff5c-488f-a61c-c9f203dbe097_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The 3rd paragraph of Section 5.2 says: =20 Where the subjectAltName field is present in the peer or server certif= icate, the Peer-Id or Server-Id MUST be set to the contents of the subjec= tAltName. If subject naming information is present only in the subjectAl= tName extension of a peer or server certificate, then the subject field M= UST be an empty sequence and the subjectAltName extension MUST be critica= l. =20 =20 Therefore it would seem that presence of both a single subject and single s= ubjectAltName would not result in export of multiple Peer-Id(s) or Server-I= d(s). This can only happen if there are multiple subjectAltName fields.=20 =20 So how about:=20 =20 "It is possible for more than one subjectAltName field to be presentin a pe= er or server certificate; similarly, it is possible for anon-empty subject = name field to also be present in a peer or servercertificate. Where more t= han one subjectAltName field is present in a certificate,=20 EAP-TLS may export more than one Peer-Id or more than one Server-Id;=20 all of the exported Peer-Id(s) and Server-Id(s) are considered valid. " =20 Joe Salowey said:=20 > looks good, except I think that there can be only one Subject Name field>= in a valid certificate. How about something like: > > "It is possible for = more than one subjectAltName field to be present> in a peer or server certi= ficate; similarly, it is possible for a> non-empty subject name field to al= so be present in a peer or server> certificate. In this case, EAP-TLS may e= xport more than one Peer-Id> or more than one Server-Id; all of the exporte= d Peer-Id(s) and> Server-Id(s) are considered > valid. "> > > _____________= ___________________> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.co= m] > Sent: Tuesday, May 08, 2007 2:54 PM> To: emu@ietf.org> Subject: [Emu] = Multiple identity issue> > > At the EMU WG meeting, we discussed the situat= ion where more> than one altsubjectName or subject field are present in a c= ertificate.> Here is some text which can be added to the end of Section 5.2= to> address this issue:> > "It is possible for more than one subjectAltNam= e field to be> present> in a peer or server certificate; similarly, it is p= ossible for> more> than one subject name field to be present in a peer or s= erver> certificate. In this case, EAP-TLS may export more than one> Peer-Id= > or more than one Server-Id; all of the exported Peer-Id(s) and> Server-Id= (s) are considered > valid. "> > > ________________________________________= _______> Emu mailing list> Emu@ietf.org> https://www1.ietf.org/mailman/list= info/emu= --_ad8788f8-ff5c-488f-a61c-c9f203dbe097_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The 3rd paragraph of Section 5.2 says:
 
   Where the subjectAltName field is present in the peer or serve= r
   certificate, the Peer-Id or Server-Id MUST be set to the = contents of
   the subjectAltName.  If subject naming inf= ormation is present only in
   the subjectAltName extension of= a peer or server certificate, then
   the subject field MUST = be an empty sequence and the subjectAltName
   extension MUST = be critical. 
 
Therefore it would seem that presence of both a single subject an= d single subjectAltName would not result in export of multiple Peer-Id(s) o= r Server-Id(s).  This can only happen if there are multiple subjectAlt= Name fields.
 
So how about:
 
"It is possible for more than one subjectAltName field to be present
in = a peer or server certificate; similarly, it is possible for a
non-empty = subject name field to also be present in a peer or server
certificate.&n= bsp; Where more than one subjectAltName field is present in a certific= ate,
EAP-TLS may export more than one Peer-Id or more than one Server-Id;
all of the exported Peer-Id(s) and Server-Id(s) are considered valid. = "
 

Joe Salowey said:

> looks good, except I think that there can be only one Subject Name= field
> in a valid certificate. How about something like:
> <= BR>> "It is possible for more than one subjectAltName field to be presen= t
> in a peer or server certificate; similarly, it is possible for a<= BR>> non-empty subject name field to also be present in a peer or server=
> certificate. In this case, EAP-TLS may export more than one Peer-I= d
> or more than one Server-Id; all of the exported Peer-Id(s) and> Server-Id(s) are considered
> valid. "
>
>
&g= t; ________________________________
>
> From: Bernard Aboba [m= ailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, May 08, 2007 2:54 = PM
> To: emu@ietf.org
> Subject: [Emu] Multiple identity issue<= BR>>
>
> At the EMU WG meeting, we discussed the situation= where more
> than one altsubjectName or subject field are present in= a certificate.
> Here is some text which can be added to the end of = Section 5.2 to
> address this issue:
>
> "It is possible= for more than one subjectAltName field to be
> present
> in a = peer or server certificate; similarly, it is possible for
> more
&= gt; than one subject name field to be present in a peer or server
> c= ertificate. In this case, EAP-TLS may export more than one
> Peer-Id<= BR>> or more than one Server-Id; all of the exported Peer-Id(s) and
&= gt; Server-Id(s) are considered
> valid. "
>
>
>= _______________________________________________
> Emu mailing list> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
<= BR> = --_ad8788f8-ff5c-488f-a61c-c9f203dbe097_-- --===============0110706357== 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 --===============0110706357==-- From emu-bounces@ietf.org Wed May 09 11:47: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 1HloNr-0004k9-NB; Wed, 09 May 2007 11:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HloNq-0004eM-9Y for emu@ietf.org; Wed, 09 May 2007 11:47:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HloNp-0001KN-Qc for emu@ietf.org; Wed, 09 May 2007 11:47:18 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 May 2007 08:47:17 -0700 X-IronPort-AV: i="4.14,510,1170662400"; d="scan'208"; a="420201088:sNHT47943008" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l49FlHbG018734; Wed, 9 May 2007 08:47:17 -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 l49FlHwn019269; Wed, 9 May 2007 15:47:17 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, 9 May 2007 08:47:16 -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] Multiple identity issue Date: Wed, 9 May 2007 08:47:15 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple identity issue Thread-Index: AceRw/ipXi/pScPBTsefzhnSDhY4ugAjJ0DA From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 09 May 2007 15:47:16.0847 (UTC) FILETIME=[51F697F0:01C79251] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3358; t=1178725637; x=1179589637; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Multiple=20identity=20issue |Sender:=20; bh=3aEUma71zTn7M03blAzW6KcvkQouVgMWBrrE9O7IzBw=; b=Hgy4QntPWEkIiUNGF834RUAjbgBKkWM1afWTVXdfyji4Amq9noGaI6/emHNaoT/zB9O3dzkI GBDm5UQrZJUrPWMZVFYPg4uCJryi4UFHxMbyDPAVOSEU7VKBADrg9mPV; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 it would be more consistent with RFC 3280 if we report a non-empty subject name as well as the subjectAltNames since they all are valid identities within the certificate. =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, May 08, 2007 3:55 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Multiple identity issue >=20 > The 3rd paragraph of Section 5.2 says: > =20 > Where the subjectAltName field is present in the peer or server > certificate, the Peer-Id or Server-Id MUST be set to the=20 > contents of > the subjectAltName. If subject naming information is=20 > present only in > the subjectAltName extension of a peer or server certificate, then > the subject field MUST be an empty sequence and the subjectAltName > extension MUST be critical. =20 > =20 > Therefore it would seem that presence of both a single=20 > subject and single subjectAltName would not result in export=20 > of multiple Peer-Id(s) or Server-Id(s). This can only happen=20 > if there are multiple subjectAltName fields.=20 > =20 > So how about:=20 > =20 > "It is possible for more than one subjectAltName field to be=20 > present in a peer or server certificate; similarly, it is=20 > possible for a non-empty subject name field to also be=20 > present in a peer or server certificate. Where more than one=20 > subjectAltName field is present in a certificate, EAP-TLS may=20 > export more than one Peer-Id or more than one Server-Id; all=20 > of the exported Peer-Id(s) and Server-Id(s) are considered valid. " > =20 >=20 > Joe Salowey said:=20 >=20 > > looks good, except I think that there can be only one Subject Name=20 > > field in a valid certificate. How about something like: > >=20 > > "It is possible for more than one subjectAltName field to=20 > be present=20 > > in a peer or server certificate; similarly, it is possible for a=20 > > non-empty subject name field to also be present in a peer or server=20 > > certificate. In this case, EAP-TLS may export more than one=20 > Peer-Id or=20 > > more than one Server-Id; all of the exported Peer-Id(s) and > > Server-Id(s) are considered > > valid. " > >=20 > >=20 > > ________________________________ > >=20 > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 08, 2007 2:54 PM > > To: emu@ietf.org > > Subject: [Emu] Multiple identity issue > >=20 > >=20 > > At the EMU WG meeting, we discussed the situation where=20 > more than one=20 > > altsubjectName or subject field are present in a certificate. > > Here is some text which can be added to the end of Section 5.2 to=20 > > address this issue: > >=20 > > "It is possible for more than one subjectAltName field to=20 > be present=20 > > in a peer or server certificate; similarly, it is possible for more=20 > > than one subject name field to be present in a peer or server=20 > > certificate. In this case, EAP-TLS may export more than one=20 > Peer-Id or=20 > > more than one Server-Id; all of the exported Peer-Id(s) and > > Server-Id(s) are considered > > valid. " > >=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 Wed May 09 12:10: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 1HlokR-0002jp-Mf; Wed, 09 May 2007 12:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlokP-0002jf-Rf for emu@ietf.org; Wed, 09 May 2007 12:10:37 -0400 Received: from bay0-omc2-s4.bay0.hotmail.com ([65.54.246.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlokO-0005f0-8O for emu@ietf.org; Wed, 09 May 2007 12:10:37 -0400 Received: from BAY117-W1 ([207.46.8.36]) by bay0-omc2-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 9 May 2007 09:10:35 -0700 Message-ID: X-Originating-IP: [72.254.8.87] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , Subject: RE: [Emu] Multiple identity issue Date: Wed, 9 May 2007 09:10:35 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 May 2007 16:10:35.0750 (UTC) FILETIME=[93C64060:01C79254] X-Spam-Score: 2.6 (++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113029499==" Errors-To: emu-bounces@ietf.org --===============0113029499== Content-Type: multipart/alternative; boundary="_310bc76b-4e17-4ffb-9c68-d31ef200bf18_" --_310bc76b-4e17-4ffb-9c68-d31ef200bf18_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think we may need a way to distinguish multiple names for the same entity= (e.g. mutiple subjectAltName/subject fields in a single certificate) from = multiple names that may not refer to the same entity (e.g. Server-Id(s) pro= vided within a tunnel method whose Phase 1 and Phase 2 terminate on differe= nt entities). Also, there is a need to distinguish the identities that def= ine the key scope (e.g. Phase 1 identities from EAP-TTLSv0) from those that= did not contribute to key generation (e.g. Phase 2 identities from EAP-TTL= Sv0).=20 Joe Salowey said:=20 > I think it would be more consistent with RFC 3280 if we report a> non-emp= ty subject name as well as the subjectAltNames since they all> are valid id= entities within the certificate. > > > -----Original Message-----> > From: = Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, May 08,= 2007 3:55 PM> > To: Joseph Salowey (jsalowey); emu@ietf.org> > Subject: RE= : [Emu] Multiple identity issue> > > > The 3rd paragraph of Section 5.2 say= s:> > > > Where the subjectAltName field is present in the peer or server> = > certificate, the Peer-Id or Server-Id MUST be set to the > > contents of>= > the subjectAltName. If subject naming information is > > present only in= > > the subjectAltName extension of a peer or server certificate, then> > t= he subject field MUST be an empty sequence and the subjectAltName> > extens= ion MUST be critical. > > > > Therefore it would seem that presence of both= a single > > subject and single subjectAltName would not result in export = > > of multiple Peer-Id(s) or Server-Id(s). This can only happen > > if the= re are multiple subjectAltName fields. > > > > So how about: > > > > "It is= possible for more than one subjectAltName field to be > > present in a pee= r or server certificate; similarly, it is > > possible for a non-empty subj= ect name field to also be > > present in a peer or server certificate. Wher= e more than one > > subjectAltName field is present in a certificate, EAP-T= LS may > > export more than one Peer-Id or more than one Server-Id; all > >= of the exported Peer-Id(s) and Server-Id(s) are considered valid. "> > > >= > > Joe Salowey said: > > > > > looks good, except I think that there can = be only one Subject Name > > > field in a valid certificate. How about some= thing like:> > > > > > "It is possible for more than one subjectAltName fie= ld to > > be present > > > in a peer or server certificate; similarly, it i= s possible for a > > > non-empty subject name field to also be present in a= peer or server > > > certificate. In this case, EAP-TLS may export more th= an one > > Peer-Id or > > > more than one Server-Id; all of the exported Pe= er-Id(s) and> > > Server-Id(s) are considered> > > valid. "> > > > > > > > = > ________________________________> > > > > > From: Bernard Aboba [mailto:b= ernard_aboba@hotmail.com]> > > Sent: Tuesday, May 08, 2007 2:54 PM> > > To:= emu@ietf.org> > > Subject: [Emu] Multiple identity issue> > > > > > > > > = At the EMU WG meeting, we discussed the situation where > > more than one >= > > altsubjectName or subject field are present in a certificate.> > > Her= e is some text which can be added to the end of Section 5.2 to > > > addres= s this issue:> > > > > > "It is possible for more than one subjectAltName f= ield to > > be present > > > in a peer or server certificate; similarly, it= is possible for more > > > than one subject name field to be present in a = peer or server > > > certificate. In this case, EAP-TLS may export more tha= n one > > Peer-Id or > > > more than one Server-Id; all of the exported Pee= r-Id(s) and> > > Server-Id(s) are considered> > > valid. "> > > > > > > > >= _______________________________________________> > > Emu mailing list> > >= Emu@ietf.org> > > https://www1.ietf.org/mailman/listinfo/emu> > > > > > = --_310bc76b-4e17-4ffb-9c68-d31ef200bf18_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think we may need a way to distinguish multiple names for the same entity= (e.g. mutiple subjectAltName/subject fields in a single certificate) from = multiple names that may not refer to the same entity (e.g. Server-Id(s) pro= vided within a tunnel method whose Phase 1 and Phase 2 terminate on differe= nt entities).  Also, there is a need to distinguish the identities tha= t define the key scope (e.g. Phase 1 identities from EAP-TTLSv0) from those= that did not contribute to key generation (e.g. Phase 2 identities from EA= P-TTLSv0).

Joe Salowey said:

> I think it would be more consistent with RFC 3280 if we report a
&g= t; non-empty subject name as well as the subjectAltNames since they all
= > are valid identities within the certificate.
>
> > --= ---Original Message-----
> > From: Bernard Aboba [mailto:bernard_a= boba@hotmail.com]
> > Sent: Tuesday, May 08, 2007 3:55 PM
>= > To: Joseph Salowey (jsalowey); emu@ietf.org
> > Subject: RE:= [Emu] Multiple identity issue
> >
> > The 3rd paragraph= of Section 5.2 says:
> >
> > Where the subjectAltName f= ield is present in the peer or server
> > certificate, the Peer-Id= or Server-Id MUST be set to the
> > contents of
> > the= subjectAltName. If subject naming information is
> > present onl= y in
> > the subjectAltName extension of a peer or server certific= ate, then
> > the subject field MUST be an empty sequence and the = subjectAltName
> > extension MUST be critical.
> >
&= gt; > Therefore it would seem that presence of both a single
> &g= t; subject and single subjectAltName would not result in export
> &g= t; of multiple Peer-Id(s) or Server-Id(s). This can only happen
> &g= t; if there are multiple subjectAltName fields.
> >
> >= So how about:
> >
> > "It is possible for more than on= e subjectAltName field to be
> > present in a peer or server cert= ificate; similarly, it is
> > possible for a non-empty subject na= me field to also be
> > present in a peer or server certificate. = Where more than one
> > subjectAltName field is present in a cert= ificate, EAP-TLS may
> > export more than one Peer-Id or more tha= n one Server-Id; all
> > of the exported Peer-Id(s) and Server-Id= (s) are considered valid. "
> >
> >
> > Joe Sa= lowey said:
> >
> > > looks good, except I think tha= t there can be only one Subject Name
> > > field in a valid ce= rtificate. How about something like:
> > >
> > > "= It is possible for more than one subjectAltName field to
> > be p= resent
> > > in a peer or server certificate; similarly, it is= possible for a
> > > non-empty subject name field to also be = present in a peer or server
> > > certificate. In this case, E= AP-TLS may export more than one
> > Peer-Id or
> > >= more than one Server-Id; all of the exported Peer-Id(s) and
> > &= gt; Server-Id(s) are considered
> > > valid. "
> > >= ;
> > >
> > > ________________________________> > >
> > > From: Bernard Aboba [mailto:bernard_abob= a@hotmail.com]
> > > Sent: Tuesday, May 08, 2007 2:54 PM
>= ; > > To: emu@ietf.org
> > > Subject: [Emu] Multiple iden= tity issue
> > >
> > >
> > > At the E= MU WG meeting, we discussed the situation where
> > more than one=
> > > altsubjectName or subject field are present in a certif= icate.
> > > Here is some text which can be added to the end of= Section 5.2 to
> > > address this issue:
> > > > > > "It is possible for more than one subjectAltName field to =
> > be present
> > > in a peer or server certificate= ; similarly, it is possible for more
> > > than one subject na= me field to be present in a peer or server
> > > certificate. = In this case, EAP-TLS may export more than one
> > Peer-Id or > > > more than one Server-Id; all of the exported Peer-Id(s) and=
> > > Server-Id(s) are considered
> > > valid. "> > >
> > >
> > > ____________________= ___________________________
> > > Emu mailing list
> >= > Emu@ietf.org
> > > https://www1.ietf.org/mailman/listinfo= /emu
> >
> >
> >

= --_310bc76b-4e17-4ffb-9c68-d31ef200bf18_-- --===============0113029499== 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 --===============0113029499==-- From emu-bounces@ietf.org Wed May 09 12:53: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 1HlpQN-0002P5-6P; Wed, 09 May 2007 12:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpQM-0002O5-Mz for emu@ietf.org; Wed, 09 May 2007 12:53:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlpQM-00042f-3l for emu@ietf.org; Wed, 09 May 2007 12:53:58 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 May 2007 09:53:58 -0700 X-IronPort-AV: i="4.14,510,1170662400"; d="scan'208"; a="420222681:sNHT49779654" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l49GrvST024884; Wed, 9 May 2007 09:53:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l49GrdAa000285; Wed, 9 May 2007 16:53:57 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); Wed, 9 May 2007 09:53:35 -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] Multiple identity issue Date: Wed, 9 May 2007 09:53:36 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Multiple identity issue Thread-Index: AceSVJSlbFUFinB5RJeEl9Nj6EeePgABaLOQ From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , X-OriginalArrivalTime: 09 May 2007 16:53:35.0932 (UTC) FILETIME=[95AEC7C0:01C7925A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4847; t=1178729637; x=1179593637; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Emu]=20Multiple=20identity=20issue |Sender:=20; bh=w9gerdE7+dmrmkDBH9nKVOTu0lO6noLtuXob+NgSOhQ=; b=Dvd2xanhVvNVx3g6C9qf7kZ+2r6uSlY5jgjP1YrxNZ49wogZ1ppYTlbk+t7nAQF9WQgexpHU VCKs9no4fV3qKPBrvDL5pk7WVLEgxU/kifSJG3bxyX54i+3/SgNpxFlA; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Yes, probably, but for EAP-TLS what we are talking about are names for the same entity which are the peer or the server. =20 I think new definitions are needed for these other concepts, which are not currently part of EAP-TLS.=20 Joe > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Wednesday, May 09, 2007 9:11 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Multiple identity issue >=20 > I think we may need a way to distinguish multiple names for=20 > the same entity (e.g. mutiple subjectAltName/subject fields=20 > in a single certificate) from multiple names that may not=20 > refer to the same entity (e.g. Server-Id(s) provided within a=20 > tunnel method whose Phase 1 and Phase 2 terminate on=20 > different entities). Also, there is a need to distinguish=20 > the identities that define the key scope (e.g. Phase 1=20 > identities from EAP-TTLSv0) from those that did not=20 > contribute to key generation (e.g. Phase 2 identities from=20 > EAP-TTLSv0).=20 >=20 > Joe Salowey said:=20 >=20 > > I think it would be more consistent with RFC 3280 if we report a=20 > > non-empty subject name as well as the subjectAltNames since=20 > they all=20 > > are valid identities within the certificate. > >=20 > > > -----Original Message----- > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > Sent: Tuesday, May 08, 2007 3:55 PM > > > To: Joseph Salowey (jsalowey); emu@ietf.org > > > Subject: RE: [Emu] Multiple identity issue > > >=20 > > > The 3rd paragraph of Section 5.2 says: > > >=20 > > > Where the subjectAltName field is present in the peer or server=20 > > > certificate, the Peer-Id or Server-Id MUST be set to the=20 > contents of=20 > > > the subjectAltName. If subject naming information is=20 > present only in=20 > > > the subjectAltName extension of a peer or server=20 > certificate, then=20 > > > the subject field MUST be an empty sequence and the=20 > subjectAltName=20 > > > extension MUST be critical. > > >=20 > > > Therefore it would seem that presence of both a single=20 > subject and=20 > > > single subjectAltName would not result in export of multiple=20 > > > Peer-Id(s) or Server-Id(s). This can only happen if there are=20 > > > multiple subjectAltName fields. > > >=20 > > > So how about:=20 > > >=20 > > > "It is possible for more than one subjectAltName field to=20 > be present=20 > > > in a peer or server certificate; similarly, it is possible for a=20 > > > non-empty subject name field to also be present in a peer=20 > or server=20 > > > certificate. Where more than one subjectAltName field is=20 > present in=20 > > > a certificate, EAP-TLS may export more than one Peer-Id=20 > or more than=20 > > > one Server-Id; all of the exported Peer-Id(s) and=20 > Server-Id(s) are=20 > > > considered valid. " > > >=20 > > >=20 > > > Joe Salowey said:=20 > > >=20 > > > > looks good, except I think that there can be only one=20 > Subject Name=20 > > > > field in a valid certificate. How about something like: > > > >=20 > > > > "It is possible for more than one subjectAltName field to > > > be present > > > > in a peer or server certificate; similarly, it is=20 > possible for a=20 > > > > non-empty subject name field to also be present in a peer or=20 > > > > server certificate. In this case, EAP-TLS may export=20 > more than one > > > Peer-Id or > > > > more than one Server-Id; all of the exported Peer-Id(s) and > > > > Server-Id(s) are considered > > > > valid. " > > > >=20 > > > >=20 > > > > ________________________________ > > > >=20 > > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > > > Sent: Tuesday, May 08, 2007 2:54 PM > > > > To: emu@ietf.org > > > > Subject: [Emu] Multiple identity issue > > > >=20 > > > >=20 > > > > At the EMU WG meeting, we discussed the situation where > > > more than one > > > > altsubjectName or subject field are present in a certificate. > > > > Here is some text which can be added to the end of=20 > Section 5.2 to=20 > > > > address this issue: > > > >=20 > > > > "It is possible for more than one subjectAltName field to > > > be present > > > > in a peer or server certificate; similarly, it is possible for=20 > > > > more than one subject name field to be present in a=20 > peer or server=20 > > > > certificate. In this case, EAP-TLS may export more than one > > > Peer-Id or > > > > more than one Server-Id; all of the exported Peer-Id(s) and > > > > Server-Id(s) are considered > > > > valid. " > > > >=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