From yoshihiro.ohba@toshiba.co.jp Sun Feb 3 08:33:22 2013 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 44E5521F8467 for ; Sun, 3 Feb 2013 08:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.088 X-Spam-Level: X-Spam-Status: No, score=-8.088 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE-XON5EMb-L for ; Sun, 3 Feb 2013 08:33:16 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA421F8464 for ; Sun, 3 Feb 2013 08:33:15 -0800 (PST) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r13GXDkf007048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 01:33:13 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r13GXDej008212; Mon, 4 Feb 2013 01:33:13 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 373; Mon, 4 Feb 2013 01:33:13 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r13GXDPs008209; Mon, 4 Feb 2013 01:33:13 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r13GXDwL014503; Mon, 4 Feb 2013 01:33:13 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA14502; Mon, 4 Feb 2013 01:33:13 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r13GXCxa014312; Mon, 4 Feb 2013 01:33:13 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r13GXCvb007955; Mon, 4 Feb 2013 01:33:12 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.20]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 01:33:12 +0900 From: To: , Thread-Topic: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt Thread-Index: AQHN/jp5IouSjWfWYE27PUpL/kASK5hg+PwAgAdgOBA= Date: Sun, 3 Feb 2013 16:33:12 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> In-Reply-To: <5108DDAA.9030708@um.es> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.60] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78BE95FD7tgxml338toshibalo_" MIME-Version: 1.0 Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 03 Feb 2013 16:33:22 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78BE95FD7tgxml338toshibalo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxlamFuZHJvLA0KDQpJbiBvcmRlciB0byBtYWludGFpbiBkZWFsIHdpdGggUkFESVVTIGNs aWVudHMgYW5kIHNlcnZlcnMgdGhhdCBkbyBub3Qgc3VwcG9ydCBmcmFnbWVudGF0aW9uLCBpdCB3 b3VsZCBiZSBjbGVhbmVyIHRvIHVzZSBSQURJVVMgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbnMgKGRy YWZ0LWhhbHdhc2lhLXJhZGV4dC1jYXBhYmlsaXR5LW5lZ290aWF0aW9uKSB0byBuZWdvdGlhdGUg dXNlIG9mIE1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0ZS4gIFRoaXMgd291bGQNCmFsbG93IGFs bCBSQURJVVMgbWVzc2FnZXMgdG8gdXNlIE1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0ZSBmb3Ig ZnJhZ21lbnRhdGlvbiB3aXRoIG5vIGV4Y2VwdGlvbi4NCg0KWW9zaGloaXJvIE9oYmENCg0KDQoN CkZyb206IGFiZmFiLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphYmZhYi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQWxlamFuZHJvIFBlcmV6IE1lbmRleg0KU2VudDogV2VkbmVzZGF5 LCBKYW51YXJ5IDMwLCAyMDEzIDU6NDYgUE0NClRvOiBhYmZhYkBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFthYmZhYl0gW3JhZGV4dF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1w ZXJlei1yYWRleHQtcmFkaXVzLWZyYWdtZW50YXRpb24tMDQudHh0DQoNCkhlbGxvIFlvc2hpLCBS YWZhLA0KDQpzZWUgc29tZSBjb21tZW50cyBpbmxpbmU6DQoNCg0KRGVhciBhbGwsDQoNCg0KDQp3 ZSBoYXZlIHJlY2VpdmVkIGFkZGl0aW9uYWwgY29tbWVudHMgZnJvbSBZb3NoaWhpcm8gT2hiYSAo bWFueSB0aGFua3MpIHRoYXQgd2Ugc2hhcmUgd2l0aCB5b3UuDQoNCg0KDQpQbGVhc2UsIHNlZSBz b21lIGNvbW1lbnRzIGlubGluZS4NCg0KDQoNCiJIZXJlIGlzIG15IHJldmlldyBvZiBkcmFmdC1w ZXJlei1yYWRleHQtcmFkaXVzLWZyYWdtZW50YXRpb24tMDQuDQoNCg0KDQpTZWN0aW9uIDE6DQoN Cg0KDQoiRWFjaCBSQURJVVMgcGFja2V0IGNhbiB0cmFuc3BvcnQgc2V2ZXJhbCBSQURJVVMgYXR0 cmlidXRlcywgdG8gY29udmV5DQoNCnRoZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gdG8gdGhlIG90 aGVyIHBlZXIsIHVwIHRvIGEgbWF4aW11bSBzaXplIG9mIDQNCg0KS0Igb2YgdG90YWwgZGF0YSAo aW5jbHVkaW5nIFJBRElVUyBwYWNrZXQgaGVhZGVycykuIg0KDQoNCg0KW1lPXSBJIHN1Z2dlc3Qg dG8gcmVwbGFjZSAiNCBLQiIgd2l0aCAiNDA5NiBieXRlcyIgdGhyb3VnaG91dCB0aGUNCg0KZG9j dW1lbnQgc2luY2UgIktCIiBjYW4gbWVhbiA0MDAwIGJ5dGVzIGluIHNvbWUgY2FzZXMuDQoNCg0K DQpbUmFmYV0gT0suDQoNCg0KDQoNCg0KIkEgcmVmZXJlbmNlLWJhc2VkIG1lY2hhbmlzbSBpcyBh bHNvIHByb3Bvc2VkIGluIFtSRkM2MTU4XSwgd2hlcmUNCg0KYXR0cmlidXRlcyBjYW4gYmUgb2J0 YWluZWQgdGhyb3VnaCBhbiBvdXQtb2YtYmFuZCBwcm90b2NvbC4iDQoNCg0KDQpbWU99IE1lYW5p bmcgb2YgdGhpcyBzZW50ZW5jZSBpcyB1bmNsZWFyLiBEb2VzIHRoaXMgbWVhbiBSQURJVVMNCg0K YXR0cmlidXRlcyBhcmUgb2J0YWluZWQgdGhyb3VnaCBzb21lIG90aGVyIHByb3RvY29sIGluc3Rl YWQgb2YgUkFESVVTPw0KDQpPciBkb2VzIHRoaXMgbWVhbiB0aGUgYWN0dWFsIGZvcm1hdCBvZiB0 aGUgVmFsdWUgZmllbGQgb2YgYSBSQURJVVMNCg0KQXR0cmlidXRlIGlzIGRlZmluZWQgaW4gb3Ro ZXIgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbj8gSW4gdGhlIGxhdHRlcg0KDQpjYXNlLCBpdCBzaG91 bGQgYmUgYWxzbyBtZW50aW9uZWQgdGhhdCBSQURJVVMtRUFQIGlzIGNhdGVnb3JpemVkIGFzIHRo ZQ0KDQptZWNoYW5pc20gZGVmaW5lZCBpbiBSRkMgNjE1OC4NCg0KDQoNCltSYWZhXSBJdCBpcyBy ZWZlcnJpbmcgdGhlIHZhbHVlIG9mIHRoZSBhdHRyaWJ1dGVzIGNhbiBiZSBvYnRhaW5lZCBieSBv dGhlciBwcm90b2NvbCBpbnN0ZWFkIG9mIFJBRElVUy4gVGhpcyBpcyBjb21pbmcgZnJvbSBhIHBy ZXZpb3VzIGNvbW1lbnQgcmVsYXRlZCB3aXRoIFNBTUwgdHJhbnNwb3J0LiBJbnN0ZWFkIG9mIHRy YW5zcG9ydGluZyB0aGUgcmVhbCBTQU1MIG1lc3NhZ2VzIGFuIFVSTCBpcyBzZXQgYXMgYXR0cmli dXRlIHZhbHVlLiBXZSBjYW4gdHJ5IHRvIGNsYXJpZnkgYSBsaXR0bGUgYml0IG1vcmUuDQoNCg0K DQoiSG93ZXZlciwgdGhlcmUgYXJlIG5vIHByb3Bvc2FscyB0byBkZWFsIHdpdGggZnJhZ21lbnRh dGlvbiBhdCBhIHBhY2tldA0KDQpsZXZlbCwgd2hlbiB0aGUgdG90YWwgc2l6ZSBleGNlZWRzIHRo ZSA0IEtCIGxpbWl0IGltcG9zZWQgYnkgdGhlIFJBRElVUw0KDQpzcGVjaWZpY2F0aW9uLiINCg0K DQoNCltZT10gTWVhbmluZyBvZiAiYXQgYSBwYWNrZXQgbGV2ZWwiIGlzIHVuY2xlYXIuIFN1Z2dl c3RlZCBjaGFuZ2U6DQoNCiJIb3dldmVyLCB0aGVyZSBhcmUgbm8gcHJvcG9zYWxzIHRvIGZyYWdl bWVudCBhIGxhcmdlLXNpemVkIFJBRElVUw0KDQpwYWNrZXQgaW50byBtdWx0aXBsZSBzbWFsbC1z aXplZCBSQURJVVMgcGFja2V0cywgd2hlcmUgdGhlIGxlbmd0aCBvZiB0aGUNCg0Kb3JpZ2luYWwg KHVuZnJhZ21lbnRlZCkgUkFESVVTIHBhY2tldCBleGNlZWRzIHRoZSA0MDk2LW9jdGV0IGxpbWl0 DQoNCmltcG9zZWQgYnkgdGhlIFJBRElVUyBzcGVjaWZpY2F0aW9uLiINCg0KDQoNCltSYWZhXSBU aGlzIHNvdW5kcyBnb29kLg0KDQoNCg0KDQoNClNlY3Rpb24gMjoNCg0KDQoNCltZT10gSSBhbSBu b3Qgc3VyZSBpZiAiVCIgZmxhZyBpcyBuZWVkZWQuIEluIG90aGVyIHdvcmRzLCBpdCBzaG91bGQg YmUNCg0KcG9zc2libGUgdG8gY2hhbmdlIFtJLUQuaWV0Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lv bnNdIHRvIHNpbXBseSBhbGxvdyBhDQoNCmZyYWdtZW50IHdpdGggdGhlIE0tZmxhZyBjbGVhcmVk IG5vdCB0byBiZSBpbmNsdWRlZCBpbiBhIG5vbi1sYXN0IGNodW5rLg0KDQoNCg0KW1JhZmFdDQoN Cg0KDQpZZXMsIHRoYXQgbWF5IGJlIHBvc3NpYmxlLiBJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCB3 ZSB3YW50ZWQgdG8ga2VlcCB1bm1vZGlmaWVkIGFueSBleGlzdGluZyBJLUQgYnkgdGhlIHRpbWUg YmVpbmcuIE1vcmVvdmVyLCBbSS1ELmlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zXSBoYXMg bm90IGNvbnNpZGVyZWQgdGhhdCBmcmFnbWVudGF0aW9uIGF0IHBhY2tldCBsZXZlbCBtYXkgb2Nj dXIgZm9yIG9idmlvdXMgcmVhc29ucy4gTW9yZW92ZXIsIHRoYXQgSS1EIGlzIGluIGEgbWF0dXJl IHN0YXRlIG5vdy4NCg0KDQoNCkluIGFueSBjYXNlLCB3ZSBtYXkgYXNrIGF1dGhvcnMgb2YgW0kt RC5pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9uc10uDQoNCg0KDQpTZWN0aW9uIDMuMzoNCg0K DQoNCltZT10gQWNjZXNzLUFjY2VwdCBmcmFnbWVudGF0aW9uIHNjaGVtZSBsb29rcyBvZGQgY29t cGFyZWQgdG8NCg0KQWNjZXNzLVJlcXVlc3QgYW5kIEFjY2Vzcy1DaGFsbGVuZ2UgZnJhZ21lbnRh dGlvbiBzY2hlbWVzLiBUaGVyZSBhcmUNCg0Kc2V2ZXJhbCBxdWVzdGlvbnMgcmVsYXRlZCB0byB0 aGlzOiAoMSkgV2h5IG11bHRpcGxlIGNodW5rcyBvZg0KDQpBY2Nlc3MtQWNjZXB0IGNhbm5vdCBi ZSBzZW50IHdpdGhvdXQgaGF2aW5nIGFuIEFjY2Vzcy1DaGFsbGFuZ2UgdG8gYmUNCg0Kc2VudCBp biBiZXR3ZWVuPyAoMikgV2h5IGFuIEFjY2Vzcy1BY2NlcHQgY2Fubm90IGNvbnRhaW4gYQ0KDQpN b3JlLURhdGEtUGVuZGluZyBhdHRyaWJ1dGUgaW5zdGVhZCBvZiB1c2luZyBhIG5ldyBzZXJ2aWNl IHR5cGUgdmFsdWU/DQoNCigzKSBIb3cgY2FuIGEgbGFyZ2UgYXR0cmlidXR1ZSB0aGF0IGlzIGFs bG93ZWQgdG8gYXBwZWFyIGluIGFuDQoNCkFjY2Vzcy1BY2NlcHQgYnV0IG5vdCBhbGxvd2VkIHRv IGFwcGVhciBpbiBBY2Nlc3MtQ2hhbGxlbmdlIGJlIGZyYWdtZW50ZWQ/DQoNCg0KDQpbUmFmYV0N Cg0KDQoNCjEpIFdlIHdhbnRlZCB0byBiZSBzeW1tZXRyaWMgaW4gdGhlIGRlc2lnbiwgd2hlcmUg QWNjZXNzLVJlcXVlc3QvQWNjZXNzLUNoYWxsZW5nZSBleGNoYW5nZSBpcyB1c2VkIHNvbWVob3cg Zm9yIGZyYWdtZW50YXRpb24gc3VwcG9ydC4gSW4gYW55IGNhc2UsIHdlIGhhdmUgYWxzbyBjb25z aWRlcmVkIHRoZSB1c2FnZSBvZiBBY2Nlc3MtQWNjZXB0IHdpdGggU2VydmljZS1UeXBlW0FkZEF1 dGhdIHNvIHVudGlsIGFsbCB0aGUgYXR0cmlidXRlcyBpbiB0aGUgd2hvbGUgUkFESVVTIEFjY2Vz cy1BY2NlcHQgYXJlIGZpbmFsbHkgc2VudCB0aGUgZXhjaGFuZ2Ugd2lsbCBiZSBBY2Nlc3MtUmVx dWVzdC9BY2Nlc3MtQWNjZXB0IChTZXJ2aWNlLVR5cGVbQWRkQXV0aF0pLCB3aGlsZSB0aGUgbGFz dCBvbmUgaXMgc2ltcGx5IEFjY2Vzcy1SZXF1ZXN0L0FjY2Vzcy1BY2NlcHQuIFRoaXMgbW9kZSBv ZiBvcGVyYXRpb24gd291bGQgc29sdmUgeW91ciBxdWVzdGlvbiAzKS4NCg0KDQoNCjIpIEkgdGhp bmsgdGhhdCBtYXkgYmUgYWxzbyBwb3NzaWJsZS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgQWxhbiBv ciBBbGV4IGNhbiBlbGFib3JhdGUgYSBsaXR0bGUgYml0IGEgbW9yZSBhYm91dCB0aGUgdXNhZ2Ug b2YgU2VydmljZS1UeXBlW0FkZEF1dGhdLg0KDQoNCg0KMykgUHJlY2lzZWx5LCB0cnlpbmcgdG8g YW5zd2VyIHRoaXMgcXVlc3Rpb24gd2UganVzdCBjYW1lIHVwIHdpdGggdGhlIHNvbHV0aW9uIGlu IDEpLiBXaGF0IGRvIHlvdSB0aGluaz8NCg0KVGhpcyBhbHRlcm5hdGl2ZSBzb3VuZHMgZ29vZCB0 byBtZS4gSG93ZXZlciwgSSB0aGluayB0aGVyZSBtYXkgYmUgc3RpbGwgc29tZSBhZHZhbnRhZ2Vz IG9mIHVzaW5nIFNlcnZpY2UtVHlwZSBpbnN0ZWFkIG9mIChvciBpbiBhZGRpdGlvbiB0bykgTW9y ZS1EYXRhLVBlbmRpbmcgZm9yIEFjY2Vzcy1BY2NlcHQgcGFja2V0cy4NCg0KSWYgdGhlIE5BUy9S UCBkb2VzIG5vdCBrbm93IGFueXRoaW5nIGFib3V0IGZyYWdtZW50YXRpb24gKGkuZS4gZG9lcyBu b3Qgc3VwcG9ydCB0aGlzIGRyYWZ0KSwgaXQgbWF5IHRha2UgdGhlIGZpcnN0IEFjY2Vzcy1BY2Nl cHQgY2h1bmssIGlnbm9yZSB0aGUgTW9yZS1EYXRhLVBlbmRpbmcgYXR0cmlidXRlIChpdCBpcyB1 bmtub3duIGZvciBpdCksIGFuZCBwcm9jZXNzIGl0IGFzIGEgY29tcGxldGUgcGFja2V0LiBBcyBu byBhZGRpdGlvbmFsIHJvdW5kLXRyaXAgaXMgbWFuZGF0b3J5IGFmdGVyIGFuIEFjY2Vzcy1BY2Nl cHQgcGFja2V0LCBpdCBtYXkgYmUgcHJvYmxlbWF0aWMgYXMgaXQgaXMgcG9zc2libGUgdGhhdCBw YXJ0IG9mIHRoZSBvYmxpZ2F0aW9ucyBmcm9tIHRoZSBBUyB0byB0aGUgTkFTIChlLmcuIEZXIHBv bGljaWVzKSBhcmUgbm90IGVuZm9yY2VkLg0KDQpIb3dldmVyLCBSRkMgMjg2NSBzYXlzIHRoYXQg KGluIHJlbGF0aW9uIHRvIEFjY2Vzcy1BY2NlcHQgcGFja2V0cyk6DQoNCkEgTkFTIGlzIG5vdA0K DQogICAgICByZXF1aXJlZCB0byBpbXBsZW1lbnQgYWxsIG9mIHRoZXNlIHNlcnZpY2UgdHlwZXMs IGFuZCBNVVNUIHRyZWF0DQoNCiAgICAgIHVua25vd24gb3IgdW5zdXBwb3J0ZWQgU2VydmljZS1U eXBlcyBhcyB0aG91Z2ggYW4gQWNjZXNzLVJlamVjdA0KDQogICAgICBoYWQgYmVlbiByZWNlaXZl ZCBpbnN0ZWFkDQoNClRoZXJlZm9yZSwgaWYgdGhlIE5BUyBkb2VzIG5vdCB1bmRlcnN0YW5kIFNl cnZpY2UtVHlwZT1BZGRpdGlvbmFsQXV0aG9yaXphdGlvbiwgdGhlIEFjY2Vzcy1BY2NlcHQgcGFj a2V0IHdpbGwgYmUgaW50ZXJwcmV0ZWQgYXMgYW4gQWNjZXNzLVJlamVjdCBvbmUsIHdoaWNoIHNl ZW1zIHRvIGJlIHRoZSBtb3N0IHJlYXNvbmFibGUgYXBwcm9hY2guDQoNClRoaXMgc29ydCBvZiBw cm9ibGVtcyBzZWVtIHRvIG5vdCBiZSBjcml0aWNhbCB3aXRoIEFjY2Vzcy1DaGFsbGVuZ2UgcGFj a2V0cywgYXMgdGhlIE5BUyBpcyBleHBlY3RlZCB0byBnZW5lcmF0ZSBhIG5ldyBBY2Nlc3MtUmVx dWVzdCBwYWNrZXQgYWZ0ZXJ3YXJkcywgYW5kIHRoZSBBUyBjYW4gZGV0ZWN0IHdoZXRoZXIgZnJh Z21lbnRhdGlvbiB3YXMgc3VwcG9ydGVkLg0KDQpSZWdhcmRzLA0KQWxlamFuZHJvDQoNCg0KDQpT ZWN0aW9uIDg6DQoNCg0KDQpbWU9dIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMg dG9vIHNob3J0LiBTZWN1cml0eSBtZWNoYW5zaW1zDQoNCnRoYXQgYXJlIG5lZWRlZCBmb3Igc2Vj dXJlIG9wZXJhdGlvbiBvZiB0aGUgcHJvcG9zZWQgZnJhZ21lbnRhdGlvbg0KDQptZWNoYW5pc20g bmVlZHMgdG8gYmUgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCg0KDQoNCltSYWZhXSBZZXMg dGhpcyBzZWN0aW9uIHdpbGwgYmUgaW1wcm92ZWQuIEppbSBhbHNvIHJhaXNlZCBjb21tZW50cyBh Ym91dCBpdC4NCg0KDQoNClNlY3Rpb24gOToNCg0KDQoNCltZT10gSSBkb24ndCB0aGluayB0aGUg Zm9sbG93aW5nIHN0YXRlbWVudCBpcyB0cnVlOiAiVGhpcyBkb2N1bWVudCBoYXMNCg0Kbm8gYWN0 aW9ucyBmb3IgSUFOQS4iIGJlY2F1c2UgU2VjdGlvbiA2IGRlZmluZXMgbmV3IGF0dHJpYnV0ZXMu DQoNCg0KDQpbUmFmYV0gQ29ycmVjdC4gVGhpcyBuZWVkcyB0byBiZSBmaXhlZC4NCg0KDQoNCkJl c3QgUmVnYXJkcywNCg0KWW9zaGloaXJvIE9oYmENCg0KIg0KDQoNCg0KQmVzdCByZWdhcmRzLg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpSYWZhZWwgTWFyaW4gTG9wZXosIFBoRA0KDQpEZXB0LiBJbmZvcm1hdGlvbiBhbmQg Q29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJSUMpDQoNCkZhY3VsdHkgb2YgQ29tcHV0ZXIg U2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0KDQozMDEwMCBNdXJjaWEgLSBTcGFpbg0KDQpU ZWxmOiArMzQ4Njg4ODg1MDEgRmF4OiArMzQ4Njg4ODQxNTEgZS1tYWlsOiByYWZhQHVtLmVzPG1h aWx0bzpyYWZhQHVtLmVzPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpyYWRleHQgbWFpbGluZyBsaXN0DQoNCnJh ZGV4dEBpZXRmLm9yZzxtYWlsdG86cmFkZXh0QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0KDQo= --_000_674F70E5F2BE564CB06B6901FD3DD78BE95FD7tgxml338toshibalo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDmmI7mnJ0iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToi77yt77yzIOaYjuacnSI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDmmI7mnJ0iOw0KCXBhbm9zZS0xOjIgMiA2 IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwg5pu45byP5LuY44GNIFwo5paH5a2XXCkiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg 5pu45byP5LuY44GNIFwo5paH5a2XXCkiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDmm7jlvI/ku5jjgY0iOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo5OS4yNXB0IDMuMGNtIDMuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGVqYW5kcm8sPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIG9yZGVyIHRvIG1haW50YWluIGRlYWwgd2l0aCBSQURJVVMgY2xpZW50 cyBhbmQgc2VydmVycyB0aGF0IGRvIG5vdCBzdXBwb3J0IGZyYWdtZW50YXRpb24sIGl0IHdvdWxk IGJlIGNsZWFuZXIgdG8gdXNlIFJBRElVUyBjYXBhYmlsaXR5IG5lZ290aWF0aW9ucyAoZHJhZnQt aGFsd2FzaWEtcmFkZXh0LWNhcGFiaWxpdHktbmVnb3RpYXRpb24pIHRvIG5lZ290aWF0ZSB1c2Ug b2YgTW9yZS1EYXRhLVBlbmRpbmcNCiBhdHRyaWJ1dGUuJm5ic3A7IFRoaXMgd291bGQgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbGxvdyBhbGwgUkFESVVTIG1lc3NhZ2Vz IHRvIHVzZSBNb3JlLURhdGEtUGVuZGluZyBhdHRyaWJ1dGUgZm9yIGZyYWdtZW50YXRpb24gd2l0 aCBubyBleGNlcHRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvc2hpaGlybyBPaGJhPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gYWJmYWItYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmFiZmFiLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkFsZWphbmRybyBQZXJleiBNZW5kZXo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51 YXJ5IDMwLCAyMDEzIDU6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IGFiZmFiQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbYWJmYWJdIFtyYWRleHRdIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtcGVyZXotcmFkZXh0LXJhZGl1cy1mcmFnbWVudGF0aW9uLTA0LnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkhlbGxvIFlv c2hpLCBSYWZhLCA8YnI+DQo8YnI+DQpzZWUgc29tZSBjb21tZW50cyBpbmxpbmU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij53ZSBoYXZlIHJlY2VpdmVkIGFkZGl0aW9uYWwgY29tbWVudHMgZnJv bSBZb3NoaWhpcm8gT2hiYSAobWFueSB0aGFua3MpIHRoYXQgd2Ugc2hhcmUgd2l0aCB5b3UuIDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlBsZWFzZSwg c2VlIHNvbWUgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZxdW90O0hlcmUgaXMgbXkgcmV2aWV3IG9mIGRyYWZ0LXBlcmV6 LXJhZGV4dC1yYWRpdXMtZnJhZ21lbnRhdGlvbi0wNC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5TZWN0aW9uIDE6PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+JnF1b3Q7RWFjaCBSQURJVVMgcGFja2V0IGNh biB0cmFuc3BvcnQgc2V2ZXJhbCBSQURJVVMgYXR0cmlidXRlcywgdG8gY29udmV5PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dGhlIG5lY2Vzc2FyeSBp bmZvcm1hdGlvbiB0byB0aGUgb3RoZXIgcGVlciwgdXAgdG8gYSBtYXhpbXVtIHNpemUgb2YgNDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPktCIG9mIHRv dGFsIGRhdGEgKGluY2x1ZGluZyBSQURJVVMgcGFja2V0IGhlYWRlcnMpLiZxdW90OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPltZT10gSSBzdWdnZXN0 IHRvIHJlcGxhY2UgJnF1b3Q7NCBLQiZxdW90OyB3aXRoICZxdW90OzQwOTYgYnl0ZXMmcXVvdDsg dGhyb3VnaG91dCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5kb2N1bWVudCBzaW5jZSAmcXVvdDtLQiZxdW90OyBjYW4gbWVhbiA0MDAwIGJ5dGVz IGluIHNvbWUgY2FzZXMuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+W1JhZmFdIE9LLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZxdW90O0EgcmVmZXJlbmNlLWJhc2VkIG1lY2hhbmlzbSBpcyBhbHNvIHBy b3Bvc2VkIGluIFtSRkM2MTU4XSwgd2hlcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5hdHRyaWJ1dGVzIGNhbiBiZSBvYnRhaW5lZCB0aHJvdWdoIGFu IG91dC1vZi1iYW5kIHByb3RvY29sLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPltZT30gTWVhbmluZyBvZiB0aGlzIHNlbnRlbmNlIGlzIHVu Y2xlYXIuIERvZXMgdGhpcyBtZWFuIFJBRElVUzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPmF0dHJpYnV0ZXMgYXJlIG9idGFpbmVkIHRocm91Z2ggc29t ZSBvdGhlciBwcm90b2NvbCBpbnN0ZWFkIG9mIFJBRElVUz88bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PciBkb2VzIHRoaXMgbWVhbiB0aGUgYWN0dWFs IGZvcm1hdCBvZiB0aGUgVmFsdWUgZmllbGQgb2YgYSBSQURJVVM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BdHRyaWJ1dGUgaXMgZGVmaW5lZCBpbiBv dGhlciBwcm90b2NvbCBzcGVjaWZpY2F0aW9uPyBJbiB0aGUgbGF0dGVyPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Y2FzZSwgaXQgc2hvdWxkIGJlIGFs c28gbWVudGlvbmVkIHRoYXQgUkFESVVTLUVBUCBpcyBjYXRlZ29yaXplZCBhcyB0aGU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5tZWNoYW5pc20gZGVm aW5lZCBpbiBSRkMgNjE1OC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5bUmFmYV0gSXQgaXMgcmVmZXJyaW5nIHRoZSB2YWx1ZSBvZiB0aGUgYXR0cmli dXRlcyBjYW4gYmUgb2J0YWluZWQgYnkgb3RoZXIgcHJvdG9jb2wgaW5zdGVhZCBvZiBSQURJVVMu IFRoaXMgaXMgY29taW5nIGZyb20gYSBwcmV2aW91cyBjb21tZW50IHJlbGF0ZWQgd2l0aCBTQU1M IHRyYW5zcG9ydC4gSW5zdGVhZCBvZiB0cmFuc3BvcnRpbmcgdGhlIHJlYWwgU0FNTCBtZXNzYWdl cyBhbiBVUkwgaXMgc2V0IGFzIGF0dHJpYnV0ZSB2YWx1ZS4gV2UgY2FuIHRyeSB0byBjbGFyaWZ5 IGEgbGl0dGxlIGJpdCBtb3JlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZxdW90O0hvd2V2ZXIsIHRoZXJlIGFyZSBubyBwcm9wb3NhbHMgdG8gZGVh bCB3aXRoIGZyYWdtZW50YXRpb24gYXQgYSBwYWNrZXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5sZXZlbCwgd2hlbiB0aGUgdG90YWwgc2l6ZSBleGNl ZWRzIHRoZSA0IEtCIGxpbWl0IGltcG9zZWQgYnkgdGhlIFJBRElVUzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnNwZWNpZmljYXRpb24uJnF1b3Q7PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W1lPXSBNZWFu aW5nIG9mICZxdW90O2F0IGEgcGFja2V0IGxldmVsJnF1b3Q7IGlzIHVuY2xlYXIuIFN1Z2dlc3Rl ZCBjaGFuZ2U6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+JnF1b3Q7SG93ZXZlciwgdGhlcmUgYXJlIG5vIHByb3Bvc2FscyB0byBmcmFnZW1lbnQgYSBs YXJnZS1zaXplZCBSQURJVVM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5wYWNrZXQgaW50byBtdWx0aXBsZSBzbWFsbC1zaXplZCBSQURJVVMgcGFja2V0 cywgd2hlcmUgdGhlIGxlbmd0aCBvZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5vcmlnaW5hbCAodW5mcmFnbWVudGVkKSBSQURJVVMgcGFja2V0 IGV4Y2VlZHMgdGhlIDQwOTYtb2N0ZXQgbGltaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pbXBvc2VkIGJ5IHRoZSBSQURJVVMgc3BlY2lmaWNhdGlv bi4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5bUmFmYV0gVGhpcyBzb3VuZHMgZ29vZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5TZWN0aW9uIDI6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W1lPXSBJIGFtIG5vdCBzdXJlIGlmICZxdW90O1QmcXVv dDsgZmxhZyBpcyBuZWVkZWQuIEluIG90aGVyIHdvcmRzLCBpdCBzaG91bGQgYmU8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5wb3NzaWJsZSB0byBjaGFu Z2UgW0ktRC5pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9uc10gdG8gc2ltcGx5IGFsbG93IGE8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5mcmFnbWVu dCB3aXRoIHRoZSBNLWZsYWcgY2xlYXJlZCBub3QgdG8gYmUgaW5jbHVkZWQgaW4gYSBub24tbGFz dCBjaHVuay48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5bUmFmYV0gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+WWVzLCB0aGF0IG1heSBiZSBwb3NzaWJsZS4gSXQgaXMgd29ydGggbm90aW5nIHRoYXQgd2Ug d2FudGVkIHRvIGtlZXAgdW5tb2RpZmllZCBhbnkgZXhpc3RpbmcgSS1EIGJ5IHRoZSB0aW1lIGJl aW5nLiBNb3Jlb3ZlciwgW0ktRC5pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9uc10gaGFzIG5v dCBjb25zaWRlcmVkIHRoYXQgZnJhZ21lbnRhdGlvbiBhdCBwYWNrZXQgbGV2ZWwgbWF5IG9jY3Vy IGZvciBvYnZpb3VzIHJlYXNvbnMuIE1vcmVvdmVyLCB0aGF0IEktRCBpcyBpbiBhIG1hdHVyZSBz dGF0ZSBub3cuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+SW4gYW55IGNhc2UsIHdlIG1heSBhc2sgYXV0aG9ycyBvZiBbSS1ELmlldGYtcmFkZXh0LXJh ZGl1cy1leHRlbnNpb25zXS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5TZWN0aW9uIDMuMzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5bWU9dIEFjY2Vzcy1BY2NlcHQgZnJhZ21lbnRhdGlvbiBzY2hlbWUg bG9va3Mgb2RkIGNvbXBhcmVkIHRvPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+QWNjZXNzLVJlcXVlc3QgYW5kIEFjY2Vzcy1DaGFsbGVuZ2UgZnJhZ21l bnRhdGlvbiBzY2hlbWVzLiBUaGVyZSBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5zZXZlcmFsIHF1ZXN0aW9ucyByZWxhdGVkIHRvIHRoaXM6ICgx KSBXaHkgbXVsdGlwbGUgY2h1bmtzIG9mPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+QWNjZXNzLUFjY2VwdCBjYW5ub3QgYmUgc2VudCB3aXRob3V0IGhh dmluZyBhbiBBY2Nlc3MtQ2hhbGxhbmdlIHRvIGJlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+c2VudCBpbiBiZXR3ZWVuPyAoMikgV2h5IGFuIEFjY2Vz cy1BY2NlcHQgY2Fubm90IGNvbnRhaW4gYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPk1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0ZSBpbnN0ZWFkIG9m IHVzaW5nIGEgbmV3IHNlcnZpY2UgdHlwZSB2YWx1ZT88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4oMykgSG93IGNhbiBhIGxhcmdlIGF0dHJpYnV0dWUg dGhhdCBpcyBhbGxvd2VkIHRvIGFwcGVhciBpbiBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFjY2Vzcy1BY2NlcHQgYnV0IG5vdCBhbGxvd2VkIHRv IGFwcGVhciBpbiBBY2Nlc3MtQ2hhbGxlbmdlIGJlIGZyYWdtZW50ZWQ/PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W1JhZmFdPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MSkgV2Ugd2FudGVkIHRvIGJlIHN5 bW1ldHJpYyBpbiB0aGUgZGVzaWduLCB3aGVyZSBBY2Nlc3MtUmVxdWVzdC9BY2Nlc3MtQ2hhbGxl bmdlIGV4Y2hhbmdlIGlzIHVzZWQgc29tZWhvdyBmb3IgZnJhZ21lbnRhdGlvbiBzdXBwb3J0LiBJ biBhbnkgY2FzZSwgd2UgaGF2ZSBhbHNvIGNvbnNpZGVyZWQgdGhlIHVzYWdlIG9mIEFjY2Vzcy1B Y2NlcHQgd2l0aCBTZXJ2aWNlLVR5cGVbQWRkQXV0aF0gc28gdW50aWwgYWxsIHRoZSBhdHRyaWJ1 dGVzIGluIHRoZSB3aG9sZSBSQURJVVMgQWNjZXNzLUFjY2VwdCBhcmUgZmluYWxseSBzZW50IHRo ZSBleGNoYW5nZSB3aWxsIGJlIEFjY2Vzcy1SZXF1ZXN0L0FjY2Vzcy1BY2NlcHQgKFNlcnZpY2Ut VHlwZVtBZGRBdXRoXSksIHdoaWxlIHRoZSBsYXN0IG9uZSBpcyBzaW1wbHkgQWNjZXNzLVJlcXVl c3QvQWNjZXNzLUFjY2VwdC4gVGhpcyBtb2RlIG9mIG9wZXJhdGlvbiB3b3VsZCBzb2x2ZSB5b3Vy IHF1ZXN0aW9uIDMpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjIpIEkgdGhpbmsgdGhhdCBtYXkgYmUgYWxzbyBwb3NzaWJsZS4gSW4gYW55IGNhc2Us IEkgdGhpbmsgQWxhbiBvciBBbGV4IGNhbiBlbGFib3JhdGUgYSBsaXR0bGUgYml0IGEgbW9yZSBh Ym91dCB0aGUgdXNhZ2Ugb2YgU2VydmljZS1UeXBlW0FkZEF1dGhdLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjMpIFByZWNpc2VseSwgdHJ5aW5nIHRv IGFuc3dlciB0aGlzIHF1ZXN0aW9uIHdlIGp1c3QgY2FtZSB1cCB3aXRoIHRoZSBzb2x1dGlvbiBp biAxKS4gV2hhdCBkbyB5b3UgdGhpbms/Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 YnI+DQpUaGlzIGFsdGVybmF0aXZlIHNvdW5kcyBnb29kIHRvIG1lLiBIb3dldmVyLCBJIHRoaW5r IHRoZXJlIG1heSBiZSBzdGlsbCBzb21lIGFkdmFudGFnZXMgb2YgdXNpbmcgU2VydmljZS1UeXBl IGluc3RlYWQgb2YgKG9yIGluIGFkZGl0aW9uIHRvKSBNb3JlLURhdGEtUGVuZGluZyBmb3IgQWNj ZXNzLUFjY2VwdCBwYWNrZXRzLjxicj4NCjxicj4NCklmIHRoZSBOQVMvUlAgZG9lcyBub3Qga25v dyBhbnl0aGluZyBhYm91dCBmcmFnbWVudGF0aW9uIChpLmUuIGRvZXMgbm90IHN1cHBvcnQgdGhp cyBkcmFmdCksIGl0IG1heSB0YWtlIHRoZSBmaXJzdCBBY2Nlc3MtQWNjZXB0IGNodW5rLCBpZ25v cmUgdGhlIE1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0ZSAoaXQgaXMgdW5rbm93biBmb3IgaXQp LCBhbmQgcHJvY2VzcyBpdCBhcyBhIGNvbXBsZXRlIHBhY2tldC4gQXMgbm8gYWRkaXRpb25hbCBy b3VuZC10cmlwDQogaXMgbWFuZGF0b3J5IGFmdGVyIGFuIEFjY2Vzcy1BY2NlcHQgcGFja2V0LCBp dCBtYXkgYmUgcHJvYmxlbWF0aWMgYXMgaXQgaXMgcG9zc2libGUgdGhhdCBwYXJ0IG9mIHRoZSBv YmxpZ2F0aW9ucyBmcm9tIHRoZSBBUyB0byB0aGUgTkFTIChlLmcuIEZXIHBvbGljaWVzKSBhcmUg bm90IGVuZm9yY2VkLjxicj4NCjxicj4NCkhvd2V2ZXIsIFJGQyAyODY1IHNheXMgdGhhdCAoaW4g cmVsYXRpb24gdG8gQWNjZXNzLUFjY2VwdCBwYWNrZXRzKTo8bzpwPjwvbzpwPjwvcD4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QSBOQVMgaXMgbm90PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlcXVpcmVkIHRvIGltcGxlbWVudCBhbGwgb2YgdGhlc2Ugc2VydmljZSB0eXBlcywg YW5kIE1VU1QgdHJlYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdW5rbm93biBvciB1bnN1cHBv cnRlZCBTZXJ2aWNlLVR5cGVzIGFzIHRob3VnaCBhbiBBY2Nlc3MtUmVqZWN0PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGhhZCBiZWVuIHJlY2VpdmVkIGluc3RlYWQ8bzpwPjwvbzpwPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KVGhl cmVmb3JlLCBpZiB0aGUgTkFTIGRvZXMgbm90IHVuZGVyc3RhbmQgU2VydmljZS1UeXBlPUFkZGl0 aW9uYWxBdXRob3JpemF0aW9uLCB0aGUgQWNjZXNzLUFjY2VwdCBwYWNrZXQgd2lsbCBiZSBpbnRl cnByZXRlZCBhcyBhbiBBY2Nlc3MtUmVqZWN0IG9uZSwgd2hpY2ggc2VlbXMgdG8gYmUgdGhlIG1v c3QgcmVhc29uYWJsZSBhcHByb2FjaC48YnI+DQo8YnI+DQpUaGlzIHNvcnQgb2YgcHJvYmxlbXMg c2VlbSB0byBub3QgYmUgY3JpdGljYWwgd2l0aCBBY2Nlc3MtQ2hhbGxlbmdlIHBhY2tldHMsIGFz IHRoZSBOQVMgaXMgZXhwZWN0ZWQgdG8gZ2VuZXJhdGUgYSBuZXcgQWNjZXNzLVJlcXVlc3QgcGFj a2V0IGFmdGVyd2FyZHMsIGFuZCB0aGUgQVMgY2FuIGRldGVjdCB3aGV0aGVyIGZyYWdtZW50YXRp b24gd2FzIHN1cHBvcnRlZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkFsZWphbmRybzxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5TZWN0aW9uIDg6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+W1lPXSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvbyBzaG9y dC4gU2VjdXJpdHkgbWVjaGFuc2ltczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPnRoYXQgYXJlIG5lZWRlZCBmb3Igc2VjdXJlIG9wZXJhdGlvbiBvZiB0 aGUgcHJvcG9zZWQgZnJhZ21lbnRhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPm1lY2hhbmlzbSBuZWVkcyB0byBiZSBkZXNjcmliZWQgaW4gdGhp cyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPltSYWZhXSBZZXMgdGhpcyBzZWN0aW9uIHdpbGwgYmUgaW1wcm92ZWQuIEppbSBhbHNvIHJh aXNlZCBjb21tZW50cyBhYm91dCBpdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5TZWN0aW9uIDk6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W1lPXSBJIGRvbid0IHRoaW5rIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50IGlzIHRydWU6ICZxdW90O1RoaXMgZG9jdW1lbnQgaGFzPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+bm8gYWN0aW9ucyBmb3IgSUFOQS4mcXVv dDsgYmVjYXVzZSBTZWN0aW9uIDYgZGVmaW5lcyBuZXcgYXR0cmlidXRlcy48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bUmFmYV0gQ29ycmVjdC4gVGhp cyBuZWVkcyB0byBiZSBmaXhlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WW9zaGloaXJvIE9oYmE8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CZXN0IHJlZ2FyZHMuPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJhZmFlbCBNYXJpbiBMb3BleiwgUGhEPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RGVwdC4gSW5mb3Jt YXRpb24gYW5kIENvbW11bmljYXRpb25zIEVuZ2luZWVyaW5nIChESUlDKTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkZhY3VsdHkgb2YgQ29tcHV0ZXIg U2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjMwMTAwIE11cmNpYSAtIFNwYWluPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGVsZjogJiM0MzszNDg2ODg4ODUw MSBGYXg6ICYjNDM7MzQ4Njg4ODQxNTEgZS1tYWlsOiA8YSBocmVmPSJtYWlsdG86cmFmYUB1bS5l cyI+cmFmYUB1bS5lczwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5yYWRleHQgbWFpbGlu ZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PGEgaHJlZj0ibWFpbHRvOnJhZGV4dEBpZXRmLm9yZyI+cmFkZXh0QGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0Ij5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_674F70E5F2BE564CB06B6901FD3DD78BE95FD7tgxml338toshibalo_-- From hartmans@painless-security.com Sun Feb 3 08:47:57 2013 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 75B5E21F8622 for ; Sun, 3 Feb 2013 08:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FRGqdpQfaYp for ; Sun, 3 Feb 2013 08:47:57 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 026E121F8620 for ; Sun, 3 Feb 2013 08:47:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0CE4520118; Sun, 3 Feb 2013 11:43:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7640A43FD; Sun, 3 Feb 2013 11:47:48 -0500 (EST) From: Sam Hartman To: References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> Date: Sun, 03 Feb 2013 11:47:48 -0500 In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> (yoshihiro ohba's message of "Sun, 3 Feb 2013 16:33:12 +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] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 03 Feb 2013 16:47:57 -0000 >>>>> writes: > Hi Alejandro, In order to maintain deal with RADIUS clients and > servers that do not support fragmentation, it would be cleaner to > use RADIUS capability negotiations > (draft-halwasia-radext-capability-negotiation) to negotiate use of > More-Data-Pending attribute. This would How widely implemented in that? From aland@deployingradius.com Sun Feb 3 08:51:37 2013 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 DD54021F8639 for ; Sun, 3 Feb 2013 08:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0545vtfKf4yy for ; Sun, 3 Feb 2013 08:51:37 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51A1021F8622 for ; Sun, 3 Feb 2013 08:51:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 067792240FA1; Sun, 3 Feb 2013 17:51:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6jIN-Cn+4U9; Sun, 3 Feb 2013 17:51:32 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 03A8C2240F52; Sun, 3 Feb 2013 17:51:31 +0100 (CET) Message-ID: <510E9592.5000303@deployingradius.com> Date: Sun, 03 Feb 2013 11:51:30 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 03 Feb 2013 16:51:38 -0000 Sam Hartman wrote: > How widely implemented in that? Not at all. It's still in the preliminary discussion phase. Alan DeKok. From aland@deployingradius.com Sun Feb 3 09:02:22 2013 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 CB2AE21F841D for ; Sun, 3 Feb 2013 09:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKellKJHLqBw for ; Sun, 3 Feb 2013 09:02:22 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A949121F8319 for ; Sun, 3 Feb 2013 09:02:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 24CAE2240FA1; Sun, 3 Feb 2013 18:02:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deEEmIhhg7Kq; Sun, 3 Feb 2013 18:02:20 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id F220622404AC; Sun, 3 Feb 2013 18:02:19 +0100 (CET) Message-ID: <510E981A.7000004@deployingradius.com> Date: Sun, 03 Feb 2013 12:02:18 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 03 Feb 2013 17:02:22 -0000 yoshihiro.ohba@toshiba.co.jp wrote: > In order to maintain deal with RADIUS clients and servers that do not > support fragmentation, it would be cleaner to use RADIUS capability > negotiations (draft-halwasia-radext-capability-negotiation) to negotiate > use of More-Data-Pending attribute. This would > allow all RADIUS messages to use More-Data-Pending attribute for > fragmentation with no exception. The existence of a More-Data-Pending in an Access-Request indicates that the client supports fragmentation. Servers which do not understand that attribute will return an Access-Accept / Reject instead of an Access-Challenge. The client will realize that it has not sent all of the data it wants to send, and will terminate the users session. A server supporting fragmentation will start off by sending an Access-Accept with Service-Type = Additional-Authorization. Clients not supporting fragmentation will not recognize the Service-Type, and under RFC 2865 Section 5.6, treat it as Access-Reject. There is no need for capability negotiation here. If a client needs to send a lot of data, it either sends all of the data, or terminates the users session. If a server needs to send a lot of data, it either sends all of the data, or sends a Service-Type which causes the client to terminate the users session. It would be *nice* to know this prior to terminating the session. Simply rejecting the user unexpectedly is safe, but unfriendly. Any capability negotiation here is a user interface problem. It helps the user or administrator understand why a session was terminated. It doesn't help the RADIUS client or server. Alan DeKok. From hartmans@painless-security.com Sun Feb 3 10:04:30 2013 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 DCDAD21F8622 for ; Sun, 3 Feb 2013 10:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgrqeCB0VOdP for ; Sun, 3 Feb 2013 10:04:30 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 678A321F8619 for ; Sun, 3 Feb 2013 10:04:30 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id F02B920393; Sun, 3 Feb 2013 13:00:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 59AF143FD; Sun, 3 Feb 2013 13:04:25 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510E9592.5000303@deployingradius.com> Date: Sun, 03 Feb 2013 13:04:25 -0500 In-Reply-To: <510E9592.5000303@deployingradius.com> (Alan DeKok's message of "Sun, 03 Feb 2013 11:51:30 -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 Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 03 Feb 2013 18:04:31 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> How widely implemented in that? Alan> Not at all. Alan> It's still in the preliminary discussion phase. OK. Because of the abfab dependency I'd strongly prefer that whatever we do for radius fragmentation depend on drafts that have at least reached the wglc stage. So, for example the dependency on radius-extensions doesn't bother me at all, but a dependency on another draft that has neither wide implementation nor has been adopted would concern me significantly. I also agree with Alan's comments about why negotiation is not a strict requirement. From ietf@augustcellars.com Sun Feb 3 10:47:04 2013 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 4984A21F873C for ; Sun, 3 Feb 2013 10:47:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbh5FxiTOBdA for ; Sun, 3 Feb 2013 10:47:03 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id BF87A21F86D2 for ; Sun, 3 Feb 2013 10:47:03 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6744F38F07; Sun, 3 Feb 2013 10:47:03 -0800 (PST) From: "Jim Schaad" To: "'Alan DeKok'" References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510E981A.7000004@deployingradius.com> In-Reply-To: <510E981A.7000004@deployingradius.com> Date: Sun, 3 Feb 2013 10:46:36 -0800 Message-ID: <002201ce023e$cd22f050$6768d0f0$@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: AQMPjOO1VvNtfumM4TxxGqnrOnKz6wEwD1sFAmC9tJ8BsDVpvAJZ9z8NAZA1KO+VnApAcA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 03 Feb 2013 18:47:04 -0000 This behavior should probably be in the document. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Alan DeKok > Sent: Sunday, February 03, 2013 9:02 AM > To: yoshihiro.ohba@toshiba.co.jp > Cc: abfab@ietf.org > Subject: Re: [abfab] [radext] New Version Notification for draft-perez- > radext-radius-fragmentation-04.txt > > yoshihiro.ohba@toshiba.co.jp wrote: > > In order to maintain deal with RADIUS clients and servers that do not > > support fragmentation, it would be cleaner to use RADIUS capability > > negotiations (draft-halwasia-radext-capability-negotiation) to > > negotiate use of More-Data-Pending attribute. This would allow all > > RADIUS messages to use More-Data-Pending attribute for fragmentation > > with no exception. > > The existence of a More-Data-Pending in an Access-Request indicates that > the client supports fragmentation. Servers which do not understand that > attribute will return an Access-Accept / Reject instead of an Access- > Challenge. The client will realize that it has not sent all of the data it wants to > send, and will terminate the users session. > > A server supporting fragmentation will start off by sending an Access-Accept > with Service-Type = Additional-Authorization. Clients not supporting > fragmentation will not recognize the Service-Type, and under RFC 2865 > Section 5.6, treat it as Access-Reject. > > There is no need for capability negotiation here. If a client needs to send a > lot of data, it either sends all of the data, or terminates the users session. If a > server needs to send a lot of data, it either sends all of the data, or sends a > Service-Type which causes the client to terminate the users session. > > It would be *nice* to know this prior to terminating the session. > Simply rejecting the user unexpectedly is safe, but unfriendly. > > Any capability negotiation here is a user interface problem. It helps the user > or administrator understand why a session was terminated. It doesn't help > the RADIUS client or server. > > Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alex@um.es Mon Feb 4 00:12:16 2013 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 188F521F8605 for ; Mon, 4 Feb 2013 00:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPeTg5ByL18U for ; Mon, 4 Feb 2013 00:12:11 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 19CA021F88EE for ; Mon, 4 Feb 2013 00:12:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 5FF0A5D577; Mon, 4 Feb 2013 09:12: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 RUsxEPhRd4Qy; Mon, 4 Feb 2013 09:12:06 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id 7F2B75D54D; Mon, 4 Feb 2013 09:12:03 +0100 (CET) Message-ID: <510F6D53.7040803@um.es> Date: Mon, 04 Feb 2013 09:12:03 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> Content-Type: multipart/alternative; boundary="------------020903050209050105040507" Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 08:12:16 -0000 This is a multi-part message in MIME format. --------------020903050209050105040507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 03/02/13 17:33, yoshihiro.ohba@toshiba.co.jp escribió: > > Hi Alejandro, > > In order to maintain deal with RADIUS clients and servers that do not > support fragmentation, it would be cleaner to use RADIUS capability > negotiations (draft-halwasia-radext-capability-negotiation) to > negotiate use of More-Data-Pending attribute. This would > > allow all RADIUS messages to use More-Data-Pending attribute for > fragmentation with no exception. > That would be an option. But I would rather do not depend on other drafts, specially not WG draft. We may need some capability negotiation within the fragmentation mechanisms. Regards, Alejandro > Yoshihiro Ohba > > *From:*abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] *On > Behalf Of *Alejandro Perez Mendez > *Sent:* Wednesday, January 30, 2013 5:46 PM > *To:* abfab@ietf.org > *Subject:* Re: [abfab] [radext] New Version Notification for > draft-perez-radext-radius-fragmentation-04.txt > > Hello Yoshi, Rafa, > > see some comments inline: > > Dear all, > > > > we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. > > > > Please, see some comments inline. > > > > "Here is my review of draft-perez-radext-radius-fragmentation-04. > > > > Section 1: > > > > "Each RADIUS packet can transport several RADIUS attributes, to convey > > the necessary information to the other peer, up to a maximum size of 4 > > KB of total data (including RADIUS packet headers)." > > > > [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the > > document since "KB" can mean 4000 bytes in some cases. > > > > [Rafa] OK. > > > > > > "A reference-based mechanism is also proposed in [RFC6158], where > > attributes can be obtained through an out-of-band protocol." > > > > [YO} Meaning of this sentence is unclear. Does this mean RADIUS > > attributes are obtained through some other protocol instead of RADIUS? > > Or does this mean the actual format of the Value field of a RADIUS > > Attribute is defined in other protocol specification? In the latter > > case, it should be also mentioned that RADIUS-EAP is categorized as the > > mechanism defined in RFC 6158. > > > > [Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more. > > > > "However, there are no proposals to deal with fragmentation at a packet > > level, when the total size exceeds the 4 KB limit imposed by the RADIUS > > specification." > > > > [YO] Meaning of "at a packet level" is unclear. Suggested change: > > "However, there are no proposals to fragement a large-sized RADIUS > > packet into multiple small-sized RADIUS packets, where the length of the > > original (unfragmented) RADIUS packet exceeds the 4096-octet limit > > imposed by the RADIUS specification." > > > > [Rafa] This sounds good. > > > > > > Section 2: > > > > [YO] I am not sure if "T" flag is needed. In other words, it should be > > possible to change [I-D.ietf-radext-radius-extensions] to simply allow a > > fragment with the M-flag cleared not to be included in a non-last chunk. > > > > [Rafa] > > > > Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now. > > > > In any case, we may ask authors of [I-D.ietf-radext-radius-extensions]. > > > > Section 3.3: > > > > [YO] Access-Accept fragmentation scheme looks odd compared to > > Access-Request and Access-Challenge fragmentation schemes. There are > > several questions related to this: (1) Why multiple chunks of > > Access-Accept cannot be sent without having an Access-Challange to be > > sent in between? (2) Why an Access-Accept cannot contain a > > More-Data-Pending attribute instead of using a new service type value? > > (3) How can a large attributue that is allowed to appear in an > > Access-Accept but not allowed to appear in Access-Challenge be fragmented? > > > > [Rafa] > > > > 1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3). > > > > 2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth]. > > > > 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think? > > > This alternative sounds good to me. However, I think there may be > still some advantages of using Service-Type instead of (or in addition > to) More-Data-Pending for Access-Accept packets. > > If the NAS/RP does not know anything about fragmentation (i.e. does > not support this draft), it may take the first Access-Accept chunk, > ignore the More-Data-Pending attribute (it is unknown for it), and > process it as a complete packet. As no additional round-trip is > mandatory after an Access-Accept packet, it may be problematic as it > is possible that part of the obligations from the AS to the NAS (e.g. > FW policies) are not enforced. > > However, RFC 2865 says that (in relation to Access-Accept packets): > > A NAS is not > required to implement all of these service types, and MUST treat > unknown or unsupported Service-Types as though an Access-Reject > had been received instead > > > Therefore, if the NAS does not understand > Service-Type=AdditionalAuthorization, the Access-Accept packet will be > interpreted as an Access-Reject one, which seems to be the most > reasonable approach. > > This sort of problems seem to not be critical with Access-Challenge > packets, as the NAS is expected to generate a new Access-Request > packet afterwards, and the AS can detect whether fragmentation was > supported. > > Regards, > Alejandro > > > Section 8: > > [YO] Security Considerations section is too short. Security mechansims > that are needed for secure operation of the proposed fragmentation > mechanism needs to be described in this section. > > [Rafa] Yes this section will be improved. Jim also raised comments about it. > > Section 9: > > [YO] I don't think the following statement is true: "This document has > no actions for IANA." because Section 6 defines new attributes. > > [Rafa] Correct. This needs to be fixed. > > Best Regards, > Yoshihiro Ohba > " > > Best regards. > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > --------------020903050209050105040507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 03/02/13 17:33, yoshihiro.ohba@toshiba.co.jp escribió:

Hi Alejandro,

 

In order to maintain deal with RADIUS clients and servers that do not support fragmentation, it would be cleaner to use RADIUS capability negotiations (draft-halwasia-radext-capability-negotiation) to negotiate use of More-Data-Pending attribute.  This would

allow all RADIUS messages to use More-Data-Pending attribute for fragmentation with no exception.


That would be an option. But I would rather do not depend on other drafts, specially not WG draft. We may need some capability negotiation within the fragmentation mechanisms.

Regards,
Alejandro

 

Yoshihiro Ohba

 

 

 

From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Alejandro Perez Mendez
Sent: Wednesday, January 30, 2013 5:46 PM
To: abfab@ietf.org
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

 

Hello Yoshi, Rafa,

see some comments inline:

 

Dear all,
 
we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. 
 
Please, see some comments inline.
 
"Here is my review of draft-perez-radext-radius-fragmentation-04.
 
Section 1:
 
"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."
 
[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.
 
[Rafa] OK.
 
 
"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."
 
[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.
 
[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.
 
"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."
 
[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."
 
[Rafa] This sounds good.
 
 
Section 2:
 
[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.
 
[Rafa] 
 
Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.
 
In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].
 
Section 3.3:
 
[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be fragmented?
 
[Rafa]
 
1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).
 
2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].
 
3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think? 


This alternative sounds good to me. However, I think there may be still some advantages of using Service-Type instead of (or in addition to) More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not support this draft), it may take the first Access-Accept chunk, ignore the More-Data-Pending attribute (it is unknown for it), and process it as a complete packet. As no additional round-trip is mandatory after an Access-Accept packet, it may be problematic as it is possible that part of the obligations from the AS to the NAS (e.g. FW policies) are not enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):

A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead


Therefore, if the NAS does not understand Service-Type=AdditionalAuthorization, the Access-Accept packet will be interpreted as an Access-Reject one, which seems to be the most reasonable approach.

This sort of problems seem to not be critical with Access-Challenge packets, as the NAS is expected to generate a new Access-Request packet afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro


Section 8:
 
[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.
 
[Rafa] Yes this section will be improved. Jim also raised comments about it.
 
Section 9:
 
[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.
 
[Rafa] Correct. This needs to be fixed.
 
Best Regards,
Yoshihiro Ohba
"
 
Best regards.
 
-------------------------------------------------------
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
-------------------------------------------------------
 
 
 
 
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

 


--------------020903050209050105040507-- From alex@um.es Mon Feb 4 00:19:34 2013 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 9BD3121F8901 for ; Mon, 4 Feb 2013 00:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHnev29PcftT for ; Mon, 4 Feb 2013 00:19:34 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id A1A7E21F874B for ; Mon, 4 Feb 2013 00:19:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 514F3536B4; Mon, 4 Feb 2013 09:19:32 +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 zBynyc64CizN; Mon, 4 Feb 2013 09:19:32 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 1BC4553691; Mon, 4 Feb 2013 09:19:30 +0100 (CET) Message-ID: <510F6F12.3050402@um.es> Date: Mon, 04 Feb 2013 09:19:30 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alan DeKok References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510E981A.7000004@deployingradius.com> In-Reply-To: <510E981A.7000004@deployingradius.com> Content-Type: multipart/alternative; boundary="------------070007080808040405030804" Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 08:19:34 -0000 This is a multi-part message in MIME format. --------------070007080808040405030804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 03/02/13 18:02, Alan DeKok escribió: > yoshihiro.ohba@toshiba.co.jp wrote: >> In order to maintain deal with RADIUS clients and servers that do not >> support fragmentation, it would be cleaner to use RADIUS capability >> negotiations (draft-halwasia-radext-capability-negotiation) to negotiate >> use of More-Data-Pending attribute. This would >> allow all RADIUS messages to use More-Data-Pending attribute for >> fragmentation with no exception. > The existence of a More-Data-Pending in an Access-Request indicates > that the client supports fragmentation. Servers which do not understand > that attribute will return an Access-Accept / Reject instead of an > Access-Challenge. Why? I assumed they will ignore the MDP attribute, and generate a Challenge if they understand the chunk as a valid Access-Request. From RFC 2865 A RADIUS server MAY ignore Attributes with an unknown Type. > The client will realize that it has not sent all of > the data it wants to send, and will terminate the users session. > > A server supporting fragmentation will start off by sending an > Access-Accept with Service-Type = Additional-Authorization. What if the server wants to send a fragmented Challenge *before* sending the Access-Accept? Then, it will send the More-Data-Pending attribute, not the Service-Type = AddAuth. Again, the client may ignore the unknown attribute and try to decode the chunk as a "regular" Access-Challenge. > Clients not > supporting fragmentation will not recognize the Service-Type, and under > RFC 2865 Section 5.6, treat it as Access-Reject. That's true for Access-Accept, not for Access-Challenge packets. > > There is no need for capability negotiation here. If a client needs > to send a lot of data, it either sends all of the data, or terminates > the users session. If a server needs to send a lot of data, it either > sends all of the data, or sends a Service-Type which causes the client > to terminate the users session. > > It would be *nice* to know this prior to terminating the session. > Simply rejecting the user unexpectedly is safe, but unfriendly. I agree with this. > Any capability negotiation here is a user interface problem. It helps > the user or administrator understand why a session was terminated. It > doesn't help the RADIUS client or server. And also agree with this. > > Alan DeKok. --------------070007080808040405030804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 03/02/13 18:02, Alan DeKok escribió:
yoshihiro.ohba@toshiba.co.jp wrote:

In order to maintain deal with RADIUS clients and servers that do not
support fragmentation, it would be cleaner to use RADIUS capability
negotiations (draft-halwasia-radext-capability-negotiation) to negotiate
use of More-Data-Pending attribute.  This would
allow all RADIUS messages to use More-Data-Pending attribute for
fragmentation with no exception.

  The existence of a More-Data-Pending in an Access-Request indicates
that the client supports fragmentation.  Servers which do not understand
that attribute will return an Access-Accept / Reject instead of an
Access-Challenge.

Why? I assumed they will ignore the MDP attribute, and generate a Challenge if they understand the chunk as a valid Access-Request.

From RFC 2865
A RADIUS server MAY ignore Attributes with an unknown Type.

The client will realize that it has not sent all of
the data it wants to send, and will terminate the users session.

  A server supporting fragmentation will start off by sending an
Access-Accept with Service-Type = Additional-Authorization.

What if the server wants to send a fragmented Challenge *before* sending the Access-Accept? Then, it will send the More-Data-Pending attribute, not the Service-Type = AddAuth. Again, the client may ignore the unknown attribute and try to decode the chunk as a "regular" Access-Challenge. 


Clients not
supporting fragmentation will not recognize the Service-Type, and under
RFC 2865 Section 5.6, treat it as Access-Reject.

That's true for Access-Accept, not for Access-Challenge packets.


  There is no need for capability negotiation here.  If a client needs
to send a lot of data, it either sends all of the data, or terminates
the users session.  If a server needs to send a lot of data, it either
sends all of the data, or sends a Service-Type which causes the client
to terminate the users session.

  It would be *nice* to know this prior to terminating the session.
Simply rejecting the user unexpectedly is safe, but unfriendly.

I agree with this.

  Any capability negotiation here is a user interface problem.  It helps
the user or administrator understand why a session was terminated.  It
doesn't help the RADIUS client or server.
And also agree with this.


  Alan DeKok.

--------------070007080808040405030804-- From yoshihiro.ohba@toshiba.co.jp Mon Feb 4 04:01:12 2013 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 D576B21F868D for ; Mon, 4 Feb 2013 04:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfxeZh6nYCvm for ; Mon, 4 Feb 2013 04:01:11 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id E884F21F8645 for ; Mon, 4 Feb 2013 04:01:10 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r14C19kE021122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 21:01:09 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r14C19IP030611; Mon, 4 Feb 2013 21:01:09 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 1003; Mon, 4 Feb 2013 21:01:09 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r14C19re030608; Mon, 4 Feb 2013 21:01:09 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r14C19IG018870; Mon, 4 Feb 2013 21:01:09 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA18868; Mon, 4 Feb 2013 21:01:09 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r14C18B8019896; Mon, 4 Feb 2013 21:01:08 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r14C18mq028841; Mon, 4 Feb 2013 21:01:08 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.20]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 21:01:08 +0900 From: To: Thread-Topic: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt Thread-Index: AQHOAq9afMZDkob8D0CRfDRDujwWF5hpmClw Date: Mon, 4 Feb 2013 12:01:08 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510F6D53.7040803@um.es> In-Reply-To: <510F6D53.7040803@um.es> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.167] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78BE962C1tgxml338toshibalo_" MIME-Version: 1.0 Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:01:13 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78BE962C1tgxml338toshibalo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdWdnZXN0IHRvIGludmVzdGlnYXRlIGFsbCBjb3JuZXIgY2FzZXMgYmVmb3JlIG1ha2luZyBh IGRlY2lzaW9uIG9uIGEgcGFydGljdWxhciBtZWNoYW5pc20uICBUaGUgY29ybmVyIGNhc2VzIGFy ZToNCg0KDQooYSkgICAgQ2xpZW50IHN1cHBvcnRzIGZyYWdtZW50YXRpb24gYW5kIHNlcnZlciBk b2VzIG5vdCBzdXBwb3J0IGZyYWdtZW50YXRpb24NCihhLTEpIEFjY2Vzcy1SZXF1ZXN0IGlzIGZy YWdtZW50ZWQNCihhLTIpIEFjY2Vzcy1DaGFsbGVuZ2UgaXMgZnJhZ21lbnRlZA0KKGEtMykgQWNj ZXNzLUFjY2VwdCBpcyBmcmFnbWVudGVkDQoNCihiKSAgIENsaWVudCBkb2VzIG5vdCBzdXBwb3J0 IGZyYWdtZW50YXRpb24gYW5kIHNlcnZlciBzdXBwb3J0cyBmcmFnbWVudGF0aW9uDQoNCihiLTEp IEFjY2Vzcy1SZXF1ZXN0IGlzIGZyYWdtZW50ZWQNCg0KKGItMikgQWNjZXNzLUNoYWxsZW5nZSBp cyBmcmFnbWVudGVkDQoNCihiLTMpIEFjY2Vzcy1BY2NlcHQgaXMgZnJhZ21lbnRlZA0KDQoNCllv c2hpaGlybyBPaGJhDQoNCg0KDQpGcm9tOiBBbGVqYW5kcm8gUGVyZXogTWVuZGV6IFttYWlsdG86 YWxleEB1bS5lc10NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDQsIDIwMTMgNToxMiBQTQ0KVG86 IG9oYmEgeW9zaGloaXJvKOWkp+WgtCDnvqnmtIsg4peL77yy77yk77yj4pah77yu77yz77ysKQ0K Q2M6IGFiZmFiQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2FiZmFiXSBbcmFkZXh0XSBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBlcmV6LXJhZGV4dC1yYWRpdXMtZnJhZ21lbnRh dGlvbi0wNC50eHQNCg0KDQpFbCAwMy8wMi8xMyAxNzozMywgeW9zaGloaXJvLm9oYmFAdG9zaGli YS5jby5qcDxtYWlsdG86eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcD4gZXNjcmliacOzOg0K SGkgQWxlamFuZHJvLA0KDQpJbiBvcmRlciB0byBtYWludGFpbiBkZWFsIHdpdGggUkFESVVTIGNs aWVudHMgYW5kIHNlcnZlcnMgdGhhdCBkbyBub3Qgc3VwcG9ydCBmcmFnbWVudGF0aW9uLCBpdCB3 b3VsZCBiZSBjbGVhbmVyIHRvIHVzZSBSQURJVVMgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbnMgKGRy YWZ0LWhhbHdhc2lhLXJhZGV4dC1jYXBhYmlsaXR5LW5lZ290aWF0aW9uKSB0byBuZWdvdGlhdGUg dXNlIG9mIE1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0ZS4gIFRoaXMgd291bGQNCmFsbG93IGFs bCBSQURJVVMgbWVzc2FnZXMgdG8gdXNlIE1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0ZSBmb3Ig ZnJhZ21lbnRhdGlvbiB3aXRoIG5vIGV4Y2VwdGlvbi4NCg0KVGhhdCB3b3VsZCBiZSBhbiBvcHRp b24uIEJ1dCBJIHdvdWxkIHJhdGhlciBkbyBub3QgZGVwZW5kIG9uIG90aGVyIGRyYWZ0cywgc3Bl Y2lhbGx5IG5vdCBXRyBkcmFmdC4gV2UgbWF5IG5lZWQgc29tZSBjYXBhYmlsaXR5IG5lZ290aWF0 aW9uIHdpdGhpbiB0aGUgZnJhZ21lbnRhdGlvbiBtZWNoYW5pc21zLg0KDQpSZWdhcmRzLA0KQWxl amFuZHJvDQoNCg0KDQpZb3NoaWhpcm8gT2hiYQ0KDQoNCg0KRnJvbTogYWJmYWItYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86YWJmYWItYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzphYmZhYi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxlamFuZHJvIFBlcmV6IE1lbmRleg0KU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDU6NDYgUE0NClRvOiBhYmZhYkBpZXRmLm9yZzxt YWlsdG86YWJmYWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2FiZmFiXSBbcmFkZXh0XSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBlcmV6LXJhZGV4dC1yYWRpdXMtZnJhZ21l bnRhdGlvbi0wNC50eHQNCg0KSGVsbG8gWW9zaGksIFJhZmEsDQoNCnNlZSBzb21lIGNvbW1lbnRz IGlubGluZToNCg0KDQpEZWFyIGFsbCwNCg0KDQoNCndlIGhhdmUgcmVjZWl2ZWQgYWRkaXRpb25h bCBjb21tZW50cyBmcm9tIFlvc2hpaGlybyBPaGJhIChtYW55IHRoYW5rcykgdGhhdCB3ZSBzaGFy ZSB3aXRoIHlvdS4NCg0KDQoNClBsZWFzZSwgc2VlIHNvbWUgY29tbWVudHMgaW5saW5lLg0KDQoN Cg0KIkhlcmUgaXMgbXkgcmV2aWV3IG9mIGRyYWZ0LXBlcmV6LXJhZGV4dC1yYWRpdXMtZnJhZ21l bnRhdGlvbi0wNC4NCg0KDQoNClNlY3Rpb24gMToNCg0KDQoNCiJFYWNoIFJBRElVUyBwYWNrZXQg Y2FuIHRyYW5zcG9ydCBzZXZlcmFsIFJBRElVUyBhdHRyaWJ1dGVzLCB0byBjb252ZXkNCg0KdGhl IG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiB0byB0aGUgb3RoZXIgcGVlciwgdXAgdG8gYSBtYXhpbXVt IHNpemUgb2YgNA0KDQpLQiBvZiB0b3RhbCBkYXRhIChpbmNsdWRpbmcgUkFESVVTIHBhY2tldCBo ZWFkZXJzKS4iDQoNCg0KDQpbWU9dIEkgc3VnZ2VzdCB0byByZXBsYWNlICI0IEtCIiB3aXRoICI0 MDk2IGJ5dGVzIiB0aHJvdWdob3V0IHRoZQ0KDQpkb2N1bWVudCBzaW5jZSAiS0IiIGNhbiBtZWFu IDQwMDAgYnl0ZXMgaW4gc29tZSBjYXNlcy4NCg0KDQoNCltSYWZhXSBPSy4NCg0KDQoNCg0KDQoi QSByZWZlcmVuY2UtYmFzZWQgbWVjaGFuaXNtIGlzIGFsc28gcHJvcG9zZWQgaW4gW1JGQzYxNThd LCB3aGVyZQ0KDQphdHRyaWJ1dGVzIGNhbiBiZSBvYnRhaW5lZCB0aHJvdWdoIGFuIG91dC1vZi1i YW5kIHByb3RvY29sLiINCg0KDQoNCltZT30gTWVhbmluZyBvZiB0aGlzIHNlbnRlbmNlIGlzIHVu Y2xlYXIuIERvZXMgdGhpcyBtZWFuIFJBRElVUw0KDQphdHRyaWJ1dGVzIGFyZSBvYnRhaW5lZCB0 aHJvdWdoIHNvbWUgb3RoZXIgcHJvdG9jb2wgaW5zdGVhZCBvZiBSQURJVVM/DQoNCk9yIGRvZXMg dGhpcyBtZWFuIHRoZSBhY3R1YWwgZm9ybWF0IG9mIHRoZSBWYWx1ZSBmaWVsZCBvZiBhIFJBRElV Uw0KDQpBdHRyaWJ1dGUgaXMgZGVmaW5lZCBpbiBvdGhlciBwcm90b2NvbCBzcGVjaWZpY2F0aW9u PyBJbiB0aGUgbGF0dGVyDQoNCmNhc2UsIGl0IHNob3VsZCBiZSBhbHNvIG1lbnRpb25lZCB0aGF0 IFJBRElVUy1FQVAgaXMgY2F0ZWdvcml6ZWQgYXMgdGhlDQoNCm1lY2hhbmlzbSBkZWZpbmVkIGlu IFJGQyA2MTU4Lg0KDQoNCg0KW1JhZmFdIEl0IGlzIHJlZmVycmluZyB0aGUgdmFsdWUgb2YgdGhl IGF0dHJpYnV0ZXMgY2FuIGJlIG9idGFpbmVkIGJ5IG90aGVyIHByb3RvY29sIGluc3RlYWQgb2Yg UkFESVVTLiBUaGlzIGlzIGNvbWluZyBmcm9tIGEgcHJldmlvdXMgY29tbWVudCByZWxhdGVkIHdp dGggU0FNTCB0cmFuc3BvcnQuIEluc3RlYWQgb2YgdHJhbnNwb3J0aW5nIHRoZSByZWFsIFNBTUwg bWVzc2FnZXMgYW4gVVJMIGlzIHNldCBhcyBhdHRyaWJ1dGUgdmFsdWUuIFdlIGNhbiB0cnkgdG8g Y2xhcmlmeSBhIGxpdHRsZSBiaXQgbW9yZS4NCg0KDQoNCiJIb3dldmVyLCB0aGVyZSBhcmUgbm8g cHJvcG9zYWxzIHRvIGRlYWwgd2l0aCBmcmFnbWVudGF0aW9uIGF0IGEgcGFja2V0DQoNCmxldmVs LCB3aGVuIHRoZSB0b3RhbCBzaXplIGV4Y2VlZHMgdGhlIDQgS0IgbGltaXQgaW1wb3NlZCBieSB0 aGUgUkFESVVTDQoNCnNwZWNpZmljYXRpb24uIg0KDQoNCg0KW1lPXSBNZWFuaW5nIG9mICJhdCBh IHBhY2tldCBsZXZlbCIgaXMgdW5jbGVhci4gU3VnZ2VzdGVkIGNoYW5nZToNCg0KIkhvd2V2ZXIs IHRoZXJlIGFyZSBubyBwcm9wb3NhbHMgdG8gZnJhZ2VtZW50IGEgbGFyZ2Utc2l6ZWQgUkFESVVT DQoNCnBhY2tldCBpbnRvIG11bHRpcGxlIHNtYWxsLXNpemVkIFJBRElVUyBwYWNrZXRzLCB3aGVy ZSB0aGUgbGVuZ3RoIG9mIHRoZQ0KDQpvcmlnaW5hbCAodW5mcmFnbWVudGVkKSBSQURJVVMgcGFj a2V0IGV4Y2VlZHMgdGhlIDQwOTYtb2N0ZXQgbGltaXQNCg0KaW1wb3NlZCBieSB0aGUgUkFESVVT IHNwZWNpZmljYXRpb24uIg0KDQoNCg0KW1JhZmFdIFRoaXMgc291bmRzIGdvb2QuDQoNCg0KDQoN Cg0KU2VjdGlvbiAyOg0KDQoNCg0KW1lPXSBJIGFtIG5vdCBzdXJlIGlmICJUIiBmbGFnIGlzIG5l ZWRlZC4gSW4gb3RoZXIgd29yZHMsIGl0IHNob3VsZCBiZQ0KDQpwb3NzaWJsZSB0byBjaGFuZ2Ug W0ktRC5pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9uc10gdG8gc2ltcGx5IGFsbG93IGENCg0K ZnJhZ21lbnQgd2l0aCB0aGUgTS1mbGFnIGNsZWFyZWQgbm90IHRvIGJlIGluY2x1ZGVkIGluIGEg bm9uLWxhc3QgY2h1bmsuDQoNCg0KDQpbUmFmYV0NCg0KDQoNClllcywgdGhhdCBtYXkgYmUgcG9z c2libGUuIEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IHdlIHdhbnRlZCB0byBrZWVwIHVubW9kaWZp ZWQgYW55IGV4aXN0aW5nIEktRCBieSB0aGUgdGltZSBiZWluZy4gTW9yZW92ZXIsIFtJLUQuaWV0 Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lvbnNdIGhhcyBub3QgY29uc2lkZXJlZCB0aGF0IGZyYWdt ZW50YXRpb24gYXQgcGFja2V0IGxldmVsIG1heSBvY2N1ciBmb3Igb2J2aW91cyByZWFzb25zLiBN b3Jlb3ZlciwgdGhhdCBJLUQgaXMgaW4gYSBtYXR1cmUgc3RhdGUgbm93Lg0KDQoNCg0KSW4gYW55 IGNhc2UsIHdlIG1heSBhc2sgYXV0aG9ycyBvZiBbSS1ELmlldGYtcmFkZXh0LXJhZGl1cy1leHRl bnNpb25zXS4NCg0KDQoNClNlY3Rpb24gMy4zOg0KDQoNCg0KW1lPXSBBY2Nlc3MtQWNjZXB0IGZy YWdtZW50YXRpb24gc2NoZW1lIGxvb2tzIG9kZCBjb21wYXJlZCB0bw0KDQpBY2Nlc3MtUmVxdWVz dCBhbmQgQWNjZXNzLUNoYWxsZW5nZSBmcmFnbWVudGF0aW9uIHNjaGVtZXMuIFRoZXJlIGFyZQ0K DQpzZXZlcmFsIHF1ZXN0aW9ucyByZWxhdGVkIHRvIHRoaXM6ICgxKSBXaHkgbXVsdGlwbGUgY2h1 bmtzIG9mDQoNCkFjY2Vzcy1BY2NlcHQgY2Fubm90IGJlIHNlbnQgd2l0aG91dCBoYXZpbmcgYW4g QWNjZXNzLUNoYWxsYW5nZSB0byBiZQ0KDQpzZW50IGluIGJldHdlZW4/ICgyKSBXaHkgYW4gQWNj ZXNzLUFjY2VwdCBjYW5ub3QgY29udGFpbiBhDQoNCk1vcmUtRGF0YS1QZW5kaW5nIGF0dHJpYnV0 ZSBpbnN0ZWFkIG9mIHVzaW5nIGEgbmV3IHNlcnZpY2UgdHlwZSB2YWx1ZT8NCg0KKDMpIEhvdyBj YW4gYSBsYXJnZSBhdHRyaWJ1dHVlIHRoYXQgaXMgYWxsb3dlZCB0byBhcHBlYXIgaW4gYW4NCg0K QWNjZXNzLUFjY2VwdCBidXQgbm90IGFsbG93ZWQgdG8gYXBwZWFyIGluIEFjY2Vzcy1DaGFsbGVu Z2UgYmUgZnJhZ21lbnRlZD8NCg0KDQoNCltSYWZhXQ0KDQoNCg0KMSkgV2Ugd2FudGVkIHRvIGJl IHN5bW1ldHJpYyBpbiB0aGUgZGVzaWduLCB3aGVyZSBBY2Nlc3MtUmVxdWVzdC9BY2Nlc3MtQ2hh bGxlbmdlIGV4Y2hhbmdlIGlzIHVzZWQgc29tZWhvdyBmb3IgZnJhZ21lbnRhdGlvbiBzdXBwb3J0 LiBJbiBhbnkgY2FzZSwgd2UgaGF2ZSBhbHNvIGNvbnNpZGVyZWQgdGhlIHVzYWdlIG9mIEFjY2Vz cy1BY2NlcHQgd2l0aCBTZXJ2aWNlLVR5cGVbQWRkQXV0aF0gc28gdW50aWwgYWxsIHRoZSBhdHRy aWJ1dGVzIGluIHRoZSB3aG9sZSBSQURJVVMgQWNjZXNzLUFjY2VwdCBhcmUgZmluYWxseSBzZW50 IHRoZSBleGNoYW5nZSB3aWxsIGJlIEFjY2Vzcy1SZXF1ZXN0L0FjY2Vzcy1BY2NlcHQgKFNlcnZp Y2UtVHlwZVtBZGRBdXRoXSksIHdoaWxlIHRoZSBsYXN0IG9uZSBpcyBzaW1wbHkgQWNjZXNzLVJl cXVlc3QvQWNjZXNzLUFjY2VwdC4gVGhpcyBtb2RlIG9mIG9wZXJhdGlvbiB3b3VsZCBzb2x2ZSB5 b3VyIHF1ZXN0aW9uIDMpLg0KDQoNCg0KMikgSSB0aGluayB0aGF0IG1heSBiZSBhbHNvIHBvc3Np YmxlLiBJbiBhbnkgY2FzZSwgSSB0aGluayBBbGFuIG9yIEFsZXggY2FuIGVsYWJvcmF0ZSBhIGxp dHRsZSBiaXQgYSBtb3JlIGFib3V0IHRoZSB1c2FnZSBvZiBTZXJ2aWNlLVR5cGVbQWRkQXV0aF0u DQoNCg0KDQozKSBQcmVjaXNlbHksIHRyeWluZyB0byBhbnN3ZXIgdGhpcyBxdWVzdGlvbiB3ZSBq dXN0IGNhbWUgdXAgd2l0aCB0aGUgc29sdXRpb24gaW4gMSkuIFdoYXQgZG8geW91IHRoaW5rPw0K DQpUaGlzIGFsdGVybmF0aXZlIHNvdW5kcyBnb29kIHRvIG1lLiBIb3dldmVyLCBJIHRoaW5rIHRo ZXJlIG1heSBiZSBzdGlsbCBzb21lIGFkdmFudGFnZXMgb2YgdXNpbmcgU2VydmljZS1UeXBlIGlu c3RlYWQgb2YgKG9yIGluIGFkZGl0aW9uIHRvKSBNb3JlLURhdGEtUGVuZGluZyBmb3IgQWNjZXNz LUFjY2VwdCBwYWNrZXRzLg0KDQpJZiB0aGUgTkFTL1JQIGRvZXMgbm90IGtub3cgYW55dGhpbmcg YWJvdXQgZnJhZ21lbnRhdGlvbiAoaS5lLiBkb2VzIG5vdCBzdXBwb3J0IHRoaXMgZHJhZnQpLCBp dCBtYXkgdGFrZSB0aGUgZmlyc3QgQWNjZXNzLUFjY2VwdCBjaHVuaywgaWdub3JlIHRoZSBNb3Jl LURhdGEtUGVuZGluZyBhdHRyaWJ1dGUgKGl0IGlzIHVua25vd24gZm9yIGl0KSwgYW5kIHByb2Nl c3MgaXQgYXMgYSBjb21wbGV0ZSBwYWNrZXQuIEFzIG5vIGFkZGl0aW9uYWwgcm91bmQtdHJpcCBp cyBtYW5kYXRvcnkgYWZ0ZXIgYW4gQWNjZXNzLUFjY2VwdCBwYWNrZXQsIGl0IG1heSBiZSBwcm9i bGVtYXRpYyBhcyBpdCBpcyBwb3NzaWJsZSB0aGF0IHBhcnQgb2YgdGhlIG9ibGlnYXRpb25zIGZy b20gdGhlIEFTIHRvIHRoZSBOQVMgKGUuZy4gRlcgcG9saWNpZXMpIGFyZSBub3QgZW5mb3JjZWQu DQoNCkhvd2V2ZXIsIFJGQyAyODY1IHNheXMgdGhhdCAoaW4gcmVsYXRpb24gdG8gQWNjZXNzLUFj Y2VwdCBwYWNrZXRzKToNCg0KQSBOQVMgaXMgbm90DQoNCiAgICAgIHJlcXVpcmVkIHRvIGltcGxl bWVudCBhbGwgb2YgdGhlc2Ugc2VydmljZSB0eXBlcywgYW5kIE1VU1QgdHJlYXQNCg0KICAgICAg dW5rbm93biBvciB1bnN1cHBvcnRlZCBTZXJ2aWNlLVR5cGVzIGFzIHRob3VnaCBhbiBBY2Nlc3Mt UmVqZWN0DQoNCiAgICAgIGhhZCBiZWVuIHJlY2VpdmVkIGluc3RlYWQNCg0KVGhlcmVmb3JlLCBp ZiB0aGUgTkFTIGRvZXMgbm90IHVuZGVyc3RhbmQgU2VydmljZS1UeXBlPUFkZGl0aW9uYWxBdXRo b3JpemF0aW9uLCB0aGUgQWNjZXNzLUFjY2VwdCBwYWNrZXQgd2lsbCBiZSBpbnRlcnByZXRlZCBh cyBhbiBBY2Nlc3MtUmVqZWN0IG9uZSwgd2hpY2ggc2VlbXMgdG8gYmUgdGhlIG1vc3QgcmVhc29u YWJsZSBhcHByb2FjaC4NCg0KVGhpcyBzb3J0IG9mIHByb2JsZW1zIHNlZW0gdG8gbm90IGJlIGNy aXRpY2FsIHdpdGggQWNjZXNzLUNoYWxsZW5nZSBwYWNrZXRzLCBhcyB0aGUgTkFTIGlzIGV4cGVj dGVkIHRvIGdlbmVyYXRlIGEgbmV3IEFjY2Vzcy1SZXF1ZXN0IHBhY2tldCBhZnRlcndhcmRzLCBh bmQgdGhlIEFTIGNhbiBkZXRlY3Qgd2hldGhlciBmcmFnbWVudGF0aW9uIHdhcyBzdXBwb3J0ZWQu DQoNClJlZ2FyZHMsDQpBbGVqYW5kcm8NCg0KDQoNCg0KU2VjdGlvbiA4Og0KDQoNCg0KW1lPXSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvbyBzaG9ydC4gU2VjdXJpdHkgbWVj aGFuc2ltcw0KDQp0aGF0IGFyZSBuZWVkZWQgZm9yIHNlY3VyZSBvcGVyYXRpb24gb2YgdGhlIHBy b3Bvc2VkIGZyYWdtZW50YXRpb24NCg0KbWVjaGFuaXNtIG5lZWRzIHRvIGJlIGRlc2NyaWJlZCBp biB0aGlzIHNlY3Rpb24uDQoNCg0KDQpbUmFmYV0gWWVzIHRoaXMgc2VjdGlvbiB3aWxsIGJlIGlt cHJvdmVkLiBKaW0gYWxzbyByYWlzZWQgY29tbWVudHMgYWJvdXQgaXQuDQoNCg0KDQpTZWN0aW9u IDk6DQoNCg0KDQpbWU9dIEkgZG9uJ3QgdGhpbmsgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaXMg dHJ1ZTogIlRoaXMgZG9jdW1lbnQgaGFzDQoNCm5vIGFjdGlvbnMgZm9yIElBTkEuIiBiZWNhdXNl IFNlY3Rpb24gNiBkZWZpbmVzIG5ldyBhdHRyaWJ1dGVzLg0KDQoNCg0KW1JhZmFdIENvcnJlY3Qu IFRoaXMgbmVlZHMgdG8gYmUgZml4ZWQuDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCllvc2hpaGly byBPaGJhDQoNCiINCg0KDQoNCkJlc3QgcmVnYXJkcy4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUmFmYWVsIE1hcmluIExv cGV6LCBQaEQNCg0KRGVwdC4gSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIEVuZ2luZWVy aW5nIChESUlDKQ0KDQpGYWN1bHR5IG9mIENvbXB1dGVyIFNjaWVuY2UtVW5pdmVyc2l0eSBvZiBN dXJjaWENCg0KMzAxMDAgTXVyY2lhIC0gU3BhaW4NCg0KVGVsZjogKzM0ODY4ODg4NTAxIEZheDog KzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lczxtYWlsdG86cmFmYUB1bS5lcz4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN Cg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KcmFkZXh0IG1haWxpbmcgbGlzdA0KDQpyYWRleHRAaWV0Zi5vcmc8bWFpbHRvOnJh ZGV4dEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y YWRleHQNCg0KDQo= --_000_674F70E5F2BE564CB06B6901FD3DD78BE962C1tgxml338toshibalo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToi77yt77yzIOaYjuacnSI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg5piO5pydIjsNCglwYW5v c2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJNUyBVSSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1IDggMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2 IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDvvK3vvLMg5piO5pydIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgVUkgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYg MCA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCDmm7jlvI/ku5jjgY0gXCjmloflrZdcKSI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLlkLnj gY3lh7rjgZcgXCjmloflrZdcKSI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJNUyBVSSBHb3RoaWMiOw0KCWNv bG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOabuOW8j+S7mOOBjSBcKOaWh+Wtl1wp IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg5pu45byP 5LuY44GNIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLjE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmENCgl7bXNvLXN0eWxlLW5hbWU6IuWQ ueOBjeWHuuOBlyBcKOaWh+Wtl1wpIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms65ZC544GN5Ye644GXOw0KCWZvbnQtZmFtaWx5OiJNUyBVSSBHb3RoaWMiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo5OS4yNXB0IDMuMGNtIDMuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NzI4MDQyNTkwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxMDcwOTQ4NTQgMjEzNzY5NTE3OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseToi77yt77yzIOaYjuacnSI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5Mzc3MTIxMTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQzMjcxOTQ2OCA1NzE4Nzg3NTggNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6MTU3NzI4MDM0NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTkyMjA0Nzc4IDQ4NjA3MjMwNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseToi77yt77yzIOaYjuacnSI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHN1Z2dl c3QgdG8gaW52ZXN0aWdhdGUgYWxsIGNvcm5lciBjYXNlcyBiZWZvcmUgbWFraW5nIGEgZGVjaXNp b24gb24gYSBwYXJ0aWN1bGFyIG1lY2hhbmlzbS4mbmJzcDsgVGhlIGNvcm5lciBjYXNlcyBhcmU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPihhKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNsaWVudCBzdXBwb3J0 cyBmcmFnbWVudGF0aW9uIGFuZCBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBmcmFnbWVudGF0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDoxOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4oYS0xKSBBY2Nlc3MtUmVxdWVzdCBpcyBmcmFnbWVudGVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDoxOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4oYS0yKSBBY2Nlc3MtQ2hhbGxlbmdlIGlzIGZyYWdtZW50ZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0O3RleHQtaW5kZW50OjE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPihhLTMpIEFjY2Vzcy1BY2NlcHQgaXMgZnJhZ21lbnRlZA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+KGIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2xpZW50 IGRvZXMgbm90IHN1cHBvcnQgZnJhZ21lbnRhdGlvbiBhbmQgc2VydmVyIHN1cHBvcnRzIGZyYWdt ZW50YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihiLTEpIEFjY2Vz cy1SZXF1ZXN0IGlzIGZyYWdtZW50ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPihiLTIpIEFjY2Vzcy1DaGFsbGVuZ2UgaXMgZnJhZ21lbnRlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+KGItMykgQWNjZXNzLUFjY2VwdCBpcyBmcmFnbWVudGVkDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Zb3NoaWhpcm8gT2hiYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEFsZWphbmRybyBQZXJl eiBNZW5kZXogW21haWx0bzphbGV4QHVtLmVzXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg RmVicnVhcnkgMDQsIDIwMTMgNToxMiBQTTxicj4NCjxiPlRvOjwvYj4gb2hiYSB5b3NoaWhpcm8o PC9zcGFuPjxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtNUyBVSSBHb3RoaWMmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+5aSn5aC0PC9zcGFu PjxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4N Cjwvc3Bhbj48c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TVMgVUkgR290aGljJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPue+qea0izwvc3Bh bj48c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7il4s8 L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O01TIFVJIEdvdGhpYyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7vvLLvvKTvvKM8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+4pahPC9zcGFu PjxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtNUyBVSSBHb3RoaWMmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+77yu77yz77ysPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPik8YnI+DQo8Yj5DYzo8 L2I+IGFiZmFiQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYWJmYWJdIFtyYWRl eHRdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGVyZXotcmFkZXh0LXJhZGl1 cy1mcmFnbWVudGF0aW9uLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkVsIDAzLzAyLzEzIDE3OjMzLCA8YSBocmVm PSJtYWlsdG86eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcCI+DQp5b3NoaWhpcm8ub2hiYUB0 b3NoaWJhLmNvLmpwPC9hPiBlc2NyaWJpw7M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgQWxlamFuZHJv LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiBvcmRlciB0byBtYWludGFpbiBkZWFsIHdpdGggUkFE SVVTIGNsaWVudHMgYW5kIHNlcnZlcnMgdGhhdCBkbyBub3Qgc3VwcG9ydCBmcmFnbWVudGF0aW9u LCBpdCB3b3VsZCBiZSBjbGVhbmVyIHRvIHVzZSBSQURJVVMgY2FwYWJpbGl0eSBuZWdvdGlhdGlv bnMgKGRyYWZ0LWhhbHdhc2lhLXJhZGV4dC1jYXBhYmlsaXR5LW5lZ290aWF0aW9uKSB0byBuZWdv dGlhdGUNCiB1c2Ugb2YgTW9yZS1EYXRhLVBlbmRpbmcgYXR0cmlidXRlLiZuYnNwOyBUaGlzIHdv dWxkIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+YWxsb3cgYWxsIFJBRElVUyBtZXNzYWdlcyB0byB1c2UgTW9yZS1EYXRhLVBl bmRpbmcgYXR0cmlidXRlIGZvciBmcmFnbWVudGF0aW9uIHdpdGggbm8gZXhjZXB0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KVGhhdCB3b3VsZCBiZSBhbiBvcHRpb24uIEJ1dCBJIHdv dWxkIHJhdGhlciBkbyBub3QgZGVwZW5kIG9uIG90aGVyIGRyYWZ0cywgc3BlY2lhbGx5IG5vdCBX RyBkcmFmdC4gV2UgbWF5IG5lZWQgc29tZSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIHdpdGhpbiB0 aGUgZnJhZ21lbnRhdGlvbiBtZWNoYW5pc21zLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KQWxl amFuZHJvPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPllvc2hpaGlybyBP aGJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4NCjxhIGhyZWY9Im1haWx0bzphYmZhYi1ib3VuY2VzQGlldGYub3JnIj5hYmZh Yi1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmFiZmFiLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzphYmZhYi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QWxlamFuZHJvIFBlcmV6IE1lbmRlejxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEphbnVhcnkgMzAsIDIwMTMgNTo0NiBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRv OmFiZmFiQGlldGYub3JnIj5hYmZhYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFthYmZhYl0gW3JhZGV4dF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1w ZXJlei1yYWRleHQtcmFkaXVzLWZyYWdtZW50YXRpb24tMDQudHh0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjEyLjBwdDttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KSGVsbG8gWW9zaGksIFJhZmEsIDxicj4N Cjxicj4NCnNlZSBzb21lIGNvbW1lbnRzIGlubGluZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPkRl YXIgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PndlIGhhdmUgcmVjZWl2ZWQgYWRkaXRpb25hbCBjb21tZW50cyBmcm9tIFlvc2hpaGlybyBPaGJh IChtYW55IHRoYW5rcykgdGhhdCB3ZSBzaGFyZSB3aXRoIHlvdS4gPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+UGxlYXNlLCBzZWUgc29tZSBjb21tZW50 cyBpbmxpbmUuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dCI+JnF1b3Q7SGVyZSBpcyBteSByZXZpZXcgb2YgZHJhZnQtcGVyZXotcmFkZXh0LXJhZGl1cy1m cmFnbWVudGF0aW9uLTA0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPlNlY3Rpb24gMTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0Ij4mcXVvdDtFYWNoIFJBRElVUyBwYWNrZXQgY2FuIHRyYW5zcG9ydCBzZXZl cmFsIFJBRElVUyBhdHRyaWJ1dGVzLCB0byBjb252ZXk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij50aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIHRvIHRo ZSBvdGhlciBwZWVyLCB1cCB0byBhIG1heGltdW0gc2l6ZSBvZiA0PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+S0Igb2YgdG90YWwgZGF0YSAoaW5jbHVk aW5nIFJBRElVUyBwYWNrZXQgaGVhZGVycykuJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+W1lPXSBJIHN1Z2dlc3QgdG8gcmVwbGFjZSAmcXVv dDs0IEtCJnF1b3Q7IHdpdGggJnF1b3Q7NDA5NiBieXRlcyZxdW90OyB0aHJvdWdob3V0IHRoZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPmRvY3VtZW50 IHNpbmNlICZxdW90O0tCJnF1b3Q7IGNhbiBtZWFuIDQwMDAgYnl0ZXMgaW4gc29tZSBjYXNlcy48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5bUmFmYV0g T0suPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+JnF1 b3Q7QSByZWZlcmVuY2UtYmFzZWQgbWVjaGFuaXNtIGlzIGFsc28gcHJvcG9zZWQgaW4gW1JGQzYx NThdLCB3aGVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPmF0dHJpYnV0ZXMgY2FuIGJlIG9idGFpbmVkIHRocm91Z2ggYW4gb3V0LW9mLWJhbmQgcHJv dG9jb2wuJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+W1lPfSBNZWFuaW5nIG9mIHRoaXMgc2VudGVuY2UgaXMgdW5jbGVhci4gRG9lcyB0aGlz IG1lYW4gUkFESVVTPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+YXR0cmlidXRlcyBhcmUgb2J0YWluZWQgdGhyb3VnaCBzb21lIG90aGVyIHByb3RvY29s IGluc3RlYWQgb2YgUkFESVVTPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQiPk9yIGRvZXMgdGhpcyBtZWFuIHRoZSBhY3R1YWwgZm9ybWF0IG9mIHRoZSBW YWx1ZSBmaWVsZCBvZiBhIFJBRElVUzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQiPkF0dHJpYnV0ZSBpcyBkZWZpbmVkIGluIG90aGVyIHByb3RvY29sIHNw ZWNpZmljYXRpb24/IEluIHRoZSBsYXR0ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij5jYXNlLCBpdCBzaG91bGQgYmUgYWxzbyBtZW50aW9uZWQgdGhh dCBSQURJVVMtRUFQIGlzIGNhdGVnb3JpemVkIGFzIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPm1lY2hhbmlzbSBkZWZpbmVkIGluIFJGQyA2MTU4 LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPltSYWZh XSBJdCBpcyByZWZlcnJpbmcgdGhlIHZhbHVlIG9mIHRoZSBhdHRyaWJ1dGVzIGNhbiBiZSBvYnRh aW5lZCBieSBvdGhlciBwcm90b2NvbCBpbnN0ZWFkIG9mIFJBRElVUy4gVGhpcyBpcyBjb21pbmcg ZnJvbSBhIHByZXZpb3VzIGNvbW1lbnQgcmVsYXRlZCB3aXRoIFNBTUwgdHJhbnNwb3J0LiBJbnN0 ZWFkIG9mIHRyYW5zcG9ydGluZyB0aGUgcmVhbCBTQU1MIG1lc3NhZ2VzIGFuIFVSTCBpcyBzZXQg YXMgYXR0cmlidXRlIHZhbHVlLiBXZSBjYW4gdHJ5IHRvIGNsYXJpZnkgYSBsaXR0bGUgYml0IG1v cmUuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+JnF1 b3Q7SG93ZXZlciwgdGhlcmUgYXJlIG5vIHByb3Bvc2FscyB0byBkZWFsIHdpdGggZnJhZ21lbnRh dGlvbiBhdCBhIHBhY2tldDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPmxldmVsLCB3aGVuIHRoZSB0b3RhbCBzaXplIGV4Y2VlZHMgdGhlIDQgS0IgbGlt aXQgaW1wb3NlZCBieSB0aGUgUkFESVVTPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdCI+c3BlY2lmaWNhdGlvbi4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5bWU9dIE1lYW5pbmcgb2YgJnF1b3Q7YXQg YSBwYWNrZXQgbGV2ZWwmcXVvdDsgaXMgdW5jbGVhci4gU3VnZ2VzdGVkIGNoYW5nZTo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mcXVvdDtIb3dldmVy LCB0aGVyZSBhcmUgbm8gcHJvcG9zYWxzIHRvIGZyYWdlbWVudCBhIGxhcmdlLXNpemVkIFJBRElV UzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPnBhY2tl dCBpbnRvIG11bHRpcGxlIHNtYWxsLXNpemVkIFJBRElVUyBwYWNrZXRzLCB3aGVyZSB0aGUgbGVu Z3RoIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPm9yaWdpbmFsICh1bmZyYWdtZW50ZWQpIFJBRElVUyBwYWNrZXQgZXhjZWVkcyB0aGUgNDA5 Ni1vY3RldCBsaW1pdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPmltcG9zZWQgYnkgdGhlIFJBRElVUyBzcGVjaWZpY2F0aW9uLiZxdW90OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPltSYWZhXSBUaGlzIHNv dW5kcyBnb29kLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPlNlY3Rpb24gMjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0Ij5bWU9dIEkgYW0gbm90IHN1cmUgaWYgJnF1b3Q7VCZxdW90OyBmbGFnIGlzIG5lZWRl ZC4gSW4gb3RoZXIgd29yZHMsIGl0IHNob3VsZCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPnBvc3NpYmxlIHRvIGNoYW5nZSBbSS1ELmlldGYtcmFk ZXh0LXJhZGl1cy1leHRlbnNpb25zXSB0byBzaW1wbHkgYWxsb3cgYTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPmZyYWdtZW50IHdpdGggdGhlIE0tZmxh ZyBjbGVhcmVkIG5vdCB0byBiZSBpbmNsdWRlZCBpbiBhIG5vbi1sYXN0IGNodW5rLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPltSYWZhXSA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5ZZXMsIHRoYXQgbWF5 IGJlIHBvc3NpYmxlLiBJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCB3ZSB3YW50ZWQgdG8ga2VlcCB1 bm1vZGlmaWVkIGFueSBleGlzdGluZyBJLUQgYnkgdGhlIHRpbWUgYmVpbmcuIE1vcmVvdmVyLCBb SS1ELmlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zXSBoYXMgbm90IGNvbnNpZGVyZWQgdGhh dCBmcmFnbWVudGF0aW9uIGF0IHBhY2tldCBsZXZlbCBtYXkgb2NjdXIgZm9yIG9idmlvdXMgcmVh c29ucy4gTW9yZW92ZXIsIHRoYXQgSS1EIGlzIGluIGEgbWF0dXJlIHN0YXRlIG5vdy48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5JbiBhbnkgY2FzZSwg d2UgbWF5IGFzayBhdXRob3JzIG9mIFtJLUQuaWV0Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lvbnNd LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPlNlY3Rp b24gMy4zOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PltZT10gQWNjZXNzLUFjY2VwdCBmcmFnbWVudGF0aW9uIHNjaGVtZSBsb29rcyBvZGQgY29tcGFy ZWQgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5B Y2Nlc3MtUmVxdWVzdCBhbmQgQWNjZXNzLUNoYWxsZW5nZSBmcmFnbWVudGF0aW9uIHNjaGVtZXMu IFRoZXJlIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPnNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gdGhpczogKDEpIFdoeSBtdWx0aXBsZSBj aHVua3Mgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0 Ij5BY2Nlc3MtQWNjZXB0IGNhbm5vdCBiZSBzZW50IHdpdGhvdXQgaGF2aW5nIGFuIEFjY2Vzcy1D aGFsbGFuZ2UgdG8gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0Ij5zZW50IGluIGJldHdlZW4/ICgyKSBXaHkgYW4gQWNjZXNzLUFjY2VwdCBjYW5ub3Qg Y29udGFpbiBhPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dCI+TW9yZS1EYXRhLVBlbmRpbmcgYXR0cmlidXRlIGluc3RlYWQgb2YgdXNpbmcgYSBuZXcgc2Vy dmljZSB0eXBlIHZhbHVlPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPigzKSBIb3cgY2FuIGEgbGFyZ2UgYXR0cmlidXR1ZSB0aGF0IGlzIGFsbG93ZWQg dG8gYXBwZWFyIGluIGFuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+QWNjZXNzLUFjY2VwdCBidXQgbm90IGFsbG93ZWQgdG8gYXBwZWFyIGluIEFjY2Vz cy1DaGFsbGVuZ2UgYmUgZnJhZ21lbnRlZD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij5bUmFmYV08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij4xKSBXZSB3YW50ZWQgdG8gYmUgc3ltbWV0cmljIGluIHRoZSBk ZXNpZ24sIHdoZXJlIEFjY2Vzcy1SZXF1ZXN0L0FjY2Vzcy1DaGFsbGVuZ2UgZXhjaGFuZ2UgaXMg dXNlZCBzb21laG93IGZvciBmcmFnbWVudGF0aW9uIHN1cHBvcnQuIEluIGFueSBjYXNlLCB3ZSBo YXZlIGFsc28gY29uc2lkZXJlZCB0aGUgdXNhZ2Ugb2YgQWNjZXNzLUFjY2VwdCB3aXRoIFNlcnZp Y2UtVHlwZVtBZGRBdXRoXSBzbyB1bnRpbCBhbGwgdGhlIGF0dHJpYnV0ZXMgaW4gdGhlIHdob2xl IFJBRElVUyBBY2Nlc3MtQWNjZXB0IGFyZSBmaW5hbGx5IHNlbnQgdGhlIGV4Y2hhbmdlIHdpbGwg YmUgQWNjZXNzLVJlcXVlc3QvQWNjZXNzLUFjY2VwdCAoU2VydmljZS1UeXBlW0FkZEF1dGhdKSwg d2hpbGUgdGhlIGxhc3Qgb25lIGlzIHNpbXBseSBBY2Nlc3MtUmVxdWVzdC9BY2Nlc3MtQWNjZXB0 LiBUaGlzIG1vZGUgb2Ygb3BlcmF0aW9uIHdvdWxkIHNvbHZlIHlvdXIgcXVlc3Rpb24gMykuPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+MikgSSB0aGlu ayB0aGF0IG1heSBiZSBhbHNvIHBvc3NpYmxlLiBJbiBhbnkgY2FzZSwgSSB0aGluayBBbGFuIG9y IEFsZXggY2FuIGVsYWJvcmF0ZSBhIGxpdHRsZSBiaXQgYSBtb3JlIGFib3V0IHRoZSB1c2FnZSBv ZiBTZXJ2aWNlLVR5cGVbQWRkQXV0aF0uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdCI+MykgUHJlY2lzZWx5LCB0cnlpbmcgdG8gYW5zd2VyIHRoaXMgcXVl c3Rpb24gd2UganVzdCBjYW1lIHVwIHdpdGggdGhlIHNvbHV0aW9uIGluIDEpLiBXaGF0IGRvIHlv dSB0aGluaz8mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxicj4NClRoaXMgYWx0ZXJu YXRpdmUgc291bmRzIGdvb2QgdG8gbWUuIEhvd2V2ZXIsIEkgdGhpbmsgdGhlcmUgbWF5IGJlIHN0 aWxsIHNvbWUgYWR2YW50YWdlcyBvZiB1c2luZyBTZXJ2aWNlLVR5cGUgaW5zdGVhZCBvZiAob3Ig aW4gYWRkaXRpb24gdG8pIE1vcmUtRGF0YS1QZW5kaW5nIGZvciBBY2Nlc3MtQWNjZXB0IHBhY2tl dHMuPGJyPg0KPGJyPg0KSWYgdGhlIE5BUy9SUCBkb2VzIG5vdCBrbm93IGFueXRoaW5nIGFib3V0 IGZyYWdtZW50YXRpb24gKGkuZS4gZG9lcyBub3Qgc3VwcG9ydCB0aGlzIGRyYWZ0KSwgaXQgbWF5 IHRha2UgdGhlIGZpcnN0IEFjY2Vzcy1BY2NlcHQgY2h1bmssIGlnbm9yZSB0aGUgTW9yZS1EYXRh LVBlbmRpbmcgYXR0cmlidXRlIChpdCBpcyB1bmtub3duIGZvciBpdCksIGFuZCBwcm9jZXNzIGl0 IGFzIGEgY29tcGxldGUgcGFja2V0LiBBcyBubyBhZGRpdGlvbmFsIHJvdW5kLXRyaXANCiBpcyBt YW5kYXRvcnkgYWZ0ZXIgYW4gQWNjZXNzLUFjY2VwdCBwYWNrZXQsIGl0IG1heSBiZSBwcm9ibGVt YXRpYyBhcyBpdCBpcyBwb3NzaWJsZSB0aGF0IHBhcnQgb2YgdGhlIG9ibGlnYXRpb25zIGZyb20g dGhlIEFTIHRvIHRoZSBOQVMgKGUuZy4gRlcgcG9saWNpZXMpIGFyZSBub3QgZW5mb3JjZWQuPGJy Pg0KPGJyPg0KSG93ZXZlciwgUkZDIDI4NjUgc2F5cyB0aGF0IChpbiByZWxhdGlvbiB0byBBY2Nl c3MtQWNjZXB0IHBhY2tldHMpOjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0Ij5BIE5BUyBpcyBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZWQg dG8gaW1wbGVtZW50IGFsbCBvZiB0aGVzZSBzZXJ2aWNlIHR5cGVzLCBhbmQgTVVTVCB0cmVhdDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1bmtub3duIG9yIHVuc3VwcG9ydGVkIFNlcnZpY2UtVHlw ZXMgYXMgdGhvdWdoIGFuIEFjY2Vzcy1SZWplY3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFk IGJlZW4gcmVjZWl2ZWQgaW5zdGVhZDxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48YnI+DQpUaGVyZWZvcmUsIGlmIHRoZSBO QVMgZG9lcyBub3QgdW5kZXJzdGFuZCBTZXJ2aWNlLVR5cGU9QWRkaXRpb25hbEF1dGhvcml6YXRp b24sIHRoZSBBY2Nlc3MtQWNjZXB0IHBhY2tldCB3aWxsIGJlIGludGVycHJldGVkIGFzIGFuIEFj Y2Vzcy1SZWplY3Qgb25lLCB3aGljaCBzZWVtcyB0byBiZSB0aGUgbW9zdCByZWFzb25hYmxlIGFw cHJvYWNoLjxicj4NCjxicj4NClRoaXMgc29ydCBvZiBwcm9ibGVtcyBzZWVtIHRvIG5vdCBiZSBj cml0aWNhbCB3aXRoIEFjY2Vzcy1DaGFsbGVuZ2UgcGFja2V0cywgYXMgdGhlIE5BUyBpcyBleHBl Y3RlZCB0byBnZW5lcmF0ZSBhIG5ldyBBY2Nlc3MtUmVxdWVzdCBwYWNrZXQgYWZ0ZXJ3YXJkcywg YW5kIHRoZSBBUyBjYW4gZGV0ZWN0IHdoZXRoZXIgZnJhZ21lbnRhdGlvbiB3YXMgc3VwcG9ydGVk Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KQWxlamFuZHJvPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPlNlY3Rp b24gODo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5b WU9dIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgdG9vIHNob3J0LiBTZWN1cml0 eSBtZWNoYW5zaW1zPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+dGhhdCBhcmUgbmVlZGVkIGZvciBzZWN1cmUgb3BlcmF0aW9uIG9mIHRoZSBwcm9wb3Nl ZCBmcmFnbWVudGF0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+bWVjaGFuaXNtIG5lZWRzIHRvIGJlIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24u PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+W1JhZmFd IFllcyB0aGlzIHNlY3Rpb24gd2lsbCBiZSBpbXByb3ZlZC4gSmltIGFsc28gcmFpc2VkIGNvbW1l bnRzIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPlNlY3Rpb24gOTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0Ij5bWU9dIEkgZG9uJ3QgdGhpbmsgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaXMg dHJ1ZTogJnF1b3Q7VGhpcyBkb2N1bWVudCBoYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5ubyBhY3Rpb25zIGZvciBJQU5BLiZxdW90OyBiZWNhdXNl IFNlY3Rpb24gNiBkZWZpbmVzIG5ldyBhdHRyaWJ1dGVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPltSYWZhXSBDb3JyZWN0LiBUaGlzIG5lZWRzIHRv IGJlIGZpeGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0Ij5Zb3NoaWhpcm8gT2hiYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPkJlc3QgcmVnYXJkcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdCI+UmFmYWVsIE1hcmluIExvcGV6LCBQaEQ8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5EZXB0LiBJbmZvcm1hdGlvbiBhbmQg Q29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJSUMpPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+RmFjdWx0eSBvZiBDb21wdXRlciBTY2llbmNlLVVu aXZlcnNpdHkgb2YgTXVyY2lhPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdCI+MzAxMDAgTXVyY2lhIC0gU3BhaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5UZWxmOiAmIzQzOzM0ODY4ODg4NTAxIEZheDogJiM0 MzszNDg2ODg4NDE1MSBlLW1haWw6IDxhIGhyZWY9Im1haWx0bzpyYWZhQHVtLmVzIj5yYWZhQHVt LmVzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPnJhZGV4dCBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48YSBocmVmPSJt YWlsdG86cmFkZXh0QGlldGYub3JnIj5yYWRleHRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcmFkZXh0PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_674F70E5F2BE564CB06B6901FD3DD78BE962C1tgxml338toshibalo_-- From hartmans@painless-security.com Mon Feb 4 04:06:48 2013 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 221E921F8694 for ; Mon, 4 Feb 2013 04:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZCW44s-ECJm for ; Mon, 4 Feb 2013 04:06:47 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1A21F868E for ; Mon, 4 Feb 2013 04:06:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id E9CE22026F; Mon, 4 Feb 2013 07:02:42 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D85DC43FD; Mon, 4 Feb 2013 07:06:43 -0500 (EST) From: Sam Hartman To: References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510F6D53.7040803@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> Date: Mon, 04 Feb 2013 07:06:43 -0500 In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> (yoshihiro ohba's message of "Mon, 4 Feb 2013 12:01:08 +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] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:06:48 -0000 >>>>> writes: > I suggest to investigate all corner cases before making a decision > on a particular mechanism. The corner cases are: Sounds reasonable. > (b) Client does not support fragmentation and server supports In case b-1 (access-request fragmentation) I'm confused. How is the access-request fragmented if a client doesn't support fragmentation? From alex@um.es Mon Feb 4 04:34:05 2013 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 8A48B21F869F for ; Mon, 4 Feb 2013 04:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.623 X-Spam-Level: X-Spam-Status: No, score=-4.623 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGeO+Uyx3uXU for ; Mon, 4 Feb 2013 04:34:03 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3B38E21F869C for ; Mon, 4 Feb 2013 04:34:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id C1C315D528; Mon, 4 Feb 2013 13:34:00 +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 HOarzikr6XQv; Mon, 4 Feb 2013 13:33:59 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id 9B6FD5D51A; Mon, 4 Feb 2013 13:33:57 +0100 (CET) Message-ID: <510FAAB5.1040708@um.es> Date: Mon, 04 Feb 2013 13:33:57 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510F6D53.7040803@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> Content-Type: multipart/alternative; boundary="------------010703000401090501090803" Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:34:05 -0000 This is a multi-part message in MIME format. --------------010703000401090501090803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 04/02/13 13:01, yoshihiro.ohba@toshiba.co.jp escribió: > > I suggest to investigate all corner cases before making a decision on > a particular mechanism. The corner cases are: > > (a)Client supports fragmentation and server does not support fragmentation > > (a-1) Access-Request is fragmented > Client includes More-Data-Pending attribute. As the Server does not understand it, the Server ignores the attribute and tries to reply to the Access-Request if it makes sense to it. If the reply is an Access-Accept/Access-Reject, the client will notice right away. However, if the reply is an Access-Challenge packet, they client may have problems distinguishing it from an Access-Challenge packet that request more fragments. Including the More-Data-Pending attribute in the Challenge may solve this situation, serving as acknowledgement of fragmentation. > (a-2) Access-Challenge is fragmented > > (a-3) Access-Accept is fragmented > Not possible. > (b)Client does not support fragmentation and server supports fragmentation > > (b-1) Access-Request is fragmented > Not possible > (b-2) Access-Challenge is fragmented > Similarly to case a-1, the client may ignore the More-Data-Pending and treat the first chunk as a regular Access-Challenge. In that case, the client will generate an Access-Request packet with the required information (depends on the received Challenge). The server may have problems to distinguish this Request from one requesting more data. > (b-3) Access-Accept is fragmented > This problem is solved by the use of Service-Type=Additional-Authorization. If the client does not understand this value, the packet is interpreted as an Access-Reject, and the client will not make wrong decisions. Regards, Alejandro > Yoshihiro Ohba > > *From:*Alejandro Perez Mendez [mailto:alex@um.es] > *Sent:* Monday, February 04, 2013 5:12 PM > *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ) > *Cc:* abfab@ietf.org > *Subject:* Re: [abfab] [radext] New Version Notification for > draft-perez-radext-radius-fragmentation-04.txt > > El 03/02/13 17:33, yoshihiro.ohba@toshiba.co.jp > escribió: > > Hi Alejandro, > > In order to maintain deal with RADIUS clients and servers that do > not support fragmentation, it would be cleaner to use RADIUS > capability negotiations > (draft-halwasia-radext-capability-negotiation) to negotiate use of > More-Data-Pending attribute. This would > > allow all RADIUS messages to use More-Data-Pending attribute for > fragmentation with no exception. > > > That would be an option. But I would rather do not depend on other > drafts, specially not WG draft. We may need some capability > negotiation within the fragmentation mechanisms. > > Regards, > Alejandro > > > Yoshihiro Ohba > > *From:*abfab-bounces@ietf.org > [mailto:abfab-bounces@ietf.org] *On Behalf Of *Alejandro Perez Mendez > *Sent:* Wednesday, January 30, 2013 5:46 PM > *To:* abfab@ietf.org > *Subject:* Re: [abfab] [radext] New Version Notification for > draft-perez-radext-radius-fragmentation-04.txt > > Hello Yoshi, Rafa, > > see some comments inline: > > Dear all, > > > > we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. > > > > Please, see some comments inline. > > > > "Here is my review of draft-perez-radext-radius-fragmentation-04. > > > > Section 1: > > > > "Each RADIUS packet can transport several RADIUS attributes, to convey > > the necessary information to the other peer, up to a maximum size of 4 > > KB of total data (including RADIUS packet headers)." > > > > [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the > > document since "KB" can mean 4000 bytes in some cases. > > > > [Rafa] OK. > > > > > > "A reference-based mechanism is also proposed in [RFC6158], where > > attributes can be obtained through an out-of-band protocol." > > > > [YO} Meaning of this sentence is unclear. Does this mean RADIUS > > attributes are obtained through some other protocol instead of RADIUS? > > Or does this mean the actual format of the Value field of a RADIUS > > Attribute is defined in other protocol specification? In the latter > > case, it should be also mentioned that RADIUS-EAP is categorized as the > > mechanism defined in RFC 6158. > > > > [Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more. > > > > "However, there are no proposals to deal with fragmentation at a packet > > level, when the total size exceeds the 4 KB limit imposed by the RADIUS > > specification." > > > > [YO] Meaning of "at a packet level" is unclear. Suggested change: > > "However, there are no proposals to fragement a large-sized RADIUS > > packet into multiple small-sized RADIUS packets, where the length of the > > original (unfragmented) RADIUS packet exceeds the 4096-octet limit > > imposed by the RADIUS specification." > > > > [Rafa] This sounds good. > > > > > > Section 2: > > > > [YO] I am not sure if "T" flag is needed. In other words, it should be > > possible to change [I-D.ietf-radext-radius-extensions] to simply allow a > > fragment with the M-flag cleared not to be included in a non-last chunk. > > > > [Rafa] > > > > Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now. > > > > In any case, we may ask authors of [I-D.ietf-radext-radius-extensions]. > > > > Section 3.3: > > > > [YO] Access-Accept fragmentation scheme looks odd compared to > > Access-Request and Access-Challenge fragmentation schemes. There are > > several questions related to this: (1) Why multiple chunks of > > Access-Accept cannot be sent without having an Access-Challange to be > > sent in between? (2) Why an Access-Accept cannot contain a > > More-Data-Pending attribute instead of using a new service type value? > > (3) How can a large attributue that is allowed to appear in an > > Access-Accept but not allowed to appear in Access-Challenge be fragmented? > > > > [Rafa] > > > > 1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3). > > > > 2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth]. > > > > 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think? > > > This alternative sounds good to me. However, I think there may be > still some advantages of using Service-Type instead of (or in addition > to) More-Data-Pending for Access-Accept packets. > > If the NAS/RP does not know anything about fragmentation (i.e. does > not support this draft), it may take the first Access-Accept chunk, > ignore the More-Data-Pending attribute (it is unknown for it), and > process it as a complete packet. As no additional round-trip is > mandatory after an Access-Accept packet, it may be problematic as it > is possible that part of the obligations from the AS to the NAS (e.g. > FW policies) are not enforced. > > However, RFC 2865 says that (in relation to Access-Accept packets): > > A NAS is not > required to implement all of these service types, and MUST treat > unknown or unsupported Service-Types as though an Access-Reject > had been received instead > > > Therefore, if the NAS does not understand > Service-Type=AdditionalAuthorization, the Access-Accept packet will be > interpreted as an Access-Reject one, which seems to be the most > reasonable approach. > > This sort of problems seem to not be critical with Access-Challenge > packets, as the NAS is expected to generate a new Access-Request > packet afterwards, and the AS can detect whether fragmentation was > supported. > > Regards, > Alejandro > > > > Section 8: > > [YO] Security Considerations section is too short. Security mechansims > that are needed for secure operation of the proposed fragmentation > mechanism needs to be described in this section. > > [Rafa] Yes this section will be improved. Jim also raised comments about it. > > Section 9: > > [YO] I don't think the following statement is true: "This document has > no actions for IANA." because Section 6 defines new attributes. > > [Rafa] Correct. This needs to be fixed. > > Best Regards, > Yoshihiro Ohba > " > > Best regards. > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > --------------010703000401090501090803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 04/02/13 13:01, yoshihiro.ohba@toshiba.co.jp escribió:

I suggest to investigate all corner cases before making a decision on a particular mechanism.  The corner cases are:

 

(a)    Client supports fragmentation and server does not support fragmentation

(a-1) Access-Request is fragmented


Client includes More-Data-Pending attribute. As the Server does not understand it, the Server ignores the attribute and tries to reply to the Access-Request if it makes sense to it. If the reply is an Access-Accept/Access-Reject, the client will notice right away. However, if the reply is an Access-Challenge packet, they client may have problems distinguishing it from an Access-Challenge packet that request more fragments. Including the More-Data-Pending attribute in the Challenge may solve this situation, serving as acknowledgement of fragmentation.


(a-2) Access-Challenge is fragmented

(a-3) Access-Accept is fragmented


Not possible.

(b)   Client does not support fragmentation and server supports fragmentation

(b-1) Access-Request is fragmented


Not possible

(b-2) Access-Challenge is fragmented


Similarly to case a-1, the client may ignore the More-Data-Pending and treat the first chunk as a regular Access-Challenge. In that case, the client will generate an Access-Request packet with the required information (depends on the received Challenge). The server may have problems to distinguish this Request from one requesting more data.


(b-3) Access-Accept is fragmented


This problem is solved by the use of Service-Type=Additional-Authorization. If the client does not understand this value, the packet is interpreted as an Access-Reject, and the client will not make wrong decisions.

Regards,
Alejandro

 

Yoshihiro Ohba

 

 

 

From: Alejandro Perez Mendez [mailto:alex@um.es]
Sent: Monday, February 04, 2013 5:12 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: abfab@ietf.org
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

 

 

El 03/02/13 17:33, yoshihiro.ohba@toshiba.co.jp escribió:

Hi Alejandro,

 

In order to maintain deal with RADIUS clients and servers that do not support fragmentation, it would be cleaner to use RADIUS capability negotiations (draft-halwasia-radext-capability-negotiation) to negotiate use of More-Data-Pending attribute.  This would

allow all RADIUS messages to use More-Data-Pending attribute for fragmentation with no exception.


That would be an option. But I would rather do not depend on other drafts, specially not WG draft. We may need some capability negotiation within the fragmentation mechanisms.

Regards,
Alejandro


 

Yoshihiro Ohba

 

 

 

From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Alejandro Perez Mendez
Sent: Wednesday, January 30, 2013 5:46 PM
To: abfab@ietf.org
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

 

Hello Yoshi, Rafa,

see some comments inline:

 

Dear all,
 
we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. 
 
Please, see some comments inline.
 
"Here is my review of draft-perez-radext-radius-fragmentation-04.
 
Section 1:
 
"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."
 
[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.
 
[Rafa] OK.
 
 
"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."
 
[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.
 
[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.
 
"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."
 
[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."
 
[Rafa] This sounds good.
 
 
Section 2:
 
[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.
 
[Rafa] 
 
Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.
 
In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].
 
Section 3.3:
 
[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be fragmented?
 
[Rafa]
 
1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).
 
2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].
 
3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think? 


This alternative sounds good to me. However, I think there may be still some advantages of using Service-Type instead of (or in addition to) More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not support this draft), it may take the first Access-Accept chunk, ignore the More-Data-Pending attribute (it is unknown for it), and process it as a complete packet. As no additional round-trip is mandatory after an Access-Accept packet, it may be problematic as it is possible that part of the obligations from the AS to the NAS (e.g. FW policies) are not enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):

A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead


Therefore, if the NAS does not understand Service-Type=AdditionalAuthorization, the Access-Accept packet will be interpreted as an Access-Reject one, which seems to be the most reasonable approach.

This sort of problems seem to not be critical with Access-Challenge packets, as the NAS is expected to generate a new Access-Request packet afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro



Section 8:
 
[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.
 
[Rafa] Yes this section will be improved. Jim also raised comments about it.
 
Section 9:
 
[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.
 
[Rafa] Correct. This needs to be fixed.
 
Best Regards,
Yoshihiro Ohba
"
 
Best regards.
 
-------------------------------------------------------
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
-------------------------------------------------------
 
 
 
 
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

 

 


--------------010703000401090501090803-- From aland@deployingradius.com Mon Feb 4 04:40:18 2013 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 74E7521F85FD for ; Mon, 4 Feb 2013 04:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PMHstqH2ui3 for ; Mon, 4 Feb 2013 04:40:17 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5F2E21F863F for ; Mon, 4 Feb 2013 04:40:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4E45F2240F52; Mon, 4 Feb 2013 13:39:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDZL91j5Kpyk; Mon, 4 Feb 2013 13:39:25 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 7590622404AC; Mon, 4 Feb 2013 13:39:24 +0100 (CET) Message-ID: <510FABFD.5010302@deployingradius.com> Date: Mon, 04 Feb 2013 07:39:25 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510E981A.7000004@deployingradius.com> <510F6F12.3050402@um.es> In-Reply-To: <510F6F12.3050402@um.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:40:18 -0000 Alejandro Perez Mendez wrote: > Why? I assumed they will ignore the MDP attribute, and generate a > Challenge if they understand the chunk as a valid Access-Request. The server might return a challenge. But any response from the server will *not* implement fragmentation. That's the point. > What if the server wants to send a fragmented Challenge *before* sending > the Access-Accept? My $0.02 is that it's probably a bad idea. Changing the semantics of existing authentication methods is hard. For example, most 802.1X implementations assume that the final EAP-Success is in the Access-Accept. If it's in an earlier challenge... who knows what will break. > Then, it will send the More-Data-Pending attribute, > not the Service-Type = AddAuth. Again, the client may ignore the unknown > attribute and try to decode the chunk as a "regular" Access-Challenge. Which is likely to contain *no* useful information for the client. So the client has an Access-Challenge it didn't expect. It can do nothing but reject the user, and close the session. This is a different error than "unknown Service-Type Additional-Authorization". Having the server send an unknown Service-Type is a known quantity. It is easy to debug, and easy to check. Alan DeKok. From alex@um.es Mon Feb 4 04:49:03 2013 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 56AFC21F85EB for ; Mon, 4 Feb 2013 04:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSlId5v5gUlp for ; Mon, 4 Feb 2013 04:49:02 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id AE70A21F859D for ; Mon, 4 Feb 2013 04:49:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 0283E4BD31; Mon, 4 Feb 2013 13:48:57 +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 aZxk+86SwJpY; Mon, 4 Feb 2013 13:48:56 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id C25634BD51; Mon, 4 Feb 2013 13:48:55 +0100 (CET) Message-ID: <510FAE37.60700@um.es> Date: Mon, 04 Feb 2013 13:48:55 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alan DeKok References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510E981A.7000004@deployingradius.com> <510F6F12.3050402@um.es> <510FABFD.5010302@deployingradius.com> In-Reply-To: <510FABFD.5010302@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:49:03 -0000 El 04/02/13 13:39, Alan DeKok escribió: > Alejandro Perez Mendez wrote: >> Why? I assumed they will ignore the MDP attribute, and generate a >> Challenge if they understand the chunk as a valid Access-Request. > The server might return a challenge. But any response from the server > will *not* implement fragmentation. That's the point. That's sure. > >> What if the server wants to send a fragmented Challenge *before* sending >> the Access-Accept? > My $0.02 is that it's probably a bad idea. Changing the semantics of > existing authentication methods is hard. For example, most 802.1X > implementations assume that the final EAP-Success is in the > Access-Accept. If it's in an earlier challenge... who knows what will > break. I think I didn't explained myself correctly. I'm not suggesting modifying existing authentication methods. EAP-Success will still appear only in Access-Accept packets. Just imagine the situation where the Server wants to include an attribute X in one of the Access-Challenge packets, and that by introducing that attribute X, the packet becomes too big. That's the case I'm thinking of. Maybe that's an impossible situation, I don't know. Let my give an example. A server wants (for whatever reason) to include an attribute X on every packet it sends to the Client. That includes every Access-Challenge belonging to a RADIUS-EAP authentication. If this attribute X is big enough, the packet will need to be fragmented. This is happening before Access-Accept. Regards, Alejandro >> Then, it will send the More-Data-Pending attribute, >> not the Service-Type = AddAuth. Again, the client may ignore the unknown >> attribute and try to decode the chunk as a "regular" Access-Challenge. > Which is likely to contain *no* useful information for the client. So > the client has an Access-Challenge it didn't expect. It can do nothing > but reject the user, and close the session. This is a different error > than "unknown Service-Type Additional-Authorization". > > Having the server send an unknown Service-Type is a known quantity. > It is easy to debug, and easy to check. > > Alan DeKok. From aland@deployingradius.com Mon Feb 4 04:55:34 2013 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 8E0E721F8667 for ; Mon, 4 Feb 2013 04:55:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leZ7ftT5-YSC for ; Mon, 4 Feb 2013 04:55:33 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDAA21F8615 for ; Mon, 4 Feb 2013 04:55:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D9E492240F52; Mon, 4 Feb 2013 13:55:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwKwCDxAxaLI; Mon, 4 Feb 2013 13:55:32 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id EC32A2240D50; Mon, 4 Feb 2013 13:55:31 +0100 (CET) Message-ID: <510FAFC2.9090307@deployingradius.com> Date: Mon, 04 Feb 2013 07:55:30 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510F6D53.7040803@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:55:34 -0000 yoshihiro.ohba@toshiba.co.jp wrote: > I suggest to investigate all corner cases before making a decision on a > particular mechanism. The corner cases are: > > (a) Client supports fragmentation and server does not support > fragmentation This is possible. > (a-1) Access-Request is fragmented > (a-2) Access-Challenge is fragmented > (a-3) Access-Accept is fragmented These scenarios are not possible. The draft talks about fragmenting *data*. The various packet types are transports used to carry data. Saying that an "Access-Request is fragmented" is meaningless. Packets aren't fragmented. If a client wants to send large amounts of data to the server, it needs to use Access-Requests to do so. It will signal support for fragmentation, as Alejandro said. The server will either ack that (via an attribute in a packet), or will ignore it. Alan DeKok. From aland@deployingradius.com Mon Feb 4 04:58:47 2013 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 86C7521F8613 for ; Mon, 4 Feb 2013 04:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIRhWnhLeYuN for ; Mon, 4 Feb 2013 04:58:47 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED2B321F85C2 for ; Mon, 4 Feb 2013 04:58:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 12F272240F52; Mon, 4 Feb 2013 13:58:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6jb4yCbTxXQ; Mon, 4 Feb 2013 13:58:45 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 4C9BB2240EBC; Mon, 4 Feb 2013 13:58:45 +0100 (CET) Message-ID: <510FB084.3010502@deployingradius.com> Date: Mon, 04 Feb 2013 07:58:44 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510E981A.7000004@deployingradius.com> <510F6F12.3050402@um.es> <510FABFD.5010302@deployingradius.com> <510FAE37.60700@um.es> In-Reply-To: <510FAE37.60700@um.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 12:58:47 -0000 Alejandro Perez Mendez wrote: > I think I didn't explained myself correctly. I'm not suggesting > modifying existing authentication methods. EAP-Success will still appear > only in Access-Accept packets. Just imagine the situation where the > Server wants to include an attribute X in one of the Access-Challenge > packets, and that by introducing that attribute X, the packet becomes > too big. That's the case I'm thinking of. Maybe that's an impossible > situation, I don't know. Authorization data from the server needs to wait until after authentication is complete. I'm not sure of any use-case for sending large amounts of non-authentication traffic from the server to the client. I would suggest that such a use-case is highly insecure. Alan DeKok. From yoshihiro.ohba@toshiba.co.jp Mon Feb 4 08:42:33 2013 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 BD8E721F84D1 for ; Mon, 4 Feb 2013 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.088 X-Spam-Level: X-Spam-Status: No, score=-7.088 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdaxpt2f3xeK for ; Mon, 4 Feb 2013 08:42:33 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD321F84C2 for ; Mon, 4 Feb 2013 08:42:32 -0800 (PST) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r14GgVqO010754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 01:42:31 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r14GgVkm015133; Tue, 5 Feb 2013 01:42:31 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 481; Tue, 5 Feb 2013 01:42:31 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r14GgUDE015127; Tue, 5 Feb 2013 01:42:30 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r14GgUnt009055; Tue, 5 Feb 2013 01:42:30 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA09052; Tue, 5 Feb 2013 01:42:30 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r14GgUwG021882; Tue, 5 Feb 2013 01:42:30 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r14GgUEf021871; Tue, 5 Feb 2013 01:42:30 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.20]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 01:42:30 +0900 From: To: Thread-Topic: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt Thread-Index: AQHOAtAYfMZDkob8D0CRfDRDujwWF5hp5zEQ Date: Mon, 4 Feb 2013 16:42:30 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78BE96905@tgxml338.toshiba.local> References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> <5108DDAA.9030708@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE95FD7@tgxml338.toshiba.local> <510F6D53.7040803@um.es> <674F70E5F2BE564CB06B6901FD3DD78BE962C1@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.3] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 04 Feb 2013 16:42:33 -0000 -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com]=20 Sent: Monday, February 04, 2013 9:07 PM To: ohba yoshihiro Cc: alex@um.es; abfab@ietf.org Subject: Re: [abfab] [radext] New Version Notification for draft-perez-rade= xt-radius-fragmentation-04.txt >>>>> writes: > I suggest to investigate all corner cases before making a decision > on a particular mechanism. The corner cases are: Sounds reasonable. > (b) Client does not support fragmentation and server supports In case= b-1 (access-request fragmentation) I'm confused. How is the access-request fragmented if a client doesn't supp= ort fragmentation? [YO] You are right, and people already correctly indicated "Not possible" i= n some of the cases including b-1. Yoshihiro Ohba From Josh.Howlett@ja.net Tue Feb 5 08:33:09 2013 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 6F69921F85C2 for ; Tue, 5 Feb 2013 08:33:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeFahix8sppK for ; Tue, 5 Feb 2013 08:33:08 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9387E21F86E7 for ; Tue, 5 Feb 2013 08:33:08 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4EF1D1A9F5F6_1113443B for ; Tue, 5 Feb 2013 16:33:07 +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 0BF791A9F4E4_1113443F for ; Tue, 5 Feb 2013 16:33:07 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 5 Feb 2013 16:33:06 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: Proposal for post-authentication attribute request Thread-Index: AQHOA755j10tqUgPnk2htHRD3jRAWQ== Date: Tue, 5 Feb 2013 16:33:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <82A78870C4FCE144949B68FD3B3F8D0C@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] Proposal for post-authentication attribute request 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, 05 Feb 2013 16:33:09 -0000 Jim has previously articulated a requirement for support of post-authentication attribute request, and to allow requests for attributes of the user and/or machine associated with the authentication. In a call before Christmas, Scott suggested a strategy based on the use of SAML Subject Confirmation. The idea is that the SAML Requester can use an attribute request using a new SAML Subject Confirmation Method. This Method gives (1) the value of the RADIUS State attribute pointing to the RADIUS session in question and (2) whether the response should include attributes describing the user or machine. Here's the proposed text: 8. RADIUS State Confirmation Method URI: urn:ietf:params:xml:ns:abfab:cm:radius-state The RADIUS State Confirmation Method indicates that the Subject is the system entity associated with a RADIUS Access-Accept message, identified by the value of the RADIUS message's State attribute. There are typically two types of system entity associated with a RADIUS authentication: a user or a machine. This Confirmation Method uses the Identity-Type TLV defined by [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation. This allows, for example, a SAML Requester to request attributes for a user, even if machine credentials were used in the original RADIUS authentication. Define an XML attribute ("RadiusStateValue") giving the RADIUS State attribute value Define an XML attribute ("RadiusIdentityType") giving the Identity-Type TLV value While working through this, I spotted a bug in the proposed ABFAB Assertion Query Profile in that it needs to specify a value for the RADIUS User-Name attribute which MUST accompany the SAML-Message attribute (per RFC2865). My view is that the user portion of the NAI in the User-Name attribute should take a well-known value for different types of SAML endpoints. For example, the attribute authority for RADIUS realm FOO could be named as saml2-attribute-authority@foo. SAML tends to use URIs to name such things, and so one option to improve consistency (at the expense of verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter (but which also supports naming RADIUS endpoints). Comments welcome... Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company 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. VAT No. 614944238 From ietf@augustcellars.com Tue Feb 5 12:02:07 2013 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 5F5BE21F8825 for ; Tue, 5 Feb 2013 12:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj5Y7tCcpxzJ for ; Tue, 5 Feb 2013 12:02:06 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id AD57321F8804 for ; Tue, 5 Feb 2013 12:02:06 -0800 (PST) Received: from Philemon (74-95-210-210-Houston.hfc.comcastbusiness.net [74.95.210.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 17D3738F12; Tue, 5 Feb 2013 12:02:05 -0800 (PST) From: "Jim Schaad" To: "'Josh Howlett'" , References: In-Reply-To: Date: Tue, 5 Feb 2013 14:01:39 -0600 Message-ID: <004701ce03db$9d15b610$d7412230$@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: AQHHnhuXdoasmf+fmY+/vIcRoLL/pZh4escQ Content-Language: en-us Subject: Re: [abfab] Proposal for post-authentication attribute request 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, 05 Feb 2013 20:02:07 -0000 Josh, I am not sure why you think that the RADIUS state variable needs to be put into the SAML and not just in the RADIUS message that is carrying the SAML request. Can you elaborate? Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Josh Howlett > Sent: Tuesday, February 05, 2013 10:33 AM > To: abfab@ietf.org > Subject: [abfab] Proposal for post-authentication attribute request > > Jim has previously articulated a requirement for support of post- > authentication attribute request, and to allow requests for attributes of the > user and/or machine associated with the authentication. > In a call before Christmas, Scott suggested a strategy based on the use of > SAML Subject Confirmation. > > The idea is that the SAML Requester can use an attribute request using a > new SAML Subject Confirmation Method. This Method gives (1) the value of > the RADIUS State attribute pointing to the RADIUS session in question and > (2) whether the response should include attributes describing the user or > machine. > > Here's the proposed text: > > 8. RADIUS State Confirmation Method > > URI: urn:ietf:params:xml:ns:abfab:cm:radius-state > > The RADIUS State Confirmation Method indicates that the Subject is > the system entity associated with a RADIUS Access-Accept message, > identified by the value of the RADIUS message's State attribute. > > There are typically two types of system entity associated with a > RADIUS authentication: a user or a machine. This Confirmation Method > uses the Identity-Type TLV defined by > [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation. This > allows, for example, a SAML Requester to request attributes for a > user, even if machine credentials were used in the original RADIUS > authentication. > > Define an XML attribute ("RadiusStateValue") giving the RADIUS State > attribute value > > Define an XML attribute ("RadiusIdentityType") giving the Identity-Type > TLV value > > Method="urn:ietf:params:xml:ns:abfab:cm:radius-state"> > RadiusIdentityType="1" /> > > > > While working through this, I spotted a bug in the proposed ABFAB Assertion > Query Profile in that it needs to specify a value for the RADIUS User-Name > attribute which MUST accompany the SAML-Message attribute (per > RFC2865). My view is that the user portion of the NAI in the User-Name > attribute should take a well-known value for different types of SAML > endpoints. For example, the attribute authority for RADIUS realm FOO could > be named as saml2-attribute-authority@foo. SAML tends to use URIs to > name such things, and so one option to improve consistency (at the expense > of > verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter > (but which also supports naming RADIUS endpoints). > > Comments welcome... > > Josh. > > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for- > profit company which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From gabilm@um.es Wed Feb 6 01:35:03 2013 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 AC15821F8800 for ; Wed, 6 Feb 2013 01:35:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZgxrs46XdL2 for ; Wed, 6 Feb 2013 01:35:03 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7E121F8793 for ; Wed, 6 Feb 2013 01:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id DCAEB4BD46; Wed, 6 Feb 2013 10:35:00 +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 18tbgtfjPmKs; Wed, 6 Feb 2013 10:35:00 +0100 (CET) Received: from [155.54.205.189] (inf-205-189.inf.um.es [155.54.205.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPSA id 11E744BD1B; Wed, 6 Feb 2013 10:34:57 +0100 (CET) Message-ID: <511223C1.2020901@um.es> Date: Wed, 06 Feb 2013 10:34:57 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal for post-authentication attribute request 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, 06 Feb 2013 09:35:03 -0000 On 05/02/13 17:33, Josh Howlett wrote: > Jim has previously articulated a requirement for support of > post-authentication attribute request, and to allow requests for > attributes of the user and/or machine associated with the authentication. > In a call before Christmas, Scott suggested a strategy based on the use of > SAML Subject Confirmation. > > The idea is that the SAML Requester can use an attribute request using a > new SAML Subject Confirmation Method. This Method gives (1) the value of > the RADIUS State attribute pointing to the RADIUS session in question and Do we have to take into account the scenario where the idP is not co-located with the Radius server? In this case this method is not valid. > (2) whether the response should include attributes describing the user or > machine. Using the current SAML AttributeQuery element the client can specify the list of desired attributes. Is it not enough to specify the set of attributes (user/machine) in the same query identified by urn? Regards, Gabi. > > Here's the proposed text: > > 8. RADIUS State Confirmation Method > > URI: urn:ietf:params:xml:ns:abfab:cm:radius-state > > The RADIUS State Confirmation Method indicates that the Subject is > the system entity associated with a RADIUS Access-Accept message, > identified by the value of the RADIUS message's State attribute. > > There are typically two types of system entity associated with a > RADIUS authentication: a user or a machine. This Confirmation Method > uses the Identity-Type TLV defined by > [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation. This > allows, for example, a SAML Requester to request attributes for a > user, even if machine credentials were used in the original RADIUS > authentication. > > Define an XML attribute ("RadiusStateValue") giving the RADIUS State > attribute value > > Define an XML attribute ("RadiusIdentityType") giving the Identity-Type > TLV value > > Method="urn:ietf:params:xml:ns:abfab:cm:radius-state"> > RadiusIdentityType="1" /> > > > > While working through this, I spotted a bug in the proposed ABFAB > Assertion Query Profile in that it needs to specify a value for the RADIUS > User-Name attribute which MUST accompany the SAML-Message attribute (per > RFC2865). My view is that the user portion of the NAI in the User-Name > attribute should take a well-known value for different types of SAML > endpoints. For example, the attribute authority for RADIUS realm FOO could > be named as saml2-attribute-authority@foo. SAML tends to use URIs to name > such things, and so one option to improve consistency (at the expense of > verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter > (but which also supports naming RADIUS endpoints). > > Comments welcome... > > Josh. > > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Feb 6 01:50:20 2013 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 C0E0C21F87FE for ; Wed, 6 Feb 2013 01:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5g7SPtqxPPW for ; Wed, 6 Feb 2013 01:50:20 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D88EC21F8756 for ; Wed, 6 Feb 2013 01:50:19 -0800 (PST) Received: from [130.246.252.205] (unknown [130.246.252.205]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.painless-security.com (Postfix) with ESMTPSA id 41C982021E; Wed, 6 Feb 2013 04:46:08 -0500 (EST) User-Agent: K-9 Mail for Android In-Reply-To: <511223C1.2020901@um.es> References: <511223C1.2020901@um.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----3BD6SBUDTJ4YCWSNHWTXBGUTQS7R4C" From: Sam Hartman Date: Wed, 06 Feb 2013 09:49:38 +0000 To: Gabriel Lopez ,Josh Howlett Message-ID: Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal for post-authentication attribute request 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, 06 Feb 2013 09:50:20 -0000 ------3BD6SBUDTJ4YCWSNHWTXBGUTQS7R4C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I don't see why a radius server couldn't communicate the state attri ute to an idp. The same attribute may apply to user and machine with different values.z Gabriel Lopez wrote: >On 05/02/13 17:33, Josh Howlett wrote: >> Jim has previously articulated a requirement for support of >> post-authentication attribute request, and to allow requests for >> attributes of the user and/or machine associated with the >authentication. >> In a call before Christmas, Scott suggested a strategy based on the >use of >> SAML Subject Confirmation. >> >> The idea is that the SAML Requester can use an attribute request >using a >> new SAML Subject Confirmation Method. This Method gives (1) the value >of >> the RADIUS State attribute pointing to the RADIUS session in question >and > >Do we have to take into account the scenario where the idP is not >co-located with the Radius server? >In this case this method is not valid. >> (2) whether the response should include attributes describing the >user or >> machine. >Using the current SAML AttributeQuery element the client can specify >the >list of desired attributes. Is it not enough to specify the set of >attributes (user/machine) in the same query identified by urn? > >Regards, Gabi. >> >> Here's the proposed text: >> >> 8. RADIUS State Confirmation Method >> >> URI: urn:ietf:params:xml:ns:abfab:cm:radius-state >> >> The RADIUS State Confirmation Method indicates that the Subject is >> the system entity associated with a RADIUS Access-Accept message, >> identified by the value of the RADIUS message's State attribute. >> >> There are typically two types of system entity associated with a >> RADIUS authentication: a user or a machine. This Confirmation >Method >> uses the Identity-Type TLV defined by >> [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation. This >> allows, for example, a SAML Requester to request attributes for a >> user, even if machine credentials were used in the original RADIUS >> authentication. >> >> Define an XML attribute ("RadiusStateValue") giving the RADIUS >State >> attribute value >> >> Define an XML attribute ("RadiusIdentityType") giving the >Identity-Type >> TLV value >> >> > Method="urn:ietf:params:xml:ns:abfab:cm:radius-state"> >> > RadiusIdentityType="1" /> >> >> >> >> While working through this, I spotted a bug in the proposed ABFAB >> Assertion Query Profile in that it needs to specify a value for the >RADIUS >> User-Name attribute which MUST accompany the SAML-Message attribute >(per >> RFC2865). My view is that the user portion of the NAI in the >User-Name >> attribute should take a well-known value for different types of SAML >> endpoints. For example, the attribute authority for RADIUS realm FOO >could >> be named as saml2-attribute-authority@foo. SAML tends to use URIs to >name >> such things, and so one option to improve consistency (at the expense >of >> verbosity) is to use the aaa: and/or aaas: URI schemes defined by >Diameter >> (but which also supports naming RADIUS endpoints). >> >> Comments welcome... >> >> Josh. >> >> >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >> not-for-profit company which is registered in England under No. >2881024 >> and whose Registered Office is at Lumen House, Library Avenue, >> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >> >> _______________________________________________ >> 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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------3BD6SBUDTJ4YCWSNHWTXBGUTQS7R4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I don't see why a radius server couldn't communicate the state attri ute to an idp.
The same attribute may apply to user and machine with different values.z

Gabriel Lopez <gabilm@um.es> wrote:
On 05/02/13 17:33, Josh Howlett wrote:
Jim has previously articulated a requirement for support of
post-authentication attribute request, and to allow requests for
attributes of the user and/or machine associated with the authentication.
In a call before Christmas, Scott suggested a strategy based on the use of
SAML Subject Confirmation.

The idea is that the SAML Requester can use an attribute request using a
new SAML Subject Confirmation Method. This Method gives (1) the value of
the RADIUS State attribute pointing to the RADIUS session in question and

Do we have to take into account the scenario where the idP is not
co-located with the Radius server?
In this case this method is not valid.
 
(2) whether the response should include attributes describing the user or
machine.
Using the current SAML AttributeQuery element the client can specify the
list of desired attributes. Is it not enough to specify the set of
attributes (user/machine) in the same query identified by urn?

Regards, Gabi.

Here's the proposed text:

8.  RADIUS State Confirmation Method

URI: urn:ietf:params:xml:ns:abfab:cm:radius-state

The RADIUS State Confirmation Method indicates that the Subject is
the system entity associated with a RADIUS Access-Accept message,
identified by the value of the RADIUS message's State attribute.

There are typically two types o
 f
system entity associated with a
RADIUS authentication: a user or a machine.  This Confirmation Method
uses the Identity-Type TLV defined by
[I-D.ietf-emu-eap-tunnel-method] to permit disambiguation.  This
allows, for example, a SAML Requester to request attributes for a
user, even if machine credentials were used in the original RADIUS
authentication.

Define an XML attribute ("RadiusStateValue") giving the RADIUS State
attribute value

Define an XML attribute ("RadiusIdentityType") giving the Identity-Type
TLV value

<SubjectConfirmation
Method="urn:ietf:params:xml:ns:abfab:cm:radius-state">
<SubjectConfirmationData RadiusStateValue="ABC123"
RadiusIdentityType="1" />
</SubjectConfirmation>


While working through this, I spotted a bug in the proposed ABFAB
Assertion Query Profile in that it needs to specify a value for the RADIUS
User-Name attr
 ibute
which MUST accompany the SAML-Message attribute (per
RFC2865). My view is that the user portion of the NAI in the User-Name
attribute should take a well-known value for different types of SAML
endpoints. For example, the attribute authority for RADIUS realm FOO could
be named as saml2-attribute-authority@foo. SAML tends to use URIs to name
such things, and so one option to improve consistency (at the expense of
verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter
(but which also supports naming RADIUS endpoints).

Comments welcome...

Josh.



Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238


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


--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------3BD6SBUDTJ4YCWSNHWTXBGUTQS7R4C-- From gabilm@um.es Wed Feb 6 06:01:04 2013 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 1014721F869C for ; Wed, 6 Feb 2013 06:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPyDEMOT3pLl for ; Wed, 6 Feb 2013 06:01:02 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9259921F8622 for ; Wed, 6 Feb 2013 06:01:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 0D8135D550; Wed, 6 Feb 2013 15:01:01 +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 EkJPxLAfMTti; Wed, 6 Feb 2013 15:01:00 +0100 (CET) Received: from [155.54.205.189] (inf-205-189.inf.um.es [155.54.205.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPSA id 2B50E5D525; Wed, 6 Feb 2013 15:00:58 +0100 (CET) Message-ID: <5112621A.7080705@um.es> Date: Wed, 06 Feb 2013 15:00:58 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sam Hartman References: <511223C1.2020901@um.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060200080202000604000507" Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal for post-authentication attribute request 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, 06 Feb 2013 14:01:04 -0000 This is a multi-part message in MIME format. --------------060200080202000604000507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06/02/13 10:49, Sam Hartman wrote: > I don't see why a radius server couldn't communicate the state attri > ute to an idp. Does the idp understand this attribute? I mean, the idp could understand the user-name, but I'm not sure if the state attribute.... regards, Gabi. > The same attribute may apply to user and machine with different values.z > > Gabriel Lopez wrote: > > On 05/02/13 17:33, Josh Howlett wrote: > > Jim has previously articulated a requirement for support of > post-authentication attribute request, and to allow requests > for attributes of the user and/or machine associated with the > authentication. In a call before Christmas, Scott suggested a > strategy based on the use of SAML Subject Confirmation. The > idea is that the SAML Requester can use an attribute request > using a new SAML Subject Confirmation Method. This Method > gives (1) the value of the RADIUS State attribute pointing to > the RADIUS session in question and > > > Do we have to take into account the scenario where the idP is not > co-located with the Radius server? > In this case this method is not valid. > > > (2) whether the response should include attributes describing > the user or machine. > > Using the current SAML AttributeQuery element the client can specify the > list of desired attributes. Is it not enough to specify the set of > attributes (user/machine) in the same query identified by urn? > > Regards, Gabi. > > Here's the proposed text: 8. RADIUS State Confirmation Method > URI: urn:ietf:params:xml:ns:abfab:cm:radius-state The RADIUS > State Confirmation Method indicates that the Subject is the > system entity associated with a RADIUS Access-Accept message, > identified by the value of the RADIUS message's State > attribute. There are typically two types o f system entity > associated with a RADIUS authentication: a user or a machine. > This Confirmation Method uses the Identity-Type TLV defined by > [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation. > This allows, for example, a SAML Requester to request > attributes for a user, even if machine credentials were used > in the original RADIUS authentication. Define an XML attribute > ("RadiusStateValue") giving the RADIUS State attribute value > Define an XML attribute ("RadiusIdentityType") giving the > Identity-Type TLV value Method="urn:ietf:params:xml:ns:abfab:cm:radius-state"> > RadiusIdentityType="1" /> While working > through this, I spotted a bug in the proposed ABFAB Assertion > Query Profile in that it needs to specify a value for the > RADIUS User-Name attr ibute which MUST accompany the > SAML-Message attribute (per RFC2865). My view is that the user > portion of the NAI in the User-Name attribute should take a > well-known value for different types of SAML endpoints. For > example, the attribute authority for RADIUS realm FOO could be > named as saml2-attribute-authority@foo. SAML tends to use URIs > to name such things, and so one option to improve consistency > (at the expense of verbosity) is to use the aaa: and/or aaas: > URI schemes defined by Diameter (but which also supports > naming RADIUS endpoints). Comments welcome... Josh. Janet(UK) > is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under > No. 2881024 and whose Registered Office is at Lumen House, > Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. > VAT No. 614944238 > ------------------------------------------------------------------------ > 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 > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. --------------060200080202000604000507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 06/02/13 10:49, Sam Hartman wrote:
I don't see why a radius server couldn't communicate the state attri ute to an idp.
Does the idp understand this attribute? I mean, the idp could understand the user-name, but I'm not sure if the state attribute....

regards, Gabi.
The same attribute may apply to user and machine with different values.z

Gabriel Lopez <gabilm@um.es> wrote: 
On 05/02/13 17:33, Josh Howlett wrote:

Jim has previously articulated a requirement for support of
post-authentication attribute request, and to allow requests for
attributes of the user and/or machine associated with the authentication.
In a call before Christmas, Scott suggested a strategy based on the use of
SAML Subject Confirmation.

The idea is that the SAML Requester can use an attribute request using a
new SAML Subject Confirmation Method. This Method gives (1) the value of
the RADIUS State attribute pointing to the RADIUS session in question and

Do we have to take into account the scenario where the idP is not
co-located with the Radius server?
In this case this method is not valid.
 

(2) whether the response should include attributes describing the user or
machine.

Using the current SAML AttributeQuery element the client can specify the
list of desired attributes. Is it not enough to specify the set of
attributes (user/machine) in the same query identified by urn?

Regards, Gabi.


Here's the proposed text:

8.  RADIUS State Confirmation Method

URI: urn:ietf:params:xml:ns:abfab:cm:radius-state

The RADIUS State Confirmation Method indicates that the Subject is
the system entity associated with a RADIUS Access-Accept message,
identified by the value of the RADIUS message's State attribute.

There are typically two types o
 f
system entity associated with a
RADIUS authentication: a user or a machine.  This Confirmation Method
uses the Identity-Type TLV defined by
[I-D.ietf-emu-eap-tunnel-method] to permit disambiguation.  This
allows, for example, a SAML Requester to request attributes for a
user, even if machine credentials were used in the original RADIUS
authentication.

Define an XML attribute ("RadiusStateValue") giving the RADIUS State
attribute value

Define an XML attribute ("RadiusIdentityType") giving the Identity-Type
TLV value

<SubjectConfirmation
Method="urn:ietf:params:xml:ns:abfab:cm:radius-state">
<SubjectConfirmationData RadiusStateValue="ABC123"
RadiusIdentityType="1" />
</SubjectConfirmation>


While working through this, I spotted a bug in the proposed ABFAB
Assertion Query Profile in that it needs to specify a value for the RADIUS
User-Name attr
 ibute
which MUST accompany the SAML-Message attribute (per
RFC2865). My view is that the user portion of the NAI in the User-Name
attribute should take a well-known value for different types of SAML
endpoints. For example, the attribute authority for RADIUS realm FOO could
be named as saml2-attribute-authority@foo. SAML tends to use URIs to name
such things, and so one option to improve consistency (at the expense of
verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter
(but which also supports naming RADIUS endpoints).

Comments welcome...

Josh.



Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238



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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--------------060200080202000604000507-- From cantor.2@osu.edu Wed Feb 6 07:10:44 2013 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 240FF21F87F7 for ; Wed, 6 Feb 2013 07:10:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiW9zVcFcF4u for ; Wed, 6 Feb 2013 07:10:43 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6C21F87A5 for ; Wed, 6 Feb 2013 07:10:43 -0800 (PST) Received: from mail46-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 15:10:42 +0000 Received: from mail46-ch1 (localhost [127.0.0.1]) by mail46-ch1-R.bigfish.com (Postfix) with ESMTP id 7DFB52A0202; Wed, 6 Feb 2013 15:10:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1155h) Received-SPF: pass (mail46-ch1: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1 (MessageSwitch) id 1360163439958933_13223; Wed, 6 Feb 2013 15:10:39 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail46-ch1.bigfish.com (Postfix) with ESMTP id E3A5D260216; Wed, 6 Feb 2013 15:10:39 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 15:10:35 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf06 (Postfix) with ESMTP id 0CB683C005D; Wed, 6 Feb 2013 10:10:15 -0500 (EST) 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 id 14.02.0328.009; Wed, 6 Feb 2013 10:10:35 -0500 From: "Cantor, Scott" To: Josh Howlett , "abfab@ietf.org" Thread-Topic: Proposal for post-authentication attribute request Thread-Index: AQHOA755j10tqUgPnk2htHRD3jRAWZhs8CoA Date: Wed, 6 Feb 2013 15:10:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Subject: Re: [abfab] Proposal for post-authentication attribute request 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, 06 Feb 2013 15:10:44 -0000 > The idea is that the SAML Requester can use an attribute request using a > new SAML Subject Confirmation Method. This Method gives (1) the value of > the RADIUS State attribute pointing to the RADIUS session in question and > (2) whether the response should include attributes describing the user or > machine. Wouldn't one assume that absent this subject confirmation, the query was ab= out the subject (the user)? > Define an XML attribute ("RadiusStateValue") giving the RADIUS State > attribute value >=20 > Define an XML attribute ("RadiusIdentityType") giving the Identity-Typ= e > TLV value You can do that, but they'll have to be namespace qualified, the wildcard i= n the schema requires namespace=3D"##other", which doesn't permit unqualifi= ed attributes. -- Scott From alex@um.es Fri Feb 8 01:21:32 2013 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 AC6F121F86DC; Fri, 8 Feb 2013 01:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaEAEDYiNbX7; Fri, 8 Feb 2013 01:21:30 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B521F8596; Fri, 8 Feb 2013 01:21:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id CF91553708; Fri, 8 Feb 2013 10:21:26 +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 rzhzaYT6eCCZ; Fri, 8 Feb 2013 10:21:26 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 7EA2953626; Fri, 8 Feb 2013 10:21:24 +0100 (CET) Message-ID: <5114C394.7060303@um.es> Date: Fri, 08 Feb 2013 10:21:24 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: "radext@ietf.org" References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> In-Reply-To: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020402050503090004070306" Cc: "abfab@ietf.org" Subject: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 08 Feb 2013 09:21:33 -0000 This is a multi-part message in MIME format. --------------020402050503090004070306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, after the valuable comments received from Jim Schaad and Yoshihiro Ohba, and further internal discussion, we have uploaded an updated version of the RADIUS fragmentation draft. The most relevant changes include: * Fragmentation can only occur after authentication. Clients wanting to send large amounts of data can signal this situation on the first Access-Request, but the exchange will happen after authentication is completed for security reasons. * More-Data-Pending is now called Frag-Status, and its functionality has been extended to cover other fragmentation signalling (including the More-Data-Pending one). * Access-Accept fragmentation is based on a series of Access-Accept packets, not mixing different types. * Security considerations and IANA considerations have been significantly improved. * The section regarding interaction with EAP has been removed, as it does not make sense any more. * Included discussion about allowed large packet size and its security implications. * Included discussion about unsupported packet types (i.e. accounting and CoA) and the rationale behind that decision. Regards, Alejandro -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt Fecha: Fri, 08 Feb 2013 01:01:48 -0800 De: internet-drafts@ietf.org Para: alex@um.es CC: aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es A new version of I-D, draft-perez-radext-radius-fragmentation-05.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 05 Title: Support of fragmentation of RADIUS packets Creation date: 2013-02-08 WG ID: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-05.txt Status: http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation Htmlized: http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-05 Abstract: This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4096 bytes limit. The IETF Secretariat --------------020402050503090004070306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

after the valuable comments received from Jim Schaad and Yoshihiro Ohba, and further internal discussion, we have uploaded an updated version of the RADIUS fragmentation draft.

The most relevant changes include:
  • Fragmentation can only occur after authentication. Clients wanting to send large amounts of data can signal this situation on the first Access-Request, but the exchange will happen after authentication is completed for security reasons.
  • More-Data-Pending is now called Frag-Status, and its functionality has been extended to cover other fragmentation signalling (including the More-Data-Pending one).
  • Access-Accept fragmentation is based on a series of Access-Accept packets, not mixing different types.
  • Security considerations and IANA considerations have been significantly improved.
  • The section regarding interaction with EAP has been removed, as it does not make sense any more.
  • Included discussion about allowed large packet size and its security implications.
  • Included discussion about unsupported packet types (i.e. accounting and CoA) and the rationale behind that decision.
Regards,
Alejandro

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt
Fecha: Fri, 08 Feb 2013 01:01:48 -0800
De: internet-drafts@ietf.org
Para: alex@um.es
CC: aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es 


A new version of I-D, draft-perez-radext-radius-fragmentation-05.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 05
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-02-08
WG ID:		 Individual Submission
Number of pages: 27
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-05.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-05

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4096 bytes limit.

                                                                                  


The IETF Secretariat


--------------020402050503090004070306-- From kwiereng@cisco.com Fri Feb 8 02:31:41 2013 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 C16A621F8733 for ; Fri, 8 Feb 2013 02:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU4Yqi3l8iDv for ; Fri, 8 Feb 2013 02:31:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 980F021F8765 for ; Fri, 8 Feb 2013 02:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=278; q=dns/txt; s=iport; t=1360319501; x=1361529101; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=boq2/C7EvMcqhRmBDlEpNSMCZp879VorKd+j8cx166s=; b=N+M8WQBOs9CS9NNf5IrUo5SgbQrf2jgPZyO7IVikbW8DKNqHy/dVpPTR BDvZdvPiurXRQk/mYeCJtWFuyzqsn6PBXYI/G+1FgPAhMZvHU7V5CEGz6 9wAzfcuv2m4c2vpDqKGTt68HpJNXjy5MxVo3r2MJDhhAhO/kNqkvQjBVX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADrTFFGQ/khR/2dsb2JhbABFwQsWc4IfAQEBAwE6RAtRVwaIHgbAUpB7YQOWJJBSgwE X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; d="scan'208";a="150283133" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2013 10:31:37 +0000 Received: from dhcp-10-61-105-5.cisco.com (dhcp-10-61-105-5.cisco.com [10.61.105.5]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r18AVaVe018017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Feb 2013 10:31:37 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 8 Feb 2013 11:31:36 +0100 References: <20130207213506.17277.42570.idtracker@ietfa.amsl.com> To: "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [abfab] abfab scheduled for IETF 86 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, 08 Feb 2013 10:31:41 -0000 Hi, Abfab is (tentatively!) scheduled for: > abfab Session 1 (2:00:00) > Wednesday, Afternoon Session I 1300-1500 > Room Name: Caribbean 6 > --------------------------------------------- this is also a good time to request a speaking slot! Klaas & Leif From hartmans@painless-security.com Sun Feb 10 05:54:59 2013 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 6B2DE21F85AC; Sun, 10 Feb 2013 05:54:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgVTGh6LWrTg; Sun, 10 Feb 2013 05:54:59 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7F21F85AB; Sun, 10 Feb 2013 05:54:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [62.50.232.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 751A22026C; Sun, 10 Feb 2013 08:50:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6BB9643FD; Sun, 10 Feb 2013 08:54:53 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> Date: Sun, 10 Feb 2013 08:54:53 -0500 In-Reply-To: <5114C394.7060303@um.es> (Alejandro Perez Mendez's message of "Fri, 08 Feb 2013 10:21:24 +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: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 10 Feb 2013 13:54:59 -0000 Hi, Alex. With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of the proposed changes: * Fragmentation can only occur after authentication. Clients wanting to send large amounts of data can signal this situation on the first Access-Request, but the exchange will happen after authentication is completed for security reasons. Unfortunately some of the use cases for SAML involve looking at the SAML request to determine what authentication would be acceptable. As an example, we need to look at the LOA to determine what EAP methods are acceptable. As such, we do actually need to be able to send things like SAML requests prior to authentication. So, I'd like to better understand the reasons for this change. If it's DOS concerns, I would prefer to revert the change and simply note the concern in security considerations. Also, from a DOS standpoint, since the entity being authenticated is the user, not the NAS, I'd like to understand how you're better off from a DOS standpoint after authentication. --Sam From aland@deployingradius.com Sun Feb 10 07:10:07 2013 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 B6DD021F8455; Sun, 10 Feb 2013 07:10:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw68YwdAvtH4; Sun, 10 Feb 2013 07:10:07 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8021F8450; Sun, 10 Feb 2013 07:10:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 15F742240F82; Sun, 10 Feb 2013 16:10:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUZVPjh9kyyb; Sun, 10 Feb 2013 16:10:03 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 5B4BC2240B5A; Sun, 10 Feb 2013 16:10:02 +0100 (CET) Message-ID: <5117B84C.10405@deployingradius.com> Date: Sun, 10 Feb 2013 10:10:04 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 10 Feb 2013 15:10:08 -0000 Sam Hartman wrote: > So, I'd like to better understand the reasons for this change. > If it's DOS concerns, I would prefer to revert the change and simply > note the concern in security considerations. It's partly DoS. The issue of the NAS sending large amounts of data to the home server is an issue. If it's for a trusted user, OK. If it's for an unknown user, it's not OK. i.e. even if the NAS only sends 10K of data, attackers can open up thousands of unauthenticated connections, and potentially DoS the server. > Also, from a DOS standpoint, since the entity being authenticated is the > user, not the NAS, I'd like to understand how you're better off from a > DOS standpoint after authentication. It reduces the attack profile. The issue of large volumes of authentication data is limited to (a) trusted NASes, and (b) known users. The other issues are packet size, and changes to existing EAP processing. EAP already largely fills RADIUS packets. Adding SAML data means that any UDP packet will be fragmented. It will then fail to cross the wider net. TCP / TLS doesn't have this problem, of course. The EAP processing issue is about synchronization. The EAP-Success needs to be in the Access-Accept. If the NAS is sending large amounts of data, it may overflow the initial sequence of packets. So... does the data get fragmented to the post-authentication stage? Will the NAS continue trying to send more data after EAP-Success? Will the server send EAP-Success in an Access-Challenge, and continue asking for the data? It's not clear what's best here. Alan DeKok. From alex@um.es Mon Feb 11 02:00:48 2013 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 DBCFD21F86D9; Mon, 11 Feb 2013 02:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTQ43ziBAKeY; Mon, 11 Feb 2013 02:00:47 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 164F821F86AF; Mon, 11 Feb 2013 02:00:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 26F7C53691; Mon, 11 Feb 2013 11:00:45 +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 FiapnXENl6KN; Mon, 11 Feb 2013 11:00:44 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id BF6B15377B; Mon, 11 Feb 2013 11:00:43 +0100 (CET) Message-ID: <5118C14A.80409@um.es> Date: Mon, 11 Feb 2013 11:00:42 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sam Hartman References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 11 Feb 2013 10:00:48 -0000 > Hi, Alex. > > With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of > the proposed changes: > > * Fragmentation can only occur after authentication. Clients wanting to send > large amounts of data can signal this situation on the first > Access-Request, but the exchange will happen after authentication is > completed for security reasons. > > > Unfortunately some of the use cases for SAML involve looking at the SAML > request to determine what authentication would be acceptable. As an > example, we need to look at the LOA to determine what EAP methods are > acceptable. Hi Sam, do you expect this data to be so large that makes the first Access-Request packet to exceed the limit? It is not avoiding SAML data to be on the packet, just avoiding the use of fragmentation for security reasons. When using EAP, the first Access-Request is usually small, as it only contains EAP-Identity. Hence, almost 4KB would be available for SAML data. Regards, Alejandro > As such, we do actually need to be able to send things like SAML > requests prior to authentication. > > So, I'd like to better understand the reasons for this change. > If it's DOS concerns, I would prefer to revert the change and simply > note the concern in security considerations. > > Also, from a DOS standpoint, since the entity being authenticated is the > user, not the NAS, I'd like to understand how you're better off from a > DOS standpoint after authentication. > > --Sam From ietf@augustcellars.com Mon Feb 11 06:39:49 2013 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 22C7121F8826; Mon, 11 Feb 2013 06:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LQA+RRNAluZ; Mon, 11 Feb 2013 06:39:48 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 98E1821F8800; Mon, 11 Feb 2013 06:39:48 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 138CD38F25; Mon, 11 Feb 2013 06:39:47 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , "'Sam Hartman'" References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5118C14A.80409@um.es> In-Reply-To: <5118C14A.80409@um.es> Date: Mon, 11 Feb 2013 06:39:19 -0800 Message-ID: <009301ce0865$93c31d80$bb495880$@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: AQJ0Y0qCk2RfjVP9dQOdyaZ8W81U7wI0Zd0uAVZ7gxkCCHJUZJb7aang Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 11 Feb 2013 14:39:49 -0000 I just created a really simple one, and it was less than 1K in size. However, this assumes that it is not signed. If you sign it then it will quickly jump in size as you are going to be looking at have a certificate and a signature included in the message which will likely be greater than 4K. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of > Alejandro Perez Mendez > Sent: Monday, February 11, 2013 2:01 AM > To: Sam Hartman > Cc: radext@ietf.org; abfab@ietf.org > Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext- > radius-fragmentation-05.txt > > > > Hi, Alex. > > > > With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of > > the proposed changes: > > > > * Fragmentation can only occur after authentication. Clients wanting to > send > > large amounts of data can signal this situation on the first > > Access-Request, but the exchange will happen after authentication is > > completed for security reasons. > > > > > > Unfortunately some of the use cases for SAML involve looking at the > > SAML request to determine what authentication would be acceptable. As > > an example, we need to look at the LOA to determine what EAP methods > > are acceptable. > Hi Sam, > > do you expect this data to be so large that makes the first Access-Request > packet to exceed the limit? It is not avoiding SAML data to be on the packet, > just avoiding the use of fragmentation for security reasons. When using EAP, > the first Access-Request is usually small, as it only contains EAP-Identity. > Hence, almost 4KB would be available for SAML data. > > Regards, > Alejandro > > > As such, we do actually need to be able to send things like SAML > > requests prior to authentication. > > > > So, I'd like to better understand the reasons for this change. > > If it's DOS concerns, I would prefer to revert the change and simply > > note the concern in security considerations. > > > > Also, from a DOS standpoint, since the entity being authenticated is > > the user, not the NAS, I'd like to understand how you're better off > > from a DOS standpoint after authentication. > > > > --Sam > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From cantor.2@osu.edu Mon Feb 11 07:12:40 2013 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 2E15B21F8797; Mon, 11 Feb 2013 07:12:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekuEVarCN8MC; Mon, 11 Feb 2013 07:12:39 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4591521F879A; Mon, 11 Feb 2013 07:12:39 -0800 (PST) Received: from mail101-co1-R.bigfish.com (10.243.78.200) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 15:12:38 +0000 Received: from mail101-co1 (localhost [127.0.0.1]) by mail101-co1-R.bigfish.com (Postfix) with ESMTP id 109623C0139; Mon, 11 Feb 2013 15:12:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zf7Izbb2dI98dI9371I146fIzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail101-co1: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail101-co1 (localhost.localdomain [127.0.0.1]) by mail101-co1 (MessageSwitch) id 136059555688898_13562; Mon, 11 Feb 2013 15:12:36 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.207]) by mail101-co1.bigfish.com (Postfix) with ESMTP id 13176580068; Mon, 11 Feb 2013 15:12:36 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 15:12:34 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf08 (Postfix) with ESMTP id 19B8B2E0059; Mon, 11 Feb 2013 10:12:34 -0500 (EST) 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 id 14.02.0328.009; Mon, 11 Feb 2013 10:12:34 -0500 From: "Cantor, Scott" To: Jim Schaad , 'Alejandro Perez Mendez' , 'Sam Hartman' Thread-Topic: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt Thread-Index: AQHOCGo36D4/g1Tcn0O+OOMs17kL9A== Date: Mon, 11 Feb 2013 15:12:33 +0000 Message-ID: In-Reply-To: <009301ce0865$93c31d80$bb495880$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A72DB382B85A643B085F9DC1A9CA1FD@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 11 Feb 2013 15:12:40 -0000 On 2/11/13 9:39 AM, "Jim Schaad" wrote: >I just created a really simple one, and it was less than 1K in size. >However, this assumes that it is not signed. If you sign it then it will >quickly jump in size as you are going to be looking at have a certificate >and a signature included in the message which will likely be greater than >4K. You don't have to include a certificate to sign a message, though. Not that it isn't large anyway, but it's not impossible to stay under 4k even when signing. -- Scott From ietf@augustcellars.com Mon Feb 11 07:36:19 2013 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 718F221F8849; Mon, 11 Feb 2013 07:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laoIhz2oQ4uu; Mon, 11 Feb 2013 07:36:18 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBD21F87D4; Mon, 11 Feb 2013 07:36:09 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id BFCE92CA18; Mon, 11 Feb 2013 07:36:08 -0800 (PST) From: "Jim Schaad" To: "'Cantor, Scott'" , "'Alejandro Perez Mendez'" , "'Sam Hartman'" References: <009301ce0865$93c31d80$bb495880$@augustcellars.com> In-Reply-To: Date: Mon, 11 Feb 2013 07:35:39 -0800 Message-ID: <00a001ce086d$72c47c20$584d7460$@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: AQMRF364oFEzl9j1/fNhPIWYyzVN2pXuq2Eg Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 11 Feb 2013 15:36:19 -0000 It is true that a certificate is not needed, however in the cases that we are looking at - cross-organization requests - it will be more likely to want to include it than not. Otherwise you have a much harder problem of supporting referring to and fetching the certificate in order to validate the signature. That said, I would hope that it would be possible to not do any signatures at all. I just don't know that it is realistic to require that the signature be omitted. jim > -----Original Message----- > From: Cantor, Scott [mailto:cantor.2@osu.edu] > Sent: Monday, February 11, 2013 7:13 AM > To: Jim Schaad; 'Alejandro Perez Mendez'; 'Sam Hartman' > Cc: radext@ietf.org; abfab@ietf.org > Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext- > radius-fragmentation-05.txt > > On 2/11/13 9:39 AM, "Jim Schaad" wrote: > > >I just created a really simple one, and it was less than 1K in size. > >However, this assumes that it is not signed. If you sign it then it > >will quickly jump in size as you are going to be looking at have a > >certificate and a signature included in the message which will likely > >be greater than 4K. > > You don't have to include a certificate to sign a message, though. > > Not that it isn't large anyway, but it's not impossible to stay under 4k even > when signing. > > -- Scott From cantor.2@osu.edu Mon Feb 11 07:44:48 2013 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 D343E21F87A9 for ; Mon, 11 Feb 2013 07:44: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR58-1bqHQAH for ; Mon, 11 Feb 2013 07:44:48 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id D27CE21F8767 for ; Mon, 11 Feb 2013 07:44:47 -0800 (PST) Received: from mail264-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 15:44:47 +0000 Received: from mail264-ch1 (localhost [127.0.0.1]) by mail264-ch1-R.bigfish.com (Postfix) with ESMTP id 2CCE52000C0; Mon, 11 Feb 2013 15:44:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zf7Izbb2dI98dI9371Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail264-ch1: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail264-ch1 (localhost.localdomain [127.0.0.1]) by mail264-ch1 (MessageSwitch) id 1360597485464015_29173; Mon, 11 Feb 2013 15:44:45 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail264-ch1.bigfish.com (Postfix) with ESMTP id 6DE62CC004B; Mon, 11 Feb 2013 15:44:45 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 15:44:44 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf02 (Postfix) with ESMTP id 4D0C520047; Mon, 11 Feb 2013 10:44:44 -0500 (EST) 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 id 14.02.0328.009; Mon, 11 Feb 2013 10:44:44 -0500 From: "Cantor, Scott" To: Jim Schaad , 'Alejandro Perez Mendez' Thread-Topic: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt Thread-Index: AQHOCGo36D4/g1Tcn0O+OOMs17kL9Jh1HeCA//+usQA= Date: Mon, 11 Feb 2013 15:44:43 +0000 Message-ID: In-Reply-To: <00a001ce086d$72c47c20$584d7460$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <77246824C5AE864FA946F70BBF8A6B75@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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, 11 Feb 2013 15:44:48 -0000 On 2/11/13 10:35 AM, "Jim Schaad" wrote: >It is true that a certificate is not needed, however in the cases that we >are looking at - cross-organization requests - it will be more likely to >want to include it than not. Otherwise you have a much harder problem of >supporting referring to and fetching the certificate in order to validate >the signature. Well, not to dispute a major reason this WG exists, but we do just fine with SAML metadata for that purpose. -- Scott From hartmans@painless-security.com Tue Feb 12 05:15:16 2013 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 0524721F8D74; Tue, 12 Feb 2013 05:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuDPTVlxZpur; Tue, 12 Feb 2013 05:15:15 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9881521F8D71; Tue, 12 Feb 2013 05:15:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id AD1B720115; Tue, 12 Feb 2013 08:10:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A562E43FD; Tue, 12 Feb 2013 08:15:12 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5117B84C.10405@deployingradius.com> Date: Tue, 12 Feb 2013 08:15:12 -0500 In-Reply-To: <5117B84C.10405@deployingradius.com> (Alan DeKok's message of "Sun, 10 Feb 2013 10:10:04 -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 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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: Tue, 12 Feb 2013 13:15:16 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> It's partly DoS. The issue of the NAS sending large amounts Alan> of data to the home server is an issue. If it's for a trusted Alan> user, OK. If it's for an unknown user, it's not OK. OK. I'm confused, because the NAS is sending data for itself in the cases where we're talking about. If the data is being sent by the user, I'd expect it to be in the EAP stream. The cases I at least am contemplating here are where the NAS wants to send data about what it requires etc. Alan> i.e. even if the NAS only sends 10K of data, attackers can Alan> open up thousands of unauthenticated connections, and Alan> potentially DoS the server. Attackers who have any valid account could probably do the same. >> Also, from a DOS standpoint, since the entity being authenticated >> is the user, not the NAS, I'd like to understand how you're >> better off from a DOS standpoint after authentication. Alan> It reduces the attack profile. The issue of large volumes Alan> of authentication data is limited to (a) trusted NASes, and Alan> (b) known users. Although this is also limited to trusted NASes. The question is whether known user vs unknown user makes a difference for data between NAS and home server. Alan> The other issues are packet size, and changes to existing Alan> EAP processing. EAP already largely fills RADIUS packets. Alan> Adding SAML data means that any UDP packet will be fragmented. Alan> It will then fail to cross the wider net. TCP / TLS doesn't Alan> have this problem, of course. my assumption is that if you were sending access-accept saml auth data you'd do it before you started EAP. --Sam From aland@deployingradius.com Tue Feb 12 06:23:11 2013 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 C5FE921F8B1E; Tue, 12 Feb 2013 06:23:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0MLFjPyJfAJ; Tue, 12 Feb 2013 06:23:11 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 357F721F8B0A; Tue, 12 Feb 2013 06:23:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 30BC82240C42; Tue, 12 Feb 2013 15:22:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HP+oQ+i0mLd; Tue, 12 Feb 2013 15:22:14 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 72D972240B4D; Tue, 12 Feb 2013 15:22:13 +0100 (CET) Message-ID: <511A5014.6050503@deployingradius.com> Date: Tue, 12 Feb 2013 09:22:12 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5117B84C.10405@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.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: Tue, 12 Feb 2013 14:23:11 -0000 Sam Hartman wrote: > I'm confused, because the NAS is sending data for itself in the cases > where we're talking about. The issue is that the NAS sends data on behalf of the user. Even if the user is unknown. So attackers can leverage the NAS to send large amounts of data. > Attackers who have any valid account could probably do the same. Yes. But that allows a negative feedback effect. You call the known person and tell them to stop attacking you. > Although this is also limited to trusted NASes. > The question is whether known user vs unknown user makes a difference > for data between NAS and home server. I think it does. It lowers the attack profile. > my assumption is that if you were sending access-accept saml auth data > you'd do it before you started EAP. I'm wary of that approach. Alan DeKok. From bernard_aboba@hotmail.com Tue Feb 12 07:42:51 2013 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 C21BE21F8D96; Tue, 12 Feb 2013 07:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce8c5t7K3X7J; Tue, 12 Feb 2013 07:42:51 -0800 (PST) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id 383E021F8D8F; Tue, 12 Feb 2013 07:42:51 -0800 (PST) Received: from BLU002-W95 ([65.55.111.73]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Feb 2013 07:42:50 -0800 X-EIP: [Xcwnlm9VnR13DYEWFZJcfhmv8sH0RJQq] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c7c4316c-a584-48d0-b113-42dd47325c17_" From: Bernard Aboba To: Alan DeKok Date: Tue, 12 Feb 2013 07:42:50 -0800 Importance: Normal In-Reply-To: <511A5014.6050503@deployingradius.com> References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es>, <5117B84C.10405@deployingradius.com>, , <511A5014.6050503@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2013 15:42:50.0861 (UTC) FILETIME=[9D61D9D0:01CE0937] Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Why not a URL? 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, 12 Feb 2013 15:42:51 -0000 --_c7c4316c-a584-48d0-b113-42dd47325c17_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me ask a potentially stupid question: Why can't we send a URL pointing to the {SAML Assertion=2C Certificate} ins= tead of sending the data itself? This is what was done in IKE to avoid fragmentation.=20 > > my assumption is that if you were sending access-accept saml auth data > > you'd do it before you started EAP. >=20 > I'm wary of that approach. >=20 > Alan DeKok. = --_c7c4316c-a584-48d0-b113-42dd47325c17_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Let me ask a potentially stupid = question:

Why can't we send a URL pointing to the {SAML Assertion=2C= Certificate} instead of sending the data itself?

This is what was d= one in IKE to avoid fragmentation.

>=3B >=3B my assumption= is that if you were sending access-accept saml auth data
>=3B >=3B = you'd do it before you started EAP.
>=3B
>=3B I'm wary of that= approach.
>=3B
>=3B Alan DeKok.

= --_c7c4316c-a584-48d0-b113-42dd47325c17_-- From aland@deployingradius.com Tue Feb 12 07:59:30 2013 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 D169D21F8EE2; Tue, 12 Feb 2013 07:59:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCGTsy1frwwG; Tue, 12 Feb 2013 07:59:30 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBE21F8EE0; Tue, 12 Feb 2013 07:59:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EF0A32240C42; Tue, 12 Feb 2013 16:59:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKZBzUnWsXVC; Tue, 12 Feb 2013 16:59:28 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 2AD4E2240B5A; Tue, 12 Feb 2013 16:59:28 +0100 (CET) Message-ID: <511A66DF.9090807@deployingradius.com> Date: Tue, 12 Feb 2013 10:59:27 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es>, <5117B84C.10405@deployingradius.com>, , <511A5014.6050503@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Why not a URL? 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, 12 Feb 2013 15:59:30 -0000 Bernard Aboba wrote: > Why can't we send a URL pointing to the {SAML Assertion, Certificate} > instead of sending the data itself? Sure. That may work. Sometimes. The RADIUS system may not be publicly accessible. So any web server has to be located somewhere else. And the RADIUS server needs a way to talk to it. Or, the firewall rules need to be updated to allow non-RADIUS requests to make it to the RADIUS server. And this has to be bi-directional, as both ends of the RADIUS conversation want to send large amounts of data to each other. I think the simplest answer is that RADIUS systems use RADIUS to exchange RADIUS data. Doing anything else requires talking to non-RADIUS people, which is hard. The downside of this draft is that some RADIUS implementations need to change. But they'd have to change *anyways* to use any URL scheme. Another issue is proxies. Some proxies are required to mangle the data they pass, for inter-operability reasons. Using RADIUS lets them do this. Using URLs means thet they either have to ignore the URL, or re-host it themselves. Relying on non-RADIUS systems means added complexity, and dependence on external systems. The RADIUS process becomes more fragile. > This is what was done in IKE to avoid fragmentation. I think the IPSec boxes are already "public" on the net. Requiring them to be closely tied to a public web server may be a simple step. Alan DeKok. From cantor.2@osu.edu Tue Feb 12 08:07:10 2013 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 BB40B21F8F22; Tue, 12 Feb 2013 08:07:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3BSRbkHG0HT; Tue, 12 Feb 2013 08:07:09 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3EA21F8F1B; Tue, 12 Feb 2013 08:07:09 -0800 (PST) Received: from mail136-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Feb 2013 16:07:08 +0000 Received: from mail136-va3 (localhost [127.0.0.1]) by mail136-va3-R.bigfish.com (Postfix) with ESMTP id A7ECD4A02B6; Tue, 12 Feb 2013 16:07:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.208; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf01; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail136-va3: domain of osu.edu designates 164.107.81.208 as permitted sender) client-ip=164.107.81.208; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf01 ; cio-krc-pf01 ; Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3 (MessageSwitch) id 1360685227677550_2620; Tue, 12 Feb 2013 16:07:07 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.254]) by mail136-va3.bigfish.com (Postfix) with ESMTP id 94F6A3A0087; Tue, 12 Feb 2013 16:07:07 +0000 (UTC) Received: from cio-krc-pf01 (164.107.81.208) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Feb 2013 16:07:04 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) by cio-krc-pf01 (Postfix) with ESMTP id 4667AA0053; Tue, 12 Feb 2013 11:07:04 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0328.009; Tue, 12 Feb 2013 11:07:04 -0500 From: "Cantor, Scott" To: Bernard Aboba , Alan DeKok Thread-Topic: [abfab] [radext] Why not a URL? Thread-Index: AQHOCTej+Cvqzu4SCEmr/aH8rIRw75h2Y4oA Date: Tue, 12 Feb 2013 16:07:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.29.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Why not a URL? 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, 12 Feb 2013 16:07:11 -0000 On 2/12/13 10:42 AM, "Bernard Aboba" wrote: >Let me ask a potentially stupid question: > >Why can't we send a URL pointing to the {SAML Assertion, Certificate} >instead of sending the data itself? In addition to all of Alan's comments, there's the fact that you have to secure the exchange over the URL, or punt and rely on artifact-style short-lived references as a replacement for securing it. -- Scott From gabilm@um.es Tue Feb 12 08:19:43 2013 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 C560721F8F6E; Tue, 12 Feb 2013 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.791 X-Spam-Level: X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUYhJijQgtTE; Tue, 12 Feb 2013 08:19:39 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id D650321F8F6C; Tue, 12 Feb 2013 08:19:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 58C3B5D524; Tue, 12 Feb 2013 17:19: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 9eyolz91A5X4; Tue, 12 Feb 2013 17:19:36 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [5.34.132.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id C54B25D51C; Tue, 12 Feb 2013 17:19:32 +0100 (CET) Message-ID: <511A6B93.80702@um.es> Date: Tue, 12 Feb 2013 17:19:31 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Cantor, Scott" References: In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Bernard Aboba , "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Why not a URL? 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, 12 Feb 2013 16:19:43 -0000 El 12/02/13 17:07, Cantor, Scott escribió: > On 2/12/13 10:42 AM, "Bernard Aboba" wrote: > >> Let me ask a potentially stupid question: >> >> Why can't we send a URL pointing to the {SAML Assertion, Certificate} >> instead of sending the data itself? > In addition to all of Alan's comments, there's the fact that you have to > secure the exchange over the URL, or punt and rely on artifact-style > short-lived references as a replacement for securing it. And probably sometimes, URL making use of HTTP+TLS negotiation could require more roundtrips than fragmented attributes. > -- Scott > > > _______________________________________________ > 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 hartmans@painless-security.com Tue Feb 12 08:41:52 2013 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 84F5B21F8F09; Tue, 12 Feb 2013 08:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLf+epSKf68a; Tue, 12 Feb 2013 08:41:52 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5A81021F8F73; Tue, 12 Feb 2013 08:41:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 00E1C20115; Tue, 12 Feb 2013 11:37:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 233D243FD; Tue, 12 Feb 2013 11:41:36 -0500 (EST) From: Sam Hartman To: Bernard Aboba References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5117B84C.10405@deployingradius.com> <511A5014.6050503@deployingradius.com> Date: Tue, 12 Feb 2013 11:41:36 -0500 In-Reply-To: (Bernard Aboba's message of "Tue, 12 Feb 2013 07:42:50 -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: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Why not a URL? 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, 12 Feb 2013 16:41:52 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> Let me ask a potentially stupid question: Why can't we send Bernard> a URL pointing to the {SAML Assertion, Certificate} instead Bernard> of sending the data itself? Hi. First, I'm a little nervous about a SAML specific proposal. In Kerberos, we found that even with compact representations of authorization data, when people really start taking advantage of dynamic authorization, the authorization data can get large. Kerberos ended up choosing to use TCP to solve its fragmentation issues. I suspect that SAML is only the most discussed use case for a fragmentation solution. However, let's explore URIs for SAML. so, several of us do not want to assume a PKI shared between the NAS and the home AAA server. That is, we want to bootstrap our trust based on the AAA fabric. (Note that some subset of that us wants to do interesting things to bootstrap AAA trust, but that also fails to involve a PKI). SAML assertions are not always public. That is, we may be unwilling to disclose a SAML assertion without authorization. So, we need to accomplish the following: 1) Prove authorization to get the SAML assertion 2) Protect the integrity of the SAML assertion 3) Provide optional confidentiality for the SAML assertion. (several of us want to use SAML with RADSEC) In addition, in several of these cases, the SAML assertion is generated as a dynamic artifact of the authentication, so you have to introduce the complexity of storing the SAML assertion for a while. URLs aren't very good at providing confidentiality and integrity unless you happen to share a PKI in common with the authority referenced in the URI. It's possible to design a solution based on references that meets these constraints. I think we discussed that in ABFAB, and that's definitely not where we ended up. I think that if someone wants to pursue a URI-based approach it would be best to have a concrete proposal on the table. Possibly something that included a URI and a hash of the content. Except that alone is not good enough because if knowing the URI is the authorization to get the assertion, how do you provide authentication of the server prior to disclosing the URI without depending on a shared PKI? --Sam From jsalowey@cisco.com Wed Feb 13 15:22:01 2013 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 7EB5721E80A3 for ; Wed, 13 Feb 2013 15:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt53+EpNV-Lt for ; Wed, 13 Feb 2013 15:22:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 17ED121E80A1 for ; Wed, 13 Feb 2013 15:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=835; q=dns/txt; s=iport; t=1360797720; x=1362007320; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=KwVtzdAaXJJSl1VBLc1B2CXG8iTHRmj7lqRC1/TmjFY=; b=Wt1bWI+E2/RUAAwLx0dDtyanSGgDX6JWfrjAXTtQCoIOopWnpjn5Njrh 44fhHzM+R+vrBtLbHez+wUIyneGGFiVlp2sN2tB0unjmcBlhHqjVGf263 C8JQXfKS2cSDpzKZxkGnBq3bguEjA8kc6tKXtCPN8tunYrDTdcLydaK9s A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAC4fHFGtJV2Z/2dsb2JhbABFhgi6ZhZzgh8BAQEDAQEBATc0CwULAgEZAwECCxQQJwsUBwIIAgQOBQiIBAYMv2IEkSNhA6Z3gwaCJw X-IronPort-AV: E=Sophos;i="4.84,660,1355097600"; d="scan'208";a="176627988" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 13 Feb 2013 23:21:59 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1DNLx6s024683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 23:21:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 17:21:59 -0600 From: "Joseph Salowey (jsalowey)" To: "abfab@ietf.org" Thread-Topic: [Emu] Last call on draft-ietf-emu-eap-tunnel-method Thread-Index: AQHOCWMjaNlLFu8Ik02844sRUJP/nA== Date: Wed, 13 Feb 2013 23:21:59 +0000 Message-ID: References: <511AABCF.8020807@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] Fwd: [Emu] Last call on draft-ietf-emu-eap-tunnel-method 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, 13 Feb 2013 23:22:01 -0000 Please send any comments to the emu (emu@ietf.org) mailing list.=20 Thanks, Joe Begin forwarded message: > From: Alan DeKok > Subject: [Emu] Last call on draft-ietf-emu-eap-tunnel-method > Date: February 12, 2013 12:53:35 PM PST > To: "emu@ietf.org" >=20 > This is a WG last call on the draft-ietf-emu-eap-tunnel-method > document. Please post reviews, comments, feedback, etc. to this list. >=20 > The WG last call will last two weeks, until February 26. >=20 > If there have been no substantive comments or issues, we will take the > document to IETF last call. Minor editorial issues can be resolved then. >=20 > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From stephen.farrell@cs.tcd.ie Mon Feb 18 07:30:41 2013 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 A0DB621F8946 for ; Mon, 18 Feb 2013 07:30:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpFjnDIkFioc for ; Mon, 18 Feb 2013 07:30:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8B921F8A71 for ; Mon, 18 Feb 2013 07:30:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3E16BE2F for ; Mon, 18 Feb 2013 15:30:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JbaIuI20dwo for ; Mon, 18 Feb 2013 15:30:05 +0000 (GMT) Received: from [IPv6:2001:770:10:203:70b4:a884:3fa8:8567] (unknown [IPv6:2001:770:10:203:70b4:a884:3fa8:8567]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8264BE1E for ; Mon, 18 Feb 2013 15:30:05 +0000 (GMT) Message-ID: <512248FE.9050204@cs.tcd.ie> Date: Mon, 18 Feb 2013 15:30:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] radius extensions draft up for approval this week 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, 18 Feb 2013 15:30:41 -0000 Hiya, This [1] draft is on this week's IESG telechat. If there's anything in there that'd be a showstopper for abfab, I'd appreciate if you'd let me know before this Thursday. I'll take silence to mean that abfab are ok with it or don't care, since I assume you'd already have yelled if there were any known gotchas. (Note: I'm not implying there is anything wrong since I've not read the thing yet so I'll still be blissfully ignorant for a wee while yet;-) Ta, S. [1] https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ From hartmans@painless-security.com Mon Feb 18 07:55:28 2013 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 ADE6821F8BCF for ; Mon, 18 Feb 2013 07:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q95XLexNgORJ for ; Mon, 18 Feb 2013 07:55:28 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 087BC21F8A3E for ; Mon, 18 Feb 2013 07:55:22 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 931CF20183; Mon, 18 Feb 2013 10:50:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C43443FD; Mon, 18 Feb 2013 10:55:19 -0500 (EST) From: Sam Hartman To: Stephen Farrell References: <512248FE.9050204@cs.tcd.ie> Date: Mon, 18 Feb 2013 10:55:19 -0500 In-Reply-To: <512248FE.9050204@cs.tcd.ie> (Stephen Farrell's message of "Mon, 18 Feb 2013 15:30:06 +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: "" Subject: Re: [abfab] radius extensions draft up for approval this week 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, 18 Feb 2013 15:55:28 -0000 I've certainly read it and been tracking the radext side of things. I haven't seen anything go past radext that alarmed me since my last full read. From jsalowey@cisco.com Fri Feb 22 15:37:29 2013 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 437B821E808D for ; Fri, 22 Feb 2013 15:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfLxgUjI3twA for ; Fri, 22 Feb 2013 15:37:28 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7BADE21E8049 for ; Fri, 22 Feb 2013 15:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3742; q=dns/txt; s=iport; t=1361576248; x=1362785848; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=X6G1RieIEpLtqRisEWS6nq10joSqG5YYbeBkMvQbV44=; b=Rl/+f1jju/9IuUtlSV0NXWNqjbVlj4mW25y77wFn5q09kNs8IsTu9V9m SDCuHa+5H3VHXBlk3gVn0cW7dFvMV65/xwN3TUqNbglZVyrwbj6xoVxFr rzHNMiE8c1N54buqwTBkEoD+2ZbyF7CCadatKJGhNBC7MYdDnc6ct+TTi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK7/J1GtJV2Y/2dsb2JhbABEwT2BDBZzgiEBBDpRASoUQicEG4gKnjKgd41NgRCDF2EDkj+UXoMHgXI1 X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180256989" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 22 Feb 2013 23:37:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1MNbRaS024867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Feb 2013 23:37:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 17:37:27 -0600 From: "Joseph Salowey (jsalowey)" To: "abfab@ietf.org" Thread-Topic: Summary of proposed changes to eat applicability document Thread-Index: AQHOEVWS0ENYfV/BxkyUaPaVivtBKQ== Date: Fri, 22 Feb 2013 23:37:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C9C632103D78D4B9DE4A51AE9DE9788@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] Summary of proposed changes to eat applicability document 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, 22 Feb 2013 23:37:29 -0000 After going through the comments on the list here is where I think we are w= ith changes to the document: 1) Section 3=20 OLD It is important for the protocol carrying EAP to prove possession of the EAP MSK between the EAP Peer and EAP Authenticator. NEW The protocol carrying EAP MUST prove possession of the EAP MSK between the EAP Peer and EAP Authenticator. ADD In the context of EAP for Application-Layer Access the application is provi= ding the EAP Lower Layer. Applications protocols vary so their specific b= ehavior and transport characteristics needs to be considered when determini= ng their retransmission and re-authentication behavior as discussed in sect= ion 3. =20 3) Retransmissions ADD=20 2.1 Retransmission In EAP, the authenticator is responsible for retransmission. By default EAP assumes that the lower layer (the application in this context) is unreliable. The authenticator can send a packet whenever its retransmission timer triggers. In this mode, applications need to be able t= o receive and process=20 EAP messages at any time during the authentication conversation. Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. When this happens, the lower layer becomes responsible for reliable delivery of EAP messages. Applications that use a lock-step or client-driven authentication protocol might benefit from this approach. In addition to retransmission behavior applications need to deal with discarded EAP messages. For example, whenever some EAP methods receive err= oneous input, these methods discard the input rather than generating an error response. If the erroneous input was generated by an attacker, legitimate input can sometimes be received after the erroneous input. Applications MUST handle discarded EAP messages, although the specific way in which discarded messages will be handled depend on the characteristics of the application. Options include failing the authentication at the application level, requesting an EAP=20 retransmit and waiting for additional EAP input. =20 Specifications of how EAP is used for application authentication SHOULD document how retransmission and message discards are handled. 4) Re-Authentication ADD 2.2 Re-Authentication EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session [RFC 3748]. Diameter standardizes a mechanism for a AAA server to request re-authentication [RFC 4005]. Re-authentication permits security associations to be updated without establishing a new session. For network access, this can be important because interrupting network access can disrupt connections and media. Some applications might not need re-authentication support. For example if sessions are relatively short-lived or if sessions can be replaced without significant disruption, re-authentication might not provide value. Protocols like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol (SMTP) are examples of protocols where establishing a new connection to update security associations is likely to be sufficient. Re-authentication is likely to be valuable if sessions or connections are long-lived or if there is a significant cost to disrupting them. Another factor may make re-authentication important. Some protocols only permit one part in a protocol (for example the client) to establish a new connection. If another party in the protocol needs the security association refreshed then re-authentication can provide a mechanism to do so. Lower layers SHOULD describe whether re-authentication is provided and which parties can initiate it.= From hartmans@painless-security.com Fri Feb 22 15:53:51 2013 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 C3D6921E804D for ; Fri, 22 Feb 2013 15:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+yipnwt7Q7n for ; Fri, 22 Feb 2013 15:53:51 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23821E8048 for ; Fri, 22 Feb 2013 15:53:48 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id ECD9D20161; Fri, 22 Feb 2013 18:49:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B74F7447B; Fri, 22 Feb 2013 18:53:44 -0500 (EST) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: Date: Fri, 22 Feb 2013 18:53:44 -0500 In-Reply-To: (Joseph Salowey's message of "Fri, 22 Feb 2013 23:37:27 +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] Summary of proposed changes to eat applicability document 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, 22 Feb 2013 23:53:51 -0000 Looks good to me. From ietf@augustcellars.com Fri Feb 22 17:47:16 2013 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 196F321E808D for ; Fri, 22 Feb 2013 17:47:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3VIfoOmFzMU for ; Fri, 22 Feb 2013 17:47:15 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7501F21E8045 for ; Fri, 22 Feb 2013 17:47:14 -0800 (PST) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6D3C538EA7; Fri, 22 Feb 2013 17:47:14 -0800 (PST) From: "Jim Schaad" To: "'Joseph Salowey \(jsalowey\)'" , References: In-Reply-To: Date: Fri, 22 Feb 2013 17:46:44 -0800 Message-ID: <007001ce1167$a2ffcd60$e8ff6820$@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: AQKq5TlprINP5ZHSpA56ognqOLVJcJbNBMCQ Content-Language: en-us Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 23 Feb 2013 01:47:16 -0000 I have no immediate qualms about this text. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Joseph Salowey (jsalowey) > Sent: Friday, February 22, 2013 3:37 PM > To: abfab@ietf.org > Subject: [abfab] Summary of proposed changes to eat applicability document > > After going through the comments on the list here is where I think we are > with changes to the document: > > 1) Section 3 > > OLD > It is important > for the protocol carrying EAP to prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. > > NEW > The protocol carrying EAP MUST prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. > > ADD > > In the context of EAP for Application-Layer Access the application is providing > the EAP Lower Layer. Applications protocols vary so their specific behavior > and transport characteristics needs to be considered when determining their > retransmission and re-authentication behavior as discussed in section 3. > > > 3) Retransmissions > > ADD > > 2.1 Retransmission > > In EAP, the authenticator is responsible for retransmission. By default EAP > assumes that the lower layer (the application in this context) is unreliable. > The authenticator can send a packet whenever its retransmission timer > triggers. In this mode, applications need to be able to receive and process > EAP messages at any time during the authentication conversation. > > Alternatively, EAP permits a lower layer to set the retransmission timer to > infinite. When this happens, the lower layer becomes responsible for reliable > delivery of EAP messages. Applications that use a lock-step or client-driven > authentication protocol might benefit from this approach. > > In addition to retransmission behavior applications need to deal with > discarded EAP messages. For example, whenever some EAP methods > receive erroneous input, these methods discard the input rather than > generating an error response. If the erroneous input was generated by an > attacker, legitimate input can sometimes be received after the erroneous > input. Applications MUST handle discarded EAP messages, although the > specific way in which discarded messages will be handled depend on the > characteristics of the application. Options include failing the authentication at > the application level, requesting an EAP > retransmit and waiting for additional EAP input. > > Specifications of how EAP is used for application authentication SHOULD > document how retransmission and message discards are handled. > > 4) Re-Authentication > > ADD > > 2.2 Re-Authentication > > EAP lower layers MAY provide a mechanism for re-authentication to happen > within an existing session [RFC 3748]. Diameter standardizes a mechanism for > a AAA server to request re-authentication [RFC 4005]. Re-authentication > permits security associations to be updated without establishing a new > session. For network access, this can be important because interrupting > network access can disrupt connections and media. > > Some applications might not need re-authentication support. For example if > sessions are relatively short-lived or if sessions can be replaced without > significant disruption, re-authentication might not provide value. Protocols > like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol > (SMTP) are examples of protocols where establishing a new connection to > update security associations is likely to be sufficient. > > Re-authentication is likely to be valuable if sessions or connections are long- > lived or if there is a significant cost to disrupting them. > > Another factor may make re-authentication important. Some protocols only > permit one part in a protocol (for example the client) to establish a new > connection. If another party in the protocol needs the security association > refreshed then re-authentication can provide a mechanism to do so. > > Lower layers SHOULD describe whether re-authentication is provided and > which parties can initiate it. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@mnt.se Sat Feb 23 01:34:58 2013 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 D126321F8F4C for ; Sat, 23 Feb 2013 01:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y24Fhup6oAJC for ; Sat, 23 Feb 2013 01:34:55 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF2821F8F25 for ; Sat, 23 Feb 2013 01:34:55 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gg13so1142245lbb.30 for ; Sat, 23 Feb 2013 01:34:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=A7V/poduh7fhGx0m4zcqXHLe4ZJ49Jgs2WODzK9xWDA=; b=MJxBH44o5oFIadzfpmBOsSt9zsq5EexZD5XKNT6XaC/vvBfCeVOljNnltgXaY06aqa jQ2DywbGkKU9atklQRCWfJf8qiIo36a77UxJH+yns0Mfl2qCBwcwxI+OcuNxe7i0yC9R FGzxPqFfJ7VAFzauOpQQuQn6mOi/5Ws9a1uQxuaTKVNE3ZLxTo7uHeOf18UPSCuxORGS sePplINi3/YmsDgh+BkhOayCFXNd301fgcJjyQ/FvvNrqPWMDiPNNlFN2y16O0A+MkKN 8nsum44AeWB3GB5jEiUryUVqKtjADLmpxnYJovZFjYRlDHohtdHuxudjB6JYzA1HySAz 0uaQ== X-Received: by 10.112.88.9 with SMTP id bc9mr2090348lbb.22.1361612094311; Sat, 23 Feb 2013 01:34:54 -0800 (PST) Received: from [130.237.241.176] (eduroam-241-176.public.su.se. [130.237.241.176]) by mx.google.com with ESMTPS id mq7sm2771509lab.1.2013.02.23.01.34.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 01:34:53 -0800 (PST) Message-ID: <51288D3C.4080105@mnt.se> Date: Sat, 23 Feb 2013 10:34:52 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnz5djAKMxZw35cJ7oQrocba6gMZxQwUrwu84CF3YEw/KPiYuZC3kOS9cb9zTessPhYRmKg Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 23 Feb 2013 09:34:58 -0000 On 02/23/2013 12:37 AM, Joseph Salowey (jsalowey) wrote: > After going through the comments on the list here is where I think we are with changes to the document: Just to be clear - the chairs consider this a consensus call for (hopefully final) changes to the eap applicability statement. We hope and expect to be able to WGLC the resulting version of the document. Cheers Leif From yoshihiro.ohba@toshiba.co.jp Sat Feb 23 08:01:35 2013 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 E2B4C21F8FD0 for ; Sat, 23 Feb 2013 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.309 X-Spam-Level: X-Spam-Status: No, score=-7.309 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUAJAUtBJRsC for ; Sat, 23 Feb 2013 08:01:34 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id C59E921F8FC5 for ; Sat, 23 Feb 2013 08:01:33 -0800 (PST) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r1NG1U0u003657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2013 01:01:30 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r1NG1TLW028773; Sun, 24 Feb 2013 01:01:29 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 431; Sun, 24 Feb 2013 01:01:29 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r1NG1TiV028770; Sun, 24 Feb 2013 01:01:29 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r1NG1TBN007172; Sun, 24 Feb 2013 01:01:29 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA07171; Sun, 24 Feb 2013 01:01:29 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r1NG1TFL008754; Sun, 24 Feb 2013 01:01:29 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r1NG1Tko021857; Sun, 24 Feb 2013 01:01:29 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.35]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.02.0328.009; Sun, 24 Feb 2013 01:01:28 +0900 From: To: , Thread-Topic: Summary of proposed changes to eat applicability document Thread-Index: AQHOEVWS0ENYfV/BxkyUaPaVivtBKZiHij3A Date: Sat, 23 Feb 2013 16:01:27 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.20] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 23 Feb 2013 16:01:35 -0000 Hi Joe, The proposed new Sections "2.1 Retransmission" and "2.2 Re-Authentication" = are intended to be added to draft-ietf-abfab-eapapplicability (and not inte= nded be added to RFC 3748), right? If so, then the following sentence in Section 2.2 should be written from ap= plication perspective in the same way as Section 2.1 for consistency: "Lower layers SHOULD describe whether re-authentication is provided and whi= ch parties can initiate it." Applications SHOULD describe whether re-authentication is provided and whic= h parties can initiate it. Regards, Yoshihiro Ohba -----Original Message----- From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of J= oseph Salowey (jsalowey) Sent: Saturday, February 23, 2013 8:37 AM To: abfab@ietf.org Subject: [abfab] Summary of proposed changes to eat applicability document After going through the comments on the list here is where I think we are w= ith changes to the document: 1) Section 3=20 OLD It is important for the protocol carrying EAP to prove possession of the EAP MSK between the EAP Peer and EAP Authenticator. NEW The protocol carrying EAP MUST prove possession of the EAP MSK between the EAP Peer and EAP Authenticator. ADD In the context of EAP for Application-Layer Access the application is provi= ding the EAP Lower Layer. Applications protocols vary so their specific b= ehavior and transport characteristics needs to be considered when determini= ng their retransmission and re-authentication behavior as discussed in sect= ion 3. =20 3) Retransmissions ADD=20 2.1 Retransmission In EAP, the authenticator is responsible for retransmission. By default EAP= assumes that the lower layer (the application in this context) is unreliab= le. The authenticator can send a packet whenever its retransmission timer t= riggers. In this mode, applications need to be able to receive and process = EAP messages at any time during the authentication conversation. Alternatively, EAP permits a lower layer to set the retransmission timer to= infinite. When this happens, the lower layer becomes responsible for relia= ble delivery of EAP messages. Applications that use a lock-step or client-d= riven authentication protocol might benefit from this approach. In addition to retransmission behavior applications need to deal with disca= rded EAP messages. For example, whenever some EAP methods receive erroneou= s input, these methods discard the input rather than generating an error re= sponse. If the erroneous input was generated by an attacker, legitimate inp= ut can sometimes be received after the erroneous input. Applications MUST h= andle discarded EAP messages, although the specific way in which discarded = messages will be handled depend on the characteristics of the application. = Options include failing the authentication at the application level, reques= ting an EAP retransmit and waiting for additional EAP input. =20 Specifications of how EAP is used for application authentication SHOULD doc= ument how retransmission and message discards are handled. 4) Re-Authentication ADD 2.2 Re-Authentication EAP lower layers MAY provide a mechanism for re-authentication to happen wi= thin an existing session [RFC 3748]. Diameter standardizes a mechanism for = a AAA server to request re-authentication [RFC 4005]. Re-authentication per= mits security associations to be updated without establishing a new session= . For network access, this can be important because interrupting network ac= cess can disrupt connections and media. Some applications might not need re-authentication support. For example if = sessions are relatively short-lived or if sessions can be replaced without = significant disruption, re-authentication might not provide value. Protocol= s like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protoco= l (SMTP) are examples of protocols where establishing a new connection to u= pdate security associations is likely to be sufficient. Re-authentication is likely to be valuable if sessions or connections are l= ong-lived or if there is a significant cost to disrupting them. Another factor may make re-authentication important. Some protocols only pe= rmit one part in a protocol (for example the client) to establish a new con= nection. If another party in the protocol needs the security association re= freshed then re-authentication can provide a mechanism to do so. Lower layers SHOULD describe whether re-authentication is provided and whic= h parties can initiate it. _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Sat Feb 23 08:16:50 2013 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 9C64521F8FD7 for ; Sat, 23 Feb 2013 08:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXfo5MkvO6HY for ; Sat, 23 Feb 2013 08:16:49 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BFC5221F8FD5 for ; Sat, 23 Feb 2013 08:16:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A22B120180; Sat, 23 Feb 2013 11:12:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7913D447B; Sat, 23 Feb 2013 11:16:44 -0500 (EST) From: Sam Hartman To: References: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> Date: Sat, 23 Feb 2013 11:16:44 -0500 In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> (yoshihiro ohba's message of "Sat, 23 Feb 2013 16:01:27 +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] Summary of proposed changes to eat applicability document 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, 23 Feb 2013 16:16:51 -0000 >>>>> writes: I'm fine with this change. From leifj@sunet.se Sun Feb 24 04:47:04 2013 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 3389721F8FE2 for ; Sun, 24 Feb 2013 04:47:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYiuNtLBA9cL for ; Sun, 24 Feb 2013 04:47:03 -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 1E2D721F8FC9 for ; Sun, 24 Feb 2013 04:47:02 -0800 (PST) Received: from [172.20.10.6] (2.70.66.127.mobile.tre.se [2.70.66.127]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id r1OCkvsW015523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 24 Feb 2013 13:47:01 +0100 (CET) Message-ID: <512A0BBF.5010006@sunet.se> Date: Sun, 24 Feb 2013 13:46:55 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 24 Feb 2013 12:47:04 -0000 On 02/23/2013 05:16 PM, Sam Hartman wrote: >>>>>> writes: > > I'm fine with this change. > _______________________________________________ > I *strongly* urge others on the list to chime in with their +1 or detailed descent at this point. Cheers Leif From jsalowey@cisco.com Mon Feb 25 08:38:13 2013 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 A736D21F950A for ; Mon, 25 Feb 2013 08:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59v+wQwJDfeS for ; Mon, 25 Feb 2013 08:38:13 -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 B01A021F9501 for ; Mon, 25 Feb 2013 08:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5128; q=dns/txt; s=iport; t=1361810292; x=1363019892; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yPoH6JcgX5it0eGPkOwlcdWGJfDFvL54GQOoTh85Vuo=; b=IwyzqNheMySlspjJ7IkmRziG2oV34jVdZge88PuXQQBNgKTL9rvV7OGi VePZSesSPlSdeu70CYh/lbSp9A2yfHTG+W0O30p/ui3heeVMiX/uFFMe+ mD3Ba36k12E8uKKIcb0ojGhd+cqdJ5/OHNd+QpCXtsrJSREhtZHdFqztP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPuSK1GtJXG9/2dsb2JhbABFhk+7BoEFFnOCHwEBAQMBAQEBHgFMCwUHBAIBCBEEAQECAwYdAgMCJwsUCQgCBA4FCIgFBgySTpp+AZFPBIEgjC2BDgImCwcGgiQ1YQOSQpRggweBcjU X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="180886145" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 25 Feb 2013 16:38:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGcC7U016373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:38:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:38:11 -0600 From: "Joseph Salowey (jsalowey)" To: " " Thread-Topic: Summary of proposed changes to eat applicability document Thread-Index: AQHOEVWS0ENYfV/BxkyUaPaVivtBKZiHij3AgAOkqoA= Date: Mon, 25 Feb 2013 16:38:10 +0000 Message-ID: References: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <5F21AAAD9165874895E849BBDCC4CECA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 25 Feb 2013 16:38:13 -0000 Good catch Yoshi, I will make this change. Thanks, Joe On Feb 23, 2013, at 8:01 AM, wrote: > Hi Joe, >=20 > The proposed new Sections "2.1 Retransmission" and "2.2 Re-Authentication= " are intended to be added to draft-ietf-abfab-eapapplicability (and not in= tended be added to RFC 3748), right? >=20 > If so, then the following sentence in Section 2.2 should be written from = application perspective in the same way as Section 2.1 for consistency: >=20 > "Lower layers SHOULD describe whether re-authentication is provided and w= hich parties can initiate it." >=20 > Applications SHOULD describe whether re-authentication is provided and wh= ich parties can initiate it. >=20 > Regards, > Yoshihiro Ohba >=20 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of= Joseph Salowey (jsalowey) > Sent: Saturday, February 23, 2013 8:37 AM > To: abfab@ietf.org > Subject: [abfab] Summary of proposed changes to eat applicability documen= t >=20 > After going through the comments on the list here is where I think we are= with changes to the document: >=20 > 1) Section 3=20 >=20 > OLD > It is important > for the protocol carrying EAP to prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. >=20 > NEW > The protocol carrying EAP MUST prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. >=20 > ADD >=20 > In the context of EAP for Application-Layer Access the application is pro= viding the EAP Lower Layer. Applications protocols vary so their specific= behavior and transport characteristics needs to be considered when determi= ning their retransmission and re-authentication behavior as discussed in se= ction 3. =20 >=20 >=20 > 3) Retransmissions >=20 > ADD=20 >=20 > 2.1 Retransmission >=20 > In EAP, the authenticator is responsible for retransmission. By default E= AP assumes that the lower layer (the application in this context) is unreli= able. The authenticator can send a packet whenever its retransmission timer= triggers. In this mode, applications need to be able to receive and proces= s EAP messages at any time during the authentication conversation. >=20 > Alternatively, EAP permits a lower layer to set the retransmission timer = to infinite. When this happens, the lower layer becomes responsible for rel= iable delivery of EAP messages. Applications that use a lock-step or client= -driven authentication protocol might benefit from this approach. >=20 > In addition to retransmission behavior applications need to deal with dis= carded EAP messages. For example, whenever some EAP methods receive errone= ous input, these methods discard the input rather than generating an error = response. If the erroneous input was generated by an attacker, legitimate i= nput can sometimes be received after the erroneous input. Applications MUST= handle discarded EAP messages, although the specific way in which discarde= d messages will be handled depend on the characteristics of the application= . Options include failing the authentication at the application level, requ= esting an EAP retransmit and waiting for additional EAP input. =20 >=20 > Specifications of how EAP is used for application authentication SHOULD d= ocument how retransmission and message discards are handled. >=20 > 4) Re-Authentication >=20 > ADD >=20 > 2.2 Re-Authentication >=20 > EAP lower layers MAY provide a mechanism for re-authentication to happen = within an existing session [RFC 3748]. Diameter standardizes a mechanism fo= r a AAA server to request re-authentication [RFC 4005]. Re-authentication p= ermits security associations to be updated without establishing a new sessi= on. For network access, this can be important because interrupting network = access can disrupt connections and media. >=20 > Some applications might not need re-authentication support. For example i= f sessions are relatively short-lived or if sessions can be replaced withou= t significant disruption, re-authentication might not provide value. Protoc= ols like HypertextTransport Protocol (HTTP) and Simple Mail Transport Proto= col (SMTP) are examples of protocols where establishing a new connection to= update security associations is likely to be sufficient. >=20 > Re-authentication is likely to be valuable if sessions or connections are= long-lived or if there is a significant cost to disrupting them. >=20 > Another factor may make re-authentication important. Some protocols only = permit one part in a protocol (for example the client) to establish a new c= onnection. If another party in the protocol needs the security association = refreshed then re-authentication can provide a mechanism to do so. >=20 > Lower layers SHOULD describe whether re-authentication is provided and wh= ich parties can initiate it. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab >=20 From hartmans@painless-security.com Mon Feb 25 13:11:34 2013 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 424A621E80D8 for ; Mon, 25 Feb 2013 13:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUaXb72lbgUt for ; Mon, 25 Feb 2013 13:11:33 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6447521E809F for ; Mon, 25 Feb 2013 13:11:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 25E0E20118; Mon, 25 Feb 2013 16:06:42 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8D986447B; Mon, 25 Feb 2013 16:11:32 -0500 (EST) From: Sam Hartman To: moonshot-community@jiscmail.ac.uk,abfab@ietf.org Date: Mon, 25 Feb 2013 16:11:32 -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] Timing on a trust router BAR BOF 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, 25 Feb 2013 21:11:34 -0000 Hi folks. We're hoping to get together a side meeting at IETF 86 to discuss the trust router proposal and start the process of preparing for a BOF this summer. we'll send out an invitation once we get a room and time. This message is calling for constraints on timing. If you have been heavily involved in the trust router work and would like to be there, let us know any times for a side meeting (typically evenings/outside session times) when you will be unavailable. We'd like to collect this information by tomorrow afternoon. From internet-drafts@ietf.org Mon Feb 25 14:03:57 2013 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 D910421E80EE; Mon, 25 Feb 2013 14:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEF2RYtox6xO; Mon, 25 Feb 2013 14:03:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2639F1F0D0A; Mon, 25 Feb 2013 14:03:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225220357.30239.95879.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:03:57 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-05.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, 25 Feb 2013 22:03:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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, Profiles, Name Identifier F= ormat, and Confirmation Methods for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-05.txt Pages : 21 Date : 2013-02-25 Abstract: This document specifies a RADIUS attribute, a binding, a name identifier format, two profiles, and two confirmation methods for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, and the binding describes the use of this attribute, and the SAML protocol messages within, with RADIUS transport. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request respectively. The name identifier format allows a subject to be named using an NAI, and the subject confirmation methods allow queries to be issued for a principal without needing to explicitly name the intended subject within the request. These artefacts have been defined to permit application in scenarios other than ABFAB, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-aaa-saml-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 14:12:36 2013 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 D7C3021E810C; Mon, 25 Feb 2013 14:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt4YtX+BStEg; Mon, 25 Feb 2013 14:12:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619CE21E80FC; Mon, 25 Feb 2013 14:12:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225221235.17662.55089.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:12:35 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-05.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, 25 Feb 2013 22:12:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond Web (AB= FAB) Architecture Author(s) : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-05.txt Pages : 49 Date : 2013-02-25 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use-cases: network access and web-based access. However, the solutions to these use-cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the GS2 family, the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-arch-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jimsch@augustcellars.com Tue Feb 26 11:26:49 2013 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 623EC21F8869 for ; Tue, 26 Feb 2013 11:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=2.317, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ9hTd24bD9a for ; Tue, 26 Feb 2013 11:26:48 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95A21F8825 for ; Tue, 26 Feb 2013 11:26:48 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A3F6B38F18; Tue, 26 Feb 2013 11:26:47 -0800 (PST) From: "Jim Schaad" To: Date: Tue, 26 Feb 2013 11:26:15 -0800 Message-ID: <018001ce1457$252783e0$6f768ba0$@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: Ac4TyEadmLXoDEkVS0CNvOS1EndVaQ== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 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, 26 Feb 2013 19:26:49 -0000 Josh and Sam, This looks much more like the discussion that we had after the last IETF meeting so I am generally happy. 1. I think inserting a paragraph start at "The name identifier..." will make it clearer which artifacts are designed to be used in ABFAB scenarios and which are designed for more universal usage. 2. In section 2 for the last bullet point in the first list - should this be the subject of an assertion or the subject of a protocol message? I am always very unclear about SAML naming of items. However this confirmation method can be in both a SAML assertion and in a query (i.e. AttributeQuery). 3. In section 5.2 - I am not happy with the single reference to RADSEC as being the required. I would be more happy if the profile required either TLS/UDP or TLS/TCP as required. Either that or TLS/TCP should be recommended. I am worried that without this there might be an issue with people thinking it is restricted to UDP. Note that for longer messages you probably really want to require the TLS/TCP version not the DTLS/UDP version. 4. In section 5.2 - I have probably said this before, I am not really a big fan of the use of language such as "MAY transmit a SAML request". If you don't do the request how can one say that you are acting as a SAML requester. A similar statement is also made for the second item. Just say "returns a SAML protocol message" and then talk about reasons that you might not wish to do so. 5. In section 5.2 - s/responder MAY also return/responder MAY return/ - it might be read as saying you could return two even though that is explicitly forbidden. 6. In section 5.2 - I think we should probably add the following paragraph: SAML responders SHOULD return a RADIUS state attribute as part of the Access-Accept message so that future SAML queries can be run against the same context of an authentication exchange. 7. In section 6 - update the reference for NAI to draft-ietf-radext-nai 8. In section 7.3.3 - I am not sure that the dependence on the abfab document at the end of the section makes sense. For example, why should the EAP method support channel binding in order to return a SAML response? I think that one can restrict the requirements to those in the AuthnRequest and those necessitated by the application (whatever the application). You probably just missed this in the general ABFAB removal. 9. In section 7.4.1 - I think the second paragraph can be removed and placed in section 7.4.2. It is not related to the AuthnRequest but to the Response. 10. In section 7.4.2 - I think we might need to make a statement about returning no subject identifier and the correct interaction with the AllowCreate attribute. If the IdP is not going to return a name, but is just returning a subject conformation that says - the user associated with this conversation - is this to be considered a "new identity" for the user? 11. In section 7.4.2 - I have a problem with the last bullet point. I would be happier if the text looked more like: Other conditions MAY be included as requested by the Relying Party or at the discretion of the Identity Provider. The Identity Provider is not obligated to honor the requested set of conditions in the , if any. If the Identity Provider does not honor the requested set of conditions is MUST either not return a message or return a message with an error. 12. In section 9. I think in this case it would be useful to have an informational reference to TEAP about mapping these from an EAP method to the URIs specified. s/artefacts/artifacts/ From klaas@cisco.com Wed Feb 27 02:47:54 2013 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 9856421F852C for ; Wed, 27 Feb 2013 02:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 316KRuMzUmKh for ; Wed, 27 Feb 2013 02:47:54 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1708221F8436 for ; Wed, 27 Feb 2013 02:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=904; q=dns/txt; s=iport; t=1361962070; x=1363171670; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=wKjL1qSIlp6j925Vfyc126arkHCijCe1FNanoV7FDJk=; b=GicwwQITQFC303GV9lAwaGcbM7svwcSJR1MfLIY/G6CiCVBnZZuDz6f0 dHou8g/D/4f0pjcM7BbQIdoQpHwPPZ7Fv6NQ1sHndW8nr8PofP1PIiS7I AmSvQAXkJArCvTzulvWR7/p6icgzzktNSlzXLo8u86fG0zujNAJ91CUzE g=; X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; d="scan'208";a="12101215" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 27 Feb 2013 10:47:48 +0000 Received: from dhcp-10-61-101-248.cisco.com (dhcp-10-61-101-248.cisco.com [10.61.101.248]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1RAlmL7024146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 10:47:48 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Feb 2013 11:47:48 +0100 Message-Id: <28808A2A-9D8F-469E-8436-F4723FB3287D@cisco.com> To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Margaret Wasserman , Jim Schaad Subject: [abfab] preliminary agenda abfab@IETF86 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, 27 Feb 2013 10:47:54 -0000 Hi, I have just posted the preliminary agenda for the abfab meeting: ==== Abfab Wednesday, March 13, 2013 1300-1500 Caribbean 6 ----------------------------------------------------------- - Agenda Bashing and Note Well (5 min, Chairs) - Document status * draft-ietf-abfab-aaa-saml (10 min, Rhys Smith) * draft-ietf-abfab-arch (20 min, Jim Schaad) * draft-ietf-abfab-eapapplicability (10 min, Joe Salowey) - Milestones and remaining document status (10 min, Chairs) * draft-ietf-abfab-gss-eap-09 * draft-ietf-abfab-gss-eap-naming-07 * draft-ietf-abfab-usecases-05 * draft-smith-abfab-usability-ui-considerations-03 - Trust Router (20 min, Sam Hartman/Margaret Wasserman/Rhys Smith) - Open Mic (45 min, All) ==== to be found at: http://www.ietf.org/proceedings/86/agenda/agenda-86-abfab Please let Leif or me know if you have any requests/comments! Klaas From alper.yegin@yegin.org Wed Feb 27 13:36:28 2013 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 AE15121F8883 for ; Wed, 27 Feb 2013 13:36:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1uJLt-69QvB for ; Wed, 27 Feb 2013 13:36:28 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id F014421F8870 for ; Wed, 27 Feb 2013 13:36:27 -0800 (PST) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MLNZC-1UAGhz3Z6Q-000ynX; Wed, 27 Feb 2013 16:36:25 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Wed, 27 Feb 2013 23:36:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BEF4D48-9904-4B8A-8555-A3827EC07B3E@yegin.org> References: To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:dXlEYupNZVlB4efODNr2SzjoM2xGz18g717lofN6rNA ASqG+1RfxojWD/JfxvdYZYeAgkYPMu5aAQ1ywPqlUXqFbWZjgN YHCQozdDBcpGLurZV8TfEy8A6Cyxi8SxlZnDO1l3WMijNAIXXw nuiU1XGQN3xm7fSXAX8AKzgfbWLpiNttzt4MfdK3br9vy0vxFh fGV8WPjWCQFrWwWJFupTWbLdlpyTzgJBLZXQGrO8VF5xu5NHeb RtRU1ndl8z0P0ZibhAiaQPaB7J0Rvpvx2tTt01JhY4eo2Bbdl4 FyGi9jVF37Aido1KoihDua3MMWMjSWOQRNGS66aY0ccOQzyPTC AksDIaQj7DqAxdappVFWatpV/mYM520ryiSRXDcpWxS5tyfADX rqRBU6H3D5XHQ== Cc: "abfab@ietf.org" Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 27 Feb 2013 21:36:28 -0000 >=20 > 2.1 Retransmission >=20 > In EAP, the authenticator is responsible for retransmission. By = default > EAP assumes that the lower layer (the application in this context) is > unreliable. The authenticator can send a packet whenever its > retransmission timer triggers. In this mode, applications need to be = able to receive and process=20 > EAP messages at any time during the authentication conversation. >=20 > Alternatively, EAP permits a lower layer to set the retransmission = timer > to infinite. When this happens, the lower layer becomes responsible = for > reliable delivery of EAP messages. Applications that use a lock-step = or > client-driven authentication protocol might benefit from this = approach. >=20 It'd be useful to explain why so, even briefly.=20 > In addition to retransmission behavior applications need to deal with > discarded EAP messages. For example, whenever some EAP methods receive = erroneous > input, these methods discard the input rather than generating an error > response. If the erroneous input was generated by an attacker, > legitimate input can sometimes be received after the erroneous > input. Applications MUST handle discarded EAP messages, > although the specific way in which discarded messages will be handled > depend on the characteristics of the application. Options include > failing the authentication at the application level, requesting an EAP=20= > retransmit and waiting for additional EAP input. =20 >=20 Are these the only three options for how apps must handle discarded EAP = messages? If so, we should state that clearly. If not, then the "MUST = handle" statement is not meaningful at all. Unless we state specific way = of handling, or provide some general guidelines (e.g., characteristics = of handling), "MUST handle" does not mean anything to implementors. Also, as I had stated earlier, this requirement implies an interface = between the EAP method layer and the EAP lower-layer. Such an interface = does not exist, there is EAP in between.=20 This requirement has additional implications on EAP methods too. = Existing EAP methods need to be modified?? > Specifications of how EAP is used for application authentication = SHOULD > document how retransmission and message discards are handled. >=20 Why not MUST?=20 > 4) Re-Authentication >=20 > ADD >=20 > 2.2 Re-Authentication >=20 > EAP lower layers MAY provide a mechanism for re-authentication to = happen > within an existing session [RFC 3748]. Diameter standardizes a = mechanism > for a AAA server to request re-authentication [RFC > 4005]. Re-authentication permits security associations to be updated > without establishing a new session. For network access, this can be > important because interrupting network access can disrupt connections > and media. >=20 > Some applications might not need re-authentication support. For = example > if sessions are relatively short-lived or if sessions can be replaced > without significant disruption, re-authentication might not provide > value. Protocols like HypertextTransport Protocol (HTTP) and Simple > Mail Transport Protocol (SMTP) are examples of protocols where > establishing a new connection to update security associations is = likely > to be sufficient. >=20 > Re-authentication is likely to be valuable if sessions or connections > are long-lived or if there is a significant cost to disrupting them. >=20 There's a bit of a terminology confusion here, I believe. I think the intention is to state that we don't need to run EAP again = and again in order to maintain an always-on security association. It is = OK to let EAP sessions expire. We can run EAP again if and when we need = a security association again. One could call this "re-authenticaiton". On the other hand, letting the security association expire and having to = run EAP again on-demand can also be called "re-authentication". > Another factor may make re-authentication important. Some protocols = only > permit one part in a protocol (for example the client) to establish a > new connection. If another party in the protocol needs the security > association refreshed then re-authentication can provide a mechanism = to > do so. >=20 > Lower layers SHOULD describe whether re-authentication is provided and > which parties can initiate it. I'd say "MUST" here too. Alper > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Feb 27 14:08:09 2013 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 46F4A21F8884 for ; Wed, 27 Feb 2013 14:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNb+h-+xjcZg for ; Wed, 27 Feb 2013 14:08:08 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C652A21F8883 for ; Wed, 27 Feb 2013 14:08:08 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0533120118; Wed, 27 Feb 2013 17:03:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC506447B; Wed, 27 Feb 2013 17:08:07 -0500 (EST) From: Sam Hartman To: abfab@ietf.org References: <8BEF4D48-9904-4B8A-8555-A3827EC07B3E@yegin.org> Date: Wed, 27 Feb 2013 17:08:07 -0500 In-Reply-To: <8BEF4D48-9904-4B8A-8555-A3827EC07B3E@yegin.org> (Alper Yegin's message of "Wed, 27 Feb 2013 23:36:20 +0200") 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] Summary of proposed changes to eat applicability document 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, 27 Feb 2013 22:08:09 -0000 I believe these comments have essentially been made before. I'm happier coming to closure on the text we have than spending more time refining it. Obviously if people jump in and want to work on these issues, then I'll end up in the rough. I just wanted to state an opinion in favor of being done rather than spending more time. --Sam From leifj@sunet.se Wed Feb 27 14:52:33 2013 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 2908921F87F5 for ; Wed, 27 Feb 2013 14:52:33 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEHh4Ls5nwTM for ; Wed, 27 Feb 2013 14:52:32 -0800 (PST) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38E21F87D5 for ; Wed, 27 Feb 2013 14:52:32 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com [62.102.145.131]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r1RMqMpT029732 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 22:52:30 GMT Message-ID: <512E8E26.3050605@sunet.se> Date: Wed, 27 Feb 2013 23:52:22 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: abfab@ietf.org References: <674F70E5F2BE564CB06B6901FD3DD78BEA2F15@tgxml338.toshiba.local> <512A0BBF.5010006@sunet.se> In-Reply-To: <512A0BBF.5010006@sunet.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 27 Feb 2013 22:52:33 -0000 On 02/24/2013 01:46 PM, Leif Johansson wrote: > On 02/23/2013 05:16 PM, Sam Hartman wrote: >>>>>>> writes: >> I'm fine with this change. >> _______________________________________________ >> > I *strongly* urge others on the list to chime in with their +1 or > detailed descent at this point. > > Cheers Leif Still waiting for more support or dissent From alper.yegin@yegin.org Wed Feb 27 23:40:32 2013 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 46FF021F8B0A for ; Wed, 27 Feb 2013 23:40:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAmCL6q3jSG6 for ; Wed, 27 Feb 2013 23:40:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B47BC21F8A0C for ; Wed, 27 Feb 2013 23:40:25 -0800 (PST) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MDRHZ-1U32Xm0y1F-00GfaN; Thu, 28 Feb 2013 02:40:23 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Thu, 28 Feb 2013 09:40:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <152D2483-5DC1-4BA0-891C-41D7010058E4@yegin.org> References: <8BEF4D48-9904-4B8A-8555-A3827EC07B3E@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:9/0kQ//bT4SvG21Jn80U/h9U2HI72MOjBDSRNhOlmrt RrO745gnzYI10ri8Y7Be58CwCm4Pm4niVunbqr9x3W/3fU4wVg zoB1fH3YJQjXLl7VTgHBe92rjsrmI5Pe1TlnJNWkz7EZoOweZZ 0TKkYmxenv2nuHTH6wLn4mgRSYC9pbFI0lOJsFveCN0QG4w7C9 qhjdj7NfAfYD1FB5ek23egfiLfoQ4xH+FtyhF7LF2h90pD/mql 9wIk5ClJIiqLXLkQR5Z6NJC7SanWksgdOW+tjn1Sj0FY7af+Wz +xyJVcCidrcEc0bIlH9auIjzCPDRr481A9u5WeqsaL24YYoKz4 aH/olbwc7C4EyFURFJvfX93EwZA40iKVNcH0LOw3sMwBsoH9bC +nKbV7meDuIxw== Cc: abfab@ietf.org Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 28 Feb 2013 07:40:32 -0000 Yes I made the same comment before.=20 Back then and now we understand you don't see them as issues.=20 We better get confirmation from other folks too before proceeding again. You disagreeing and everyone else being silent is not really comforting = to proceed, IMHO. Can someone else please take a stab at the points I'm raising and let us = know whether they think they are issues or not? On Feb 28, 2013, at 12:08 AM, Sam Hartman wrote: > I believe these comments have essentially been made before. I'm = happier > coming to closure on the text we have than spending more time refining > it. > Obviously if people jump in and want to work on these issues, then = I'll > end up in the rough. > I just wanted to state an opinion in favor of being done rather than > spending more time. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Thu Feb 28 01:33:05 2013 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 E4C6921F8B61 for ; Thu, 28 Feb 2013 01:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G288zLYG-i5k for ; Thu, 28 Feb 2013 01:33:04 -0800 (PST) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 327B621F8A25 for ; Thu, 28 Feb 2013 01:33:04 -0800 (PST) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 637E620C804A_12F244EB; Thu, 28 Feb 2013 09:33:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 036DD20C8038_12F244EF; Thu, 28 Feb 2013 09:33:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 28 Feb 2013 09:33:01 +0000 From: Josh Howlett To: Jim Schaad , "draft-ietf-abfab-aaa-saml@tools.ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 Thread-Index: Ac4TyEadmLXoDEkVS0CNvOS1EndVaQBzk+eA Date: Thu, 28 Feb 2013 09:33:00 +0000 Message-ID: In-Reply-To: <018001ce1457$252783e0$6f768ba0$@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.3.1.130117 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <853FB5A2584D1E4CA41ACE4130A16A6D@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 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, 28 Feb 2013 09:33:06 -0000 Jim, >This looks much more like the discussion that we had after the last IETF >meeting so I am generally happy. Glad to hear that. >1. I think inserting a paragraph start at "The name identifier..." will >make it clearer which artifacts are designed to be used in ABFAB scenarios >and which are designed for more universal usage. Agreed. In fact I'm thinking of re-structuring the entire document to make that distinction more obvious to the reader (but not sure if it's worth the pain). >2. In section 2 for the last bullet point in the first list - should >this >be the subject of an assertion or the subject of a protocol message? I am >always very unclear about SAML naming of items. However this confirmation >method can be in both a SAML assertion and in a query (i.e. >AttributeQuery). In SAML, only assertions and their requests have Subjects; framing PDUs do not. I'll try to make this more obvious in that bullet. >3. In section 5.2 - I am not happy with the single reference to RADSEC as >being the required. I would be more happy if the profile required either >TLS/UDP or TLS/TCP as required. Either that or TLS/TCP should be >recommended. I am worried that without this there might be an issue with >people thinking it is restricted to UDP. > >Note that for longer messages you probably really want to require the >TLS/TCP version not the DTLS/UDP version. Good point, I'll clarify. >4. In section 5.2 - I have probably said this before, I am not really a >big >fan of the use of language such as "MAY transmit a SAML request". If you >don't do the request how can one say that you are acting as a SAML >requester. A similar statement is also made for the second item. Just >say >"returns a SAML protocol message" and then talk about reasons that you >might not wish to do so. Yes, you did mention that before but I failed to follow through. I will do so on the next iteration. >5. In section 5.2 - s/responder MAY also return/responder MAY return/ - >it >might be read as saying you could return two even though that is >explicitly >forbidden. Ok. >6. In section 5.2 - I think we should probably add the following >paragraph: > >SAML responders SHOULD return a RADIUS state attribute as part of the >Access-Accept message so that future SAML queries can be run against the >same context of an authentication exchange. Good idea. >7. In section 6 - update the reference for NAI to draft-ietf-radext-nai Ok -- I had no idea the NAI was being updated (again). (I note that the new doc talks of "confederations", which I consider a synonym for "federation" in this context. Possibly the author of that doc might want to refer to ABFAB, by way of an example?) >8. In section 7.3.3 - I am not sure that the dependence on the abfab >document at the end of the section makes sense. For example, why should >the >EAP method support channel binding in order to return a SAML response? I >think that one can restrict the requirements to those in the AuthnRequest >and those necessitated by the application (whatever the application). You >probably just missed this in the general ABFAB removal. Correct; I'll remove. >9. In section 7.4.1 - I think the second paragraph can be removed and >placed in section 7.4.2. It is not related to the AuthnRequest but to the >Response. Ok. >10. In section 7.4.2 - I think we might need to make a statement about >returning no subject identifier and the correct interaction with the >AllowCreate attribute. If the IdP is not going to return a name, but is >just returning a subject conformation that says - the user associated with >this conversation - is this to be considered a "new identity" for the >user? I need to think about this; I will propose a form of words. >11. In section 7.4.2 - I have a problem with the last bullet point. I >would be happier if the text looked more like: > >Other conditions MAY be included as requested by the Relying Party or at >the >discretion of the Identity Provider. The Identity Provider is not >obligated >to honor the requested set of conditions in the , if >any. If the Identity Provider does not honor the requested set of >conditions is MUST either not return a message or return >a > message with an error. The conditions included by the RP in the request are (SAMLCore section 3.4.1) "intended as input to the process of constructing the assertion, rather than as conditions on the use of the request itself". An assertion that include these conditions can always be discarded by the RP, so I am unclear what value the new sentence adds? >12. In section 9. I think in this case it would be useful to have an >informational reference to TEAP about mapping these from an EAP method to >the URIs specified. I'm not sure if we want to explicitly map the TEAP concepts of user and machine, although I admit that I don't have a strong argument against this. I suppose have a vague concern that in creating this linkage we might inadvertently constrain ourselves to TEAP's definition of 'user' or 'machine', or guide implementors/deployers towards use of a specific EAP method (I suppose that informative usage guards against this to some extent, but I could imagine an over-zealous interpretations of this). >s/artefacts/artifacts/ Thanks again for the review. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company 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. VAT No. 614944238 From Josh.Howlett@ja.net Thu Feb 28 02:20:31 2013 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 B044E21F8AB4 for ; Thu, 28 Feb 2013 02:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEwUxSfjt6E3 for ; Thu, 28 Feb 2013 02:20:30 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 477A421F8A80 for ; Thu, 28 Feb 2013 02:20:30 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F3DF01AF45EA_12F2F6CB; Thu, 28 Feb 2013 10:20:28 +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 7F9091AF45F8_12F2F6CF; Thu, 28 Feb 2013 10:20:28 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 28 Feb 2013 10:20:28 +0000 From: Josh Howlett To: Alper Yegin , Joseph Salowey Thread-Topic: [abfab] Summary of proposed changes to eat applicability document Thread-Index: AQHOFZ06GN1d52taok+mJwmwwrtZsw== Date: Thu, 28 Feb 2013 10:20:27 +0000 Message-ID: In-Reply-To: <8BEF4D48-9904-4B8A-8555-A3827EC07B3E@yegin.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 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] Summary of proposed changes to eat applicability document 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, 28 Feb 2013 10:20:31 -0000 I am happy with the proposed text. I have made some comments to Alper's issues below. Josh. On 27/02/2013 21:36, "Alper Yegin" wrote: >>=20 >> 2.1 Retransmission >>=20 >> In EAP, the authenticator is responsible for retransmission. By default >> EAP assumes that the lower layer (the application in this context) is >> unreliable. The authenticator can send a packet whenever its >> retransmission timer triggers. In this mode, applications need to be >>able to receive and process >> EAP messages at any time during the authentication conversation. >>=20 >> Alternatively, EAP permits a lower layer to set the retransmission timer >> to infinite. When this happens, the lower layer becomes responsible for >> reliable delivery of EAP messages. Applications that use a lock-step or >> client-driven authentication protocol might benefit from this approach. >>=20 > >It'd be useful to explain why so, even briefly. I'm happy with this description. It is somewhat terse, but it meets the need. >> In addition to retransmission behavior applications need to deal with >> discarded EAP messages. For example, whenever some EAP methods receive >>erroneous >> input, these methods discard the input rather than generating an error >> response. If the erroneous input was generated by an attacker, >> legitimate input can sometimes be received after the erroneous >> input. Applications MUST handle discarded EAP messages, >> although the specific way in which discarded messages will be handled >> depend on the characteristics of the application. Options include >> failing the authentication at the application level, requesting an EAP >> retransmit and waiting for additional EAP input. >>=20 > >Are these the only three options for how apps must handle discarded EAP >messages? If so, we should state that clearly. If not, then the "MUST >handle" statement is not meaningful at all. Unless we state specific way >of handling, or provide some general guidelines (e.g., characteristics of >handling), "MUST handle" does not mean anything to implementors. The applicability statement is describing a behaviour that needs to be considered by applications if they want to interoperate. It is reasonable to leave the question of what it means to successfully interoperate as an exercise for the application, because that will vary from application to application. >Also, as I had stated earlier, this requirement implies an interface >between the EAP method layer and the EAP lower-layer. Such an interface >does not exist, there is EAP in between. >This requirement has additional implications on EAP methods too. Existing >EAP methods need to be modified?? I don't follow this logic. While one can argue that such an interface might be useful, that does not imply that one is necessary. There is running code to prove it :-) >> Specifications of how EAP is used for application authentication SHOULD >> document how retransmission and message discards are handled. >>=20 > >Why not MUST? See the first point. >> 4) Re-Authentication >>=20 >> ADD >>=20 >> 2.2 Re-Authentication >>=20 >> EAP lower layers MAY provide a mechanism for re-authentication to happen >> within an existing session [RFC 3748]. Diameter standardizes a mechanism >> for a AAA server to request re-authentication [RFC >> 4005]. Re-authentication permits security associations to be updated >> without establishing a new session. For network access, this can be >> important because interrupting network access can disrupt connections >> and media. >>=20 >> Some applications might not need re-authentication support. For example >> if sessions are relatively short-lived or if sessions can be replaced >> without significant disruption, re-authentication might not provide >> value. Protocols like HypertextTransport Protocol (HTTP) and Simple >> Mail Transport Protocol (SMTP) are examples of protocols where >> establishing a new connection to update security associations is likely >> to be sufficient. >>=20 >> Re-authentication is likely to be valuable if sessions or connections >> are long-lived or if there is a significant cost to disrupting them. >>=20 > >There's a bit of a terminology confusion here, I believe. > >I think the intention is to state that we don't need to run EAP again and >again in order to maintain an always-on security association. It is OK to >let EAP sessions expire. We can run EAP again if and when we need a >security association again. One could call this "re-authenticaiton". > >On the other hand, letting the security association expire and having to >run EAP again on-demand can also be called "re-authentication". I regret that I don't understand what point is being made here. The text seems pretty clear to me. >> Another factor may make re-authentication important. Some protocols only >> permit one part in a protocol (for example the client) to establish a >> new connection. If another party in the protocol needs the security >> association refreshed then re-authentication can provide a mechanism to >> do so. >>=20 >> Lower layers SHOULD describe whether re-authentication is provided and >> which parties can initiate it. > >I'd say "MUST" here too. Ditto the first point. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company 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. VAT No. 614944238 From alper.yegin@yegin.org Thu Feb 28 03:47:35 2013 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 A0B4521F87EE for ; Thu, 28 Feb 2013 03:47:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpFKASnVIs3X for ; Thu, 28 Feb 2013 03:47:34 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A92C321F862E for ; Thu, 28 Feb 2013 03:47:34 -0800 (PST) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MCcTS-1U1iIk1FvW-0092gf; Thu, 28 Feb 2013 06:47:33 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Thu, 28 Feb 2013 13:47:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> References: To: Josh Howlett X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:GJf48pTb8Yb7JcUY7Eg2ugkDb2tVTQgtAL9PGMldK47 VskZOzRs8KxLOG6pCaWT4e3C+vBbZvOOp5fk3cXl/Wep09MSWR BndlpPCspW9b/raMDLuMejOs5qcEnkHagk7+DcqCmZ48eFoX10 sUQsf1dLE95/sozTuGKca+vVmk25EE7ul6QAhraLvWIvvt0SHU 9QvepdN2T6mw1LyqR7cwTFI6Ol03IBHBmqXexAhV5kF5JBdcXN JjQJeZ5KFiTviCQHMxWOYSbaQLUQT6oXWuRL0tAnOO1gqZlbyX v5CVfjj43Hxf/lLIa7f375Un1hUy8V+c6OLFvfzRyUXtoowX5e uG1UZzRKEkYv0wVHDM0r+np2yBjIPUAoX0ayV4QfopTsKzVm4j 8kjMnovLIvYeQ== Cc: "abfab@ietf.org" Subject: Re: [abfab] Summary of proposed changes to eat applicability document 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, 28 Feb 2013 11:47:35 -0000 >>>=20 >>> 2.1 Retransmission >>>=20 >>> In EAP, the authenticator is responsible for retransmission. By = default >>> EAP assumes that the lower layer (the application in this context) = is >>> unreliable. The authenticator can send a packet whenever its >>> retransmission timer triggers. In this mode, applications need to be >>> able to receive and process >>> EAP messages at any time during the authentication conversation. >>>=20 >>> Alternatively, EAP permits a lower layer to set the retransmission = timer >>> to infinite. When this happens, the lower layer becomes responsible = for >>> reliable delivery of EAP messages. Applications that use a lock-step = or >>> client-driven authentication protocol might benefit from this = approach. >>>=20 >>=20 >> It'd be useful to explain why so, even briefly. >=20 > I'm happy with this description. It is somewhat terse, but it meets = the > need. >=20 I don't think readers' understanding can make the jump from 1st+2nd = sentences to the 3rd sentence without having followed all the = discussions on the list. I'm merely concerned about that. If I'm the only one concerned, then = that's fine=85. >>> In addition to retransmission behavior applications need to deal = with >>> discarded EAP messages. For example, whenever some EAP methods = receive >>> erroneous >>> input, these methods discard the input rather than generating an = error >>> response. If the erroneous input was generated by an attacker, >>> legitimate input can sometimes be received after the erroneous >>> input. Applications MUST handle discarded EAP messages, >>> although the specific way in which discarded messages will be = handled >>> depend on the characteristics of the application. Options include >>> failing the authentication at the application level, requesting an = EAP >>> retransmit and waiting for additional EAP input. >>>=20 >>=20 >> Are these the only three options for how apps must handle discarded = EAP >> messages? If so, we should state that clearly. If not, then the "MUST >> handle" statement is not meaningful at all. Unless we state specific = way >> of handling, or provide some general guidelines (e.g., = characteristics of >> handling), "MUST handle" does not mean anything to implementors. >=20 > The applicability statement is describing a behaviour that needs to be > considered by applications if they want to interoperate. This "MUST" cannot be implemented. It's not clear what an implementor = "must" be doing to comply. This is merely telling us "there's a problem, you MUST deal with it".=20 This reads more like recognition of an issue, rather than a solution. We should either have a very clear "MUST do this =85", or Define what the problem is, and leave it to the application designers to = deal with it in their own terms. (And even in this case not sure if you = can use "MUST"=85 maybe, maybe not.) We have neither of the above. > It is reasonable > to leave the question of what it means to successfully interoperate as = an > exercise for the application, because that will vary from application = to > application. >=20 >> Also, as I had stated earlier, this requirement implies an interface >> between the EAP method layer and the EAP lower-layer. Such an = interface >> does not exist, there is EAP in between. >> This requirement has additional implications on EAP methods too. = Existing >> EAP methods need to be modified?? >=20 > I don't follow this logic. While one can argue that such an interface > might be useful, that does not imply that one is necessary. There is > running code to prove it :-) >=20 So, how do you deal with this in your implementation? If the EAP = authentication method (e.g., EAP-TLS, EAP-AKA, etc.) discards a message, = who takes what action? >>> Specifications of how EAP is used for application authentication = SHOULD >>> document how retransmission and message discards are handled. >>>=20 >>=20 >> Why not MUST? >=20 > See the first point. >=20 I was suggesting using MUST instead of SHOULD. I didn't understand how = your first point addresses my comment here. >>> 4) Re-Authentication >>>=20 >>> ADD >>>=20 >>> 2.2 Re-Authentication >>>=20 >>> EAP lower layers MAY provide a mechanism for re-authentication to = happen >>> within an existing session [RFC 3748]. Diameter standardizes a = mechanism >>> for a AAA server to request re-authentication [RFC >>> 4005]. Re-authentication permits security associations to be updated >>> without establishing a new session. For network access, this can be >>> important because interrupting network access can disrupt = connections >>> and media. >>>=20 >>> Some applications might not need re-authentication support. For = example >>> if sessions are relatively short-lived or if sessions can be = replaced >>> without significant disruption, re-authentication might not provide >>> value. Protocols like HypertextTransport Protocol (HTTP) and Simple >>> Mail Transport Protocol (SMTP) are examples of protocols where >>> establishing a new connection to update security associations is = likely >>> to be sufficient. >>>=20 >>> Re-authentication is likely to be valuable if sessions or = connections >>> are long-lived or if there is a significant cost to disrupting them. >>>=20 >>=20 >> There's a bit of a terminology confusion here, I believe. >>=20 >> I think the intention is to state that we don't need to run EAP again = and >> again in order to maintain an always-on security association. It is = OK to >> let EAP sessions expire. We can run EAP again if and when we need a >> security association again. One could call this "re-authenticaiton". >>=20 >> On the other hand, letting the security association expire and having = to >> run EAP again on-demand can also be called "re-authentication". >=20 > I regret that I don't understand what point is being made here. The = text > seems pretty clear to me. I'm confused about the terms "re-authenticaiton" and "session".=20 To me, both of the following cases qualify as "re-authentication": - Either the EAP peer or the EAP authenticator initiates new EAP = authentication before the current EAP SA expires. One or more EAP = authentication sessions live inside the same EAP lower-layer session. - EAP SA can be left to expire. The EAP lower-layer session may or may = not expire in response to the EAP SA expiration. Whoever needs EAP SA is = responsible for initiating EAP authentication. For example, when the = server has some data to transmit but there is no SA available, then it'd = trigger authentication. Having said both qualifies as "re-auth" in my understanding, I believe = the text is referring to the former type.=20 Maybe we need some additional terminology to distinguish the two type = from each other. >=20 >>> Another factor may make re-authentication important. Some protocols = only >>> permit one part in a protocol (for example the client) to establish = a >>> new connection. If another party in the protocol needs the security >>> association refreshed then re-authentication can provide a mechanism = to >>> do so. >>>=20 >>> Lower layers SHOULD describe whether re-authentication is provided = and >>> which parties can initiate it. >>=20 >> I'd say "MUST" here too. >=20 > Ditto the first point. >=20 I was suggesting using MUST instead of SHOULD. I didn't understand how = your first point addresses my comment here. Alper > Josh. >=20 >=20 > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20= > not-for-profit company 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. VAT No. 614944238 >=20 From cantor.2@osu.edu Thu Feb 28 07:12:21 2013 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 0452021F8BA1 for ; Thu, 28 Feb 2013 07:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.77 X-Spam-Level: X-Spam-Status: No, score=-3.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08VO6kYsz+Nu for ; Thu, 28 Feb 2013 07:12:20 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFF021F8B9E for ; Thu, 28 Feb 2013 07:12:20 -0800 (PST) Received: from mail64-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 15:12:19 +0000 Received: from mail64-co1 (localhost [127.0.0.1]) by mail64-co1-R.bigfish.com (Postfix) with ESMTP id B1D06A400A5; Thu, 28 Feb 2013 15:12:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275chz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1155h) Received-SPF: pass (mail64-co1: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail64-co1 (localhost.localdomain [127.0.0.1]) by mail64-co1 (MessageSwitch) id 1362064337517045_22075; Thu, 28 Feb 2013 15:12:17 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.227]) by mail64-co1.bigfish.com (Postfix) with ESMTP id 7491C20053; Thu, 28 Feb 2013 15:12:17 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 15:12:16 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf02 (Postfix) with ESMTP id 7DCED20049; Thu, 28 Feb 2013 10:12:16 -0500 (EST) 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 id 14.02.0328.009; Thu, 28 Feb 2013 10:12:16 -0500 From: "Cantor, Scott" To: Josh Howlett , Jim Schaad , "draft-ietf-abfab-aaa-saml@tools.ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 Thread-Index: Ac4TyEadmLXoDEkVS0CNvOS1EndVaQBzk+eAAAvZ4IA= Date: Thu, 28 Feb 2013 15:12:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A8A2A61273FA446A3C4C9DDD9D14EDD@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 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, 28 Feb 2013 15:12:21 -0000 On 2/28/13 4:33 AM, "Josh Howlett" wrote: > >>2. In section 2 for the last bullet point in the first list - should >>this be the subject of an assertion or the subject of a protocol >>message? I am >>always very unclear about SAML naming of items. However this >>confirmation >>method can be in both a SAML assertion and in a query (i.e. >>AttributeQuery). > >In SAML, only assertions and their requests have Subjects; framing PDUs do >not. I'll try to make this more obvious in that bullet. Queries have subjects. I think the bullet's context would apply to both. >>10. In section 7.4.2 - I think we might need to make a statement about >>returning no subject identifier and the correct interaction with the >>AllowCreate attribute. If the IdP is not going to return a name, but is >>just returning a subject conformation that says - the user associated >>with >>this conversation - is this to be considered a "new identity" for the >>user? > >I need to think about this; I will propose a form of words. AllowCreate is an evil little gnome of a feature, but I think to address Jim's point, it only applies to identifiers, period. If there's no identifier asserted, it's irrelevant from a processing standpoint. >The conditions included by the RP in the request are (SAMLCore section >3.4.1) "intended as input to the process of constructing the assertion, >rather than as conditions on the use of the request itself". An assertion >that include these conditions can always be discarded by the RP, so I am >unclear what value the new sentence adds? I suppose it would be to limit the processing by the IdP if the RP knows it's going to throw away the result anyway. -- Scott From leifj@nordu.net Thu Feb 28 05:46:45 2013 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 0DBB721F87EA for ; Thu, 28 Feb 2013 05:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stqcIk+fA9ZX for ; Thu, 28 Feb 2013 05:46:44 -0800 (PST) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1791421F8621 for ; Thu, 28 Feb 2013 05:46:42 -0800 (PST) Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r1SDkbnB002469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 13:46:40 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1362059201; bh=3XGGU6qQS2nguultNLhlBR7kw/IjrdAJ0Rthn26lQIo=; h=From:Subject:References:In-Reply-To:Date:To:Cc; b=M2GyaGjkdwvP7YWkf6UPgnxFiWY1CDRido2MjCgXpV/cOVVqxuzNO7y/oUaql7hri DwaeJ6T1TOf239rY2lUjHIK5B2E2wIsG9AWGo9U2/+YynFQt58/zZ80QNU2QHMRkw2 ROpsdzWHWR0Z8z8+x99IO9kaSbheMle+nqXrqEs4= X-Footer: bm9yZHUubmV0 Received: from [2.68.212.137] ([2.68.212.137]) by kerio.nordu.net; Thu, 28 Feb 2013 14:46:36 +0100 From: "Leif Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> Mime-Version: 1.0 (1.0) In-Reply-To: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> Message-Id: <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> Date: Thu, 28 Feb 2013 14:46:33 +0100 To: Alper Yegin X-Mailman-Approved-At: Thu, 28 Feb 2013 07:39:26 -0800 Cc: "abfab@ietf.org" Subject: Re: [abfab] Summary of proposed changes to eat applicability.document 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, 28 Feb 2013 13:46:45 -0000 >=20 > This "MUST" cannot be implemented. It's not clear what an implementor "mus= t" be doing to comply. > This is merely telling us "there's a problem, you MUST deal with it".=20 > This reads more like recognition of an issue, rather than a solution. I' going to weigh in (as an individual) on this point.=20 There is (imo) nothing inherently problematic about calling out a problem th= at needs to be addressed in another specification, especially when writing a= n applicability statement. Cheers Leif From ietf@augustcellars.com Thu Feb 28 07:53:09 2013 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 2C17B21F87C3 for ; Thu, 28 Feb 2013 07:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgNo+jkWwQ0a for ; Thu, 28 Feb 2013 07:53:08 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A13F821F8B70 for ; Thu, 28 Feb 2013 07:53:08 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 811B22CA23; Thu, 28 Feb 2013 07:53:07 -0800 (PST) From: "Jim Schaad" To: "'Josh Howlett'" , "'Jim Schaad'" , References: <018001ce1457$252783e0$6f768ba0$@augustcellars.com> In-Reply-To: Date: Thu, 28 Feb 2013 07:52:35 -0800 Message-ID: <02c401ce15cb$a13e4480$e3bacd80$@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: AQGU+FiNX6irAeKJzpsbjwNN6DuwGZkBpd4A Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 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, 28 Feb 2013 15:53:09 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Josh Howlett > >11. In section 7.4.2 - I have a problem with the last bullet point. I > >would be happier if the text looked more like: > > > >Other conditions MAY be included as requested by the Relying Party or > >at the discretion of the Identity Provider. The Identity Provider is > >not obligated to honor the requested set of conditions in the > >, if any. If the Identity Provider does not honor > >the requested set of conditions is MUST either not return a > > message or return a message with > an > >error. > > The conditions included by the RP in the request are (SAMLCore section > 3.4.1) "intended as input to the process of constructing the assertion, rather > than as conditions on the use of the request itself". An assertion that include > these conditions can always be discarded by the RP, so I am unclear what > value the new sentence adds? > To me current text says the following. The RP says please do this. The IdP does not do this. The IdP returns an assertion. How does the RP know that the IdP did not do this. The new sentences says. If the IdP is not going to do this - error. Jim From Josh.Howlett@ja.net Thu Feb 28 08:14:50 2013 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 1BE5821F85CC for ; Thu, 28 Feb 2013 08:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obaQ05zaKg7i for ; Thu, 28 Feb 2013 08:14:49 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 836DD21F85A0 for ; Thu, 28 Feb 2013 08:14:49 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A7BC91AF49E8_12F8278B; Thu, 28 Feb 2013 16:14:48 +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 7E0001AF49E2_12F8278F; Thu, 28 Feb 2013 16:14:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 28 Feb 2013 16:14:48 +0000 From: Josh Howlett To: Jim Schaad , 'Jim Schaad' , "draft-ietf-abfab-aaa-saml@tools.ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 Thread-Index: Ac4TyEadmLXoDEkVS0CNvOS1EndVaQBzk+eAAA1CfIAAAMVxAA== Date: Thu, 28 Feb 2013 16:14:47 +0000 Message-ID: In-Reply-To: <02c401ce15cb$a13e4480$e3bacd80$@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.3.1.130117 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <921BD7AADB4FD64BA3BC202B76797790@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-05 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, 28 Feb 2013 16:14:50 -0000 >>>Other conditions MAY be included as requested by the Relying Party or >> >at the discretion of the Identity Provider. The Identity Provider is >> >not obligated to honor the requested set of conditions in the >> >, if any. If the Identity Provider does not honor >> >the requested set of conditions is MUST either not return a >> > message or return a message with >> an >> >error. >>=20 >> The conditions included by the RP in the request are (SAMLCore section >> 3.4.1) "intended as input to the process of constructing the assertion, >rather >> than as conditions on the use of the request itself". An assertion that >include >> these conditions can always be discarded by the RP, so I am unclear what >> value the new sentence adds? >>=20 > >To me current text says the following. The RP says please do this. The >IdP >does not do this. The IdP returns an assertion. > >How does the RP know that the IdP did not do this. It parses the assertion. The requested conditions are either present, or not. These conditions are not instructions to the IdP as to how it should process the request. They are instructions from the IdP to the SP describing the circumstances in which the assertion can be considered valid. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company 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. VAT No. 614944238 From hartmans@painless-security.com Thu Feb 28 09:20:32 2013 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 87E1221F89C7 for ; Thu, 28 Feb 2013 09:20:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVTLdfr58LYR for ; Thu, 28 Feb 2013 09:20:31 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1B21F89C0 for ; Thu, 28 Feb 2013 09:20:27 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id E66A120144; Thu, 28 Feb 2013 12:15:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B06E447B; Thu, 28 Feb 2013 12:20:26 -0500 (EST) From: Sam Hartman To: "Leif Johansson" References: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> Date: Thu, 28 Feb 2013 12:20:26 -0500 In-Reply-To: <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> (Leif Johansson's message of "Thu, 28 Feb 2013 14:46:33 +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] Summary of proposed changes to eat applicability.document 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, 28 Feb 2013 17:20:32 -0000 Josh, Alper, I'd like to come back to one point. Alper asked why we wanted to have SHOULD describe re-authentication and retransmission behavior rather than MUST describe that behavior. When we use the SHOULD 2119 keyword it's because we believe there are unusual circumstances where violating the SHOULD is the right thing to do. SHOULD is a fairly strong requirement, but it does not apply 100% of the time. The primary reason I think that should be a SHOULD not a MUST is that I think documenting the lower layer (which is to say the application) is only a SHOLUD. If a company creates a proprietary application, I don't think it's our business to mandate that they document certain things. I cannot think of a case where it would be appropriate for a document in the IETF describing the use of EAP for application authentication should leave out discussion of retransmission and discard behavior. (We'll need to go fix draft-ietf-abfab-gss-eap as it does not discuss discard behavior) Re-authentication is more complex. I prefer the current text but don't think it would be a problem to change the SHOULD document for retransmission and discard to a MUST. I'd object to the change for re-authentication. --Sam