From klaas@cisco.com Tue Nov 1 02:33:05 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8843221F8F4D for ; Tue, 1 Nov 2011 02:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ-jRiwfpNWb for ; Tue, 1 Nov 2011 02:33:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B5CB221F8EEC for ; Tue, 1 Nov 2011 02:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=734; q=dns/txt; s=iport; t=1320139984; x=1321349584; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=fQLuLYc0gs4x7ZwbrnkjlwbwnuenSjkN4xJGaKRRPew=; b=NxSOtmg7jqo3d8zkbS5Z7CUlCqh1BXQX0FyauD3a/dmUg6E8YczlRv75 4Q13ZIOAyY3EAqA9E7GG543ELs5OfwgwUPw4zI3YSBCV4JvjoIIw90xqt 2+ziAeIzM9AVuOaKA+aR79jmVCuEvkdSt1hJb2yzKjIB8l2sMJOakE8ec w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4GAKq8r06tJXG8/2dsb2JhbABCmiiPEIEFggsBJ4IynF6BJgGeU4ghYQSUD5Fg X-IronPort-AV: E=Sophos;i="4.69,437,1315180800"; d="scan'208";a="32430373" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 01 Nov 2011 09:33:03 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA19X2fo000374 for ; Tue, 1 Nov 2011 09:33:03 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Nov 2011 10:33:01 +0100 Message-Id: <90D77954-4EF2-4A0F-96BB-10A70F26AC2A@cisco.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [abfab] draft agenda abfab@IETF82 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 09:33:06 -0000 Hi, I just posted below draft agenda. We propose to have a 45 minute = technical discussion slot to discuss outstanding issues with the drafts. = Leif and I will collect open issues, but please let us know any topics = that you want to discuss. Klaas & Leif =3D=3D=3D abfab (Friday - 2 hrs) * Agenda bashing and Note Well (10 min) * Current Document Status (45 mins) - draft-ietf-abfab-gss-eap (Sam Hartman) - draft-ietf-abfab-aaa-saml (Josh Howlett) - draft-winter-abfab-eapapplicability (Stefan Winter) * Propsed and New Documents (15 mins) - draft-mrw-abfab-trust-router (Margaret Wasserman) * Technical discussion (45 mins) * Administrivia and AOB (5 min) - Updating the milestones and timeline= From wei.yinxing@zte.com.cn Tue Nov 1 08:02:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F20921F9832 for ; Tue, 1 Nov 2011 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.026 X-Spam-Level: X-Spam-Status: No, score=-97.026 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiL4ayEMRLFj for ; Tue, 1 Nov 2011 08:02:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF2121F982F for ; Tue, 1 Nov 2011 08:02:43 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690967931198; Tue, 1 Nov 2011 22:53:40 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16073.2449460320; Tue, 1 Nov 2011 23:02:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA1F2JZT028603; Tue, 1 Nov 2011 23:02:19 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: <4EAE9B0B.6060302@um.es> To: Alejandro Perez Mendez MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Tue, 1 Nov 2011 23:02:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-01 23:02:21, Serialize complete at 2011-11-01 23:02:21 Content-Type: multipart/alternative; boundary="=_alternative 00529C2A4825793B_=" X-MAIL: mse01.zte.com.cn pA1F2JZT028603 Cc: abfab@ietf.org Subject: Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:02:45 -0000 This is a multipart message in MIME format. --=_alternative 00529C2A4825793B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEFsZWphbmRybw0KDQogIFNBTUwvQUFBIGlzIHRoZSB1bmRlcmx5aW5nIG1lY2hhbmlzbXMg Zm9yIGF1dGhlbnRpY2F0aW9uIGluIHRoaXMgZHJhZnQuIA0KICBJbiBzdGVwIDMsIFJQIC0+IElk UCA6IDxzYW1scDpBdXRoblJlcXVlc3Q+LCBJdCBNQVkgcmVxdWlyZSBzb21lIA0KYWRkdGlvbmFs IGluZm9tYXRpb24sIHN1Y2ggYXMgTkFJIC0gd2hpY2ggaXMgdXNlZCB0byBpZGVudGlmeSBzdWJq ZWN0LCANCnNlY3VyaXR5IHRva2VuIC0gd2hpY2ggaXMgdXNlZCB0byBhc3N1cmUgdGhlIHN1Ympl Y3QgaXMgdGhlIGhvbGRlciBvZiB0aGUgDQprZXkuIFRoZW4gSWRQIGNvbnN0cnVjdCBhc3NlcnRp b24gDQogICBzdGVwIDQsIElkUCAtPiBSUCA6IDxzYW1scDpSZXNwb25zZT4sIHdoaWNoIGNvbnRh aW5zIGFzc2VydGlvbiANCmluZm9ybWF0aW9uLg0KDQpUaGUgY3JlZGVudGlhbCAoZS5nLiBNU0sp IGlzIE5PVCB0cmFuc2ZlcnJlZCBkaXJlY3RseSBmcm9tIElkUCB0byBSUCBpbiANCnRoaXMgZHJh ZnQsIEl0IGlzIFNBTUwgYXNzZXJ0aW9uIHRoYXQgaXMgdHJhc3BvcnRlZCBiZXR3ZWVuIHRoZW0u IFRoZSB0d28gDQpjaXRlZCByZWZlcmVuY2VzIGRlZmluZSBTQU1ML0FBQSBtZWNoYW5pc21zLCBi dXQgSSBhbSBOT1Qgc3VyZSB3aGV0aGVyIA0KdGhleSBjb25zaWRlciB0aGlzIGNhc2UuDQoNClRo YW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KLS0tLS0tLS0tLS0tDQpZaW54aW5nIFdlaSANCg0K DQoNCg0KQWxlamFuZHJvIFBlcmV6IE1lbmRleiA8YWxleEB1bS5lcz4gDQq3orz+yMs6ICBhYmZh Yi1ib3VuY2VzQGlldGYub3JnDQoyMDExLzEwLzMxIDIwOjU2DQoNCsrVvP7Iyw0KYWJmYWJAaWV0 Zi5vcmcNCrOty80NCg0K1vfM4g0KUmU6IFthYmZhYl0gZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDEg aXMgdXBsb2FkZWQsIHBsZWFzZSByZXZpZXcgaXQNCg0KDQoNCg0KDQoNCkhpIFlpbnhpbmcsDQoN CkFmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0LCBJIGhhdmUgYSBkb3VidCBjb25jZXJuaW5nIHdpdGgg eW91ciBwcm9wb3NhbC4gIEluIA0Kc2VjdGlvbiA0LCBzdGVwIDMsIHRoZSB0ZXh0IHNheXM6DQpX aGVuIFJQIHJlY2VpZXZlcyB0aGUgcmVxdWVzdCBmcm9tIFVFLCBpdCBjaGVja2VzIHdoZXRoZXIg dGhlDQogICAgICAgY3JlZGVudGlhbCBpcyBhdmlhbGFibGUuICBJZiBub3QsIFJQIGluaXRpYXRl cyBBQUEgcmVxdWVzdCB0bw0KICAgICAgIHJldHJpZXZlIGNyZWRlbnRpYWwgZnJvbSBJZFAgW0kt RC5pZXRmLWFiZmFiLWFhYS1zYW1sXQ0KICAgICAgIFtJLUQuam9uZXMtZGlhbWV0ZXItYWJmYWJd Lg0KDQpJdCBpcyBub3QgY2xlYXIgdG8gbWUgaG93IGNyZWRlbnRpYWxzIChNU0sgb3Igc2ltaWxh cikgYXJlIHRyYW5zcG9ydGVkIHRvIA0KdGhlIFJQLCBzaW5jZSBpdCBzZWVtcyAoZHVlIHRvIHRo ZSByZWZlcmVuY2VzIHlvdSBjaXRlKSB0aGF0IGl0IGlzIGRvbmUgDQp0aHJvdWdoIFNBTUwuDQpD YW4geW91IHByb3ZpZGUgZnVydGhlciBkZXRhaWxzIG9uIHRoaXMsIHBsZWFzZT8NCg0KUmVnYXJk cywNCkFsZWphbmRybw0KDQpIaSwgQWxsIA0KDQogIFRoZSAtMDEgdmVyc2lvbiBvZiBkcmFmdC13 ZWktYWJmYWItZmNsYSBpcyB1cGxvYWRlZCwgcGxlYXNlIGZvbGxvdyB0aGUgDQpsaW5rIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDEudHh0IHRvIG9wZW4gaXQu IA0KDQogIFBsZWFzZSByZXZpZXcgaXQsIGFueSBjb21tZW50cyBhcmUgd2VsY29tZSEgDQoNCkZp bGVuYW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0LXdlaS1hYmZhYi1mY2xhDQpSZXZpc2lvbjog ICAgICAgICAgICAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNzDQpDcmVhdGlvbiBkYXRlOiAgICAgICAg ICAgICAgICAgIDIwMTEtMTAtMzENCldHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDkNCg0KQWJzdHJh Y3Q6DQogIE5ldHdvcmsgc3RyYXR1bSBhbmQgYXBwbGljYXRpb24gc3RyYXR1bSBmb3JtIGEgZmVk ZXJhdGlvbiB0bw0KICBmYWNpbGlhdGUgdXNlcidzIGFjY2Vzcy4gIE5ldHdvcmsgb3BlcmF0b3Ig YWN0cyBhcyBJZGVudGl0eSBQcm92aWRlcg0KICAoSWRQKSwgYW5kIGFwcGxpY2F0aW9uIHJldXNl cyB1bmRlcmx5aW5nIG5ldHdvcmsncyBzZWN1cml0eQ0KICBjYXBhYmlsaXRpZXMgdG8gc2ltbGlm eSBhcHBsaWNhdGlvbidzIGFjY2Vzcy4gIFRoaXMgZG9jdW1lbnQgaXMgdG8NCiAgaW50cm9kdWNl IHN1Y2ggZmVkZXJhdGVkIGNyb3NzLWxheWVyIGFjY2VzcyB1c2UgY2FzZSBhbmQgbWVzc2FnZQ0K ICBmbG93cy4gDQoNCg0KLS0tLS0tLS0tLS0tIA0KWWlueGluZyBXZWkNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byAN Cm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhh cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5 c3RlbS4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQphYmZhYiBtYWlsaW5nIGxpc3QNCmFiZmFiQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KYWJmYWIgbWFpbGluZyBsaXN0DQphYmZhYkBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYg0KDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRp b24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBu YW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24g dG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQg YXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBh cmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00529C2A4825793B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCA8L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkFsZWphbmRybzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFNBTUwvQUFBIGlzIHRoZSB1bmRlcmx5aW5n IG1lY2hhbmlzbXMNCmZvciBhdXRoZW50aWNhdGlvbiBpbiB0aGlzIGRyYWZ0LiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJbiBzdGVwIDMsIFJQIC0m Z3Q7IElkUCA6ICZsdDtzYW1scDpBdXRoblJlcXVlc3QmZ3Q7LA0KSXQgTUFZIHJlcXVpcmUgc29t ZSBhZGR0aW9uYWwgaW5mb21hdGlvbiwgc3VjaCBhcyBOQUkgLSB3aGljaCBpcyB1c2VkIHRvDQpp ZGVudGlmeSBzdWJqZWN0LCBzZWN1cml0eSB0b2tlbiAtIHdoaWNoIGlzIHVzZWQgdG8gYXNzdXJl IHRoZSBzdWJqZWN0DQppcyB0aGUgaG9sZGVyIG9mIHRoZSBrZXkuIFRoZW4gSWRQIGNvbnN0cnVj dCBhc3NlcnRpb24gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7c3RlcCA0LCBJZFAgLSZndDsgUlAgOg0KJmx0O3NhbWxwOlJlc3BvbnNlJmd0 Oywgd2hpY2ggY29udGFpbnMgYXNzZXJ0aW9uIGluZm9ybWF0aW9uLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGNyZWRlbnRpYWwgKGUuZy4gTVNL KSBpcyBOT1QgdHJhbnNmZXJyZWQNCmRpcmVjdGx5IGZyb20gSWRQIHRvIFJQIGluIHRoaXMgZHJh ZnQsIEl0IGlzIFNBTUwgYXNzZXJ0aW9uIHRoYXQgaXMgdHJhc3BvcnRlZA0KYmV0d2VlbiB0aGVt LiBUaGUgdHdvIGNpdGVkIHJlZmVyZW5jZXMgZGVmaW5lIFNBTUwvQUFBIG1lY2hhbmlzbXMsIGJ1 dA0KSSBhbSBOT1Qgc3VyZSB3aGV0aGVyIHRoZXkgY29uc2lkZXIgdGhpcyBjYXNlLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+LS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5ZaW54aW5nIFdlaSA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTMzJT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+QWxlamFuZHJvIFBlcmV6IE1lbmRleg0KJmx0O2FsZXhAdW0uZXMm Z3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7I yzogJm5ic3A7YWJmYWItYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDExLzEwLzMxIDIwOjU2PC9mb250Pg0KPHRkIHdpZHRoPTY2JT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmFiZmFiQGlldGYub3JnPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Fi ZmFiXSBkcmFmdC13ZWktYWJmYWItZmNsYS0wMQ0KaXMgdXBsb2FkZWQsIHBsZWFzZSByZXZpZXcg aXQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ SGkgWWlueGluZyw8YnI+DQo8YnI+DQpBZnRlciByZWFkaW5nIHRoZSBkcmFmdCwgSSBoYXZlIGEg ZG91YnQgY29uY2VybmluZyB3aXRoIHlvdXIgcHJvcG9zYWwuDQombmJzcDtJbiBzZWN0aW9uIDQs IHN0ZXAgMywgdGhlIHRleHQgc2F5czo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5XaGVu IFJQIHJlY2VpZXZlcyB0aGUgcmVxdWVzdCBmcm9tIFVFLCBpdCBjaGVja2VzDQp3aGV0aGVyIHRo ZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIGlzIGF2aWFsYWJsZS4gJm5i c3A7SWYgbm90LCBSUCBpbml0aWF0ZXMNCkFBQSByZXF1ZXN0IHRvPGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7IHJldHJpZXZlIGNyZWRlbnRpYWwgZnJvbSBJZFAgW0ktRC5pZXRmLWFiZmFiLWFh YS1zYW1sXTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbSS1ELmpvbmVzLWRpYW1ldGVyLWFi ZmFiXS48YnI+DQo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+SXQgaXMgbm90IGNsZWFy IHRvIG1lIGhvdyBjcmVkZW50aWFscyAoTVNLIG9yIHNpbWlsYXIpDQphcmUgdHJhbnNwb3J0ZWQg dG8gdGhlIFJQLCBzaW5jZSBpdCBzZWVtcyAoZHVlIHRvIHRoZSByZWZlcmVuY2VzIHlvdSBjaXRl KQ0KdGhhdCBpdCBpcyBkb25lIHRocm91Z2ggU0FNTC48YnI+DQpDYW4geW91IHByb3ZpZGUgZnVy dGhlciBkZXRhaWxzIG9uIHRoaXMsIHBsZWFzZT88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkFs ZWphbmRybzwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkhpLCBBbGw8L3R0Pjwv Zm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiAm bmJzcDtUaGUgLTAxIHZlcnNpb24gb2YgZHJhZnQtd2VpLWFiZmFiLWZjbGEgaXMgdXBsb2FkZWQs IHBsZWFzZSBmb2xsb3cNCnRoZSBsaW5rIDwvdHQ+PC9mb250PjxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDEudHh0Ij48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZT48dHQ+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC13ZWktYWJmYWItZmNs YS0wMS50eHQ8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mj48dHQ+DQp0byBvcGVuIGl0 LjwvdHQ+PC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9Mj48dHQ+ PGJyPg0KICZuYnNwO1BsZWFzZSByZXZpZXcgaXQsIGFueSBjb21tZW50cyBhcmUgd2VsY29tZSE8 L3R0PjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQo8 YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC13ZWktYWJmYWItZmNsYTxicj4NClJldmlzaW9uOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzAxPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZlZGVyYXRlZCBDcm9zcy1MYXllcg0KQWNjZXNzPGJy Pg0KQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7MjAxMS0xMC0zMTxicj4NCldHIElEOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQpOdW1iZXIgb2YgcGFnZXM6IDk8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQogJm5ic3A7PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD5OZXR3b3JrIHN0 cmF0dW0gYW5kIGFwcGxpY2F0aW9uIHN0cmF0dW0NCmZvcm0gYSBmZWRlcmF0aW9uIHRvPGJyPg0K ICZuYnNwO2ZhY2lsaWF0ZSB1c2VyJ3MgYWNjZXNzLiAmbmJzcDtOZXR3b3JrIG9wZXJhdG9yIGFj dHMgYXMgSWRlbnRpdHkNClByb3ZpZGVyPGJyPg0KICZuYnNwOyhJZFApLCBhbmQgYXBwbGljYXRp b24gcmV1c2VzIHVuZGVybHlpbmcgbmV0d29yaydzIHNlY3VyaXR5PGJyPg0KICZuYnNwO2NhcGFi aWxpdGllcyB0byBzaW1saWZ5IGFwcGxpY2F0aW9uJ3MgYWNjZXNzLiAmbmJzcDtUaGlzIGRvY3Vt ZW50DQppcyB0bzxicj4NCiAmbmJzcDtpbnRyb2R1Y2Ugc3VjaCBmZWRlcmF0ZWQgY3Jvc3MtbGF5 ZXIgYWNjZXNzIHVzZSBjYXNlIGFuZCBtZXNzYWdlPGJyPg0KICZuYnNwO2Zsb3dzLjwvdHQ+PC9m b250Pjxmb250IHNpemU9Mz4gPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJy Pg0KLS0tLS0tLS0tLS0tPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPjx0dD48YnI+DQpZaW54aW5nIFdlaTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48 dHQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkDQpzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUg YWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVh c2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIu PGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYWJmYWIgbWFpbGluZyBsaXN0PGJy Pg0KPC90dD48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86YWJmYWJAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWU+PHR0Pjx1PmFiZmFiQGlldGYub3JnPC91PjwvdHQ+PC9mb250PjwvYT48Zm9u dCBzaXplPTM+PHR0Pjxicj4NCjwvdHQ+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYjwvdT48L3R0PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTI+PHR0 Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYWJm YWIgbWFpbGluZyBsaXN0PGJyPg0KYWJmYWJAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+ PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZu YnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWls Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lw aWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7 dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm bmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVu dHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhl cnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3Ry YW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1 c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZu YnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwm bmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7 b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2 aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDth cmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRl ci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJz cDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5i c3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00529C2A4825793B_=-- From alex@um.es Tue Nov 1 10:30:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2199A21F99BE for ; Tue, 1 Nov 2011 10:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69OmoV9+LuvT for ; Tue, 1 Nov 2011 10:30:30 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7059021F999B for ; Tue, 1 Nov 2011 10:30:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 1775A5D51E; Tue, 1 Nov 2011 18:29:07 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3bBXswzofwMc; Tue, 1 Nov 2011 18:29:06 +0100 (CET) Received: from [192.168.1.130] (49.247.221.87.dynamic.jazztel.es [87.221.247.49]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id B77C85D51D; Tue, 1 Nov 2011 18:28:58 +0100 (CET) Message-ID: <4EB02C59.9030502@um.es> Date: Tue, 01 Nov 2011 18:28:57 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: wei.yinxing@zte.com.cn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806040701040307030900" Cc: abfab@ietf.org Subject: Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:30:31 -0000 This is a multi-part message in MIME format. --------------040806040701040307030900 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Hi Yinxing, > > Hi, Alejandro > > SAML/AAA is the underlying mechanisms for authentication in this draft. > In step 3, RP -> IdP : , It MAY require some > addtional infomation, such as NAI - which is used to identify subject, > security token - which is used to assure the subject is the holder of > the key. Then IdP construct assertion > step 4, IdP -> RP : , which contains assertion > information. > > The credential (e.g. MSK) is NOT transferred directly from IdP to RP > in this draft, It is SAML assertion that is trasported between them. > The two cited references define SAML/AAA mechanisms, but I am NOT sure > whether they consider this case. If the MSK or derived key is not transferred to the RP, how can it verify the identity of the UE? That's the point that is not clear to me in the flow. You say that the credential used by the UE is derived from the MSK. Then the acceptor (the RP) has to be able to verify somehow this credential, either: 1) It obtains the credential from the AAA which took place in the authentication 2) It delegates the verification of the credential to the AAA, but in this case, you have to define the interface between the RP and the AAA for this purpose, since as you commented, SAML is not indicated for that. Regards, Alejandro > > Thanks for your comments. > > ------------ > Yinxing Wei > > > > *Alejandro Perez Mendez * > ·¢¼þÈË: abfab-bounces@ietf.org > > 2011/10/31 20:56 > > > ÊÕ¼þÈË > abfab@ietf.org > ³­ËÍ > > Ö÷Ìâ > Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it > > > > > > > > > > Hi Yinxing, > > After reading the draft, I have a doubt concerning with your proposal. > In section 4, step 3, the text says: > When RP receieves the request from UE, it checkes whether the > credential is avialable. If not, RP initiates AAA request to > retrieve credential from IdP [I-D.ietf-abfab-aaa-saml] > [I-D.jones-diameter-abfab]. > > It is not clear to me how credentials (MSK or similar) are transported > to the RP, since it seems (due to the references you cite) that it is > done through SAML. > Can you provide further details on this, please? > > Regards, > Alejandro > > Hi, All > > The -01 version of draft-wei-abfab-fcla is uploaded, please follow the > link _http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt_to open it. > > Please review it, any comments are welcome! > > Filename: draft-wei-abfab-fcla > Revision: 01 > Title: Federated Cross-Layer Access > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > Network stratum and application stratum form a federation to > faciliate user's access. Network operator acts as Identity Provider > (IdP), and application reuses underlying network's security > capabilities to simlify application's access. This document is to > introduce such federated cross-layer access use case and message > flows. > > > ------------ > Yinxing Wei > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of > this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the originator of the message. Any views expressed in this message are > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > _______________________________________________ > abfab mailing list > _abfab@ietf.org_ > _https://www.ietf.org/mailman/listinfo/abfab_ > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --------------040806040701040307030900 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit Hi Yinxing,


Hi, Alejandro

  SAML/AAA is the underlying mechanisms for authentication in this draft.
  In step 3, RP -> IdP : <samlp:AuthnRequest>, It MAY require some addtional infomation, such as NAI - which is used to identify subject, security token - which is used to assure the subject is the holder of the key. Then IdP construct assertion
   step 4, IdP -> RP : <samlp:Response>, which contains assertion information.

The credential (e.g. MSK) is NOT transferred directly from IdP to RP in this draft, It is SAML assertion that is trasported between them. The two cited references define SAML/AAA mechanisms, but I am NOT sure whether they consider this case.

If the MSK or derived key is not transferred to the RP, how can it verify the identity of the UE? That's the point that is not clear to me in the flow. You say that the credential used by the UE is derived from the MSK. Then the acceptor (the RP) has to be able to verify somehow this credential, either:

1) It obtains the credential from the AAA which took place in the authentication
2) It delegates the verification of the credential to the AAA, but in this case, you have to define the interface between the RP and the AAA for this purpose, since as you commented, SAML is not indicated for that.

Regards,
Alejandro


Thanks for your comments.

------------
Yinxing Wei



Alejandro Perez Mendez <alex@um.es>
·¢¼þÈË:  abfab-bounces@ietf.org

2011/10/31 20:56

ÊÕ¼þÈË
 abfab@ietf.org
³­ËÍ
Ö÷Ìâ
 Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it







Hi Yinxing,

After reading the draft, I have a doubt concerning with your proposal.  In section 4, step 3, the text says:
When RP receieves the request from UE, it checkes whether the
      credential is avialable.  If not, RP initiates AAA request to
      retrieve credential from IdP [I-D.ietf-abfab-aaa-saml]
      [I-D.jones-diameter-abfab].
It is not clear to me how credentials (MSK or similar) are transported to the RP, since it seems (due to the references you cite) that it is done through SAML.
Can you provide further details on this, please?

Regards,
Alejandro

Hi, All

 The -01 version of draft-wei-abfab-fcla is uploaded, please follow the link http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt to open it.

 Please review it, any comments are welcome!

Filename:                  draft-wei-abfab-fcla
Revision:                  01
Title:                                   Federated Cross-Layer Access
Creation date:                  2011-10-31
WG ID:                                   Individual Submission
Number of pages: 9

Abstract:
 Network stratum and application stratum form a federation to
 faciliate user's access.  Network operator acts as Identity Provider
 (IdP), and application reuses underlying network's security
 capabilities to simlify application's access.  This document is to
 introduce such federated cross-layer access use case and message
 flows.


------------
Yinxing Wei
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--------------040806040701040307030900-- From smith@Cardiff.ac.uk Tue Nov 1 16:06:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E539D21F9E1D for ; Tue, 1 Nov 2011 16:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax2m6CPfPgLj for ; Tue, 1 Nov 2011 16:06:47 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 7046521F9E19 for ; Tue, 1 Nov 2011 16:06:47 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1RLNPl-0004YF-D5; Tue, 01 Nov 2011 23:06:41 +0000 Received: from [109.144.236.165] (helo=[10.84.69.117]) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RLNPl-0006JB-6O; Tue, 01 Nov 2011 23:06:41 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_375B02B1-113B-4C3A-9872-400915CF6EBE" From: Rhys Smith In-Reply-To: Date: Tue, 1 Nov 2011 23:06:35 +0000 Message-Id: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> References: To: wei.yinxing@zte.com.cn X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 23:06:49 -0000 --Apple-Mail=_375B02B1-113B-4C3A-9872-400915CF6EBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Yinxing, (cc:ed to abfab list for discussion), Some answers to your answers below, followed by some suggested = rewording.=20 > For the text "but that's not the purpose of this document", the = clarification is as follows:=20 > (1), Federated identity is in the scope of abfab wg,and the case also = supports non-web application.=20 > (2), in the section 3. Context of Use Cases in this document = (draft-ietf-usecases-01), it says:=20 > In the interest of promoting the development of technology of broad=20 > applicability, the present authors welcome use cases and requirements=20= > from other sectors and communities.=20 1 - Yes, federated identity is in the scope of the WG. But the purpose = of the working group is not to explain why federated identity in general = is a good thing. 2 - Absolutely, please don't misunderstand, I'm happy to accept all = valid use cases that people come up with... > Yinxing#2>The point is that the mobile network infrastructure has = already had security capabilities (e.g. authentication, integrity and = confidentiality ) which is mandatory for user equipment attacked to = network.=20 > Application can make use of this capability without duplicating the = similar task done in network layer. As to desktop or laptop, when they = connect to the network, the authentication is performed in other way = provided by network operators.=20 OK, yes, I see that in your particular use case the process would be = slightly different than in normal use cases, and so therefore might well = be worthy of including in the use case doc - if your separate I-D gains = consensus. If it is to go in the use case doc, however, the current text doesn't = really fit in the document as it stands (both in terms of style and = content). It really does say a lot of unnecessary things (e.g. federated = access is good because it means users don't have to remember multiple = credentials) and things that I'm sure people (including myself) would = argue with (e.g. do all telecom operators always provide trusted = identity? I think not!). So I've had a go at writing my own version of this use case trying to = draw out the main points that you're arguing for. Does this capture what = is trying to be said sufficiently well? (It still needs tidying up, but = I'm just trying to get the gist of your use case first). =3D=3D=3D=3D=3D Accessing Applications from Devices on a Mobile Telecoms Infrastructure Mobile telecom operators typically have the following properties: * A large collection of registered users, many of whom may have = identities registered to a fairly high level of assurance (often for = payment purposes). However, not all users will have this property - for = example, non-contract customers in countries with low levels of identity = registration requirements. * An existing network infrastructure capable of authenticating a = mobile device, and by inference, its owner. * A large collection of applications (both web-based and non = web-based) that its users wish to access using their mobile device. = These applications could be hosted by the mobile telecoms operator = directly, or could be any application or system on the internet - for = example, network messaging services, VoIP, email, etc. At present, authentication to these applications will be typically = configured manually by the user on their mobile device but inputting = their (usually pre-provisioned out-of-band) credentials for that = application - one per application. The use of ABFAB technologies in this case, via a mechanism dubbed = "federated cross-layer access" (see [ref]) would enhance the user = experience of using these applications on mobile devices greatly. = Federated cross-layer access would make use of the initial mutual = authentication between device and network to enable subsequent = authentication and authorisation to happen in a seamless manner for the = user of that device authenticating to applications. =3D=3D=3D=3D=3D Rhys. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_375B02B1-113B-4C3A-9872-400915CF6EBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Yinxing, (cc:ed to abfab list for = discussion),

Some answers to your = answers below, followed by some suggested = rewording. 


For the text "but that's not the purpose of this document", the clarification is as follows:
(1), Federated identity is in the = scope of abfab wg,and the case also supports non-web application.
(2), in the section 3. Context of = Use Cases in this document (draft-ietf-usecases-01), it says:
In the interest of promoting the = development of technology of broad
applicability, the present = authors welcome use cases and requirements
from other sectors and = communities.

1 - Yes, federated identity is in = the scope of the WG. But the purpose of the working group is not to = explain why federated identity in general is a good = thing.

2 - Absolutely, please don't = misunderstand, I'm happy to accept all valid use cases that people come = up with...



Yinxing#2>The point is = that the mobile network infrastructure has already had security capabilities (e.g. = authentication, integrity and confidentiality ) which is mandatory for user equipment = attacked to network.
Application can = make use of this capability without duplicating the similar task done in network layer. As to desktop or laptop, when they connect to the network, the = authentication is performed in other way provided by network operators.


OK, yes, I see that = in your particular use case the process would be slightly different than = in normal use cases, and so therefore might well be worthy of including = in the use case doc - if your separate I-D gains = consensus.

If it is to go in the use case doc, = however, the current text doesn't really fit in the document as it = stands (both in terms of style and content). It really does say a lot of = unnecessary things (e.g. federated access is good because it means users = don't have to remember multiple credentials) and things that I'm sure = people (including myself) would argue with (e.g. do all telecom = operators always provide trusted identity? I think = not!).

So I've had a go at writing my own = version of this use case trying to draw out the main points that you're = arguing for. Does this capture what is trying to be said sufficiently = well? (It still needs tidying up, but I'm just trying to get the gist of = your use case = first).

=3D=3D=3D=3D=3D

Accessing Applications from = Devices on a Mobile Telecoms Infrastructure

Mobile = telecom operators typically have the following properties:
    * A large collection of registered = users, many of whom may have identities registered to a fairly high = level of assurance (often for payment purposes). However, not all users = will have this property - for example, non-contract customers in = countries with low levels of identity registration = requirements.

    * An existing network = infrastructure capable of authenticating a mobile device, and by = inference, its owner.

    * A large collection of = applications (both web-based and non web-based) that its users wish to = access using their mobile device. These applications could be hosted by = the mobile telecoms operator directly, or could be any application or = system on the internet - for example, network messaging services, VoIP, = email, etc.

At present, authentication to these = applications will be typically configured manually by the user on their = mobile device but inputting their (usually pre-provisioned out-of-band) = credentials for that application - one per application.
The use of ABFAB technologies in this case, via a = mechanism dubbed "federated cross-layer access" (see [ref]) would = enhance the user experience of using these applications on mobile = devices greatly. Federated cross-layer access would make use of the = initial mutual authentication between device and network to enable = subsequent authentication and authorisation to happen in a seamless = manner for the user of that device authenticating to = applications.

smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

= --Apple-Mail=_375B02B1-113B-4C3A-9872-400915CF6EBE-- From hartmans@painless-security.com Tue Nov 1 18:27:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463B511E8081 for ; Tue, 1 Nov 2011 18:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj+IUDjIZek7 for ; Tue, 1 Nov 2011 18:27:13 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D3F2011E807F for ; Tue, 1 Nov 2011 18:27:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A948020239; Tue, 1 Nov 2011 21:28:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E7711435A; Tue, 1 Nov 2011 21:27:03 -0400 (EDT) From: Sam Hartman To: Rhys Smith References: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> Date: Tue, 01 Nov 2011 21:27:03 -0400 In-Reply-To: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> (Rhys Smith's message of "Tue, 1 Nov 2011 23:06:35 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hartmans-ietf@mit.edu, kwiereng@cisco.com, abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 01:27:14 -0000 >>>>> "Rhys" == Rhys Smith writes: Rhys> The use of ABFAB technologies in this case, via a mechanism Rhys> dubbed "federated cross-layer access" (see [ref]) would Rhys> enhance the user experience of using these applications on Rhys> mobile devices greatly. Federated cross-layer access would Rhys> make use of the initial mutual authentication between device Rhys> and network to enable subsequent authentication and Rhys> authorisation to happen in a seamless manner for the user of Rhys> that device authenticating to applications. I'm not fond of the architecture of re-using the authentication or at least am nervous about the architectural coupling involved. Why isn't it sufficient to simply re-use the credential? I.E. we cann't we perform a second mutual authentication.? --Sam From alex@um.es Wed Nov 2 01:20:49 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6611E80D3 for ; Wed, 2 Nov 2011 01:20:49 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJBpUwGY1fJU for ; Wed, 2 Nov 2011 01:20:49 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE2111E80CD for ; Wed, 2 Nov 2011 01:20:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 680185D4EB for ; Wed, 2 Nov 2011 09:20:47 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s71ZWS90CgA2 for ; Wed, 2 Nov 2011 09:20:46 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id D69A85D4E2 for ; Wed, 2 Nov 2011 09:20:45 +0100 (CET) Message-ID: <4EB0FD5C.7010008@um.es> Date: Wed, 02 Nov 2011 09:20:44 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 08:20:49 -0000 >>> "Rhys" == Rhys Smith writes: > > Rhys> The use of ABFAB technologies in this case, via a mechanism > Rhys> dubbed "federated cross-layer access" (see [ref]) would > Rhys> enhance the user experience of using these applications on > Rhys> mobile devices greatly. Federated cross-layer access would > Rhys> make use of the initial mutual authentication between device > Rhys> and network to enable subsequent authentication and > Rhys> authorisation to happen in a seamless manner for the user of > Rhys> that device authenticating to applications. > > > I'm not fond of the architecture of re-using the authentication or at > least am nervous about the architectural coupling involved. Why isn't > it sufficient to simply re-use the credential? I.E. we cann't we perform > a second mutual authentication.? Well, I guess that the point is exactly that, to avoid that second mutual authentication by resuing cryptographic material generated during the network authentication. An average user would like to enter his PIN number only once, when the device starts, and then, he can access services seamlessly, without being prompted about the PIN number again. This is even more interesting if instead a PIN number the user has to write a passphrase (not thinking in a mobile phone now, but in a WPA-enterprise authentication, for example). If you are thinking on providing SSO within all the services of the federation, as we do in our kerberized proposal, the intention is to incorporate the network access as another service, without worrying in which layer it works. As it is usually the first service accesed by the user in a session, it would be in charge to "bootstrapp" the SSO. Regards, Alejandro > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From klaas@cisco.com Wed Nov 2 02:21:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA4F11E8113 for ; Wed, 2 Nov 2011 02:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAaghDjqAWOz for ; Wed, 2 Nov 2011 02:21:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1B37F11E80D9 for ; Wed, 2 Nov 2011 02:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=2832; q=dns/txt; s=iport; t=1320225696; x=1321435296; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ydv2GSv673yGHvcsVjERvpPJwb4BwR06MAosft3IKQw=; b=YFbuMx8vej2zoxzpbSgYBE4ooobDCLhmp6g7iFwGISjRHG5kJfufu8V1 7GkGWhzPP3bTy25EkTHvfoYrsjImOTW8Y8N9FBrcviRMKSN6wmh/JkiN+ MsXWA5rP55afBgIiBMQp1mCepf/bfybWJ67wi/YWsYa8bzpqqt4Pej/1E E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAGQKsU6tJXG8/2dsb2JhbABDqCqBHoEFgXIBAQEDAQEBAQ8BJzQLEAsSNCciDgYTIodgCJZOAZ5NBIgvYQSUFJFm X-IronPort-AV: E=Sophos;i="4.69,443,1315180800"; d="scan'208";a="32726448" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2011 09:21:35 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA29LY7J018651; Wed, 2 Nov 2011 09:21:35 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Klaas Wierenga In-Reply-To: <4EB0FD5C.7010008@um.es> Date: Wed, 2 Nov 2011 10:21:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02DCEBB9-499C-4A73-9EEA-B057C5484213@cisco.com> References: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> <4EB0FD5C.7010008@um.es> To: Alejandro Perez Mendez X-Mailer: Apple Mail (2.1251.1) Cc: abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:21:36 -0000 On Nov 2, 2011, at 9:20 AM, Alejandro Perez Mendez wrote: >=20 >>>> "Rhys" =3D=3D Rhys Smith writes: >>=20 >> Rhys> The use of ABFAB technologies in this case, via a = mechanism >> Rhys> dubbed "federated cross-layer access" (see [ref]) would >> Rhys> enhance the user experience of using these applications on >> Rhys> mobile devices greatly. Federated cross-layer access would >> Rhys> make use of the initial mutual authentication between = device >> Rhys> and network to enable subsequent authentication and >> Rhys> authorisation to happen in a seamless manner for the user = of >> Rhys> that device authenticating to applications. >>=20 >>=20 >> I'm not fond of the architecture of re-using the authentication or at >> least am nervous about the architectural coupling involved. Why = isn't >> it sufficient to simply re-use the credential? I.E. we cann't we = perform >> a second mutual authentication.? >=20 > Well, I guess that the point is exactly that, to avoid that second = mutual authentication by resuing cryptographic material generated during = the network authentication. An average user would like to enter his PIN = number only once, when the device starts, and then, he can access = services seamlessly, without being prompted about the PIN number again. = This is even more interesting if instead a PIN number the user has to = write a passphrase (not thinking in a mobile phone now, but in a = WPA-enterprise authentication, for example). >=20 > If you are thinking on providing SSO within all the services of the = federation, as we do in our kerberized proposal, the intention is to = incorporate the network access as another service, without worrying in = which layer it works. As it is usually the first service accesed by the = user in a session, it would be in charge to "bootstrapp" the SSO. yes, I agree with that. Furthermore, I can imagine mobile operators = offering brokered services (operator A strikes a deal with SaaS provider = B) to their users, by definition the authentication process of the = operator is the one you want to rely on. I could also imagine a step-up = authentication sort of scenario, in which the network authentication = acts as the first factor and another authentication method is used as = additional authentication for services that have a demand for stronger = authentication. Klaas P.S. I like Rhys' wording >=20 > Regards, > Alejandro >=20 >>=20 >> --Sam >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alex@um.es Wed Nov 2 06:08:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D6521F90AE for ; Wed, 2 Nov 2011 06:08:36 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVPa3BdRdh96 for ; Wed, 2 Nov 2011 06:08:35 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7FF21F9064 for ; Wed, 2 Nov 2011 06:08:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id C813C5D64D for ; Wed, 2 Nov 2011 14:08:33 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7UF6+vC4yMyR for ; Wed, 2 Nov 2011 14:08:33 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 007655D5AC for ; Wed, 2 Nov 2011 14:08:31 +0100 (CET) Message-ID: <4EB140CF.1040206@um.es> Date: Wed, 02 Nov 2011 14:08:31 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <011a01cc9833$3a006440$ae012cc0$@augustcellars.com> In-Reply-To: <011a01cc9833$3a006440$ae012cc0$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------030607090108010106070508" Subject: Re: [abfab] Review on gss-eap-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:08:37 -0000 This is a multi-part message in MIME format. --------------030607090108010106070508 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Sam, I also performed a review of the -03 version of the draft. Thought many of the comments were already pointed out by Jim and solved in -04 version, some of them are still valid. Most of them are typos or clarifications. I hope the will help. Section 1.2 * "In this case, the GSS-API peer acts..:" s/GSS-API peer/GSS-API acceptor/ Section 3.1 * Related with the GSS_C_NT_HOSTBASED_SERVICE name, I think the textual representation should be "SERVICE@HOST" instead of "HOST@SERVICE". * In the sentence "but the semantics are not similar enough semantics to use..." the second "semantics" is redundant Section 3.3 * Surround with () the reference in the sentence "..unless the acceptor supplies the acceptor name response Section 5.4.3.". Section 5 * Change "The innerToken field starts with a 16-bit network byte order token type." with "The innerToken field starts with a 16-bit network byte order token type identifier." to be consistent with the table. * In the figure describing the structure of the inner token, it may not be clear if Position is given in bits or bytes (not that in the parragraph above it talks about a 16-bit field, not a 2-byte field. Section 5.2 * It is stated that "The subtoken type MUST be unique within a given token". Is there any requirement or motivation for this? Won't this limit us in the future for extensions? Just asking, cause I don't really know. Section 5.4 * If the optimization related with the discussion "GSS-EAP: do we need an identity request" is specified, the text should be changed to reflect the fact that the acceptor response when in Initial State may not be an EAP request/identity message, but an EAP request starting a specific EAP method. Section 5.4.3 * Change "Typically this token would only be send if" with "Typically this token would only be sent if" * Change "If the initiator receivs an EAP Success message," with "If the initiator receives an EAP Success message" * Change "then the acceptor sends this in the Eap Request subtoken type" with "then the acceptor sends this in the EAP Request subtoken type" * What happens when none of the initiator supplied target names are applicable? An error is produced, or a name out of the proposed list is given? If this last case applies, then the text should be modified to reflect this fact. Section 5.5 * In the sentence "If the EAP state machine generates an EAP success message, then EAP believes the authentication is successful.", did you mean "If the EAP state machine generates an EAP success message, then EAP authenticator believes the authentication is successful."? * There is an inconsistence between the text in the first bullet and the text in the second bullet. In the first one, it talks about the EAP state machine generating EAP messages. Opposite, the second one talks about the acceptor receiving EAP messages. Though I understand they both are correct, I think it would be better to homogeneize and, in the fist bullet say: "If the acceptor receives an EAP success message.....". * Additionally, in the second bullet it is stated that an error subtoken is sent, and GSS failure is returned. However, in the third bullet it is stated that a subtoken is returned. The use of "send" and "return" may result a bit confusing. I think that we may want to homogenize this and assume that tokens are sent while GSS errors are returned. Section 5.6.2 * Nothing is said about the key to be used (I guess it will be the CRK described in section 6). Section 5.7 * I have a question here, not an issue, I'm just curious. If the PROT_READY is never available and per-message security services cannot be used before context establishment, how do you call to GSS_Wrap and GSS_GetMIC to generate the Channel Bindings and MIC subtokens? Section 6 * s/following procedur/following procedure/ Best regards, Alejandro El 01/11/11 02:11, Jim Schaad escribió: > >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans@painless-security.com] >> Sent: Sunday, October 30, 2011 4:20 PM >> To: Jim Schaad >> Cc: draft-ietf-abfab-gss-eap-authors@ietf.org; abfab@ietf.org >> Subject: Re: [abfab] Review on gss-eap-03 >> >>>>>>> "Jim" == Jim Schaad writes: >> >> Jim> Is the ABNF for "name" still wrong? >> >> I don't think so. >> What problem or oddity do you see? >> Hmm. >> I see that realm is only permitted if host is present. I think I've fixed > that. >> I think it's correct now in 04. > That was the specific error that I saw. > >> >> Jim> section 3.4 missing >> >> Jim> Section 4 - does/should the application get any control ovret >> Jim> the set of allowable EAP methods to be used or is that purely a >> Jim> fucntion of your GSS-API library >> >> Currently no mechanism is provided for an application to enfluence this. >> A mechanism probably should have system-level policy configuration. >> A mechanism could expose a credential option on the initiator. >> If we ever need to standardize a credential option we can, but I don't see > a >> need for that now. >> >> >> >> Jim> For consistency the paragraph: Tokens from the initiator to >> Jim> acceptor use an outer token type of 06 01; tokens from acceptor >> Jim> to initiator use an outer token type of 06 02. These token >> Jim> types are registered in the registry of RFC 4121 token types; >> Jim> see Section 8.1. >> >> My understanding is that the ID describes which type of token (token >> type) we are dealing with. >> So, I've phrased it as token s with from acceptor to initiator use an > inner >> token type with ID xxx. >> 1) token type with ID >> and 2) inner not outer > Looks fine > >> Jim> should refer to the "token ID" rather than the "outer token >> Jim> type" either that or the item in the table should be updated. >> >> Jim> section 5.2 refers to "token type" - I think that maybe this is >> Jim> the most constant phrase to be used. >> >> I've updated the registry to talk about token type identifiers. >> >> Jim> I will say that this version did harmonize and make the token >> Jim> naming scheme much more consistent and readable. I think this >> Jim> is a big improvement. >> Great! >> >> Jim> s/secondsubtoken/second subtoken/ (in the table) >> >> Jim> Section 5.3 - Is there going to be a rule that you should send >> Jim> two error subtokens in the even t\the length is greater than 8? >> Jim> I can understand saying you should ignore the extended bytes >> Jim> but should you really ignore the error code itself? >> >> In 04 we have initiators MUST ignore octets beyond the GSS EAP error code >> for future extensibility. Thanks for the catch. >> >> Jim> Section 5.4 - you have different names for the acceptor name >> Jim> subtokens in the description of what is permitted and the >> Jim> actual subtoken names - I think you might want to harmonize >> Jim> this. >> >> Jim> Is there a rason that the EAP request subtoken is not >> Jim> documented in section 5.4 since it is a required subtoken from >> Jim> in the Initial State message from the acceptor? >> >> I've added a reference. However I think it's better to document EAP > request >> and response near each other. >> Note that if we adopt the proposal to reduce a round trip this subtoken > goes >> away from initial state. >> >> Jim> Section 5.4.1 - I realize this is a debugging string (Vender >> Jim> Subtoken) but is there any reason in this day and age not make >> Jim> it a UTF8 string? (Other than it is not one for Kerbros) >> >> It doesn't exist for Kerberos (which has no vendor string I'm aware of) so > I >> don't think that's a concern. >> >> I've made it UTF-8; I don't care. >> >> Jim> Section 5.4.3 - Should something be said about what the >> Jim> acceptor should do if the initiator sends an acceptor name >> Jim> which is not completely correct for the specific acceptor. I >> Jim> am thinking specifically of things like adding a host name or >> Jim> adding some service specifics to the acceptor name. Is this >> Jim> permitted? Or is this and error condition or since this is >> Jim> typically not sent is the acceptor name from the client to be >> Jim> used in all events. (unless totally wrong) >> >> I think you mean 5.4.2 not 5.4.3? >> My assumption is that you need to send a superset of what the acceptor >> expects, else things will fail at channel binding. I think you want to > leave it to >> channel binding to fail unless an IDP wants to implement some form of >> aliasing. > In 5.4.2 s/hosntame/hostname/ > > I meant 5.4.3 - because I was assuming this was an Acceptor error rather > than an Initiator. That is if the Acceptor name is not a superset then it > would return an error. The question is should you both error and return the > response in some sense. > > One possibility is that the Initiator sends name #1, the Acceptor replies > with name #2 and then the intiator says that this is acceptable and sends > name #2 as part of the channel binding. In this case the was no error but > the initator name is not a superset of the acceptor name that came back. > >> >> >> Jim> para #2 s/this token/This token/ >> >> Jim> Section 5.5 s/ACCEPTOR/acceptor/ > Not fixed > >> Jim> The first bullet of this section is causing me some mental >> Jim> problems. The acceptor cannot confirm that the protected >> Jim> result and the final result are consistent - this is hidden >> Jim> from the acceptor. --- or you need to be passing the protected >> Jim> result as a RADIUS attribute, at which point it is not really >> Jim> protected anymore. >> >> For combined authenticators the acceptor can and should evaluate the >> protected result. >> For pass-through authenticators the acceptor should confirm there's AAA >> success if there is EAP success. > Ok - I think this is more clear now. > >> Jim> The acceptor can confirm that a key has been delivered to it, >> Jim> but it does not know the source of the key - i.e. was it >> Jim> derived or just transmitted inside of the EAP session. >> >> Here, we mean the security claim discussed in section 7.10 of RFC 3748, > which >> probably includes transmitting a key. >> Their term, not mine. >> I've added a reference. >> > Ok > >> >> Jim> Should the acceptor or the initiator send the error subtoken - >> Jim> or should the acceptor be looking for clear EAP messages and >> Jim> generate a failure? >> >> I don't understand. >> >> Jim> I think you need to carefully re-read the section and verify >> Jim> that you think it is correct. >> >> I think it is consistent with what EAP does and what our implementation >> does. >> There are some disadvantages to how EAP handles failures. >> We can discuss at IETF 82 if you like. > I think this would probably be a good idea - just so I can be sure that we > understand each other and what the doc says. >> Jim> Setion 5.6 - Please tell me which type of channel binding I am >> Jim> getting at this point. (I know it is GSS-API channel binding, >> Jim> but given that two different types are discussed in the >> Jim> document I think being explcit would be good.) >> >> Also added a forward reference. >> >> Jim> Section 6 - Is the KMSK in the "Tn = " line supposed to be >> Jim> GMSK? >> Yes. >> >> >> Jim> Section 6.1 - I am unclear what the extension option field is >> Jim> referring to please clarify. >> >> This was all wrong and has been fixed. Thanks for the reality check. > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------030607090108010106070508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Sam,

I also performed a review of the -03 version of the draft. Thought many of the comments were already pointed out by Jim and solved in -04 version, some of them are still valid. Most of them are typos or clarifications. I hope the will help.

Section 1.2
  • "In this case, the GSS-API peer acts..:"    s/GSS-API peer/GSS-API acceptor/   
   
Section 3.1
  • Related with the GSS_C_NT_HOSTBASED_SERVICE name, I think the textual representation should be "SERVICE@HOST" instead of "HOST@SERVICE".  
  • In the sentence "but the semantics are not similar enough semantics to use..." the second "semantics" is redundant 
   
Section 3.3
  • Surround with () the reference in the sentence "..unless the acceptor supplies the acceptor name response Section 5.4.3.".
       
Section 5
  • Change "The innerToken field starts with a 16-bit network byte order token type." with "The innerToken field starts with a 16-bit network byte order token type identifier." to be consistent with the table.
  • In the figure describing the structure of the inner token, it may not be clear if Position is given in bits or bytes (not that in the parragraph above it talks about a 16-bit field, not a 2-byte field.
       
Section 5.2
  • It is stated that "The subtoken type MUST be unique within a given token". Is there any requirement or motivation for this? Won't this limit us in the future for extensions? Just asking, cause I don't really know.
       
Section 5.4
  • If the optimization related with the discussion "GSS-EAP: do we need an identity request" is specified, the text should be changed to reflect the fact that the acceptor response when in Initial State may not be an EAP request/identity message, but an EAP request starting a specific EAP method.
       
Section 5.4.3
  •     Change "Typically this token would only be send if" with "Typically this token would only be sent if"   
  •     Change "If the initiator receivs an EAP Success message," with "If the initiator receives an EAP Success message"
  •     Change "then the acceptor sends this in the Eap Request subtoken type" with "then the acceptor sends this in the EAP Request subtoken type"
  •     What happens when none of the initiator supplied target names are applicable? An error is produced, or a name out of the proposed list is given? If this last case applies, then the text should be modified to reflect this fact.
       
Section 5.5
  • In the sentence "If the EAP state machine generates an EAP success message, then EAP believes the authentication is successful.", did you mean "If the EAP state machine generates an EAP success message, then EAP authenticator believes the authentication is successful."?
  • There is an inconsistence between the text in the first bullet and the text in the second bullet. In the first one, it talks about the EAP state machine generating EAP messages. Opposite, the second one talks about the acceptor receiving EAP messages. Though I understand they both are correct, I think it would be better to homogeneize and, in the fist bullet say: "If the acceptor receives an EAP success message.....".
  • Additionally, in the second bullet it is stated that an error subtoken is sent, and GSS failure is returned. However, in the third bullet it is stated that a subtoken is returned. The use of "send" and "return" may result a bit confusing. I think that we may want to homogenize this and assume that tokens are sent while GSS errors are returned.   
   
Section 5.6.2   
  • Nothing is said about the key to be used (I guess it will be the CRK described in section 6).    
  

Section 5.7
  • I have a question here, not an issue, I'm just curious. If the PROT_READY is never available and per-message security services cannot be used before context establishment, how do you call to GSS_Wrap and GSS_GetMIC to generate the Channel Bindings and MIC subtokens? 
  
Section 6
  • s/following procedur/following procedure/
   
Best regards,
Alejandro         
   



El 01/11/11 02:11, Jim Schaad escribió: 


-----Original Message-----
From: Sam Hartman [mailto:hartmans@painless-security.com]
Sent: Sunday, October 30, 2011 4:20 PM
To: Jim Schaad
Cc: draft-ietf-abfab-gss-eap-authors@ietf.org; abfab@ietf.org
Subject: Re: [abfab] Review on gss-eap-03


"Jim" == Jim Schaad <ietf@augustcellars.com> writes:


    Jim> Is the ABNF for "name" still wrong?

I don't think so.
What problem or oddity do you see?
Hmm.
I see that realm is only permitted if host is present. I think I've fixed

that.

I think it's correct now in 04.

That was the specific error that I saw.



    Jim> section 3.4 missing

    Jim> Section 4 - does/should the application get any control ovret
    Jim> the set of allowable EAP methods to be used or is that purely a
    Jim> fucntion of your GSS-API library

Currently no mechanism is provided for an application to enfluence this.
A mechanism probably should have system-level policy configuration.
A mechanism could expose a credential option on the initiator.
If we ever need to standardize a credential option we can, but I don't see

a

need for that now.



    Jim> For consistency the paragraph: Tokens from the initiator to
    Jim> acceptor use an outer token type of 06 01; tokens from acceptor
    Jim> to initiator use an outer token type of 06 02.  These token
    Jim> types are registered in the registry of RFC 4121 token types;
    Jim> see Section 8.1.

My understanding is that the ID describes which type of token (token
type) we are dealing with.
So, I've phrased it as token s with from acceptor to initiator use  an

inner

token type with ID xxx.
1) token type with ID
and 2) inner not outer

Looks fine


    Jim> should refer to the "token ID" rather than the "outer token
    Jim> type" either that or the item in the table should be updated.

    Jim> section 5.2 refers to "token type" - I think that maybe this is
    Jim> the most constant phrase to be used.

I've updated the registry to talk about token type identifiers.

    Jim> I will say that this version did harmonize and make the token
    Jim> naming scheme much more consistent and readable.  I think this
    Jim> is a big improvement.
Great!

    Jim> s/secondsubtoken/second subtoken/ (in the table)

    Jim> Section 5.3 - Is there going to be a rule that you should send
    Jim> two error subtokens in the even t\the length is greater than 8?
    Jim> I can understand saying you should ignore the extended bytes
    Jim> but should you really ignore the error code itself?

In 04 we have initiators MUST ignore octets beyond the GSS EAP error code
for future extensibility.  Thanks for the catch.

    Jim> Section 5.4 - you have different names for the acceptor name
    Jim> subtokens in the description of what is permitted and the
    Jim> actual subtoken names - I think you might want to harmonize
    Jim> this.

    Jim> Is there a rason that the EAP request subtoken is not
    Jim> documented in section 5.4 since it is a required subtoken from
    Jim> in the Initial State message from the acceptor?

I've added a reference. However I think it's better to document EAP

request

and response near each other.
Note that if we adopt the proposal to reduce a round trip this subtoken

goes

away from initial state.

    Jim> Section 5.4.1 - I realize this is a debugging string (Vender
    Jim> Subtoken) but is there any reason in this day and age not make
    Jim> it a UTF8 string?  (Other than it is not one for Kerbros)

It doesn't exist for Kerberos (which has no vendor string I'm aware of) so

I

don't think that's a concern.

I've made it UTF-8; I don't care.

    Jim> Section 5.4.3 - Should something be said about what the
    Jim> acceptor should do if the initiator sends an acceptor name
    Jim> which is not completely correct for the specific acceptor.  I
    Jim> am thinking specifically of things like adding a host name or
    Jim> adding some service specifics to the acceptor name.  Is this
    Jim> permitted?  Or is this and error condition or since this is
    Jim> typically not sent is the acceptor name from the client to be
    Jim> used in all events. (unless totally wrong)

I think you mean 5.4.2 not 5.4.3?
My assumption is that you need to send a superset of what the acceptor
expects, else things will fail at channel binding. I think you want to

leave it to

channel binding to fail unless an IDP wants to implement  some form of
aliasing.

In 5.4.2 s/hosntame/hostname/

I meant 5.4.3 - because I was assuming this was an Acceptor error rather
than an Initiator.  That is if the Acceptor name is not a superset then it
would return an error.  The question is should you both error and return the
response in some sense.  

One possibility is that the Initiator sends name #1, the Acceptor replies
with name #2 and then the intiator says that this is acceptable and sends
name #2 as part of the channel binding.    In this case the was no error but
the initator name is not a superset of the acceptor name that came back.




    Jim> para #2 s/this token/This token/

    Jim> Section 5.5 s/ACCEPTOR/acceptor/

Not fixed


    Jim> The first bullet of this section is causing me some mental
    Jim> problems.  The acceptor cannot confirm that the protected
    Jim> result and the final result are consistent - this is hidden
    Jim> from the acceptor.  --- or you need to be passing the protected
    Jim> result as a RADIUS attribute, at which point it is not really
    Jim> protected anymore.

For combined authenticators the acceptor can and should evaluate the
protected result.
For pass-through authenticators the acceptor should confirm there's AAA
success if there is EAP success.

Ok - I think this is more clear now.


    Jim> The acceptor can confirm that a key has been delivered to it,
    Jim> but it does not know the source of the key - i.e. was it
    Jim> derived or just transmitted inside of the EAP session.

Here, we mean the security claim discussed in section 7.10 of RFC 3748,

which

probably includes transmitting a key.
Their term, not mine.
I've added a reference.


Ok



    Jim> Should the acceptor or the initiator send the error subtoken -
    Jim> or should the acceptor be looking for clear EAP messages and
    Jim> generate a failure?

I don't understand.

    Jim> I think you need to carefully re-read the section and verify
    Jim> that you think it is correct.

I think it is consistent with what EAP does and what our implementation
does.
There are some disadvantages to how EAP handles failures.
We can discuss at IETF 82 if you like.

I think this would probably be a good idea - just so I can be sure that we
understand each other and what the doc says.  

    Jim> Setion 5.6 - Please tell me which type of channel binding I am
    Jim> getting at this point. (I know it is GSS-API channel binding,
    Jim> but given that two different types are discussed in the
    Jim> document I think being explcit would be good.)

Also added a forward reference.

    Jim> Section 6 - Is the KMSK in the "Tn = " line supposed to be
    Jim> GMSK?
Yes.


    Jim> Section 6.1 - I am unclear what the extension option field is
    Jim> referring to please clarify.

This was all wrong and has been fixed. Thanks for the reality check.


_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------030607090108010106070508-- From wei.yinxing@zte.com.cn Wed Nov 2 08:05:49 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0872911E8102 for ; Wed, 2 Nov 2011 08:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.335 X-Spam-Level: X-Spam-Status: No, score=-97.335 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bMi7B7tLIhd for ; Wed, 2 Nov 2011 08:05:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDFA11E8103 for ; Wed, 2 Nov 2011 08:05:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713967931198; Wed, 2 Nov 2011 23:01:48 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.4809747284; Wed, 2 Nov 2011 23:05:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pA2F5ZeX076694; Wed, 2 Nov 2011 23:05:35 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> To: Rhys Smith MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Wed, 2 Nov 2011 23:05:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-02 23:05:39, Serialize complete at 2011-11-02 23:05:39 Content-Type: multipart/alternative; boundary="=_alternative 0052EAA14825793C_=" X-MAIL: mse02.zte.com.cn pA2F5ZeX076694 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:05:49 -0000 This is a multipart message in MIME format. --=_alternative 0052EAA14825793C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJoeXMNCg0KICBUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbnMuDQogIEkgYWdyZWUg dGhhdCB0aGUgd2hvbGUgZG9jdW1lbnQgU0hPVUxEIGNvbmZvcm1zIHdpdGggdGhlIHNhbWUgc3R5 bGUuIEkgDQphcHByZWNpYXRlIHlvdXIgcmV3b3JkaW5nIHdvcmsuDQoNCk15IGNvbW1lbnQgaXMg YXMgZm9sbG93Lg0KPT09PT0NCg0KQWNjZXNzaW5nIEFwcGxpY2F0aW9ucyBmcm9tIERldmljZXMg b24gYSBNb2JpbGUgVGVsZWNvbXMgSW5mcmFzdHJ1Y3R1cmUNCllpbnhpbmcjMT4gU2hhbGwgdGhl IHVzZSBjYXNlIGJlIGxpbXRlZCBpbiBNb2JpbGUgVGVsZWNvbXMgSW5mcmFzdHJ1Y3R1cmU/IA0K VGhlIG1vYmlsZSBhY2Nlc3MgaXMganVzdCBvbmUgc3BlY2lmaWMgZXhhbXBsZSwgc29tZSBvdGhl ciBhY2Nlc3MgdHlwZXMgDQooZS5nLiBmaXhlZC1saW5lIGFjY2VzcyBzdWNoIGFzIEFEU0wgYWNj ZXNzKSBtYXkgbmVlZCB0byBiZSBjb25zaWRlcmVkLiANCk15IHN1Z2dlc3Rpb24gaXMgdG8gcmVt b3ZlICJNb2JpbGUiIGluIHRoZSB0aXRsZS4NCg0KTW9iaWxlIHRlbGVjb20gb3BlcmF0b3JzIHR5 cGljYWxseSBoYXZlIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoNCg0KICAgICogQSBsYXJnZSBj b2xsZWN0aW9uIG9mIHJlZ2lzdGVyZWQgdXNlcnMsIG1hbnkgb2Ygd2hvbSBtYXkgaGF2ZSANCmlk ZW50aXRpZXMgcmVnaXN0ZXJlZCB0byBhIGZhaXJseSBoaWdoIGxldmVsIG9mIGFzc3VyYW5jZSAo b2Z0ZW4gZm9yIA0KcGF5bWVudCBwdXJwb3NlcykuIEhvd2V2ZXIsIG5vdCBhbGwgdXNlcnMgd2ls bCBoYXZlIHRoaXMgcHJvcGVydHkgLSBmb3IgDQpleGFtcGxlLCBub24tY29udHJhY3QgY3VzdG9t ZXJzIGluIGNvdW50cmllcyB3aXRoIGxvdyBsZXZlbHMgb2YgaWRlbnRpdHkgDQpyZWdpc3RyYXRp b24gcmVxdWlyZW1lbnRzLg0KDQogICAgKiBBbiBleGlzdGluZyBuZXR3b3JrIGluZnJhc3RydWN0 dXJlIGNhcGFibGUgb2YgYXV0aGVudGljYXRpbmcgYSANCm1vYmlsZSBkZXZpY2UsIGFuZCBieSBp bmZlcmVuY2UsIGl0cyBvd25lci4NCg0KICAgICogQSBsYXJnZSBjb2xsZWN0aW9uIG9mIGFwcGxp Y2F0aW9ucyAoYm90aCB3ZWItYmFzZWQgYW5kIG5vbiANCndlYi1iYXNlZCkgdGhhdCBpdHMgdXNl cnMgd2lzaCB0byBhY2Nlc3MgdXNpbmcgdGhlaXIgbW9iaWxlIGRldmljZS4gVGhlc2UgDQphcHBs aWNhdGlvbnMgY291bGQgYmUgaG9zdGVkIGJ5IHRoZSBtb2JpbGUgdGVsZWNvbXMgb3BlcmF0b3Ig ZGlyZWN0bHksIG9yIA0KY291bGQgYmUgYW55IGFwcGxpY2F0aW9uIG9yIHN5c3RlbSBvbiB0aGUg aW50ZXJuZXQgLSBmb3IgZXhhbXBsZSwgbmV0d29yayANCm1lc3NhZ2luZyBzZXJ2aWNlcywgVm9J UCwgZW1haWwsIGV0Yy4NCg0KQXQgcHJlc2VudCwgYXV0aGVudGljYXRpb24gdG8gdGhlc2UgYXBw bGljYXRpb25zIHdpbGwgYmUgdHlwaWNhbGx5IA0KY29uZmlndXJlZCBtYW51YWxseSBieSB0aGUg dXNlciBvbiB0aGVpciBtb2JpbGUgZGV2aWNlIGJ1dCBpbnB1dHRpbmcgdGhlaXIgDQoodXN1YWxs eSBwcmUtcHJvdmlzaW9uZWQgb3V0LW9mLWJhbmQpIGNyZWRlbnRpYWxzIGZvciB0aGF0IGFwcGxp Y2F0aW9uIC0gDQpvbmUgcGVyIGFwcGxpY2F0aW9uLg0KDQpUaGUgdXNlIG9mIEFCRkFCIHRlY2hu b2xvZ2llcyBpbiB0aGlzIGNhc2UsIHZpYSBhIG1lY2hhbmlzbSBkdWJiZWQgDQoiZmVkZXJhdGVk IGNyb3NzLWxheWVyIGFjY2VzcyIgKHNlZSBbcmVmXSkgd291bGQgZW5oYW5jZSB0aGUgdXNlciAN CmV4cGVyaWVuY2Ugb2YgdXNpbmcgdGhlc2UgYXBwbGljYXRpb25zIG9uIG1vYmlsZSBkZXZpY2Vz IGdyZWF0bHkuIA0KRmVkZXJhdGVkIGNyb3NzLWxheWVyIGFjY2VzcyB3b3VsZCBtYWtlIHVzZSBv ZiB0aGUgaW5pdGlhbCBtdXR1YWwgDQphdXRoZW50aWNhdGlvbiBiZXR3ZWVuIGRldmljZSBhbmQg bmV0d29yayB0byBlbmFibGUgc3Vic2VxdWVudCANCmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp c2F0aW9uIHRvIGhhcHBlbiBpbiBhIHNlYW1sZXNzIG1hbm5lciBmb3IgdGhlIA0KdXNlciBvZiB0 aGF0IGRldmljZSBhdXRoZW50aWNhdGluZyB0byBhcHBsaWNhdGlvbnMuDQoNCj09PT09DQoNCi0t LS0tLS0tLS0tLS0NCkJlc3QgUmVnYXJkcyENCllpbnhpbmcgV2VpDQogDQoNCg0KDQpSaHlzIFNt aXRoIDxTbWl0aEBjYXJkaWZmLmFjLnVrPiANCreivP7IyzogIHNtaXRoQENhcmRpZmYuYWMudWsN CjIwMTEvMTEvMDIgMDc6MDYNCg0KytW8/sjLDQp3ZWkueWlueGluZ0B6dGUuY29tLmNuDQqzrcvN DQphYmZhYkBpZXRmLm9yZywgaGFydG1hbnMtaWV0ZkBtaXQuZWR1LCBrd2llcmVuZ0BjaXNjby5j b20sIGxlaWZqQHN1bmV0LnNlDQrW98ziDQpSZTogUGxlYXNlIHJldmlldyB0aGUgdXNlIGNhc2Ug IjQueCBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNzIg0KDQoNCg0KDQoNCg0KSGkgWWlueGlu ZywgKGNjOmVkIHRvIGFiZmFiIGxpc3QgZm9yIGRpc2N1c3Npb24pLA0KDQpTb21lIGFuc3dlcnMg dG8geW91ciBhbnN3ZXJzIGJlbG93LCBmb2xsb3dlZCBieSBzb21lIHN1Z2dlc3RlZCByZXdvcmRp bmcuIA0KDQoNCkZvciB0aGUgdGV4dCAiYnV0IHRoYXQncyBub3QgdGhlIHB1cnBvc2Ugb2YgdGhp cyBkb2N1bWVudCIsIHRoZSANCmNsYXJpZmljYXRpb24gaXMgYXMgZm9sbG93czogDQooMSksIEZl ZGVyYXRlZCBpZGVudGl0eSBpcyBpbiB0aGUgc2NvcGUgb2YgYWJmYWIgd2csYW5kIHRoZSBjYXNl IGFsc28gDQpzdXBwb3J0cyBub24td2ViIGFwcGxpY2F0aW9uLiANCigyKSwgaW4gdGhlIHNlY3Rp b24gMy4gQ29udGV4dCBvZiBVc2UgQ2FzZXMgaW4gdGhpcyBkb2N1bWVudCANCihkcmFmdC1pZXRm LXVzZWNhc2VzLTAxKSwgaXQgc2F5czogDQpJbiB0aGUgaW50ZXJlc3Qgb2YgcHJvbW90aW5nIHRo ZSBkZXZlbG9wbWVudCBvZiB0ZWNobm9sb2d5IG9mIGJyb2FkIA0KYXBwbGljYWJpbGl0eSwgdGhl IHByZXNlbnQgYXV0aG9ycyB3ZWxjb21lIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIA0KZnJv bSBvdGhlciBzZWN0b3JzIGFuZCBjb21tdW5pdGllcy4gDQoNCjEgLSBZZXMsIGZlZGVyYXRlZCBp ZGVudGl0eSBpcyBpbiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBCdXQgdGhlIHB1cnBvc2Ugb2YgDQp0 aGUgd29ya2luZyBncm91cCBpcyBub3QgdG8gZXhwbGFpbiB3aHkgZmVkZXJhdGVkIGlkZW50aXR5 IGluIGdlbmVyYWwgaXMgYSANCmdvb2QgdGhpbmcuDQoNCjIgLSBBYnNvbHV0ZWx5LCBwbGVhc2Ug ZG9uJ3QgbWlzdW5kZXJzdGFuZCwgSSdtIGhhcHB5IHRvIGFjY2VwdCBhbGwgdmFsaWQgDQp1c2Ug Y2FzZXMgdGhhdCBwZW9wbGUgY29tZSB1cCB3aXRoLi4uDQoNCg0KDQpZaW54aW5nIzI+VGhlIHBv aW50IGlzIHRoYXQgdGhlIG1vYmlsZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGhhcyBhbHJlYWR5 IA0KaGFkIHNlY3VyaXR5IGNhcGFiaWxpdGllcyAoZS5nLiBhdXRoZW50aWNhdGlvbiwgaW50ZWdy aXR5IGFuZCANCmNvbmZpZGVudGlhbGl0eSApIHdoaWNoIGlzIG1hbmRhdG9yeSBmb3IgdXNlciBl cXVpcG1lbnQgYXR0YWNrZWQgdG8gDQpuZXR3b3JrLiANCkFwcGxpY2F0aW9uIGNhbiBtYWtlIHVz ZSBvZiB0aGlzIGNhcGFiaWxpdHkgd2l0aG91dCBkdXBsaWNhdGluZyB0aGUgDQpzaW1pbGFyIHRh c2sgZG9uZSBpbiBuZXR3b3JrIGxheWVyLiBBcyB0byBkZXNrdG9wIG9yIGxhcHRvcCwgd2hlbiB0 aGV5IA0KY29ubmVjdCB0byB0aGUgbmV0d29yaywgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZv cm1lZCBpbiBvdGhlciB3YXkgDQpwcm92aWRlZCBieSBuZXR3b3JrIG9wZXJhdG9ycy4gDQoNCg0K T0ssIHllcywgSSBzZWUgdGhhdCBpbiB5b3VyIHBhcnRpY3VsYXIgdXNlIGNhc2UgdGhlIHByb2Nl c3Mgd291bGQgYmUgDQpzbGlnaHRseSBkaWZmZXJlbnQgdGhhbiBpbiBub3JtYWwgdXNlIGNhc2Vz LCBhbmQgc28gdGhlcmVmb3JlIG1pZ2h0IHdlbGwgDQpiZSB3b3J0aHkgb2YgaW5jbHVkaW5nIGlu IHRoZSB1c2UgY2FzZSBkb2MgLSBpZiB5b3VyIHNlcGFyYXRlIEktRCBnYWlucyANCmNvbnNlbnN1 cy4NCg0KSWYgaXQgaXMgdG8gZ28gaW4gdGhlIHVzZSBjYXNlIGRvYywgaG93ZXZlciwgdGhlIGN1 cnJlbnQgdGV4dCBkb2Vzbid0IA0KcmVhbGx5IGZpdCBpbiB0aGUgZG9jdW1lbnQgYXMgaXQgc3Rh bmRzIChib3RoIGluIHRlcm1zIG9mIHN0eWxlIGFuZCANCmNvbnRlbnQpLiBJdCByZWFsbHkgZG9l cyBzYXkgYSBsb3Qgb2YgdW5uZWNlc3NhcnkgdGhpbmdzIChlLmcuIGZlZGVyYXRlZCANCmFjY2Vz cyBpcyBnb29kIGJlY2F1c2UgaXQgbWVhbnMgdXNlcnMgZG9uJ3QgaGF2ZSB0byByZW1lbWJlciBt dWx0aXBsZSANCmNyZWRlbnRpYWxzKSBhbmQgdGhpbmdzIHRoYXQgSSdtIHN1cmUgcGVvcGxlIChp bmNsdWRpbmcgbXlzZWxmKSB3b3VsZCANCmFyZ3VlIHdpdGggKGUuZy4gZG8gYWxsIHRlbGVjb20g b3BlcmF0b3JzIGFsd2F5cyBwcm92aWRlIHRydXN0ZWQgaWRlbnRpdHk/IA0KSSB0aGluayBub3Qh KS4NCg0KU28gSSd2ZSBoYWQgYSBnbyBhdCB3cml0aW5nIG15IG93biB2ZXJzaW9uIG9mIHRoaXMg dXNlIGNhc2UgdHJ5aW5nIHRvIGRyYXcgDQpvdXQgdGhlIG1haW4gcG9pbnRzIHRoYXQgeW91J3Jl IGFyZ3VpbmcgZm9yLiBEb2VzIHRoaXMgY2FwdHVyZSB3aGF0IGlzIA0KdHJ5aW5nIHRvIGJlIHNh aWQgc3VmZmljaWVudGx5IHdlbGw/IChJdCBzdGlsbCBuZWVkcyB0aWR5aW5nIHVwLCBidXQgSSdt IA0KanVzdCB0cnlpbmcgdG8gZ2V0IHRoZSBnaXN0IG9mIHlvdXIgdXNlIGNhc2UgZmlyc3QpLg0K DQo9PT09PQ0KDQpBY2Nlc3NpbmcgQXBwbGljYXRpb25zIGZyb20gRGV2aWNlcyBvbiBhIE1vYmls ZSBUZWxlY29tcyBJbmZyYXN0cnVjdHVyZQ0KDQpNb2JpbGUgdGVsZWNvbSBvcGVyYXRvcnMgdHlw aWNhbGx5IGhhdmUgdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KDQogICAgKiBBIGxhcmdlIGNv bGxlY3Rpb24gb2YgcmVnaXN0ZXJlZCB1c2VycywgbWFueSBvZiB3aG9tIG1heSBoYXZlIA0KaWRl bnRpdGllcyByZWdpc3RlcmVkIHRvIGEgZmFpcmx5IGhpZ2ggbGV2ZWwgb2YgYXNzdXJhbmNlIChv ZnRlbiBmb3IgDQpwYXltZW50IHB1cnBvc2VzKS4gSG93ZXZlciwgbm90IGFsbCB1c2VycyB3aWxs IGhhdmUgdGhpcyBwcm9wZXJ0eSAtIGZvciANCmV4YW1wbGUsIG5vbi1jb250cmFjdCBjdXN0b21l cnMgaW4gY291bnRyaWVzIHdpdGggbG93IGxldmVscyBvZiBpZGVudGl0eSANCnJlZ2lzdHJhdGlv biByZXF1aXJlbWVudHMuDQoNCiAgICAqIEFuIGV4aXN0aW5nIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1 cmUgY2FwYWJsZSBvZiBhdXRoZW50aWNhdGluZyBhIA0KbW9iaWxlIGRldmljZSwgYW5kIGJ5IGlu ZmVyZW5jZSwgaXRzIG93bmVyLg0KDQogICAgKiBBIGxhcmdlIGNvbGxlY3Rpb24gb2YgYXBwbGlj YXRpb25zIChib3RoIHdlYi1iYXNlZCBhbmQgbm9uIA0Kd2ViLWJhc2VkKSB0aGF0IGl0cyB1c2Vy cyB3aXNoIHRvIGFjY2VzcyB1c2luZyB0aGVpciBtb2JpbGUgZGV2aWNlLiBUaGVzZSANCmFwcGxp Y2F0aW9ucyBjb3VsZCBiZSBob3N0ZWQgYnkgdGhlIG1vYmlsZSB0ZWxlY29tcyBvcGVyYXRvciBk aXJlY3RseSwgb3IgDQpjb3VsZCBiZSBhbnkgYXBwbGljYXRpb24gb3Igc3lzdGVtIG9uIHRoZSBp bnRlcm5ldCAtIGZvciBleGFtcGxlLCBuZXR3b3JrIA0KbWVzc2FnaW5nIHNlcnZpY2VzLCBWb0lQ LCBlbWFpbCwgZXRjLg0KDQpBdCBwcmVzZW50LCBhdXRoZW50aWNhdGlvbiB0byB0aGVzZSBhcHBs aWNhdGlvbnMgd2lsbCBiZSB0eXBpY2FsbHkgDQpjb25maWd1cmVkIG1hbnVhbGx5IGJ5IHRoZSB1 c2VyIG9uIHRoZWlyIG1vYmlsZSBkZXZpY2UgYnV0IGlucHV0dGluZyB0aGVpciANCih1c3VhbGx5 IHByZS1wcm92aXNpb25lZCBvdXQtb2YtYmFuZCkgY3JlZGVudGlhbHMgZm9yIHRoYXQgYXBwbGlj YXRpb24gLSANCm9uZSBwZXIgYXBwbGljYXRpb24uDQoNClRoZSB1c2Ugb2YgQUJGQUIgdGVjaG5v bG9naWVzIGluIHRoaXMgY2FzZSwgdmlhIGEgbWVjaGFuaXNtIGR1YmJlZCANCiJmZWRlcmF0ZWQg Y3Jvc3MtbGF5ZXIgYWNjZXNzIiAoc2VlIFtyZWZdKSB3b3VsZCBlbmhhbmNlIHRoZSB1c2VyIA0K ZXhwZXJpZW5jZSBvZiB1c2luZyB0aGVzZSBhcHBsaWNhdGlvbnMgb24gbW9iaWxlIGRldmljZXMg Z3JlYXRseS4gDQpGZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgYWNjZXNzIHdvdWxkIG1ha2UgdXNlIG9m IHRoZSBpbml0aWFsIG11dHVhbCANCmF1dGhlbnRpY2F0aW9uIGJldHdlZW4gZGV2aWNlIGFuZCBu ZXR3b3JrIHRvIGVuYWJsZSBzdWJzZXF1ZW50IA0KYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcmlz YXRpb24gdG8gaGFwcGVuIGluIGEgc2VhbWxlc3MgbWFubmVyIGZvciB0aGUgDQp1c2VyIG9mIHRo YXQgZGV2aWNlIGF1dGhlbnRpY2F0aW5nIHRvIGFwcGxpY2F0aW9ucy4NCg0KPT09PT0NCg0KUmh5 cy4NCi0tDQpEciBSaHlzIFNtaXRoOiBJZGVudGl0eSwgQWNjZXNzLCBhbmQgTWlkZGxld2FyZSBT cGVjaWFsaXN0DQpDYXJkaWZmIFVuaXZlcnNpdHkgJiBKQU5FVChVSykNCg0KZW1haWw6IHNtaXRo QGNhcmRpZmYuYWMudWsgLyByaHlzLnNtaXRoQGphLm5ldA0KR1BHOiAweERFMkYwMjRDDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 0052EAA14825793C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSaHlzPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgVGhhbmtzIGZvciB5 b3VyIGNsYXJpZmljYXRpb25zLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7IEkgYWdyZWUgdGhhdCB0aGUgd2hvbGUgZG9jdW1lbnQNClNIT1VMRCBjb25m b3JtcyB3aXRoIHRoZSBzYW1lIHN0eWxlLiBJIGFwcHJlY2lhdGUgeW91ciByZXdvcmRpbmcgd29y ay48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk15IGNv bW1lbnQgaXMgYXMgZm9sbG93LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+PGk+PT09PT08L2k+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0j ZTEwMDAwIGZhY2U9InNhbnMtc2VyaWYiPjxpPkFjY2Vzc2luZyBBcHBsaWNhdGlvbnMNCmZyb20g RGV2aWNlcyBvbiBhIE1vYmlsZSBUZWxlY29tcyBJbmZyYXN0cnVjdHVyZTwvaT48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+WWlueGluZyMxJmd0 OyBTaGFsbCB0aGUgdXNlDQpjYXNlIGJlIGxpbXRlZCBpbiBNb2JpbGUgVGVsZWNvbXMgSW5mcmFz dHJ1Y3R1cmU/IFRoZSBtb2JpbGUgYWNjZXNzIGlzDQpqdXN0IG9uZSBzcGVjaWZpYyBleGFtcGxl LCBzb21lIG90aGVyIGFjY2VzcyB0eXBlcyAoZS5nLiBmaXhlZC1saW5lIGFjY2Vzcw0Kc3VjaCBh cyBBRFNMIGFjY2VzcykgbWF5IG5lZWQgdG8gYmUgY29uc2lkZXJlZC4gPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPk15IHN1Z2dlc3Rpb24gaXMg dG8gcmVtb3ZlDQomcXVvdDtNb2JpbGUmcXVvdDsgaW4gdGhlIHRpdGxlLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGk+TW9iaWxlIHRlbGVjb20gb3Bl cmF0b3JzIHR5cGljYWxseQ0KaGF2ZSB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6PC9pPjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGk+Jm5ic3A7ICZu YnNwOyAqIEEgbGFyZ2UgY29sbGVjdGlvbg0Kb2YgcmVnaXN0ZXJlZCB1c2VycywgbWFueSBvZiB3 aG9tIG1heSBoYXZlIGlkZW50aXRpZXMgcmVnaXN0ZXJlZCB0byBhIGZhaXJseQ0KaGlnaCBsZXZl bCBvZiBhc3N1cmFuY2UgKG9mdGVuIGZvciBwYXltZW50IHB1cnBvc2VzKS4gSG93ZXZlciwgbm90 IGFsbA0KdXNlcnMgd2lsbCBoYXZlIHRoaXMgcHJvcGVydHkgLSBmb3IgZXhhbXBsZSwgbm9uLWNv bnRyYWN0IGN1c3RvbWVycyBpbg0KY291bnRyaWVzIHdpdGggbG93IGxldmVscyBvZiBpZGVudGl0 eSByZWdpc3RyYXRpb24gcmVxdWlyZW1lbnRzLjwvaT48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxpPiZuYnNwOyAmbmJzcDsgKiBBbiBleGlzdGluZyBu ZXR3b3JrDQppbmZyYXN0cnVjdHVyZSBjYXBhYmxlIG9mIGF1dGhlbnRpY2F0aW5nIGEgbW9iaWxl IGRldmljZSwgYW5kIGJ5IGluZmVyZW5jZSwNCml0cyBvd25lci48L2k+PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48aT4mbmJzcDsgJm5ic3A7ICogQSBs YXJnZSBjb2xsZWN0aW9uDQpvZiBhcHBsaWNhdGlvbnMgKGJvdGggd2ViLWJhc2VkIGFuZCBub24g d2ViLWJhc2VkKSB0aGF0IGl0cyB1c2VycyB3aXNoDQp0byBhY2Nlc3MgdXNpbmcgdGhlaXIgbW9i aWxlIGRldmljZS4gVGhlc2UgYXBwbGljYXRpb25zIGNvdWxkIGJlIGhvc3RlZA0KYnkgdGhlIG1v YmlsZSB0ZWxlY29tcyBvcGVyYXRvciBkaXJlY3RseSwgb3IgY291bGQgYmUgYW55IGFwcGxpY2F0 aW9uIG9yDQpzeXN0ZW0gb24gdGhlIGludGVybmV0IC0gZm9yIGV4YW1wbGUsIG5ldHdvcmsgbWVz c2FnaW5nIHNlcnZpY2VzLCBWb0lQLA0KZW1haWwsIGV0Yy48L2k+PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48aT5BdCBwcmVzZW50LCBhdXRoZW50aWNh dGlvbiB0byB0aGVzZQ0KYXBwbGljYXRpb25zIHdpbGwgYmUgdHlwaWNhbGx5IGNvbmZpZ3VyZWQg bWFudWFsbHkgYnkgdGhlIHVzZXIgb24gdGhlaXINCm1vYmlsZSBkZXZpY2UgYnV0IGlucHV0dGlu ZyB0aGVpciAodXN1YWxseSBwcmUtcHJvdmlzaW9uZWQgb3V0LW9mLWJhbmQpDQpjcmVkZW50aWFs cyBmb3IgdGhhdCBhcHBsaWNhdGlvbiAtIG9uZSBwZXIgYXBwbGljYXRpb24uPC9pPjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGk+VGhlIHVzZSBvZiBB QkZBQiB0ZWNobm9sb2dpZXMgaW4NCnRoaXMgY2FzZSwgdmlhIGEgbWVjaGFuaXNtIGR1YmJlZCAm cXVvdDtmZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgYWNjZXNzJnF1b3Q7DQooc2VlIFtyZWZdKSB3b3Vs ZCBlbmhhbmNlIHRoZSB1c2VyIGV4cGVyaWVuY2Ugb2YgdXNpbmcgdGhlc2UgYXBwbGljYXRpb25z DQpvbiBtb2JpbGUgZGV2aWNlcyBncmVhdGx5LiBGZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgYWNjZXNz IHdvdWxkIG1ha2UgdXNlDQpvZiB0aGUgaW5pdGlhbCBtdXR1YWwgYXV0aGVudGljYXRpb24gYmV0 d2VlbiBkZXZpY2UgYW5kIG5ldHdvcmsgdG8gZW5hYmxlDQpzdWJzZXF1ZW50IGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3Jpc2F0aW9uIHRvIGhhcHBlbiBpbiBhIHNlYW1sZXNzIG1hbm5lcg0KZm9y IHRoZSB1c2VyIG9mIHRoYXQgZGV2aWNlIGF1dGhlbnRpY2F0aW5nIHRvIGFwcGxpY2F0aW9ucy48 L2k+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJIZWx2ZXRpY2EiPjxpPj09 PT09PC9pPjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ LS0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ QmVzdCBSZWdhcmRzITwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ WWlueGluZyBXZWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5SaHlzIFNtaXRoICZsdDtTbWl0aEBjYXJk aWZmLmFjLnVrJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+t6K8/sjLOiAmbmJzcDtzbWl0aEBDYXJkaWZmLmFjLnVrPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEvMTEvMDIgMDc6MDY8L2ZvbnQ+DQo8dGQgd2lk dGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+d2VpLnlpbnhpbmdAenRl LmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+YWJmYWJAaWV0Zi5vcmcsIGhhcnRtYW5zLWlldGZA bWl0LmVkdSwNCmt3aWVyZW5nQGNpc2NvLmNvbSwgbGVpZmpAc3VuZXQuc2U8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBQbGVhc2UgcmV2aWV3IHRoZSB1c2UgY2FzZSAmcXVvdDs0LngNCkZlZGVyYXRl ZCBDcm9zcy1MYXllciBBY2Nlc3MmcXVvdDs8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SGkgWWlueGluZywgKGNj OmVkIHRvIGFiZmFiIGxpc3QgZm9yDQpkaXNjdXNzaW9uKSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlNvbWUgYW5zd2VycyB0byB5b3VyIGFuc3dlcnMg YmVsb3csDQpmb2xsb3dlZCBieSBzb21lIHN1Z2dlc3RlZCByZXdvcmRpbmcuIDwvZm9udD4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5G b3IgdGhlIHRleHQgJnF1b3Q7YnV0IHRoYXQncw0Kbm90IHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9j dW1lbnQmcXVvdDssIHRoZSBjbGFyaWZpY2F0aW9uIGlzIGFzIGZvbGxvd3M6PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQooMSksIEZlZGVyYXRlZCBpZGVudGl0eSBpcyBpbiB0 aGUgc2NvcGUgb2YgYWJmYWIgd2csYW5kIHRoZSBjYXNlIGFsc28gc3VwcG9ydHMNCm5vbi13ZWIg YXBwbGljYXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCigyKSwgaW4g dGhlIDxpPnNlY3Rpb24gMy4gQ29udGV4dCBvZiBVc2UgQ2FzZXM8L2k+IGluIHRoaXMgZG9jdW1l bnQgKGRyYWZ0LWlldGYtdXNlY2FzZXMtMDEpLA0KaXQgc2F5czogPGk+PGJyPg0KSW4gdGhlIGlu dGVyZXN0IG9mIHByb21vdGluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgdGVjaG5vbG9neSBvZiBicm9h ZDwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxpPjxicj4NCmFwcGxpY2FiaWxp dHksIHRoZSBwcmVzZW50IGF1dGhvcnMgd2VsY29tZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50 czwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxpPjxicj4NCmZyb20gb3RoZXIg c2VjdG9ycyBhbmQgY29tbXVuaXRpZXMuPC9pPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjEgLSBZZXMsIGZlZGVyYXRlZCBpZGVudGl0eSBpcyBpbiB0aGUNCnNjb3BlIG9mIHRoZSBX Ry4gQnV0IHRoZSBwdXJwb3NlIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIG5vdCB0byBleHBsYWlu DQp3aHkgZmVkZXJhdGVkIGlkZW50aXR5IGluIGdlbmVyYWwgaXMgYSBnb29kIHRoaW5nLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MiAtIEFic29sdXRl bHksIHBsZWFzZSBkb24ndCBtaXN1bmRlcnN0YW5kLA0KSSdtIGhhcHB5IHRvIGFjY2VwdCBhbGwg dmFsaWQgdXNlIGNhc2VzIHRoYXQgcGVvcGxlIGNvbWUgdXAgd2l0aC4uLjwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij5ZaW54aW5nIzImZ3Q7VGhlIHBvaW50IGlzDQp0aGF0IHRoZSBtb2JpbGUgbmV0d29yayBpbmZy YXN0cnVjdHVyZSBoYXMgYWxyZWFkeSBoYWQgc2VjdXJpdHkgY2FwYWJpbGl0aWVzDQooZS5nLiBh dXRoZW50aWNhdGlvbiwgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHkgKSB3aGljaCBpcyBt YW5kYXRvcnkNCmZvciB1c2VyIGVxdWlwbWVudCBhdHRhY2tlZCB0byBuZXR3b3JrLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQXBwbGljYXRpb24gY2FuIG1ha2UgdXNlIG9m IHRoaXMgY2FwYWJpbGl0eSB3aXRob3V0IGR1cGxpY2F0aW5nIHRoZSBzaW1pbGFyDQp0YXNrIGRv bmUgaW4gbmV0d29yayBsYXllci4gQXMgdG8gZGVza3RvcCBvciBsYXB0b3AsIHdoZW4gdGhleSBj b25uZWN0DQp0byB0aGUgbmV0d29yaywgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBp biBvdGhlciB3YXkgcHJvdmlkZWQgYnkNCm5ldHdvcmsgb3BlcmF0b3JzLjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T0ssIHllcywgSSBzZWUgdGhhdCBpbiB5b3VyIHBhcnRp Y3VsYXINCnVzZSBjYXNlIHRoZSBwcm9jZXNzIHdvdWxkIGJlIHNsaWdodGx5IGRpZmZlcmVudCB0 aGFuIGluIG5vcm1hbCB1c2UgY2FzZXMsDQphbmQgc28gdGhlcmVmb3JlIG1pZ2h0IHdlbGwgYmUg d29ydGh5IG9mIGluY2x1ZGluZyBpbiB0aGUgdXNlIGNhc2UgZG9jDQotIGlmIHlvdXIgc2VwYXJh dGUgSS1EIGdhaW5zIGNvbnNlbnN1cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPklmIGl0IGlzIHRvIGdvIGluIHRoZSB1c2UgY2FzZSBkb2MsDQpob3dl dmVyLCB0aGUgY3VycmVudCB0ZXh0IGRvZXNuJ3QgcmVhbGx5IGZpdCBpbiB0aGUgZG9jdW1lbnQg YXMgaXQgc3RhbmRzDQooYm90aCBpbiB0ZXJtcyBvZiBzdHlsZSBhbmQgY29udGVudCkuIEl0IHJl YWxseSBkb2VzIHNheSBhIGxvdCBvZiB1bm5lY2Vzc2FyeQ0KdGhpbmdzIChlLmcuIGZlZGVyYXRl ZCBhY2Nlc3MgaXMgZ29vZCBiZWNhdXNlIGl0IG1lYW5zIHVzZXJzIGRvbid0IGhhdmUNCnRvIHJl bWVtYmVyIG11bHRpcGxlIGNyZWRlbnRpYWxzKSBhbmQgdGhpbmdzIHRoYXQgSSdtIHN1cmUgcGVv cGxlIChpbmNsdWRpbmcNCm15c2VsZikgd291bGQgYXJndWUgd2l0aCAoZS5nLiBkbyBhbGwgdGVs ZWNvbSBvcGVyYXRvcnMgYWx3YXlzIHByb3ZpZGUNCnRydXN0ZWQgaWRlbnRpdHk/IEkgdGhpbmsg bm90ISkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5T byBJJ3ZlIGhhZCBhIGdvIGF0IHdyaXRpbmcgbXkgb3duIHZlcnNpb24NCm9mIHRoaXMgdXNlIGNh c2UgdHJ5aW5nIHRvIGRyYXcgb3V0IHRoZSBtYWluIHBvaW50cyB0aGF0IHlvdSdyZSBhcmd1aW5n DQpmb3IuIERvZXMgdGhpcyBjYXB0dXJlIHdoYXQgaXMgdHJ5aW5nIHRvIGJlIHNhaWQgc3VmZmlj aWVudGx5IHdlbGw/IChJdA0Kc3RpbGwgbmVlZHMgdGlkeWluZyB1cCwgYnV0IEknbSBqdXN0IHRy eWluZyB0byBnZXQgdGhlIGdpc3Qgb2YgeW91ciB1c2UNCmNhc2UgZmlyc3QpLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT08L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSNlMTAwMDAgZmFjZT0ic2Fucy1zZXJpZiI+QWNjZXNz aW5nIEFwcGxpY2F0aW9ucw0KZnJvbSBEZXZpY2VzIG9uIGEgTW9iaWxlIFRlbGVjb21zIEluZnJh c3RydWN0dXJlPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij5Nb2JpbGUgdGVsZWNvbSBvcGVyYXRvcnMgdHlwaWNhbGx5IGhhdmUNCnRoZSBmb2xsb3dpbmcg cHJvcGVydGllczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgKiBBIGxhcmdlIGNvbGxlY3Rpb24gb2YNCnJlZ2lzdGVyZWQgdXNl cnMsIG1hbnkgb2Ygd2hvbSBtYXkgaGF2ZSBpZGVudGl0aWVzIHJlZ2lzdGVyZWQgdG8gYSBmYWly bHkNCmhpZ2ggbGV2ZWwgb2YgYXNzdXJhbmNlIChvZnRlbiBmb3IgcGF5bWVudCBwdXJwb3Nlcyku IEhvd2V2ZXIsIG5vdCBhbGwNCnVzZXJzIHdpbGwgaGF2ZSB0aGlzIHByb3BlcnR5IC0gZm9yIGV4 YW1wbGUsIG5vbi1jb250cmFjdCBjdXN0b21lcnMgaW4NCmNvdW50cmllcyB3aXRoIGxvdyBsZXZl bHMgb2YgaWRlbnRpdHkgcmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50cy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgKiBBbiBleGlz dGluZyBuZXR3b3JrDQppbmZyYXN0cnVjdHVyZSBjYXBhYmxlIG9mIGF1dGhlbnRpY2F0aW5nIGEg bW9iaWxlIGRldmljZSwgYW5kIGJ5IGluZmVyZW5jZSwNCml0cyBvd25lci48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgKiBBIGxh cmdlIGNvbGxlY3Rpb24gb2YNCmFwcGxpY2F0aW9ucyAoYm90aCB3ZWItYmFzZWQgYW5kIG5vbiB3 ZWItYmFzZWQpIHRoYXQgaXRzIHVzZXJzIHdpc2ggdG8NCmFjY2VzcyB1c2luZyB0aGVpciBtb2Jp bGUgZGV2aWNlLiBUaGVzZSBhcHBsaWNhdGlvbnMgY291bGQgYmUgaG9zdGVkIGJ5DQp0aGUgbW9i aWxlIHRlbGVjb21zIG9wZXJhdG9yIGRpcmVjdGx5LCBvciBjb3VsZCBiZSBhbnkgYXBwbGljYXRp b24gb3Igc3lzdGVtDQpvbiB0aGUgaW50ZXJuZXQgLSBmb3IgZXhhbXBsZSwgbmV0d29yayBtZXNz YWdpbmcgc2VydmljZXMsIFZvSVAsIGVtYWlsLA0KZXRjLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QXQgcHJlc2VudCwgYXV0aGVudGljYXRpb24gdG8g dGhlc2UNCmFwcGxpY2F0aW9ucyB3aWxsIGJlIHR5cGljYWxseSBjb25maWd1cmVkIG1hbnVhbGx5 IGJ5IHRoZSB1c2VyIG9uIHRoZWlyDQptb2JpbGUgZGV2aWNlIGJ1dCBpbnB1dHRpbmcgdGhlaXIg KHVzdWFsbHkgcHJlLXByb3Zpc2lvbmVkIG91dC1vZi1iYW5kKQ0KY3JlZGVudGlhbHMgZm9yIHRo YXQgYXBwbGljYXRpb24gLSBvbmUgcGVyIGFwcGxpY2F0aW9uLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHVzZSBvZiBBQkZBQiB0ZWNobm9sb2dp ZXMgaW4gdGhpcw0KY2FzZSwgdmlhIGEgbWVjaGFuaXNtIGR1YmJlZCAmcXVvdDtmZWRlcmF0ZWQg Y3Jvc3MtbGF5ZXIgYWNjZXNzJnF1b3Q7IChzZWUNCltyZWZdKSB3b3VsZCBlbmhhbmNlIHRoZSB1 c2VyIGV4cGVyaWVuY2Ugb2YgdXNpbmcgdGhlc2UgYXBwbGljYXRpb25zIG9uDQptb2JpbGUgZGV2 aWNlcyBncmVhdGx5LiBGZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgYWNjZXNzIHdvdWxkIG1ha2UgdXNl IG9mDQp0aGUgaW5pdGlhbCBtdXR1YWwgYXV0aGVudGljYXRpb24gYmV0d2VlbiBkZXZpY2UgYW5k IG5ldHdvcmsgdG8gZW5hYmxlDQpzdWJzZXF1ZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp c2F0aW9uIHRvIGhhcHBlbiBpbiBhIHNlYW1sZXNzIG1hbm5lcg0KZm9yIHRoZSB1c2VyIG9mIHRo YXQgZGV2aWNlIGF1dGhlbnRpY2F0aW5nIHRvIGFwcGxpY2F0aW9ucy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkhlbHZldGljYSI+PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlJoeXMuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4tLTxicj4NCkRyIFJoeXMgU21pdGg6IElkZW50aXR5LCBB Y2Nlc3MsIGFuZCBNaWRkbGV3YXJlIFNwZWNpYWxpc3Q8YnI+DQpDYXJkaWZmIFVuaXZlcnNpdHkg JmFtcDsgSkFORVQoVUspPGJyPg0KPGJyPg0KZW1haWw6IDwvZm9udD48YSBocmVmPW1haWx0bzpz bWl0aEBjYXJkaWZmLmFjLnVrPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PnNtaXRoQGNhcmRpZmYuYWMudWs8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQovIDwvZm9udD48YSBocmVmPW1haWx0bzpyaHlzLnNtaXRoQGphLm5l dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yaHlzLnNtaXRo QGphLm5ldDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQpHUEc6IDB4REUyRjAyNEM8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0052EAA14825793C_=-- From smith@Cardiff.ac.uk Wed Nov 2 11:35:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7104911E80D6 for ; Wed, 2 Nov 2011 11:35:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scnYbFGy7Cl1 for ; Wed, 2 Nov 2011 11:35:08 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id A418211E80C8 for ; Wed, 2 Nov 2011 11:35:07 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1RLfeO-0006dk-2G; Wed, 02 Nov 2011 18:35:00 +0000 Received: from [86.189.3.3] (helo=[10.84.70.75]) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RLfeN-0006MC-Uz; Wed, 02 Nov 2011 18:35:00 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_34BF6009-9630-4DED-A12A-60709B7874C6" From: Rhys Smith In-Reply-To: Date: Wed, 2 Nov 2011 18:34:54 +0000 Message-Id: <2F4AB7A1-536B-4EF0-B7B4-6D99039356A4@cardiff.ac.uk> References: To: wei.yinxing@zte.com.cn X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:35:08 -0000 --Apple-Mail=_34BF6009-9630-4DED-A12A-60709B7874C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On 2 Nov 2011, at 15:05, wei.yinxing@zte.com.cn wrote: > Accessing Applications from Devices on a Mobile Telecoms = Infrastructure=20 > Yinxing#1> Shall the use case be limted in Mobile Telecoms = Infrastructure? The mobile access is just one specific example, some = other access types (e.g. fixed-line access such as ADSL access) may need = to be considered.=20 > My suggestion is to remove "Mobile" in the title.=20 Good point - when I was reading your work I was assuming mobile telecoms = - an incorrect assumption on my part. I'll remove Mobile as suggested = and put in the use case doc. R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_34BF6009-9630-4DED-A12A-60709B7874C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 wei.yinxing@zte.com.cn = wrote:
Accessing Applications from Devices on a Mobile Telecoms Infrastructure
Yinxing#1> = Shall the use case be limted in Mobile Telecoms Infrastructure? The mobile access is just one specific example, some other access types (e.g. fixed-line = access such as ADSL access) may need to be considered.
My suggestion is = to remove "Mobile" in the title. 

Good = point - when I was reading your work I was assuming mobile telecoms - an = incorrect assumption on my part. I'll remove Mobile as suggested and put = in the use case doc.

R.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C
In-Reply-To: Date: Wed, 2 Nov 2011 19:07:16 +0000 Message-Id: References: <8EE107E3-4666-4EC0-804B-B2E9CD3645FF@cardiff.ac.uk> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: hartmans-ietf@mit.edu, kwiereng@cisco.com, abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 19:07:27 -0000 --Apple-Mail=_31BF4444-08D2-43D8-BE23-45A95064EC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Nov 2011, at 01:27, Sam Hartman wrote: >=20 > I'm not fond of the architecture of re-using the authentication or at > least am nervous about the architectural coupling involved. Why isn't > it sufficient to simply re-use the credential? I.E. we cann't we = perform > a second mutual authentication.? >=20 > --Sam Well, not my use case - but I was assuming exactly that - a second = mutual auth without having to involve the user, rather than actual reuse = of a single authentication event... R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_31BF4444-08D2-43D8-BE23-45A95064EC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I'm not fond of the architecture of = re-using the authentication or at
least am nervous about the = architectural coupling involved.  Why isn't
it sufficient to = simply re-use the credential? I.E. we cann't we perform
a second = mutual = authentication.?

--Sam


Well, not my use case - but I was assuming exactly that - a = second mutual auth without having to involve the user, rather than = actual reuse of a single authentication = event...

R.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C
To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Soliciting use cases... X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 19:22:05 -0000 --Apple-Mail=_9187C42F-1153-4CE3-8F3E-B44EB8F95D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So, I've made some more wording changes to tidy the doc and I've added = the Cross Layer Access use case, as discussed in the other thread. = Obviously can't post the new version as submission is closed now until = post Taipei. For now though, I'm still looking for some use case text on how abfab = could help the following (these have been mentioned in the past): * SIP * PLASMA * Trust Router * Anything else you can think of! If anyone fancies writing a few paragraphs for how they think abfab = could help these technologies, or anything else you can think of, those = would be gratefully received (I don't know these areas well enough to = write them up myself). I'm happy to accept extremely draft text (on or = off-list) and work with you to tidy it up and flesh it out, if you have = ideas but not the time or inclination to write something properly... Kind Regards, Rhys. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_9187C42F-1153-4CE3-8F3E-B44EB8F95D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii So, = I've made some more wording changes to tidy the doc and I've added the = Cross Layer Access use case, as discussed in the other thread. Obviously = can't post the new version as submission is closed now until post = Taipei.

For now though, I'm still looking for some = use case text on how abfab could help the following (these have been = mentioned in the past):
* SIP
* PLASMA
* = Trust Router
* Anything else you can think = of!

If anyone fancies writing a few paragraphs = for how they think abfab could help these technologies, or anything else = you can think of, those would be gratefully received (I don't know these = areas well enough to write them up myself). I'm happy to accept = extremely draft text (on or off-list) and work with you to tidy it up = and flesh it out, if you have ideas but not the time or inclination to = write something properly...

Kind = Regards,
Rhys.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

= --Apple-Mail=_9187C42F-1153-4CE3-8F3E-B44EB8F95D46-- From hartmans@painless-security.com Wed Nov 2 15:20:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5439811E80A5 for ; Wed, 2 Nov 2011 15:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8nTwZQwMF1e for ; Wed, 2 Nov 2011 15:20:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DD46811E80CB for ; Wed, 2 Nov 2011 15:20:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 719E3201B1; Wed, 2 Nov 2011 18:20:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 949EB435A; Wed, 2 Nov 2011 18:19:52 -0400 (EDT) From: Sam Hartman To: Rhys Smith References: <2F4AB7A1-536B-4EF0-B7B4-6D99039356A4@cardiff.ac.uk> Date: Wed, 02 Nov 2011 18:19:52 -0400 In-Reply-To: <2F4AB7A1-536B-4EF0-B7B4-6D99039356A4@cardiff.ac.uk> (Rhys Smith's message of "Wed, 2 Nov 2011 18:34:54 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hartmans-ietf@mit.edu, kwiereng@cisco.com, abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 22:20:06 -0000 >>>>> "Rhys" == Rhys Smith writes: Rhys> On 2 Nov 2011, at 15:05, wei.yinxing@zte.com.cn wrote: Rhys> Accessing Applications from Devices on a Mobile Telecoms Rhys> Infrastructure Yinxing#1> Shall the use case be limted in Rhys> Mobile Telecoms Infrastructure? The mobile access is just one Rhys> specific example, some other access types (e.g. fixed-line Rhys> access such as ADSL access) may need to be considered. My Rhys> suggestion is to remove "Mobile" in the title. Rhys> Good point - when I was reading your work I was assuming Rhys> mobile telecoms - an incorrect assumption on my part. I'll Rhys> remove Mobile as suggested and put in the use case doc. Rhys> R. -- Dr Rhys Smith: Identity, Access, and Middleware Rhys> Specialist Cardiff University & JANET(UK) I object to this going into the use case doc until we resolve the question about authentication vs credential re-use. I want wording that is neutral on that subject or that favors credential re-use. Obviously, if I'm in the rough I'll stand aside. From smith@Cardiff.ac.uk Wed Nov 2 16:11:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2186221F9DBC for ; Wed, 2 Nov 2011 16:11:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEbaBJzLGWXw for ; Wed, 2 Nov 2011 16:11:13 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4B23B21F9C20 for ; Wed, 2 Nov 2011 16:11:13 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1RLjxZ-0003Ya-Ro; Wed, 02 Nov 2011 23:11:05 +0000 Received: from [217.39.7.252] (helo=[10.84.70.75]) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RLjxZ-0001td-Ng; Wed, 02 Nov 2011 23:11:05 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_9DB47217-E54D-4D82-B643-B6FE59CB4BBE" From: Rhys Smith In-Reply-To: Date: Wed, 2 Nov 2011 23:11:00 +0000 Message-Id: <1600072A-C816-4382-8AD3-31FABB4E2DA5@cardiff.ac.uk> References: <2F4AB7A1-536B-4EF0-B7B4-6D99039356A4@cardiff.ac.uk> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: hartmans-ietf@mit.edu, kwiereng@cisco.com, abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 23:11:14 -0000 --Apple-Mail=_9DB47217-E54D-4D82-B643-B6FE59CB4BBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Nov 2011, at 22:19, Sam Hartman wrote: > I object to this going into the use case doc until we resolve the > question about authentication vs credential re-use. > I want wording that is neutral on that subject or that favors = credential > re-use. OK - you're right, it's important that this is made clear in the use = case. Yinxing, what does the federated cross-layer idea that you're promoting = actually do in terms of reuse of an authentication instance versus reuse = of a credential to create new authentications? We need to make sure the = description is accurate, and when it's accurate, we then need to make = sure that there's consensus in this group that this (whatever your ideas = are) is a good thing. R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_9DB47217-E54D-4D82-B643-B6FE59CB4BBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I object to = this going into the use case doc until we resolve the
question about = authentication vs credential re-use.
I want wording that is neutral = on that subject or that favors = credential
re-use.


OK = - you're right, it's important that this is made clear in the use = case.

Yinxing, what does the federated = cross-layer idea that you're promoting actually do in terms of reuse of = an authentication instance versus reuse of a credential to create new = authentications? We need to make sure the description is accurate, and = when it's accurate, we then need to make sure that there's consensus in = this group that this (whatever your ideas are) is a good = thing.

R.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C
; Thu, 3 Nov 2011 08:06:26 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 09:06:25 +0100 Message-Id: <68C7732B-2124-42FA-B103-FC55D1DFE3DB@wierenga.net> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [abfab] aaa-saml and AAI X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 08:06:29 -0000 for those not on the radext list Begin forwarded message: > From: Alan DeKok > Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab = and SAML) > Date: November 3, 2011 8:02:31 AM GMT+01:00 > To: "Sanchez, Mauricio (HP Networking)" > Cc: Bernard Aboba , "dromasca@avaya.com" = , "radext@ietf.org" >=20 > Sanchez, Mauricio (HP Networking) wrote: >> Alan: I see that you posted a new rev of the NAI doc. Are you = amendable >> to presenting on your doc and framing in the context of the = conversation >> below?=20 >=20 > Yes. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext Begin forwarded message: > From: "Sanchez, Mauricio (HP Networking)" > Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab = and SAML) > Date: November 3, 2011 12:32:38 AM GMT+01:00 > To: Bernard Aboba , Alan DeKok = > Cc: "dromasca@avaya.com" , "radext@ietf.org" = >=20 > We should discuss this at upcoming meeting.=20 > =20 > Alan: I see that you posted a new rev of the NAI doc. Are you = amendable to presenting on your doc and framing in the context of the = conversation below?=20 > =20 > -MS > =20 Begin forwarded message: > From: Bernard Aboba > Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab = and SAML) > Date: November 2, 2011 4:22:25 PM GMT+01:00 > To: Alan DeKok > Cc: "dromasca@avaya.com" , radext@ietf.org >=20 > > > This document includes a requirement for encoding of the NAI as = per RFC > > > 4282. > > >=20 > > > Today, RADIUS implementations do not convert U-labels within the > > > domain-portion of the NAI to A-labels, because the User-Name = attribute > > > is 8-bit clean and designed to handle UTF-8, as described within = RFC > > > 2865, Section 5.1. > >=20 > > I agree. I pointed the document authors to my 4282bis, and they > > pointed out it wasn't a published spec, or even a WG item. > > > > > As a result, RFC 4282 doesn't really apply to RADIUS, and = mentioning > > > that with respect to User-Name encoding is potentially confusing = (and > > > could create an interoperability problem that doesn't exist = today). > >=20 > > This is the most important point for me. > >=20 > > Is it time to move ahead with 4282bis? There have been few comments > > on the existing doc. All it does is codify current practice. > > > > > [BA] Given that the spec would create an incompatible variant of = RADIUS, > I'd say that the situation is pretty serious, and that a document = clarifying > the encoding of the NAI within RADIUS is critical.=20 >=20 > Beyond that though, it strikes me that we may also need a "RADIUS = Change > Process" document. =20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext Begin forwarded message: > From: Alan DeKok > Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab = and SAML) > Date: November 2, 2011 8:43:19 AM GMT+01:00 > To: Bernard Aboba > Cc: "dromasca@avaya.com" , radext@ietf.org >=20 > Bernard Aboba wrote: >> This document includes a requirement for encoding of the NAI as per = RFC >> 4282. >>=20 >> Today, RADIUS implementations do not convert U-labels within the >> domain-portion of the NAI to A-labels, because the User-Name = attribute >> is 8-bit clean and designed to handle UTF-8, as described within RFC >> 2865, Section 5.1. >=20 > I agree. I pointed the document authors to my 4282bis, and they > pointed out it wasn't a published spec, or even a WG item. >=20 >> As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning >> that with respect to User-Name encoding is potentially confusing (and >> could create an interoperability problem that doesn't exist today). >=20 > This is the most important point for me. >=20 > Is it time to move ahead with 4282bis? There have been few comments > on the existing doc. All it does is codify current practice. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext Begin forwarded message: > From: "Romascanu, Dan (Dan)" > Subject: [radext] FW: [abfab] I-D Action: = draft-ietf-abfab-aaa-saml-02.txt > Date: November 1, 2011 2:28:33 PM GMT+01:00 > To: >=20 >=20 > FYI. >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, November 01, 2011 1:44 AM > To: i-d-announce@ietf.org > Cc: abfab@ietf.org > Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Application Bridging for > Federated Access Beyond web Working Group of the IETF. >=20 > Title : A RADIUS Attribute, Binding and Profiles for > SAML > Author(s) : Josh Howlett > Sam Hartman > Filename : draft-ietf-abfab-aaa-saml-02.txt > Pages : 14 > Date : 2011-10-31 >=20 > This document specifies a RADIUS attribute, binding and two profiles > for the Security Assertion Mark-up Language (SAML). The attribute > provides RADIUS encapsulation of SAML protocol messages, while the > binding describes the transport of this attribute, and the SAML > protocol messages within, using RADIUS. The profiles describe the > application of this binding for Abfab authentication and assertion > query/request. The SAML RADIUS attribute and binding are defined > generically to permit application in other scenarios, such as = network > access. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From wei.yinxing@zte.com.cn Thu Nov 3 04:36:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5111E8094 for ; Thu, 3 Nov 2011 04:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.433 X-Spam-Level: X-Spam-Status: No, score=-96.433 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDlNBIDxVy3e for ; Thu, 3 Nov 2011 04:36:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E008E11E8088 for ; Thu, 3 Nov 2011 04:36:38 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690967931198; Thu, 3 Nov 2011 19:27:17 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 27575.4816808042; Thu, 3 Nov 2011 19:36:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pA3BaEjP087829; Thu, 3 Nov 2011 19:36:14 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: <1600072A-C816-4382-8AD3-31FABB4E2DA5@cardiff.ac.uk> To: Rhys Smith MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Thu, 3 Nov 2011 19:35:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-03 19:36:18, Serialize complete at 2011-11-03 19:36:18 Content-Type: multipart/alternative; boundary="=_alternative 003FBDE54825793D_=" X-MAIL: mse02.zte.com.cn pA3BaEjP087829 Cc: abfab@ietf.org, hartmans-ietf@mit.edu, kwiereng@cisco.com Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:36:41 -0000 This is a multipart message in MIME format. --=_alternative 003FBDE54825793D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJoeXMNCg0KICAgSSBhZ3JlZSB3aXRoIHRoZSBwb2ludCB0aGF0IGNyZWRlbnRpYWwgcmUt dXNlIGlzIG1vcmUgYWNjdXJhdGUuIElmIA0Kc29tZW9uZSBwcmVmZXJzIHRvIHVzZSB0aGUgcmVz dWx0IG9mIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9uLCB0aGUgDQp2aWV3IG9mIGNyZWRl bnRpYWwgcmUtdXNlIGlzIE9LLiBJZiBkb2VzIG5vdCwgb25lIGNhbiBjaG9vc2UgdG8gaW5pdGlh dGUgDQphbm90aGVyIGF1dGhlbnRpY2F0aW9uICBmb3IgaGlnaGVyIHNlY3VyaXR5LCBpdCBhbHNv IHdvcmtzLiBJdCBNQVkgZGVwZW5kIA0Kb24gbG9jYWwgcG9saWN5Lg0KDQotLS0tLS0tLS0tLQ0K WWlueGluZyBXZWkNCg0KDQoNCg0KUmh5cyBTbWl0aCA8U21pdGhAY2FyZGlmZi5hYy51az4gDQq3 orz+yMs6ICBzbWl0aEBDYXJkaWZmLmFjLnVrDQoyMDExLzExLzAzIDA3OjExDQoNCsrVvP7Iyw0K U2FtIEhhcnRtYW4gPGhhcnRtYW5zQFBBSU5MRVNTLVNFQ1VSSVRZLkNPTT4NCrOty80NCndlaS55 aW54aW5nQHp0ZS5jb20uY24sIGt3aWVyZW5nQGNpc2NvLmNvbSwgYWJmYWJAaWV0Zi5vcmcsIA0K aGFydG1hbnMtaWV0ZkBtaXQuZWR1DQrW98ziDQpSZTogW2FiZmFiXSBQbGVhc2UgcmV2aWV3IHRo ZSB1c2UgY2FzZSAiNC54IEZlZGVyYXRlZCBDcm9zcy1MYXllciAgQWNjZXNzIg0KDQoNCg0KDQoN Cg0KDQpPbiAyIE5vdiAyMDExLCBhdCAyMjoxOSwgU2FtIEhhcnRtYW4gd3JvdGU6DQoNCkkgb2Jq ZWN0IHRvIHRoaXMgZ29pbmcgaW50byB0aGUgdXNlIGNhc2UgZG9jIHVudGlsIHdlIHJlc29sdmUg dGhlDQpxdWVzdGlvbiBhYm91dCBhdXRoZW50aWNhdGlvbiB2cyBjcmVkZW50aWFsIHJlLXVzZS4N Ckkgd2FudCB3b3JkaW5nIHRoYXQgaXMgbmV1dHJhbCBvbiB0aGF0IHN1YmplY3Qgb3IgdGhhdCBm YXZvcnMgY3JlZGVudGlhbA0KcmUtdXNlLg0KDQoNCk9LIC0geW91J3JlIHJpZ2h0LCBpdCdzIGlt cG9ydGFudCB0aGF0IHRoaXMgaXMgbWFkZSBjbGVhciBpbiB0aGUgdXNlIGNhc2UuDQoNCllpbnhp bmcsIHdoYXQgZG9lcyB0aGUgZmVkZXJhdGVkIGNyb3NzLWxheWVyIGlkZWEgdGhhdCB5b3UncmUg cHJvbW90aW5nIA0KYWN0dWFsbHkgZG8gaW4gdGVybXMgb2YgcmV1c2Ugb2YgYW4gYXV0aGVudGlj YXRpb24gaW5zdGFuY2UgdmVyc3VzIHJldXNlIA0Kb2YgYSBjcmVkZW50aWFsIHRvIGNyZWF0ZSBu ZXcgYXV0aGVudGljYXRpb25zPyBXZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGUgDQpkZXNjcmlwdGlv biBpcyBhY2N1cmF0ZSwgYW5kIHdoZW4gaXQncyBhY2N1cmF0ZSwgd2UgdGhlbiBuZWVkIHRvIG1h a2Ugc3VyZSANCnRoYXQgdGhlcmUncyBjb25zZW5zdXMgaW4gdGhpcyBncm91cCB0aGF0IHRoaXMg KHdoYXRldmVyIHlvdXIgaWRlYXMgYXJlKSANCmlzIGEgZ29vZCB0aGluZy4NCg0KUi4NCi0tDQpE ciBSaHlzIFNtaXRoOiBJZGVudGl0eSwgQWNjZXNzLCBhbmQgTWlkZGxld2FyZSBTcGVjaWFsaXN0 DQpDYXJkaWZmIFVuaXZlcnNpdHkgJiBKQU5FVChVSykNCg0KZW1haWw6IHNtaXRoQGNhcmRpZmYu YWMudWsgLyByaHlzLnNtaXRoQGphLm5ldA0KR1BHOiAweERFMkYwMjRDDQoNCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003FBDE54825793D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSaHlzPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SSBhZ3Jl ZSB3aXRoIHRoZSBwb2ludA0KdGhhdCBjcmVkZW50aWFsIHJlLXVzZSBpcyBtb3JlIGFjY3VyYXRl LiBJZiBzb21lb25lIHByZWZlcnMgdG8gdXNlIHRoZQ0KcmVzdWx0IG9mIG5ldHdvcmsgYWNjZXNz IGF1dGhlbnRpY2F0aW9uLCB0aGUgdmlldyBvZiBjcmVkZW50aWFsIHJlLXVzZQ0KaXMgT0suIElm IGRvZXMgbm90LCBvbmUgY2FuIGNob29zZSB0byBpbml0aWF0ZSBhbm90aGVyIGF1dGhlbnRpY2F0 aW9uICZuYnNwO2Zvcg0KaGlnaGVyIHNlY3VyaXR5LCBpdCBhbHNvIHdvcmtzLiBJdCBNQVkgZGVw ZW5kIG9uIGxvY2FsIHBvbGljeS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5ZaW54aW5nIFdlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzElPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5SaHlzIFNtaXRoICZsdDtTbWl0aEBjYXJkaWZmLmFj LnVrJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ t6K8/sjLOiAmbmJzcDtzbWl0aEBDYXJkaWZmLmFjLnVrPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjIwMTEvMTEvMDMgMDc6MTE8L2ZvbnQ+DQo8dGQgd2lkdGg9Njgl Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2FtIEhhcnRtYW4gJmx0O2hhcnRt YW5zQFBBSU5MRVNTLVNFQ1VSSVRZLkNPTSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPndlaS55aW54 aW5nQHp0ZS5jb20uY24sIGt3aWVyZW5nQGNpc2NvLmNvbSwNCmFiZmFiQGlldGYub3JnLCBoYXJ0 bWFucy1pZXRmQG1pdC5lZHU8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbYWJmYWJdIFBsZWFzZSBy ZXZpZXcgdGhlIHVzZSBjYXNlDQomcXVvdDs0LnggRmVkZXJhdGVkIENyb3NzLUxheWVyICZuYnNw O0FjY2VzcyZxdW90OzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9Mz5PbiAyIE5vdiAyMDExLCBhdCAyMjoxOSwgU2FtIEhhcnRtYW4gd3Jv dGU6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5JIG9iamVjdCB0byB0aGlzIGdvaW5n IGludG8gdGhlIHVzZSBjYXNlIGRvYyB1bnRpbCB3ZQ0KcmVzb2x2ZSB0aGU8YnI+DQpxdWVzdGlv biBhYm91dCBhdXRoZW50aWNhdGlvbiB2cyBjcmVkZW50aWFsIHJlLXVzZS48YnI+DQpJIHdhbnQg d29yZGluZyB0aGF0IGlzIG5ldXRyYWwgb24gdGhhdCBzdWJqZWN0IG9yIHRoYXQgZmF2b3JzIGNy ZWRlbnRpYWw8YnI+DQpyZS11c2UuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mz5PSyAtIHlvdSdyZSByaWdodCwgaXQncyBpbXBvcnRhbnQgdGhhdCB0aGlzIGlzIG1hZGUgY2xl YXINCmluIHRoZSB1c2UgY2FzZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPllpbnhp bmcsIHdoYXQgZG9lcyB0aGUgZmVkZXJhdGVkIGNyb3NzLWxheWVyIGlkZWEgdGhhdA0KeW91J3Jl IHByb21vdGluZyBhY3R1YWxseSBkbyBpbiB0ZXJtcyBvZiByZXVzZSBvZiBhbiBhdXRoZW50aWNh dGlvbiBpbnN0YW5jZQ0KdmVyc3VzIHJldXNlIG9mIGEgY3JlZGVudGlhbCB0byBjcmVhdGUgbmV3 IGF1dGhlbnRpY2F0aW9ucz8gV2UgbmVlZCB0bw0KbWFrZSBzdXJlIHRoZSBkZXNjcmlwdGlvbiBp cyBhY2N1cmF0ZSwgYW5kIHdoZW4gaXQncyBhY2N1cmF0ZSwgd2UgdGhlbg0KbmVlZCB0byBtYWtl IHN1cmUgdGhhdCB0aGVyZSdzIGNvbnNlbnN1cyBpbiB0aGlzIGdyb3VwIHRoYXQgdGhpcyAod2hh dGV2ZXINCnlvdXIgaWRlYXMgYXJlKSBpcyBhIGdvb2QgdGhpbmcuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mz5SLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LS08YnI+DQpEciBSaHlz IFNtaXRoOiBJZGVudGl0eSwgQWNjZXNzLCBhbmQgTWlkZGxld2FyZSBTcGVjaWFsaXN0PGJyPg0K Q2FyZGlmZiBVbml2ZXJzaXR5ICZhbXA7IEpBTkVUKFVLKTxicj4NCjxicj4NCmVtYWlsOiA8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86c21pdGhAY2FyZGlmZi5hYy51az48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dT5zbWl0aEBjYXJkaWZmLmFjLnVrPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPg0K LyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmh5cy5zbWl0aEBqYS5uZXQ+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWU+PHU+cmh5cy5zbWl0aEBqYS5uZXQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+ PGJyPg0KR1BHOiAweERFMkYwMjRDPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003FBDE54825793D_=-- From alex@um.es Thu Nov 3 05:29:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DEC1F0C93 for ; Thu, 3 Nov 2011 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLueQEcsdcNB for ; Thu, 3 Nov 2011 05:29:50 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9F90E1F0C5F for ; Thu, 3 Nov 2011 05:29:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 60E3E5D64F for ; Thu, 3 Nov 2011 13:29:47 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nvh3LEDsxnTU for ; Thu, 3 Nov 2011 13:29:46 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id AE2D25D590 for ; Thu, 3 Nov 2011 13:29:45 +0100 (CET) Message-ID: <4EB28939.7030508@um.es> Date: Thu, 03 Nov 2011 13:29:45 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <20111031234336.4776.78692.idtracker@ietfa.amsl.com> In-Reply-To: <20111031234336.4776.78692.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000706060900080505010808" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:29:50 -0000 This is a multi-part message in MIME format. --------------000706060900080505010808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Josh, I have some few comments regarding version -02 of the aaa-saml draft. Mostly typos. 0. Abstract * "...RADIUS attribute, binding and two..:" -> "RADIUS attribute, a binding and two..." 1. Introduction * In the 3er paragraph it is mentioned Diameter, while it is not mentioned again in the rest of the document. Indeed, it is a RADIUS-specific document. 3. RADIUS SAML-Message Attribute * Length should be >=3, not >=4, since it is stated in the text that Message field can have one or more octets (see description of User-Name attribute in RFC 2865 for a similar attribute). * I have a question related with the RADIUS maximum packet size. RFC 2865 states that the maximum size is 4096 bytes. That means that if an SAML Assertion would be bigger than 4K, it would be impossible to transport it in a single RADIUS message. Even without signatures, a SAML Assertion containing attributes may exceed this size if the attributes contains data enough. Have you thought about any mechanism to lead with this kind of situations, for example the use of a Hash&URL or similar? 5.3.2 * "The Relying Party, on receiving the EAP-Response/Identity message from the User Agent, MUST send it towards the Identity Provider using the SAML RADIUS binding" -> Did you mean RADIUS EAP, or is SAML RADIUS binding intended to transport EAP messages? 5.4.1 * "If the Relying Provider wishes to..." -> "If the Relying Party wishes to..." 5.4.2 * "Provider is NOT obligated to honor the requested set of in the , if any." -> Something missing between "set of" and "in the". 5.4.3 * "Verify that the InResponseTo attribute in the bearer " -> Shouldm't it be "sender-vouches" instead of "bearer"? Regards, Alejandro > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. > > Title : A RADIUS Attribute, Binding and Profiles for SAML > Author(s) : Josh Howlett > Sam Hartman > Filename : draft-ietf-abfab-aaa-saml-02.txt > Pages : 14 > Date : 2011-10-31 > > This document specifies a RADIUS attribute, binding and two profiles > for the Security Assertion Mark-up Language (SAML). The attribute > provides RADIUS encapsulation of SAML protocol messages, while the > binding describes the transport of this attribute, and the SAML > protocol messages within, using RADIUS. The profiles describe the > application of this binding for Abfab authentication and assertion > query/request. The SAML RADIUS attribute and binding are defined > generically to permit application in other scenarios, such as network > access. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------000706060900080505010808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Josh,

I have some few comments regarding version -02 of the aaa-saml draft. Mostly typos.

0. Abstract
  • "...RADIUS attribute, binding and two..:" -> "RADIUS attribute, a binding and two..."

1. Introduction
  • In the 3er paragraph it is mentioned Diameter, while it is not mentioned again in the rest of the document. Indeed, it is a RADIUS-specific document.
3. RADIUS SAML-Message Attribute
  • Length should be >=3, not >=4, since it is stated in the text that Message field can have one or more octets (see description of User-Name attribute in RFC 2865 for a similar attribute).
  • I have a question related with the RADIUS maximum packet size. RFC 2865 states that the maximum size is 4096 bytes. That means that if an SAML Assertion would be bigger than 4K, it would be impossible to transport it in a single RADIUS message. Even without signatures, a SAML Assertion containing attributes may exceed this size if the attributes contains data enough. Have you thought about any mechanism to lead with this kind of situations, for example the use of a Hash&URL or similar?
5.3.2
  • "The Relying Party, on receiving the EAP-Response/Identity message from the User Agent, MUST send it towards the Identity Provider using the SAML RADIUS binding" -> Did you mean RADIUS EAP, or is SAML RADIUS binding intended to transport EAP messages?
5.4.1
  • "If the Relying Provider wishes to..." -> "If the Relying Party wishes to..."
5.4.2
  • "Provider is NOT obligated to honor the requested set of in the <samlp:AuthnRequest>, if any." -> Something missing between "set of" and "in the".
5.4.3
  • "Verify that the InResponseTo attribute in the bearer <saml:SubjectConfirmationData>" -> Shouldm't it be "sender-vouches" instead of "bearer"?
Regards,
Alejandro


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

	Title           : A RADIUS Attribute, Binding and Profiles for SAML
	Author(s)       : Josh Howlett
                          Sam Hartman
	Filename        : draft-ietf-abfab-aaa-saml-02.txt
	Pages           : 14
	Date            : 2011-10-31

   This document specifies a RADIUS attribute, binding and two profiles
   for the Security Assertion Mark-up Language (SAML).  The attribute
   provides RADIUS encapsulation of SAML protocol messages, while the
   binding describes the transport of this attribute, and the SAML
   protocol messages within, using RADIUS.  The profiles describe the
   application of this binding for Abfab authentication and assertion
   query/request.  The SAML RADIUS attribute and binding are defined
   generically to permit application in other scenarios, such as network
   access.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------000706060900080505010808-- From gabilm@um.es Thu Nov 3 06:08:03 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB9011E8117 for ; Thu, 3 Nov 2011 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2n6fUSljL5z for ; Thu, 3 Nov 2011 06:08:02 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0F211E810F for ; Thu, 3 Nov 2011 06:08:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id E96A45362E for ; Thu, 3 Nov 2011 14:08:00 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rqhvEWRU5o-8 for ; Thu, 3 Nov 2011 14:08:00 +0100 (CET) Received: from eduroam_um-230-36.inf.um.es (eduroam_um-230-36.inf.um.es [155.54.230.36]) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPA id B842853810 for ; Thu, 3 Nov 2011 14:07:57 +0100 (CET) Message-ID: <4EB292A6.6040706@um.es> Date: Thu, 03 Nov 2011 14:09:58 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <20111031234336.4776.78692.idtracker@ietfa.amsl.com> <4EB28939.7030508@um.es> In-Reply-To: <4EB28939.7030508@um.es> X-Enigmail-Version: 1.3.2 Content-Type: multipart/alternative; boundary="------------030200040204020009040106" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:08:03 -0000 This is a multi-part message in MIME format. --------------030200040204020009040106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Let me add an additional comment: I wonder about the requirement of not signing the SAML assertion. Maybe it requires a more detailed analysis. First, if the SAML assertion is generated by a legacy idP then it should discriminate between requesters (the RADIUS server in this case) and to decide not to sign the assertion issued for this entity. It could be ok, but I think should be explicitly described in the text. Other option is to allow the RADIUS server cuts short the assertion and to remove the XML signature, but I don't like this. Second, you have to take into account that the SAML assertion will be for a one-time use and it could not be managed/validated by a third party. Let's think in a scenario where the received assertion is used later on to request other end user attributes and the original SAML assertion should be first validated in order to check validity. Best regards, Gabi. El 03/11/11 13:29, Alejandro Perez Mendez escribió: > Hi Josh, > > I have some few comments regarding version -02 of the aaa-saml draft. > Mostly typos. > > 0. Abstract > > * "...RADIUS attribute, binding and two..:" -> "RADIUS attribute, a > binding and two..." > > > 1. Introduction > > * In the 3er paragraph it is mentioned Diameter, while it is not > mentioned again in the rest of the document. Indeed, it is a > RADIUS-specific document. > > 3. RADIUS SAML-Message Attribute > > * Length should be >=3, not >=4, since it is stated in the text that > Message field can have one or more octets (see description of > User-Name attribute in RFC 2865 for a similar attribute). > * I have a question related with the RADIUS maximum packet size. RFC > 2865 states that the maximum size is 4096 bytes. That means that if > an SAML Assertion would be bigger than 4K, it would be impossible to > transport it in a single RADIUS message. Even without signatures, a > SAML Assertion containing attributes may exceed this size if the > attributes contains data enough. Have you thought about any > mechanism to lead with this kind of situations, for example the use > of a Hash&URL or similar? > > 5.3.2 > > * "The Relying Party, on receiving the EAP-Response/Identity message > from the User Agent, MUST send it towards the Identity Provider > using the SAML RADIUS binding" -> Did you mean RADIUS EAP, or is > SAML RADIUS binding intended to transport EAP messages? > > 5.4.1 > > * "If the Relying Provider wishes to..." -> "If the Relying Party > wishes to..." > > 5.4.2 > > * "Provider is NOT obligated to honor the requested set of in the > , if any." -> Something missing between "set of" > and "in the". > > 5.4.3 > > * "Verify that the InResponseTo attribute in the bearer > " -> Shouldm't it be "sender-vouches" > instead of "bearer"? > > Regards, > Alejandro > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Application Bridging >> for Federated Access Beyond web Working Group of the IETF. >> >> Title : A RADIUS Attribute, Binding and Profiles for SAML >> Author(s) : Josh Howlett >> Sam Hartman >> Filename : draft-ietf-abfab-aaa-saml-02.txt >> Pages : 14 >> Date : 2011-10-31 >> >> This document specifies a RADIUS attribute, binding and two profiles >> for the Security Assertion Mark-up Language (SAML). The attribute >> provides RADIUS encapsulation of SAML protocol messages, while the >> binding describes the transport of this attribute, and the SAML >> protocol messages within, using RADIUS. The profiles describe the >> application of this binding for Abfab authentication and assertion >> query/request. The SAML RADIUS attribute and binding are defined >> generically to permit application in other scenarios, such as >> network >> access. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L?pez Mill?n Departamento de Ingenier?a de la Informaci?n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --------------030200040204020009040106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Let me add an additional comment:

I wonder about the requirement of not signing the SAML assertion. Maybe it requires a more detailed analysis.
First, if the SAML assertion is generated by a legacy idP then it should discriminate between requesters (the RADIUS server in this case) and to decide not to sign the assertion issued for this entity. It could be ok, but I think should be explicitly described in the text. Other option is to allow the RADIUS server cuts short the assertion and to remove the XML signature, but I don't like this.
Second, you have to take into account that the SAML assertion will be for a one-time use and it could not be managed/validated by a third party. Let's think in a scenario where the received assertion is used later on to request other end user attributes and the original SAML assertion should be first validated in order to check validity.

Best regards, Gabi.

El 03/11/11 13:29, Alejandro Perez Mendez escribió:
Hi Josh,

I have some few comments regarding version -02 of the aaa-saml draft. Mostly typos.

0. Abstract

 * "...RADIUS attribute, binding and two..:" -> "RADIUS attribute, a
   binding and two..."


1. Introduction

 * In the 3er paragraph it is mentioned Diameter, while it is not
   mentioned again in the rest of the document. Indeed, it is a
   RADIUS-specific document.

3. RADIUS SAML-Message Attribute

 * Length should be >=3, not >=4, since it is stated in the text that
   Message field can have one or more octets (see description of
   User-Name attribute in RFC 2865 for a similar attribute).
 * I have a question related with the RADIUS maximum packet size. RFC
   2865 states that the maximum size is 4096 bytes. That means that if
   an SAML Assertion would be bigger than 4K, it would be impossible to
   transport it in a single RADIUS message. Even without signatures, a
   SAML Assertion containing attributes may exceed this size if the
   attributes contains data enough. Have you thought about any
   mechanism to lead with this kind of situations, for example the use
   of a Hash&URL or similar?

5.3.2

 * "The Relying Party, on receiving the EAP-Response/Identity message
   from the User Agent, MUST send it towards the Identity Provider
   using the SAML RADIUS binding" -> Did you mean RADIUS EAP, or is
   SAML RADIUS binding intended to transport EAP messages?

5.4.1

 * "If the Relying Provider wishes to..." -> "If the Relying Party
   wishes to..."

5.4.2

 * "Provider is NOT obligated to honor the requested set of in the
   <samlp:AuthnRequest>, if any." -> Something missing between "set of"
   and "in the".

5.4.3

 * "Verify that the InResponseTo attribute in the bearer
   <saml:SubjectConfirmationData>" -> Shouldm't it be "sender-vouches"
   instead of "bearer"?

Regards,
Alejandro


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

    Title           : A RADIUS Attribute, Binding and Profiles for SAML
    Author(s)       : Josh Howlett
                           Sam Hartman
    Filename        : draft-ietf-abfab-aaa-saml-02.txt
    Pages           : 14
    Date            : 2011-10-31

    This document specifies a RADIUS attribute, binding and two profiles
    for the Security Assertion Mark-up Language (SAML).  The attribute
    provides RADIUS encapsulation of SAML protocol messages, while the
    binding describes the transport of this attribute, and the SAML
    protocol messages within, using RADIUS.  The profiles describe the
    application of this binding for Abfab authentication and assertion
    query/request.  The SAML RADIUS attribute and binding are defined
    generically to permit application in other scenarios, such as network
    access.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab 



_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab



-- 
----------------------------------------------------------------
Gabriel L—pez Mill‡n
Departamento de Ingenier’a de la Informaci—n y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gabilm@um.es
--------------030200040204020009040106-- From lukeh@padl.com Thu Nov 3 06:10:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0098311E80F4 for ; Thu, 3 Nov 2011 06:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jH2mhz06HcW for ; Thu, 3 Nov 2011 06:10:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id DC7DF21F8D24 for ; Thu, 3 Nov 2011 06:10:50 -0700 (PDT) Received: by us.padl.com with ESMTP id pA3DALDj019852; Thu, 3 Nov 2011 09:10:23 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Luke Howard In-Reply-To: <4EB292A6.6040706@um.es> Date: Fri, 4 Nov 2011 00:10:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031234336.4776.78692.idtracker@ietfa.amsl.com> <4EB28939.7030508@um.es> <4EB292A6.6040706@um.es> To: =?iso-8859-1?Q?Gabriel_L=F3pez?= X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:10:56 -0000 > First, if the SAML assertion is generated by a legacy idP then it = should discriminate between requesters (the RADIUS server in this case) = and to decide not to sign the assertion issued for this entity. It could = be ok, but I think should be explicitly described in the text. Other = option is to allow the RADIUS server cuts short the assertion and to = remove the XML signature, but I don't like this. The acceptor could ignore it. > Second, you have to take into account that the SAML assertion will be = for a one-time use and it could not be managed/validated by a third = party. Let's think in a scenario where the received assertion is used = later on to request other end user attributes and the original SAML = assertion should be first validated in order to check validity. This makes sense (kind of like Kerberos constrained delegation where the = authorisation data is signed). But it could be optional? -- Luke= From gabilm@um.es Thu Nov 3 06:17:20 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6B11E8110 for ; Thu, 3 Nov 2011 06:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JRh6fEbcTIX for ; Thu, 3 Nov 2011 06:17:19 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id BC9B011E810F for ; Thu, 3 Nov 2011 06:17:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 6D66D4C228; Thu, 3 Nov 2011 14:17:17 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w9JXul0Q2Znf; Thu, 3 Nov 2011 14:17:17 +0100 (CET) Received: from eduroam_um-230-36.inf.um.es (eduroam_um-230-36.inf.um.es [155.54.230.36]) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPA id 4624F4C23C; Thu, 3 Nov 2011 14:17:13 +0100 (CET) Message-ID: <4EB294D2.3060305@um.es> Date: Thu, 03 Nov 2011 14:19:14 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Luke Howard References: <20111031234336.4776.78692.idtracker@ietfa.amsl.com> <4EB28939.7030508@um.es> <4EB292A6.6040706@um.es> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:17:20 -0000 El 03/11/11 14:10, Luke Howard escribió: >> First, if the SAML assertion is generated by a legacy idP then it should discriminate between requesters (the RADIUS server in this case) and to decide not to sign the assertion issued for this entity. It could be ok, but I think should be explicitly described in the text. Other option is to allow the RADIUS server cuts short the assertion and to remove the XML signature, but I don't like this. > The acceptor could ignore it. yes, I was thinking in the size of the SAML assertion and the limit of 4096 bytes commented by Alejandro in the last email. The XMLSignature would increase considerably the message size. > >> Second, you have to take into account that the SAML assertion will be for a one-time use and it could not be managed/validated by a third party. Let's think in a scenario where the received assertion is used later on to request other end user attributes and the original SAML assertion should be first validated in order to check validity. > > This makes sense (kind of like Kerberos constrained delegation where the authorisation data is signed). But it could be optional? not sure about that regards, Gabi. > > -- Luke -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From cantor.2@osu.edu Thu Nov 3 07:31:32 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035CE11E80ED for ; Thu, 3 Nov 2011 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rnkSUr73kJx for ; Thu, 3 Nov 2011 07:31:31 -0700 (PDT) Received: from defang4.it.ohio-state.edu (defang4.it.ohio-state.edu [128.146.216.84]) by ietfa.amsl.com (Postfix) with ESMTP id 79D7511E80A4 for ; Thu, 3 Nov 2011 07:31:29 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang4.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pA3EUI7B009908; Thu, 3 Nov 2011 10:31:24 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Thu, 3 Nov 2011 10:30:18 -0400 From: "Cantor, Scott" To: =?iso-8859-1?Q?Gabriel_L=F3pez?= , Luke Howard Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgA== Date: Thu, 3 Nov 2011 14:30:15 +0000 Message-ID: In-Reply-To: <4EB294D2.3060305@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.84 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 14:31:32 -0000 On 11/3/11 9:19 AM, "Gabriel L=F3pez" wrote: >yes, I was thinking in the size of the SAML assertion and the limit of >4096 bytes commented by Alejandro in the last email. The XMLSignature >would increase considerably the message size. The only dramatic size increase comes from putting the certificate in the message. If you don't do that (as in, you don't use PKIX), then it isn't really that large. >>This makes sense (kind of like Kerberos constrained delegation where the >>authorisation data is signed). But it could be optional? >not sure about that Not optional in the sense that it would be used as if it were signed, just optional meaning not all assertions would have that capability. As in fact they wouldn't. You can't just sign the assertion and magically treat it as a reusable token. Well, you can, but those people are ignoring the standard. Other content is also needed or you have a very lax model. -- Scott From alex@um.es Thu Nov 3 07:51:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160B511E80BF for ; Thu, 3 Nov 2011 07:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns2k3-VzvUTG for ; Thu, 3 Nov 2011 07:51:09 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8057111E80B4 for ; Thu, 3 Nov 2011 07:51:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 536494C209 for ; Thu, 3 Nov 2011 15:51:08 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cb68JOVDT6V8 for ; Thu, 3 Nov 2011 15:51:08 +0100 (CET) Received: from [192.168.1.130] (49.247.221.87.dynamic.jazztel.es [87.221.247.49]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 42B834C0EF for ; Thu, 3 Nov 2011 15:51:06 +0100 (CET) Message-ID: <4EB2AA58.1050106@um.es> Date: Thu, 03 Nov 2011 15:51:04 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 14:51:10 -0000 > On 11/3/11 9:19 AM, "Gabriel López" wrote: >> yes, I was thinking in the size of the SAML assertion and the limit of >> 4096 bytes commented by Alejandro in the last email. The XMLSignature >> would increase considerably the message size. > The only dramatic size increase comes from putting the certificate in the > message. If you don't do that (as in, you don't use PKIX), then it isn't > really that large. What if the user has some attribute which is > 4K? For example a photo (for biometric comparation). I think that this situation should not be ignored, even when I can agree it will not be the most usual. Regards, Alejandro From cantor.2@osu.edu Thu Nov 3 07:59:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515D911E80D4 for ; Thu, 3 Nov 2011 07:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.664 X-Spam-Level: X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEHrGNZkLQPb for ; Thu, 3 Nov 2011 07:59:57 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id BFE5611E808E for ; Thu, 3 Nov 2011 07:59:57 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA3Exorx006548; Thu, 3 Nov 2011 10:59:56 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Thu, 3 Nov 2011 10:58:39 -0400 From: "Cantor, Scott" To: Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoA= Date: Thu, 3 Nov 2011 14:58:37 +0000 Message-ID: In-Reply-To: <4EB2AA58.1050106@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <37bcb8ac-092b-452b-85f0-4e21581ad324> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 14:59:58 -0000 On 11/3/11 10:51 AM, "Alejandro Perez Mendez" wrote: >What if the user has some attribute which is > 4K? For example a photo >(for biometric comparation). >I think that this situation should not be ignored, even when I can agree >it will not be the most usual. Sorry, I wasn't saying the assertion wouldn't be > 4K, I was saying the signature alone isn't that much bigger than a mediumish attribute unless you add the cert. I thought the > 4K thing was addressed by chunking it up. If not, you have a problem. -- Scott From alex@um.es Thu Nov 3 08:10:35 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B430A1F0C34 for ; Thu, 3 Nov 2011 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXII2dvR8hyu for ; Thu, 3 Nov 2011 08:09:52 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE531F0C78 for ; Thu, 3 Nov 2011 08:09:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 7BEEE4C217; Thu, 3 Nov 2011 16:09:48 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CIS85Eu5EOqJ; Thu, 3 Nov 2011 16:09:48 +0100 (CET) Received: from [192.168.1.130] (49.247.221.87.dynamic.jazztel.es [87.221.247.49]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id EAA024C222; Thu, 3 Nov 2011 16:09:45 +0100 (CET) Message-ID: <4EB2AEB8.9050709@um.es> Date: Thu, 03 Nov 2011 16:09:44 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Cantor, Scott" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:10:35 -0000 > On 11/3/11 10:51 AM, "Alejandro Perez Mendez" wrote: >> What if the user has some attribute which is> 4K? For example a photo >> (for biometric comparation). >> I think that this situation should not be ignored, even when I can agree >> it will not be the most usual. > Sorry, I wasn't saying the assertion wouldn't be> 4K, I was saying the > signature alone isn't that much bigger than a mediumish attribute unless > you add the cert. > > I thought the> 4K thing was addressed by chunking it up. If not, you have > a problem. That exactly the problem. Even splitting into 253-byte chucks, a RADIUS message cannot have more than 4K in total, including all the attributes. So, I think it would be required to find a solution for this, as it could happen, even without certificates and signatures. Regards, Alejandro > > -- Scott > From cantor.2@osu.edu Thu Nov 3 08:20:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3D91F0C9F for ; Thu, 3 Nov 2011 08:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.66 X-Spam-Level: X-Spam-Status: No, score=-3.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81Mzg8ee8QiK for ; Thu, 3 Nov 2011 08:20:29 -0700 (PDT) Received: from defang18.it.ohio-state.edu (defang18.it.ohio-state.edu [128.146.216.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3D21F0C72 for ; Thu, 3 Nov 2011 08:20:29 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang18.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA3FHkvE030426; Thu, 3 Nov 2011 11:20:25 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Thu, 3 Nov 2011 11:18:41 -0400 From: "Cantor, Scott" To: Alejandro Perez Mendez Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoCAAEYpAP//v3CA Date: Thu, 3 Nov 2011 15:18:39 +0000 Message-ID: In-Reply-To: <4EB2AEB8.9050709@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.132 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:20:29 -0000 On 11/3/11 11:09 AM, "Alejandro Perez Mendez" wrote: >> >> I thought the> 4K thing was addressed by chunking it up. If not, you >>have >> a problem. > >That exactly the problem. Even splitting into 253-byte chucks, a RADIUS >message cannot have more than 4K in total, including all the attributes. >So, I think it would be required to find a solution for this, as it >could happen, even without certificates and signatures. You have to, yes. Depending on the semantics, by reference could work, but it's definitely a pain and complicates the security model. -- Scott From smith@Cardiff.ac.uk Thu Nov 3 08:21:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255E31F0C72 for ; Thu, 3 Nov 2011 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPZ-mU04HihU for ; Thu, 3 Nov 2011 08:21:28 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 458D421F8CBD for ; Thu, 3 Nov 2011 08:21:28 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1RLz6Y-0006z6-CR; Thu, 03 Nov 2011 15:21:22 +0000 Received: from [109.144.21.98] (helo=[10.80.66.141]) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RLz6R-0007Qa-L5; Thu, 03 Nov 2011 15:21:22 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_36A293F8-6485-4C67-AB79-9CC47BB16716" From: Rhys Smith In-Reply-To: <4EB2AEB8.9050709@um.es> Date: Thu, 3 Nov 2011 15:21:09 +0000 Message-Id: References: <4EB2AEB8.9050709@um.es> To: Alejandro Perez Mendez X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:21:29 -0000 --Apple-Mail=_36A293F8-6485-4C67-AB79-9CC47BB16716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote: >=20 >> On 11/3/11 10:51 AM, "Alejandro Perez Mendez" wrote: >>> What if the user has some attribute which is> 4K? For example a = photo >>> (for biometric comparation). >>> I think that this situation should not be ignored, even when I can = agree >>> it will not be the most usual. >> Sorry, I wasn't saying the assertion wouldn't be> 4K, I was saying = the >> signature alone isn't that much bigger than a mediumish attribute = unless >> you add the cert. >>=20 >> I thought the> 4K thing was addressed by chunking it up. If not, you = have >> a problem. >=20 > That exactly the problem. Even splitting into 253-byte chucks, a = RADIUS message cannot have more than 4K in total, including all the = attributes. So, I think it would be required to find a solution for = this, as it could happen, even without certificates and signatures. Could send a SAML artifact and then get the real, large, SAML assertion = by resolving the artifact over http on the issuing IdP? R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_36A293F8-6485-4C67-AB79-9CC47BB16716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 11/3/11 10:51 AM, = "Alejandro Perez Mendez"<alex@um.es> =  wrote:
What if the user has some attribute which is>  4K? = For example a photo
(for biometric = comparation).
I think that this situation = should not be ignored, even when I can = agree
it will not be the most = usual.
Sorry, I = wasn't saying the assertion wouldn't be>  4K, I was saying = the
signature alone isn't that = much bigger than a mediumish attribute = unless
you add the = cert.

I thought = the>  4K thing was addressed by chunking it up. If not, you = have
a = problem.

That exactly the problem. Even splitting = into 253-byte chucks, a RADIUS message cannot have more than 4K in = total, including all the attributes. So, I think it would be required to = find a solution for this, as it could happen, even without certificates = and signatures.

Could send a SAML = artifact and then get the real, large, SAML assertion by resolving the = artifact over http on the issuing = IdP?

R.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C
Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:32:00 -0000 This is a multi-part message in MIME format. --------------090503020506000400080601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 03/11/11 16:21, Rhys Smith escribió: > > On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote: > >> >>> On 11/3/11 10:51 AM, "Alejandro Perez Mendez">> > wrote: >>>> What if the user has some attribute which is> 4K? For example a photo >>>> (for biometric comparation). >>>> I think that this situation should not be ignored, even when I can >>>> agree >>>> it will not be the most usual. >>> Sorry, I wasn't saying the assertion wouldn't be> 4K, I was saying the >>> signature alone isn't that much bigger than a mediumish attribute unless >>> you add the cert. >>> >>> I thought the> 4K thing was addressed by chunking it up. If not, >>> you have >>> a problem. >> >> That exactly the problem. Even splitting into 253-byte chucks, a >> RADIUS message cannot have more than 4K in total, including all the >> attributes. So, I think it would be required to find a solution for >> this, as it could happen, even without certificates and signatures. > > Could send a SAML artifact and then get the real, large, SAML > assertion by resolving the artifact over http on the issuing IdP? You could, but then you would need to rely on a PKI for the trust (during http assertion retrieving). I thought that idea was already discarded in favor of AAA-based trust. Regards, Alejandro > > R. > -- > Dr Rhys Smith: Identity, Access, and Middleware Specialist > Cardiff University & JANET(UK) > > email: smith@cardiff.ac.uk / > rhys.smith@ja.net > GPG: 0xDE2F024C > > --------------090503020506000400080601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

El 03/11/11 16:21, Rhys Smith escribió:

On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote:


On 11/3/11 10:51 AM, "Alejandro Perez Mendez"<alex@um.es>  wrote:
What if the user has some attribute which is>  4K? For example a photo
(for biometric comparation).
I think that this situation should not be ignored, even when I can agree
it will not be the most usual.
Sorry, I wasn't saying the assertion wouldn't be>  4K, I was saying the
signature alone isn't that much bigger than a mediumish attribute unless
you add the cert.

I thought the>  4K thing was addressed by chunking it up. If not, you have
a problem.

That exactly the problem. Even splitting into 253-byte chucks, a RADIUS message cannot have more than 4K in total, including all the attributes. So, I think it would be required to find a solution for this, as it could happen, even without certificates and signatures.

Could send a SAML artifact and then get the real, large, SAML assertion by resolving the artifact over http on the issuing IdP?

You could, but then you would need to rely on a PKI for the trust (during http assertion retrieving). I thought that idea was already discarded in favor of AAA-based trust.

Regards,
Alejandro


R.
--
Dr Rhys Smith: Identity, Access, and Middleware Specialist
Cardiff University & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: 0xDE2F024C


--------------090503020506000400080601-- From leifj@sunet.se Thu Nov 3 08:34:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1441F0CB8 for ; Thu, 3 Nov 2011 08:34:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVy480hUDPVr for ; Thu, 3 Nov 2011 08:34:35 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 30C4D1F0CB3 for ; Thu, 3 Nov 2011 08:34:28 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pA3FYNDQ021079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Nov 2011 16:34:27 +0100 (CET) Message-ID: <4EB2B47F.4060107@sunet.se> Date: Thu, 03 Nov 2011 16:34:23 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <4EB2AEB8.9050709@um.es> <4EB2B3E7.8050208@um.es> In-Reply-To: <4EB2B3E7.8050208@um.es> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:34:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/03/2011 04:31 PM, Alejandro Perez Mendez wrote: > > > El 03/11/11 16:21, Rhys Smith escribió: >> >> On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote: >> >>> >>>> On 11/3/11 10:51 AM, "Alejandro Perez Mendez">>> > wrote: >>>>> What if the user has some attribute which is> 4K? For >>>>> example a photo (for biometric comparation). I think that >>>>> this situation should not be ignored, even when I can >>>>> agree it will not be the most usual. >>>> Sorry, I wasn't saying the assertion wouldn't be> 4K, I was >>>> saying the signature alone isn't that much bigger than a >>>> mediumish attribute unless you add the cert. >>>> >>>> I thought the> 4K thing was addressed by chunking it up. If >>>> not, you have a problem. >>> >>> That exactly the problem. Even splitting into 253-byte chucks, >>> a RADIUS message cannot have more than 4K in total, including >>> all the attributes. So, I think it would be required to find a >>> solution for this, as it could happen, even without >>> certificates and signatures. >> >> Could send a SAML artifact and then get the real, large, SAML >> assertion by resolving the artifact over http on the issuing >> IdP? > > You could, but then you would need to rely on a PKI for the trust > (during http assertion retrieving). I thought that idea was > already discarded in favor of AAA-based trust. You can have any white-list including one based on metadata. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ytH4ACgkQ8Jx8FtbMZnfoEQCdGjcCkryIKRPdbmzuMvWBiBis OLMAnA3fdu6CAPDrrb/MP1HTGFbEMF3Q =EmUx -----END PGP SIGNATURE----- From cantor.2@osu.edu Thu Nov 3 08:35:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462BB11E80D4 for ; Thu, 3 Nov 2011 08:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.656 X-Spam-Level: X-Spam-Status: No, score=-3.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-ik1yY0oS06 for ; Thu, 3 Nov 2011 08:35:41 -0700 (PDT) Received: from defang12.it.ohio-state.edu (defang12.it.ohio-state.edu [128.146.216.21]) by ietfa.amsl.com (Postfix) with ESMTP id C22CC11E80CD for ; Thu, 3 Nov 2011 08:35:41 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang12.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA3FXcqA031292; Thu, 3 Nov 2011 11:35:27 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Thu, 3 Nov 2011 11:33:51 -0400 From: "Cantor, Scott" To: Rhys Smith , Alejandro Perez Mendez Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoCAAEYpAIAAAzGA///AfIA= Date: Thu, 3 Nov 2011 15:33:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.21 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:35:42 -0000 On 11/3/11 11:21 AM, "Rhys Smith" wrote: > >Could send a SAML artifact and then get the real, large, SAML assertion >by resolving the artifact over http on the issuing IdP? Existing SAML 2.0 artifacts reference protocol messages, not assertions. That's not necessarily a problem, you can just wrap it in a Response. Whatever you do by reference also means an extra protocol stack, extra security considerations around the reference and the resolution process, and state management across clusters unless you complicate the model to get around it. -- Scott From diego@tid.es Thu Nov 3 08:40:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613F911E80D4 for ; Thu, 3 Nov 2011 08:40:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I6so8uYW5Lv for ; Thu, 3 Nov 2011 08:40:44 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9D43711E8129 for ; Thu, 3 Nov 2011 08:40:43 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU300FS8CVSHR@tid.hi.inet> for abfab@ietf.org; Thu, 03 Nov 2011 16:40:40 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 73.74.30058.8F5B2BE4; Thu, 03 Nov 2011 16:40:40 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LU300FS5CVSHR@tid.hi.inet> for abfab@ietf.org; Thu, 03 Nov 2011 16:40:40 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 03 Nov 2011 16:40:39 +0100 Date: Thu, 03 Nov 2011 16:40:39 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: "abfab@ietf.org" Message-id: <892DA6FE-399B-4269-8F6A-C734A381CCD0@tid.es> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DMljl/ezQro0XP2K9VJwTg)" Content-language: en-US Accept-Language: en-US Thread-topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-index: AcyaPvBA0BQpMPgERxOOZwDHarPFUQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f3d6d00000756a-b3-4eb2b5f8179c X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXCFe9nqPtj6yY/g77JUhYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo7vq1gKpjpUdN6Zz9zAuMa8i5GTQ0LAROLs3AlMELaYxIV7 69m6GLk4hAS2MUo8/NgKlhAS+MEosWyhP4TdyCixq58bxGYRUJWYdGA1M4jNJqAu0XL0G0sX IweHsICjxIs3KSBhTiDzxotfYGNEgMrPP//ABlLCK2ApsfpYAUiYV0BQ4sfkeywgNrNAtMTT fzuYIWxxiebWm2BxRqDTvp9aAzXGSeLZ70ssELaexNmbd6FqRCXutK9nhHhFQGLJnvPMELao xMvH/1ghrq+VuHl2F/sERtFZSFbPQrJ6FpLVELaBxPtz86Hi2sBweA1l60ts/HKWEVl8ASP7 Kkax4qSizPSMktzEzJx0AyO9jEy9zLzUkk2MkMjK3MG4fKfKIUYBDkYlHl7B8o1+QqyJZcWV uYcYJTmYlER5X23e5CfEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHf9YqAcb0piZVVqUT5MSoaD Q0mCNxSYBIQEi1LTUyvSMnOA6QMmzcTBCdLOA9QeAlLDW1yQmFucmQ6RP8UoKSXOmwKSEABJ ZJTmwfW+YhQHOlIYoo0HmOjgul4BDWQCGuizEWxgSSJCSqqBcd7slDKLLZdFHjk2lr6Yf8NC tlA/pP5UxKkoc+91RVwFCxU8/lcE8FouKNtw5IjEn0IGxZLEjpMPQkQ+hirM2vY/t1xuFSvP 6z9MifPLXwRdNvyxb8H1zgQeHoNscaP7YivLxHzW352z6pLHV+mflZMuv3b7ntB+NHeh/zVz S4GqE2Z/FTUfKbEUZyQaajEXFScCAKGS2XsxAwAA References: <4EB2AEB8.9050709@um.es> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:40:45 -0000 --Boundary_(ID_DMljl/ezQro0XP2K9VJwTg) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi, On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote: On 11/3/11 10:51 AM, "Alejandro Perez Mendez"= > wrote: What if the user has some attribute which is> 4K? For example a photo (for biometric comparation). I think that this situation should not be ignored, even when I can agree it will not be the most usual. Sorry, I wasn't saying the assertion wouldn't be> 4K, I was saying the signature alone isn't that much bigger than a mediumish attribute unless you add the cert. I thought the> 4K thing was addressed by chunking it up. If not, you have a problem. That exactly the problem. Even splitting into 253-byte chucks, a RADIUS mes= sage cannot have more than 4K in total, including all the attributes. So, I= think it would be required to find a solution for this, as it could happen= , even without certificates and signatures. I don't want to open a can of worms, but we could consider the idea of more= compact coding formats, like JWT=85 There is a WG (JOSE, http://datatracke= r.ietf.org/wg/jose/) dealing with this stuff, plus our OAuth colleagues, o= f course. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_DMljl/ezQro0XP2K9VJwTg) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi,

On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote:
On 11/3/11 10:51 AM, "Alejandro Perez Mendez= "<alex@um.es>  wrote:
What if the user has some attribute which is> =  4K? For example a photo
(for biometric comparation).
I think that this situation should not be ignored= , even when I can agree
it will not be the most usual.
Sorry, I wasn't saying the assertion wouldn't be&= gt;  4K, I was saying the
signature alone isn't that much bigger than a med= iumish attribute unless
you add the cert.

I thought the>  4K thing was addressed by= chunking it up. If not, you have
a problem.

That exactly the problem. Even splitting into 253-byte chucks, a RADIUS mes= sage cannot have more than 4K in total, including all the attributes. So, I= think it would be required to find a solution for this, as it could happen= , even without certificates and signatures.

I don't want to open a can of worms, but we could consider the idea of= more compact coding formats, like JWT=85 There is a WG (JOSE, http://datatracker.ietf.or= g/wg/jose/) dealing with  this stuff, plus our OAuth colleagues, o= f course.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: diego@tid.es
Tel:      +34 913 129 041
-----------------------------------------






Este mensaje se dirige exclu= sivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo = y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_DMljl/ezQro0XP2K9VJwTg)-- From cantor.2@osu.edu Thu Nov 3 09:01:02 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BD711E8129 for ; Thu, 3 Nov 2011 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1crJV+lfyyWS for ; Thu, 3 Nov 2011 09:01:01 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7B11E8101 for ; Thu, 3 Nov 2011 09:01:00 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA3G0vre014388; Thu, 3 Nov 2011 12:00:59 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi; Thu, 3 Nov 2011 12:00:32 -0400 From: "Cantor, Scott" To: DIEGO LOPEZ GARCIA , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoCAAEYpAIAAAzGAgAAFcoD//8JAAA== Date: Thu, 3 Nov 2011 15:59:38 +0000 Message-ID: In-Reply-To: <892DA6FE-399B-4269-8F6A-C734A381CCD0@tid.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:01:02 -0000 >I don't want to open a can of worms, but we could consider the idea of >more compact coding formats, like JWT=8A Can you explain how my 5K of data becomes < 4K because I take out some angle brackets? -- Scott From hartmans@painless-security.com Thu Nov 3 10:39:22 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261DD1F0C7C for ; Thu, 3 Nov 2011 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-tcJkO7YXmk for ; Thu, 3 Nov 2011 10:39:21 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8FA1F0C76 for ; Thu, 3 Nov 2011 10:39:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CC924202C9; Thu, 3 Nov 2011 13:40:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5F8C1435A; Thu, 3 Nov 2011 13:39:16 -0400 (EDT) From: Sam Hartman To: wei.yinxing@zte.com.cn References: Date: Thu, 03 Nov 2011 13:39:16 -0400 In-Reply-To: (wei yinxing's message of "Thu, 3 Nov 2011 19:35:56 +0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, hartmans-ietf@mit.edu, kwiereng@cisco.com Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:39:22 -0000 >>>>> "wei" == wei yinxing writes: wei> Hi, Rhys wei> I agree with the point that credential re-use is more wei> accurate. If someone prefers to use the result of network wei> access authentication, the view of credential re-use is OK. If wei> does not, one can choose to initiate another authentication for wei> higher security, it also works. It MAY depend on local policy. OK. I expect this issue will pop up again if we go beyond use-case, but I think that can wait until a mechanism discussion happens. --Sam From hannes.tschofenig@nsn.com Thu Nov 3 10:42:59 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFE411E8132 for ; Thu, 3 Nov 2011 10:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.712 X-Spam-Level: X-Spam-Status: No, score=-106.712 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0w36kDzeVTn for ; Thu, 3 Nov 2011 10:42:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B60DD11E8129 for ; Thu, 3 Nov 2011 10:42:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA3HgkFc022850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 18:42:46 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA3HgiF3000669; Thu, 3 Nov 2011 18:42:45 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 18:42:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9A4F.F9F0E9E8" Date: Thu, 3 Nov 2011 19:44:22 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DBA41BC@FIESEXC035.nsn-intra.net> In-Reply-To: <4EB2B3E7.8050208@um.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AcyaPb4XwiTX+CQ+RFSw0YyNttZ8lwAElEfg References: <4EB2AEB8.9050709@um.es> <4EB2B3E7.8050208@um.es> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Alejandro Perez Mendez" , "Rhys Smith" X-OriginalArrivalTime: 03 Nov 2011 17:42:38.0159 (UTC) FILETIME=[FA6F3DF0:01CC9A4F] Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:42:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9A4F.F9F0E9E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RADIUS was never developed for these types of things. Hence, it is not " = ideally" suited for such scenarios.=20 This was one of the reasons for the development of Diameter.=20 =20 ciao Hannes =20 =20 From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf = Of ext Alejandro Perez Mendez Sent: Thursday, November 03, 2011 5:32 PM To: Rhys Smith Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt =20 El 03/11/11 16:21, Rhys Smith escribi=F3:=20 =20 On 3 Nov 2011, at 15:09, Alejandro Perez Mendez wrote: On 11/3/11 10:51 AM, "Alejandro Perez Mendez" wrote: What if the user has some attribute which is> 4K? For example a photo (for biometric comparation). I think that this situation should not be ignored, even when I can = agree it will not be the most usual. Sorry, I wasn't saying the assertion wouldn't be> 4K, I was saying the signature alone isn't that much bigger than a mediumish attribute = unless you add the cert. =20 I thought the> 4K thing was addressed by chunking it up. If not, you = have a problem. That exactly the problem. Even splitting into 253-byte chucks, a RADIUS = message cannot have more than 4K in total, including all the attributes. = So, I think it would be required to find a solution for this, as it = could happen, even without certificates and signatures. =20 Could send a SAML artifact and then get the real, large, SAML assertion = by resolving the artifact over http on the issuing IdP? You could, but then you would need to rely on a PKI for the trust = (during http assertion retrieving). I thought that idea was already = discarded in favor of AAA-based trust. Regards, Alejandro =20 R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C =20 ------_=_NextPart_001_01CC9A4F.F9F0E9E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

RADIUS was never developed for these types of things. Hence, it is = not “ ideally” suited for such scenarios. =

This was one of the reasons for the development of Diameter. =

 

ciao

Hannes

 

 

From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On = Behalf Of ext Alejandro Perez Mendez
Sent: Thursday, = November 03, 2011 5:32 PM
To: Rhys Smith
Cc: = abfab@ietf.org
Subject: Re: [abfab] I-D Action: = draft-ietf-abfab-aaa-saml-02.txt

 



El = 03/11/11 16:21, Rhys Smith escribi=F3:

 

On = 3 Nov 2011, at 15:09, Alejandro Perez Mendez = wrote:





On 11/3/11 = 10:51 AM, "Alejandro Perez Mendez"<alex@um.es> =  wrote:

What = if the user has some attribute which is>  4K? For example a = photo

(for = biometric = comparation).

I = think that this situation should not be ignored, even when I can = agree

it = will not be the most = usual.

Sorry, I wasn't saying the assertion wouldn't be> =  4K, I was saying the

signature alone isn't that much bigger than a = mediumish attribute unless

you = add the cert.

 

I = thought the>  4K thing was addressed by chunking it up. If not, = you have

a = problem.


That = exactly the problem. Even splitting into 253-byte chucks, a RADIUS = message cannot have more than 4K in total, including all the attributes. = So, I think it would be required to find a solution for this, as it = could happen, even without certificates and = signatures.

 

Could send a SAML artifact and then get the real, = large, SAML assertion by resolving the artifact over http on the issuing = IdP?


You could, but then = you would need to rely on a PKI for the trust (during http assertion = retrieving). I thought that idea was already discarded in favor of = AAA-based = trust.

Regards,
Alejandro


 

R.

--=
Dr Rhys Smith: Identity, Access, and = Middleware Specialist
Cardiff = University & JANET(UK)

email: smith@cardiff.ac.uk / <= a = href=3D"mailto:rhys.smith@ja.net">rhys.smith@ja.net
GPG: = 0xDE2F024C



<= /span>

 

------_=_NextPart_001_01CC9A4F.F9F0E9E8-- From hartmans@painless-security.com Thu Nov 3 10:58:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1E01F0C4F for ; Thu, 3 Nov 2011 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bnb9sC9+DRf for ; Thu, 3 Nov 2011 10:58:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C23E61F0C40 for ; Thu, 3 Nov 2011 10:58:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id ACC5A202D8; Thu, 3 Nov 2011 13:59:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3E9FC435A; Thu, 3 Nov 2011 13:58:22 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Thu, 03 Nov 2011 13:58:22 -0400 In-Reply-To: (Scott Cantor's message of "Thu, 3 Nov 2011 15:59:38 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:58:29 -0000 >>>>> "Cantor," == Cantor, Scott writes: >> I don't want to open a can of worms, but we could consider the >> idea of more compact coding formats, like JWTŠ Cantor,> Can you explain how my 5K of data becomes < 4K because I Cantor,> take out some angle brackets? I have not read 02. I have some comments based on the discussion. 1) aaa-saml MUST NOT normatively repeat any text about the EAP binding from the RADIUS eap binding. As an example the quoted description of the handling of EAP identity is different from the RADIUS EAP spec. We committed to not changing RADIUS or EAP. While I guess we didn't strictly commit to not changing RADIUS EAP, I really don't think we want to go there, especially when we have no good reason for doing so. 2) As has been pointed out the 4096 limit is on RADIUS messages *not* on SAML assertions. Also, it's not a limit: it is a minimum size implementations must handle. So, I think a better way of phrasing this is that if your SAML assertion makes a RADIUS PDE greater than 4k it very likely will not be carried in its entirety. 3) We have no business forbidding signatures. We SHOULD mandate that NASes default to not checking signatures. We SHOULD point out that you can strip/not issue a signature to make your assertion smaller. 4) I prefer attribute query as a way to get larger/more attributes over URL references or artifacts. 5) We need more discussion on the size issue. I'll note several things. First: the protocol may be useful even if it does have limitations. If it happens that most of the things people want to do with it are possible, but some are not, it may have sufficient utilitiy. Compression increases the utility. It doesn't help if you want a 10k photo with FreeRADIUS, but it does help if you're close to the boundary. So, I don't view it as a valid objection that is a size limit or that some use cases are precluded by the size limit. I do view it as an objection that the size limit does not permit enough use cases. I don't know whether that's true. However my personal opinion is that I don't agree with a message complaining about a size limit unless it explains both things that are prohibited and makes an argument about why prohibiting those things is a bad tradeoff. Second: We can explore whether it's operationally viable to raise the limit. I'm a little dubious about this. The RADIUS world seems to have hard-coded the 4k limit in servers and proxies. That is not how I would have done things. I'm told it's a simple constant that can be increased and rebuilt in several popular implementations. I am skeptical of the viability of doing that or how well it works if you do. Still we should consider. However I do believe the length limitation is the big thing to consider for saml-aaa. From ietf@augustcellars.com Thu Nov 3 11:29:52 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D944C11E80AE for ; Thu, 3 Nov 2011 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFCDahp-bLZH for ; Thu, 3 Nov 2011 11:29:52 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A628A11E8083 for ; Thu, 3 Nov 2011 11:29:51 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 360AD2CA49; Thu, 3 Nov 2011 11:29:51 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Cantor, Scott'" References: In-Reply-To: Date: Thu, 3 Nov 2011 11:29:20 -0700 Message-ID: <030d01cc9a56$80db4360$8291ca20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHjWiwTPjzf6dE3+18NjQcI5u21oQNXAzzHlVNASUA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 18:29:53 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Thursday, November 03, 2011 10:58 AM > To: Cantor, Scott > Cc: abfab@ietf.org > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt > > > 3) We have no business forbidding signatures. We SHOULD mandate that > NASes default to not checking signatures. We SHOULD point out that you can > strip/not issue a signature to make your assertion smaller. I agree with this BIG TIME. I have just scanned the draft and the fact that no signatures were allowed gave me heartburn. Jim From Josh.Howlett@ja.net Thu Nov 3 12:00:04 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DF51F0CC9 for ; Thu, 3 Nov 2011 12:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9GaskPM8X8f for ; Thu, 3 Nov 2011 12:00:04 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE0E1F0CBE for ; Thu, 3 Nov 2011 12:00:02 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 656264A6B5E_EB2E4AEB; Thu, 3 Nov 2011 18:59:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id C4FBD4A6B5C_EB2E4ADF; Thu, 3 Nov 2011 18:59:57 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 18:59:57 +0000 From: Josh Howlett To: Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgABNbQA= Date: Thu, 3 Nov 2011 18:59:57 +0000 Message-ID: In-Reply-To: <4EB28939.7030508@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 19:00:05 -0000 Hi Alejandro, Thanks for your careful review. I'll correct the nits ASAP. >=20=20=20=20=20=20 >* In the 3er paragraph it is mentioned Diameter, while it is not > mentioned again in the rest of the document. Indeed, it is a > RADIUS-specific document. Yes; aligning this with the Diameter document is the goal for the next rev. >* I have a question related with the RADIUS maximum packet size. > RFC 2865 states that the maximum size is 4096 bytes. That means > that if an SAML Assertion would be bigger than 4K, it would be > impossible to transport it in a single RADIUS message. Even > without signatures, a SAML Assertion containing attributes may > exceed this size if the attributes contains data enough. Have > you thought about any mechanism to lead with this kind of > situations, for example the use of a Hash&URL or similar? In this case I believe that Diameter should be used. I agree that it would be possible to invent a callback mechanism to resolve a jumbo assertion, but I believe that these would introduce non-trivial implementation and operational issues. Speaking from an operator's perspective, I would personally prefer to increase the RADIUS message MTU (particularly for the TCP transport case), but obviously there are process considerations that could impede this. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Thu Nov 3 12:00:05 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DFD11E80DA for ; Thu, 3 Nov 2011 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZsrLgogcJjR for ; Thu, 3 Nov 2011 12:00:04 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF871F0CC2 for ; Thu, 3 Nov 2011 12:00:04 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0A9781A9DA89_EB2E4B2B; Thu, 3 Nov 2011 19:00:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D649B1A9DA88_EB2E4B1F; Thu, 3 Nov 2011 19:00:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 19:00:01 +0000 From: Josh Howlett To: "Cantor, Scott" , Alejandro Perez Mendez Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAJ+gIAAH7iA Date: Thu, 3 Nov 2011 19:00:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <361757FC5CF460419F438F0EB277DAD7@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 19:00:05 -0000 >Depending on the semantics, by reference could work, but it's definitely a >pain and complicates the security model. That was my conclusion in a nutshell. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Thu Nov 3 14:33:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FC81F0CB2 for ; Thu, 3 Nov 2011 14:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gArvoHZ9nWUH for ; Thu, 3 Nov 2011 14:33:55 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id BCC091F0C7F for ; Thu, 3 Nov 2011 14:33:52 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0A4411A9D9A6_EB308C0B; Thu, 3 Nov 2011 21:33:52 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D2B0E1A9D72A_EB308BFF; Thu, 3 Nov 2011 21:33:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 21:33:51 +0000 From: Josh Howlett To: Sam Hartman , "Cantor, Scott" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AAO+WA Date: Thu, 3 Nov 2011 21:33:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:33:56 -0000 Sam, > >1) aaa-saml MUST NOT normatively repeat any text about the EAP binding >from the RADIUS eap binding. As an example the quoted description of the >handling of EAP identity is different from the RADIUS EAP spec. We >committed to not changing RADIUS or EAP. While I guess we didn't >strictly commit to not changing RADIUS EAP, I really don't think we want >to go there, especially when we have no good reason for doing so. Point taken. This started off as a narrative and ended up being prescriptive. I'll fix. >4) I prefer attribute query as a way to get larger/more attributes over >URL references or artifacts. I'd prefer Diameter. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Thu Nov 3 14:36:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4395E1F0CB6 for ; Thu, 3 Nov 2011 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv3R83oQUmtx for ; Thu, 3 Nov 2011 14:36:35 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id B19291F0CB2 for ; Thu, 3 Nov 2011 14:36:35 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 081AD1A9D50A_EB30963B; Thu, 3 Nov 2011 21:36:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D492F1A9D1ED_EB30962F; Thu, 3 Nov 2011 21:36:34 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 21:36:34 +0000 From: Josh Howlett To: Jim Schaad , Sam Hartman , "'Cantor, Scott'" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AACFoAgAA0TQA= Date: Thu, 3 Nov 2011 21:36:33 +0000 Message-ID: In-Reply-To: <030d01cc9a56$80db4360$8291ca20$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C703600EADE3C499DD1BA786B3BDC70@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:36:36 -0000 >> >>3) We have no business forbidding signatures. We SHOULD mandate that >> NASes default to not checking signatures. We SHOULD point out that you >>can >> strip/not issue a signature to make your assertion smaller. > >I agree with this BIG TIME. I have just scanned the draft and the fact >that >no signatures were allowed gave me heartburn. I am happy with Sam's proposal, and I'll update accordingly. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From diego@tid.es Thu Nov 3 15:13:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82A11E80B7 for ; Thu, 3 Nov 2011 15:13:21 -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.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdWgiCfTo8k3 for ; Thu, 3 Nov 2011 15:13:20 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 90F5311E80A2 for ; Thu, 3 Nov 2011 15:13:20 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU300D11V27GV@tid.hi.inet> for abfab@ietf.org; Thu, 03 Nov 2011 23:13:19 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 5B.58.30058.FF113BE4; Thu, 03 Nov 2011 23:13:19 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LU300D0YV26GV@tid.hi.inet> for abfab@ietf.org; Thu, 03 Nov 2011 23:13:18 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Thu, 03 Nov 2011 23:13:18 +0100 Date: Thu, 03 Nov 2011 23:13:18 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: "abfab@ietf.org" Message-id: <543331DE-62E9-4870-8731-46A3B8D461F7@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-index: Acyadcq3gIGprc4FTgKL8Kp6s/WJ7Q== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f3d6d00000756a-9e-4eb311ff6dda X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42Lhivcz1P0vuNnP4PkcDouP198wOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+XjFtaCBs6KfWenMTUw9rF3MXJySAiYSLQ9WQRli0lcuLee rYuRi0NIYBujxMmGLVDOD0aJ/3/OsUM4jYwSU99MZepi5OBgEVCVaO+2A+lmE1CXaDn6jQUk LCzgKPHiTQpImFNAT+Lg106wBSJA1eeff2ADsXkFLCWa+/8zQtiCEj8m32MBsZmB6j/+uc0I YYtLNLfehIprSzx5d4EVxGYEOvT7qTVMEDOdJJ79vsQCYetJ9G/qZIaoEZW4076eEeIxAYkl e84zQ9iiEi8f/wObIySgK3F50mX2CYxis5CcMQvJGbOQnDELyRkLGFlWMYoVJxVlpmeU5CZm 5qQbGOllZOpl5qWWbGKEREvmDsblO1UOMQpwMCrx8AqWb/QTYk0sK67MPcQoycGkJMprxL/Z T4gvKT+lMiOxOCO+qDQntfgQowQHs5IIr/KPTX5CvCmJlVWpRfkwKRkODiUJ3psCQG2CRanp qRVpmTnAlACTZuLgBGnnAWpnByYIId7igsTc4sx0iPwpRkkpcV4lkIQASCKjNA+u9xWjONCR wrxCIFkeYPKC63oFNJAJaKDPRpB7iksSEVJSDYy9Ott77KpKLDa9Ov7Z7jVn2X3lyjO/n8xp OzZ9g9+XwKOPd732qmksvvt4wdNpj9QWGBgVszt+DVy6UtUoQydZIVVz3bk3V7ob11+u2Tct ifHQXIPN6jbHc84E/Y+U4cvsV/5Vuvv69A7ZDZoR1wI/lwc9yHqbkSPavilMcM+RbcbW+c7K VycrsRRnJBpqMRcVJwIAXeR6VhsDAAA= References: Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 22:13:21 -0000 On 3 Nov 2011, at 16:59 , Cantor, Scott wrote: >> I don't want to open a can of worms, but we could consider the idea of >> more compact coding formats, like JWT=8A > > Can you explain how my 5K of data becomes < 4K because I take out some > angle brackets? It is not some angle brackets, but avoiding XML verbosity. Anyway, I'd agre= e that a solution like this (or compression or anything similar) would only= move the bar a little bit higher. When (and if) assertion size becomes a p= roblem, the only choices I think you'll have are attribute queries or DIAME= TER=85 Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From wei.yinxing@zte.com.cn Thu Nov 3 17:58:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D211E80DE; Thu, 3 Nov 2011 17:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.485 X-Spam-Level: X-Spam-Status: No, score=-97.485 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv4D1vi+3E7y; Thu, 3 Nov 2011 17:58:05 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DF92111E80AB; Thu, 3 Nov 2011 17:58:04 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417132100040734; Fri, 4 Nov 2011 08:54:01 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.2787061262; Fri, 4 Nov 2011 08:57:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pA40vhO5066233; Fri, 4 Nov 2011 08:57:46 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Rhys Smith MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Fri, 4 Nov 2011 08:57:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-04 08:57:47, Serialize complete at 2011-11-04 08:57:47 Content-Type: multipart/alternative; boundary="=_alternative 00054A5C4825793E_=" X-MAIL: mse02.zte.com.cn pA40vhO5066233 Cc: abfab@ietf.org, abfab-bounces@ietf.org Subject: Re: [abfab] Soliciting use cases... X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:58:06 -0000 This is a multipart message in MIME format. --=_alternative 00054A5C4825793E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJoeXMNCg0KICBJIGhhdmUgYSBsaXR0bGUgY29uZnVzaW9uIGFib3V0IHRoZSBzdWJtaXNz aW9uIGRhdGUgb2YgdGhlIG5ldyB2ZXJzaW9uLiANCkZvciBteSBrbm93bGVkZ2UgaW4gSUVURiwg b25lIGNhbiBzdWJtaXQgYSBkcmFmdCBhdCBhbnkgdGltZS4gT25seSBpZiBvbmUgDQp3YW50cyB0 byBwcmVzZW50IGF0IHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZywgb25lIE1VU1Qgc3VibWl0IGl0 IGJlZm9yZSANCnRoZSBkZWFkbGluZSBvZiB0aGUgc3VibWlzc2lvbi4NCg0KIElmIG15IHVuZGVy c3RhbmRpbmcgaXMgY29ycmVjdCwgdG8gcG9zdCB0aGUgbmV3IHZlcnNpb24gd2lsbCBub3QgYmUg YW4gDQppc3N1ZSwgZm9yIHdlIGhhdmUgZ290IHJvdWdoIGNvbnNlbnN1cyBvbiB0aGlzIHVzZSBj YXNlLiBJZiBub3QsIGl0IGlzIA0KcmVhc29uYWJsZSB0byBmb2xsb3cgeW91ciBhZHZpY2UuDQoN Ci0tLS0tLS0tLS0tLQ0KWWlueGluZyBXZWkNCg0KIA0KDQoNCg0KUmh5cyBTbWl0aCA8c21pdGhA Y2FyZGlmZi5hYy51az4gDQq3orz+yMs6ICBhYmZhYi1ib3VuY2VzQGlldGYub3JnDQoyMDExLzEx LzAzIDAzOjIxDQoNCsrVvP7Iyw0KYWJmYWJAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0KW2FiZmFi XSBTb2xpY2l0aW5nIHVzZSBjYXNlcy4uLg0KDQoNCg0KDQoNCg0KU28sIEkndmUgbWFkZSBzb21l IG1vcmUgd29yZGluZyBjaGFuZ2VzIHRvIHRpZHkgdGhlIGRvYyBhbmQgSSd2ZSBhZGRlZCB0aGUg DQpDcm9zcyBMYXllciBBY2Nlc3MgdXNlIGNhc2UsIGFzIGRpc2N1c3NlZCBpbiB0aGUgb3RoZXIg dGhyZWFkLiBPYnZpb3VzbHkgDQpjYW4ndCBwb3N0IHRoZSBuZXcgdmVyc2lvbiBhcyBzdWJtaXNz aW9uIGlzIGNsb3NlZCBub3cgdW50aWwgcG9zdCBUYWlwZWkuDQoNCkZvciBub3cgdGhvdWdoLCBJ J20gc3RpbGwgbG9va2luZyBmb3Igc29tZSB1c2UgY2FzZSB0ZXh0IG9uIGhvdyBhYmZhYiANCmNv dWxkIGhlbHAgdGhlIGZvbGxvd2luZyAodGhlc2UgaGF2ZSBiZWVuIG1lbnRpb25lZCBpbiB0aGUg cGFzdCk6DQoqIFNJUA0KKiBQTEFTTUENCiogVHJ1c3QgUm91dGVyDQoqIEFueXRoaW5nIGVsc2Ug eW91IGNhbiB0aGluayBvZiENCg0KSWYgYW55b25lIGZhbmNpZXMgd3JpdGluZyBhIGZldyBwYXJh Z3JhcGhzIGZvciBob3cgdGhleSB0aGluayBhYmZhYiBjb3VsZCANCmhlbHAgdGhlc2UgdGVjaG5v bG9naWVzLCBvciBhbnl0aGluZyBlbHNlIHlvdSBjYW4gdGhpbmsgb2YsIHRob3NlIHdvdWxkIGJl IA0KZ3JhdGVmdWxseSByZWNlaXZlZCAoSSBkb24ndCBrbm93IHRoZXNlIGFyZWFzIHdlbGwgZW5v dWdoIHRvIHdyaXRlIHRoZW0gdXAgDQpteXNlbGYpLiBJJ20gaGFwcHkgdG8gYWNjZXB0IGV4dHJl bWVseSBkcmFmdCB0ZXh0IChvbiBvciBvZmYtbGlzdCkgYW5kIA0Kd29yayB3aXRoIHlvdSB0byB0 aWR5IGl0IHVwIGFuZCBmbGVzaCBpdCBvdXQsIGlmIHlvdSBoYXZlIGlkZWFzIGJ1dCBub3QgDQp0 aGUgdGltZSBvciBpbmNsaW5hdGlvbiB0byB3cml0ZSBzb21ldGhpbmcgcHJvcGVybHkuLi4NCg0K S2luZCBSZWdhcmRzLA0KUmh5cy4NCi0tDQpEciBSaHlzIFNtaXRoOiBJZGVudGl0eSwgQWNjZXNz LCBhbmQgTWlkZGxld2FyZSBTcGVjaWFsaXN0DQpDYXJkaWZmIFVuaXZlcnNpdHkgJiBKQU5FVChV SykNCg0KZW1haWw6IHNtaXRoQGNhcmRpZmYuYWMudWsgLyByaHlzLnNtaXRoQGphLm5ldA0KR1BH OiAweERFMkYwMjRDDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KYWJmYWIgbWFpbGluZyBsaXN0DQphYmZhYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00054A5C4825793E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSaHlzPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSSBoYXZlIGEgbGl0 dGxlIGNvbmZ1c2lvbiBhYm91dA0KdGhlIHN1Ym1pc3Npb24gZGF0ZSBvZiB0aGUgbmV3IHZlcnNp b24uIEZvciBteSBrbm93bGVkZ2UgaW4gSUVURiwgb25lIGNhbg0Kc3VibWl0IGEgZHJhZnQgYXQg YW55IHRpbWUuIE9ubHkgaWYgb25lIHdhbnRzIHRvIHByZXNlbnQgYXQgdGhlIGZhY2UtdG8tZmFj ZQ0KbWVldGluZywgb25lIE1VU1Qgc3VibWl0IGl0IGJlZm9yZSB0aGUgZGVhZGxpbmUgb2YgdGhl IHN1Ym1pc3Npb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDtJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsDQp0byBwb3N0IHRoZSBu ZXcgdmVyc2lvbiB3aWxsIG5vdCBiZSBhbiBpc3N1ZSwgZm9yIHdlIGhhdmUgZ290IHJvdWdoIGNv bnNlbnN1cw0Kb24gdGhpcyB1c2UgY2FzZS4gSWYgbm90LCBpdCBpcyByZWFzb25hYmxlIHRvIGZv bGxvdyB5b3VyIGFkdmljZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPi0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+WWlueGluZyBXZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj5SaHlzIFNtaXRoICZsdDtzbWl0aEBjYXJkaWZmLmFjLnVrJmd0Ozwv Yj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAm bmJzcDthYmZhYi1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTEvMTEvMDMgMDM6MjE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+YWJmYWJAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlthYmZhYl0gU29s aWNpdGluZyB1c2UgY2FzZXMuLi48L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+U28sIEkndmUgbWFkZSBzb21lIG1vcmUgd29yZGluZyBjaGFuZ2Vz IHRvIHRpZHkgdGhlIGRvYw0KYW5kIEkndmUgYWRkZWQgdGhlIENyb3NzIExheWVyIEFjY2VzcyB1 c2UgY2FzZSwgYXMgZGlzY3Vzc2VkIGluIHRoZSBvdGhlcg0KdGhyZWFkLiBPYnZpb3VzbHkgY2Fu J3QgcG9zdCB0aGUgbmV3IHZlcnNpb24gYXMgc3VibWlzc2lvbiBpcyBjbG9zZWQgbm93DQp1bnRp bCBwb3N0IFRhaXBlaS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkZvciBub3cgdGhv dWdoLCBJJ20gc3RpbGwgbG9va2luZyBmb3Igc29tZSB1c2UgY2FzZSB0ZXh0DQpvbiBob3cgYWJm YWIgY291bGQgaGVscCB0aGUgZm9sbG93aW5nICh0aGVzZSBoYXZlIGJlZW4gbWVudGlvbmVkIGlu IHRoZQ0KcGFzdCk6PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4qIFNJUDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+KiBQTEFTTUE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiogVHJ1c3QgUm91 dGVyPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4qIEFueXRoaW5nIGVsc2UgeW91IGNhbiB0aGlu ayBvZiE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPklmIGFueW9uZSBmYW5jaWVzIHdy aXRpbmcgYSBmZXcgcGFyYWdyYXBocyBmb3IgaG93IHRoZXkNCnRoaW5rIGFiZmFiIGNvdWxkIGhl bHAgdGhlc2UgdGVjaG5vbG9naWVzLCBvciBhbnl0aGluZyBlbHNlIHlvdSBjYW4gdGhpbmsNCm9m LCB0aG9zZSB3b3VsZCBiZSBncmF0ZWZ1bGx5IHJlY2VpdmVkIChJIGRvbid0IGtub3cgdGhlc2Ug YXJlYXMgd2VsbCBlbm91Z2gNCnRvIHdyaXRlIHRoZW0gdXAgbXlzZWxmKS4gSSdtIGhhcHB5IHRv IGFjY2VwdCBleHRyZW1lbHkgZHJhZnQgdGV4dCAob24NCm9yIG9mZi1saXN0KSBhbmQgd29yayB3 aXRoIHlvdSB0byB0aWR5IGl0IHVwIGFuZCBmbGVzaCBpdCBvdXQsIGlmIHlvdSBoYXZlDQppZGVh cyBidXQgbm90IHRoZSB0aW1lIG9yIGluY2xpbmF0aW9uIHRvIHdyaXRlIHNvbWV0aGluZyBwcm9w ZXJseS4uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+S2luZCBSZWdhcmRzLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+Umh5cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPi0tPGJy Pg0KRHIgUmh5cyBTbWl0aDogSWRlbnRpdHksIEFjY2VzcywgYW5kIE1pZGRsZXdhcmUgU3BlY2lh bGlzdDxicj4NCkNhcmRpZmYgVW5pdmVyc2l0eSAmYW1wOyBKQU5FVChVSyk8YnI+DQo8YnI+DQpl bWFpbDogPC9mb250PjxhIGhyZWY9bWFpbHRvOnNtaXRoQGNhcmRpZmYuYWMudWs+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsdWU+PHU+c21pdGhAY2FyZGlmZi5hYy51azwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9Mz4NCi8gPC9mb250PjxhIGhyZWY9bWFpbHRvOnJoeXMuc21pdGhAamEubmV0Pjxmb250 IHNpemU9MyBjb2xvcj1ibHVlPjx1PnJoeXMuc21pdGhAamEubmV0PC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zPjxicj4NCkdQRzogMHhERTJGMDI0QzwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K YWJmYWIgbWFpbGluZyBsaXN0PGJyPg0KYWJmYWJAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8 YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNl OiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDtt YWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1Jl Y2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5i c3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtu b3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29u dGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtv dGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNw O3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFs Jm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJz cDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0 eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5i c3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1h aWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5i c3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJz cDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJz cDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3Nl bmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQm bmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRF Jm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00054A5C4825793E_=-- From wei.yinxing@zte.com.cn Thu Nov 3 18:38:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59511E80DB for ; Thu, 3 Nov 2011 18:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.82 X-Spam-Level: X-Spam-Status: No, score=-95.82 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK53HrK32byg for ; Thu, 3 Nov 2011 18:38:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D811E8091 for ; Thu, 3 Nov 2011 18:38:24 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690967931198; Fri, 4 Nov 2011 09:28:42 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 58777.4129787514; Fri, 4 Nov 2011 09:37:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA41c0uP048358; Fri, 4 Nov 2011 09:38:00 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Fri, 4 Nov 2011 09:37:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-04 09:38:01, Serialize complete at 2011-11-04 09:38:01 Content-Type: multipart/alternative; boundary="=_alternative 0008F98B4825793E_=" X-MAIL: mse01.zte.com.cn pA41c0uP048358 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:38:26 -0000 This is a multipart message in MIME format. --=_alternative 0008F98B4825793E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFNhbQ0KDQogSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgdGV4dCAidGhhdCBjYW4gd2FpdCB1 bnRpbCBhIG1lY2hhbmlzbSBkaXNjdXNzaW9uIA0KaGFwcGVucyIgeW91IHdyb3RlLiBGb3IgbXkg ZXhwZXJpZW5jZSwgdXNlIGNhc2UgaXMgZGV2ZWxvcGVkIGF0IGZpcnN0IA0Kc3RhZ2UgYW5kIGl0 IGlzIGluZGVwZW5kZW50IG9mIG1lY2hhbmlzbXMuIEN1cnJlbnRseSwgdGhlIHVzZSBjYXNlIGRv IA0KZXhpc3QgYW5kIGNhbiBicmluZyBzb21lIGJlbmlmaXRzLg0KDQogTXkgc3VnZ2VzdGlvbiBp cyB0byBzZXBlcmF0ZSB0aGUgZGlzdXNzaW9ucyBiZXR3ZWVuIHRoZSB1c2UgY2FzZSBhbmQgDQpw b3RlbnRpYWwgc29sdXRpb25zLiBJZiBhIHVzZSBjYXNlIGlzIE9LLCB3ZSBjYW4gZG9jdW1lbnQg aXQgZmlyc3RseS4gSW4gDQp0aGUgc2Vjb25kIHN0YWdlIHdlIHRyeSB0byBmaW5kIHNvbHV0aW9u cyBvciBtZWNoYW5pc21zIGZvciB0aGF0IGNhc2UuIFdlIA0KbWF5IGV2YWx1YXRlIHNvbWUgY2Fu ZGlkYXRlZCBzb2x1dGlvbnMgYXQgdGhpcyBzdGFnZS4NCg0KLS0tLS0tLS0tLS0tDQpZaW54aW5n IFdlaQ0KDQoNCg0KDQpTYW0gSGFydG1hbiA8aGFydG1hbnNAcGFpbmxlc3Mtc2VjdXJpdHkuY29t PiANCjIwMTEvMTEvMDQgMDE6MzkNCg0KytW8/sjLDQp3ZWkueWlueGluZ0B6dGUuY29tLmNuDQqz rcvNDQpSaHlzIFNtaXRoIDxTbWl0aEBjYXJkaWZmLmFjLnVrPiwgYWJmYWJAaWV0Zi5vcmcsIGhh cnRtYW5zLWlldGZAbWl0LmVkdSwgDQprd2llcmVuZ0BjaXNjby5jb20NCtb3zOINClJlOiBbYWJm YWJdIFBsZWFzZSByZXZpZXcgdGhlIHVzZSBjYXNlICI0LnggRmVkZXJhdGVkIENyb3NzLUxheWVy ICBBY2Nlc3MiDQoNCg0KDQoNCg0KDQo+Pj4+PiAid2VpIiA9PSB3ZWkgeWlueGluZyA8d2VpLnlp bnhpbmdAenRlLmNvbS5jbj4gd3JpdGVzOg0KDQogICAgd2VpPiBIaSwgUmh5cw0KDQogICAgd2Vp PiAgICBJIGFncmVlIHdpdGggdGhlIHBvaW50IHRoYXQgY3JlZGVudGlhbCByZS11c2UgaXMgbW9y ZQ0KICAgIHdlaT4gYWNjdXJhdGUuIElmIHNvbWVvbmUgcHJlZmVycyB0byB1c2UgdGhlIHJlc3Vs dCBvZiBuZXR3b3JrDQogICAgd2VpPiBhY2Nlc3MgYXV0aGVudGljYXRpb24sIHRoZSB2aWV3IG9m IGNyZWRlbnRpYWwgcmUtdXNlIGlzIE9LLiBJZg0KICAgIHdlaT4gZG9lcyBub3QsIG9uZSBjYW4g Y2hvb3NlIHRvIGluaXRpYXRlIGFub3RoZXIgYXV0aGVudGljYXRpb24gZm9yDQogICAgd2VpPiBo aWdoZXIgc2VjdXJpdHksIGl0IGFsc28gd29ya3MuIEl0IE1BWSBkZXBlbmQgb24gbG9jYWwgcG9s aWN5Lg0KDQpPSy4NCkkgZXhwZWN0IHRoaXMgaXNzdWUgd2lsbCBwb3AgdXAgYWdhaW4gaWYgd2Ug Z28gYmV5b25kIHVzZS1jYXNlLCBidXQgSQ0KdGhpbmsgdGhhdCBjYW4gd2FpdCB1bnRpbCBhIG1l Y2hhbmlzbSBkaXNjdXNzaW9uIGhhcHBlbnMuDQoNCi0tU2FtDQoNCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0008F98B4825793E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBTYW08L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0kgZG8gbm90IHVuZGVy c3RhbmQgdGhlIHRleHQgJnF1b3Q7PC9mb250Pjxmb250IHNpemU9Mj48dHQ+dGhhdA0KY2FuIHdh aXQgdW50aWwgYSBtZWNoYW5pc20gZGlzY3Vzc2lvbiBoYXBwZW5zPC90dD48L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KeW91IHdyb3RlLiBGb3IgbXkgZXhwZXJp ZW5jZSwgdXNlIGNhc2UgaXMgZGV2ZWxvcGVkIGF0IGZpcnN0IHN0YWdlIGFuZA0KaXQgaXMgaW5k ZXBlbmRlbnQgb2YgbWVjaGFuaXNtcy4gQ3VycmVudGx5LCB0aGUgdXNlIGNhc2UgZG8gZXhpc3Qg YW5kIGNhbg0KYnJpbmcgc29tZSBiZW5pZml0cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO015IHN1Z2dlc3Rpb24gaXMgdG8gc2VwZXJhdGUg dGhlDQpkaXN1c3Npb25zIGJldHdlZW4gdGhlIHVzZSBjYXNlIGFuZCBwb3RlbnRpYWwgc29sdXRp b25zLiBJZiBhIHVzZSBjYXNlDQppcyBPSywgd2UgY2FuIGRvY3VtZW50IGl0IGZpcnN0bHkuIElu IHRoZSBzZWNvbmQgc3RhZ2Ugd2UgdHJ5IHRvIGZpbmQgc29sdXRpb25zDQpvciBtZWNoYW5pc21z IGZvciB0aGF0IGNhc2UuIFdlIG1heSBldmFsdWF0ZSBzb21lIGNhbmRpZGF0ZWQgc29sdXRpb25z DQphdCB0aGlzIHN0YWdlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+LS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5ZaW54aW5nIFdlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5TYW0gSGFydG1hbiAmbHQ7aGFydG1hbnNAcGFpbmxlc3Mt c2VjdXJpdHkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDExLzExLzA0IDAxOjM5PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPndlaS55aW54aW5nQHp0ZS5jb20uY248L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJoeXMgU21pdGggJmx0O1NtaXRoQGNhcmRpZmYuYWMudWsmZ3Q7LA0KYWJmYWJA aWV0Zi5vcmcsIGhhcnRtYW5zLWlldGZAbWl0LmVkdSwga3dpZXJlbmdAY2lzY28uY29tPC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5SZTogW2FiZmFiXSBQbGVhc2UgcmV2aWV3IHRoZSB1c2UgY2FzZQ0KJnF1 b3Q7NC54IEZlZGVyYXRlZCBDcm9zcy1MYXllciAmbmJzcDtBY2Nlc3MmcXVvdDs8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZxdW90O3dlaSZxdW90OyA9PSB3ZWkgeWlueGluZw0KJmx0O3dlaS55aW54 aW5nQHp0ZS5jb20uY24mZ3Q7IHdyaXRlczo8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwO3dlaSZn dDsgSGksIFJoeXM8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwO3dlaSZndDsgJm5ic3A7ICZuYnNw O0kgYWdyZWUgd2l0aCB0aGUgcG9pbnQgdGhhdCBjcmVkZW50aWFsDQpyZS11c2UgaXMgbW9yZTxi cj4NCiAmbmJzcDsgJm5ic3A7d2VpJmd0OyBhY2N1cmF0ZS4gSWYgc29tZW9uZSBwcmVmZXJzIHRv IHVzZSB0aGUgcmVzdWx0IG9mDQpuZXR3b3JrPGJyPg0KICZuYnNwOyAmbmJzcDt3ZWkmZ3Q7IGFj Y2VzcyBhdXRoZW50aWNhdGlvbiwgdGhlIHZpZXcgb2YgY3JlZGVudGlhbCByZS11c2UNCmlzIE9L LiBJZjxicj4NCiAmbmJzcDsgJm5ic3A7d2VpJmd0OyBkb2VzIG5vdCwgb25lIGNhbiBjaG9vc2Ug dG8gaW5pdGlhdGUgYW5vdGhlciBhdXRoZW50aWNhdGlvbg0KZm9yPGJyPg0KICZuYnNwOyAmbmJz cDt3ZWkmZ3Q7IGhpZ2hlciBzZWN1cml0eSwgaXQgYWxzbyB3b3Jrcy4gSXQgTUFZIGRlcGVuZCBv bg0KbG9jYWwgcG9saWN5Ljxicj4NCjxicj4NCk9LLjxicj4NCkkgZXhwZWN0IHRoaXMgaXNzdWUg d2lsbCBwb3AgdXAgYWdhaW4gaWYgd2UgZ28gYmV5b25kIHVzZS1jYXNlLCBidXQgSTxicj4NCnRo aW5rIHRoYXQgY2FuIHdhaXQgdW50aWwgYSBtZWNoYW5pc20gZGlzY3Vzc2lvbiBoYXBwZW5zLjxi cj4NCjxicj4NCi0tU2FtPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1Ro ZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMm bmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJz cDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtw ZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJz cDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpU aGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0 dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5k Jm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3Rv Jm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJz cDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtp biZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2lu YXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZu YnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJz cDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRo aXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3Im bmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50 aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0008F98B4825793E_=-- From hartmans@painless-security.com Thu Nov 3 19:23:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED2C11E80F0 for ; Thu, 3 Nov 2011 19:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olccc9HP2IBz for ; Thu, 3 Nov 2011 19:23:57 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7340D11E80B6 for ; Thu, 3 Nov 2011 19:23:57 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7203E202D8; Thu, 3 Nov 2011 22:24:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 74E7A435A; Thu, 3 Nov 2011 22:23:53 -0400 (EDT) From: Sam Hartman To: wei.yinxing@zte.com.cn References: Date: Thu, 03 Nov 2011 22:23:53 -0400 In-Reply-To: (wei yinxing's message of "Fri, 4 Nov 2011 09:37:40 +0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 02:23:58 -0000 >>>>> "wei" == wei yinxing writes: wei> My suggestion is to seperate the disussions between the use wei> case and potential solutions. that is what I was proposing. I have some concerns about one of the solutions you propose, but think discussing those concerns can wait until/if the working group considers such a mechanism. --Sam From wei.yinxing@zte.com.cn Thu Nov 3 20:57:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD7A11E809C; Thu, 3 Nov 2011 20:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.69 X-Spam-Level: X-Spam-Status: No, score=-95.69 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGrSHWmzF8Tk; Thu, 3 Nov 2011 20:57:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5E71F11E8096; Thu, 3 Nov 2011 20:57:39 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566902100040734; Fri, 4 Nov 2011 11:48:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 58777.2787061262; Fri, 4 Nov 2011 11:57:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pA43vHnp097579; Fri, 4 Nov 2011 11:57:18 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Rhys Smith MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Fri, 4 Nov 2011 11:56:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-04 11:57:19, Serialize complete at 2011-11-04 11:57:19 Content-Type: multipart/alternative; boundary="=_alternative 0015B8364825793E_=" X-MAIL: mse02.zte.com.cn pA43vHnp097579 Cc: abfab@ietf.org, abfab-bounces@ietf.org Subject: Re: [abfab] Soliciting use cases... X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 03:57:41 -0000 This is a multipart message in MIME format. --=_alternative 0015B8364825793E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJoeXMNCg0KICAgV2hlbiBJIGNoZWNrZWQgdGhlIHNpdGUgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9zdWJtaXQvLCBJIGZvdW5kIA0KbXkgdW5kZXJzdGFuZGluZyBpcyBpbmNvcnJl Y3QuIA0KDQogICBOb3cgZm9sbG93IHlvdXIgYWR2aWNlIQ0KIA0KICAgSSBhbSBzb3JyeSwgcGxl YXNlIGRpc2NhcmQgdGhlIHByZXZpb3VzIG1haWwhIA0KDQotLS0tLS0tLS0tLS0tDQpCZXN0IFJl Z2FyZHMhDQpZaW54aW5nIFdlaQ0KDQoNCg0Kd2VpLnlpbnhpbmdAenRlLmNvbS5jbiANCreivP7I yzogIGFiZmFiLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEvMTEvMDQgMDg6NTcNCg0KytW8/sjLDQpS aHlzIFNtaXRoIDxzbWl0aEBjYXJkaWZmLmFjLnVrPg0Ks63LzQ0KYWJmYWJAaWV0Zi5vcmcsIGFi ZmFiLWJvdW5jZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBbYWJmYWJdIFNvbGljaXRpbmcgdXNlIGNh c2VzLi4uDQoNCg0KDQoNCg0KDQoNCkhpLCBSaHlzIA0KDQogIEkgaGF2ZSBhIGxpdHRsZSBjb25m dXNpb24gYWJvdXQgdGhlIHN1Ym1pc3Npb24gZGF0ZSBvZiB0aGUgbmV3IHZlcnNpb24uIA0KRm9y IG15IGtub3dsZWRnZSBpbiBJRVRGLCBvbmUgY2FuIHN1Ym1pdCBhIGRyYWZ0IGF0IGFueSB0aW1l LiBPbmx5IGlmIG9uZSANCndhbnRzIHRvIHByZXNlbnQgYXQgdGhlIGZhY2UtdG8tZmFjZSBtZWV0 aW5nLCBvbmUgTVVTVCBzdWJtaXQgaXQgYmVmb3JlIA0KdGhlIGRlYWRsaW5lIG9mIHRoZSBzdWJt aXNzaW9uLiANCg0KIElmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgdG8gcG9zdCB0aGUg bmV3IHZlcnNpb24gd2lsbCBub3QgYmUgYW4gDQppc3N1ZSwgZm9yIHdlIGhhdmUgZ290IHJvdWdo IGNvbnNlbnN1cyBvbiB0aGlzIHVzZSBjYXNlLiBJZiBub3QsIGl0IGlzIA0KcmVhc29uYWJsZSB0 byBmb2xsb3cgeW91ciBhZHZpY2UuIA0KDQotLS0tLS0tLS0tLS0gDQpZaW54aW5nIFdlaSANCg0K ICANCg0KDQpSaHlzIFNtaXRoIDxzbWl0aEBjYXJkaWZmLmFjLnVrPiANCreivP7IyzogIGFiZmFi LWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDExLzExLzAzIDAzOjIxIA0KDQoNCsrVvP7Iyw0KYWJmYWJA aWV0Zi5vcmcgDQqzrcvNDQoNCtb3zOINClthYmZhYl0gU29saWNpdGluZyB1c2UgY2FzZXMuLi4N Cg0KDQoNCg0KDQoNCg0KDQpTbywgSSd2ZSBtYWRlIHNvbWUgbW9yZSB3b3JkaW5nIGNoYW5nZXMg dG8gdGlkeSB0aGUgZG9jIGFuZCBJJ3ZlIGFkZGVkIHRoZSANCkNyb3NzIExheWVyIEFjY2VzcyB1 c2UgY2FzZSwgYXMgZGlzY3Vzc2VkIGluIHRoZSBvdGhlciB0aHJlYWQuIE9idmlvdXNseSANCmNh bid0IHBvc3QgdGhlIG5ldyB2ZXJzaW9uIGFzIHN1Ym1pc3Npb24gaXMgY2xvc2VkIG5vdyB1bnRp bCBwb3N0IFRhaXBlaS4gDQoNCkZvciBub3cgdGhvdWdoLCBJJ20gc3RpbGwgbG9va2luZyBmb3Ig c29tZSB1c2UgY2FzZSB0ZXh0IG9uIGhvdyBhYmZhYiANCmNvdWxkIGhlbHAgdGhlIGZvbGxvd2lu ZyAodGhlc2UgaGF2ZSBiZWVuIG1lbnRpb25lZCBpbiB0aGUgcGFzdCk6IA0KKiBTSVAgDQoqIFBM QVNNQSANCiogVHJ1c3QgUm91dGVyIA0KKiBBbnl0aGluZyBlbHNlIHlvdSBjYW4gdGhpbmsgb2Yh IA0KDQpJZiBhbnlvbmUgZmFuY2llcyB3cml0aW5nIGEgZmV3IHBhcmFncmFwaHMgZm9yIGhvdyB0 aGV5IHRoaW5rIGFiZmFiIGNvdWxkIA0KaGVscCB0aGVzZSB0ZWNobm9sb2dpZXMsIG9yIGFueXRo aW5nIGVsc2UgeW91IGNhbiB0aGluayBvZiwgdGhvc2Ugd291bGQgYmUgDQpncmF0ZWZ1bGx5IHJl Y2VpdmVkIChJIGRvbid0IGtub3cgdGhlc2UgYXJlYXMgd2VsbCBlbm91Z2ggdG8gd3JpdGUgdGhl bSB1cCANCm15c2VsZikuIEknbSBoYXBweSB0byBhY2NlcHQgZXh0cmVtZWx5IGRyYWZ0IHRleHQg KG9uIG9yIG9mZi1saXN0KSBhbmQgDQp3b3JrIHdpdGggeW91IHRvIHRpZHkgaXQgdXAgYW5kIGZs ZXNoIGl0IG91dCwgaWYgeW91IGhhdmUgaWRlYXMgYnV0IG5vdCANCnRoZSB0aW1lIG9yIGluY2xp bmF0aW9uIHRvIHdyaXRlIHNvbWV0aGluZyBwcm9wZXJseS4uLiANCg0KS2luZCBSZWdhcmRzLCAN ClJoeXMuIA0KLS0NCkRyIFJoeXMgU21pdGg6IElkZW50aXR5LCBBY2Nlc3MsIGFuZCBNaWRkbGV3 YXJlIFNwZWNpYWxpc3QNCkNhcmRpZmYgVW5pdmVyc2l0eSAmIEpBTkVUKFVLKQ0KDQplbWFpbDog c21pdGhAY2FyZGlmZi5hYy51ayAvIHJoeXMuc21pdGhAamEubmV0DQpHUEc6IDB4REUyRjAyNEMg DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYWJmYWIg bWFpbGluZyBsaXN0DQphYmZhYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hYmZhYg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9u IGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFiZmFiIG1haWxpbmcgbGlzdA0K YWJmYWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWJm YWINCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 0015B8364825793E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSaHlzPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7V2hlbiBJ IGNoZWNrZWQgdGhlIHNpdGUNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0Lywg SSBmb3VuZCBteSB1bmRlcnN0YW5kaW5nIGlzIGluY29ycmVjdC4NCjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO05vdyBmb2xsb3cg eW91ciBhZHZpY2UhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7SSBhbSBzb3JyeSwgcGxlYXNlIGRpc2NhcmQNCnRoZSBwcmV2aW91cyBtYWls ISA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0t LS0tLS0tLS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3Qg UmVnYXJkcyE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllpbnhp bmcgV2VpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjxiPndlaS55aW54aW5nQHp0ZS5jb20uY248L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7YWJmYWItYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLzExLzA0IDA4OjU3 PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJoeXMgU21pdGggJmx0O3NtaXRoQGNhcmRpZmYuYWMudWsmZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5hYmZhYkBpZXRmLm9yZywgYWJmYWItYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6IFthYmZhYl0gU29saWNpdGluZyB1c2UgY2FzZXMuLi48L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KSGksIFJoeXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDtJIGhhdmUg YSBsaXR0bGUgY29uZnVzaW9uIGFib3V0IHRoZSBzdWJtaXNzaW9uIGRhdGUgb2YgdGhlIG5ldyB2 ZXJzaW9uLg0KRm9yIG15IGtub3dsZWRnZSBpbiBJRVRGLCBvbmUgY2FuIHN1Ym1pdCBhIGRyYWZ0 IGF0IGFueSB0aW1lLiBPbmx5IGlmIG9uZQ0Kd2FudHMgdG8gcHJlc2VudCBhdCB0aGUgZmFjZS10 by1mYWNlIG1lZXRpbmcsIG9uZSBNVVNUIHN1Ym1pdCBpdCBiZWZvcmUNCnRoZSBkZWFkbGluZSBv ZiB0aGUgc3VibWlzc2lvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiBJZiBteSB1 bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIHRvIHBvc3QgdGhlIG5ldyB2ZXJzaW9uIHdpbGwgbm90 IGJlIGFuDQppc3N1ZSwgZm9yIHdlIGhhdmUgZ290IHJvdWdoIGNvbnNlbnN1cyBvbiB0aGlzIHVz ZSBjYXNlLiBJZiBub3QsIGl0IGlzDQpyZWFzb25hYmxlIHRvIGZvbGxvdyB5b3VyIGFkdmljZS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQotLS0tLS0tLS0tLS08L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCllpbnhpbmcgV2VpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQog PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8YnI+DQo8YnI+DQo8 L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUw JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Umh5cyBTbWl0aCAmbHQ7c21pdGhA Y2FyZGlmZi5hYy51ayZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwO2FiZmFiLWJvdW5jZXNA aWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEvMTEvMDMgMDM6MjE8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTQ5JT4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTUl Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg0JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+YWJmYWJAaWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5bYWJmYWJdIFNvbGljaXRpbmcgdXNlIGNhc2VzLi4uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4N Cjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQpTbywgSSd2ZSBtYWRlIHNvbWUgbW9y ZSB3b3JkaW5nIGNoYW5nZXMgdG8gdGlkeSB0aGUgZG9jIGFuZCBJJ3ZlIGFkZGVkDQp0aGUgQ3Jv c3MgTGF5ZXIgQWNjZXNzIHVzZSBjYXNlLCBhcyBkaXNjdXNzZWQgaW4gdGhlIG90aGVyIHRocmVh ZC4gT2J2aW91c2x5DQpjYW4ndCBwb3N0IHRoZSBuZXcgdmVyc2lvbiBhcyBzdWJtaXNzaW9uIGlz IGNsb3NlZCBub3cgdW50aWwgcG9zdCBUYWlwZWkuDQo8YnI+DQo8YnI+DQpGb3Igbm93IHRob3Vn aCwgSSdtIHN0aWxsIGxvb2tpbmcgZm9yIHNvbWUgdXNlIGNhc2UgdGV4dCBvbiBob3cgYWJmYWIg Y291bGQNCmhlbHAgdGhlIGZvbGxvd2luZyAodGhlc2UgaGF2ZSBiZWVuIG1lbnRpb25lZCBpbiB0 aGUgcGFzdCk6IDxicj4NCiogU0lQIDxicj4NCiogUExBU01BIDxicj4NCiogVHJ1c3QgUm91dGVy IDxicj4NCiogQW55dGhpbmcgZWxzZSB5b3UgY2FuIHRoaW5rIG9mISA8YnI+DQo8YnI+DQpJZiBh bnlvbmUgZmFuY2llcyB3cml0aW5nIGEgZmV3IHBhcmFncmFwaHMgZm9yIGhvdyB0aGV5IHRoaW5r IGFiZmFiIGNvdWxkDQpoZWxwIHRoZXNlIHRlY2hub2xvZ2llcywgb3IgYW55dGhpbmcgZWxzZSB5 b3UgY2FuIHRoaW5rIG9mLCB0aG9zZSB3b3VsZA0KYmUgZ3JhdGVmdWxseSByZWNlaXZlZCAoSSBk b24ndCBrbm93IHRoZXNlIGFyZWFzIHdlbGwgZW5vdWdoIHRvIHdyaXRlIHRoZW0NCnVwIG15c2Vs ZikuIEknbSBoYXBweSB0byBhY2NlcHQgZXh0cmVtZWx5IGRyYWZ0IHRleHQgKG9uIG9yIG9mZi1s aXN0KSBhbmQNCndvcmsgd2l0aCB5b3UgdG8gdGlkeSBpdCB1cCBhbmQgZmxlc2ggaXQgb3V0LCBp ZiB5b3UgaGF2ZSBpZGVhcyBidXQgbm90DQp0aGUgdGltZSBvciBpbmNsaW5hdGlvbiB0byB3cml0 ZSBzb21ldGhpbmcgcHJvcGVybHkuLi4gPGJyPg0KPGJyPg0KS2luZCBSZWdhcmRzLCA8YnI+DQpS aHlzLiA8YnI+DQotLTxicj4NCkRyIFJoeXMgU21pdGg6IElkZW50aXR5LCBBY2Nlc3MsIGFuZCBN aWRkbGV3YXJlIFNwZWNpYWxpc3Q8YnI+DQpDYXJkaWZmIFVuaXZlcnNpdHkgJmFtcDsgSkFORVQo VUspPGJyPg0KPGJyPg0KZW1haWw6IDwvZm9udD48YSBocmVmPW1haWx0bzpzbWl0aEBjYXJkaWZm LmFjLnVrPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnNtaXRo QGNhcmRpZmYuYWMudWs8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQovIDwvZm9udD48YSBocmVmPW1haWx0bzpyaHlzLnNtaXRoQGphLm5ldD48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yaHlzLnNtaXRoQGphLm5ldDwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpHUEc6IDB4REUy RjAyNEMgPC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQphYmZhYiBtYWlsaW5nIGxpc3Q8YnI+DQph YmZhYkBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWJmYWI8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJy Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMg bWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3Ro ZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhh cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0 ZW0uPGJyPg0KPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFiZmFiIG1haWxpbmcgbGlzdDxicj4N CmFiZmFiQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hYmZhYjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5m b3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1h dGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZu YnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZu YnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24m bmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJz cDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJz cDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7 dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlz Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWls Jm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgm bmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVk Jm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJz cDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2 ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZu YnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZu YnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZu YnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5 c3RlbS4NCjwvcHJlPg== --=_alternative 0015B8364825793E_=-- From gabilm@um.es Fri Nov 4 01:24:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8483B21F8BEC for ; Fri, 4 Nov 2011 01:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucWqean5HoR7 for ; Fri, 4 Nov 2011 01:24:36 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id DC75821F8BEB for ; Fri, 4 Nov 2011 01:24:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 7C1424C216; Fri, 4 Nov 2011 09:24:34 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pyyUjgA27GEo; Fri, 4 Nov 2011 09:24:34 +0100 (CET) Received: from eduroam_um-231-128.inf.um.es (eduroam_um-231-128.inf.um.es [155.54.231.128]) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPA id 889D34C237; Fri, 4 Nov 2011 09:24:30 +0100 (CET) Message-ID: <4EB3A1B8.6030602@um.es> Date: Fri, 04 Nov 2011 09:26:32 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Cantor, Scott" References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:24:36 -0000 El 03/11/11 15:30, Cantor, Scott escribió: > On 11/3/11 9:19 AM, "Gabriel López" wrote: >> yes, I was thinking in the size of the SAML assertion and the limit of >> 4096 bytes commented by Alejandro in the last email. The XMLSignature >> would increase considerably the message size. > The only dramatic size increase comes from putting the certificate in the > message. If you don't do that (as in, you don't use PKIX), then it isn't > really that large. > >>> This makes sense (kind of like Kerberos constrained delegation where the >>> authorisation data is signed). But it could be optional? >> not sure about that > Not optional in the sense that it would be used as if it were signed, just > optional meaning not all assertions would have that capability. As in fact > they wouldn't. You can't just sign the assertion and magically treat it as > a reusable token. Well, you can, but those people are ignoring the > standard. Other content is also needed or you have a very lax model. Well, I'm thinking about the Federated Cross-Layer Access use case. Network access authentication could provide RADIUS server with a SAML assertion, then application service could obtain this assertion (directly from the AAA server or through the end user) and take an access control decision based on that. Protecting the SAML assertion in a correct way would not derive in a lax model. Of course, I agree, it doesn't follow any current SAML specification. Anyway, this topic will require a new thread. Thanks Scott for you comments. > > -- Scott > -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From gabilm@um.es Fri Nov 4 01:46:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4611721F8B24 for ; Fri, 4 Nov 2011 01:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXLYdCu2U9xs for ; Fri, 4 Nov 2011 01:46:39 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8D721F8B1E for ; Fri, 4 Nov 2011 01:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id C64C15D4D8; Fri, 4 Nov 2011 09:46:37 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lSoOfo5LBaxn; Fri, 4 Nov 2011 09:46:37 +0100 (CET) Received: from eduroam_um-231-128.inf.um.es (eduroam_um-231-128.inf.um.es [155.54.231.128]) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPA id 30D2F5D590; Fri, 4 Nov 2011 09:46:34 +0100 (CET) Message-ID: <4EB3A6E5.6090900@um.es> Date: Fri, 04 Nov 2011 09:48:37 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rhys Smith References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: multipart/alternative; boundary="------------050808060703050607000904" Cc: abfab@ietf.org Subject: Re: [abfab] Soliciting use cases... X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:46:40 -0000 This is a multi-part message in MIME format. --------------050808060703050607000904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, El 02/11/11 20:21, Rhys Smith escribió: > So, I've made some more wording changes to tidy the doc and I've added the Cross Layer Access use case, as discussed in the other thread. Obviously can't post the new version as submission is closed now until post Taipei. > > For now though, I'm still looking for some use case text on how abfab could help the following (these have been mentioned in the past): > * SIP I remember some emails in July about the VoIP/SIP use case and it was not clear whether it would be covered by abfab or not. I'm opinion the SIP use case could be of interest in the sense that users can initiate sessions (generally speaking, not only VoIP sessions) in remote/visited organizations. SIP requests (register,invite,etc) could be delivered directly to the home proxies, but afaik those are usually filtered by firewalls. Abfab architecture could be used by SIP proxies (remote/home) and UA to delegate the authentication/authorization process to the AAA infrastructure. If you consider this use case is of interest for abfab I could write some text for the draft. Regards, Gabi. > * PLASMA > * Trust Router > * Anything else you can think of! > > If anyone fancies writing a few paragraphs for how they think abfab could help these technologies, or anything else you can think of, those would be gratefully received (I don't know these areas well enough to write them up myself). I'm happy to accept extremely draft text (on or off-list) and work with you to tidy it up and flesh it out, if you have ideas but not the time or inclination to write something properly... > > Kind Regards, > Rhys. > -- > Dr Rhys Smith: Identity, Access, and Middleware Specialist > Cardiff University & JANET(UK) > > email: smith@cardiff.ac.uk / rhys.smith@ja.net > GPG: 0xDE2F024C > > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L?pez Mill?n Departamento de Ingenier?a de la Informaci?n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --------------050808060703050607000904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

El 02/11/11 20:21, Rhys Smith escribió: 
So, I've made some more wording changes to tidy the doc and I've added the Cross Layer Access use case, as discussed in the other thread. Obviously can't post the new version as submission is closed now until post Taipei.

For now though, I'm still looking for some use case text on how abfab could help the following (these have been mentioned in the past):
* SIP

I remember some emails in July about the VoIP/SIP use case and it was not clear whether it would be covered by abfab or not.
I'm opinion the SIP use case could be of interest in the sense that users can initiate sessions (generally speaking, not only VoIP sessions) in remote/visited organizations. SIP requests (register,invite,etc) could be delivered directly to the home proxies, but afaik those are usually filtered by firewalls.
Abfab architecture could be used by SIP proxies (remote/home) and UA to delegate the authentication/authorization process to the AAA infrastructure.
If you consider this use case is of interest for abfab I could write some text for the draft.

Regards, Gabi.  

* PLASMA
* Trust Router
* Anything else you can think of!

If anyone fancies writing a few paragraphs for how they think abfab could help these technologies, or anything else you can think of, those would be gratefully received (I don't know these areas well enough to write them up myself). I'm happy to accept extremely draft text (on or off-list) and work with you to tidy it up and flesh it out, if you have ideas but not the time or inclination to write something properly...

Kind Regards,
Rhys.
--
Dr Rhys Smith: Identity, Access, and Middleware Specialist
Cardiff University & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: 0xDE2F024C





_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab



-- 
----------------------------------------------------------------
Gabriel L—pez Mill‡n
Departamento de Ingenier’a de la Informaci—n y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gabilm@um.es
--------------050808060703050607000904-- From alex@um.es Fri Nov 4 01:57:09 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2964721F8BE5 for ; Fri, 4 Nov 2011 01:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn6tdtt5-uUB for ; Fri, 4 Nov 2011 01:57:08 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 341CD21F8BE7 for ; Fri, 4 Nov 2011 01:57:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id ABBDC5D59D for ; Fri, 4 Nov 2011 09:57:04 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K-wB58NH2alf for ; Fri, 4 Nov 2011 09:57:04 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id B497A5D5A1 for ; Fri, 4 Nov 2011 09:57:00 +0100 (CET) Message-ID: <4EB3A8DC.5000609@um.es> Date: Fri, 04 Nov 2011 09:57:00 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:57:09 -0000 > > 2) As has been pointed out the 4096 limit is on RADIUS messages *not* on > SAML assertions. Also, it's not a limit: it is a minimum size > implementations must handle. So, I think a better way of phrasing this > is that if your SAML assertion makes a RADIUS PDE greater than 4k it > very likely will not be carried in its entirety. The text from RFC 2865 says, regarding the Length field o a RADIUS message, the following: The minimum length is 20 and maximum length is 4096 Hence, IMHO it is a limit. > 4) I prefer attribute query as a way to get larger/more attributes over > URL references or artifacts. I agree, but if attribute queries are performed using SOAP (for example), you would need to rely in certificate-based trust, and AAA-based trust would not be enough, right? > > 5) We need more discussion on the size issue. > I'll note several things. > > First: the protocol may be useful even if it does have limitations. If > it happens that most of the things people want to do with it are > possible, but some are not, it may have sufficient utilitiy. Compression > increases the utility. It doesn't help if you want a 10k photo with > FreeRADIUS, but it does help if you're close to the boundary. Right. Actually, we are using compression in our prototype. > So, I > don't view it as a valid objection that is a size limit or that some use > cases are precluded by the size limit. I do view it as an objection > that the size limit does not permit enough use cases. I don't know > whether that's true. However my personal opinion is that I don't agree > with a message complaining about a size limit unless it explains both > things that are prohibited and makes an argument about why prohibiting > those things is a bad tradeoff. Maybe I did not explain myself well. I was not postulating myself against the use of RADIUS, or complaining about it. On the contrary, I was just raising an issue we found in our prototype, in the aim to find out a consensual solution for the specific (and probably infrequent) cases where the size limit may appear. Of course, one can use Diameter instead. But I would like to have a solution for RADIUS. > Second: We can explore whether it's operationally viable to raise the > limit. I'm a little dubious about this. The RADIUS world seems to have > hard-coded the 4k limit in servers and proxies. That is not how I would > have done things. I'm told it's a simple constant that can be increased > and rebuilt in several popular implementations. > I am skeptical of the viability of doing that or how well it works if > you do. Still we should consider. I think they did that way because that limit is specified in the RADIUS spec. I would guess that, as you say, it will be a simple constant easily increseable for the servers you control. But it would be needed to rebuild all the RADIUS servers that take part in the federation, so they do not strip messages when acting as proxies. Anyway, increasing that number would be against RADIUS specification, if I did not understand it wrong. Best regards, Alejandro > > However I do believe the length limitation is the big thing to consider > for saml-aaa. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Fri Nov 4 02:29:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D65521F8C36 for ; Fri, 4 Nov 2011 02:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr4gNa92kZ17 for ; Fri, 4 Nov 2011 02:29:48 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6C821F8C04 for ; Fri, 4 Nov 2011 02:29:34 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E75F94A6B65_EB3B07AB; Fri, 4 Nov 2011 09:29:30 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id C4ADB4A6B62_EB3B07AF; Fri, 4 Nov 2011 09:29:30 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 09:29:30 +0000 From: Josh Howlett To: Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYA= Date: Fri, 4 Nov 2011 09:29:29 +0000 Message-ID: In-Reply-To: <4EB3A8DC.5000609@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:29:48 -0000 > >Of course, one can use Diameter >instead. But I would like to have a solution for RADIUS. Could I ask why? I am satisfied that 4k is plenty for the use-cases that I see today. Adding support for more will incur significant complexity, which feels disproportionate for a corner-case. If people have such a corner case, they can use Diameter. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From aland@deployingradius.com Fri Nov 4 02:44:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F17121F8BE5; Fri, 4 Nov 2011 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYAzPgfs2AWm; Fri, 4 Nov 2011 02:44:13 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8568C21F8C15; Fri, 4 Nov 2011 02:44:10 -0700 (PDT) Message-ID: <4EB3B3CD.1020009@deployingradius.com> Date: Fri, 04 Nov 2011 10:43:41 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , <4EB0F497.1000104@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , radext@ietf.org Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:44:14 -0000 Bernard Aboba wrote: > [BA] Given that the spec would create an incompatible variant of RADIUS, > I'd say that the situation is pretty serious, and that a document clarifying > the encoding of the NAI within RADIUS is critical. OK. Can we get support for this position on the various mailing lists? I suspect the abfab people want to work within the existing RADIUS framework. The main difficulty is that the only NAI specification is 4282. If abfab has a normative dependency on an NAI spec, then publishing 4282bis quickly is a good idea. The draft describes existing practices, and has no new recommendations in it. So it *should* be non-controversial. Alan DeKok. From gabilm@um.es Fri Nov 4 03:00:16 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C5B21F8C33 for ; Fri, 4 Nov 2011 03:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u6F4fc2BKS1 for ; Fri, 4 Nov 2011 03:00:15 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0987121F8C1E for ; Fri, 4 Nov 2011 03:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id B74A94C24E; Fri, 4 Nov 2011 11:00:12 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FxcIcccRdl4m; Fri, 4 Nov 2011 11:00:11 +0100 (CET) Received: from eduroam_um-231-128.inf.um.es (eduroam_um-231-128.inf.um.es [155.54.231.128]) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPA id A55384C227; Fri, 4 Nov 2011 11:00:05 +0100 (CET) Message-ID: <4EB3B81F.4020001@um.es> Date: Fri, 04 Nov 2011 11:02:07 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 10:00:16 -0000 El 04/11/11 10:29, Josh Howlett escribió: >> Of course, one can use Diameter >> instead. But I would like to have a solution for RADIUS. > Could I ask why? I am satisfied that 4k is plenty for the use-cases that I > see today. Well, current implementation is over RADIUS and if you have to transport SAML assertion including XML Signature (+X.509PKC) (even if parties do ignore it) you can have problems even with small size attributes. If you can life with SAML assertion including XML Signature (without X.509PKC) then it is ok. Also, if you plan to implement this in a real deployment... well, Diameter may not be fully used yet :) regards, Gabi. > Adding support for more will incur significant complexity, > which feels disproportionate for a corner-case. If people have such a > corner case, they can use Diameter. > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de Ingenier’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From Josh.Howlett@ja.net Fri Nov 4 03:02:49 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DA421F8BF6; Fri, 4 Nov 2011 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlbwcyY7v3DW; Fri, 4 Nov 2011 03:02:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id B873321F8B84; Fri, 4 Nov 2011 03:02:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 585801A9BDFD_EB3B847B; Fri, 4 Nov 2011 10:02:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 392CC1A9BB12_EB3B847F; Fri, 4 Nov 2011 10:02:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 10:02:46 +0000 From: Josh Howlett To: Alan DeKok , Bernard Aboba Thread-Topic: [abfab] [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) Thread-Index: AQHMmtjnIo886vb7uEWZ4qYbvdPxrg== Date: Fri, 4 Nov 2011 10:02:46 +0000 Message-ID: In-Reply-To: <4EB3B3CD.1020009@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 10:02:49 -0000 > I suspect the abfab people want to work within the existing RADIUS >framework. The main difficulty is that the only NAI specification is >4282. If abfab has a normative dependency on an NAI spec, then >publishing 4282bis quickly is a good idea. I think the alternative would be to define something abfab-specific, which would be non-optimal for the reasons given. I would prefer to use 4282bis. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Nov 4 03:10:38 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AA321F8C33 for ; Fri, 4 Nov 2011 03:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bQrPUKverME for ; Fri, 4 Nov 2011 03:10:37 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id EB4B121F8B90 for ; Fri, 4 Nov 2011 03:10:36 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 1884C1A9BE37_EB3BA07B; Fri, 4 Nov 2011 10:10:15 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id E796C1A9BE1B_EB3BA06F; Fri, 4 Nov 2011 10:10:14 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 10:10:14 +0000 From: Josh Howlett To: =?iso-8859-1?Q?Gabriel_L=F3pez?= Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYCAAAkggIAAAj+A Date: Fri, 4 Nov 2011 10:10:13 +0000 Message-ID: In-Reply-To: <4EB3B81F.4020001@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 10:10:38 -0000 >Well, current implementation is over RADIUS and if you have to transport >SAML assertion including XML Signature (+X.509PKC) (even if parties do >ignore it) you can have problems even with small size attributes. If you >can life with SAML assertion including XML Signature (without X.509PKC) >then it is ok. My assumption is that the SAML responder does not include a signature; the transport can provide the needed assurances. Deployments that require signatures should use Diameter. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From gabilm@um.es Fri Nov 4 03:29:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F28B21F8C32 for ; Fri, 4 Nov 2011 03:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF6bs2wkAYL6 for ; Fri, 4 Nov 2011 03:29:36 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id D99FB21F8C17 for ; Fri, 4 Nov 2011 03:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id B9E414C23E; Fri, 4 Nov 2011 11:29:33 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GL6tbWaWnrqH; Fri, 4 Nov 2011 11:29:33 +0100 (CET) Received: from eduroam_um-231-128.inf.um.es (eduroam_um-231-128.inf.um.es [155.54.231.128]) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPA id D32284C245; Fri, 4 Nov 2011 11:29:28 +0100 (CET) Message-ID: <4EB3BF02.6020808@um.es> Date: Fri, 04 Nov 2011 11:31:30 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 10:29:36 -0000 El 04/11/11 11:10, Josh Howlett escribió: >> Well, current implementation is over RADIUS and if you have to transport >> SAML assertion including XML Signature (+X.509PKC) (even if parties do >> ignore it) you can have problems even with small size attributes. If you >> can life with SAML assertion including XML Signature (without X.509PKC) >> then it is ok. > My assumption is that the SAML responder does not include a signature; the > transport can provide the needed assurances. Deployments that require > signatures should use Diameter. Then I think the draft document should comment something like: "SAML assertion ¿should/must? not be signed if AAA transport is RADIUS, otherwise it could" It is not clear for me, but if you are ok ... regards, Gabi. > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de Ingenier’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From hartmans@painless-security.com Fri Nov 4 05:58:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA62E21F8B6C; Fri, 4 Nov 2011 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDUXs3lnmlN0; Fri, 4 Nov 2011 05:58:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 017F721F8B6B; Fri, 4 Nov 2011 05:58:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6B86D2009E; Fri, 4 Nov 2011 08:58:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 28B4F435A; Fri, 4 Nov 2011 08:57:57 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> Date: Fri, 04 Nov 2011 08:57:57 -0400 In-Reply-To: <4EB3B3CD.1020009@deployingradius.com> (Alan DeKok's message of "Fri, 04 Nov 2011 10:43:41 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba , radext@ietf.org, "abfab@ietf.org" Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 12:58:14 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Bernard Aboba wrote: >> [BA] Given that the spec would create an incompatible variant of >> RADIUS, I'd say that the situation is pretty serious, and that a >> document clarifying the encoding of the NAI within RADIUS is >> critical. Alan> OK. Can we get support for this position on the various Alan> mailing lists? Alan> I suspect the abfab people want to work within the existing Alan> RADIUS framework. The main difficulty is that the only NAI Alan> specification is 4282. If abfab has a normative dependency on Alan> an NAI spec, then publishing 4282bis quickly is a good idea. 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap. Alan> The draft describes existing practices, and has no new Alan> recommendations in it. So it *should* be non-controversial. Uh. Good luck with that. I'd definitely want to understand the internationalization story before supporting a new NAI spec. I understand your concerns with 4282. I suspect others will feel similarly. So, even if we all end up agreeing with you in the end, I'd expect it to be a careful process--definitely far beyond what I hope it takes to get draft-ietf-abfab-gss-eap approved. Now, at least for ABFAB implementations, I don't think it's a big deal. I think we can leave all the processing up to the final AAA server. I think i18n is a topic we really need to discuss for ABFAB in IETF 82. From aland@deployingradius.com Fri Nov 4 06:40:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D9C21F8BEC; Fri, 4 Nov 2011 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1yssSJk9MgE; Fri, 4 Nov 2011 06:40:17 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7C21F8BC5; Fri, 4 Nov 2011 06:40:16 -0700 (PDT) Message-ID: <4EB3EB21.6090800@deployingradius.com> Date: Fri, 04 Nov 2011 14:39:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , radext@ietf.org, "abfab@ietf.org" Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 13:40:17 -0000 Sam Hartman wrote: > 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap. That's a problem. As Bernard said, 4282 mandates behavior which *no one* implements. Anyone implementing 4282 will be incompatible with all known RADIUS systems. I think the goal of abfab is to be interoperable with existing RADIUS roaming systems. > I'd definitely want to understand the internationalization story before > supporting a new NAI spec. Short story: AAA systems shouldn't mangle the NAI. 4282 demands NAI mangling, which is bad. > I suspect others will feel similarly. So, even if we all end up > agreeing with you in the end, I'd expect it to be a careful > process--definitely far beyond what I hope it takes to get > draft-ietf-abfab-gss-eap approved. Then we have a problem. The draft conflicts with real-world practice. > Now, at least for ABFAB implementations, I don't think it's a big > deal. I think we can leave all the processing up to the final AAA > server. That's pretty much what is said by 4282bis. > I think i18n is a topic we really need to discuss for ABFAB in IETF 82. And interoperability with RADIUS. Alan DeKok. From cantor.2@osu.edu Fri Nov 4 07:09:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C23B21F8C58 for ; Fri, 4 Nov 2011 07:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eS3g3+dAANG for ; Fri, 4 Nov 2011 07:09:35 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 578DA21F8C57 for ; Fri, 4 Nov 2011 07:09:32 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA4E9QP0024539; Fri, 4 Nov 2011 10:09:30 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi; Fri, 4 Nov 2011 10:07:56 -0400 From: "Cantor, Scott" To: Josh Howlett , Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoCAAEYpAIAAAzGAgAAFcoD//8JAAAAMh2gAAB9iaAAAASJtgAABTmKA Date: Fri, 4 Nov 2011 14:06:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <5f6dcd4f-8703-4253-8959-238651b1a131> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:09:36 -0000 On 11/4/11 5:29 AM, "Josh Howlett" wrote: > >Could I ask why? I am satisfied that 4k is plenty for the use-cases that I >see today. Adding support for more will incur significant complexity, >which feels disproportionate for a corner-case. If people have such a >corner case, they can use Diameter. I'm still doing some research on this (I need to mock up some assertions using my data and extensions), but my intuition is that I can definitely not get behind anything with a limit that low. -- Scott From cantor.2@osu.edu Fri Nov 4 07:30:00 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449A221F8C54 for ; Fri, 4 Nov 2011 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmDGtwvEk5Lh for ; Fri, 4 Nov 2011 07:29:59 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAA921F8C53 for ; Fri, 4 Nov 2011 07:29:59 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA4ETqok003901; Fri, 4 Nov 2011 10:29:58 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Fri, 4 Nov 2011 10:29:14 -0400 From: "Cantor, Scott" To: "Cantor, Scott" , Josh Howlett , Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoCAAEYpAIAAAzGAgAAFcoD//8JAAAAMh2gAAB9iaAAAASJtgAABTmKAAADHYIA= Date: Fri, 4 Nov 2011 14:29:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:30:00 -0000 On 11/4/11 10:06 AM, "Cantor, Scott" wrote: >On 11/4/11 5:29 AM, "Josh Howlett" wrote: >> >>Could I ask why? I am satisfied that 4k is plenty for the use-cases that >>I >>see today. Adding support for more will incur significant complexity, >>which feels disproportionate for a corner-case. If people have such a >>corner case, they can use Diameter. > >I'm still doing some research on this (I need to mock up some assertions >using my data and extensions), but my intuition is that I can definitely >not get behind anything with a limit that low. I feel like I should explain that a bit more directly: While most of the >4K use cases I have now are not federated (its usually enrollment data that gets it above the line), my experience is that having two infrastructures (one for intra-, one for inter-) is bad. I also believe support for SAML based delegation is important to gradually move people away from building "client of web service is root" models to get around having decent delegation support. That adds size (as well as signature). I believe it's short shrift to focus on passing small numbers of attributes around, because if you think that's all there is, then that means attributes aren't getting used widely, which means federation's not going anywhere anyway. Authentication alone is not a motivator for the effort involved. Attributes are all that will drive it. I'm of course fine with DIAMETER if people are deploying it, or will be within the next 5 years or so. One question on that=8Awith the intent to move to a model where you connect directly from the acceptor's AAA server to the home server via TLS, does that mean only the two endpoints would need DIAMETER anyway? That's a reasonable compromise. -- Scott From Josh.Howlett@ja.net Fri Nov 4 09:10:55 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1970C21F8B17 for ; Fri, 4 Nov 2011 09:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LN2IxNCo-+p for ; Fri, 4 Nov 2011 09:10:54 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id CD25921F8CA2 for ; Fri, 4 Nov 2011 09:10:53 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9E5004A6B6F_EB40E7CB; Fri, 4 Nov 2011 16:10:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id E67834A6B6B_EB40E7BF; Fri, 4 Nov 2011 16:10:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 16:10:35 +0000 From: Josh Howlett To: "Cantor, Scott" , Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYCAAE2DgIAABjuAgAAcUgA= Date: Fri, 4 Nov 2011 16:10:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset=UTF-8 Content-ID: <85129432CD1A2D42B1081FBFD6809D87@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:10:55 -0000 >>> >>>Could I ask why? I am satisfied that 4k is plenty for the use-cases that >>>I >>>see today. Adding support for more will incur significant complexity, >>>which feels disproportionate for a corner-case. If people have such a >>>corner case, they can use Diameter. >> >>I'm still doing some research on this (I need to mock up some assertions >>using my data and extensions), but my intuition is that I can definitely >>not get behind anything with a limit that low. > >I feel like I should explain that a bit more directly: > >While most of the >4K use cases I have now are not federated (its usually >enrollment data that gets it above the line), my experience is that having >two infrastructures (one for intra-, one for inter-) is bad. > >I also believe support for SAML based delegation is important to gradually >move people away from building "client of web service is root" models to >get around having decent delegation support. That adds size (as well as >signature). Yes, I'm certainly sympathetic to that argument. I agree that for inter-domain delegation, we will need support for this. In that case, Diameter is your friend. However, for intra-domain delegation, I think there's plenty of mileage in using Kerberos delegation semantics (with an unsigned SAML assertion in the PAC) rather than SAML delegation semantics. In this case, we can use RADIUS. >I believe it's short shrift to focus on passing small numbers of >attributes around, because if you think that's all there is, then that >means attributes aren't getting used widely, which means federation's not >going anywhere anyway. Authentication alone is not a motivator for the >effort involved. Attributes are all that will drive it. Agreed. We should certainly provide a mechanism that supports arbitrarily sized payloads for the reasons you state. However, if a reasonable proportion of use cases can be solved with a simple (if not necessarily comprehensive) RADIUS-based mechanism, we should do that rather than reinvent Diameter. >I'm of course fine with DIAMETER if people are deploying it, or will be >within the next 5 years or so. That's the $64K question. My view is that we should take a pragmatic approach, and provide a simple option that is readily deployable today and which addresses many -- if not all -- use cases, and provide an alternative mechanism to satisfy those other use cases. > One question on that=C5=A0with the intent to >move to a model where you connect directly from the acceptor's AAA server >to the home server via TLS, does that mean only the two endpoints would >need DIAMETER anyway? That's a reasonable compromise. That's certainly a possible deployment option although I believe that even in a Diameter-based deployment, there may be a role for proxies and other active intermediaries. However, I think I may have misunderstood the thrust of your question...? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From cantor.2@osu.edu Fri Nov 4 09:39:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0718521F8BE7 for ; Fri, 4 Nov 2011 09:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVFTQto8FphO for ; Fri, 4 Nov 2011 09:39:49 -0700 (PDT) Received: from defang18.it.ohio-state.edu (defang18.it.ohio-state.edu [128.146.216.132]) by ietfa.amsl.com (Postfix) with ESMTP id DE02A21F8BD7 for ; Fri, 4 Nov 2011 09:39:44 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang18.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pA4GcrHw026598; Fri, 4 Nov 2011 12:39:42 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Fri, 4 Nov 2011 12:36:55 -0400 From: "Cantor, Scott" To: Josh Howlett , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCbyBP4YveuIXk2urodCPZdCu5WbJBANgABFDQD//9DJgIAASN8A//+/DoCAAEYpAIAAAzGAgAAFcoD//8JAAAAMh2gAAB9iaAAAASJtgAABTmKAAADHYIAAC+w1AP//xE0A Date: Fri, 4 Nov 2011 16:36:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <5aa6f4d9-f026-4d64-9e35-a12a1da3262a> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.132 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:39:50 -0000 On 11/4/11 12:10 PM, "Josh Howlett" wrote: > >That's certainly a possible deployment option although I believe that even >in a Diameter-based deployment, there may be a role for proxies and other >active intermediaries. However, I think I may have misunderstood the >thrust of your question...? I'm trying to confirm my understanding that if I had an app at my end and federated partners that supported DIAMETER that I wouldn't need the entire eduroam fabric to be running DIAMETER too. In other words, it's a peer to peer problem of updating software to support a feature, not waiting for an entire national network to upgrade. -- Scott From Josh.Howlett@ja.net Fri Nov 4 10:14:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCD121F8C59 for ; Fri, 4 Nov 2011 10:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB3tTbrIgcqD for ; Fri, 4 Nov 2011 10:14:17 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA911E8080 for ; Fri, 4 Nov 2011 10:14:17 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 42CE24A6B62_EB41D68B; Fri, 4 Nov 2011 17:14:16 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 1AF994A6B5C_EB41D68F; Fri, 4 Nov 2011 17:14:16 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 17:14:15 +0000 From: Josh Howlett To: "Cantor, Scott" , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYCAAE2DgIAABjuAgAAcUgCAAAddAIAACluA Date: Fri, 4 Nov 2011 17:14:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <79F3B58519E1E549A2100E849425237B@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:14:17 -0000 >>That's certainly a possible deployment option although I believe that >>even >>in a Diameter-based deployment, there may be a role for proxies and other >>active intermediaries. However, I think I may have misunderstood the >>thrust of your question...? > >I'm trying to confirm my understanding that if I had an app at my end and >federated partners that supported DIAMETER that I wouldn't need the entire >eduroam fabric to be running DIAMETER too. > >In other words, it's a peer to peer problem of updating software to >support a feature, not waiting for an entire national network to upgrade. Ah ok. Yes, it's a peer to peer problem. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From jsalowey@cisco.com Fri Nov 4 10:57:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD711E8082 for ; Fri, 4 Nov 2011 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM+05FCzn7Ir for ; Fri, 4 Nov 2011 10:57:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 02EC611E807F for ; Fri, 4 Nov 2011 10:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=542; q=dns/txt; s=iport; t=1320429450; x=1321639050; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=od0lxfUaYi+uf/rsPbaWg1YI8cbYpzpe7gjIM3iD5xw=; b=P6gqC7upLYI7Haf0G8MRrA6EaGEG2aOZzhNrCuqY9L/KYItrYGS3CcXV 62CbNLDfXivm5rIou0yr9F+zpxj5Cm69tA9anmGnPXlO0SnhoSPNQMW6N V25g+WiHfHOUDOjxAGaeHL4MAq6RbwBxzdpYZOC3TFqBkV1p79UPkYnr2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcHAMwmtE6rRDoI/2dsb2JhbABEmlOOEIEggQWCCwEngjKHaJYAgSYBnlOISGMEiAqMEoUxjFU X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12374096" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 04 Nov 2011 17:57:30 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA4HvTPh019125 for ; Fri, 4 Nov 2011 17:57:29 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2011 10:58:01 -0700 Message-Id: <38ACF849-2CAC-4CA1-94B6-FF6FE0EC89BF@cisco.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [abfab] New Version of draft-winter-abfab-eapapplicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:57:30 -0000 Stefan and I recently published a revision to the EAP applicability = statement draft. It can be found here: = http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-01. The = draft takes incorporates much of the feedback we had on the list. If = there is time on the agenda we can provide an update in the Taipei = meeting. Please provide feedback, If there is general happiness with = the ABFAB portion of the draft we can start socializing with the other = related working groups (EMU, NEA, etc.)=20 Thanks, Joe= From leifj@sunet.se Sat Nov 5 02:27:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1602E21F87C2 for ; Sat, 5 Nov 2011 02:27:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SUX8ieCpVdm for ; Sat, 5 Nov 2011 02:27:49 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF921F8797 for ; Sat, 5 Nov 2011 02:27:48 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pA59RiSW019750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Nov 2011 10:27:47 +0100 (CET) Message-ID: <4EB50190.7010007@sunet.se> Date: Sat, 05 Nov 2011 10:27:44 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <38ACF849-2CAC-4CA1-94B6-FF6FE0EC89BF@cisco.com> In-Reply-To: <38ACF849-2CAC-4CA1-94B6-FF6FE0EC89BF@cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] New Version of draft-winter-abfab-eapapplicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 09:27:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2011 06:58 PM, Joe Salowey wrote: > Stefan and I recently published a revision to the EAP applicability > statement draft. It can be found here: > http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-01. > The draft takes incorporates much of the feedback we had on the > list. If there is time on the agenda we can provide an update in > the Taipei meeting. Please provide feedback, If there is general > happiness with the ABFAB portion of the draft we can start > socializing with the other related working groups (EMU, NEA, etc.) > > No need to give ABFAB an exclusive rw-lock I think. I suggest you guys get up at the mic at all the other relevant WGs and socialize like there is no tomorrow throughout the IETF-week. Lets hope for some good feedback for our Friday meeting. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk61AZAACgkQ8Jx8FtbMZncNpgCgsOI3XId8IBX16xvHSeXGQTdh aykAoIuht8IIHBit5c8D3Yw7uGDl0SPt =m7Bg -----END PGP SIGNATURE----- From hartmans@painless-security.com Sat Nov 5 07:54:09 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7930321F85AE for ; Sat, 5 Nov 2011 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNm2C8iin2TN for ; Sat, 5 Nov 2011 07:54:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 208DA21F85AA for ; Sat, 5 Nov 2011 07:54:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3AA8A20274; Sat, 5 Nov 2011 10:54:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F021E435A; Sat, 5 Nov 2011 10:53:49 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <38ACF849-2CAC-4CA1-94B6-FF6FE0EC89BF@cisco.com> <4EB50190.7010007@sunet.se> Date: Sat, 05 Nov 2011 10:53:49 -0400 In-Reply-To: <4EB50190.7010007@sunet.se> (Leif Johansson's message of "Sat, 05 Nov 2011 10:27:44 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] New Version of draft-winter-abfab-eapapplicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 14:54:09 -0000 As I've expressed earlier, I'd really like to see this draft adopted by ABFAB. I strongly encourage the authors to do any socializing they need to do that or to advance the quality of the draft. --Sam From Josh.Howlett@ja.net Sun Nov 6 08:47:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876A521F84D8 for ; Sun, 6 Nov 2011 08:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0vhAtcQEmYm for ; Sun, 6 Nov 2011 08:47:43 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id EE65F21F84D5 for ; Sun, 6 Nov 2011 08:47:42 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4AA8B4A6B77_EB6BA2BB; Sun, 6 Nov 2011 16:47:39 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id A65314A6B85_EB6BA2AF; Sun, 6 Nov 2011 16:47:38 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Sun, 6 Nov 2011 16:47:38 +0000 From: Josh Howlett To: Josh Howlett , "Cantor, Scott" , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYCAAE2DgIAABjuAgAAcUgCAAAddAIAACluAgAMdTwA= Date: Sun, 6 Nov 2011 16:47:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D7F837484739440B9C987916C13D12D@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:47:43 -0000 (Responding to my own mail) >>> >>>That's certainly a possible deployment option although I believe that >>>even >>>in a Diameter-based deployment, there may be a role for proxies and >>>other >>>active intermediaries. However, I think I may have misunderstood the >>>thrust of your question...? >> >>I'm trying to confirm my understanding that if I had an app at my end and >>federated partners that supported DIAMETER that I wouldn't need the >>entire >>eduroam fabric to be running DIAMETER too. >> >>In other words, it's a peer to peer problem of updating software to >>support a feature, not waiting for an entire national network to upgrade. > >Ah ok. Yes, it's a peer to peer problem. Let me clarify that, because I suspect I was still misunderstanding your question.=20 If you were relying on an intermediate fabric for trust establishment and other assurances, then that fabric (and your federated partners, obviously) would also need to support Diameter. While Diameter supports proxies, it does not require them for trust establishment and routing between federated partners as in the RADIUS case. A Diameter based fabric is much more likely to look like a mesh federation. This obviously creates a problem if you already have a hub-and-spoke or hierarchical hub-and-spoke RADIUS federation (as in the eduroam case) and want to use SAML messages > 4kb. In this case, you need to change your fabric. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Sun Nov 6 12:56:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECF421F861E for ; Sun, 6 Nov 2011 12:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6DnYioT89XZ for ; Sun, 6 Nov 2011 12:56:54 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7930E21F8586 for ; Sun, 6 Nov 2011 12:56:54 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3166120274; Sun, 6 Nov 2011 15:57:32 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CE7B5435A; Sun, 6 Nov 2011 15:56:32 -0500 (EST) From: Sam Hartman To: Josh Howlett References: Date: Sun, 06 Nov 2011 15:56:32 -0500 In-Reply-To: (Josh Howlett's message of "Sun, 6 Nov 2011 16:47:38 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 20:56:55 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> While Diameter supports proxies, it does not require them for Josh> trust establishment and routing between federated partners as Josh> in the RADIUS case. what does this statement mean? I'm obviously missing some important feature of Diameter, which is unsurprising because I know very little about it. From leifj@sunet.se Mon Nov 7 01:15:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444BE21F8569 for ; Mon, 7 Nov 2011 01:15:26 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PISIFtQacVGZ for ; Mon, 7 Nov 2011 01:15:25 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 57E1B21F8515 for ; Mon, 7 Nov 2011 01:15:24 -0800 (PST) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pA79FJib016021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Nov 2011 10:15:23 +0100 (CET) Message-ID: <4EB7A1A7.5070603@sunet.se> Date: Mon, 07 Nov 2011 10:15:19 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 09:15:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2011 09:56 PM, Sam Hartman wrote: >>>>>> "Josh" == Josh Howlett writes: > > Josh> While Diameter supports proxies, it does not require them > for Josh> trust establishment and routing between federated > partners as Josh> in the RADIUS case. > > what does this statement mean? I'm obviously missing some > important feature of Diameter, which is unsurprising because I know > very little about it. I think Josh is saying that Diameter uses SRV records much like RADSEC. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk63oacACgkQ8Jx8FtbMZncASACgiB31n+N0+oZtUQ/hz15PGu4P f+wAoLkdqIZrP60Nm8dMec8xJhnBoQaj =UpQa -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Nov 7 01:25:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23AA21F8663 for ; Mon, 7 Nov 2011 01:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nQfzmLnmdOY for ; Mon, 7 Nov 2011 01:25:43 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 386F121F85A8 for ; Mon, 7 Nov 2011 01:25:43 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0D3E71A9A247_EB7A415B; Mon, 7 Nov 2011 09:25:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id DDA211A9A240_EB7A414F; Mon, 7 Nov 2011 09:25:40 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Mon, 7 Nov 2011 09:25:40 +0000 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYCAAE2DgIAABjuAgAAcUgCAAAddAIAACluAgAMdTwCAAEWkHIAAzlCAgAAC5IA= Date: Mon, 7 Nov 2011 09:25:40 +0000 Message-ID: In-Reply-To: <4EB7A1A7.5070603@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 09:25:43 -0000 > >On 11/06/2011 09:56 PM, Sam Hartman wrote: >>>>>>> "Josh" =3D=3D Josh Howlett writes: >>=20 >> Josh> While Diameter supports proxies, it does not require them >> for Josh> trust establishment and routing between federated >> partners as Josh> in the RADIUS case. >>=20 >> what does this statement mean? I'm obviously missing some >> important feature of Diameter, which is unsurprising because I know >> very little about it. > >I think Josh is saying that Diameter uses SRV records much like RADSEC. Yes, that kind of thing. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Mon Nov 7 05:19:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072FE21F8B82 for ; Mon, 7 Nov 2011 05:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dw32G0IBclO for ; Mon, 7 Nov 2011 05:19:55 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9399021F8B7B for ; Mon, 7 Nov 2011 05:19:55 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6ABC7201CB; Mon, 7 Nov 2011 08:20:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56EF6435A; Mon, 7 Nov 2011 08:19:40 -0500 (EST) From: Sam Hartman To: Josh Howlett References: Date: Mon, 07 Nov 2011 08:19:40 -0500 In-Reply-To: (Josh Howlett's message of "Mon, 7 Nov 2011 09:25:40 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 13:19:56 -0000 >>>>> "Josh" == Josh Howlett writes: >> >> On 11/06/2011 09:56 PM, Sam Hartman wrote: >>>>>>>> "Josh" == Josh Howlett writes: >>> Josh> While Diameter supports proxies, it does not require them >>> for Josh> trust establishment and routing between federated >>> partners as Josh> in the RADIUS case. >>> >>> what does this statement mean? I'm obviously missing some >>> important feature of Diameter, which is unsurprising because I >>> know very little about it. >> >> I think Josh is saying that Diameter uses SRV records much like >> RADSEC. Josh> Yes, that kind of thing. Yeah, but how does that help me without a trust relationship? From Josh.Howlett@ja.net Mon Nov 7 05:40:49 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1E621F8B8F for ; Mon, 7 Nov 2011 05:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXVxeM601uKz for ; Mon, 7 Nov 2011 05:40:48 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5468121F8B8E for ; Mon, 7 Nov 2011 05:40:48 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7023A4A6B65_EB7DFDCB; Mon, 7 Nov 2011 13:40:44 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 489B44A6B5C_EB7DFDCF; Mon, 7 Nov 2011 13:40:44 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Mon, 7 Nov 2011 13:40:43 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AQHMmCb0k0p7Nh9VoUG4kP9gt2B2ypWbGDuAgAALPQCAAAAaAIAAAnwAgAAT2ICAAAXRAIAAAhyAgAADGwCAAAMxgIAABXKAgAAFTgCAACF624AA+sYAgAAJEYCAAE2DgIAABjuAgAAcUgCAAAddAIAACluAgAMdTwCAAEWkHIAAzlCAgAAC5ICAAEF83oAABcYA Date: Mon, 7 Nov 2011 13:40:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <1ACC52A82D4D01439DE00A2AF42EBC18@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 13:40:49 -0000 > Josh> While Diameter supports proxies, it does not require them > >>> for Josh> trust establishment and routing between federated > >>> partners as Josh> in the RADIUS case. > >>>=20 > >>> what does this statement mean? I'm obviously missing some > >>> important feature of Diameter, which is unsurprising because I > >>> know very little about it. > >>=20 > >> I think Josh is saying that Diameter uses SRV records much like > >> RADSEC. > > Josh> Yes, that kind of thing. > >Yeah, but how does that help me without a trust relationship? In RADIUS you're compelled to use proxy for federated trust relationships. In Diameter you have more options. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Mon Nov 7 06:37:35 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE6021F8B2B for ; Mon, 7 Nov 2011 06:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fMMZjhCqxt9 for ; Mon, 7 Nov 2011 06:37:34 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C570B21F8B2A for ; Mon, 7 Nov 2011 06:37:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D232320424; Mon, 7 Nov 2011 09:38:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B628B435A; Mon, 7 Nov 2011 09:37:23 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB3EB21.6090800@deployingradius.com> Date: Mon, 07 Nov 2011 09:37:23 -0500 In-Reply-To: <4EB3EB21.6090800@deployingradius.com> (Alan DeKok's message of "Fri, 04 Nov 2011 14:39:45 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba , "abfab@ietf.org" Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:37:35 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> 4282 is currently a normative dependency of >> draft-ietf-abfab-gss-eap. Alan> That's a problem. As Bernard said, 4282 mandates behavior Alan> which *no one* implements. Anyone implementing 4282 will be Alan> incompatible with all known RADIUS systems. I think we can come up with text that makes it clear what's going on and that leaves processing to the final AAA server. I do support doing that. I do not support changing the dependency to a draft instead of an RFC. If we fail to be able to come up with clear text that makes our intent clear, then I'll re-evaluate my position. Obviously if the WG comes to some other consensus I'll be happy to update the dependency. From aland@deployingradius.com Mon Nov 7 08:07:04 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3043321F8BF4 for ; Mon, 7 Nov 2011 08:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiNEr7Hgh1VX for ; Mon, 7 Nov 2011 08:07:03 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A197021F8BEF for ; Mon, 7 Nov 2011 08:07:03 -0800 (PST) Message-ID: <4EB8020A.5060000@deployingradius.com> Date: Mon, 07 Nov 2011 17:06:34 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB3EB21.6090800@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "abfab@ietf.org" Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:07:04 -0000 Sam Hartman wrote: > I think we can come up with text that makes it clear what's going on and > that leaves processing to the final AAA server. That isn't enough. 4282 requires that the NAI be mangled in order to create a normal form. This mangling is done *before* the NAI is used in EAP. No NAI implementation does this. Requiring compliance with 4282 means that implementations of draft-ietf-abfab-gss-eap *cannot* inter-operate with existing EAP implementations. > I do support doing > that. I do not support changing the dependency to a draft instead of an > RFC. I understand why. Alan DeKok. From hannes.tschofenig@nsn.com Mon Nov 7 09:11:46 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A683221F8B0C for ; Mon, 7 Nov 2011 09:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.696 X-Spam-Level: X-Spam-Status: No, score=-106.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7T0voK+xJGA for ; Mon, 7 Nov 2011 09:11:46 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0521F8B05 for ; Mon, 7 Nov 2011 09:11:45 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA7HBiUO031911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 18:11:44 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA7HBfwr030426; Mon, 7 Nov 2011 18:11:43 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 18:11:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 19:13:24 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DBDD109@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt Thread-Index: AcydT/QvvX+PVv/vRlKGnojZOsGP0QAHHBkw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sam Hartman" , "Josh Howlett" X-OriginalArrivalTime: 07 Nov 2011 17:11:42.0393 (UTC) FILETIME=[51F6D290:01CC9D70] Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 17:11:46 -0000 There are two aspects:=20 1) How can you technically find the server you need to talk to? Diameter has defined a DNS based discovery procedure. 2) Is the Diameter entity you talk to indeed some entity you trust? The IETF Diameter specifications only talk about (1) and not about (2).=20 They implicitly assume that (2) is addressed somehow outside the realm of the IETF.=20 There is a relationship between the two issues. Depending on how you address (2) you may constraint the solutions for (1). Not only the AAA community had made that observation but also the RAI guys with their work on SIP when the had initially planned to model the proxy-to-proxy interaction according to email.=20 In Diameter the DNS based discovery was not used by anyone at few years back; this was the time when I co-chaired the DIME group and helped to organize interop-events were we had gotten feedback from the other implementers. Everyone was using nailed-up connections (and they used IPsec) and so the need to dynamically discover servers did not arise.=20 Ciao Hannes -----Original Message----- From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of ext Sam Hartman Sent: Monday, November 07, 2011 3:20 PM To: Josh Howlett Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt >>>>> "Josh" =3D=3D Josh Howlett writes: >>=20 >> On 11/06/2011 09:56 PM, Sam Hartman wrote: >>>>>>>> "Josh" =3D=3D Josh Howlett writes: >>>=20 Josh> While Diameter supports proxies, it does not require them >>> for Josh> trust establishment and routing between federated >>> partners as Josh> in the RADIUS case. >>>=20 >>> what does this statement mean? I'm obviously missing some >>> important feature of Diameter, which is unsurprising because I >>> know very little about it. >>=20 >> I think Josh is saying that Diameter uses SRV records much like >> RADSEC. Josh> Yes, that kind of thing. Yeah, but how does that help me without a trust relationship? _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From leifj@sunet.se Mon Nov 7 11:08:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BAE11E809C for ; Mon, 7 Nov 2011 11:08:48 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX9n1mTgmK-3 for ; Mon, 7 Nov 2011 11:08:48 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA8B11E808E for ; Mon, 7 Nov 2011 11:08:47 -0800 (PST) Received: from [10.0.0.232] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pA7J8dG5026900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Nov 2011 20:08:44 +0100 (CET) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <629CF7D5-D11A-45EC-B9DB-156CFBCDBB9C@sunet.se> X-Mailer: iPad Mail (8L1) From: Leif Johansson Date: Mon, 7 Nov 2011 20:09:29 +0100 To: Sam Hartman Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:08:48 -0000 7 nov 2011 kl. 14:19 skrev Sam Hartman : >>>>>> "Josh" == Josh Howlett writes: > >>> >>> On 11/06/2011 09:56 PM, Sam Hartman wrote: >>>>>>>>> "Josh" == Josh Howlett writes: >>>> > Josh> While Diameter supports proxies, it does not require them >>>> for Josh> trust establishment and routing between federated >>>> partners as Josh> in the RADIUS case. >>>> >>>> what does this statement mean? I'm obviously missing some >>>> important feature of Diameter, which is unsurprising because I >>>> know very little about it. >>> >>> I think Josh is saying that Diameter uses SRV records much like >>> RADSEC. > > Josh> Yes, that kind of thing. > > Yeah, but how does that help me without a trust relationship? It doesn't really. From hartmans@painless-security.com Mon Nov 7 11:09:33 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EF121F84A9 for ; Mon, 7 Nov 2011 11:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbrgTvUXphNq for ; Mon, 7 Nov 2011 11:09:33 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 40C2021F848E for ; Mon, 7 Nov 2011 11:09:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D7938201CB; Mon, 7 Nov 2011 14:10:21 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8C137435A; Mon, 7 Nov 2011 14:09:21 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB3EB21.6090800@deployingradius.com> <4EB8020A.5060000@deployingradius.com> Date: Mon, 07 Nov 2011 14:09:21 -0500 In-Reply-To: <4EB8020A.5060000@deployingradius.com> (Alan DeKok's message of "Mon, 07 Nov 2011 17:06:34 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba , "abfab@ietf.org" Subject: Re: [abfab] [radext] RFC 4282 and RADIUS implementations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:09:33 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> I think we can come up with text that makes it clear what's going >> on and that leaves processing to the final AAA server. Alan> That isn't enough. 4282 requires that the NAI be mangled in Alan> order to create a normal form. This mangling is done *before* Alan> the NAI is used in EAP. Alan> No NAI implementation does this. Requiring compliance with Alan> 4282 means that implementations of draft-ietf-abfab-gss-eap Alan> *cannot* inter-operate with existing EAP implementations. Understood. I believe we can also make it clear that the realm portion of a GSS EAP name is not mangled. From hartmans@painless-security.com Wed Nov 9 12:53:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83701F0C88 for ; Wed, 9 Nov 2011 12:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQI1UjiWmorq for ; Wed, 9 Nov 2011 12:53:48 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD8F1F0C86 for ; Wed, 9 Nov 2011 12:53:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 222632009E; Wed, 9 Nov 2011 15:54:30 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 940B9435A; Wed, 9 Nov 2011 15:53:42 -0500 (EST) From: Sam Hartman To: abfab@ietf.org, ietf-krb-wg@anl.gov mail-followups-to: ietf-krb-wg@anl.gov Date: Wed, 09 Nov 2011 15:53:42 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:53:48 -0000 [I think this is a Kerberos discussion mostly, but consider keeping abfab in your reply if your discussion fits the abfab list.] A month or so ago, I promised to write up a use case in response to an abfab discussion having to do with obtaining a Kerberos ticket as a side effect of a gss-eap preauthentication. As background, Microsoft has a Kerberos mechanism called protocol transition. The idea is that a service authenticates someone using a non-Kerberos means. However, that service still wants to know what the authorization characteristics of that user are. In the Microsoft model, the KDC/directory are always responsible for domain level authorization. In order to obtain authorization information you need a security token; to get one of those in a domain you generally need a Kerberos PAC. There's a lot going for this model. It centralizes policy for the RP organization in one place: the domain controller for the resource domain. We had several discussions at the MIT Kerberos Consortium's conference last year about how valuable this is, and about how if we can maintain this in the federated context, Kerberos could be an important policy mechanism for the cloud. I'd like Moonshot (the GSS-EAP implementation I'm working on) to be able to support this model. One thing we can do is just use protocol transition as it's specified in Microsoft's extensions today. You do a GSS-EAP authentication to the RP, the RP asks the KDC for a ticket, life goes on. The problem with this is that protocol transition is relatively weak from a security standpoint. The service makes an assertion to the KDC that authentication happened. This can be a privacy exposure to a certain extent: the service needs to be trusted to obtain authorization information for any user who might authenticate to it regardless of whether they have. Microsoft has accepted this; some environments may not. Another problem is that the resource domain controller may not have the information needed to construct authorization information in a GSS-EAP federation. SAML or RADIUS or Diameter information may be necessary. Now, the KDC could trust the service to disclose the information, or could possibly rely on SAML signatures. Trusting the service that much seems a big stretch. Relying on SAMl signatures viloates the one-trust-infrastructure design principle. In particular, it's generally a bad idea for a security system to force deployers to set up more than one trust infrastructure because those are very expensive. If we're using GSS-EAP we already have AAA trust. We should use that. so, somehow, we need to get the KDC as a trusted intermediary in the GSS-EAP authentication. Note that we don't want to depend on any particular initiator functionality. the RP needs to interact with the KDC for its own purposes regardless of whether the initiator has ever heard of Kerberos. I had originally thought about an EAP pre-authentication mechanism to accomplish this goal. The idea is that gss-eap would take EAP packets out of its incoming tokens and send them to the KDC as part of a fast-armored AS-request. The client would be ambiguous--somehow determined by preauth and the service would be the RP. The service would not learn the MSK, but could be told the GMSK (GSS-EAP key). If I could figure out a way to do this with gss-preauth and gss-eap then I'd support gss-preauth. Conceptually, I guess what's going on here is that you want to export a context from the KDC and import it on the RP. However, we don't want to expose the MSK to the RP so that if we are doing something that exposes a TGT to the initiator we have a key to use. So, this involves probably some changes to GSS-EAP and to the preauth type. GSS-EAP probably needs to gain a standardized exported context and the GSS preauth needs to gain a way to transfer an exported context token if the mechanism supports the appropriate attribute. Or something like that. I'd appreciate comments on this use case and once we understand the use case I'd like to talk about mechanisms for getting there. From nico@cryptonector.com Wed Nov 9 13:46:59 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E220F11E8093 for ; Wed, 9 Nov 2011 13:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDiVyDLI2V3s for ; Wed, 9 Nov 2011 13:46:59 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3711E8080 for ; Wed, 9 Nov 2011 13:46:59 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 1079B26406A for ; Wed, 9 Nov 2011 13:46:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ZkQ2FEwmTqrgDYvCHL2iw N4BLfzMmCC65wKSkE7fhCQ8QB2Mmg+BzKrHFGY3/Pj9ld+N6KWVs0fgGKecTpedj P5MhVto8hyp+/uFcwUiPSrnrrhf1T9pOIm/6Gc4YWhCb2mvsduvDX3BXZQLEj1mb vR3plZax6BKIOpQddYCNJ0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U4ETEYQdeXJloRaAfi1C vmA9+Po=; b=cLqTu0CgN5lNy0hY/eEK9eCzdSb/7Va7yulp/reck+b9BBrXokkj Gu+c8AOK7HMax/vJmaKdadJFHxIjV+vEGDGO8LpNfu19tsUWmshzYNNyoxtxYqBA XvYVxPsdherFfykBbLvzYH2HNcHa3zrPg5lkm6tJRHPf3kuKlifn0UU= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id DED86264063 for ; Wed, 9 Nov 2011 13:46:58 -0800 (PST) Received: by ywt2 with SMTP id 2so2639846ywt.31 for ; Wed, 09 Nov 2011 13:46:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.199 with SMTP id a7mr8399540pbc.58.1320875217841; Wed, 09 Nov 2011 13:46:57 -0800 (PST) Received: by 10.68.40.162 with HTTP; Wed, 9 Nov 2011 13:46:57 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Nov 2011 15:46:57 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: ietf-krb-wg@anl.gov, abfab@ietf.org Subject: Re: [abfab] [Ietf-krb-wg] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:47:00 -0000 I agree that this is a desirable use case. I think this can be generalized though, via an IAKERB-like GSS mechanism. Let me sketch it that way and then see if we can make incremental changes to GSS-EAP instead of pursuing a generic solution. What I have in mind is a pseudo-mechanism -- think of it as a stackable pseudo-mechanism. It needn't actually be that generic if that's a problem for you. The pseudo-mechanism would add a bit of framing to the initiator's initial security context and channel binding data by which to bear the name of the RP, while the inner context tokens would be targeted at a different RP: the KDC in this case. Ah, but the initiator would have to learn the name of the inner context's RP (the KDC, or rather, realm name), and this would either require a host2realm facility like we have in most Kerberos clients, or an extra round-trip (and trusting the RP); we wouldn't wan the extra round-trip. On the acceptor side all context tokens would be proxied to the KDC over a tunnel authenticating the RP to the KDC, and then the KDC would give the RP an exported security context token. So that's the generic sketch. A non-generic set of changes for GSS-EAP would look the same, only without a different mechanism OID and without the generic pseudo-mechanism in the way. Note that you'll need the RP to be able to tell the KDC about the CB data affix -the RP's name as seen by the initiator- or have the KDC figure it out from the context (the armor key for the FAST tunnel). Nico -- From hartmans@mit.edu Wed Nov 9 14:08:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73021F849B for ; Wed, 9 Nov 2011 14:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.995 X-Spam-Level: X-Spam-Status: No, score=-102.995 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS11YlJT0zWO for ; Wed, 9 Nov 2011 14:08:07 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D055421F84A1 for ; Wed, 9 Nov 2011 14:08:06 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C7D03201F1; Wed, 9 Nov 2011 17:08:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3AAC0435A; Wed, 9 Nov 2011 17:07:57 -0500 (EST) From: Sam Hartman To: Nico Williams References: Date: Wed, 09 Nov 2011 17:07:57 -0500 In-Reply-To: (Nico Williams's message of "Wed, 9 Nov 2011 15:46:57 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-krb-wg@anl.gov, abfab@ietf.org, Sam Hartman Subject: Re: [abfab] [Ietf-krb-wg] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:08:08 -0000 So, you presented an alternate proposal that violated one of my constraints without describing what it offers that my proposal did not offer. In particular, you propose changing the initiator. I don't like changing the initiator to support this use case because it's possible for an initiator to mis-implement the new functionality or if it is optional to choose not to implement it at all. Then you get initiators that work against some environments but not against high-infrastructure environments, which tend to be sensitive to working with as many initiators as possible. Also, I don't think the set of RP-side intermediates is the initiator's business at all. We don't tell the initiator what AAA proxies we use, so why should the initiator be involved in this? Finally, host-to-realm in clients has generally been regarded as a bad idea in Kerberos. If we had it to do over I would not support host-to-realm functionality in the clients. I don't support having that functionality in clients in a new protocol. From alex@um.es Thu Nov 10 01:49:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C18221F8B05 for ; Thu, 10 Nov 2011 01:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QdSougWPN4B for ; Thu, 10 Nov 2011 01:49:49 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id F351621F8ABE for ; Thu, 10 Nov 2011 01:49:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 9AA854C256; Thu, 10 Nov 2011 10:49:46 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YlB29p8FRey6; Thu, 10 Nov 2011 10:49:45 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 45EE54C259; Thu, 10 Nov 2011 10:49:40 +0100 (CET) Message-ID: <4EBB9E33.4040706@um.es> Date: Thu, 10 Nov 2011 10:49:39 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-krb-wg@anl.gov, abfab@ietf.org Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:49:50 -0000 > [I think this is a Kerberos discussion mostly, but consider keeping > abfab in your reply if your discussion fits the abfab list.] > > A month or so ago, I promised to write up a use case in response to an > abfab discussion having to do with obtaining a Kerberos ticket as a side > effect of a gss-eap preauthentication. > > > As background, Microsoft has a Kerberos mechanism called protocol > transition. The idea is that a service authenticates someone using a > non-Kerberos means. However, that service still wants to know what the > authorization characteristics of that user are. > In the Microsoft model, the KDC/directory are always responsible for > domain level authorization. > In order to obtain authorization information you need a security token; > to get one of those in a domain you generally need a Kerberos PAC. > > There's a lot going for this model. It centralizes policy for the RP > organization in one place: the domain controller for the resource > domain. > > We had several discussions at the MIT Kerberos Consortium's conference > last year about how valuable this is, and about how if we can maintain > this in the federated context, Kerberos could be an important policy > mechanism for the cloud. > > I'd like Moonshot (the GSS-EAP implementation I'm working on) to be able > to support this model. Would be acceptable to support Kerberos on the client side? If so, then I think this model (or a very similar one) could be supported by Moonshot by relying in IAKERB and draft-perez-abfab-eap-gss-preauth. The initiator (client) authenticates with the KDC by means of GSS-preauth + GSS-EAP. The transport of the Kerberos messages is done throught the RP, which at the end will obtain the ST with the corresponding authorization information. This way GSS-EAP is being used for federated authentication while the KDC is being used for local realm authorization. > > One thing we can do is just use protocol transition as it's specified in > Microsoft's extensions today. > You do a GSS-EAP authentication to the RP, the RP asks the KDC for a > ticket, life goes on. > > The problem with this is that protocol transition is relatively weak > from a security standpoint. The service makes an assertion to the KDC > that authentication happened. > This can be a privacy exposure to a certain extent: the service needs to > be trusted to obtain authorization information for any user who might > authenticate to it regardless of whether they have. Microsoft has > accepted this; some environments may not. > > Another problem is that the resource domain controller may not have the > information needed to construct authorization information in a GSS-EAP > federation. SAML or RADIUS or Diameter information may be > necessary. Now, the KDC could trust the service to disclose the > information, or could possibly rely on SAML signatures. > > Trusting the service that much seems a big stretch. > > Relying on SAMl signatures viloates the one-trust-infrastructure design > principle. In particular, it's generally a bad idea for a security > system to force deployers to set up more than one trust infrastructure > because those are very expensive. If we're using GSS-EAP we already have > AAA trust. We should use that. > > so, somehow, we need to get the KDC as a trusted intermediary in the > GSS-EAP authentication. > > Note that we don't want to depend on any particular initiator > functionality. the RP needs to interact with the KDC for its own > purposes regardless of whether the initiator has ever heard of Kerberos. > > I had originally thought about an EAP pre-authentication mechanism to > accomplish this goal. The idea is that gss-eap would take EAP packets > out of its incoming tokens and send them to the KDC as part of a > fast-armored AS-request. The client would be ambiguous--somehow > determined by preauth and the service would be the RP. The service > would not learn the MSK, but could be told the GMSK (GSS-EAP key). What will be the RP from the point of view of the home AAA/IdP? It should be the original RP (the application), and not the KDC if you want to provide a full set of attributes and you want the IdP to be able to determine which privacy policies will be applicable to release them. Best regards, Alejandro > > If I could figure out a way to do this with gss-preauth and gss-eap then > I'd support gss-preauth. > > > Conceptually, I guess what's going on here is that you want to export a > context from the KDC and import it on the RP. However, we don't want to > expose the MSK to the RP so that if we are doing something that exposes > a TGT to the initiator we have a key to use. > > So, this involves probably some changes to GSS-EAP and to the preauth > type. GSS-EAP probably needs to gain a standardized exported context > and the GSS preauth needs to gain a way to transfer an exported context > token if the mechanism supports the appropriate attribute. > Or something like that. > > I'd appreciate comments on this use case and once we understand the use > case I'd like to talk about mechanisms for getting there. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Nov 10 02:09:16 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0799821F8AD1 for ; Thu, 10 Nov 2011 02:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2QJqBQIyHWg for ; Thu, 10 Nov 2011 02:09:15 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAF621F84FB for ; Thu, 10 Nov 2011 02:09:15 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E88C22009E; Thu, 10 Nov 2011 05:10:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF0E0435A; Thu, 10 Nov 2011 05:09:12 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <4EBB9E33.4040706@um.es> Date: Thu, 10 Nov 2011 05:09:12 -0500 In-Reply-To: <4EBB9E33.4040706@um.es> (Alejandro Perez Mendez's message of "Thu, 10 Nov 2011 10:49:39 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-krb-wg@anl.gov, abfab@ietf.org, Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 10:09:16 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >> [I think this is a Kerberos discussion mostly, but consider >> keeping abfab in your reply if your discussion fits the abfab >> list.] >> >> A month or so ago, I promised to write up a use case in response >> to an abfab discussion having to do with obtaining a Kerberos >> ticket as a side effect of a gss-eap preauthentication. >> >> >> As background, Microsoft has a Kerberos mechanism called protocol >> transition. The idea is that a service authenticates someone >> using a non-Kerberos means. However, that service still wants to >> know what the authorization characteristics of that user are. In >> the Microsoft model, the KDC/directory are always responsible for >> domain level authorization. In order to obtain authorization >> information you need a security token; to get one of those in a >> domain you generally need a Kerberos PAC. >> >> There's a lot going for this model. It centralizes policy for the >> RP organization in one place: the domain controller for the >> resource domain. >> >> We had several discussions at the MIT Kerberos Consortium's >> conference last year about how valuable this is, and about how if >> we can maintain this in the federated context, Kerberos could be >> an important policy mechanism for the cloud. >> >> I'd like Moonshot (the GSS-EAP implementation I'm working on) to >> be able to support this model. Alejandro> Would be acceptable to support Kerberos on the client Alejandro> side? Alejandro> If so, then I think this model (or a very similar one) Alejandro> could be supported by Moonshot by relying in IAKERB and Alejandro> draft-perez-abfab-eap-gss-preauth. The initiator (client) Alejandro> authenticates with the KDC by means of GSS-preauth + Alejandro> GSS-EAP. The transport of the Kerberos messages is done Alejandro> throught the RP, which at the end will obtain the ST with Alejandro> the corresponding authorization information. This way Alejandro> GSS-EAP is being used for federated authentication while Alejandro> the KDC is being used for local realm authorization. No, not really. I see lots of reasons why I don't think this works. The biggest in my mind is that the client behavior I'd recommend for Kerberos is different than what I'd recommend for GSS-EAP. Kerberos is something that clients tend to try and use whenever it is available. They assume it will fast-fail if it is the wrong option for a given authentication. That's not really true for something Federated. Also, this needs to behavior that doesn't require client-side support so that you can't end up with clients that don't support it. It would be OK to add mandatory behavior to draft-ietf-abfab-gss-eap. However I definitely don't want to end up with clients that don't support whatever we end up with here. Alejandro> What will be the RP from the point of view of the home Alejandro> AAA/IdP? It should be the original RP (the application), Alejandro> and not the KDC if you want to provide a full set of Alejandro> attributes and you want the IdP to be able to determine Alejandro> which privacy policies will be applicable to release Alejandro> them. In my model the client thinks it is authenticating to the RP, so the RP's information is in the acceptor name RADIUS attributes. The KDC may include other information, possibly convincing the IDP to release more attributes to the KDC only some of which will be forwarded to this RP. (Think constrained Kerberos delegation). Alternatively the IDP may release only the attributes needed by this RP and the KDC may do additional attribute queries as in your prototype. From a deployment standpoint I don't like that model because it is desirable to minimize cases where a KDC calls out to another domain, but if you need that level of privacy it is the right approach. --Sam From alex@um.es Thu Nov 10 02:27:11 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5C821F8A62 for ; Thu, 10 Nov 2011 02:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibe7EO4pMXzS for ; Thu, 10 Nov 2011 02:27:10 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 795EA21F8A58 for ; Thu, 10 Nov 2011 02:27:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id A50414C275; Thu, 10 Nov 2011 11:27:08 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L7C4aiUpY+x3; Thu, 10 Nov 2011 11:27:08 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 830D14C26C; Thu, 10 Nov 2011 11:27:02 +0100 (CET) Message-ID: <4EBBA6F6.3050804@um.es> Date: Thu, 10 Nov 2011 11:27:02 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4EBB9E33.4040706@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ietf-krb-wg@anl.gov, abfab@ietf.org, Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 10:27:11 -0000 El 10/11/11 11:09, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > >> [I think this is a Kerberos discussion mostly, but consider > >> keeping abfab in your reply if your discussion fits the abfab > >> list.] > >> > >> A month or so ago, I promised to write up a use case in response > >> to an abfab discussion having to do with obtaining a Kerberos > >> ticket as a side effect of a gss-eap preauthentication. > >> > >> > >> As background, Microsoft has a Kerberos mechanism called protocol > >> transition. The idea is that a service authenticates someone > >> using a non-Kerberos means. However, that service still wants to > >> know what the authorization characteristics of that user are. In > >> the Microsoft model, the KDC/directory are always responsible for > >> domain level authorization. In order to obtain authorization > >> information you need a security token; to get one of those in a > >> domain you generally need a Kerberos PAC. > >> > >> There's a lot going for this model. It centralizes policy for the > >> RP organization in one place: the domain controller for the > >> resource domain. > >> > >> We had several discussions at the MIT Kerberos Consortium's > >> conference last year about how valuable this is, and about how if > >> we can maintain this in the federated context, Kerberos could be > >> an important policy mechanism for the cloud. > >> > >> I'd like Moonshot (the GSS-EAP implementation I'm working on) to > >> be able to support this model. > > Alejandro> Would be acceptable to support Kerberos on the client > Alejandro> side? > > Alejandro> If so, then I think this model (or a very similar one) > Alejandro> could be supported by Moonshot by relying in IAKERB and > Alejandro> draft-perez-abfab-eap-gss-preauth. The initiator (client) > Alejandro> authenticates with the KDC by means of GSS-preauth + > Alejandro> GSS-EAP. The transport of the Kerberos messages is done > Alejandro> throught the RP, which at the end will obtain the ST with > Alejandro> the corresponding authorization information. This way > Alejandro> GSS-EAP is being used for federated authentication while > Alejandro> the KDC is being used for local realm authorization. > > No, not really. > > I see lots of reasons why I don't think this works. > The biggest in my mind is that the client behavior I'd recommend for > Kerberos is different than what I'd recommend for GSS-EAP. > Kerberos is something that clients tend to try and use whenever it is > available. > They assume it will fast-fail if it is the wrong option for a given > authentication. > That's not really true for something Federated. I don't see why a user on possession of a valid ticket for the application's realm should not be use it to fast authenticate with it. I agree a different situation would occur when the user does not have a TGT yet, but I don't really see a big difference between starting a Kerberos preauthentication (which will use GSS-EAP as mechanism) or a direct GSS-EAP authentication. In the usual Kerberos use case, the user has to "kinit" to obtain the TGT, and that process may imply several round trips as specified in RFC 6113. > > Also, this needs to behavior that doesn't require client-side support so > that you can't end up with clients that don't support it. > It would be OK to add mandatory behavior to > draft-ietf-abfab-gss-eap. However I definitely don't want to end up > with clients that don't support whatever we end up with here. I see your point, but anyway it does require the client to support GSS-EAP. Why not adding a Kerberos dependency for the support of the specific use case? > > Alejandro> What will be the RP from the point of view of the home > Alejandro> AAA/IdP? It should be the original RP (the application), > Alejandro> and not the KDC if you want to provide a full set of > Alejandro> attributes and you want the IdP to be able to determine > Alejandro> which privacy policies will be applicable to release > Alejandro> them. > > In my model the client thinks it is authenticating to the RP, so the > RP's information is in the acceptor name RADIUS attributes. The KDC may > include other information, possibly convincing the IDP to release more > attributes to the KDC only some of which will be forwarded to this > RP. (Think constrained Kerberos delegation). Alternatively the IDP may > release only the attributes needed by this RP and the KDC may do > additional attribute queries as in your prototype. From a deployment > standpoint I don't like that model because it is desirable to minimize > cases where a KDC calls out to another domain, but if you need that > level of privacy it is the right approach. Ok, thanks for the clarification. I understand now. I thought that the KDC was including its own name in the Acceptor Name RADIUS attribute. Regards, Alejandro > > --Sam From hartmans@painless-security.com Thu Nov 10 03:32:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DEE21F8AEE for ; Thu, 10 Nov 2011 03:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu5N8m82cYj1 for ; Thu, 10 Nov 2011 03:32:36 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D801F21F8ADC for ; Thu, 10 Nov 2011 03:32:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AE3492009E; Thu, 10 Nov 2011 06:33:20 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 77680435A; Thu, 10 Nov 2011 06:32:32 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <4EBB9E33.4040706@um.es> <4EBBA6F6.3050804@um.es> Date: Thu, 10 Nov 2011 06:32:32 -0500 In-Reply-To: <4EBBA6F6.3050804@um.es> (Alejandro Perez Mendez's message of "Thu, 10 Nov 2011 11:27:02 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-krb-wg@anl.gov, abfab@ietf.org, Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 11:32:36 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >> Alejandro> Would be acceptable to support Kerberos on the client Alejandro> side? >> Alejandro> If so, then I think this model (or a very similar one) Alejandro> could be supported by Moonshot by relying in IAKERB and Alejandro> draft-perez-abfab-eap-gss-preauth. The initiator (client) Alejandro> authenticates with the KDC by means of GSS-preauth + Alejandro> GSS-EAP. The transport of the Kerberos messages is done Alejandro> throught the RP, which at the end will obtain the ST with Alejandro> the corresponding authorization information. This way Alejandro> GSS-EAP is being used for federated authentication while Alejandro> the KDC is being used for local realm authorization. >> >> No, not really. >> >> I see lots of reasons why I don't think this works. The biggest >> in my mind is that the client behavior I'd recommend for Kerberos >> is different than what I'd recommend for GSS-EAP. Kerberos is >> something that clients tend to try and use whenever it is >> available. They assume it will fast-fail if it is the wrong >> option for a given authentication. That's not really true for >> something Federated. Alejandro> I don't see why a user on possession of a valid ticket Alejandro> for the application's realm should not be use it to fast Alejandro> authenticate with it. I want this, yes. However for the fast reauthentication use case it's reasonable to assume initiator support. Alejandro> I agree a different situation Alejandro> would occur when the user does not have a TGT yet, but I Alejandro> don't really see a big difference between starting a Alejandro> Kerberos preauthentication (which will use GSS-EAP as Alejandro> mechanism) or a direct GSS-EAP authentication. In the Alejandro> usual Kerberos use case, the user has to "kinit" to Alejandro> obtain the TGT, and that process may imply several round Alejandro> trips as specified in RFC 6113. I'm not worried about the round trips when the authentication succeeds. The issue is what should the client application logic. There are a lot of applications (and this is encouraged) for Kerberos where the application tries fairly hard to use Kerberos if Kerberos is offered by the server. The assumption is a coupling of realms; the people who you talk to who offer Kerberos are people you want to talk Kerberos to. This affects retry behavior, affects whether you prompt users for Kerberos passwords, etc. This is an operational issue not directly a protocol issue. It's a big deal though. >> >> Also, this needs to behavior that doesn't require client-side >> support so that you can't end up with clients that don't support >> it. It would be OK to add mandatory behavior to >> draft-ietf-abfab-gss-eap. However I definitely don't want to end >> up with clients that don't support whatever we end up with here. Alejandro> I see your point, but anyway it does require the client Alejandro> to support GSS-EAP. Why not adding a Kerberos dependency Alejandro> for the support of the specific use case? The deployment motivations are wrong. The RP is the one who has the deployment insentive to share infrastructure and better handle authorization within the RP organization. If making that work depends on something the client does, then it's a lot harder to deploy because the client is not motivated to make internal RP matters easier. So, the RP would either have to have a fallback for clients that don't support the option or would end up just not using the option. >> Alejandro> What will be the RP from the point of view of the home Alejandro> AAA/IdP? It should be the original RP (the application), Alejandro> and not the KDC if you want to provide a full set of Alejandro> attributes and you want the IdP to be able to determine Alejandro> which privacy policies will be applicable to release Alejandro> them. >> >> In my model the client thinks it is authenticating to the RP, so >> the RP's information is in the acceptor name RADIUS attributes. >> The KDC may include other information, possibly convincing the >> IDP to release more attributes to the KDC only some of which will >> be forwarded to this RP. (Think constrained Kerberos >> delegation). Alternatively the IDP may release only the >> attributes needed by this RP and the KDC may do additional >> attribute queries as in your prototype. From a deployment >> standpoint I don't like that model because it is desirable to >> minimize cases where a KDC calls out to another domain, but if >> you need that level of privacy it is the right approach. Alejandro> Ok, thanks for the clarification. I understand now. I Alejandro> thought that the KDC was including its own name in the Alejandro> Acceptor Name RADIUS attribute. If the KDC puts its own name in the acceptor name attribute, then the channel binding will fail. All this is possible for GSS-EAP, but it's starting to look kind of complex in terms of generic gss-preauth: 1) We need the KDC to impersonate all RPs in its realm in terms of being an acceptor for the GSS preauth mechanism. Clearly possible for EAP but not say for a public-key mechanism. 2) We need standardized context tokens 3) We need keying such that there is some key only the KDC and client know. From Josh.Howlett@ja.net Thu Nov 10 04:19:46 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E39E21F8B3B for ; Thu, 10 Nov 2011 04:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGSiBlTN+hM9 for ; Thu, 10 Nov 2011 04:19:45 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id A191A21F8B06 for ; Thu, 10 Nov 2011 04:19:45 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A5CEC1A9A28E_EBBC15EB; Thu, 10 Nov 2011 12:19:42 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 802E21A9C547_EBBC15EF; Thu, 10 Nov 2011 12:19:42 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 10 Nov 2011 12:19:42 +0000 From: Josh Howlett To: Sam Hartman , Alejandro Perez Mendez Thread-Topic: [abfab] gss-eap preauth as a protocol transition mechanism Thread-Index: AQHMn5yGC6gchoMOREuEi+tMdDrMC5WmBs+A Date: Thu, 10 Nov 2011 12:19:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-krb-wg@anl.gov" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:19:46 -0000 >All this is possible for GSS-EAP, but it's starting to look kind of >complex in terms of generic gss-preauth: What are the practical benefits of a generic gss pre-auth mechanism when Kerberos pre-auth itself provides an extensible framework? I can see that there is value in the re-using deployed gss mechanisms if this avoids having to create functionally-equivalent but redundant pre-auth mechanisms in the case where an equivalent gss mechanism already exists, but are there really so many of these that this is a compelling argument? It sounds as though there is potentially a trade-off that we could make between complexity and generality. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From alex@um.es Thu Nov 10 04:35:09 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444D521F8B3F for ; Thu, 10 Nov 2011 04:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbsNW1NYxgWq for ; Thu, 10 Nov 2011 04:35:08 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 91B6621F8B1F for ; Thu, 10 Nov 2011 04:35:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id CC2B24C2BC; Thu, 10 Nov 2011 13:35:05 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NzVKui7fK11d; Thu, 10 Nov 2011 13:35:04 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id AE7AF4C272; Thu, 10 Nov 2011 13:34:14 +0100 (CET) Message-ID: <4EBBC4C6.2040203@um.es> Date: Thu, 10 Nov 2011 13:34:14 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" , Sam Hartman , "ietf-krb-wg@anl.gov" Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:35:09 -0000 El 10/11/11 13:19, Josh Howlett escribió: >> All this is possible for GSS-EAP, but it's starting to look kind of >> complex in terms of generic gss-preauth: > What are the practical benefits of a generic gss pre-auth mechanism when > Kerberos pre-auth itself provides an extensible framework? I can see that > there is value in the re-using deployed gss mechanisms if this avoids > having to create functionally-equivalent but redundant pre-auth mechanisms > in the case where an equivalent gss mechanism already exists, but are > there really so many of these that this is a compelling argument? It > sounds as though there is potentially a trade-off that we could make > between complexity and generality. Hi Josh, on the first place, to make the KDC Moonshot-enabled you need it to support GSS preauth. You can consider the KDC as another RP withing a realm. On the second place, the use of FAST to protect the transport may result redundant for many authentication mechanism (for example, EAP where no assumptions are made on the security of the transport layer), introducing unnecessary round trips and computational effort (FAST requires a DH to be performed). Note that you can see GSS preauth as an alternative to FAST, not to the Kerberos preauth framework. The latter only defines the guidelines to define preuth mechanisms (which we have followed to define the GSS preauth). Regards, Alejandro > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > From hartmans@painless-security.com Thu Nov 10 05:19:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E6C21F8B39 for ; Thu, 10 Nov 2011 05:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb0yaQswo9cI for ; Thu, 10 Nov 2011 05:19:08 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 607FC21F8AEC for ; Thu, 10 Nov 2011 05:19:08 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C42D82009E; Thu, 10 Nov 2011 08:19:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4EEB9435A; Thu, 10 Nov 2011 08:18:59 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <4EBBC4C6.2040203@um.es> Date: Thu, 10 Nov 2011 08:18:59 -0500 In-Reply-To: <4EBBC4C6.2040203@um.es> (Alejandro Perez Mendez's message of "Thu, 10 Nov 2011 13:34:14 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "ietf-krb-wg@anl.gov" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 13:19:08 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> El 10/11/11 13:19, Josh Howlett escribió: >>> All this is possible for GSS-EAP, but it's starting to look kind >>> of complex in terms of generic gss-preauth: >> What are the practical benefits of a generic gss pre-auth >> mechanism when Kerberos pre-auth itself provides an extensible >> framework? I can see that there is value in the re-using deployed >> gss mechanisms if this avoids having to create >> functionally-equivalent but redundant pre-auth mechanisms in the >> case where an equivalent gss mechanism already exists, but are >> there really so many of these that this is a compelling argument? >> It sounds as though there is potentially a trade-off that we >> could make between complexity and generality. Alejandro> Hi Josh, Alejandro> on the first place, to make the KDC Moonshot-enabled you Alejandro> need it to support GSS preauth. Or define an EAP preauthentication fast factor. Alejandro> You can consider the KDC Alejandro> as another RP withing a realm. On the second place, the Alejandro> use of FAST to protect the transport may result redundant Alejandro> for many authentication mechanism (for example, EAP where Alejandro> no assumptions are made on the security of the transport Alejandro> layer), introducing unnecessary round trips and Alejandro> computational effort (FAST requires a DH to be Alejandro> performed). FAST does not require a DH, especially if it is being used to secure only the path between the RP and KDC. Depending on how a client used it, FAST might require a DH if you run the FAST tunnel from the KDC back to the client. From alex@um.es Thu Nov 10 06:28:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2824A21F8AFD for ; Thu, 10 Nov 2011 06:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akUmzX6u63BJ for ; Thu, 10 Nov 2011 06:28:07 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8269621F8AFE for ; Thu, 10 Nov 2011 06:28:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 77EA75D703; Thu, 10 Nov 2011 15:28:02 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Fjn6hrv-Eu3; Thu, 10 Nov 2011 15:28:01 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id E64F85D44C; Thu, 10 Nov 2011 15:27:53 +0100 (CET) Message-ID: <4EBBDF69.2080602@um.es> Date: Thu, 10 Nov 2011 15:27:53 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4EBBC4C6.2040203@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "ietf-krb-wg@anl.gov" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 14:28:08 -0000 >>>> "Alejandro" == Alejandro Perez Mendez writes: > Alejandro> El 10/11/11 13:19, Josh Howlett escribió: > >>> All this is possible for GSS-EAP, but it's starting to look kind > >>> of complex in terms of generic gss-preauth: > >> What are the practical benefits of a generic gss pre-auth > >> mechanism when Kerberos pre-auth itself provides an extensible > >> framework? I can see that there is value in the re-using deployed > >> gss mechanisms if this avoids having to create > >> functionally-equivalent but redundant pre-auth mechanisms in the > >> case where an equivalent gss mechanism already exists, but are > >> there really so many of these that this is a compelling argument? > >> It sounds as though there is potentially a trade-off that we > >> could make between complexity and generality. > > Alejandro> Hi Josh, > > Alejandro> on the first place, to make the KDC Moonshot-enabled you > Alejandro> need it to support GSS preauth. > > Or define an EAP preauthentication fast factor. I guess you meant GSS-EAP preauthentication fast factor, right? > > Alejandro> You can consider the KDC > Alejandro> as another RP withing a realm. On the second place, the > Alejandro> use of FAST to protect the transport may result redundant > Alejandro> for many authentication mechanism (for example, EAP where > Alejandro> no assumptions are made on the security of the transport > Alejandro> layer), introducing unnecessary round trips and > Alejandro> computational effort (FAST requires a DH to be > Alejandro> performed). > > FAST does not require a DH, especially if it is being used to secure > only the path between the RP and KDC. > Depending on how a client used it, FAST might require a DH if you run > the FAST tunnel from the KDC back to the client. But I was talking about using Moonshot as the authentication mechanism for the KDC (as we did in draft-perez-abfab-gss-eap-preauth), thus, you would need anonymous PKINIT to establish an ad-hoc securized channel between the user and the KDC. Regards, Alejandro > From hartmans@painless-security.com Thu Nov 10 06:47:16 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E772C21F888A for ; Thu, 10 Nov 2011 06:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbdY8AmaeJND for ; Thu, 10 Nov 2011 06:47:16 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 21A7921F8880 for ; Thu, 10 Nov 2011 06:47:16 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B2B3D20244; Thu, 10 Nov 2011 09:48:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 53019435A; Thu, 10 Nov 2011 09:47:13 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <4EBBC4C6.2040203@um.es> <4EBBDF69.2080602@um.es> Date: Thu, 10 Nov 2011 09:47:13 -0500 In-Reply-To: <4EBBDF69.2080602@um.es> (Alejandro Perez Mendez's message of "Thu, 10 Nov 2011 15:27:53 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf-krb-wg@anl.gov" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 14:47:17 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >> Alejandro> on the first place, to make the KDC Moonshot-enabled you Alejandro> need it to support GSS preauth. >> >> Or define an EAP preauthentication fast factor. Alejandro> I guess you meant GSS-EAP preauthentication fast factor, Alejandro> right? No. Any preauth mechanism is a FAST factor. So if there is a GSS preauth there is a GSS and thus GSS-EAP FAST factor. I mean go back to a model where it's EAP between the RP and KDC not GSS. I've been thinking more about this. It's obvious to me that we don't want to use the same GSS-EAP context between the client and RP that we do between the RP and KDC, even if we use the same EAP conversation. My rationale is a bit complicated. One of the big reasons is that the question of which enctype to use, what GSS-EAP features to use etc should depend on the RP capabilities not on the KDC capabilities. Also, (and perhaps this is what Nico's getting at) it simplifies GSS channel binding between the client and RP. This doesn't mean we can't use GSS-PREAUTH; it just means using GSS-PREAUTH is kind of complicated. So, like Josh, I'm beginning to ask what GSS buys us in preauthentication? From rafa@um.es Thu Nov 10 09:14:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB2821F8B89 for ; Thu, 10 Nov 2011 09:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTyRMCt0TpMf for ; Thu, 10 Nov 2011 09:14:44 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id F2DF121F8B8A for ; Thu, 10 Nov 2011 09:14:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 9B1005D70F; Thu, 10 Nov 2011 18:14:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YZVKmYx+227e; Thu, 10 Nov 2011 18:14:39 +0100 (CET) Received: from inf-205-239.inf.um.es (inf-205-239.inf.um.es [155.54.205.239]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id 56D375D70A; Thu, 10 Nov 2011 18:14:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 10 Nov 2011 18:14:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7967B1BD-A12C-410B-BEE6-04FEBD3C7E78@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: ietf-krb-wg@anl.gov, abfab@ietf.org Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:14:45 -0000 Hi Sam: I have some comments below. El 09/11/2011, a las 21:53, Sam Hartman escribi=F3: >=20 > [I think this is a Kerberos discussion mostly, but consider keeping > abfab in your reply if your discussion fits the abfab list.] >=20 > A month or so ago, I promised to write up a use case in response to an > abfab discussion having to do with obtaining a Kerberos ticket as a = side > effect of a gss-eap preauthentication. >=20 >=20 > As background, Microsoft has a Kerberos mechanism called protocol > transition. The idea is that a service authenticates someone using a > non-Kerberos means. However, that service still wants to know what = the > authorization characteristics of that user are. > In the Microsoft model, the KDC/directory are always responsible for > domain level authorization. > In order to obtain authorization information you need a security = token; > to get one of those in a domain you generally need a Kerberos PAC. >=20 > There's a lot going for this model. It centralizes policy for the RP > organization in one place: the domain controller for the resource > domain. >=20 > We had several discussions at the MIT Kerberos Consortium's conference > last year about how valuable this is, and about how if we can maintain > this in the federated context, Kerberos could be an important policy > mechanism for the cloud. >=20 > I'd like Moonshot (the GSS-EAP implementation I'm working on) to be = able > to support this model. >=20 > One thing we can do is just use protocol transition as it's specified = in > Microsoft's extensions today. > You do a GSS-EAP authentication to the RP, the RP asks the KDC for a > ticket, life goes on. What kind of ticket would the RP request? The ticket is for the RP = right?. So some trust between the KDC and the RP is required. >=20 > The problem with this is that protocol transition is relatively weak > from a security standpoint. The service makes an assertion to the KDC > that authentication happened. > This can be a privacy exposure to a certain extent: the service needs = to > be trusted to obtain authorization information for any user who might > authenticate to it regardless of whether they have. Microsoft has > accepted this; some environments may not. At first sight, the Microsoft's model sounds reasonable to me. The = reason is that the RP belongs to the same domain as the resource = controller. Unless you consider them in two different domains or there = is an assumption where the RP might be attacked or may be impersonated = in some easy way. On the other hand, I was wondering why the RP is trusted to receive any = information about the user even when a different party (home AAA server) = tells the KDC that user is authenticated. The only thing I believe you = avoid with this alternative way is that a RP out of control requests = authorization information for non-present or non-authenticated users. Is = that what you want to avoid? >=20 > Another problem is that the resource domain controller may not have = the > information needed to construct authorization information in a GSS-EAP > federation. SAML or RADIUS or Diameter information may be > necessary. Now, the KDC could trust the service to disclose the > information, or could possibly rely on SAML signatures. >=20 > Trusting the service that much seems a big stretch. >=20 > Relying on SAMl signatures viloates the one-trust-infrastructure = design > principle. In particular, it's generally a bad idea for a security > system to force deployers to set up more than one trust infrastructure > because those are very expensive. If we're using GSS-EAP we already = have > AAA trust. We should use that. >=20 > so, somehow, we need to get the KDC as a trusted intermediary in the > GSS-EAP authentication. >=20 > Note that we don't want to depend on any particular initiator > functionality. the RP needs to interact with the KDC for its own > purposes regardless of whether the initiator has ever heard of = Kerberos. >=20 > I had originally thought about an EAP pre-authentication mechanism to > accomplish this goal. The idea is that gss-eap would take EAP packets > out of its incoming tokens and send them to the KDC as part of a > fast-armored AS-request. The client would be ambiguous--somehow > determined by preauth and the service would be the RP. The service > would not learn the MSK, but could be told the GMSK (GSS-EAP key). Basically what it is described here is a protocol to transport EAP = between the RP and the KDC. am I correct?. Moreover it seems that the = KDC is acting as a AAA proxy where the transport between the RP and KDC = is based on Kerberos. Btw, who is the EAP authenticator here? Apparently, it is still the RP = however the MSK does not arrive to the authenticator but to another = entity different to the authenticator. AFAIK, RFC 5247 assumes that MSK = will reach the authenticator. >=20 > If I could figure out a way to do this with gss-preauth and gss-eap = then > I'd support gss-preauth. >=20 >=20 > Conceptually, I guess what's going on here is that you want to export = a > context from the KDC and import it on the RP. However, we don't want = to > expose the MSK to the RP so that if we are doing something that = exposes > a TGT to the initiator we have a key to use. Another possibility is that the key you do not want to export to RP is = based on some key derived from the EMSK and allow the MSK to reach the = RP. >=20 > So, this involves probably some changes to GSS-EAP and to the preauth > type. GSS-EAP probably needs to gain a standardized exported context > and the GSS preauth needs to gain a way to transfer an exported = context > token if the mechanism supports the appropriate attribute. > Or something like that. >=20 > I'd appreciate comments on this use case and once we understand the = use > case I'd like to talk about mechanisms for getting there. Under my point of view (maybe wrong) this imply the definition of a new = backend protocol to transport EAP, despite in general we already have = RADIUS and Diameter for that purpose. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Thu Nov 10 09:15:28 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534D921F8B90 for ; Thu, 10 Nov 2011 09:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkXZcWA5hG+7 for ; Thu, 10 Nov 2011 09:15:27 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F921F8B89 for ; Thu, 10 Nov 2011 09:15:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id A74CA5D70E; Thu, 10 Nov 2011 18:15:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jpXrzxo+85l3; Thu, 10 Nov 2011 18:15:26 +0100 (CET) Received: from inf-205-239.inf.um.es (inf-205-239.inf.um.es [155.54.205.239]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id C5C8E5D70A; Thu, 10 Nov 2011 18:15:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 10 Nov 2011 18:15:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B9EAF5F-22FE-48E4-BB75-F3CD636A9873@um.es> References: <4EBBC4C6.2040203@um.es> <4EBBDF69.2080602@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: "ietf-krb-wg@anl.gov" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:15:28 -0000 Hi Sam: Let me answer this one as well. El 10/11/2011, a las 15:47, Sam Hartman escribi=F3: >>>>>> "Alejandro" =3D=3D Alejandro Perez Mendez writes: >=20 >>>=20 > Alejandro> on the first place, to make the KDC Moonshot-enabled you > Alejandro> need it to support GSS preauth. >>>=20 >>> Or define an EAP preauthentication fast factor. >=20 > Alejandro> I guess you meant GSS-EAP preauthentication fast factor, > Alejandro> right? >=20 > No. > Any preauth mechanism is a FAST factor. > So if there is a GSS preauth there is a GSS and thus GSS-EAP FAST > factor. >=20 > I mean go back to a model where it's EAP between the RP and KDC not = GSS. So indeed we would be defining a new type of backend transport protocol = for EAP based on Kerberos >=20 > I've been thinking more about this. It's obvious to me that we don't > want to use the same GSS-EAP context between the client and RP that we > do between the RP and KDC, even if we use the same EAP conversation. = My > rationale is a bit complicated. One of the big reasons is that the > question of which enctype to use, what GSS-EAP features to use etc > should depend on the RP capabilities not on the KDC capabilities. = Also, > (and perhaps this is what Nico's getting at) it simplifies GSS channel > binding between the client and RP. >=20 > This doesn't mean we can't use GSS-PREAUTH; it just means using > GSS-PREAUTH is kind of complicated. > So, like Josh, I'm beginning to ask what GSS buys us in > preauthentication? Let me clarify one aspect about GSS-PREAUTH in Kerberos = (http://tools.ietf.org/html/draft-perez-krb-wg-gss-preauth-00). The idea = we had when designing GSS preauth in Kerberos is to provide a flexible = pre-authentication mechanism for Kerberos based on the multiple = mechanism that GSS-API could offer (in particular, the GSS-EAP mechanism = can be used as we described in = http://tools.ietf.org/html/draft-perez-abfab-eap-gss-preauth-00). In = fact, this flexibility was one the advantages we mentioned with respect = to the use of EAP packets directly as pre-authentication data in = Kerberos, which, by the way, we also described some time ago = (http://www.ietf.org/mail-archive/web/abfab/current/msg00040.html).=20 Obviously, the goal of our work is to define a flexible = pre-authentication mechanism for Kerberos, but not a transport for EAP = in the backend side of the acceptor/authenticator. However, I understand = that if the same concept might be used it would really nice but, as I = said, goals are completely different under my point of view. Best regards. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From leifj@mnt.se Sun Nov 13 19:31:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF23F11E8192 for ; Sun, 13 Nov 2011 19:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5cvEqXjR+hp for ; Sun, 13 Nov 2011 19:31:27 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D303311E8160 for ; Sun, 13 Nov 2011 19:31:26 -0800 (PST) Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAE3VJWI012952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Nov 2011 04:31:25 +0100 (CET) Message-ID: <4EC08B86.3080704@mnt.se> Date: Mon, 14 Nov 2011 04:31:18 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] gss-eap preauth as a protocol transition mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:31:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Speaking strictly as an individual... > Relying on SAMl signatures viloates the one-trust-infrastructure > design principle. In particular, it's generally a bad idea for a > security system to force deployers to set up more than one trust > infrastructure because those are very expensive. If we're using > GSS-EAP we already have AAA trust. We should use that. Not getting into any of the other points, arguably SAML trust infra- structure is much more widely deployed than AAA infrastructure in the environments where KDCs are widely deployed. Also I've yet to see a practical example of the single trust-infra- structure principle applied. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Ai4YACgkQ8Jx8FtbMZncJcwCZAfSpdo5/ELSy1/9k0tvSw/c7 2+UAoLBPzXnF7EzAP+3iNlllP1XUt8sd =f+Mg -----END PGP SIGNATURE----- From hartmans@mit.edu Wed Nov 16 00:06:04 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B134F11E81F5 for ; Wed, 16 Nov 2011 00:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5-3oujypez7 for ; Wed, 16 Nov 2011 00:06:04 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4122E11E81F4 for ; Wed, 16 Nov 2011 00:06:01 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-51cb.meeting.ietf.org [130.129.81.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BCFB920CDB; Wed, 16 Nov 2011 03:06:39 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1BA67435A; Wed, 16 Nov 2011 03:05:57 -0500 (EST) From: Sam Hartman To: Alexey Melnikov References: <4E75ACD5.5000104@isode.com> Date: Wed, 16 Nov 2011 03:05:56 -0500 In-Reply-To: <4E75ACD5.5000104@isode.com> (Alexey Melnikov's message of "Sun, 18 Sep 2011 09:33:25 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 08:06:04 -0000 Hi. I seem to have missed these review comments. Many have been addressed already, but some have not. Expect a confirmination when I believe I've addressed them. My apology for failing to deal with this before IETF. From leifj@sunet.se Thu Nov 17 03:17:24 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F293A21F9BB2 for ; Thu, 17 Nov 2011 03:17:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYR-0obThrkU for ; Thu, 17 Nov 2011 03:17:17 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2F221F9B81 for ; Thu, 17 Nov 2011 03:17:15 -0800 (PST) Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAHBH3iZ019562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Nov 2011 12:17:12 +0100 (CET) Message-ID: <4EC4ED2C.6030805@sunet.se> Date: Thu, 17 Nov 2011 12:17:00 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] slides for tomorrows meeting X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:17:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 are now up on https://datatracker.ietf.org/meeting/82/materials.html Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7E7SwACgkQ8Jx8FtbMZncK2ACfUOHcx5u0XEdXsuN8W2hqr1DQ w6UAn1KT8yMdTa45gJC3sPx13I0ZCKY/ =0ATO -----END PGP SIGNATURE----- From hartmans@mit.edu Fri Nov 18 03:56:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1D821F8B0B for ; Fri, 18 Nov 2011 03:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XzJfT4oL2d9 for ; Fri, 18 Nov 2011 03:56:26 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E224321F8B02 for ; Fri, 18 Nov 2011 03:56:25 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [203.69.99.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3035421149 for ; Fri, 18 Nov 2011 06:57:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F26FA435E; Fri, 18 Nov 2011 06:55:35 -0500 (EST) To: abfab@ietf.org From: Sam Hartman Message-Id: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> Date: Fri, 18 Nov 2011 06:55:35 -0500 (EST) Subject: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:56:26 -0000 Jim has requested that the acceptor always return an acceptor name token to the client even if the client sends an expected acceptor name token to the acceptor. The idea is that if the client sends something like smtp the acceptor could return smtp@mail.example.com. The advantage here is that the client gains a more complete form of the acceptor name. In the meeting today I said there were no disadvantages besides a few octets. Turns out that's not quite true. The client now needs to confirm that the received name is acceptable. Implementing that is a tad tricky but certainly doable. I support this change but would like to call for comments. From hartmans@mit.edu Fri Nov 18 03:56:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43F721F8B0B for ; Fri, 18 Nov 2011 03:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8UKQ+R0RsTZ for ; Fri, 18 Nov 2011 03:56:26 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 65DD921F8B02 for ; Fri, 18 Nov 2011 03:56:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [203.69.99.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BFE412114C for ; Fri, 18 Nov 2011 06:57:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 70EF8435C; Fri, 18 Nov 2011 06:52:26 -0500 (EST) To: abfab@ietf.org From: Sam Hartman Message-Id: <20111118115226.70EF8435C@carter-zimmerman.suchdamage.org> Date: Fri, 18 Nov 2011 06:52:26 -0500 (EST) Subject: [abfab] Silence means concent: changes to gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:56:26 -0000 Hi. In the meeting today we got to a few issues where the chairs asked me to inform the list that unless there are objections we're making the changes: 1) Moving to RFC 3961 MIC tokens 2) Adopting the internationalization strategy discussed on slides today. Roughly, we will give guidance regarding portions of our name types that are hostnames or usernames; people feeding hostnames to us should make sure they comply with IDNA. Servers MAY compare them in an IDNA-sensitive manner as part of the acceptor name attributes we are preparing. We'll coordinate with RADIUS folks (read Alan) to figure out what to say about RADIUS username attributes. It's my understanding that applications ADs are OK with this strategy and strongly suggest that since most of our identifiers are not user input we adopt a minimalist strategy regarding i18n. 3) Moving to RADIUS attributes from draft-ietf-radext-radius-extensions 4) Plugging in the OIDs from the OID registry after the EAP round trip issue is resolved. From ietf@augustcellars.com Fri Nov 18 05:46:46 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46A421F8B3B for ; Fri, 18 Nov 2011 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV4RHUKE-KKR for ; Fri, 18 Nov 2011 05:46:46 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54C3421F8AFD for ; Fri, 18 Nov 2011 05:46:46 -0800 (PST) Received: from Tobias (unknown [203.69.99.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 789D42CA26; Fri, 18 Nov 2011 05:46:43 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> In-Reply-To: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> Date: Fri, 18 Nov 2011 21:46:09 +0800 Message-ID: <004f01cca5f8$70815ba0$518412e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGPar1g4fu8LE0FNJ1lD9BkyqQBFJYtGr/Q Content-Language: en-us Subject: Re: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 13:46:46 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Friday, November 18, 2011 7:56 PM > To: abfab@ietf.org > Subject: [abfab] GSS EAP: Acceptor Name all the time > > > Jim has requested that the acceptor always return an acceptor name token > to the client even if the client sends an expected acceptor name token to the > acceptor. The idea is that if the client sends something like smtp the > acceptor could return smtp@mail.example.com. > > The advantage here is that the client gains a more complete form of the > acceptor name. > > In the meeting today I said there were no disadvantages besides a few > octets. > Turns out that's not quite true. > The client now needs to confirm that the received name is acceptable. > Implementing that is a tad tricky but certainly doable. While it is true that the client can confirm that the received name is acceptable, I think that for the most part this could be considered to be a NOP as the name returned SHOULD be a more detailed version of the name the client sent up. That is if the client asks for "smtp" then the server MUST NOT return "xmpp@mail.example.com" as this would be something that would never be expected. If the client does not do the validation, then it can send its version of the name as part of the channel bindings and let the EAP server worry about the comparisons. IN that case it will be no worse than it is today. Jim > > I support this change but would like to call for comments. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Fri Nov 18 05:58:47 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AE221F87E2 for ; Fri, 18 Nov 2011 05:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw0ciqyqzpzE for ; Fri, 18 Nov 2011 05:58:47 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0321F87D6 for ; Fri, 18 Nov 2011 05:58:46 -0800 (PST) Received: by us.padl.com with ESMTP id pAIDwg4V017954; Fri, 18 Nov 2011 08:58:44 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20111118115226.70EF8435C@carter-zimmerman.suchdamage.org> Date: Sat, 19 Nov 2011 00:58:41 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111118115226.70EF8435C@carter-zimmerman.suchdamage.org> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Silence means concent: changes to gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 13:58:47 -0000 > 1) Moving to RFC 3961 MIC tokens +1 > 3) Moving to RADIUS attributes from = draft-ietf-radext-radius-extensions I agree this is more elegant, particularly for fragmented attributes. = OTOH it may make it may restrict the use of existing RADIUS client = implementations (although, I suppose, as extended attributes are still = valid RADIUS attributes, it could be implemented by the mechanism = itself). -- Luke= From weiyinxing@gmail.com Fri Nov 18 17:44:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214BD1F0C59 for ; Fri, 18 Nov 2011 17:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPAM_DOMN0b=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 003TGkxc+hdi for ; Fri, 18 Nov 2011 17:44:52 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAF71F0C3B for ; Fri, 18 Nov 2011 17:44:52 -0800 (PST) Received: by ggeq3 with SMTP id q3so1883911gge.31 for ; Fri, 18 Nov 2011 17:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=FG9IgQaE6p6Dft3QiJxnF9w7I4Isus9oqUEQw21KIHE=; b=O7I99dwc1NMOqAhEOfv3PlcoyVNcyTZ1888SdhKpeKpa+Z+kQY3YQL1qM8mmHLmNbx ZF30/ew3Vjbbue2NRLcAegWB8gJ7hHRaJlQNNnjmttK0aCdrpMGjtGB+IDkDWLi3pa5U 7Qc8lH4Za6AePUOMHZ1txgFVqkjbrAJiLKGM8= Received: by 10.236.161.193 with SMTP id w41mr8838131yhk.93.1321667089510; Fri, 18 Nov 2011 17:44:49 -0800 (PST) Received: from 220-137-253-21.dynamic.hinet.net (220-137-253-21.dynamic.hinet.net. [220.137.253.21]) by mx.google.com with ESMTPS id c10sm3399792yhj.2.2011.11.18.17.44.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 17:44:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10--237507254 From: weiyinxing In-Reply-To: Date: Sat, 19 Nov 2011 09:44:36 +0800 Message-Id: <6264151D-EEC3-458A-B5B7-F4FBEEA4A515@gmail.com> References: To: Rhys Smith X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Soliciting use cases... X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 01:44:53 -0000 --Apple-Mail-10--237507254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Rhys The IETF Taipei's meeting is closed now. When will you post the = revised version which includes cross-layer access use cases? Hope it = will happen soon. ----------------- Yinxing Wei =20 On 2011-11-3, at =E4=B8=8A=E5=8D=883:21, Rhys Smith wrote: > So, I've made some more wording changes to tidy the doc and I've added = the Cross Layer Access use case, as discussed in the other thread. = Obviously can't post the new version as submission is closed now until = post Taipei. >=20 > For now though, I'm still looking for some use case text on how abfab = could help the following (these have been mentioned in the past): > * SIP > * PLASMA > * Trust Router > * Anything else you can think of! >=20 > If anyone fancies writing a few paragraphs for how they think abfab = could help these technologies, or anything else you can think of, those = would be gratefully received (I don't know these areas well enough to = write them up myself). I'm happy to accept extremely draft text (on or = off-list) and work with you to tidy it up and flesh it out, if you have = ideas but not the time or inclination to write something properly... >=20 > Kind Regards, > Rhys. > -- > Dr Rhys Smith: Identity, Access, and Middleware Specialist > Cardiff University & JANET(UK) >=20 > email: smith@cardiff.ac.uk / rhys.smith@ja.net > GPG: 0xDE2F024C >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail-10--237507254 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Rhys

   The IETF Taipei's meeting is closed = now. When will you post the revised version which includes cross-layer = access use cases? Hope it will happen = soon.

-----------------
Yinxing Wei =    

On 2011-11-3, at =E4=B8=8A=E5=8D=883= :21, Rhys Smith wrote:

So, I've made some more wording = changes to tidy the doc and I've added the Cross Layer Access use case, = as discussed in the other thread. Obviously can't post the new version = as submission is closed now until post Taipei.

For now though, I'm = still looking for some use case text on how abfab could help the = following (these have been mentioned in the past):
* = SIP
* PLASMA
* Trust Router
* Anything = else you can think of!

If anyone fancies = writing a few paragraphs for how they think abfab could help these = technologies, or anything else you can think of, those would be = gratefully received (I don't know these areas well enough to write them = up myself). I'm happy to accept extremely draft text (on or off-list) = and work with you to tidy it up and flesh it out, if you have ideas but = not the time or inclination to write something = properly...

Kind = Regards,
Rhys.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

_______________________________________________
abfab = mailing list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

= --Apple-Mail-10--237507254-- From ietf@augustcellars.com Sun Nov 20 13:46:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081B221F8797 for ; Sun, 20 Nov 2011 13:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAj7hmKgFB2w for ; Sun, 20 Nov 2011 13:46:56 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8C87421F8663 for ; Sun, 20 Nov 2011 13:46:56 -0800 (PST) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id BD9502CA11; Sun, 20 Nov 2011 13:46:55 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> In-Reply-To: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> Date: Sun, 20 Nov 2011 13:46:22 -0800 Message-ID: <014f01cca7cd$da334870$8e99d950$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGPar1g4fu8LE0FNJ1lD9BkyqQBFJYwxe1g Content-Language: en-us Subject: Re: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 21:46:57 -0000 Another advantage of this proposal is for re-connections. It would be possible to connect to an arbitrary server the first time and be more specific about the server the next time you connect as you might have cached some tokens for doing the reconnect. You want to know who to reconnect to the second time around. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Friday, November 18, 2011 3:56 AM > To: abfab@ietf.org > Subject: [abfab] GSS EAP: Acceptor Name all the time > > > Jim has requested that the acceptor always return an acceptor name token > to the client even if the client sends an expected acceptor name token to the > acceptor. The idea is that if the client sends something like smtp the > acceptor could return smtp@mail.example.com. > > The advantage here is that the client gains a more complete form of the > acceptor name. > > In the meeting today I said there were no disadvantages besides a few > octets. > Turns out that's not quite true. > The client now needs to confirm that the received name is acceptable. > Implementing that is a tad tricky but certainly doable. > > I support this change but would like to call for comments. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nico@cryptonector.com Sun Nov 20 13:54:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DEF1F0C53 for ; Sun, 20 Nov 2011 13:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8Mdj0pxRchh for ; Sun, 20 Nov 2011 13:54:12 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 157221F0C51 for ; Sun, 20 Nov 2011 13:54:12 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id A67953B806A for ; Sun, 20 Nov 2011 13:54:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=M60E86uD1+7DXLfhwG9pb 5vjJ0HULDIzDW23cMNjj469rUZ788PBNY6vaIZ/iZ8FZ90AOoobWYdoXf2KkgInJ fzlc1DBj6OU0D9DfV5a4MbwkRjVUX0hPhkBSZCOyP5uouxB8IzmKcROwY/BeAVMB nr/mT7c6T34Pwn8SKIqDcY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3C4nUT7JbimYiHD+mOQm k/rC0Uk=; b=FYKFB5CiVMOP4NSbKBPmTdxGmq5TGWrMwyQ/96RM2SAX6s0KMti/ sFlddIwSAGiXYTkK8XkPqUrsi7yd5DloDl6KR0GbQkWdR4h+jT16inRCpBA7da3E 5G5kVCFRjb53w6yFEitfcEtGPF72mNTNQy4xeWV3uUReUv8UVXduyrE= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 802B93B8069 for ; Sun, 20 Nov 2011 13:54:11 -0800 (PST) Received: by yenm7 with SMTP id m7so1767172yen.31 for ; Sun, 20 Nov 2011 13:54:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.10.138 with SMTP id i10mr25523570pbb.92.1321826050536; Sun, 20 Nov 2011 13:54:10 -0800 (PST) Received: by 10.68.192.70 with HTTP; Sun, 20 Nov 2011 13:54:10 -0800 (PST) In-Reply-To: <014f01cca7cd$da334870$8e99d950$@augustcellars.com> References: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> <014f01cca7cd$da334870$8e99d950$@augustcellars.com> Date: Sun, 20 Nov 2011 15:54:10 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 21:54:13 -0000 I like the ability to canonicalize target names during security context establishment, particularly when target_name == GSS_C_NO_NAME. The idea that a name could be wildcarded is neat, but not really necessary since the client could just use target_name == GSS_C_NO_NAME then do the matching on the actual target name (obtained with GSS_Inquire_context()). Ah, but if the acceptor is using GSS_C_NO_CREDENTIAL and has credentials for lots of names including host-based service names for lots of services... then the selected target name may not match the initiator's desired service name. To add wildcarding to the API would require some additional work at the API level (mainly in the form of new name types, i think), but it could be done. I'd be OK with it. Nico -- From jimsch@augustcellars.com Sun Nov 20 13:51:32 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BFC1F0C51 for ; Sun, 20 Nov 2011 13:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3PE2FzTBxzM for ; Sun, 20 Nov 2011 13:51:32 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 60E491F0C34 for ; Sun, 20 Nov 2011 13:51:32 -0800 (PST) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2E77038F08; Sun, 20 Nov 2011 13:51:32 -0800 (PST) From: "Jim Schaad" To: Date: Sun, 20 Nov 2011 13:50:59 -0800 Message-ID: <015001cca7ce$7ef0beb0$7cd23c10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcynzeT0bQRAP1AdS7qCnZtuwYFOyA== Content-Language: en-us X-Mailman-Approved-At: Sun, 20 Nov 2011 22:55:12 -0800 Cc: abfab@ietf.org Subject: [abfab] SAML Request/Response X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 21:51:32 -0000 Josh, You said something at the last meeting that took me a couple of days to process and figure out that I might have some type of problem. I really would like to be able to send SAML request messages after the EAP has completed. However there are situations where it might not be feasible and I think this needs to be discussed. If the acceptor is not told the identity of the client, then it would be unable to send a SAML request at a later point in time. If the request is sent along with the EAP conversation, then the EAP server knows the identity of the client. However after the EAP conversation has finished, I would not expect the EAP server to send a state token to allow for a continuation of the conversation. In order to deal with this case, it may be that the EAP server will need to provide an anonymous identity to the acceptor that it can later correlate back to the actual identity of the client. Such a provider could be an encrypted token. Jim From Josh.Howlett@ja.net Mon Nov 21 00:28:05 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D321F8B0D for ; Mon, 21 Nov 2011 00:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-dVo02MCeIW for ; Mon, 21 Nov 2011 00:28:05 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4221C21F8B0A for ; Mon, 21 Nov 2011 00:28:04 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C06891A9A283_ECA0B91B; Mon, 21 Nov 2011 08:28:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 9A58D1A9A265_ECA0B91F; Mon, 21 Nov 2011 08:28:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Mon, 21 Nov 2011 08:28:01 +0000 From: Josh Howlett To: Jim Schaad Thread-Topic: SAML Request/Response Thread-Index: AcynzeT0bQRAP1AdS7qCnZtuwYFOyAAVwQmA Date: Mon, 21 Nov 2011 08:28:00 +0000 Message-ID: In-Reply-To: <015001cca7ce$7ef0beb0$7cd23c10$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <44CE1E67191A22448C7F2E136CBA9A67@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML Request/Response X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 08:28:05 -0000 Jim, >In order to deal with this case, it may be that the EAP server will need >to >provide an anonymous identity to the acceptor that it can later correlate >back to the actual identity of the client. Such a provider could be an >encrypted token. SAML defines a pseudonymous identifier intended for this use case. This vale would be returned to the acceptor at the end of the Abfab Authentication Profile in a SAML authentication assertion. The acceptor could subsequently use this value to name the subject in a subsequent Abfab Assertion Request. Does that work for your use case? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Mon Nov 21 07:43:18 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533F911E80C7 for ; Mon, 21 Nov 2011 07:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNwfP4ONhFkq for ; Mon, 21 Nov 2011 07:43:17 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1552311E80B0 for ; Mon, 21 Nov 2011 07:43:11 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2BF8D20D9B; Mon, 21 Nov 2011 10:43:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3A8F8435A; Mon, 21 Nov 2011 10:43:09 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <015001cca7ce$7ef0beb0$7cd23c10$@augustcellars.com> Date: Mon, 21 Nov 2011 10:43:09 -0500 In-Reply-To: <015001cca7ce$7ef0beb0$7cd23c10$@augustcellars.com> (Jim Schaad's message of "Sun, 20 Nov 2011 13:50:59 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] SAML Request/Response X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:43:18 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> In order to deal with this case, it may be that the EAP server Jim> will need to provide an anonymous identity to the acceptor that Jim> it can later correlate back to the actual identity of the Jim> client. Such a provider could be an encrypted token. Right. I think this is the way to handle later attribute queries. From hartmans@painless-security.com Mon Nov 21 07:45:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF3F11E80C7 for ; Mon, 21 Nov 2011 07:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6BjzNqPdXqT for ; Mon, 21 Nov 2011 07:45:50 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 36D1311E80B0 for ; Mon, 21 Nov 2011 07:45:50 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3CFC520D9B; Mon, 21 Nov 2011 10:46:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5070F435A; Mon, 21 Nov 2011 10:45:48 -0500 (EST) From: Sam Hartman To: Nico Williams References: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> <014f01cca7cd$da334870$8e99d950$@augustcellars.com> Date: Mon, 21 Nov 2011 10:45:48 -0500 In-Reply-To: (Nico Williams's message of "Sun, 20 Nov 2011 15:54:10 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:45:50 -0000 >>>>> "Nico" == Nico Williams writes: Nico> To add wildcarding to the API would require some additional Nico> work at the API level (mainly in the form of new name types, i Nico> think), but it could be done. I'd be OK with it. Hmm. There's a sort of wild carding present in gss-eap today. In particular, the EAP server is only required to perform channel binding on parts of the name present in the EAP channel binding data from the initiator. so, for example, if the hostname component is absent, any hostname may be supplied by the acceptor. I think this is OK. From nico@cryptonector.com Mon Nov 21 08:09:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E3121F8AEA for ; Mon, 21 Nov 2011 08:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLkaNYYEcuc7 for ; Mon, 21 Nov 2011 08:09:13 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 01DC421F87D3 for ; Mon, 21 Nov 2011 08:09:12 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id BA9E436006F for ; Mon, 21 Nov 2011 08:09:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=crAXvHng+YUFbgHKH709boskSqoNafy+GfUouWD5Tnn7 5kjpNsr8QEk2DDxRN4cob7IMhJbHvrRPtIposBXofcNUS7owizi1V5eGsoPuXwOw MyYwrkQv/+7MFEg8zipGbfpkBsfDuuIDhfAHE19DNiEmzsRpuMCWFYerx0L9Hug= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=EAuI9o6JUlLMmKRVs5P3SBHJtNo=; b=kS8mr1BectF 5wU6Q6IvjhmeHUwx+pUJeRAkoP1zWfpubmENXKXwboPQ40z0tL1/2SmTUYV1jloG 6oSAj0oUqGoNRaRyEAMDm5c8/yojiL/G2I+ON8SZ2qutrxUuHjbkvfvIdcvocmVi j6JGKebbgpkM5pPPNmiff3th2W49byAc= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 8C14E360079 for ; Mon, 21 Nov 2011 08:09:12 -0800 (PST) Received: by ghrr14 with SMTP id r14so3572473ghr.31 for ; Mon, 21 Nov 2011 08:09:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.30.68 with SMTP id q4mr32337693pbh.75.1321891751528; Mon, 21 Nov 2011 08:09:11 -0800 (PST) Received: by 10.68.192.70 with HTTP; Mon, 21 Nov 2011 08:09:11 -0800 (PST) In-Reply-To: References: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> <014f01cca7cd$da334870$8e99d950$@augustcellars.com> Date: Mon, 21 Nov 2011 10:09:11 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:09:17 -0000 On Mon, Nov 21, 2011 at 9:45 AM, Sam Hartman wrote: > Hmm. =C2=A0There's a sort of wild carding present in gss-eap today. =C2= =A0In > particular, the EAP server is only required to perform channel binding > on parts of the name present in the EAP channel binding data from the > initiator. =C2=A0so, for example, if the hostname component is absent, an= y > hostname may be supplied by the acceptor. > I think this is OK. IMO it's OK. The API needs a way to represent this though. I'm not sure that this is an important feature -- it'd be less important if we had proper credential sets. But let's sketch it: - Add a new name-type called GSS_C_NT_HOSTBASED_SERVICE_PATTERN with the same syntax as host-based service names, but that allows either or both the service and hostname to be wildcarded. - Mechanisms that support this will indicate it through GSS_Inquire_names_for_mech(). But I think it'd be preferable instead to say that any mechanism which supports target_name =3D=3D GSS_C_NO_NAME supports wildcarding since the initiator can take the acceptor's chosen name and match the pattern against it. - What to do when GSS_Canonicalize_name() is called on a non-MN of that name type? - When a host-based service name pattern is used as a target name in GSS_Init_sec_context() the acceptor will pick a credential whose desired_name matches the given pattern, else it will fail. The initiator application can see that name by calling GSS_Inquire_context() on the established sec context (or when it's PROT_READY). - Alternatively the initiator use GSS_C_NO_NAME as the target_name and the acceptor uses patterns for credential acquisition so as to have credentials only for the desired sub-set of acceptor names. Hmmm, the complication here is that not all mechanisms can support this mode. If the goal is to wildcard the host portion then I'd rather say that the acceptor must have credentials only for its service (while still using GSS_C_NO_CREDENTIAL) and then the initiator uses GSS_C_NO_NAME for the target and checks the result via GSS_Inquire_context(). Nico -- From klaas@cisco.com Mon Nov 21 08:26:59 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3977521F8BF4 for ; Mon, 21 Nov 2011 08:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV7ehx3y5X2x for ; Mon, 21 Nov 2011 08:26:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8730B21F8BE8 for ; Mon, 21 Nov 2011 08:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=7830; q=dns/txt; s=iport; t=1321892812; x=1323102412; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=XZOgIwxPWwX0xaB73Lv1lOP78ugOK1DLyYWf7BI4B3E=; b=aGJu3XUW82fOeOtbkYMp4E7euLBgJ/P3C6ganHg3qHzmJ6bzkjcS098a x30XslqT1QGI1liT9KhUNCKpgO6j39Gal1x5QYSmNzyQ486knM4ptjQkI CM7um78bD/6JrQ+YPuJxmzgEOsCRdb3IkcQ2FgoQItGd53AFNRaKuGLtJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAIt7yk6tJV2Z/2dsb2JhbABDqjqBBYILASc0OH1CB5xRgSYBnjKJNGMElDySBg X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; d="scan'208";a="37903662" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 21 Nov 2011 16:26:52 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pALGQoQV001109 for ; Mon, 21 Nov 2011 16:26:51 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 17:26:50 +0100 Message-Id: <03826A76-5333-41D0-BABA-5945DACF92B7@cisco.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [abfab] draft minutes for abfab@ietf82 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:26:59 -0000 Hi, with thanks to the note taker and jabber scribes please let me know if anything is not correct. Klaas =3D=3D=3D=3D ABFAB Minutes IETF 82 note taker: Jim Schaad jabber scribe: Josh Howlett, Joe Salowey * Agenda * EAP Applicibility statement Leif: - is the content close to last call ? Stefan Winter - some people violenty disagree. Have covered what was = targed. So happy w/ content Joe Salowey - NEA text is still missing to some degree. Leif: - emu working group disucssion w/ different options on hosting - = in our chater - Stephen - what should we do? Stefan - chainging something fundamental in EAP Stephen Farrell- What dependencies? Sam Hartman - normative dependancy on the core spec Leif - why normative? Sam - core should not be published before this - it is currently not = legal to use EAP this way. States what needs to be done to use EAP beyond net access. Core wants to say how these requirements are met. Klaas - why do you care about how much we need it? Stephen - could be contentious in other working groups - could drag on. Sean Turner - if you cross call last call then I don't have a problem. Sean - does it need to be done at all? Sam -yes Eliot Lear - app doc has been used to say don't do that in the past. = How to we phase this. Sam - as an AD said that you cannot use EAP w/o updating the app = statement. Stephen - have a chat and see what it should be done. Leif - Joe did hum in emu - some consus that they wanted to own the document. Steve/Joe should we ask or say if EMU wants to own then let it Joe - No more natural of a home in EMU - targeted to methods - abfab has bigger need - needs to be large review but no stake in where it gets = done. Leif - dissucss with ADs and then go forward. Joe - would be useful if more things were going to happen - more = guidence for future things makes sense. ACTION - chairs and ADs meet to make a decision. * GSS-EAP Straw Poll - is the internationalization method as given good - sense of room was yes RFC 3961/4121 - plan is to move to the 3961 back - ask for objections on = the list Leif - Sam - please push thread to resolutions and gauge consensus then = the chair will concensus call * GSS-Naming * AAA-SAML Leif - possible to profile to add the feature?=20 Josh - ok to do later Issue - the name of the file contains AAA but only does radius - is that = an issue? Stephen - not an issue Issue - Signatures on the SAML message Eliot - Under what circumstances would a signature be sent where it = would have to be ignored? Josh - RP could chose to rely on the transport Sam - Have signature w/ legacy IdP - NAS does not have trust anchors to validate signature - already have RADIUS to provide integrity. - don't = want to reject assertion that is signed because it cannot be validated, but = would have accepted if unisgned Leif - counter argument on profile - can always write a new profile that required signatures Eliot - Should say both MUST NOT check and SHOULD NOT send for = consistency in the past. Sam - better than MUST NOT send Leif - Easy to strip signatures if needed - really easy to do. Leif - in SAML space - common to separate implementation profile, = deployment profile - Implement must supply or deployment must turn on. - need to = call this out Josh - deployment profile Sam - don't think deployment profile should be a std track document - = need a implementation profile - deployment profile in BCP or arch document. Josh - XML digsig needs restrictions to get interop. Sam - IETF constrain implementations not deployments. Leif - +1 what sam says Stephen - can be one or many hops? - MANY hops Sam - no - hops are integrity protected Hannes - difference between specified and deployed Sam - trusted third party proxy security gets deployed.=20 Payload size Eliot - average size of a SAML transaction? Josh - currently not really known Diego Lopez - compression of assertion? Josh - One binding allows for Leif - 3.5 k for one sample - signed - real issue Jim - Option 1- need to at least error - #2 go to diameter Eliot - sub options #2 - go to diameter Leif - actual attributes were only one K Hannes - using diameter should be ok - good implementations exist. - avoid option #3 - routs around why we did abfab to begin with - fragmentation layer - looks like a real hack - would prefer = TCP/TLS version of radius Sam - two implementations of NCP over radius have 4k limit even on TCP - radius spec is hard coded Diego - option 2 is wisest - but in a federations somebody will break = it. - proxies or deployment of radius=20 Hannes - how much can you actually change? - depends on the specific deployment. Bigger radius deployments are start radius and then go to private version - may not always be an issue. Diego - moment single assertion grows to large means all deployments = need to change Hannes - how far should we bend to deal with existing deployments=20 Klaas - option 3 - should be considered - not talking about applications = but radius server talking to IDP - not same set of problems as what abfab Hannes - work w/ existing AAA structure - both right - Eliot - Lots of homework - size - environment being measured - network = auth vs other uses - some is prognosticating - for an architecture should = assume grossly expensive Leif - will see wide span of number and type of attributes - hard to = predict a small size assume can get really big ELiot - agree option #1 is not an option. - option #4 seems like more = work than revisiting diameter draft Jim - Humongous SAML statements Hannes - what does option #4 look like Josh - have possible to do resolution by reference to identifier - have = mime type and chuck. Sam - think sever only access request Leif - Can combine different options such as 2 and 3. Define a RESTful SAML binding - (already done) Think Diego has a point - any deployment will be unpredictable Stepen - If option #4 means generic then needs to go out of this group. Sam - if not on there - then add radius based mech for doing only SAML assertions generic fragmentation would be painful - would need RADEXT review Jeff Hutzelman - can RPs do the artifact resolving over an arbitrary = large federation? Leif - no - but all solutions add new requirements. Leif - Present updated set of options and have round 2 discussion on the mailing list * abfab arch & Uses Cases Tracker discussion and etiquette * use cases JIM - find the Plasma use cases - somebody agreed to do that Consensus call - should the OID document be a working group document - = Much yes - zero no - one no idea * Multihop Federations & Trust Router Leif - we have a charter item that covers the problem statement. Not = clear that this the only way to skin the cat. Leif - would be willing to review - might give alternative solutions as well. Problem is broader than just ABFAB. Current trust router draft narrows down to a specific model (hub and spoke) very quickly. Good approach to start by having a discussion = around the problems if it were really general. Klaas - Many related options exist (routing prototcols, group management = protocols etc), not clear what unique problem is solved. Margaret - current statement is a motivation for the work not a general = problem statement. Poll - Who is interested in working on the problem statement draft Yes - Leif, Diego, Hannes, Josh, Karen, Jim, Tom Yu No - no hands * Current technical Issues - 3GPP Issues - no discussion in this meeting - continue on the list - Report No consensus for adoption of draft-jones-diameter - no = response. Intend to re-issue.= From hartmans@painless-security.com Mon Nov 21 08:29:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E021F8C0C for ; Mon, 21 Nov 2011 08:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZHDVXVhIW2K for ; Mon, 21 Nov 2011 08:29:41 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 114BB21F8C0A for ; Mon, 21 Nov 2011 08:29:41 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CD1AE20DAD; Mon, 21 Nov 2011 11:30:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D0E8F435A; Mon, 21 Nov 2011 11:29:38 -0500 (EST) From: Sam Hartman To: Nico Williams References: <20111118115535.F26FA435E@carter-zimmerman.suchdamage.org> <014f01cca7cd$da334870$8e99d950$@augustcellars.com> Date: Mon, 21 Nov 2011 11:29:38 -0500 In-Reply-To: (Nico Williams's message of "Mon, 21 Nov 2011 10:09:11 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] GSS EAP: Acceptor Name all the time X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:29:41 -0000 OK. Well, if you have any concerns about the text currently in the draft please raise them. As best I understand what you're saying what the draft says is fine. --Sam From diego@tid.es Fri Nov 25 07:04:33 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3513921F8BB2 for ; Fri, 25 Nov 2011 07:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05Kws8r9gYTx for ; Fri, 25 Nov 2011 07:04:32 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id CB85221F8BAB for ; Fri, 25 Nov 2011 07:04:31 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV800AYV1VA2W@tid.hi.inet> for abfab@ietf.org; Fri, 25 Nov 2011 16:04:29 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 08.C0.21312.FECAFCE4; Fri, 25 Nov 2011 15:57:51 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LV700KC9SI0IP@tid.hi.inet> for abfab@ietf.org; Fri, 25 Nov 2011 12:42:00 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Fri, 25 Nov 2011 12:42:00 +0100 Date: Fri, 25 Nov 2011 12:41:58 +0100 From: DIEGO LOPEZ GARCIA To: "abfab@ietf.org" Message-id: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: 4K limit Thread-index: AcyrZz3FZVz3VcZdSHK0DtYsm6Jkmw== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f1c6d000005340-d3-4ecfacef420b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsXCFe9nqFu57ryfwZKlShYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsxb9xkLJolWLDjTzdbAeEaki5GTQ0LAROLIn3eMELaYxIV7 69m6GLk4hAS2MUqs+3MMyvnBKPFvZgMrhNPIKPF80nsWkBYWAVWJH3MmgNlsAuoSLUe/gdnC AoISfX0b2UFsEaCa888/sIHYvAKWEjtm9rBC2IISPybfA6rn4GAG6p0yJRckzCwgLtHcepMF wlaUmLaoAew6RqDrvp9awwQxUkzixuXTLBC2nsTU/rXsEDWiEnfa10N9IyCxZM95ZghbVOLl 43+sExhFZiHZPAth8ywkm2ch2byAkWUVo1hxUlFmekZJbmJmTrqBkV5Gpl5mXmrJJkZI8Gfu YFy+U+UQowAHoxIP74S55/yEWBPLiitzDzFKcjApifKaLzvvJ8SXlJ9SmZFYnBFfVJqTWnyI UYKDWUmEt7MYqJw3JbGyKrUoHyYlw8GhJMHrMw+oTbAoNT21Ii0zBxjjMGkmDk6Qdh6g9qXL gWp4iwsSc4sz0yHypxglpcR5H4AkBEASGaV5cL2vGMWBjhSGaOMBJiO4rldAA5mABv5ccgZk YEkiQkqqgVFe+ouCyTWHa5NaypcKtPxtPBomW7f8Z9b+1X9MY/sizs+ZGt3xMUfL79Xbs/fM hS1vp94xmWsp2ew0ifGwa9Se5w/eKzdZXQzKqcwRs1/AzyEetch/pZ/0uXMPNkjKMK8RCWz3 l414OT+aW2DH/KraHYLN91UiF83a+CV7Xer8nNNenwyrVZVYijMSDbWYi4oTAchyaPADAwAA Subject: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 15:04:33 -0000 SGksDQoNClRoaW5raW5nIGFib3V0IHRoZSA0SyBsaW1pdCBpbiB0aGUgUkFESVVTIHBheWxvYWQg YW5kIHRoZSBmb3VyIG9wdGlvbnMgb3V0bGluZWQgYnkgSm9zaCBhbmQgdGhlIGRpc2N1c3Npb24g d2UgaGFkIGluIFRhaXBlaSwgSSBndWVzcyB3ZSBjb3VsZCBoYXZlIGEgZmlmdGggb3B0aW9uOiB0 aGUgdXNlIG9mIG11bHRpLXBhY2tldCBSQURJVVMgc2Vzc2lvbnMgdG8gdHJhbnNmZXIgU0FNTCBk YXRhIHdoZW4gdGhlIHBheWxvYWQgbGltaXQgaXMgcmVhY2hlZC4gVGhpcyB3aWxsIGtlZXAgdXMg aW4gUkFESVVTIHNwYWNlIGFuZCBhbGxvdyBmb3IgYXJiaXRyYXJ5IGxvbmcgU0FNTCBtZXNzYWdl cy4gT2YgY291cnNlLCB0aGlzIHdvdWxkIGJlIGFuIG9wdGlvbmFsIGJlaGF2aW9yLCBrZWVwaW5n IHRoZSBjdXJyZW50IChvbmUgU0FNTCBtZXNzYWdlIGluIG9uZSBSQURJVVMgcGFja2V0KSBhcyB0 aGUgZGVmYXVsdCwgbWFuZGF0b3J5LCBvbmUuIFRoaXMgYXBwcm9hY2ggY291bGQgZXZlbiBiZSB1 c2FibGUgaW4gb3RoZXIgcG90ZW50aWFsIGNhc2VzIHdoZXJlIHRoZSA0SyBwYXlsb2FkIGxpbWl0 IG1heSBiZWNvbWUgYW4gaXNzdWUuDQoNCkZyb20gdGhlIFNBTUwgUkFESVVTIGJpbmRpbmcgcG9p bnQgb2YgdmlldyB0aGlzIHdvdWxkIGltcGx5IHRvIGFsbG93IHRoZSB1c2Ugb2Ygc2V2ZXJhbCBT QU1MIG1lc3NhZ2VzLiBJbiBwcmluY2lwbGUsIHNldmVyYWwgQXV0aE4gc3RhdGVtZW50cyByZWxh dGVkIHRvIHRoZSBzYW1lIE5BSSBhbmQgY29udGFpbmluZyB0aGUgY29ycmVzcG9uZGluZyBhdHRy aWJ1dGVzLlRoZSBSQURJVVMgY2xpZW50IC8gU0FNTCBSUCB3b3VsZCBoYXZlIHRvIGRlYWwgd2l0 aCB0aGVtIGFzIGEgc2luZ2xlIHN0YXRlbWVudA0KDQpGcm9tIHRoZSBSQURJVVMgcHJvdG9jb2wg cG9pbnQgb2YgdmlldyBJIHNlZSB0d28gcG9zc2libGUgb3B0aW9uczogbWFraW5nIHRoZSBzZXJ2 ZXIgdG8gc2VuZCBzdWNjZXNzaXZlIEFjY2Vzcy1DaGFsbGVuZ2UgcmVzcG9uc2VzIHdpdGggdGhl IGNvcnJlc3BvbmRpbmcgU0FNTCBtZXNzYWdlcywgb3IgZGVmaW5pbmcgYSBuZXcgUkFESVVTIHBh Y2tldCB0eXBlLiBUaGUgZmlyc3Qgb3B0aW9uIGhhcyB0aGUgYWR2YW50YWdlIG9mIGJlaW5nIGVh c2llciB0byBpbXBsZW1lbnQsIHRob3VnaCBpdCBpbXBsaWVzIHN0cmV0Y2hpbmcgKHByb2JhYmx5 IHRvbyBtdWNoKSB0aGUgc2VtYW50aWNzIG9mIHRoZSBjaGFsbGVuZ2UgbG9vcHMuDQoNClRoZXJl IGlzIG9mIGNvdXJzZSBhIGxvdCB0byBlbGxhYm9yYXRlIHRvIG1ha2UgdGhpcyBhIHZpYWJsZSBz b2x1dGlvbiBhbmQgSSBjYW4gdm9sdW50ZWVyIHRvIHN0YXJ0IHdyaXRpbmcgc29tZXRoaW5nIG1v cmUgZGV0YWlsZWQgaWYgdGhlIGdyb3VwIHRoaW5rcyB0aGlzIGlkZWEgbWFrZXMgYW55IHNlbnNl Lg0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5m aWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KDQplLW1haWw6IGRp ZWdvQHRpZC5lcw0KVGVsOiAgICAgICszNCA5MTMgMTI5IDA0MQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJp Z2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVz dHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25p Y28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRl bmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNl aXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0dHA6Ly93 d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From aland@deployingradius.com Fri Nov 25 07:18:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2418C21F858D for ; Fri, 25 Nov 2011 07:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6scjUgPoWbJ for ; Fri, 25 Nov 2011 07:18:07 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 98A5621F858C for ; Fri, 25 Nov 2011 07:18:06 -0800 (PST) Message-ID: <4ECFB193.40204@deployingradius.com> Date: Fri, 25 Nov 2011 16:17:39 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> In-Reply-To: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 15:18:08 -0000 DIEGO LOPEZ GARCIA wrote: > From the RADIUS protocol point of view I see two possible options: making the server to send successive Access-Challenge responses with the corresponding SAML messages, or defining a new RADIUS packet type. The first option has the advantage of being easier to implement, though it implies stretching (probably too much) the semantics of the challenge loops. It involves some serious changes to RADIUS servers and clients. For this to work at *all*, it would have to be done via Access-Challenge. These will pass through intermediate proxies. Any new RADIUS packet code will be dropped by nearly everyone. > There is of course a lot to ellaborate to make this a viable solution and I can volunteer to start writing something more detailed if the group thinks this idea makes any sense. You'll have to pass it by radext. That review traditionally takes a while. An alternative that's been discussed has been to relax the 4K packet size limit for RADIUS over TCP. TCP doesn't have fragmentation issues like UDP, which makes it easier to increase the packet size. Another alternative is to stop using RADIUS for bulk data transfer. :) Instead, put the data somewhere..., and have the client somehow... get it via another protocol. Alan DeKok. From diego@tid.es Fri Nov 25 15:54:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685CB21F8B16 for ; Fri, 25 Nov 2011 15:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrEufVmhJW-n for ; Fri, 25 Nov 2011 15:54:29 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7676621F8AEC for ; Fri, 25 Nov 2011 15:54:27 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV800ATGQEL2X@tid.hi.inet> for abfab@ietf.org; Sat, 26 Nov 2011 00:54:21 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id B7.B9.21312.CAA20DE4; Sat, 26 Nov 2011 00:54:21 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LV800BMHQEK75@tid.hi.inet> for abfab@ietf.org; Sat, 26 Nov 2011 00:54:20 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Sat, 26 Nov 2011 00:54:20 +0100 Date: Sat, 26 Nov 2011 00:54:19 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4ECFB193.40204@deployingradius.com> To: Alan DeKok Message-id: <8D0DBD77-E5D2-443E-B415-447F2346FE49@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] 4K limit Thread-index: AcyrzYy66YqdE5OwRKyM/nvYP30CpA== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f1c6d000005340-28-4ed02aacfa9d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsXCFe9nqLtW64KfwcSVghYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvqWB6wF06QqFsxcyNjAeECyi5GTQ0LARGLypPuMELaYxIV7 69m6GLk4hAS2MUp8vHyJGcL5wSjxoOMMVKaRUWLB10YWkBYWAVWJCWt+gNlsAuoSLUe/gdnC ArISc45vZwWxOQUMJa6ducsGYosIaEksWL8IrIYZqPftxAVgNbwClhL37s5hhLAFJX5MvgdU wwFUoy4xZUouRLm4RHPrTahWRYlpixrAyhmBrv5+ag0TSLmIgJzEzUUREJv0JCZ/aGODKBGV uNO+HupJAYkle84zQ9iiEi8f/wO7QEggQaJ75R2WCYzis5AcMQvhiFlIjpiF5IgFjCyrGMWK k4oy0zNKchMzc9INjPQyMvUy81JLNjFCYihzB+PynSqHGAU4GJV4eA98Pu8nxJpYVlyZe4hR koNJSZR3vuYFPyG+pPyUyozE4oz4otKc1OJDjBIczEoivKvOAJXzpiRWVqUW5cOkZDg4lCR4 H4K0CRalpqdWpGXmABMFTJqJgxOknQeo/TpIDW9xQWJucWY6RP4Uo6SUOO9dkIQASCKjNA+u 9xWjONCRwrw3QLI8wJQG1/UKaCAT0MCfS86ADCxJREhJNTAy5Ow/cCt0abfjxLbDCjvzAkI/ a07+deA4G+fG6o36hd8/3n93cJMywwWzsxXHflo2vzz15aujSr/p3V3H7vp9NA3ZweEeG6zr JFd388XLbD/BNZbay9p/OZkdzq8qy5n3z7uO+WdIiYRqdMgFhZdH4z4Z61ytXDox+nvrvXAX F+12rlcOj/WVWIozEg21mIuKEwEhoj2xJgMAAA== References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ECFB193.40204@deployingradius.com> Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 23:54:30 -0000 DQpPbiAyNSBOb3YgMjAxMSwgYXQgMTY6MTcgLCBBbGFuIERlS29rIHdyb3RlOg0KPiAgSXQgaW52 b2x2ZXMgc29tZSBzZXJpb3VzIGNoYW5nZXMgdG8gUkFESVVTIHNlcnZlcnMgYW5kIGNsaWVudHMu DQo+DQo+ICBGb3IgdGhpcyB0byB3b3JrIGF0ICphbGwqLCBpdCB3b3VsZCBoYXZlIHRvIGJlIGRv bmUgdmlhDQo+IEFjY2Vzcy1DaGFsbGVuZ2UuICBUaGVzZSB3aWxsIHBhc3MgdGhyb3VnaCBpbnRl cm1lZGlhdGUgcHJveGllcy4gIEFueQ0KPiBuZXcgUkFESVVTIHBhY2tldCBjb2RlIHdpbGwgYmUg ZHJvcHBlZCBieSBuZWFybHkgZXZlcnlvbmUuDQoNClRoYXQncyBhIGdvb2QgcG9pbnQgdG8gbWFr ZSB0aGUgZGVjaXNpb24gZm9yIGEgdHlwZSBvZiBwYWNrZXQuIEFjY2Vzcy1DaGFsbGVuZ2Ugd291 bGQgYmUuDQoNCj4+IFRoZXJlIGlzIG9mIGNvdXJzZSBhIGxvdCB0byBlbGxhYm9yYXRlIHRvIG1h a2UgdGhpcyBhIHZpYWJsZSBzb2x1dGlvbiBhbmQgSSBjYW4gdm9sdW50ZWVyIHRvIHN0YXJ0IHdy aXRpbmcgc29tZXRoaW5nIG1vcmUgZGV0YWlsZWQgaWYgdGhlIGdyb3VwIHRoaW5rcyB0aGlzIGlk ZWEgbWFrZXMgYW55IHNlbnNlLg0KPg0KPiAgWW91J2xsIGhhdmUgdG8gcGFzcyBpdCBieSByYWRl eHQuICBUaGF0IHJldmlldyB0cmFkaXRpb25hbGx5IHRha2VzIGENCj4gd2hpbGUuDQoNCkkgZGlk IG5vdCBob3BlIGl0IHRvIGJlIGEgcXVpY2sgcHJvY2VzcyBhbnl3YXkuIElmIHdlIGRlY2lkZSB0 byBnbyB0aGlzIHdheSB0aGVyZSBhcmUgc29tZSBwYXJ0aWFsIHNvbHV0aW9ucyAobGlrZSByZXF1 ZXN0aW5nIHRoZSBTQU1MIG1lc3NhZ2UgdG8gYmUgY29tcHJlc3NlZCBpbiB0aGUgUkFESVVTIGF0 dHJpYnV0ZSkgdGhhdCB3b3VsZCBidXkgdXMgc29tZSB0aW1lLg0KDQo+ICBBbiBhbHRlcm5hdGl2 ZSB0aGF0J3MgYmVlbiBkaXNjdXNzZWQgaGFzIGJlZW4gdG8gcmVsYXggdGhlIDRLIHBhY2tldA0K PiBzaXplIGxpbWl0IGZvciBSQURJVVMgb3ZlciBUQ1AuICBUQ1AgZG9lc24ndCBoYXZlIGZyYWdt ZW50YXRpb24gaXNzdWVzDQo+IGxpa2UgVURQLCB3aGljaCBtYWtlcyBpdCBlYXNpZXIgdG8gaW5j cmVhc2UgdGhlIHBhY2tldCBzaXplLg0KDQpUaGlzIGFsdGVybmF0aXZlIHdvdWxkIGJlIGlkZWFs LCBhcyBsb25nIGFzDQooMSkgSXQgaXMgbGlrZWx5IHRvIGJlIGFjY2VwdGVkIGFuZCBpbXBsZW1l bnRlZC4NCigyKSBXZSBhcmUgdGFsa2luZyBhYm91dCBub3QgaGF2aW5nIGFueSBwYWNrZXQgc2l6 ZSBsaW1pdCwgd2hhdCBJJ2Qgc2F5IHdvdWxkIG1hdGNoIHdpdGggIlRDUCBzdHlsZSINCldoYXQn cyB5b3Ugb3BpbmlvbiBvbiB0aGlzPyBXb3VsZCBBQkZBQiBoZWxwIGluIGJ1aWxkaW5nIHRoZSBj YXNlIGZvciBpdD8NCg0KPiAgQW5vdGhlciBhbHRlcm5hdGl2ZSBpcyB0byBzdG9wIHVzaW5nIFJB RElVUyBmb3IgYnVsayBkYXRhIHRyYW5zZmVyLiA6KQ0KPiBJbnN0ZWFkLCBwdXQgdGhlIGRhdGEg c29tZXdoZXJlLi4uLCBhbmQgaGF2ZSB0aGUgY2xpZW50IHNvbWVob3cuLi4gZ2V0DQo+IGl0IHZp YSBhbm90aGVyIHByb3RvY29sLg0KDQpUaGlzIGhhcyBiZWVuIHN1Z2dlc3RlZCBhcyBvbmUgb2Yg dGhlIGFsdGVybmF0aXZlcywgc2luY2UgU0FNTCBwcm92aWRlcyB0aGlzIGNhcGFiaWxpdHkgdGhy b3VnaCBzby1jYWxsZWQgYXJ0aWZhY3RzLCBCdXQgdGhlIEFCRkFCIGF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbSBpcyBpbnRlbmRlZCAoYXMgZmFyIGFzIEkgY2FuIHRlbGwpIHRvIGF2b2lkIHRoZSBu ZWVkIG9mIGEgc2Vjb25kIHRydXN0IGZyYW1ld29yayBvdXQgb2YgdGhlIEFBQS4gQW4gYWRkaXRp b25hbCBwcm90b2NvbCB0byBnZXQgYXR0cmlidXRlcyB3b3VsZCByZXF1aXJlIHRoaXMgc2Vjb25k IHRydXN0IGZyYW1ld29yay4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFy ZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJ K0QNCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgICArMzQgOTEzIDEyOSAwNDENCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCg0KDQpFc3Rl IG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVk ZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBj b3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlz IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9u bHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBv dXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From aland@deployingradius.com Sat Nov 26 02:40:59 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E52A21F869E for ; Sat, 26 Nov 2011 02:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1toXa8oxf97 for ; Sat, 26 Nov 2011 02:40:59 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D44A221F867F for ; Sat, 26 Nov 2011 02:40:58 -0800 (PST) Message-ID: <4ED0C21C.4000701@deployingradius.com> Date: Sat, 26 Nov 2011 11:40:28 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ECFB193.40204@deployingradius.com> <8D0DBD77-E5D2-443E-B415-447F2346FE49@tid.es> In-Reply-To: <8D0DBD77-E5D2-443E-B415-447F2346FE49@tid.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 10:40:59 -0000 DIEGO LOPEZ GARCIA wrote: > This alternative would be ideal, as long as > (1) It is likely to be accepted and implemented. There have bee a number of discussions about extending the 4K limit for RADIUS over TCP. So the possibility of acceptance is there. Implementations will follow. > (2) We are talking about not having any packet size limit, what I'd say would match with "TCP style" There will still be a limit of 64K, due to the RADIUS protocol headers. > What's you opinion on this? Would ABFAB help in building the case for it? Yes. Having use-cases means it's easier to standardize something. Alan DeKok. From alex@um.es Mon Nov 28 03:16:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D5C21F8D09 for ; Mon, 28 Nov 2011 03:16:57 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX0JmOLclVYI for ; Mon, 28 Nov 2011 03:16:56 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7E721F8CF6 for ; Mon, 28 Nov 2011 03:16:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id D455653610 for ; Mon, 28 Nov 2011 12:16:50 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wjDrCfl0ws61 for ; Mon, 28 Nov 2011 12:16:50 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id 5F141535C3 for ; Mon, 28 Nov 2011 12:16:49 +0100 (CET) Message-ID: <4ED36DA1.402@um.es> Date: Mon, 28 Nov 2011 12:16:49 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> In-Reply-To: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 11:16:57 -0000 > Hi, > > Thinking about the 4K limit in the RADIUS payload and the four options outlined by Josh and the discussion we had in Taipei, I guess we could have a fifth option: the use of multi-packet RADIUS sessions to transfer SAML data when the payload limit is reached. This will keep us in RADIUS space and allow for arbitrary long SAML messages. Of course, this would be an optional behavior, keeping the current (one SAML message in one RADIUS packet) as the default, mandatory, one. This approach could even be usable in other potential cases where the 4K payload limit may become an issue. > > From the SAML RADIUS binding point of view this would imply to allow the use of several SAML messages. In principle, several AuthN statements related to the same NAI and containing the corresponding attributes.The RADIUS client / SAML RP would have to deal with them as a single statement > > From the RADIUS protocol point of view I see two possible options: making the server to send successive Access-Challenge responses with the corresponding SAML messages, or defining a new RADIUS packet type. The first option has the advantage of being easier to implement, though it implies stretching (probably too much) the semantics of the challenge loops. Hi Diego, all, we have been discussing this topic internally, and we see another alternative for this. We could define a new RADIUS attribute which indicates the total length of the SAML Message to be received (for example, we could call it SAML-Message-Length). This attribute would be included in the first RADIUS message containing SAML-Message attributes. When the RP receives this attribute, it knows how many SAML data is expected from the AAA/IdP and therefore, if the total length of the received SAML-Message attributes is less than expected, it means that the message has been truncated and that more data is to be retrieved. Then the RP would send an Access-Request message to the AAA/IdP requesting more data. The AAA/IdP replies with more SAML-Message attributes. As the RP already knows how many data is to be received, this process is repeated until the whole SAML message has been received. It has to cost of defining a new RADIUS Attribute, but the advantage that it does not modify the RADIUS or SAML protocols. What do you think? Do you think it is reasonable? We could elaborate a more detailed description if you find it interesting. Regards, Alejandro From aland@deployingradius.com Mon Nov 28 04:11:23 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B121F8AEC for ; Mon, 28 Nov 2011 04:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNcTMs6Aj7H9 for ; Mon, 28 Nov 2011 04:11:23 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 59C5D21F8A7B for ; Mon, 28 Nov 2011 04:11:23 -0800 (PST) Message-ID: <4ED37A3E.4020709@deployingradius.com> Date: Mon, 28 Nov 2011 13:10:38 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> In-Reply-To: <4ED36DA1.402@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 12:11:24 -0000 Alejandro Perez Mendez wrote: > we have been discussing this topic internally, and we see another > alternative for this. We could define a new RADIUS attribute which > indicates the total length of the SAML Message to be received (for > example, we could call it SAML-Message-Length). This attribute would be > included in the first RADIUS message containing SAML-Message attributes. That could work. I'm concerned about the possibility of conflict. i.e. the first packet says "10K SAML data", but the total length of the SAML data is != 10K. > When the RP receives this attribute, it knows how many SAML data is > expected from the AAA/IdP and therefore, if the total length of the > received SAML-Message attributes is less than expected, it means that > the message has been truncated and that more data is to be retrieved. It would be simpler I think to just have an attribute saying "more SAML data". If it's in an Access-Accept, the client asks for more data. That means that the processing flow is the same for the first Access-Accept, and for any subsequent Access-Accepts. > Then the RP would send an Access-Request message to the AAA/IdP > requesting more data. The AAA/IdP replies with more SAML-Message > attributes. As the RP already knows how many data is to be received, > this process is repeated until the whole SAML message has been received. That could work... > It has to cost of defining a new RADIUS Attribute, but the advantage > that it does not modify the RADIUS or SAML protocols. There are additional issues not discussed here. How do you tie the packets together? > What do you think? Do you think it is reasonable? We could elaborate a > more detailed description if you find it interesting. What is already done is to use "Service-Type = Authorize-Only". See RFC 5080 for a discussion. - user authenticates - final Access-Accept contains a State attribute - final Access-Accept contains an attribute "more SAML data" - NAS sends new Access-Request (somehow) tied to the original session - this Access-Request contains Service-Type = Authorize Only State from original Access-Accept - server replies with Access-Challenge / Access-Accept - packets contain SAML data - if the reply is an Access-Challenge, the NAS sends another Access-Request Similar things are done already with Access-Request and Authorize-Only. So that behavior falls within the context of existing RADIUS practices. The only new thing here is the use of Access-Challenge in this context. My $0.02 is that this mechanism for transporting bulk authorization data in RADIUS should be defined separately from it's use in SAML. There have been enough requests over the years for this that others will find it useful, too. Alan DeKok. From alex@um.es Mon Nov 28 05:30:22 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29421F8C88 for ; Mon, 28 Nov 2011 05:30:22 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsu9JB8klTfz for ; Mon, 28 Nov 2011 05:30:21 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 211D421F8C7E for ; Mon, 28 Nov 2011 05:30:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 54E4353613; Mon, 28 Nov 2011 14:30:20 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oVIbSBIq1g4k; Mon, 28 Nov 2011 14:30:20 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id C52D65359F; Mon, 28 Nov 2011 14:30:15 +0100 (CET) Message-ID: <4ED38CE7.5070405@um.es> Date: Mon, 28 Nov 2011 14:30:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alan DeKok References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> In-Reply-To: <4ED37A3E.4020709@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 13:30:22 -0000 Hi Alan, thanks for you quick response. Our mail was just a first attempt to provide a solution. I agree that some details were not described, or even thought. See my comments below. > Alejandro Perez Mendez wrote: >> we have been discussing this topic internally, and we see another >> alternative for this. We could define a new RADIUS attribute which >> indicates the total length of the SAML Message to be received (for >> example, we could call it SAML-Message-Length). This attribute would be >> included in the first RADIUS message containing SAML-Message attributes. > That could work. I'm concerned about the possibility of conflict. > i.e. the first packet says "10K SAML data", but the total length of the > SAML data is != 10K. Right, that kind of situations must be avoided. Anyway, the AAA server would discard or send an error message on any Access-Request received when no additional SAML data is to be sent. >> When the RP receives this attribute, it knows how many SAML data is >> expected from the AAA/IdP and therefore, if the total length of the >> received SAML-Message attributes is less than expected, it means that >> the message has been truncated and that more data is to be retrieved. > It would be simpler I think to just have an attribute saying "more > SAML data". If it's in an Access-Accept, the client asks for more data. > That means that the processing flow is the same for the first > Access-Accept, and for any subsequent Access-Accepts. Yes, that would also work. >> Then the RP would send an Access-Request message to the AAA/IdP >> requesting more data. The AAA/IdP replies with more SAML-Message >> attributes. As the RP already knows how many data is to be received, >> this process is repeated until the whole SAML message has been received. > That could work... > >> It has to cost of defining a new RADIUS Attribute, but the advantage >> that it does not modify the RADIUS or SAML protocols. > There are additional issues not discussed here. > > How do you tie the packets together? As you say below, the State attribute would do the work. Additionally, the "more SAML data" could contain a reference, and be included in the following Access-Request message. Though I think the State attribute would be enough. >> What do you think? Do you think it is reasonable? We could elaborate a >> more detailed description if you find it interesting. > What is already done is to use "Service-Type = Authorize-Only". See > RFC 5080 for a discussion. > > - user authenticates > - final Access-Accept contains a State attribute > - final Access-Accept contains an attribute "more SAML data" -final Access-Accept contains a Termination-Action attribute with the value of RADIUS-Request > - NAS sends new Access-Request (somehow) tied to the original session > - this Access-Request contains > Service-Type = Authorize Only > State from original Access-Accept > - server replies with Access-Challenge / Access-Accept > - packets contain SAML data > - if the reply is an Access-Challenge, the NAS sends > another Access-Request Yeah, we had in mind something very similar. > Similar things are done already with Access-Request and > Authorize-Only. So that behavior falls within the context of existing > RADIUS practices. > The only new thing here is the use of Access-Challenge in this context. Another alternative would be the following: after the "more SAML data" attribute is sent, instead of performing several Access-Request/Access-Challenge roundtrips, perform several Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if this procedure would go against something in the standards. Regards, Alejandro > My $0.02 is that this mechanism for transporting bulk authorization > data in RADIUS should be defined separately from it's use in SAML. > There have been enough requests over the years for this that others will > find it useful, too. > Alan DeKok. From aland@deployingradius.com Mon Nov 28 05:45:39 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D127321F8C61 for ; Mon, 28 Nov 2011 05:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pwsVkLPics5 for ; Mon, 28 Nov 2011 05:45:39 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7D21F8C29 for ; Mon, 28 Nov 2011 05:45:39 -0800 (PST) Message-ID: <4ED39068.6000406@deployingradius.com> Date: Mon, 28 Nov 2011 14:45:12 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> <4ED38CE7.5070405@um.es> In-Reply-To: <4ED38CE7.5070405@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 13:45:39 -0000 Alejandro Perez Mendez wrote: >> How do you tie the packets together? > > As you say below, the State attribute would do the work. Additionally, > the "more SAML data" could contain a reference, and be included in the > following Access-Request message. Though I think the State attribute > would be enough. It would be preferable, but not enough. The packet needs to be routed through a proxy chain, so it needs to contain a User-Name attribute. >> - user authenticates >> - final Access-Accept contains a State attribute >> - final Access-Accept contains an attribute "more SAML data" > -final Access-Accept contains a Termination-Action attribute with the > value of RADIUS-Request I'm not sure I'd do that. Termination-Action is for *terminating* the service. In your use-case, service would continue, but more SAML authorization attributes would be needed. Instead, the first Access-Accept could contain "Service-Type = Additional-Authorization". This would be a new value indicating that additional authorization is required for the user. The NAS would then send requests for more data, as discussed earlier. The final Access-Accept would contain an updated Service-Type, for the users real service. > Another alternative would be the following: after the "more SAML data" > attribute is sent, instead of performing several > Access-Request/Access-Challenge roundtrips, perform several > Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if > this procedure would go against something in the standards. I think using Access-Challenge would be better. Alan DeKok. From alex@um.es Mon Nov 28 06:36:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3A621F8CA3 for ; Mon, 28 Nov 2011 06:36:53 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XukJCdO8Ic47 for ; Mon, 28 Nov 2011 06:36:53 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id C00E521F8C96 for ; Mon, 28 Nov 2011 06:36:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 2180B5D483; Mon, 28 Nov 2011 15:36:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iV+TwjiF07wL; Mon, 28 Nov 2011 15:36:50 +0100 (CET) Received: from [192.168.1.132] (243.246.221.87.dynamic.jazztel.es [87.221.246.243]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 05BB45D480; Mon, 28 Nov 2011 15:36:46 +0100 (CET) Message-ID: <4ED39C78.404@um.es> Date: Mon, 28 Nov 2011 15:36:40 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alan DeKok References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> <4ED38CE7.5070405@um.es> <4ED39068.6000406@deployingradius.com> In-Reply-To: <4ED39068.6000406@deployingradius.com> Content-Type: multipart/alternative; boundary="------------000401000203000700030404" Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 14:36:53 -0000 This is a multi-part message in MIME format. --------------000401000203000700030404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 28/11/11 14:45, Alan DeKok escribió: > Alejandro Perez Mendez wrote: >>> How do you tie the packets together? >> As you say below, the State attribute would do the work. Additionally, >> the "more SAML data" could contain a reference, and be included in the >> following Access-Request message. Though I think the State attribute >> would be enough. > It would be preferable, but not enough. The packet needs to be routed > through a proxy chain, so it needs to contain a User-Name attribute. you are right. I was just assuming that the User-Name was already there. > >>> - user authenticates >>> - final Access-Accept contains a State attribute >>> - final Access-Accept contains an attribute "more SAML data" >> -final Access-Accept contains a Termination-Action attribute with the >> value of RADIUS-Request > I'm not sure I'd do that. Termination-Action is for *terminating* the > service. In your use-case, service would continue, but more SAML > authorization attributes would be needed. RFC says, in regard with the State attribute: This Attribute is available to be sent by the server to the client in an Access-Challenge and MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any. This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. So I understood that if State attribute is sent within an Access-Request, then Termination-Action is required. > > Instead, the first Access-Accept could contain "Service-Type = > Additional-Authorization". This would be a new value indicating that > additional authorization is required for the user. But then it is required to define a new Service-Type value. Service-Type is not mandatory, would it be better to just not including it in the first Access-Accept? The "more SAML data" should be enough to indicate that. Regards, Alejandro > > The NAS would then send requests for more data, as discussed earlier. > The final Access-Accept would contain an updated Service-Type, for the > users real service. > >> Another alternative would be the following: after the "more SAML data" >> attribute is sent, instead of performing several >> Access-Request/Access-Challenge roundtrips, perform several >> Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if >> this procedure would go against something in the standards. > I think using Access-Challenge would be better. > > Alan DeKok. --------------000401000203000700030404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

El 28/11/11 14:45, Alan DeKok escribió: 
Alejandro Perez Mendez wrote:

   How do you tie the packets together?

As you say below, the State attribute would do the work. Additionally,
the "more SAML data" could contain a reference, and be included in the
following Access-Request message. Though I think the State attribute
would be enough.

  It would be preferable, but not enough.  The packet needs to be routed
through a proxy chain, so it needs to contain a User-Name attribute.

you are right. I was just assuming that the User-Name was already there. 


- user authenticates
- final Access-Accept contains a State attribute
- final Access-Accept contains an attribute "more SAML data"

-final Access-Accept contains a Termination-Action attribute with the
value of RADIUS-Request

  I'm not sure I'd do that.  Termination-Action is for *terminating* the
service.  In your use-case, service would continue, but more SAML
authorization attributes would be needed.

RFC says, in regard with the State attribute:
     This Attribute is available to be sent by the server to the client
      in an Access-Challenge and MUST be sent unmodified from the client
      to the server in the new Access-Request reply to that challenge,
      if any.
This Attribute is available to be sent by the server to the client
      in an Access-Accept that also includes a Termination-Action
      Attribute with the value of RADIUS-Request.

So I understood that if State attribute is sent within an Access-Request, then Termination-Action is required.



  Instead, the first Access-Accept could contain "Service-Type =
Additional-Authorization".  This would be a new value indicating that
additional authorization is required for the user.

But then it is required to define a new Service-Type value. Service-Type is not mandatory, would it be better to just not including it in the first Access-Accept? The "more SAML data" should be enough to indicate that.

Regards,
Alejandro


  The NAS would then send requests for more data, as discussed earlier.
 The final Access-Accept would contain an updated Service-Type, for the
users real service.


Another alternative would be the following: after the "more SAML data"
attribute is sent, instead of performing several
Access-Request/Access-Challenge roundtrips, perform several
Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if
this procedure would go against something in the standards.

  I think using Access-Challenge would be better.

  Alan DeKok.
--------------000401000203000700030404-- From hartmans@painless-security.com Mon Nov 28 07:04:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8D921F8BF4 for ; Mon, 28 Nov 2011 07:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBumlF6J5nRK for ; Mon, 28 Nov 2011 07:04:52 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4503221F8BD8 for ; Mon, 28 Nov 2011 07:04:52 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6C9F02017A; Mon, 28 Nov 2011 10:05:11 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F12A94239; Mon, 28 Nov 2011 10:04:39 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> <4ED38CE7.5070405@um.es> Date: Mon, 28 Nov 2011 10:04:39 -0500 In-Reply-To: <4ED38CE7.5070405@um.es> (Alejandro Perez Mendez's message of "Mon, 28 Nov 2011 14:30:15 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:04:53 -0000 I'm generally in favor of exploring both relaxing the 4k limit and/or defining a mechanism so that SAML attributes can be spread across multiple messages. I'm not generally in favor of defining a generic radius fragmentation message. My concern about using another protocol besides RADIUS to retrieve the SAML is that you'll have proxy, firewall and credentialing issues with that other protocol. I think we'll run into as much fun getting our other protocol through as we would a new RADIUS message type even if the other protocol is HTTP. That said, I definitely think a different protocol is preferable to a new RADIUS message type. --Sam From cantor.2@osu.edu Mon Nov 28 07:21:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD2F21F8CF2 for ; Mon, 28 Nov 2011 07:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybt5lQaKVXyH for ; Mon, 28 Nov 2011 07:21:38 -0800 (PST) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id CB52721F8876 for ; Mon, 28 Nov 2011 07:21:36 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pASFLKHH025640; Mon, 28 Nov 2011 10:21:35 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Mon, 28 Nov 2011 10:21:24 -0500 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] 4K limit Thread-Index: AQHMrb9OaTUm41Y5m0S6yhxfv7JsQJXChc0AgAAWP4CAABpggP//sOYA Date: Mon, 28 Nov 2011 15:21:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <84bd4fda-523e-45bb-9621-0e051e828d12> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:21:44 -0000 On 11/28/11 10:04 AM, "Sam Hartman" wrote: >I'm generally in favor of exploring both relaxing the 4k limit and/or >defining a mechanism so that SAML attributes can be spread across >multiple messages. > >I'm not generally in favor of defining a generic radius fragmentation >message. Obviously I want to see the limit dealt with, but I would note that SAML is not the issue here, the user data is. The XML framing is not a significant source of size, and the problem won't be any different with JWT. -- Scott From aland@deployingradius.com Mon Nov 28 07:38:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2921F8B1E for ; Mon, 28 Nov 2011 07:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxR0JOZc8+zJ for ; Mon, 28 Nov 2011 07:38:40 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1CF21F8A6C for ; Mon, 28 Nov 2011 07:38:40 -0800 (PST) Message-ID: <4ED3AAE6.1040600@deployingradius.com> Date: Mon, 28 Nov 2011 16:38:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> <4ED38CE7.5070405@um.es> <4ED39068.6000406@deployingradius.com> <4ED39C78.404@um.es> In-Reply-To: <4ED39C78.404@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:38:41 -0000 Alejandro Perez Mendez wrote: > RFC says, in regard with the State attribute: ... > So I understood that if State attribute is sent within an > Access-Request, then Termination-Action is required. I'm not sure that's required. I know I've *rarely* seen a Termination-Action when there's a State in Access-Accept. So I wouldn't worry about it too much. >> Instead, the first Access-Accept could contain "Service-Type = >> Additional-Authorization". This would be a new value indicating that >> additional authorization is required for the user. > > But then it is required to define a new Service-Type value. Service-Type > is not mandatory, would it be better to just not including it in the > first Access-Accept? The "more SAML data" should be enough to indicate that. The issue for me is a *generic* way of handling this. A "more SAML data" thing is specific to SAML. Alan DeKok. From diego@tid.es Mon Nov 28 07:44:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE20521F8CF6 for ; Mon, 28 Nov 2011 07:44:41 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7YJjuCwiGlV for ; Mon, 28 Nov 2011 07:44:41 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id CF80B21F8CED for ; Mon, 28 Nov 2011 07:44:40 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVD003DZNQE46@tid.hi.inet> for abfab@ietf.org; Mon, 28 Nov 2011 16:44:38 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 59.8B.21312.66CA3DE4; Mon, 28 Nov 2011 16:44:38 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LVD003DWNQD46@tid.hi.inet> for abfab@ietf.org; Mon, 28 Nov 2011 16:44:38 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 28 Nov 2011 16:44:37 +0100 Date: Mon, 28 Nov 2011 16:44:37 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: "abfab@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [abfab] 4K limit Thread-index: Acyt5KKQRbHtu8GdR2OUt1SrS5r59g== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f1c6d000005340-d3-4ed3ac660c85 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42Lhivcz1E1bc9nP4Mt3PouP198wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/yqHSwF3TwV2xe/YmtgvMbZxcjJISFgIvH5TBcrhC0mceHe ejYQW0hgG6PE6ouGXYxcQPYPRomlGx+zQDiNjBI973ewg1SxCKhK3N8+jRHEZhNQl2g5+o0F xBYWkJWYc3w72FROAT2J5t0nmEFsEaD6888/gG3gFbCUmPn8PROELSjxY/I9sF5moPqPf24z QtjiEs2tN6Hi2hJP3l0Am8kIdOn3U2uAejmAZspJ3FwUATFeT2LixAlMECWiEnfa1zNCPCYg sWTPeWYIW1Ti5eN/rBBP6kocO3+XaQKj2CwkV8xCcsUsJFfMQnLFAkaWVYxixUlFmekZJbmJ mTnpBkZ6GZl6mXmpJZsYIdGSuYNx+U6VQ4wCHIxKPLwbLl/yE2JNLCuuzD3EKMnBpCTK6776 sp8QX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV6mAKAcb0piZVVqUT5MSoaDQ0mCtxukTbAoNT21 Ii0zB5gSYNJMHJwg7TxA7X9BaniLCxJzizPTIfKnGCWlxHkvgCQEQBIZpXlwva8YxYGOFOZt B8nyAJMXXNcroIFMQAM5Zl4AGViSiJCSamA0DXHUU9qVWXbG6IZWQpZSyP3TuX9cdwVcrVxW 8vnoISHloKNBqw86fv2oXTXf7fnZx3W/jXkz96eUfH0yg3ma67w9F8tEFoW9WGgacj1CesIZ o7MsunzVzhIyzfvLGvJfH5+86INYnOfDVZklql9//b3uEsjp/mnq/26f147Z15fc7/v7cv4j JZbijERDLeai4kQAxK1dWRsDAAA= References: Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:44:41 -0000 On 28 Nov 2011, at 16:21 , Cantor, Scott wrote: > On 11/28/11 10:04 AM, "Sam Hartman" wrot= e: > >> I'm generally in favor of exploring both relaxing the 4k limit and/or >> defining a mechanism so that SAML attributes can be spread across >> multiple messages. >> >> I'm not generally in favor of defining a generic radius fragmentation >> message. > > Obviously I want to see the limit dealt with, but I would note that SAML > is not the issue here, the user data is. The XML framing is not a > significant source of size, and the problem won't be any different with > JWT. Agreed. As far as I can tell, we are talking about how to spread user ident= ity data required for authorization into several RADIUS messages (and neces= sarily in several RADIUS atributes). The precise format of the identity dat= a is immaterial. And looking at how the thread is evolving I think that the ideas are conver= ging=85 Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From hartmans@painless-security.com Mon Nov 28 07:46:49 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6114121F8CED for ; Mon, 28 Nov 2011 07:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrZMtIFS+S+q for ; Mon, 28 Nov 2011 07:46:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 04D4121F8BF4 for ; Mon, 28 Nov 2011 07:46:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4435C200F5; Mon, 28 Nov 2011 10:47:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 320C44239; Mon, 28 Nov 2011 10:46:42 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 28 Nov 2011 10:46:42 -0500 In-Reply-To: (Scott Cantor's message of "Mon, 28 Nov 2011 15:21:32 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:46:49 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 11/28/11 10:04 AM, "Sam Hartman" wrote: >> I'm generally in favor of exploring both relaxing the 4k limit >> and/or defining a mechanism so that SAML attributes can be spread >> across multiple messages. >> >> I'm not generally in favor of defining a generic radius >> fragmentation message. Cantor,> Obviously I want to see the limit dealt with, but I would Cantor,> note that SAML is not the issue here, the user data is. The Cantor,> XML framing is not a significant source of size, and the Cantor,> problem won't be any different with JWT. OK, well, I'm happy with the direction Alan is going in which seems to be a service type related to user data. What I didn't want was something at the radius messaging layer so deep in tchanging RADIUS that it could never get standardized. From cantor.2@osu.edu Mon Nov 28 07:52:12 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B6621F8C16 for ; Mon, 28 Nov 2011 07:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMldWY5HjyDC for ; Mon, 28 Nov 2011 07:52:11 -0800 (PST) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6B62421F8CD5 for ; Mon, 28 Nov 2011 07:52:07 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pASFpsmQ023858 for ; Mon, 28 Nov 2011 10:52:06 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi; Mon, 28 Nov 2011 10:51:55 -0500 From: "Cantor, Scott" To: "abfab@ietf.org" Thread-Topic: Comments on draft-ietf-abfab-gss-eap-naming-01 Thread-Index: AQHMreWnhkVwty1kkEqeC1Su5qvJ3Q== Date: Mon, 28 Nov 2011 15:52:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Subject: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:52:12 -0000 Just some small editorial suggestions... Section 3, third paragraph, "However for other name formats, including...", strike "for". Same paragraph, the sentence "So, based on who is named by the name, the semantics of the attribute can be determined." doesn't read terribly well. Which "name" are we talking about? I think you mean the name of the issuer, not the name of the attribute, but it's unclear since the document as a whole is mostly about attribute naming. Section 4, fourth paragraph, "trust context is an important part of the context", I suggest "trust context is an important part of this overall context". Same paragraph, there's a "AA" missing a third A. Substantive questons on section 6: I think you're proposing the name "urn:ietf:params:gss-eap:saml-aaa-assertion" be shared by both GSS-EAP and GSS-SAML-EC? I'm not a name bigot, I don't much care about it, but I wonder about the use of both gss-eap and moreso "-aaa-" in a name used with a mechanism that's neither EAP nor AAA. Is there a reason not to just use a more generic name? I note in particular the "-aaa-" part is missing from the SAML attribute section 6.2 constant, so maybe this was an oversight. They should be consistent in any case. There's also the question of value representation. Is the intent here to capture the value as expressed in XML directly, or the value subsequent to local processing such as a SAML implementation might perform? I think we need to say something, but I'll refrain from suggesting anything until we answer that question. Finally, I would add a third section to cover SAML NameID elements. A lot of SAML implementations do a poor job with attributes, and I've tended to always cover NameIDs in a consistent way to make sure those are handled uniformly so relying parties can deal with either. The value issue is also a consideration here, so I can propose text once we settle that. In terms of naming, the 's Format attribute is essentially the unique name you want, so it's a two part name, probably "urn:ietf:params:gss-eap:saml-nameid" and then the Format. -- Scott From Josh.Howlett@ja.net Mon Nov 28 07:53:55 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7E21F8CF6 for ; Mon, 28 Nov 2011 07:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8NGQdfeyN+G for ; Mon, 28 Nov 2011 07:53:54 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84B21F8CEE for ; Mon, 28 Nov 2011 07:53:54 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0B65F1A9B330_ED3AE90B; Mon, 28 Nov 2011 15:53:52 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 572F41A9B303_ED3AE8FF; Mon, 28 Nov 2011 15:53:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Mon, 28 Nov 2011 15:53:51 +0000 From: Josh Howlett To: Alejandro Perez Mendez , Alan DeKok Thread-Topic: [abfab] 4K limit Thread-Index: AcyrZz3FZVz3VcZdSHK0DtYsm6JkmwCV/sGAAAHhKAAAAsfUgAAFA5aA Date: Mon, 28 Nov 2011 15:53:51 +0000 Message-ID: In-Reply-To: <4ED38CE7.5070405@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FD300D28402F848A2FF906E6057C894@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:53:55 -0000 > >> - NAS sends new Access-Request (somehow) tied to the original session >> - this Access-Request contains >> Service-Type =3D Authorize Only >> State from original Access-Accept >> - server replies with Access-Challenge / Access-Accept >> - packets contain SAML data >> - if the reply is an Access-Challenge, the NAS sends >> another Access-Request > >Yeah, we had in mind something very similar. Likewise. I was going to propose something very similar to this for the Abfab Assertion Request Profile, so that the RP is able to obtain an assertion from an IdP at some point after authentication. I'd like to use the same mechanism for both post hoc assertion request and delivery of jumbo assertions (where delivery of a jumbo authentication assertion is essentially the case where the assertion is not necessarily solicited and happens immediately after authentication. So I think we should try to decouple the RADIUS/EAP authentication roundtrips from the RADIUS/SAML assertion roundtrips, modulo some mechanism to tie these together. There's another wrinkle that hasn't been discussed, which is that the SAML Request may also be larger than 4K. So we really need to deal with jumbo messages in both directions, which makes this even more interesting although I think that Alejandro's proposal works in this case. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Mon Nov 28 08:04:32 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6392C21F8BDB for ; Mon, 28 Nov 2011 08:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odanbi20kh4H for ; Mon, 28 Nov 2011 08:04:32 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E4D5921F8CE4 for ; Mon, 28 Nov 2011 08:04:31 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7AC9620126; Mon, 28 Nov 2011 11:04:56 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 537984239; Mon, 28 Nov 2011 11:04:25 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 28 Nov 2011 11:04:25 -0500 In-Reply-To: (Scott Cantor's message of "Mon, 28 Nov 2011 15:52:04 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:04:32 -0000 The actual URNs in the current doc are completely wrong. In particular for anything shared I don't think the string gss-eap should appear. GSS-API naming extensions has two value forms. The first is intended as a raw form, presumably XML. The second is a display value and is implementation dependent. You get both when you get a name attribute. (Well, you can request one or both). From cantor.2@osu.edu Mon Nov 28 08:16:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB57621F8CAB for ; Mon, 28 Nov 2011 08:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDs4VS7n0bjw for ; Mon, 28 Nov 2011 08:16:30 -0800 (PST) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4A521F8C4C for ; Mon, 28 Nov 2011 08:16:30 -0800 (PST) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pASGGT16025346; Mon, 28 Nov 2011 11:16:29 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Mon, 28 Nov 2011 11:16:29 -0500 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 Thread-Index: AQHMreeEDu2VuDvkVUuL1dXPCIhnW5XCdmWA Date: Mon, 28 Nov 2011 16:16:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6d2a36aa-a43d-41b0-8b93-78276b78e5bb> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:16:30 -0000 On 11/28/11 11:04 AM, "Sam Hartman" wrote: >The actual URNs in the current doc are completely wrong. In particular >for anything shared I don't think the string gss-eap should appear. Ok. >GSS-API naming extensions has two value forms. The first is intended as >a raw form, presumably XML. The second is a display value and is >implementation dependent. You get both when you get a name >attribute. (Well, you can request one or both). Ok, then I suspect we should probably provide guidance, possibly going so far as a MUST as to how to handle that. In particular, you presumably want the XML to be well-formed, so that creates additional work for the mechanism or whatever's creating the name attribute to serialize it safely. If the XML is the "raw" form, then the question is what the display form would be. When something like Shibboleth decodes the XML into something easily string-able, it does that by turning it from SAML into a local attribute, which wouldn't address this question. It could be left implementation dependent what the display name for the raw SAML is, or one could say that for the common case of a simple-valued element, you just use the text content of the element, otherwise undefined. -- Scott From hartmans@painless-security.com Mon Nov 28 08:43:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DEB21F8922 for ; Mon, 28 Nov 2011 08:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIjt1L+aMB9g for ; Mon, 28 Nov 2011 08:43:47 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9E54121F85D1 for ; Mon, 28 Nov 2011 08:43:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6C5352016A; Mon, 28 Nov 2011 11:44:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EE1344239; Mon, 28 Nov 2011 11:43:37 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 28 Nov 2011 11:43:37 -0500 In-Reply-To: (Scott Cantor's message of "Mon, 28 Nov 2011 16:16:37 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:43:48 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 11/28/11 11:04 AM, "Sam Hartman" wrote: >> The actual URNs in the current doc are completely wrong. In >> particular for anything shared I don't think the string gss-eap >> should appear. Cantor,> Ok. >> GSS-API naming extensions has two value forms. The first is >> intended as a raw form, presumably XML. The second is a display >> value and is implementation dependent. You get both when you get >> a name attribute. (Well, you can request one or both). Cantor,> Ok, then I suspect we should probably provide guidance, Cantor,> possibly going so far as a MUST as to how to handle Cantor,> that. In particular, you presumably want the XML to be Cantor,> well-formed, so that creates additional work for the Cantor,> mechanism or whatever's creating the name attribute to Cantor,> serialize it safely. I'd kind of assumed that you want the raw value of the element in question. At least if there are no elements just data such as a string, I think you want that. I agree that if there are XML elements in the attribute value, you probably do need to handle namespaces and make it well-formed. From cantor.2@osu.edu Mon Nov 28 08:57:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89BE21F8CC5 for ; Mon, 28 Nov 2011 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diLCKgAUWEvm for ; Mon, 28 Nov 2011 08:57:27 -0800 (PST) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0F20821F8CFC for ; Mon, 28 Nov 2011 08:57:26 -0800 (PST) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pASGvPpe029050; Mon, 28 Nov 2011 11:57:26 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Mon, 28 Nov 2011 11:57:26 -0500 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 Thread-Index: AQHMreeEDu2VuDvkVUuL1dXPCIhnW5XCdmWAgABbXYD//7AAgA== Date: Mon, 28 Nov 2011 16:57:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:57:27 -0000 On 11/28/11 11:43 AM, "Sam Hartman" wrote: > >I'd kind of assumed that you want the raw value of the element in >question. At least if there are no elements just data such as a string, >I think you want that. I agree that if there are XML elements in the >attribute value, you probably do need to handle namespaces and make it >well-formed. Yes, that's fine. We just need to explicitly say that or it will be ambiguous. -- Scott From hartmans@painless-security.com Mon Nov 28 09:05:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA9221F8713 for ; Mon, 28 Nov 2011 09:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zalRlJFWulEk for ; Mon, 28 Nov 2011 09:05:58 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2328321F85A8 for ; Mon, 28 Nov 2011 09:05:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8952B20188; Mon, 28 Nov 2011 12:06:22 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 55C154239; Mon, 28 Nov 2011 12:05:51 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 28 Nov 2011 12:05:51 -0500 In-Reply-To: (Scott Cantor's message of "Mon, 28 Nov 2011 16:57:17 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 17:05:58 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 11/28/11 11:43 AM, "Sam Hartman" wrote: >> >I'd kind of assumed that you want the raw value of the element in >> question. At least if there are no elements just data such as a >> string, I think you want that. I agree that if there are XML >> elements in the attribute value, you probably do need to handle >> namespaces and make it well-formed. Cantor,> Yes, that's fine. We just need to explicitly say that or it Cantor,> will be ambiguous. Agreed. So, resolving your editorial issues is trivial. I already have an action item to run a proposed set of URNs by kitten and abfab. Any chance you could give me text on the values and name IDs? The latest XML source is in the draft repository, although plain text is also fine. From nico@cryptonector.com Mon Nov 28 09:52:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95AA21F8BEC for ; Mon, 28 Nov 2011 09:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYt1K0w5p4ZV for ; Mon, 28 Nov 2011 09:52:10 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 39D6821F8BDC for ; Mon, 28 Nov 2011 09:52:10 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id E7BB326C064 for ; Mon, 28 Nov 2011 09:52:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=KWvRK8iJheEKY2PnXmsBR ZXYMGgXLHsrfQS/RmNeOx3hHUXsiDmooq636KUoNUkgYHBmv5syq7gk06CD3pHf3 GsUeRy206Tw12HKfXG935qjLg4HPd8w91OnWnTcDKF3O4gyQtuGJzn9sWfWmcouE BFiuPnUd5NkZP2tdre0WZY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=NcNXVazsx8A7q38rC7aL MOLjmw4=; b=G/BcAWGfe5wH6cy3A8zVjnKKgVopfVkLqSqJkPTW8CUcQj3e8ltq W/VEl2eImsKq4+GxYtNqWy3jH94D1J5GjvvlRdFXeFz9RyQRG+fH88VUoiMWsgKX y0hZpohXy4jTyfPtYS4a0GLItHrVDpudWeA1H51warfls8BdJT1DUac= Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id BD49726C063 for ; Mon, 28 Nov 2011 09:52:09 -0800 (PST) Received: by qadb10 with SMTP id b10so836776qad.10 for ; Mon, 28 Nov 2011 09:52:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.199 with SMTP id a7mr55616611pbc.58.1322502728735; Mon, 28 Nov 2011 09:52:08 -0800 (PST) Received: by 10.68.192.70 with HTTP; Mon, 28 Nov 2011 09:52:08 -0800 (PST) In-Reply-To: <4ED37A3E.4020709@deployingradius.com> References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> Date: Mon, 28 Nov 2011 11:52:08 -0600 Message-ID: From: Nico Williams To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 17:52:10 -0000 Note that this would result in a synchronous round trip for every 4KB of data. That could get painful. It'd be preferable to burn a round trip on negotiation of large packets, no? Nico -- From cantor.2@osu.edu Mon Nov 28 10:02:35 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32AE21F8B6C for ; Mon, 28 Nov 2011 10:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH1noRjcUCD2 for ; Mon, 28 Nov 2011 10:02:34 -0800 (PST) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 15C3021F8B64 for ; Mon, 28 Nov 2011 10:02:33 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pASI2KIF032721; Mon, 28 Nov 2011 13:02:27 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Mon, 28 Nov 2011 13:02:25 -0500 From: "Cantor, Scott" To: Nico Williams , Alan DeKok Thread-Topic: [abfab] 4K limit Thread-Index: AQHMrb9OaTUm41Y5m0S6yhxfv7JsQJXChc0AgABfagD//68LAA== Date: Mon, 28 Nov 2011 18:02:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:02:35 -0000 On 11/28/11 12:52 PM, "Nico Williams" wrote: >Note that this would result in a synchronous round trip for every 4KB >of data. That could get painful. It'd be preferable to burn a round >trip on negotiation of large packets, no? I think in practice >4K is rare, >8K is even rarer, etc. You won't have much benefit from burning a round trip ahead of time. -- Scott From hartmans@painless-security.com Mon Nov 28 10:10:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDF721F8CAE for ; Mon, 28 Nov 2011 10:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WREuowpVmgb for ; Mon, 28 Nov 2011 10:10:27 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A521F8B82 for ; Mon, 28 Nov 2011 10:10:21 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B4A1E2010C; Mon, 28 Nov 2011 13:10:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8C5674239; Mon, 28 Nov 2011 13:10:14 -0500 (EST) From: Sam Hartman To: Nico Williams References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> Date: Mon, 28 Nov 2011 13:10:14 -0500 In-Reply-To: (Nico Williams's message of "Mon, 28 Nov 2011 11:52:08 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:10:47 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Note that this would result in a synchronous round trip for Nico> every 4KB of data. That could get painful. It'd be Nico> preferable to burn a round trip on negotiation of large Nico> packets, no? For Moonshot, relaxing the 4k limit for TCP definitely seems more Nico> attractive. We're often going to have a very few number of proxies involved. For general RADIUS, it's more complex because there's not really a good way to engage the proxies in negotiation. From aland@deployingradius.com Mon Nov 28 10:24:51 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061A21F8B5D for ; Mon, 28 Nov 2011 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC1C20N2IypO for ; Mon, 28 Nov 2011 10:24:50 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEDE21F8797 for ; Mon, 28 Nov 2011 10:24:50 -0800 (PST) Message-ID: <4ED3D1D5.1080805@deployingradius.com> Date: Mon, 28 Nov 2011 19:24:21 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <10546499-135E-49EA-9B54-2394E69CD796@tid.es> <4ED36DA1.402@um.es> <4ED37A3E.4020709@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:24:51 -0000 Nico Williams wrote: > Note that this would result in a synchronous round trip for every 4KB > of data. That could get painful. RADIUS isn't TCP. :( > It'd be preferable to burn a round > trip on negotiation of large packets, no? Which is likely to work in many fewer situations. How can a NAS negotiate large packets through multiple layers of proxies? RADIUS is designed to be point to point (security, proxying, etc.) So any multi-hop negotiation is doomed to failure from the start. Alan DeKok. From cantor.2@osu.edu Mon Nov 28 12:58:52 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AD111E808E for ; Mon, 28 Nov 2011 12:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlGgS-S0xjxU for ; Mon, 28 Nov 2011 12:58:51 -0800 (PST) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3916911E80E8 for ; Mon, 28 Nov 2011 12:58:51 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pASKwaI6019223; Mon, 28 Nov 2011 15:58:49 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Mon, 28 Nov 2011 15:58:41 -0500 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 Thread-Index: AQHMreeEDu2VuDvkVUuL1dXPCIhnW5XCdmWAgABbXYD//7AAgIAAVjeA///tOYA= Date: Mon, 28 Nov 2011 20:58:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <65c7897d-3188-4b88-947d-094c70056e48> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 20:58:52 -0000 On 11/28/11 12:05 PM, "Sam Hartman" wrote: > >Any chance you could give me text on the values and name IDs? The latest >XML source is in the draft repository, although plain text is also fine. Ok, here's some text to try. I included language about character encoding. I don't know if that's needed, but I suspect something probably is, whether it's this or something else. There's also some ugly text about NameID qualifiers because of an unfortunate decision to allow defaulting there. I captured what my guidelines would be in the general case of a SAML implementation. For section 6.2: Each attribute carried in the assertion SHOULD also be a GSS name attribute. The name of this attribute has three parts, all separated by an ASCII space character. The first part is TBD. The second part is the URI for the element's NameFormat XML attribute. The final part is the element's Name XML attribute. If the content of each element is a simple text node (or nodes), then the raw and "display" values of the GSS name attribute MUST be the text content of the element(s) encoded as UTF-8. If the value is not simple, then the raw value(s) of the GSS name attribute MUST be the well-formed serialization of the element(s) encoded as UTF-8. The "display" values are implementation-defined. Then the last paragraph is the same as what you have now. Then add section 6.3 SAML Name Identifiers: The carried in the subject of the assertion SHOULD also be a GSS name attribute. The name of this attribute has two parts, separated by an ASCII space character. The first part is TBD. The second part is the URI for the element's Format XML attribute. The raw value of the GSS name attribute MUST be the well-formed serialization of the element encoded as UTF-8. The "display" value is implementation-defined. For formats defined by section 8.3 of [SAMLCORE], missing values of the NameQualifier or SPNameQualifier XML attributes MUST be populated in accordance with the definition of the format prior to serialization. In other words, the defaulting rules specified for the "persistent" and "transient" formats MUST be applied prior to serialization. This attribute SHOULD be marked authenticated if the name identifier is contained in a SAML assertion that has been successfully validated back to the trusted source of the peer credential. In the GSS-EAP mechanism, a SAML assertion carried in an integrity-protected and authenticated AAA protocol SHALL be sufficiently validated. An implementation MAY apply local policy checks to this assertion and discard it if it is unacceptable according to these checks. -- Scott From ietf@augustcellars.com Mon Nov 28 13:33:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6BD11E80DD for ; Mon, 28 Nov 2011 13:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDo3Pyzg0oaw for ; Mon, 28 Nov 2011 13:33:48 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC1511E8085 for ; Mon, 28 Nov 2011 13:33:48 -0800 (PST) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B3BE638F0E; Mon, 28 Nov 2011 13:33:47 -0800 (PST) From: "Jim Schaad" To: "'Josh Howlett'" , "'Alejandro Perez Mendez'" , "'Alan DeKok'" References: <4ED38CE7.5070405@um.es> In-Reply-To: Date: Mon, 28 Nov 2011 13:33:13 -0800 Message-ID: <045001ccae15$58e4fd10$0aaef730$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJpRtoXrD9W90iaysEEu2/Pgn/WIpSJnAqA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 21:33:48 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Josh Howlett > Sent: Monday, November 28, 2011 7:54 AM > To: Alejandro Perez Mendez; Alan DeKok > Cc: abfab@ietf.org > Subject: Re: [abfab] 4K limit > > > > >> - NAS sends new Access-Request (somehow) tied to the original session > >> - this Access-Request contains > >> Service-Type = Authorize Only > >> State from original Access-Accept > >> - server replies with Access-Challenge / Access-Accept > >> - packets contain SAML data > >> - if the reply is an Access-Challenge, the NAS sends > >> another Access-Request > > > >Yeah, we had in mind something very similar. > > Likewise. I was going to propose something very similar to this for the Abfab > Assertion Request Profile, so that the RP is able to obtain an assertion from > an IdP at some point after authentication. > > I'd like to use the same mechanism for both post hoc assertion request and > delivery of jumbo assertions (where delivery of a jumbo authentication > assertion is essentially the case where the assertion is not necessarily > solicited and happens immediately after authentication. > > So I think we should try to decouple the RADIUS/EAP authentication > roundtrips from the RADIUS/SAML assertion roundtrips, modulo some > mechanism to tie these together. > > There's another wrinkle that hasn't been discussed, which is that the SAML > Request may also be larger than 4K. So we really need to deal with jumbo > messages in both directions, which makes this even more interesting > although I think that Alejandro's proposal works in this case. I think that in general one can deal with this by forcing the RP to make multiple requests rather than a single request in this case. However I also have an item which was discussed some months ago but has not reared its head again. That is that there may be a proxy in the middle that wants to do some re-writing of the SAML messages in both directions. This would be for the purpose of changes attribute names so that a common mapping does not need to be understood by either end but just by the proxy in the middle. This means that we need to be thinking of the proxy suddenly become the server/client of the fragmented message or becoming the service that is going to provide/ask for the OOB query method. Jim > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited by > guarantee which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Mon Nov 28 13:52:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51A11E80FC for ; Mon, 28 Nov 2011 13:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llsi7gp8XjdW for ; Mon, 28 Nov 2011 13:52:53 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC1F811E80F8 for ; Mon, 28 Nov 2011 13:52:52 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D4515200F4; Mon, 28 Nov 2011 16:53:16 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7D1A24239; Mon, 28 Nov 2011 16:52:45 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <4ED38CE7.5070405@um.es> <045001ccae15$58e4fd10$0aaef730$@augustcellars.com> Date: Mon, 28 Nov 2011 16:52:45 -0500 In-Reply-To: <045001ccae15$58e4fd10$0aaef730$@augustcellars.com> (Jim Schaad's message of "Mon, 28 Nov 2011 13:33:13 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 21:52:53 -0000 I think your proxy use-case argues for doing this in-band with RADIUS so you get the same proxy chain no matter what is going on. From alex@um.es Tue Nov 29 00:10:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2480A21F8B31 for ; Tue, 29 Nov 2011 00:10:42 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLyUnJBYEw7n for ; Tue, 29 Nov 2011 00:10:41 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id D077E21F8AAC for ; Tue, 29 Nov 2011 00:10:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 165A0535B5; Tue, 29 Nov 2011 09:10:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xm0Z5hSaUk0W; Tue, 29 Nov 2011 09:10:38 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id 8A30853613; Tue, 29 Nov 2011 09:10:30 +0100 (CET) Message-ID: <4ED49375.9040401@um.es> Date: Tue, 29 Nov 2011 09:10:29 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 08:10:42 -0000 El 28/11/11 16:53, Josh Howlett escribió: >>> - NAS sends new Access-Request (somehow) tied to the original session >>> - this Access-Request contains >>> Service-Type = Authorize Only >>> State from original Access-Accept >>> - server replies with Access-Challenge / Access-Accept >>> - packets contain SAML data >>> - if the reply is an Access-Challenge, the NAS sends >>> another Access-Request >> Yeah, we had in mind something very similar. > Likewise. I was going to propose something very similar to this for the > Abfab Assertion Request Profile, so that the RP is able to obtain an > assertion from an IdP at some point after authentication. > > I'd like to use the same mechanism for both post hoc assertion request and > delivery of jumbo assertions (where delivery of a jumbo authentication > assertion is essentially the case where the assertion is not necessarily > solicited and happens immediately after authentication. Agree > > So I think we should try to decouple the RADIUS/EAP authentication > roundtrips from the RADIUS/SAML assertion roundtrips, modulo some > mechanism to tie these together. How are you thinking decoupling them? Performing the RADIUS/EAP as usual (not SAML related data), and let the RP to start afterwards an "assertion request process" to obtain the authentication assertion? > > There's another wrinkle that hasn't been discussed, which is that the SAML > Request may also be larger than 4K. So we really need to deal with jumbo > messages in both directions, which makes this even more interesting > although I think that Alejandro's proposal works in this case. We also discussed this. Although a jumbo SAML Request is possible, it would be really unlikely. The main reason to really think about jumbo SAML messages was, I think, that it is impossible to foresee the amount of SAML Attributes that will be included in the Response. The request, however, should not be that big if certificates are not included on it (as pointed out by Scott). Anyway, I agree that, to avoid problems in the future, we provide for this functionality. I think that the "more SAML data" attribute proposed by Alan would work also if included in requests. In such a case, the AAA/idP could send an Access-Challenge message (including User-Name and State attributes, for example), waiting for more data to come from the RP. Additionally, the "more SAML data" could contain some kind of "cookie" or "nonce" value, in such a way that if returned unmodified in the following Request/Response message to the creator, it allows to tie all the messages within a conversation, if other means (e.g. State attribute) are finally not enough or not applicable. Regards, Alejandro > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > From diego@tid.es Tue Nov 29 09:56:00 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A6A21F8B9B for ; Tue, 29 Nov 2011 09:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olk1wZrJDEZu for ; Tue, 29 Nov 2011 09:56:00 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38EFE21F8B64 for ; Tue, 29 Nov 2011 09:55:59 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVF00MWPOH90U@tid.hi.inet> for abfab@ietf.org; Tue, 29 Nov 2011 18:55:57 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 2C.EA.04893.BE825DE4; Tue, 29 Nov 2011 19:48:11 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LVF00MWKOH90U@tid.hi.inet> for abfab@ietf.org; Tue, 29 Nov 2011 18:55:57 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Tue, 29 Nov 2011 18:55:57 +0100 Date: Tue, 29 Nov 2011 18:55:55 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4ED49375.9040401@um.es> To: Alejandro Perez Mendez Message-id: <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] 4K limit Thread-index: AcyuwCUwt3QYCiwcQoaA0kY4M5TMwQ== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f4c6d00000131d-0f-4ed528eb83a4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsXCFe/Apfta46qfQccvPouP198wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr43nvX+aCFSIV1x+9Zm1gfCLcxcjJISFgItH/eCEbhC0mceHe eiCbi0NIYAOjxL5prewQzg9GicbL+6AyjYwSi3bcAGthEVCV+HmkiwnEZhNQl2g5+o0FxBYW kJWYc3w7K4jNCVTz/uYHdhBbBKhm671PYPXMAp4S1zftA7I5OHgFLCXO7OYDCfMKCEr8mHyP BSTMDFQ+ZUouRLW4RHPrTRYIW1Fi2qIGRhCbEejo76fWgE0REZCTuLkoAmKRnkTzsi52iBJR iTvt6xkhfhSQWLLnPDOELSrx8vE/VpBWIaBjrj0NnsAoPgvJDbMQbpiF5IZZSG5YwMiyilGs OKkoMz2jJDcxMyfdwFAvI1MvMy+1ZBMjJH4ydjAu36lyiFGAg1GJhzdY6aqfEGtiWXFl7iFG SQ4mJVFeVwmgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeYDagHG9KYmVValE+TEqGg0NJgpdT BiglWJSanlqRlpkDTBIwaSYOTpB2HqB2RpAa3uKCxNzizHSI/ClGSSlxXi6QhABIIqM0D673 FaM40JHCvO+kgbI8wHQG1/UKaCAT0MD2yVdABpYkIqSkGhhPsOy9f/jd/0/He+RbPj1cFhIg od+zt13NyPOqTlH8Zh7m3cfz3za4b//x898p949yBZ8yXshUPFM7HtIx99zf24umtu9IcHRP Z160LsfCoEJme9X7jK8crQcmNjZ9q6vp/7MmePlE3cVn63i7DKftbXCLfnD53Yc6RS5rhYvB 197NiftXp3VSiaU4I9FQi7moOBEAv8rfxyQDAAA= References: <4ED49375.9040401@um.es> Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:56:00 -0000 DQpPbiAyOSBOb3YgMjAxMSwgYXQgMDk6MTAgLCBBbGVqYW5kcm8gUGVyZXogTWVuZGV6IHdyb3Rl Og0KPiBJIHRoaW5rIHRoYXQgdGhlICJtb3JlIFNBTUwgZGF0YSIgYXR0cmlidXRlIHByb3Bvc2Vk IGJ5IEFsYW4gd291bGQgd29yaw0KPiBhbHNvIGlmIGluY2x1ZGVkIGluIHJlcXVlc3RzLiBJbiBz dWNoIGEgY2FzZSwgdGhlIEFBQS9pZFAgY291bGQgc2VuZCBhbg0KPiBBY2Nlc3MtQ2hhbGxlbmdl IG1lc3NhZ2UgKGluY2x1ZGluZyBVc2VyLU5hbWUgYW5kIFN0YXRlIGF0dHJpYnV0ZXMsIGZvcg0K PiBleGFtcGxlKSwgd2FpdGluZyBmb3IgbW9yZSBkYXRhIHRvIGNvbWUgZnJvbSB0aGUgUlAuDQoN CkFzIEFsYW4gbm90ZWQsIHdlIHNob3VsZCBhaW0gZm9yIGEgbW9yZSBnZW5lcmFsIG5hbWUgZm9y IHRoZSBhdHRyaWJ1dGUuIFRob3VnaCB0aGUgZXhjaGFuZ2Ugb2YgU0FNTCBkYXRhIGlzIHRoZSBt YWluIChhbmQgcHJvYmFibHkgdW5pcXVlLCBhdCBsZWFzdCBmb3IgdGhlIG1vbWVudCkgdXNlIGNh c2UsIEkgZG9uJ3Qgc2VlIGFueSBodXJ0IGluIHVzaW5nIHNvbWV0aGluZyBsaWtlICJtb3JlIGFk ZGl0aW9uYWwgZGF0YSIgb3IgIm1vcmUgZXh0ZXJuYWwgZGF0YSIgb3IgIm1vcmUgYXV0aG9yaXph dGlvbiBkYXRhIi4uLg0KDQo+IEFkZGl0aW9uYWxseSwgdGhlICJtb3JlIFNBTUwgZGF0YSIgY291 bGQgY29udGFpbiBzb21lIGtpbmQgb2YgImNvb2tpZSINCj4gb3IgIm5vbmNlIiB2YWx1ZSwgaW4g c3VjaCBhIHdheSB0aGF0IGlmIHJldHVybmVkIHVubW9kaWZpZWQgaW4gdGhlDQo+IGZvbGxvd2lu ZyBSZXF1ZXN0L1Jlc3BvbnNlIG1lc3NhZ2UgdG8gdGhlIGNyZWF0b3IsIGl0IGFsbG93cyB0byB0 aWUgYWxsDQo+IHRoZSBtZXNzYWdlcyB3aXRoaW4gYSBjb252ZXJzYXRpb24sIGlmIG90aGVyIG1l YW5zIChlLmcuIFN0YXRlDQo+IGF0dHJpYnV0ZSkgYXJlIGZpbmFsbHkgbm90IGVub3VnaCBvciBu b3QgYXBwbGljYWJsZS4NCg0KSW5kZWVkLiBJIHRoaW5rIGl0IHdvdWxkIHByb3ZpZGUgbm90IG9u bHkgdGhpcyB0eWluZyBtZWNoYW5pc20sIGJ1dCBhbHNvIHRoZSBwb3NzaWJsaXR5IG9mIHVzaW5n IGl0IHRvIHBvaW50IHRoZSBjb252ZXJzYXRpb24gKGFuZCB0aGUgc3ViamVjdCBvZiB0aGUgZGF0 YSBiZWluZyBleGNoYW5nZWQpIHRvIHRoZSBlbGVtZW50cyBwcm92aWRpbmcgdGhvc2UgYWRkaXRp b25hbCBhdXRob3JpemF0aW9uIGRhdGEsIGFuZCBJIGd1ZXNzIHRoaXMgY291bGQgc2F0aXNmeSB3 aGF0IEpvc2ggY2FsbGVkIHRoZSBkZWNvdXBsaW5nIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQg YXNzZXJ0aW9uIHJvdW5kdHJpcHMuDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZh bGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25p Y2EgSStEDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICAgKzM0IDkxMyAxMjkgMDQx DQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52 w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1 YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9y IGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFT L2Rpc2NsYWltZXIuYXNweA0K