From glenzorn@comcast.net Sun May 3 00:03:20 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888F23A6B19 for ; Sun, 3 May 2009 00:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3OAUMRWTGB1 for ; Sun, 3 May 2009 00:03:19 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id A95913A6ADA for ; Sun, 3 May 2009 00:03:19 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id muzT1b00716AWCUA4v4l9u; Sun, 03 May 2009 07:04:45 +0000 Received: from gwzPC ([210.57.242.40]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id mv4a1b0090t0P5u8Sv4eEk; Sun, 03 May 2009 07:04:43 +0000 From: "Glen Zorn" To: Date: Sun, 3 May 2009 16:04:32 +0900 Message-ID: <006301c9cbbd$6e621930$4b264b90$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0064_01C9CC08.DE49C130" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnLsoOkdCYEKy3SSYGNh0atg3sZHQACte6Q Content-Language: en-us Subject: [Emu] FW: I-D Action:draft-clancy-emu-aaapay-02.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 07:03:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01C9CC08.DE49C130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Sunday, May 03, 2009 2:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-clancy-emu-aaapay-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Method Support for Transporting AAA Payloads Author(s) : C. Clancy, et al. Filename : draft-clancy-emu-aaapay-02.txt Pages : 9 Date : 2009-05-02 This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-clancy-emu-aaapay-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0064_01C9CC08.DE49C130 Content-Type: Message/External-body; name="draft-clancy-emu-aaapay-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-clancy-emu-aaapay-02.txt" Content-Type: text/plain Content-ID: <2009-05-02223246.I-D@ietf.org> ------=_NextPart_000_0064_01C9CC08.DE49C130 Content-Type: text/plain; name="ATT00091.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00091.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0064_01C9CC08.DE49C130-- From bernard_aboba@hotmail.com Tue May 5 04:09:33 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC58D3A717E for ; Tue, 5 May 2009 04:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vztvl0DUQpU for ; Tue, 5 May 2009 04:09:32 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id A44C83A6D69 for ; Tue, 5 May 2009 04:09:32 -0700 (PDT) Received: from BLU137-W4 ([65.55.116.74]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 04:10:59 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_56e3fc4d-9fd7-40b2-a90e-748146b6cd4f_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Date: Tue, 5 May 2009 04:10:59 -0700 Importance: Normal In-Reply-To: <2828BDE8DC61004E8104C78E82A0B39715D2F50A84@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <5732FB56D3427441A21EC6D531B6C225019E4866@STORK.scenix.com> <2828BDE8DC61004E8104C78E82A0B39715D2F50A84@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 X-OriginalArrivalTime: 05 May 2009 11:10:59.0489 (UTC) FILETIME=[2B66C110:01C9CD72] Subject: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 11:09:33 -0000 --_56e3fc4d-9fd7-40b2-a90e-748146b6cd4f_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ________________________________________ From: Murat Sezgin [msezgin@ubicom.com] Sent: Tuesday=2C May 05=2C 2009 3:27 AM To: Dan Simon=3B Bernard Aboba=3B Ryan Hurst Subject: RFC5216 - L-Flag in the fragment packets =20 Hi Mr.Simon=2C Mr.Aboba and Mr.Hurst =20 In the =932.1.5 Fragmentation=94 section of the RFC5216=2C it is written t= hat =93The L flag is set to indicate the presence of the four-octet TLS Mes= sage Length field=2C and MUST be set for the first fragment of a fragmented= TLS message or set of messages=94. Here=2C it is not clear that the other = fragments must or must not include this L-flag set. On the other hand=2C th= e RFC5281-- EAP-TTLS=2C indicates that =93Fragments other than the first MU= ST NOT have the L bit set=94. Is there a L-flag inconsistency between the = EAP-TLS and EAP-TTLS fragments. Do you think you need to explicitly put the= same statement in the RFC5216? =20 In the FreeRadius implementation=2C there is an option called =93include_l= ength=94 in the tls module configuration section of eap.conf file=2C its de= fault value is set to =93yes=94=2C and with this configuration the server s= ends the L-flag in each fragment=2C this is not consistent with the TTLS RF= C. FreeRadius=92s TTLS implementation also uses this option in its TLS hand= shake phase. Regards=2C Murat Sezgin Software Engineer www.ubicom.com =20 --_56e3fc4d-9fd7-40b2-a90e-748146b6cd4f_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 =3B________________________________________
 =3BFrom: M= urat Sezgin [msezgin@ubicom.com]
 =3BSent: Tuesday=2C May 05=2C 2009= 3:27 AM
 =3BTo: Dan Simon=3B Bernard Aboba=3B Ryan Hurst
 = =3BSubject: RFC5216 - L-Flag in the fragment packets
 =3B
 = =3BHi Mr.Simon=2C Mr.Aboba and Mr.Hurst
 =3B
 =3BIn the =932= .1.5 Fragmentation=94 section of the RFC5216=2C it is written that =93The L= flag is set to indicate the presence of the four-octet TLS Message Length = field=2C and MUST be set for the first fragment of a fragmented TLS message= or set of messages=94. Here=2C it is not clear that the other fragments mu= st or must not include this L-flag set. On the other hand=2C the RFC5281-- = EAP-TTLS=2C indicates that =93Fragments other than the first MUST NOT have = the L bit set=94. Is there a L-flag inconsistency between the EAP-TLS and = EAP-TTLS fragments. Do you think you need to explicitly put the same statem= ent in the RFC5216?
 =3B
 =3BIn the FreeRadius implementation= =2C there is an option called =93include_length=94 in the tls module config= uration section of eap.conf file=2C its default value is set to =93yes=94= =2C and with this configuration the server sends the L-flag in each fragmen= t=2C this is not consistent with the TTLS RFC. FreeRadius=92s TTLS implemen= tation also uses this option in its TLS handshake phase.

 =3BReg= ards=2C
 =3BMurat Sezgin
 =3BSoftware Engineer
 =3Bwww= .ubicom.com
 =3B
= --_56e3fc4d-9fd7-40b2-a90e-748146b6cd4f_-- From j@w1.fi Tue May 5 05:24:13 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E07F3A7191 for ; Tue, 5 May 2009 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWG8MMltT7Qm for ; Tue, 5 May 2009 05:24:12 -0700 (PDT) Received: from jmalinen.user.openhosting.com (128-177-27-249.ip.openhosting.com [128.177.27.249]) by core3.amsl.com (Postfix) with ESMTP id 893143A7190 for ; Tue, 5 May 2009 05:24:12 -0700 (PDT) Received: from jm (a91-155-82-88.elisa-laajakaista.fi [91.155.82.88]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id n45CPWA6024155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 08:25:34 -0400 Received: by jm (sSMTP sendmail emulation); Tue, 05 May 2009 15:25:32 +0300 Date: Tue, 5 May 2009 15:25:32 +0300 From: Jouni Malinen To: Bernard Aboba Message-ID: <20090505122532.GB2543@jm.kir.nu> References: <5732FB56D3427441A21EC6D531B6C225019E4866@STORK.scenix.com> <2828BDE8DC61004E8104C78E82A0B39715D2F50A84@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: emu@ietf.org Subject: Re: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:24:13 -0000 > From: Murat Sezgin [msezgin@ubicom.com] > In the “2.1.5 Fragmentation” section of the RFC5216, it is written that “The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages”. Here, it is not clear that the other fragments must or must not include this L-flag set. On the other hand, the RFC5281-- EAP-TTLS, indicates that “Fragments other than the first MUST NOT have the L bit set”. Is there a L-flag inconsistency between the EAP-TLS and EAP-TTLS fragments. Do you think you need to explicitly put the same statement in the RFC5216? The situation with the L-Flag in EAP methods that use TLS (TLS, PEAP, TTLS, FAST) is actually even more confusing than this particular detail might suggest. For example, PEAPv0 seems to require that the TLS Message Length is included even in unfragmented frames in Phase 1 (however, it is not allowed to be included in Phase 2!) or at least a deployed and commonly used server requires such behavior to interoperate properly for certain cases. Taken into account that many implementations share code between EAP-TLS/PEAP/TTLS/FAST, it would be great if these methods were to use the same rules for fragmentation. Alas, I do not think that this would be feasible due to conflicting requirements in the specifications and/or deployed implementations.. Anyway, it would be great if all new RFCs touching this area have clear statements describing the exact and consistent (at least within the EAP method) use of the TLS Message Length field for all frames, so that we could hopefully avoid getting even more variance on how this needs to be processed in the future. > In the FreeRadius implementation, there is an option called “include_length” in the tls module configuration section of eap.conf file, its default value is set to “yes”, and with this configuration the server sends the L-flag in each fragment, this is not consistent with the TTLS RFC. FreeRadius’s TTLS implementation also uses this option in its TLS handshake phase. So far, I've never needed to include the TLS Message Length in any other frame than the first fragmented. However, I have had to implement workarounds to allow the non-fragmented frames to get special handling in some cases, i.e., to get the TLS Message Length added into them (both for all frames and also with the difference in Phase 1 vs. Phase 2 as described above). Obviously, this is not really a desired situation since it takes considerable amount of time to come up with all the needed workarounds to interoperate with existing implementations. -- Jouni Malinen PGP id EFC895FA From jrausch@juniper.net Tue May 5 10:26:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293D33A71BD for ; Tue, 5 May 2009 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzCxlQk4IETO for ; Tue, 5 May 2009 10:26:42 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 22DC828C244 for ; Tue, 5 May 2009 10:26:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSgB2/v1KIA21saUDGP7PN2R0SGYUjz9u@postini.com; Tue, 05 May 2009 10:27:27 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 5 May 2009 10:26:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 5 May 2009 13:26:42 -0400 From: Jonathan Rausch To: "'emu@ietf.org'" Date: Tue, 5 May 2009 13:26:42 -0400 Thread-Topic: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) Thread-Index: AcnNci5ylnNhUgg6Q3+lLaAnu+p2SQAB3megAAIwzeAAAOLmEAACeqMwAAR+gGAAAHXR0AAAE2yw Message-ID: <48A3702B6745EC48BA1F7EBE2184707496B2226731@EMBX01-WF.jnpr.net> References: <0EC737CDF53698408D52FF82864745BB3977772B8D@EMBX01-HQ.jnpr.net> <48A3702B6745EC48BA1F7EBE2184707496B222672F@EMBX01-WF.jnpr.net> <48A3702B6745EC48BA1F7EBE2184707496B2226730@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48A3702B6745EC48BA1F7EBE2184707496B2226731EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Steven Erickson , Clifford Kahn Subject: Re: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:29:04 -0000 --_000_48A3702B6745EC48BA1F7EBE2184707496B2226731EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the Juniper Networks implementation of both EAP-TTLS and EAP-TLS, used b= oth in the Steel Belted RADIUS and the UAC NAC products, the L bit is set a= nd the Length field is added only in the first fragment of the EAP-TTLS or = EAP-TLS message. All other fragments do not contain the length field and t= he L bit is not set. There is no option to set the L bit and add the lengt= h field on every fragment. In a non-fragmented message the L bit is set an= d the length field is added. This is in line with what is stated in RFC528= 1: "If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant)." Juniper's versions of both EAP methods are implemented the same way in rega= rds to the L-bit and length field, and if there is a perceived inconsistenc= y between the two RFCs perhaps it should be clarified. Regards, Jonathan Rausch Software Engineer Service Layer Technologies Business Group Juniper Networks, Inc. ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Berna= rd Aboba Sent: Tuesday, May 05, 2009 4:11 AM To: emu@ietf.org Subject: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) ________________________________________ From: Murat Sezgin [msezgin@ubicom.com] Sent: Tuesday, May 05, 2009 3:27 AM To: Dan Simon; Bernard Aboba; Ryan Hurst Subject: RFC5216 - L-Flag in the fragment packets Hi Mr.Simon, Mr.Aboba and Mr.Hurst In the "2.1.5 Fragmentation" section of the RFC5216, it is written that "T= he L flag is set to indicate the presence of the four-octet TLS Message Len= gth field, and MUST be set for the first fragment of a fragmented TLS messa= ge or set of messages". Here, it is not clear that the other fragments must= or must not include this L-flag set. On the other hand, the RFC5281-- EAP-= TTLS, indicates that "Fragments other than the first MUST NOT have the L bi= t set". Is there a L-flag inconsistency between the EAP-TLS and EAP-TTLS fr= agments. Do you think you need to explicitly put the same statement in the = RFC5216? In the FreeRadius implementation, there is an option called "include_lengt= h" in the tls module configuration section of eap.conf file, its default va= lue is set to "yes", and with this configuration the server sends the L-fla= g in each fragment, this is not consistent with the TTLS RFC. FreeRadius's = TTLS implementation also uses this option in its TLS handshake phase. Regards, Murat Sezgin Software Engineer www.ubicom.com --_000_48A3702B6745EC48BA1F7EBE2184707496B2226731EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the Juniper Networks implementation= of both EAP-TTLS and EAP-TLS, used both in the Steel Belted RADIUS and the UAC NAC products, the L bit is set and the Length field is added only in the first fragment of the EAP-TTLS or EAP-TLS message.  All other fragments do n= ot contain the length field and the L bit is not set.  There is no option= to set the L bit and add the length field on every fragment.  In a non-fragmented message the L bit is set and the length field is added. &nbs= p;This is in line with what is stated in RFC5281:

 

“If there are multiple fr=
agments, the first fragment MUST have the L
bit set and =
include the length of the entire raw message prior to
fragmentatio=
n.  Fragments other than the first MUST NOT have the L
bit set.&nbs=
p; Unfragmented messages MAY have the L bit set and include
the length o=
f the message (though this information is redundant).R=
20;

 

Juniper’s versions of both EAP methods are implemented the same way in regards to the L-bit and length fie= ld, and if there is a perceived inconsistency between the two RFCs perhaps it should be clarified.

 

Regards,

Jonathan Rausch

 

Software Engineer

Service Layer Technologies Business Gr= oup

Juniper Networks, Inc.

 

From:= emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, May 05, 2009 = 4:11 AM
To: emu@ietf.org
Subject: [Emu] RFC5216 - L-F= lag in the fragment packets (fwd)



 ________________________________________
 From: Murat Sezgin [msezgin@ubicom.com]
 Sent: Tuesday, May 05, 2009 3:27 AM
 To: Dan Simon; Bernard Aboba; Ryan Hurst
 Subject: RFC5216 - L-Flag in the fragment packets
 
 Hi Mr.Simon, Mr.Aboba and Mr.Hurst
 
 In the “2.1.5 Fragmentation” section of the RFC5216, it i= s written that “The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment= of a fragmented TLS message or set of messages”. Here, it is not clear t= hat the other fragments must or must not include this L-flag set. On the other hand, the RFC5281-- EAP-TTLS, indicates that “Fragments other than th= e first MUST NOT have the L bit set”. Is there a L-flag inconsistency between the EAP-TLS and EAP-TTLS fragments. Do you think you need to explic= itly put the same statement in the RFC5216?
 
 In the FreeRadius implementation, there is an option called “include_length” in the tls module configuration section of eap.conf file, its default value is set to “yes”, and with this configuration the server sends the L-flag in each fragment, this is not consistent with the TTLS RFC. FreeRadius’s TTLS implementation also u= ses this option in its TLS handshake phase.

 Regards,
 Murat Sezgin
 Software Engineer
 www.ubicom.com
 

--_000_48A3702B6745EC48BA1F7EBE2184707496B2226731EMBX01WFjnprn_-- From aland@deployingradius.com Thu May 7 01:47:36 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F86C3A6F47 for ; Thu, 7 May 2009 01:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1iH24Ub2rIk for ; Thu, 7 May 2009 01:47:35 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 56FAF28C272 for ; Thu, 7 May 2009 01:46:43 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id C9D2F12343A4 for ; Thu, 7 May 2009 10:48:10 +0200 (CEST) Message-ID: <4A02A04B.7030503@deployingradius.com> Date: Thu, 07 May 2009 10:48:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: emu@ietf.org References: <5732FB56D3427441A21EC6D531B6C225019E4866@STORK.scenix.com> <2828BDE8DC61004E8104C78E82A0B39715D2F50A84@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Emu] RFC5216 - L-Flag in the fragment packets (fwd) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 08:47:36 -0000 Bernard Aboba wrote: > In the FreeRadius implementation, there is an option called > include_length in the tls module configuration section of eap.conf > file, its default value is set to yes, and with this configuration the > server sends the L-flag in each fragment, this is not consistent with > the TTLS RFC. FreeRadiuss TTLS implementation also uses this option in > its TLS handshake phase. All I can say is that it's inter-operable with everything out there. In any case, future releases will have this behavior configurable. Alan DeKok. From khoeper@motorola.com Thu May 28 16:01:52 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C748C3A68D9 for ; Thu, 28 May 2009 16:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTjXh6E1ULy8 for ; Thu, 28 May 2009 16:01:51 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id D4A023A67C0 for ; Thu, 28 May 2009 16:01:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-6.tower-55.messagelabs.com!1243551812!12363478!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7783 invoked from network); 28 May 2009 23:03:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 May 2009 23:03:33 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n4SN3RMu005223 for ; Thu, 28 May 2009 16:03:32 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n4SN3Rox006837 for ; Thu, 28 May 2009 18:03:27 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n4SN3Qh9006834 for ; Thu, 28 May 2009 18:03:26 -0500 (CDT) 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: Thu, 28 May 2009 19:03:04 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F060EE03A@de01exm68.ds.mot.com> In-Reply-To: <49F6BDAE.2010101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of chbind-01 thread-index: AcnH2wY7iCu/YEXhSXKHhoSRoYAPcAX+bc3w References: <49F6BDAE.2010101@cisco.com> From: "Hoeper Katrin-QWKN37" To: "Klaas Wierenga" X-CFilter-Loop: Reflected Cc: emu@ietf.org Subject: Re: [Emu] review of chbind-01 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 23:01:52 -0000 Hello Klaas, Thank you for your very thorough review! And sorry that it took me so long to reply. My replies are in-line and will be reflected in the next draft version that I plan on posting shortly.=20 I would appreciate your and the group's feedback on whether I addressed all your comments.=20 I'd like to ask the group to check Klaas' primary comment since it is concerned with the scope of the draft. I'd be interested to know who shares this concern and whether the current draft should be modified accordingly. You'll find my opinion on this matter among my other replies below. Regards, Katrin -----Original Message----- From: Klaas Wierenga [mailto:klaas@cisco.com]=20 Sent: Tuesday, April 28, 2009 3:26 AM To: Hoeper Katrin-QWKN37 Cc: emu@ietf.org Subject: review of chbind-01 Hi Katrin, I have reviewed your draft and I think the content is in principle in=20 pretty good shape, see my comments further below. I have however a more=20 fundamental concern that I would like to hear your (and others') opinion about. I have the feeling that the draft is too complicated because you mix=20 two, only loosely related, problems. The way I see it there are 2=20 fundamental issues: 1) the NAS talks to both the peer and to the authentication server and=20 the information given to both doesn't have to be consistent 2) the NAS gives information to authentication server (via the peer or=20 not) and the authentication server needs to evaluate that information=20 and make policy decisions based on that. Issue 1 is for me the one that most needs solving, and I would prefer=20 this draft to focus on that one only. Issue 2 is not so much a technical problem as a business problem. The administrative entities controlling=20 respectively the NAS and the AuthN server need to agree on the info they exchange and it is than up to the administrative entity to process=20 that info (and log it for non-repudiation purposes etc.) and make policy decisions on them. Wrt to issue 1 I wonder if it is not sufficient to just "close the=20 loop", i.e. have the NAS send the same info to both peer and AuthN=20 server. Or alternatively, have all the info flow through the peer, that=20 way you can be sure that peer and AuthN server have a consistent view of what the NAS offers. [KH] I agree that the solution presented in the current draft consists of a technical part (exchange end-to-end secured information between the peer & server, verify it and notify the peer about the result) and an administrative part (setting up a database to support the consistency and compliance checks of the exchanged channel binding information). Introducing a database to the network model is absolute essential for the solution to work. First of all, the exchanged information cannot be directly compared because peer and server may have a different view of the network information provided by the NAS/authenticator. For example, the peer may identify a NAS by its SSID, whereas the EAP server may only know the NAS-IP-Address. In order for the server to check whether both addresses belong to the same device, a table look-up is required. Such look-up tables are stored in the local database. Secondly, in roaming scenarios the server cannot "know" each NAS of all visited networks that the home network has a roaming agreement with. Here, the server can only check whether the information broadcasted by a NAS in a visited network complies with the roaming agreement with this network. For that reason, rules derived from the agreements and policies need to be stored in a database, such that the server can use these rules for its consistency/compliance checks.=20 I hope we can agree on that a database is absolute essential for implementing meaningful channel bindings and that channel bindings in roaming scenarios need to make use of rules that have been derived from agreements and/or policies. The draft does not say how these rules are derived, that is indeed outside the scope. Bernard suggested in one of his earlier reviews to utilize such policy compliance checks to validate authorizations, e.g. checking whether a peer is authorized to access a particular part of a network or using a particular media. In addition, the solution enables the server to check whether an authenticator is authorized to grant access to a peer under the given circumstances. These authorization checks are included in the draft and are carried out by additional compliance checks. IMO this is a nice feature that can be achieved using channel bindings without changing the underlying protocol. It only requires additional information to be stored in the database. If there is a consensus that this feature should be outside the scope of the draft, it could be moved to a separate draft. Again, though, the local database and some compliance checks would still be a part of the remaining channel binding solution. ------------------------------------------------------ My concrete comments: 1, par 2: "while there may be some identity tied to that security=20 association" What do you mean with "identity", are you talking about NAS-identifier,=20 or something more generic? [KH] Yes, we are referring to NAS-IP-Address, NAS-Identifier and such. Proposed solution: "While there may be some identity tied to that security association, such as the NAS-Identifier, there's no reason the access point needs to advertize a consistent identity to clients."=20 1, par 4: "consistent with the defined network policy" I think it is not so much consistent as well as that is 'satisfies' the=20 defined network policies [KH] Agree. What about 'compliant' instead? In addition, I think its best to explicitly distinguish between the consistency and the compliance checks. Proposed solution: "This allows the server to verify the authenticator is providing information to the peer that is 1) consistent with the information stored about this authenticator and 2) compliant with the defined network policy. In addition, the presented solution allows the server to verify that the peer is authorized to access the network in the manner described by the NAS." 3, par 1: I think you should call out here that proxy's are an example=20 of that, you mention it later but it helps to give the reader an idea=20 what you are talking about. [KH] Agree. Proposed solution: "Additionally, while an authenticator may not be compromised, other compromised elements in the networks (such as proxies), could provide false information to the authenticator..."=20 3, examples: I don't find the examples very compelling, how about for=20 example a NAS giving wrong billing info to the peer "5$ all you can eat, while sending per minute rates to the Auth server? [KH] The current roaming example was chosen to illustrate an attack where victims are not aware of that they are actually roaming. If you (or anybody else) can come up with a more compelling example for the enterprise case, please let me know. Proposed solution: I will add another simple example to the Service Provider Network case along the lines of what you suggested. 4: "...do not ensure the binding different layers..." -> "...the binding OF different layers..." [KH] Corrected. 4.1: is the fact whether it is plaintext or opaque the unique=20 difference? I would argue that it is whether it is in a separate channel or inline in the session key derivation. I think the plaintext vs opaque doesn't add anything here, later in your requirements you point out that the info sent needs to be protected, that seems enough to me. [KH] Here, we wanted to emphasize that only the exchange of the data allows an analysis of the information rather than a bitwise comparison. Latter only works for identical information (not always feasible, see different address/identifier discussion) that is exactly encoded in the same way (not really practical).=20 Proposed solution: "The peer and server can both uniquely encode their respective view of the network information without exchanging it, resulting into an opaque blob that can be included directly into the derivation of EAP session keys." 4.2.: is it not enough to just say that the AuthN server and the peer=20 need to get the same info? isConsistent would become isEqual, much=20 easier to compute...... ;-) Unfortunately, isEqual is not feasible (see earlier discussion and address/identifier example). Another way to put it: Let's imagine peer and NAS/authenticator speak Dutch with each other, whereas the NAS/authenticator and the authentication server speak German. The isConsistent check allows us to verify whether both pieces of information have the same meaning (using the dictionary stored in the local database). On the other hand, the isEqual check will always fail. Proposed solution: none. 5.1, par 1: isConsistant -> isConsistent [KH] Corrected. 5.2, par 1: conistency of i1 and i2 and evaluating the policy is indeed=20 nontrivial, but policy evaluation should imo be out of scope for this=20 draft anyway. Policy verification is a local problem at the Auth server=20 side, it has nothing to do withy the communication protocols. [KH] See my reply to your first comment. 6.2: "EAP methods MUST be able to import channel binding data from the=20 lower layer...." I don't understand this requirement, what type of data are we talking about? [KH] For example, a peer should include the SSID received in the Beacon of a NAS/authenticator in i1. Consequently, a peer must be able to include information in i1 that has not been received as part of the EAP method. In order to do this, the EAP method must be able to access this kind of information from a lower layer. Proposed solution: none 7.2: NAS-Port-Type Why a MUST? I can imagine many use cases where from a policy point of=20 view I couldn't care less what medium type I am using [KH] Agree Proposed solution: change to SHOULD 7.3: again, why a MUST? [KH] Disagree. This is not a policy question. This AVP is essential for mitigating lying NAS attacks and thus should be a MUST. Proposed solution: none 7.3.?: I think it worthwhile including 802.11u, after all this deals=20 with NASes communicating data about their network to the peers, that is=20 exactly what 11u does. [KH] Older draft versions included additional link-layers (admittedly not 11u), but were removed due to lack of feedback from the group on which AVPs should be included. Instead a few general attributes are provided that are useful to all link-layers (Section 7.2) and attributes for .11, 11r and 11s are listed as an example (Section 7.3). This is intended to provide a guideline for implementers to choose appropriate attributes when implementing channel bindings on different link layers. If you (or somebody else) happen to know which 11u AVPs should be used here, please let me know and I include them. Proposed solution: none, unless feedback from group is received 9.1: There is also trust between NAS/Authenticator and AuthN server. The=20 Authenticator relies on the Authentication server for policy decisions. [KH] The trust model for channel bindings assumes that peer and server are honest, while the authenticator is the potential attacker (e.g. lying NAS attack, etc). In a trust model you usually don't care who the attacker trusts. 10.1, par 4: I don't think you put contractual info about roaming=20 partners in the database, but the rules in the policy engine are rather=20 the results of that. [KH] Agree Proposed solution: "In the service provider case, there should be a mechanism for entering policy rules that have been derived from the contractual information about roaming partners." Cheers, Klaas [KH] Prost, Katrin From khoeper@motorola.com Thu May 28 17:13:12 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19FB3A68BE for ; Thu, 28 May 2009 17:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXxYbq8BtVBK for ; Thu, 28 May 2009 17:13:12 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id DFFD93A67C0 for ; Thu, 28 May 2009 17:13:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1243556093!22047264!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9949 invoked from network); 29 May 2009 00:14:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 May 2009 00:14:54 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n4T0ErYq013213 for ; Thu, 28 May 2009 17:14:53 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n4T0Er3Z017605 for ; Thu, 28 May 2009 19:14:53 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n4T0EqKi017602 for ; Thu, 28 May 2009 19:14:53 -0500 (CDT) 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: Thu, 28 May 2009 20:14:31 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F060EE04D@de01exm68.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-emu-chbind-02 thread-index: Acnf8iOvvhcWpb84RhiHFiWXtsjE3QAABjyw From: "Hoeper Katrin-QWKN37" To: X-CFilter-Loop: Reflected Subject: [Emu] FW: New Version Notification for draft-ietf-emu-chbind-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 00:13:12 -0000 I just posted a new version of the channel binding draft addressing Klaas' comments (see my earlier post to the list) and updating some references. Katrin -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, May 28, 2009 7:11 PM To: Hoeper Katrin-QWKN37 Cc: clancy@LTSnet.net Subject: New Version Notification for draft-ietf-emu-chbind-02=20 A new version of I-D, draft-ietf-emu-chbind-02.txt has been successfuly submitted by Katrin Hoeper and posted to the IETF repository. Filename: draft-ietf-emu-chbind Revision: 02 Title: Channel Binding Support for EAP Methods Creation_date: 2009-05-28 WG ID: emu Number_of_pages: 23 Abstract: This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. =20 The IETF Secretariat. From root@core3.amsl.com Thu May 28 17:15:01 2009 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2D96E3A6BA5; Thu, 28 May 2009 17:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090529001501.2D96E3A6BA5@core3.amsl.com> Date: Thu, 28 May 2009 17:15:01 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-chbind-02.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 00:15:01 -0000 --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 : Channel Binding Support for EAP Methods Author(s) : C. Clancy, K. Hoeper Filename : draft-ietf-emu-chbind-02.txt Pages : 23 Date : 2009-05-28 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-emu-chbind-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-28171032.I-D@ietf.org> --NextPart-- From jsalowey@cisco.com Thu May 28 22:20:23 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272D13A657C for ; Thu, 28 May 2009 22:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg7PqpuRgRup for ; Thu, 28 May 2009 22:20:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 273113A6ABE for ; Thu, 28 May 2009 22:20:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,269,1241395200"; d="scan'208";a="191764510" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 May 2009 05:22:05 +0000 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 n4T5M5G8027816; Thu, 28 May 2009 22:22:05 -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.13.8/8.13.8) with ESMTP id n4T5M5Z2001693; Fri, 29 May 2009 05:22:05 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.3959); Thu, 28 May 2009 22:22: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 22:22:04 -0700 Message-ID: In-Reply-To: <000901c9c622$3e70d720$bb528560$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1 Thread-Index: AcnFlJm2s39lHrRDQZ6a+ffGFcz6QwAjY0BQBn6Xw4A= References: <000901c9c622$3e70d720$bb528560$@net> From: "Joseph Salowey (jsalowey)" To: "Glen Zorn" , X-OriginalArrivalTime: 29 May 2009 05:22:05.0802 (UTC) FILETIME=[67DD9CA0:01C9E01D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1338; t=1243574526; x=1244438526; 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]=20comments=20on=20draft-ietf-emu- eaptunnel-req-02.txt,=20part=201 |Sender:=20; bh=Pg3cRwX4NJDJ1JO0GX5dxxCqcVFB7CJvFADxp0VNuhc=; b=pHX4LpjVXyLuqEU7aPpxEZqV+0RrpyrfGKzG3MpoiKRrjVgvpPkhXEqvuW kzn2KlX1nGmMPdkZD6DQqgPTfAb7BpGd5oqjvmvAVzoMMBx16yTDNXcb0ANx f0hs1JlS6uR/zye38ekoNqHnME23zCjPwHjfVr58a7GBVMioY5j3Q=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 05:20:23 -0000 Hi Glen, Thanks for the review. I've incorporated most of the suggestions into a new revision. I have a question for you below. =20 > Same section, last paragraph, says: >=20 > Since EAP authentication occurs before network access is=20 > granted the > tunnel method SHOULD enable an inner exchange to provide=20 > support for > minimal password management tasks including password=20 > change, "new PIN > mode", and "next token mode" required by some systems. >=20 > "New token mode" and "new PIN mode" refer to the proprietary=20 > SecureID system > from RSA. I don't know why we should be giving RSA free=20 > advertising ;-), > nor why their system deserves explicit mention. Suggestion: >=20 > CHANGE: > change, "new PIN mode", and "next token mode" required by=20 > some systems. > TO > change and other "housekeeping" functions required by some systems. >=20 > This might also be a good place to mention that certain data=20 > related to > authorization may need to be communicated to the peer; it is=20 > forbidden to do > this in an EAP Success message, but there is no such=20 > constraint (yet) upon > the TLS tunnel. >=20 [Joe] I think this information would go in section 3.8 Extensibility. Do you have specific text that you think should go there. =20 =20 From jsalowey@cisco.com Thu May 28 22:20:23 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03E23A6C52 for ; Thu, 28 May 2009 22:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYZXfetKisJK for ; Thu, 28 May 2009 22:20:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B0C163A657C for ; Thu, 28 May 2009 22:20:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,269,1241395200"; d="scan'208";a="191764514" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 May 2009 05:22:07 +0000 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 n4T5M72W026423; Thu, 28 May 2009 22:22:07 -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.13.8/8.13.8) with ESMTP id n4T5M75S014726; Fri, 29 May 2009 05:22:07 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.3959); Thu, 28 May 2009 22:22: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 Date: Thu, 28 May 2009 22:22:04 -0700 Message-ID: In-Reply-To: <000901c9c622$3e70d720$bb528560$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1 Thread-Index: AcnFlJm2s39lHrRDQZ6a+ffGFcz6QwAjY0BQBn6Xw4A= References: <000901c9c622$3e70d720$bb528560$@net> From: "Joseph Salowey (jsalowey)" To: "Glen Zorn" , X-OriginalArrivalTime: 29 May 2009 05:22:07.0443 (UTC) FILETIME=[68D80230:01C9E01D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1338; t=1243574527; x=1244438527; 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]=20comments=20on=20draft-ietf-emu- eaptunnel-req-02.txt,=20part=201 |Sender:=20; bh=Pg3cRwX4NJDJ1JO0GX5dxxCqcVFB7CJvFADxp0VNuhc=; b=KMNyMaAUQIQdATYhyGl4QtdQNTFUitbp+WOSUnqvb15m2Uq4ccjS4+3ye3 WCNscSG2o1t6GwCisucIDoknDT6gSUspvlSyNV3N2FyB6MxZpEWbLw1dLA8r 4BqI3Pm9rd; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 05:20:23 -0000 Hi Glen, Thanks for the review. I've incorporated most of the suggestions into a new revision. I have a question for you below. =20 > Same section, last paragraph, says: >=20 > Since EAP authentication occurs before network access is=20 > granted the > tunnel method SHOULD enable an inner exchange to provide=20 > support for > minimal password management tasks including password=20 > change, "new PIN > mode", and "next token mode" required by some systems. >=20 > "New token mode" and "new PIN mode" refer to the proprietary=20 > SecureID system > from RSA. I don't know why we should be giving RSA free=20 > advertising ;-), > nor why their system deserves explicit mention. Suggestion: >=20 > CHANGE: > change, "new PIN mode", and "next token mode" required by=20 > some systems. > TO > change and other "housekeeping" functions required by some systems. >=20 > This might also be a good place to mention that certain data=20 > related to > authorization may need to be communicated to the peer; it is=20 > forbidden to do > this in an EAP Success message, but there is no such=20 > constraint (yet) upon > the TLS tunnel. >=20 [Joe] I think this information would go in section 3.8 Extensibility. Do you have specific text that you think should go there. =20 =20 From jsalowey@cisco.com Thu May 28 22:26:30 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83383A68E3 for ; Thu, 28 May 2009 22:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfEeoYJkFdqy for ; Thu, 28 May 2009 22:26:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BB4953A67DB for ; Thu, 28 May 2009 22:26:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,269,1241395200"; d="scan'208";a="78238165" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 29 May 2009 05:28:13 +0000 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 n4T5SDeo023217; Thu, 28 May 2009 22:28:13 -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.13.8/8.13.8) with ESMTP id n4T5SDHq004503; Fri, 29 May 2009 05:28:13 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, 28 May 2009 22:28:13 -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: Thu, 28 May 2009 22:28:11 -0700 Message-ID: In-Reply-To: <000901c9c622$3e70d720$bb528560$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunnel requirements and RFC 5247 and RFC 4962 Thread-Index: AcnFlJm2s39lHrRDQZ6a+ffGFcz6QwAjY0BQBn7RTdA= References: <000901c9c622$3e70d720$bb528560$@net> From: "Joseph Salowey (jsalowey)" To: "Glen Zorn" , X-OriginalArrivalTime: 29 May 2009 05:28:13.0197 (UTC) FILETIME=[42D9A3D0:01C9E01E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2198; t=1243574893; x=1244438893; 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:=20Tunnel=20requirements=20and=20RFC=205247=20and= 20RFC=204962 |Sender:=20; bh=faVe0Z0i7uVuT1qjWTtPLA73Bjdfh9ec7KiwIsQznzI=; b=CaXlcDBAG2Mn3yrIpgiUmZi7kT3kQIwb3Din4HVCSbSENHitCtarsblZHW iUQM1PDI3bcFOr0aF1X9brmqbcfAGPeJ9LwvHs1iZQa5iZz7Hs18YipQPA/F c2oycAfwYI; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Emu] Tunnel requirements and RFC 5247 and RFC 4962 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 05:26:30 -0000 Below, Glen suggests that it would be better to list specific requirements from RFC 5247 and RFC 4962 to avoid later confusion. This sounds like a good idea, is someone willing to contribute some text on this? I think it would be a distilled list of requirements from the two drafts normalized so they don't conflict.=20 Thanks, Joe >=20 > Section 4.1.1, third paragraph says: >=20 > The tunnel method MUST meet all the EAP method=20 > requirements contained > in the EAP Key Management Framework [RFC5247] or its=20 > successor. The > tunnel method MUST include MSK and EMSK generation. This=20 > will enable > the tunnel method to properly fit into the EAP key management > framework, maintaining all of the security properties and=20 > guarantees > of that framework. >=20 > While it is undoubtedly tempting to simply require compliance=20 > with RFC 5247, > given the rather incredible amount of drivel and nonsense=20 > present in that > RFC, it might be a better idea to be specific about precisely what > requirements need to be satisfied. >=20 > Same section, last paragraph: same comment as the last, but=20 > in spades. Just > one example that leaps out: Section 4.1.1, 4th paragraph of=20 > the draft in > question says "The tunnel method MUST NOT be tied to any single > cryptographic algorithm." and the last paragraph says "The=20 > tunnel method > MUST meet requirements pertinent to EAP method contained in=20 > Section 3 of RFC > 4962 [RFC4962]. This includes: cryptographic algorithm=20 > independence..." but > the subsection on algorithm independence in Section 3 of RFC 4962 says > "...an EAP method MAY depend on a specific cryptographic=20 > algorithm." While > this specific contradiction might be addressed by adding a=20 > sentence stating > that conflicts are resolved in favor of this draft other, more subtle > problems might not. >=20 >=20 > ~gwz >=20 > Play assigns meaning to human activity--work erases it. > -- P.L. Wilson >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From jsalowey@cisco.com Sun May 31 15:43:02 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2473A6DE0 for ; Sun, 31 May 2009 15:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKg+YYKuqIkG for ; Sun, 31 May 2009 15:42:54 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CA1D03A67FC for ; Sun, 31 May 2009 15:42:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,280,1241395200"; d="scan'208";a="192540456" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 31 May 2009 22:42:54 +0000 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 n4VMgsIM021931; Sun, 31 May 2009 15:42:54 -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.13.8/8.13.8) with ESMTP id n4VMgsYQ020671; Sun, 31 May 2009 22:42:54 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); Sun, 31 May 2009 15:42: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 Date: Sun, 31 May 2009 15:42:53 -0700 Message-ID: In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F060EE03A@de01exm68.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] review of chbind-01 Thread-Index: AcnH2wY7iCu/YEXhSXKHhoSRoYAPcAX+bc3wAJnMEzA= References: <49F6BDAE.2010101@cisco.com> <3A241A6B234BE948B8B474D261FEBC2F060EE03A@de01exm68.ds.mot.com> From: "Joseph Salowey (jsalowey)" To: "Hoeper Katrin-QWKN37" , "klaas(mailer list)" X-OriginalArrivalTime: 31 May 2009 22:42:54.0285 (UTC) FILETIME=[22E367D0:01C9E241] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14157; t=1243809774; x=1244673774; 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]=20review=20of=20chbind-01 |Sender:=20; bh=meopqDlYUMuV4dnL5aA8wDJL+G6j1o2n0fun1brmfZc=; b=sxXo8PnZhiPKlOfWasFNUHaG9WNXA5/lPebV8JEW9iRSnK8bxsPnANUPX+ 8BVwXpjJUqDRejMrkK2bAg7tR6cu/m/MoyUGN07M8DUBywuUMUDD7x1uTVtT RzRVlqcwt4Wu5y6SQTieexu8GY+Yr4WvQVbyS34f7/viFDezFqCt4=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] review of chbind-01 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 22:43:02 -0000 I'm not sure I quite understand the differences between the two cases.=20 =20 I think Klaas is saying that we need a protocol to exchange channel binding information, but we should stop before we define rules on how to evaluate this information. While I think that the requirements for the protocol are absolutely necessary, I believe the analysis would be incomplete if we did not provide information on how the data is expected to be evaluated. In many cases this evaluation needs to be done against stored data to validate the correct operation of the system. =20 Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Hoeper Katrin-QWKN37 > Sent: Thursday, May 28, 2009 4:03 PM > To: klaas(mailer list) > Cc: emu@ietf.org > Subject: Re: [Emu] review of chbind-01 >=20 > Hello Klaas, >=20 > Thank you for your very thorough review! > And sorry that it took me so long to reply. >=20 > My replies are in-line and will be reflected in the next=20 > draft version that I plan on posting shortly.=20 >=20 > I would appreciate your and the group's feedback on whether I=20 > addressed all your comments.=20 >=20 > I'd like to ask the group to check Klaas' primary comment=20 > since it is concerned with the scope of the draft. I'd be=20 > interested to know who shares this concern and whether the=20 > current draft should be modified accordingly. You'll find my=20 > opinion on this matter among my other replies below. >=20 > Regards, > Katrin >=20 >=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@cisco.com] > Sent: Tuesday, April 28, 2009 3:26 AM > To: Hoeper Katrin-QWKN37 > Cc: emu@ietf.org > Subject: review of chbind-01 >=20 > Hi Katrin, >=20 > I have reviewed your draft and I think the content is in=20 > principle in pretty good shape, see my comments further=20 > below. I have however a more fundamental concern that I would=20 > like to hear your (and others') opinion >=20 > about. >=20 > I have the feeling that the draft is too complicated because=20 > you mix two, only loosely related, problems. The way I see it=20 > there are 2 fundamental issues: >=20 > 1) the NAS talks to both the peer and to the authentication=20 > server and the information given to both doesn't have to be consistent >=20 > 2) the NAS gives information to authentication server (via the peer or > not) and the authentication server needs to evaluate that=20 > information and make policy decisions based on that. >=20 > Issue 1 is for me the one that most needs solving, and I=20 > would prefer this draft to focus on that one only. Issue 2 is=20 > not so much a technical >=20 > problem as a business problem. The administrative entities=20 > controlling respectively the NAS and the AuthN server need to=20 > agree on the info they >=20 > exchange and it is than up to the administrative entity to=20 > process that info (and log it for non-repudiation purposes=20 > etc.) and make policy >=20 > decisions on them. >=20 > Wrt to issue 1 I wonder if it is not sufficient to just=20 > "close the loop", i.e. have the NAS send the same info to=20 > both peer and AuthN server. Or alternatively, have all the=20 > info flow through the peer, that way you can be sure that=20 > peer and AuthN server have a consistent view of >=20 > what the NAS offers. >=20 > [KH] I agree that the solution presented in the current draft=20 > consists of a technical part (exchange end-to-end secured=20 > information between the peer & server, verify it and notify=20 > the peer about the result) and an administrative part=20 > (setting up a database to support the consistency and=20 > compliance checks of the exchanged channel binding information). >=20 > Introducing a database to the network model is absolute=20 > essential for the solution to work. First of all, the=20 > exchanged information cannot be directly compared because=20 > peer and server may have a different view of the network=20 > information provided by the NAS/authenticator. For example,=20 > the peer may identify a NAS by its SSID, whereas the EAP=20 > server may only know the NAS-IP-Address. In order for the=20 > server to check whether both addresses belong to the same=20 > device, a table look-up is required. Such look-up tables are=20 > stored in the local database. Secondly, in roaming scenarios=20 > the server cannot "know" each NAS of all visited networks=20 > that the home network has a roaming agreement with. Here, the=20 > server can only check whether the information broadcasted by=20 > a NAS in a visited network complies with the roaming=20 > agreement with this network. For that reason, rules derived=20 > from the agreements and policies need to be stored in a=20 > database, such that the server can use these rules for its=20 > consistency/compliance checks.=20 >=20 > I hope we can agree on that a database is absolute essential=20 > for implementing meaningful channel bindings and that channel=20 > bindings in roaming scenarios need to make use of rules that=20 > have been derived from agreements and/or policies. The draft=20 > does not say how these rules are derived, that is indeed=20 > outside the scope. >=20 > Bernard suggested in one of his earlier reviews to utilize=20 > such policy compliance checks to validate authorizations,=20 > e.g. checking whether a peer is authorized to access a=20 > particular part of a network or using a particular media. In=20 > addition, the solution enables the server to check whether an=20 > authenticator is authorized to grant access to a peer under=20 > the given circumstances. These authorization checks are=20 > included in the draft and are carried out by additional=20 > compliance checks. IMO this is a nice feature that can be=20 > achieved using channel bindings without changing the=20 > underlying protocol. It only requires additional information=20 > to be stored in the database. If there is a consensus that=20 > this feature should be outside the scope of the draft, it=20 > could be moved to a separate draft. Again, though, the local=20 > database and some compliance checks would still be a part of=20 > the remaining channel binding solution. > ------------------------------------------------------ >=20 >=20 > My concrete comments: >=20 > 1, par 2: "while there may be some identity tied to that=20 > security association" >=20 > What do you mean with "identity", are you talking about=20 > NAS-identifier, or something more generic? >=20 > [KH] Yes, we are referring to NAS-IP-Address, NAS-Identifier and such. >=20 > Proposed solution: "While there may be some identity tied to=20 > that security association, such as the NAS-Identifier,=20 > there's no reason the access point needs to advertize a=20 > consistent identity to clients."=20 >=20 > 1, par 4: "consistent with the defined network policy" >=20 > I think it is not so much consistent as well as that is=20 > 'satisfies' the defined network policies >=20 > [KH] Agree. What about 'compliant' instead? In addition, I=20 > think its best to explicitly distinguish between the=20 > consistency and the compliance checks. >=20 > Proposed solution: "This allows the server to verify the=20 > authenticator is providing information to the peer that is 1)=20 > consistent with the information stored about this=20 > authenticator and 2) compliant with the defined network=20 > policy. In addition, the presented solution allows the server=20 > to verify that the peer is authorized to access the network=20 > in the manner described by the NAS." >=20 > 3, par 1: I think you should call out here that proxy's are=20 > an example of that, you mention it later but it helps to give=20 > the reader an idea what you are talking about. >=20 > [KH] Agree. >=20 > Proposed solution: "Additionally, while an authenticator may=20 > not be compromised, other compromised elements in the=20 > networks (such as proxies), could provide false information=20 > to the authenticator..."=20 >=20 > 3, examples: I don't find the examples very compelling, how=20 > about for example a NAS giving wrong billing info to the peer=20 > "5$ all you can eat, >=20 > while sending per minute rates to the Auth server? >=20 > [KH] The current roaming example was chosen to illustrate an=20 > attack where victims are not aware of that they are actually=20 > roaming. If you (or anybody else) can come up with a more=20 > compelling example for the enterprise case, please let me know. >=20 > Proposed solution: I will add another simple example to the=20 > Service Provider Network case along the lines of what you suggested. >=20 > 4: "...do not ensure the binding different layers..." ->=20 > "...the binding >=20 > OF different layers..." >=20 > [KH] Corrected. >=20 > 4.1: is the fact whether it is plaintext or opaque the unique=20 > difference? I would argue that it is whether it is in a=20 > separate channel >=20 > or inline in the session key derivation. I think the=20 > plaintext vs opaque >=20 > doesn't add anything here, later in your requirements you=20 > point out that >=20 > the info sent needs to be protected, that seems enough to me. >=20 > [KH] Here, we wanted to emphasize that only the exchange of=20 > the data allows an analysis of the information rather than a=20 > bitwise comparison. > Latter only works for identical information (not always=20 > feasible, see different address/identifier discussion) that=20 > is exactly encoded in the same way (not really practical).=20 >=20 > Proposed solution: "The peer and server can both uniquely=20 > encode their respective view of the network information=20 > without exchanging it, resulting into an opaque blob that can=20 > be included directly into the derivation of EAP session keys." >=20 > 4.2.: is it not enough to just say that the AuthN server and=20 > the peer need to get the same info? isConsistent would become=20 > isEqual, much easier to compute...... ;-) >=20 > Unfortunately, isEqual is not feasible (see earlier=20 > discussion and address/identifier example). Another way to=20 > put it: Let's imagine peer and NAS/authenticator speak Dutch=20 > with each other, whereas the NAS/authenticator and the=20 > authentication server speak German. The isConsistent check=20 > allows us to verify whether both pieces of information have=20 > the same meaning (using the dictionary stored in the local=20 > database). On the other hand, the isEqual check will always fail. >=20 > Proposed solution: none. >=20 > 5.1, par 1: isConsistant -> isConsistent >=20 > [KH] Corrected. >=20 > 5.2, par 1: conistency of i1 and i2 and evaluating the policy=20 > is indeed nontrivial, but policy evaluation should imo be out=20 > of scope for this draft anyway. Policy verification is a=20 > local problem at the Auth server side, it has nothing to do=20 > withy the communication protocols. >=20 > [KH] See my reply to your first comment. >=20 > 6.2: "EAP methods MUST be able to import channel binding data=20 > from the lower layer...." >=20 > I don't understand this requirement, what type of data are we=20 > talking about? >=20 > [KH] For example, a peer should include the SSID received in=20 > the Beacon of a NAS/authenticator in i1. Consequently, a peer=20 > must be able to include information in i1 that has not been=20 > received as part of the EAP method. In order to do this, the=20 > EAP method must be able to access this kind of information=20 > from a lower layer. >=20 > Proposed solution: none >=20 > 7.2: NAS-Port-Type >=20 > Why a MUST? I can imagine many use cases where from a policy=20 > point of view I couldn't care less what medium type I am using >=20 > [KH] Agree >=20 > Proposed solution: change to SHOULD >=20 > 7.3: again, why a MUST? >=20 > [KH] Disagree. This is not a policy question. This AVP is=20 > essential for mitigating lying NAS attacks and thus should be a MUST. >=20 > Proposed solution: none >=20 > 7.3.?: I think it worthwhile including 802.11u, after all=20 > this deals with NASes communicating data about their network=20 > to the peers, that is exactly what 11u does. >=20 > [KH] Older draft versions included additional link-layers=20 > (admittedly not 11u), but were removed due to lack of=20 > feedback from the group on which AVPs should be included.=20 > Instead a few general attributes are provided that are useful=20 > to all link-layers (Section 7.2) and attributes for .11, 11r=20 > and 11s are listed as an example (Section 7.3). This is=20 > intended to provide a guideline for implementers to choose=20 > appropriate attributes when implementing channel bindings on=20 > different link layers. >=20 > If you (or somebody else) happen to know which 11u AVPs=20 > should be used here, please let me know and I include them. >=20 > Proposed solution: none, unless feedback from group is received >=20 > 9.1: >=20 > There is also trust between NAS/Authenticator and AuthN=20 > server. The Authenticator relies on the Authentication server=20 > for policy decisions. >=20 > [KH] The trust model for channel bindings assumes that peer=20 > and server are honest, while the authenticator is the=20 > potential attacker (e.g. > lying NAS attack, etc). In a trust model you usually don't=20 > care who the attacker trusts. >=20 > 10.1, par 4: I don't think you put contractual info about=20 > roaming partners in the database, but the rules in the policy=20 > engine are rather the results of that. >=20 > [KH] Agree >=20 > Proposed solution: "In the service provider case, there=20 > should be a mechanism for entering policy rules that have=20 > been derived from the contractual information about roaming partners." >=20 >=20 > Cheers, >=20 > Klaas >=20 > [KH] Prost, Katrin > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20