From emu-bounces@ietf.org Mon Apr 03 14:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUAo-00039R-VA; Mon, 03 Apr 2006 14:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUAn-00037D-0V for emu@ietf.org; Mon, 03 Apr 2006 14:53:09 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUAm-0007Lf-I8 for emu@ietf.org; Mon, 03 Apr 2006 14:53:08 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 03 Apr 2006 11:53:08 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k33Ir3Gv028430 for ; Mon, 3 Apr 2006 11:53:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C65750.D6917CEF" Date: Mon, 3 Apr 2006 12:00:13 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906D04FB8@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 65 meeting minutes Thread-Index: AcZXT9SFPy8CSPScSpiurARigQwLMw== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Emu] Draft IETF 65 meeting minutes X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C65750.D6917CEF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Attached are draft minutes for IETF 65 EMU meeting. Please let me know if you have any additions or corrections. =20 Thanks, Joe ------_=_NextPart_001_01C65750.D6917CEF Content-Type: text/plain; name="EMU IETF 65 minutes.txt" Content-Transfer-Encoding: base64 Content-Description: EMU IETF 65 minutes.txt Content-Disposition: attachment; filename="EMU IETF 65 minutes.txt" SUVURiA2NSBFQVAgTWV0aG9kIFVwZGF0ZSAoRU1VKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClR1ZXNkYXkgTWFyY2ggMjEsIDIwMDYNCg0KQ29tcGlsZWQgZnJvbSBub3Rl cyB0YWtlbiBieSBMYWtzbWluYXRoIERvbmRldGkgYW5kIE5hbmN5IENhbS1XaW5nZXQNCg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQox LiBFTVUgcHJlIHNoYXJlZCBrZXkgZGVzaWduIHRlYW0gdXBkYXRlIChVcmkgQmx1bWVudGhhbCkN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQpQcmVzZW50YXRpb24gKFVyaSk6IEVBUCBtZXRob2QgdXBkYXRlIGZyb20gdGhlIFBTSyBk ZXNpZ24gdGVhbQ0KLSBHb2FsczogQ3JlYXRlIGFuIEVBUCBtZXRob2QgYmFzZWQgb24gYSBQU0ss IG1lZXRzIDM3NDggYW5kIDQwMTcgcmVxcywNCiAgYW5kIHNpbXBsZSBhbmQgY29tcGFjdCANCg0K LSBEZWNpc2lvbnM6DQogIE5vdCBiYXNlZCBvbiBUTFMtUFNLDQogIHN5bW1ldHJpYyBjcmVkZW50 aWFscyBvbmx5LCBubyBwdWJsaWMga2V5IGJhc2VkIGNyZWRlbnRpYWxzDQogIE5vIG11bHRpLXBh cnR5DQogIEZhc3QgcmVzdW1wdGlvbiBpcyB1bm5lY2Vzc2FyeQ0KICBNdXN0IHN1cHBvcnQgY2hh bm5lbCBiaW5kaW5ncw0KICBBbGdvcml0aG0gYWdpbGl0eQ0KICBQcm92aXNpb25pbmcgb3V0IG9m IHNjb3BlDQogIERpc2N1c3Npb24gb24gS2V5IEdlbmVyYXRpb24vdHJhbnNwb3J0IHZzLiBkZXJp dmF0aW9uDQogDQogIChEYXZpZCBNY0dyZXcpKTogV2hhdCBhcmUgdGhlIGF0dGFja3Mgb24gdGhl IHRyYW5zcG9ydCBvZiBrZXlzDQogIChVcmkpOiBjaG9zZW4tcGxhaW4gdGV4dCBhdHRhY2tzDQoN CiAgKEhhbm5lcyBUc2Nob2ZlbmlnKTogSSBhbHNvIGJlbGlldmUgdGhlcmUgaXMgcm9vbSBmb3Ig YW5hbHlzaXMNCiAgIEJvdGggZW5kIHBvaW50cyBjb250cmlidXRpbmcgdG8ga2V5IG1hdCBpcyBn b29kLg0KDQogIChCZXJuYXJkIEFib2JhKTogSXMgYW55b25lIGZyb20gTklTVCBwYXJ0IG9mIHRo ZSBkZXNpZ24gdGVhbT8NCiAgIFdlIHdhbnQgdG8gYmUgcHJvYWN0aXZlIGFib3V0IGdldHRpbmcg aW5wdXQgZnJvbSBOSVNULg0KDQogIChKb2UgU2Fsb3dleSk6IEplc3NlLCBEYXZpZCBhbmQgQ2hh cmxlcyBoYXZlIE5JU1QgY29udGFjdHMsIA0KICAgd2UgaGF2ZSBjb250YWN0ZWQgTGlseSBDaGVu IGF0IE5JU1QgYW5kIG1hZGUgaGVyZSBhd2FyZSBvZiANCiAgIHRoZSBFTVUgZWZmb3J0cy4gIFdp bGwgY29udGludWUgd2l0aCBOSVNUIGludGVyYWN0aW9uLg0KICANCi0gQ29udGludWluZzoNCiAg IE1pbmltaXplIG51bWJlciBvZiByZXEgcHJpbWl0aXZlcw0KICAgRklQUyBjb21wbGlhbmNlDQoN Ci0gT3BlbiBpc3N1ZToNCg0KICBSYW5kb21uZXNzIHNvdXJjZToNCiAgICBDYW4gd2UgbGl2ZSB3 aXRoIG9uZSBvZiB0aGUgc291cmNlcyBjb250cmlidXRpbmc/DQogIENpcGhlciBzZWxlY3Rpb246 IA0KICAgIEFsZ29yaXRobSBhZ2lsaXR5IGdyYW51bGFyaXR5DQogIElkZW50aXR5IGhpZGluZw0K ICAgIFdlIGNhbiBwcm9iYWJseSBkZWZlcg0KICBDaGFubmVsIEJpbmRpbmcgDQogICAgZm9ybWF0 IGFuZCByZXF1aXJlbWVudCBmb3IgY29uZmlkZW50aWFsaXR5DQoNCihCZXJuYXJkKTogRG8gd2Ug bmVlZCBjcnlwdG8gdG8gYWNoaWV2ZSBDQj8NCihZb3NoaSk6IFEgb24gQ0I/IFdoaWNoIHR5cGUg b2YgQ0IgdGhpcyBXRyBpcyBhc3N1bWluZz8NCiAgVGhlcmUgaXMgYW4gaXNzdWUgYWJvdXQgY2Fy cnlpbmcgQ0Igb3ZlciBFQVAgbWV0aG9kLg0KICBJdCBhcHBlYXJzIHRoYXQgc29tZSBjb25maWcg b2YgQ0IgaXMgbmVlZGVkIGF0IHRoZSBzZXJ2ZXIuDQogIFdoeSBkbyB5b3UgbmVlZCB0byBjYXJy eSBDQiBpbmZvIHZpYSBFQVAgbWV0aG9kPw0KDQooSGFubmVzKTogV2UnbGwgc3BlY2lmeSBDQiBz dHVmZiBzZXBhcmF0ZWx5LCBhbmQgbm90IGluIEVBUCBtZXRob2QuDQooSm9lKTogV2UgZGV0ZXJt aW5lZCB0aGF0IGhhdmluZyB0aGUgYWJpbGl0eSB0byBjYXJyeSBjaGFubmVsIGJpbmRpbmcgdHlw ZSBkYXRhLA0KICBhdXRoZW50aWNhdGVkIGFuZCBwb3NzaWJseSBlbmNyeXB0ZWQgZGF0YSwNCiAg aXMgYSBnZW5lcmljIG9wZXJhdGlvbi4NCiAgTm90IHN1cmUgaWYgRXhhY3QgZm9ybWF0IGFuZCBj b250ZW50cyBhcmUgY2xlYXINCihKYXJpKTogQ0IgaW4gRUFQIG1ldGhvZCBhbmQgb3BhcXVlDQoN CihKb2UpOiBEZWZpbmluZyB0aGUgZm9ybWF0IGlzIGhhcmQ6IHBvdGVudGlhbGx5IHRoZXJlIG1h eSBiZSBtdWx0aXBsZQ0KIHR5cGVzIG9mIGRhdGEgdG8gY2FycnkuIE1ldGhvZCB3b24ndCBkZWZp bmUgdGhlIGNvbnRlbnQgb2YgQ0IuICANCiBJdCdzIGFuIG9wYXF1ZSBibG9iIHRoYXQgYSBtZXRo b2QgY2FycmllZC4NCg0KKFlvc2hpKTogV2h5IGRvZXMgQ0IgaW5mbyBuZWVkIHRvIGJlIGNhcnJp ZWQgaW4gRUFQIG1ldGhvZD8NCg0KKFBhc2kpOiBEaWZmZXJlbnQgd2F5cyBvZiBkb2luZyBDQi4g IE9uZSBpcyB0byBjYXJyeSBhbmQgdGhhdCBhbGxvd3MgdXMNCiAgdG8gbm90IG1vZGlmeSBBUHMu DQoNCihIYW5uZXMpOiBXZSBoYXZlbid0IHJlYWxseSBsb29rZWQgaW50byBZb3NoaSdzIGxhdGVz dCBkb2N1bWVudA0KDQooSm9lKTogVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHJlYXNvbnMgd2h5IHlv dSB3b3VsZCBjYXJyeSBpdCBpbiBFQVANCiAgbWV0aG9kLiBGb3IgZXhhbXBsZSBrZXlpbmcgbWF0 ZXJpYWwgbWF5IG5vdCBiZSB1c2VkIGluIGFsbCBjaXJjdW1zdGFuY2VzLg0KDQooQmVybmFyZCk6 IEZpeCBpdCBpbiB0aGUgRUFQIGtleWluZyBmcmFtZXdvcmsgcGVyaGFwcw0KDQooVmlkeWEpOiBB Ym91dCBDQiBhbmQgdXNpbmcga2V5IGRlcml2YXRpb246IHdoZW4geW91IHRpZSB0aGF0IHRvIGtl eQ0KICBkZXJpdmF0aW9uIHdvdWxkIGJlIHRvbyByZXN0cmljdGl2ZS4gIFdoYXQgaWYgdGhlIHBl ZXIncyB2aWV3IG9mIHRoZQ0KICBDQiBpcyBhIHN1YnNldCBvZiB0aGUgQVMncyB2aWV3IG9mIHRo ZSBDQg0KDQooVXJpKTogSSBhbSBub3Qgc3VyZSBJIGFncmVlLiAgTGV0J3MgdGFrZSBpdCBvZmZs aW5lIG9yIHRvIG1haWxpbmcgbGlzdA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjIuIFJGQzI3MTZi aXMtMDEgKEJlcm5hcmQgQWJvYmEpDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KLSA8c2VlIHNsaWRl cz4NCg0KLSBOZXh0IHN0ZXBzOg0KICBTb2xpY2l0IGZlZWRiYWNrIGZyb20gaW1wbGVtZW50ZXJz DQogIE1vdmluZyBmb3J3YXJkPw0KDQotIFZvbHVudGVlcnMgZm9yIHJldmlld3M6DQoNClNldmVy YWwgVm9sdW50ZWVycyBpbmNsdWRpbmc6DQoNCiAgVXJpIChzb3J0IG9mIGludGVyZXN0ZWQpDQog IFZpZHlhDQogIFBhc2kNCg0KICg/Pz8pOiBRdWVzdGlvbiBhYm91dCBFTVNLIGRlcml2YXRpb24g YW5kIHdoYXQgYWJvdXQgYmFja3dhcmQNCiAgY29tcGF0aWJpbGl0eQ0KDQooSGFubmVzKTogIERv IHlvdSBzdXBwb3J0IFBTS3M/DQooQmVybmFyZCk6IE5vLCBUaGlzIGlzIGp1c3QgYmFzZWQgb24g Y2VydHMNCg0KKEhhbm5lcyk6IFJlcXVlc3QgZnJvbSAzR1BQMiBhbmQgV2lNQVggdXNlIFBTS3Mu ICBXaGF0IHdvdWxkIHRoZXkgaGF2ZQ0KIHRvIGRvIGlmIHRoZXkgd2FudCB0byBkbyBFQVAtVExT LVBTSy4NCg0KKEJlcm5hcmQpOiBXaGF0IGhhcHBlbnMgd2l0aCBiYWNrd2FyZCBjb21wYXRpYmls aXR5LiANCiAgTmVlZCBlbXBpcmljYWwgZXZpZGVuY2UuIENlcnRzIGFyZSBtYW5kYXRvcnkgYW5k IFBTS3Mgd291bGQgYmUgb3B0aW9uYWwsIA0KICBzbyBkb2Vzbid0IHNlZW0gdG8gYWRkIHZhbHVl Lg0KDQooSGFubmVzKTogQ2xlYW5lciBhcHByb2FjaCB3b3VsZCBiZSBhIG5ldyB0eXBlIGNvZGUN Cg0KKEJlcm5hcmQpOiBhZ3JlZXMuDQoNCihKb2UpOiBDaGFydGVyIGl0ZW0gb24gZW5oYW5jZWQg RUFQLVRMUyAobmV3IHR5cGUgY29kZSkgZXhpc3RzDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpFbmQgb2Ygc2NoZWR1bGVkIGFnZW5kYQ0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCkNoYW5uZWwgYmluZGluZyBkaXNjdXNzaW9uDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQooU2FtIEhhcnRtYW4pOiBFQVAgY2hhbm5lbCBi aW5kaW5nIGlzIGJpbmRpbmcgdG8gYSBzcGVjaWZpYyBwb3J0IG9yIE5BUywgaXMgaXQ/DQooSm9l KTogeWVzIA0KDQooSm9lKTogY2hhbm5lbCBiaW5kaW5nIGNhcnJ5IHR3byB0aGluZ3M6IG9uZSBm b3IgYmluZGluZyB0byBhIHR1bm5lbCBhbmQgb25lIGZvcg0KIEF1dGhlbnRpY2F0b3IvTkFTLiAg VGhlc2UgYXJlIGRpZmZlcmVudCB0eXBlcy4NCg0KKEJlcm5hcmQpOiBIYXMgYW55b25lIGltcGxl bWVudGVkIGNoYW5uZWwgYmluZGluZz8NCg0KKG5vIEFuc3dlcikNCg0KKEpvZSk6IFRoZXJlIGlz IG5vIG5lZWQgdG8gZG8gY2hhbm5lbCBiaW5kaW5nIGluIG1hbnkgY2FzZXMsIHNpbmNlIHR5cGlj YWxseSBhbGwgYXV0aGVudGljYXRvcnMgaW4gYSBzeXN0ZW0gcHJvdmlkZSB0aGUgc2FtZSBzZXJ2 aWNlcy4NCg0KKEJlcm5hcmQpOiBPbmUgdXNlIGNhc2UsIGlzIGEgZGlzY3Vzc2lvbiBpbiA4MDIu MTF1IGFib3V0IG1vbmV0YXJ5DQp2ZXJpZmljYXRpb24NCg0KKEpvZSk6IGRpZmZlcmVudGlhdGVk IEFQIGNhc2UgbWlnaHQgbmVlZCBjaGFubmVsIGJpbmRpbmcNCg0KKFBhc2kpOiB0d28gZGlmZmVy ZW50IHR5cGVzIG9mIGF1dGhlbnRpY2F0b3JzIHByb3ZpZGluZyBkaWZmZXJlbnQgc2VydmljZXMN Cg0K ------_=_NextPart_001_01C65750.D6917CEF 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_001_01C65750.D6917CEF-- From emu-bounces@ietf.org Mon Apr 17 00:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVLYX-0007vi-JI; Mon, 17 Apr 2006 00:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVLYW-0007vd-FB for emu@ietf.org; Mon, 17 Apr 2006 00:41:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVLYW-0007cx-69 for emu@ietf.org; Mon, 17 Apr 2006 00:41:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2006 21:41:45 -0700 X-IronPort-AV: i="4.04,124,1144047600"; d="scan'208"; a="320151105:sNHT32362856" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3H4fhh0002061; Sun, 16 Apr 2006 21:41:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Apr 2006 21:49:02 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906E493A9@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-simon-emu-rfc2716bis-01 Thread-Index: AcZh2TkZi5F5kdq9TUaIvqxDmo/VMw== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Bernard Aboba Subject: [Emu] draft-simon-emu-rfc2716bis-01 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I think this draft is a good start. At the meeting at IETF 65 the working group desired to take this draft as a working group item. Would the authors submit this draft as draft-ietf-emu-rfc2716bis-00.txt. Comments on the draft: 1. Section 2.4 Identity verification The document specifies that the peer as server ID is carried in the subjectAltName extension. =20 A. It is possible that this extension may be empty and the name be carried in the subjectName. Should this be taken into account? What is the format of the ID, is it represented in ASN.1 format? =20 B. It seems that there may be more than one SubjectAltName. Are both used as the ID? It seems that order would matter for constructing a key name. =20 C. This document should probably reference RFC 3280.=20 D. I think the last paragraph might not be quite correct: "... Please note that in the case where the EAP authentication is remoted that the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended destination and whether the EAP server exists within a target sub-domain." I'm not quite sure what the is meant by "target sub-domain." In any case it is important that the peer be able to authorize the server as an EAP-Server that can authorize the authenticator the peer is connecting to. This is more than being issued by an organizational CA since that particular CA may issue certificates for many purposes. There either needs to be something in the certificate or the peer must have configuration to be able to perform the authorization. =20 2. Section 2.5 Key Hierarchy A. Why is the EMSK broken into two halves? It should not be as this implies a particular usage for the EMSK. It should just be one 64 byte value. B. Does this section tie the implementation of the PRF 10 2246? What if TLS 1.2 supports a different PRF?=20 C. This section shoes the TLS key hierarchy, shouldn't it show the EAP-TLS key hierarchy? 3. Section 2.6 Ciphersuite negotiation A. At the SAAG meeting in IETF 65 Sam brought up an issue with multiple layers of negotiation with EAP-TLS. Is there a vulnerability introduced by multiple levels of negotiation? Is it possible that an peer or server will negotiate a weaker authentication method though the negotiation of TLS ciphersuites than it would through EAP negotiation? B. The draft does not seem to specify which ciphersuites it is intended to be used with. Should it? 4. General=20 The document should define a Method-ID (for computing session-ID and key names). The method ID could be as simple as the concatenation of the server and client Finished messages. (these hashes contain the Client and Hello Random's as well as the identities exchanged in the certificates). =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 29 06:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZmNS-0004Ic-DP; Sat, 29 Apr 2006 06:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZmNQ-0004Dc-HP for emu@ietf.org; Sat, 29 Apr 2006 06:08:36 -0400 Received: from nz-out-0102.google.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZmNO-0005Mq-0p for emu@ietf.org; Sat, 29 Apr 2006 06:08:36 -0400 Received: by nz-out-0102.google.com with SMTP id z6so2424896nzd for ; Sat, 29 Apr 2006 03:08:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=acPcmgBCeT851Tbb8F9O94/jIN056uroTbQrjSjkd4AtiNuysWweMXsAPl8JXfrQ+stH30ig5PD7SI7qr+V+J809VilUvn64dAyePTwWgphuZ07VXqrX1SyVk1vUGTYTwatNGMknhjR21udPVunuzoA9AdQIq4Tm++LJyz+TBdQ= Received: by 10.36.79.4 with SMTP id c4mr2947239nzb; Sat, 29 Apr 2006 03:08:33 -0700 (PDT) Received: from ?192.168.0.6? ( [213.54.76.63]) by mx.gmail.com with ESMTP id 12sm1568105nzn.2006.04.29.03.08.30; Sat, 29 Apr 2006 03:08:31 -0700 (PDT) From: Thomas Otto To: emu@ietf.org Date: Sat, 29 Apr 2006 12:08:26 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604291208.26523.thomas.g.otto@googlemail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Emu] ICV in EAP-PAX X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi all, the following question arose while re-reading several specs. EAP-PAX computes an ICV (Integrity Check Value) as follows (Sect. 3.3) The ICV is computed as the MAC over the entire EAP packet, including the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC is keyed using the 16-octet ICK, using the MAC type specified by the MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been derived, the MAC is keyed using a zero-octet NULL key. If the ICV field is incorrect, the receiver MUST silently discard the packet. But RFC 3748 days in Section 3.1 [...] EAP methods may not include a MIC, or if they do, it may not be computed over all the fields in the EAP packet, such as the Code, Identifier, Length, or Type fields. [...] So, is the ICV of EAP-PAX compliant to RFC 3748 at all? And which additional security is obtained through the ICV ? (Compare the packet-wise MAC to the strategy of TLS: There, it suffices to compute at the end a checksum (by means of the Finished messages) over the whole handshake messages to ensure the handshake's integrity). We should discuss whether the ICVs are allowed and/or makes sense. (... I remember EAP-SAKE also computes an ICV over the whole packet ...) Thomas _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Apr 29 10:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZqqe-0003ch-UB; Sat, 29 Apr 2006 10:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZqqd-0003YN-UN for emu@ietf.org; Sat, 29 Apr 2006 10:55:03 -0400 Received: from bay106-f16.bay106.hotmail.com ([65.54.161.26] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZqqd-00021v-KT for emu@ietf.org; Sat, 29 Apr 2006 10:55:03 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 29 Apr 2006 07:55:03 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 29 Apr 2006 14:55:01 GMT X-Originating-IP: [67.182.139.247] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <200604291208.26523.thomas.g.otto@googlemail.com> From: "Bernard Aboba" To: thomas.g.otto@googlemail.com, emu@ietf.org Bcc: Subject: RE: [Emu] ICV in EAP-PAX Date: Sat, 29 Apr 2006 07:55:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Apr 2006 14:55:03.0012 (UTC) FILETIME=[E5251240:01C66B9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > The ICV is computed as the MAC over the entire EAP packet, including > the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC > is keyed using the 16-octet ICK, using the MAC type specified by the > MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, > PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been > derived, the MAC is keyed using a zero-octet NULL key. > If the ICV field is incorrect, the receiver MUST silently discard the > packet. > >But RFC 3748 days in Section 3.1 > > [...] EAP methods may not > include a MIC, or if they do, it may not be computed over all the > fields in the EAP packet, such as the Code, Identifier, Length, > or Type fields. [...] > > >So, is the ICV of EAP-PAX compliant to RFC 3748 at all? Yes, it is compliant. The text above was meant to convey that not all EAP methods will be able to cover the entire EAP packet in their MAC. >And which additional security is obtained through the ICV ? The ability to protect against modification of the EAP header fields including Code, Identifier, Length and Type. >(Compare the packet-wise MAC to the strategy of TLS: There, it suffices >to compute at the end a checksum (by means of the Finished messages) >over the whole handshake messages to ensure the handshake's >integrity). The problem with the approach taken by TLS-based methods is that they are vulnerable to Type substitution attacks. For example, it is possible to take a TLS packet sent as part of EAP-TLS, EAP-TTLS, PEAP, TLS-PSK, etc. and change the Type field, making it seem like it is a packet of another Type. If done as part of the initial Request/Response exchange, it is possible to fool the EAP Peer into accepting a proposal of a wrong Type. If only one packet has its Type changed, according to the EAP state machine RFC 4137, such an attack would cause the entire EAP exchange to fail. However, if all the packets coming from the server have their Type changed, it may be possible for the entire TLS exchange to conclude successfully without the peer figuring out that the wrong Type has been used. If the TLS session cache is shared by all TLS-based methods, and the peer does not tie together the TLS Session-ID with the Type used, it would be possible for the peer to successfully resume a session created by EAP-TLS within an EAP-TTLS or PEAP conversation, without even realizing that it was actually an EAP-TLS resumption. >We should discuss whether the ICVs are allowed and/or makes sense. >(... I remember EAP-SAKE also computes an ICV over the whole packet ...) _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu