From wei.yinxing@zte.com.cn Mon Jul 4 04:47:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFB21F0C4A for ; Mon, 4 Jul 2011 04:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 GhMc7DL0O3tk for ; Mon, 4 Jul 2011 04:47:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A76CE1F0C49 for ; Mon, 4 Jul 2011 04:47:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 4864967931198; Mon, 4 Jul 2011 19:45:56 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 54914.967931198; Mon, 4 Jul 2011 19:47:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p64BliVo066348 for ; Mon, 4 Jul 2011 19:47:44 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) To: abfab@ietf.org MIME-Version: 1.0 X-KeepSent: 7B8E05C8:C529A048-482578C3:0040A97D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 4 Jul 2011 19:47:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-04 19:47:45, Serialize complete at 2011-07-04 19:47:45 Content-Type: multipart/alternative; boundary="=_alternative 0040CD1E482578C3_=" X-MAIL: mse01.zte.com.cn p64BliVo066348 Subject: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 11:47:54 -0000 This is a multipart message in MIME format. --=_alternative 0040CD1E482578C3_= Content-Type: text/plain; charset="US-ASCII" Hi, all A new draft is uploaded into abfab, please review it. Any comments are welcome! ------------------------------------------------------- http://www.ietf.org/id/draft-wei-abfab-fcla-00.txt ABFAB Y. Wei, Ed. Internet-Draft ZTE Corporation Intended status: Informational July 4, 2011 Expires: January 5, 2012 Federated Cross-Layer Access draft-wei-abfab-fcla-00 Abstract Network stratum and application stratum form a federation to faciliate user's access. Network operator acts as Identity Provider (IdP), and application reuses underlying network's security capabilities to simlify application's access. This document is to introduce such federated cross-layer access use case. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0040CD1E482578C3_= Content-Type: text/html; charset="US-ASCII"
Hi, all

 A new draft is uploaded into abfab, please review it. Any comments are welcome!

-------------------------------------------------------
 http://www.ietf.org/id/draft-wei-abfab-fcla-00.txt
ABFAB                                                        Y. Wei, Ed.
Internet-Draft                                           ZTE Corporation
Intended status: Informational                              July 4, 2011
Expires: January 5, 2012

                     Federated Cross-Layer Access
                       draft-wei-abfab-fcla-00

Abstract

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


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0040CD1E482578C3_=-- From smith@Cardiff.ac.uk Mon Jul 4 11:07:09 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44B11E80D2 for ; Mon, 4 Jul 2011 11:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwUciBvmKEuE for ; Mon, 4 Jul 2011 11:07:09 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA211E80D3 for ; Mon, 4 Jul 2011 11:07:08 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QdnY2-0002G7-Uc for abfab@ietf.org; Mon, 04 Jul 2011 19:07:06 +0100 Received: from [86.184.20.181] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QdnY2-0001y6-R0 for abfab@ietf.org; Mon, 04 Jul 2011 19:07:06 +0100 From: Rhys Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2011 19:07:01 +0100 Message-Id: <9033D877-5264-49B1-8D9F-4B46DE8EBAAE@cardiff.ac.uk> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] First draft of Usability I-D submitted 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 Jul 2011 18:07:09 -0000 Hi all, I volunteered to pull together the document in the abfab charter around = usability of abfab technologies. I've just posted a -00 draft of the = doc, which can be found here: = http://www.ietf.org/id/draft-smith-abfab-usability-ui-considerations-00.tx= t At the moment, it's pretty rough and ready and is more of a straw man = around structure and type of content than anything else. You can = consider every single paragraph as "todo". I've split the document up into what I see as the three main areas of = usability of a client that helps users perform abfab magic - managing = identities, managing service to identity mappings, and handling errors. = Each area definitely needs a lot more work. So please, all reviews and comments most welcome. Usability is one of = those particularly thorny areas that is hard to tie down, but will quite = likely make or break this technology when it comes to user acceptance, = so I think it's pretty important. I will definitely be harassing those of you who have expressed an = interest (or got shanghaied into being interested) over the coming month = or so for feedback and suggestions :-). Kind Regards, Rhys. -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From gabilm@um.es Tue Jul 5 07:42:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E011E8074 for ; Tue, 5 Jul 2011 07:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.99 X-Spam-Level: X-Spam-Status: No, score=-4.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 agQCgbnc0HG4 for ; Tue, 5 Jul 2011 07:42:55 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 56B5B21F8579 for ; Tue, 5 Jul 2011 07:42:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 3803B5386C; Tue, 5 Jul 2011 16:42:52 +0200 (CEST) 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 V+USqHVkf+oC; Tue, 5 Jul 2011 16:42:51 +0200 (CEST) Received: from [192.168.1.101] (unknown [84.236.164.185]) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPA id CE8BC5385C; Tue, 5 Jul 2011 16:42:47 +0200 (CEST) To: "=?utf-8?B?Umh5cyBTbWl0aA==?=" ,abfab@ietf.org From: "=?utf-8?B?Z2FiaWxtQHVtLmVz?=" Date: Tue, 05 Jul 2011 16:43:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1309876988442" Message-Id: <20110705144247.CE8BC5385C@xenon11.um.es> Subject: Re: [abfab] =?utf-8?q?First_draft_of_Usability_I-D_submitted?= 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 Jul 2011 14:42:56 -0000 ------=_Part_0_1309876988442 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkuIAoKSXMgdGhlIHBhc3N3b3JkIG9yIHRoZSBpZGVudGl0eSBjb250YWluZXIgcHJvdGVjdGVk IGJ5IHNvbWUgcGFzc3BocmFzZT8gSSBzdXBwb3NlIGl0IGlzIG5vdCBzdG9yZWQgaW4gY2xlYXIg dGV4dC4KClJlZ2FyZHMsIEdhYmkgCgpFbnZpYWRvIGRlc2RlIG1pIEhUQwoKLS0tLS0gUmVwbHkg bWVzc2FnZSAtLS0tLQpEZTogIlJoeXMgU21pdGgiIDxzbWl0aEBjYXJkaWZmLmFjLnVrPgpGZWNo YTogbHVuLiwganVsLiA0LCAyMDExIDIwOjA3CkFzdW50bzogW2FiZmFiXSBGaXJzdCBkcmFmdCBv ZiBVc2FiaWxpdHkgSS1EIHN1Ym1pdHRlZApQYXJhOiA8YWJmYWJAaWV0Zi5vcmc+CgpIaSBhbGws CgpJIHZvbHVudGVlcmVkIHRvIHB1bGwgdG9nZXRoZXIgdGhlIGRvY3VtZW50IGluIHRoZSBhYmZh YiBjaGFydGVyIGFyb3VuZCB1c2FiaWxpdHkgb2YgYWJmYWIgdGVjaG5vbG9naWVzLiBJJ3ZlIGp1 c3QgcG9zdGVkIGEgLTAwIGRyYWZ0IG9mIHRoZSBkb2MsIHdoaWNoIGNhbiBiZSBmb3VuZCBoZXJl OgoKaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zbWl0aC1hYmZhYi11c2FiaWxpdHktdWkt Y29uc2lkZXJhdGlvbnMtMDAudHh0CgpBdCB0aGUgbW9tZW50LCBpdCdzIHByZXR0eSByb3VnaCBh bmQgcmVhZHkgYW5kIGlzIG1vcmUgb2YgYSBzdHJhdyBtYW4gYXJvdW5kIHN0cnVjdHVyZSBhbmQg dHlwZSBvZiBjb250ZW50IHRoYW4gYW55dGhpbmcgZWxzZS4gWW91IGNhbiBjb25zaWRlciBldmVy eSBzaW5nbGUgcGFyYWdyYXBoIGFzICJ0b2RvIi4KCkkndmUgc3BsaXQgdGhlIGRvY3VtZW50IHVw IGludG8gd2hhdCBJIHNlZSBhcyB0aGUgdGhyZWUgbWFpbiBhcmVhcyBvZiB1c2FiaWxpdHkgb2Yg YSBjbGllbnQgdGhhdCBoZWxwcyB1c2VycyBwZXJmb3JtIGFiZmFiIG1hZ2ljIC0gbWFuYWdpbmcg aWRlbnRpdGllcywgbWFuYWdpbmcgc2VydmljZSB0byBpZGVudGl0eSBtYXBwaW5ncywgYW5kIGhh bmRsaW5nIGVycm9ycy4gRWFjaCBhcmVhIGRlZmluaXRlbHkgbmVlZHMgYSBsb3QgbW9yZSB3b3Jr LgoKU28gcGxlYXNlLCBhbGwgcmV2aWV3cyBhbmQgY29tbWVudHMgbW9zdCB3ZWxjb21lLiBVc2Fi aWxpdHkgaXMgb25lIG9mIHRob3NlIHBhcnRpY3VsYXJseSB0aG9ybnkgYXJlYXMgdGhhdCBpcyBo YXJkIHRvIHRpZSBkb3duLCBidXQgd2lsbCBxdWl0ZSBsaWtlbHkgbWFrZSBvciBicmVhayB0aGlz IHRlY2hub2xvZ3kgd2hlbiBpdCBjb21lcyB0byB1c2VyIGFjY2VwdGFuY2UsIHNvIEkgdGhpbmsg aXQncyBwcmV0dHkgaW1wb3J0YW50LgoKSSB3aWxsIGRlZmluaXRlbHkgYmUgaGFyYXNzaW5nIHRo b3NlIG9mIHlvdSB3aG8gaGF2ZSBleHByZXNzZWQgYW4gaW50ZXJlc3QgKG9yIGdvdCBzaGFuZ2hh aWVkIGludG8gYmVpbmcgaW50ZXJlc3RlZCkgb3ZlciB0aGUgY29taW5nIG1vbnRoIG9yIHNvIGZv ciBmZWVkYmFjayBhbmQgc3VnZ2VzdGlvbnMgOi0pLgoKS2luZCBSZWdhcmRzLApSaHlzLgotLQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCkRyIFJoeXMgU21pdGggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGU6IHNtaXRoQGNhcmRpZmYuYWMudWsKRW5naW5lZXJpbmcgQ29uc3VsdGFudDogSWRlbnRp dHkgJiBBY2Nlc3MgTWFuYWdlbWVudCAgKEdQRzoweERFMkYwMjRDKQpJbmZvcm1hdGlvbiBTZXJ2 aWNlcywKQ2FyZGlmZiBVbml2ZXJzaXR5LCAgICAgICAgICAgICAgICAgICAgICAgICAgICB0OiAr NDQgKDApIDI5IDIwODcgMDEyNgozOS00MSBQYXJrIFBsYWNlLCBDYXJkaWZmLCAgICAgICAgICAg ICAgICAgICAgIGY6ICs0NCAoMCkgMjkgMjA4NyA0Mjg1CkNGMTAgM0JCLCBVbml0ZWQgS2luZ2Rv bS4gICAgICAgICAgICAgICAgICAgICAgbTogKzQ0ICgwKSA3OTY4IDA4NyA4MjEKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYWJm YWIgbWFpbGluZyBsaXN0CmFiZmFiQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWJmYWIK ------=_Part_0_1309876988442 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkuIDxicj48YnI+SXMgdGhlIHBhc3N3b3JkIG9yIHRoZSBpZGVudGl0eSBjb250YWluZXIgcHJv dGVjdGVkIGJ5IHNvbWUgcGFzc3BocmFzZT8gSSBzdXBwb3NlIGl0IGlzIG5vdCBzdG9yZWQgaW4g Y2xlYXIgdGV4dC48YnI+PGJyPlJlZ2FyZHMsIEdhYmkgPGJyPjxicj5FbnZpYWRvIGRlc2RlIG1p IEhUQzxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5EZTogJnF1b3Q7Umh5cyBT bWl0aCZxdW90OyAmbHQ7c21pdGhAY2FyZGlmZi5hYy51ayZndDs8YnI+RmVjaGE6IGx1bi4sIGp1 bC4gNCwgMjAxMSAyMDowNzxicj5Bc3VudG86IFthYmZhYl0gRmlyc3QgZHJhZnQgb2YgVXNhYmls aXR5IEktRCBzdWJtaXR0ZWQ8YnI+UGFyYTogJmx0O2FiZmFiQGlldGYub3JnJmd0Ozxicj48YnI+ SGkgYWxsLDxicj48YnI+SSB2b2x1bnRlZXJlZCB0byBwdWxsIHRvZ2V0aGVyIHRoZSBkb2N1bWVu dCBpbiB0aGUgYWJmYWIgY2hhcnRlciBhcm91bmQgdXNhYmlsaXR5IG9mIGFiZmFiIHRlY2hub2xv Z2llcy4gSSYjMzk7dmUganVzdCBwb3N0ZWQgYSAtMDAgZHJhZnQgb2YgdGhlIGRvYywgd2hpY2gg Y2FuIGJlIGZvdW5kIGhlcmU6PGJyPjxicj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LXNtaXRoLWFiZmFiLXVzYWJpbGl0eS11aS1jb25zaWRlcmF0aW9ucy0wMC50eHQiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc21pdGgtYWJmYWItdXNhYmlsaXR5LXVpLWNvbnNp ZGVyYXRpb25zLTAwLnR4dDwvYT48YnI+PGJyPkF0IHRoZSBtb21lbnQsIGl0JiMzOTtzIHByZXR0 eSByb3VnaCBhbmQgcmVhZHkgYW5kIGlzIG1vcmUgb2YgYSBzdHJhdyBtYW4gYXJvdW5kIHN0cnVj dHVyZSBhbmQgdHlwZSBvZiBjb250ZW50IHRoYW4gYW55dGhpbmcgZWxzZS4gWW91IGNhbiBjb25z aWRlciBldmVyeSBzaW5nbGUgcGFyYWdyYXBoIGFzICZxdW90O3RvZG8mcXVvdDsuPGJyPjxicj5J JiMzOTt2ZSBzcGxpdCB0aGUgZG9jdW1lbnQgdXAgaW50byB3aGF0IEkgc2VlIGFzIHRoZSB0aHJl ZSBtYWluIGFyZWFzIG9mIHVzYWJpbGl0eSBvZiBhIGNsaWVudCB0aGF0IGhlbHBzIHVzZXJzIHBl cmZvcm0gYWJmYWIgbWFnaWMgLSBtYW5hZ2luZyBpZGVudGl0aWVzLCBtYW5hZ2luZyBzZXJ2aWNl IHRvIGlkZW50aXR5IG1hcHBpbmdzLCBhbmQgaGFuZGxpbmcgZXJyb3JzLiBFYWNoIGFyZWEgZGVm aW5pdGVseSBuZWVkcyBhIGxvdCBtb3JlIHdvcmsuPGJyPjxicj5TbyBwbGVhc2UsIGFsbCByZXZp ZXdzIGFuZCBjb21tZW50cyBtb3N0IHdlbGNvbWUuIFVzYWJpbGl0eSBpcyBvbmUgb2YgdGhvc2Ug cGFydGljdWxhcmx5IHRob3JueSBhcmVhcyB0aGF0IGlzIGhhcmQgdG8gdGllIGRvd24sIGJ1dCB3 aWxsIHF1aXRlIGxpa2VseSBtYWtlIG9yIGJyZWFrIHRoaXMgdGVjaG5vbG9neSB3aGVuIGl0IGNv bWVzIHRvIHVzZXIgYWNjZXB0YW5jZSwgc28gSSB0aGluayBpdCYjMzk7cyBwcmV0dHkgaW1wb3J0 YW50Ljxicj48YnI+SSB3aWxsIGRlZmluaXRlbHkgYmUgaGFyYXNzaW5nIHRob3NlIG9mIHlvdSB3 aG8gaGF2ZSBleHByZXNzZWQgYW4gaW50ZXJlc3QgKG9yIGdvdCBzaGFuZ2hhaWVkIGludG8gYmVp bmcgaW50ZXJlc3RlZCkgb3ZlciB0aGUgY29taW5nIG1vbnRoIG9yIHNvIGZvciBmZWVkYmFjayBh bmQgc3VnZ2VzdGlvbnMgOi0pLjxicj48YnI+S2luZCBSZWdhcmRzLDxicj5SaHlzLjxicj4tLTxi cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPkRyIFJoeXMgU21pdGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlOiBzbWl0aEBjYXJkaWZmLmFj LnVrPGJyPkVuZ2luZWVyaW5nIENvbnN1bHRhbnQ6IElkZW50aXR5ICZhbXA7IEFjY2VzcyBNYW5h Z2VtZW50ICZuYnNwOyhHUEc6MHhERTJGMDI0Qyk8YnI+SW5mb3JtYXRpb24gU2VydmljZXMsPGJy PkNhcmRpZmYgVW5pdmVyc2l0eSwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3Q6ICs0NCAoMCkgMjkgMjA4NyAwMTI2PGJyPjM5LTQxIFBhcmsgUGxhY2UsIENhcmRpZmYs ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBmOiArNDQgKDApIDI5IDIwODcgNDI4NTxicj5DRjEwIDNCQiwgVW5pdGVk IEtpbmdkb20uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttOiArNDQgKDApIDc5NjggMDg3IDgyMTxicj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5hYmZhYiBtYWlsaW5nIGxpc3Q8YnI+YWJmYWJAaWV0Zi5vcmc8YnI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYjwvYT48YnI+PGJyPjxicj4= ------=_Part_0_1309876988442-- From smith@Cardiff.ac.uk Tue Jul 5 08:17:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5606F228015 for ; Tue, 5 Jul 2011 08:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9sC41FUi8wO for ; Tue, 5 Jul 2011 08:17:53 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6337122800F for ; Tue, 5 Jul 2011 08:17:53 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Qe7No-00047d-9w; Tue, 05 Jul 2011 16:17:52 +0100 Received: from [86.184.20.181] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qe7No-0004JO-5z; Tue, 05 Jul 2011 16:17:52 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rhys Smith In-Reply-To: <20110705144247.CE8BC5385C@xenon11.um.es> Date: Tue, 5 Jul 2011 16:17:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <651143B8-4C1E-4B92-BF39-A06904D0C1B4@cardiff.ac.uk> References: <20110705144247.CE8BC5385C@xenon11.um.es> To: gabilm@um.es X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] First draft of Usability I-D submitted 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 Jul 2011 15:17:54 -0000 I guess protecting the identity selector/container with a passphrase is = definitely a possibility someone implementing such a beast would = consider, and therefore usability aspects should be discussed, so should = probably be in the next draft. How such a passphrase would be stored securely would be, of course, = implementation specific and out of scope for this doc I think... R. On 5 Jul 2011, at 15:43, gabilm@um.es wrote: > Hi.=20 >=20 > Is the password or the identity container protected by some = passphrase? I suppose it is not stored in clear text. >=20 > Regards, Gabi=20 >=20 > Enviado desde mi HTC >=20 > ----- Reply message ----- > De: "Rhys Smith" > Fecha: lun., jul. 4, 2011 20:07 > Asunto: [abfab] First draft of Usability I-D submitted > Para: >=20 > Hi all, >=20 > I volunteered to pull together the document in the abfab charter = around usability of abfab technologies. I've just posted a -00 draft of = the doc, which can be found here: >=20 > = http://www.ietf.org/id/draft-smith-abfab-usability-ui-considerations-00.tx= t >=20 > At the moment, it's pretty rough and ready and is more of a straw man = around structure and type of content than anything else. You can = consider every single paragraph as "todo". >=20 > I've split the document up into what I see as the three main areas of = usability of a client that helps users perform abfab magic - managing = identities, managing service to identity mappings, and handling errors. = Each area definitely needs a lot more work. >=20 > So please, all reviews and comments most welcome. Usability is one of = those particularly thorny areas that is hard to tie down, but will quite = likely make or break this technology when it comes to user acceptance, = so I think it's pretty important. >=20 > I will definitely be harassing those of you who have expressed an = interest (or got shanghaied into being interested) over the coming month = or so for feedback and suggestions :-). >=20 > Kind Regards, > Rhys. > -- > ---------------------------------------------------------------------- > Dr Rhys Smith e: smith@cardiff.ac.uk > Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) > Information Services, > Cardiff University, t: +44 (0) 29 2087 0126 > 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 > CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From gabilm@um.es Tue Jul 5 08:26:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC129E8010 for ; Tue, 5 Jul 2011 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.99 X-Spam-Level: X-Spam-Status: No, score=-4.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 yPiGTplbCyfk for ; Tue, 5 Jul 2011 08:26:01 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 95F799E800E for ; Tue, 5 Jul 2011 08:26:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id CC13353680; Tue, 5 Jul 2011 17:25:58 +0200 (CEST) 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 CPM8kY+q6D2g; Tue, 5 Jul 2011 17:25:58 +0200 (CEST) Received: from [192.168.1.101] (unknown [84.236.164.185]) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPA id 566EE53831; Tue, 5 Jul 2011 17:25:55 +0200 (CEST) To: "=?utf-8?B?Umh5cyBTbWl0aA==?=" From: "=?utf-8?B?Z2FiaWxtQHVtLmVz?=" Date: Tue, 05 Jul 2011 17:26:15 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1309879575828" Message-Id: <20110705152555.566EE53831@xenon11.um.es> Cc: abfab@ietf.org Subject: Re: [abfab] =?utf-8?q?First_draft_of_Usability_I-D_submitted?= 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 Jul 2011 15:26:02 -0000 ------=_Part_0_1309879575828 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T2suIAoKQnV0IHlvdSBzaG91bGQgbm90IHN0b3JlIHRoZSBwYXNzcGhyYXNlLiBJdCBzaG91bGQg YmUgaW4geW91ciBoZWFkIDopCgpFbnZpYWRvIGRlc2RlIG1pIEhUQwoKLS0tLS0gUmVwbHkgbWVz c2FnZSAtLS0tLQpEZTogIlJoeXMgU21pdGgiIDxzbWl0aEBjYXJkaWZmLmFjLnVrPgpGZWNoYTog bWFyLiwganVsLiA1LCAyMDExIDE3OjE3CkFzdW50bzogW2FiZmFiXSBGaXJzdCBkcmFmdCBvZiBV c2FiaWxpdHkgSS1EIHN1Ym1pdHRlZApQYXJhOiA8Z2FiaWxtQHVtLmVzPgpDQzogPGFiZmFiQGll dGYub3JnPgoKCkkgZ3Vlc3MgcHJvdGVjdGluZyB0aGUgaWRlbnRpdHkgc2VsZWN0b3IvY29udGFp bmVyIHdpdGggYSBwYXNzcGhyYXNlIGlzIGRlZmluaXRlbHkgYSBwb3NzaWJpbGl0eSBzb21lb25l IGltcGxlbWVudGluZyBzdWNoIGEgYmVhc3Qgd291bGQgY29uc2lkZXIsIGFuZCB0aGVyZWZvcmUg dXNhYmlsaXR5IGFzcGVjdHMgc2hvdWxkIGJlIGRpc2N1c3NlZCwgc28gc2hvdWxkIHByb2JhYmx5 IGJlIGluIHRoZSBuZXh0IGRyYWZ0LgoKSG93IHN1Y2ggYSBwYXNzcGhyYXNlIHdvdWxkIGJlIHN0 b3JlZCBzZWN1cmVseSB3b3VsZCBiZSwgb2YgY291cnNlLCBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp YyBhbmQgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvYyBJIHRoaW5rLi4uCgpSLgoKCk9uIDUgSnVs IDIwMTEsIGF0IDE1OjQzLCBnYWJpbG1AdW0uZXMgd3JvdGU6Cgo+IEhpLiAKPiAKPiBJcyB0aGUg cGFzc3dvcmQgb3IgdGhlIGlkZW50aXR5IGNvbnRhaW5lciBwcm90ZWN0ZWQgYnkgc29tZSBwYXNz cGhyYXNlPyBJIHN1cHBvc2UgaXQgaXMgbm90IHN0b3JlZCBpbiBjbGVhciB0ZXh0Lgo+IAo+IFJl Z2FyZHMsIEdhYmkgCj4gCj4gRW52aWFkbyBkZXNkZSBtaSBIVEMKPiAKPiAtLS0tLSBSZXBseSBt ZXNzYWdlIC0tLS0tCj4gRGU6ICJSaHlzIFNtaXRoIiA8c21pdGhAY2FyZGlmZi5hYy51az4KPiBG ZWNoYTogbHVuLiwganVsLiA0LCAyMDExIDIwOjA3Cj4gQXN1bnRvOiBbYWJmYWJdIEZpcnN0IGRy YWZ0IG9mIFVzYWJpbGl0eSBJLUQgc3VibWl0dGVkCj4gUGFyYTogPGFiZmFiQGlldGYub3JnPgo+ IAo+IEhpIGFsbCwKPiAKPiBJIHZvbHVudGVlcmVkIHRvIHB1bGwgdG9nZXRoZXIgdGhlIGRvY3Vt ZW50IGluIHRoZSBhYmZhYiBjaGFydGVyIGFyb3VuZCB1c2FiaWxpdHkgb2YgYWJmYWIgdGVjaG5v bG9naWVzLiBJJ3ZlIGp1c3QgcG9zdGVkIGEgLTAwIGRyYWZ0IG9mIHRoZSBkb2MsIHdoaWNoIGNh biBiZSBmb3VuZCBoZXJlOgo+IAo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc21pdGgt YWJmYWItdXNhYmlsaXR5LXVpLWNvbnNpZGVyYXRpb25zLTAwLnR4dAo+IAo+IEF0IHRoZSBtb21l bnQsIGl0J3MgcHJldHR5IHJvdWdoIGFuZCByZWFkeSBhbmQgaXMgbW9yZSBvZiBhIHN0cmF3IG1h biBhcm91bmQgc3RydWN0dXJlIGFuZCB0eXBlIG9mIGNvbnRlbnQgdGhhbiBhbnl0aGluZyBlbHNl LiBZb3UgY2FuIGNvbnNpZGVyIGV2ZXJ5IHNpbmdsZSBwYXJhZ3JhcGggYXMgInRvZG8iLgo+IAo+ IEkndmUgc3BsaXQgdGhlIGRvY3VtZW50IHVwIGludG8gd2hhdCBJIHNlZSBhcyB0aGUgdGhyZWUg bWFpbiBhcmVhcyBvZiB1c2FiaWxpdHkgb2YgYSBjbGllbnQgdGhhdCBoZWxwcyB1c2VycyBwZXJm b3JtIGFiZmFiIG1hZ2ljIC0gbWFuYWdpbmcgaWRlbnRpdGllcywgbWFuYWdpbmcgc2VydmljZSB0 byBpZGVudGl0eSBtYXBwaW5ncywgYW5kIGhhbmRsaW5nIGVycm9ycy4gRWFjaCBhcmVhIGRlZmlu aXRlbHkgbmVlZHMgYSBsb3QgbW9yZSB3b3JrLgo+IAo+IFNvIHBsZWFzZSwgYWxsIHJldmlld3Mg YW5kIGNvbW1lbnRzIG1vc3Qgd2VsY29tZS4gVXNhYmlsaXR5IGlzIG9uZSBvZiB0aG9zZSBwYXJ0 aWN1bGFybHkgdGhvcm55IGFyZWFzIHRoYXQgaXMgaGFyZCB0byB0aWUgZG93biwgYnV0IHdpbGwg cXVpdGUgbGlrZWx5IG1ha2Ugb3IgYnJlYWsgdGhpcyB0ZWNobm9sb2d5IHdoZW4gaXQgY29tZXMg dG8gdXNlciBhY2NlcHRhbmNlLCBzbyBJIHRoaW5rIGl0J3MgcHJldHR5IGltcG9ydGFudC4KPiAK PiBJIHdpbGwgZGVmaW5pdGVseSBiZSBoYXJhc3NpbmcgdGhvc2Ugb2YgeW91IHdobyBoYXZlIGV4 cHJlc3NlZCBhbiBpbnRlcmVzdCAob3IgZ290IHNoYW5naGFpZWQgaW50byBiZWluZyBpbnRlcmVz dGVkKSBvdmVyIHRoZSBjb21pbmcgbW9udGggb3Igc28gZm9yIGZlZWRiYWNrIGFuZCBzdWdnZXN0 aW9ucyA6LSkuCj4gCj4gS2luZCBSZWdhcmRzLAo+IFJoeXMuCj4gLS0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4gRHIgUmh5cyBTbWl0aCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZTogc21p dGhAY2FyZGlmZi5hYy51awo+IEVuZ2luZWVyaW5nIENvbnN1bHRhbnQ6IElkZW50aXR5ICYgQWNj ZXNzIE1hbmFnZW1lbnQgIChHUEc6MHhERTJGMDI0QykKPiBJbmZvcm1hdGlvbiBTZXJ2aWNlcywK PiBDYXJkaWZmIFVuaXZlcnNpdHksICAgICAgICAgICAgICAgICAgICAgICAgICAgIHQ6ICs0NCAo MCkgMjkgMjA4NyAwMTI2Cj4gMzktNDEgUGFyayBQbGFjZSwgQ2FyZGlmZiwgICAgICAgICAgICAg ICAgICAgICBmOiArNDQgKDApIDI5IDIwODcgNDI4NQo+IENGMTAgM0JCLCBVbml0ZWQgS2luZ2Rv bS4gICAgICAgICAgICAgICAgICAgICAgbTogKzQ0ICgwKSA3OTY4IDA4NyA4MjEKPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiBhYmZhYiBtYWlsaW5nIGxpc3QKPiBhYmZhYkBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWJmYWIKPiAKPiAKCi0tCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KRHIg Umh5cyBTbWl0aCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZTogc21pdGhAY2Fy ZGlmZi5hYy51awpFbmdpbmVlcmluZyBDb25zdWx0YW50OiBJZGVudGl0eSAmIEFjY2VzcyBNYW5h Z2VtZW50ICAoR1BHOjB4REUyRjAyNEMpCkluZm9ybWF0aW9uIFNlcnZpY2VzLApDYXJkaWZmIFVu aXZlcnNpdHksICAgICAgICAgICAgICAgICAgICAgICAgICAgIHQ6ICs0NCAoMCkgMjkgMjA4NyAw MTI2CjM5LTQxIFBhcmsgUGxhY2UsIENhcmRpZmYsICAgICAgICAgICAgICAgICAgICAgZjogKzQ0 ICgwKSAyOSAyMDg3IDQyODUKQ0YxMCAzQkIsIFVuaXRlZCBLaW5nZG9tLiAgICAgICAgICAgICAg ICAgICAgICBtOiArNDQgKDApIDc5NjggMDg3IDgyMQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgoKCg== ------=_Part_0_1309879575828 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T2suIDxicj48YnI+QnV0IHlvdSBzaG91bGQgbm90IHN0b3JlIHRoZSBwYXNzcGhyYXNlLiBJdCBz aG91bGQgYmUgaW4geW91ciBoZWFkIDopPGJyPjxicj5FbnZpYWRvIGRlc2RlIG1pIEhUQzxicj48 YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5EZTogJnF1b3Q7Umh5cyBTbWl0aCZxdW90 OyAmbHQ7c21pdGhAY2FyZGlmZi5hYy51ayZndDs8YnI+RmVjaGE6IG1hci4sIGp1bC4gNSwgMjAx MSAxNzoxNzxicj5Bc3VudG86IFthYmZhYl0gRmlyc3QgZHJhZnQgb2YgVXNhYmlsaXR5IEktRCBz dWJtaXR0ZWQ8YnI+UGFyYTogJmx0O2dhYmlsbUB1bS5lcyZndDs8YnI+Q0M6ICZsdDthYmZhYkBp ZXRmLm9yZyZndDs8YnI+PGJyPjxicj5JIGd1ZXNzIHByb3RlY3RpbmcgdGhlIGlkZW50aXR5IHNl bGVjdG9yL2NvbnRhaW5lciB3aXRoIGEgcGFzc3BocmFzZSBpcyBkZWZpbml0ZWx5IGEgcG9zc2li aWxpdHkgc29tZW9uZSBpbXBsZW1lbnRpbmcgc3VjaCBhIGJlYXN0IHdvdWxkIGNvbnNpZGVyLCBh bmQgdGhlcmVmb3JlIHVzYWJpbGl0eSBhc3BlY3RzIHNob3VsZCBiZSBkaXNjdXNzZWQsIHNvIHNo b3VsZCBwcm9iYWJseSBiZSBpbiB0aGUgbmV4dCBkcmFmdC48YnI+PGJyPkhvdyBzdWNoIGEgcGFz c3BocmFzZSB3b3VsZCBiZSBzdG9yZWQgc2VjdXJlbHkgd291bGQgYmUsIG9mIGNvdXJzZSwgaW1w bGVtZW50YXRpb24gc3BlY2lmaWMgYW5kIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2MgSSB0aGlu ay4uLjxicj48YnI+Ui48YnI+PGJyPjxicj5PbiA1IEp1bCAyMDExLCBhdCAxNTo0MywgZ2FiaWxt QHVtLmVzIHdyb3RlOjxicj48YnI+Jmd0OyBIaS4gPGJyPiZndDsgPGJyPiZndDsgSXMgdGhlIHBh c3N3b3JkIG9yIHRoZSBpZGVudGl0eSBjb250YWluZXIgcHJvdGVjdGVkIGJ5IHNvbWUgcGFzc3Bo cmFzZT8gSSBzdXBwb3NlIGl0IGlzIG5vdCBzdG9yZWQgaW4gY2xlYXIgdGV4dC48YnI+Jmd0OyA8 YnI+Jmd0OyBSZWdhcmRzLCBHYWJpIDxicj4mZ3Q7IDxicj4mZ3Q7IEVudmlhZG8gZGVzZGUgbWkg SFRDPGJyPiZndDsgPGJyPiZndDsgLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4mZ3Q7IERl OiAmcXVvdDtSaHlzIFNtaXRoJnF1b3Q7ICZsdDtzbWl0aEBjYXJkaWZmLmFjLnVrJmd0Ozxicj4m Z3Q7IEZlY2hhOiBsdW4uLCBqdWwuIDQsIDIwMTEgMjA6MDc8YnI+Jmd0OyBBc3VudG86IFthYmZh Yl0gRmlyc3QgZHJhZnQgb2YgVXNhYmlsaXR5IEktRCBzdWJtaXR0ZWQ8YnI+Jmd0OyBQYXJhOiAm bHQ7YWJmYWJAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsgPGJyPiZndDsgSGkgYWxsLDxicj4mZ3Q7IDxi cj4mZ3Q7IEkgdm9sdW50ZWVyZWQgdG8gcHVsbCB0b2dldGhlciB0aGUgZG9jdW1lbnQgaW4gdGhl IGFiZmFiIGNoYXJ0ZXIgYXJvdW5kIHVzYWJpbGl0eSBvZiBhYmZhYiB0ZWNobm9sb2dpZXMuIEkm IzM5O3ZlIGp1c3QgcG9zdGVkIGEgLTAwIGRyYWZ0IG9mIHRoZSBkb2MsIHdoaWNoIGNhbiBiZSBm b3VuZCBoZXJlOjxicj4mZ3Q7IDxicj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtc21pdGgtYWJmYWItdXNhYmlsaXR5LXVpLWNvbnNpZGVyYXRpb25zLTAwLnR4dCI+ aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zbWl0aC1hYmZhYi11c2FiaWxpdHktdWktY29u c2lkZXJhdGlvbnMtMDAudHh0PC9hPjxicj4mZ3Q7IDxicj4mZ3Q7IEF0IHRoZSBtb21lbnQsIGl0 JiMzOTtzIHByZXR0eSByb3VnaCBhbmQgcmVhZHkgYW5kIGlzIG1vcmUgb2YgYSBzdHJhdyBtYW4g YXJvdW5kIHN0cnVjdHVyZSBhbmQgdHlwZSBvZiBjb250ZW50IHRoYW4gYW55dGhpbmcgZWxzZS4g WW91IGNhbiBjb25zaWRlciBldmVyeSBzaW5nbGUgcGFyYWdyYXBoIGFzICZxdW90O3RvZG8mcXVv dDsuPGJyPiZndDsgPGJyPiZndDsgSSYjMzk7dmUgc3BsaXQgdGhlIGRvY3VtZW50IHVwIGludG8g d2hhdCBJIHNlZSBhcyB0aGUgdGhyZWUgbWFpbiBhcmVhcyBvZiB1c2FiaWxpdHkgb2YgYSBjbGll bnQgdGhhdCBoZWxwcyB1c2VycyBwZXJmb3JtIGFiZmFiIG1hZ2ljIC0gbWFuYWdpbmcgaWRlbnRp dGllcywgbWFuYWdpbmcgc2VydmljZSB0byBpZGVudGl0eSBtYXBwaW5ncywgYW5kIGhhbmRsaW5n IGVycm9ycy4gRWFjaCBhcmVhIGRlZmluaXRlbHkgbmVlZHMgYSBsb3QgbW9yZSB3b3JrLjxicj4m Z3Q7IDxicj4mZ3Q7IFNvIHBsZWFzZSwgYWxsIHJldmlld3MgYW5kIGNvbW1lbnRzIG1vc3Qgd2Vs Y29tZS4gVXNhYmlsaXR5IGlzIG9uZSBvZiB0aG9zZSBwYXJ0aWN1bGFybHkgdGhvcm55IGFyZWFz IHRoYXQgaXMgaGFyZCB0byB0aWUgZG93biwgYnV0IHdpbGwgcXVpdGUgbGlrZWx5IG1ha2Ugb3Ig YnJlYWsgdGhpcyB0ZWNobm9sb2d5IHdoZW4gaXQgY29tZXMgdG8gdXNlciBhY2NlcHRhbmNlLCBz byBJIHRoaW5rIGl0JiMzOTtzIHByZXR0eSBpbXBvcnRhbnQuPGJyPiZndDsgPGJyPiZndDsgSSB3 aWxsIGRlZmluaXRlbHkgYmUgaGFyYXNzaW5nIHRob3NlIG9mIHlvdSB3aG8gaGF2ZSBleHByZXNz ZWQgYW4gaW50ZXJlc3QgKG9yIGdvdCBzaGFuZ2hhaWVkIGludG8gYmVpbmcgaW50ZXJlc3RlZCkg b3ZlciB0aGUgY29taW5nIG1vbnRoIG9yIHNvIGZvciBmZWVkYmFjayBhbmQgc3VnZ2VzdGlvbnMg Oi0pLjxicj4mZ3Q7IDxicj4mZ3Q7IEtpbmQgUmVnYXJkcyw8YnI+Jmd0OyBSaHlzLjxicj4mZ3Q7 IC0tPGJyPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7IERyIFJoeXMgU21pdGggJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlOiBz bWl0aEBjYXJkaWZmLmFjLnVrPGJyPiZndDsgRW5naW5lZXJpbmcgQ29uc3VsdGFudDogSWRlbnRp dHkgJmFtcDsgQWNjZXNzIE1hbmFnZW1lbnQgJm5ic3A7KEdQRzoweERFMkYwMjRDKTxicj4mZ3Q7 IEluZm9ybWF0aW9uIFNlcnZpY2VzLDxicj4mZ3Q7IENhcmRpZmYgVW5pdmVyc2l0eSwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Q6ICs0NCAoMCkgMjkgMjA4NyAwMTI2 PGJyPiZndDsgMzktNDEgUGFyayBQbGFjZSwgQ2FyZGlmZiwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGY6ICs0NCAo MCkgMjkgMjA4NyA0Mjg1PGJyPiZndDsgQ0YxMCAzQkIsIFVuaXRlZCBLaW5nZG9tLiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7bTogKzQ0ICgwKSA3OTY4IDA4NyA4MjE8YnI+Jmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPiZndDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyBhYmZhYiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBhYmZhYkBpZXRmLm9y Zzxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWJmYWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWJmYWI8L2E+PGJy PiZndDsgPGJyPiZndDsgPGJyPjxicj4tLTxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkRyIFJoeXMgU21p dGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBlOiBzbWl0aEBjYXJkaWZmLmFjLnVrPGJyPkVuZ2luZWVyaW5nIENvbnN1bHRhbnQ6 IElkZW50aXR5ICZhbXA7IEFjY2VzcyBNYW5hZ2VtZW50ICZuYnNwOyhHUEc6MHhERTJGMDI0Qyk8 YnI+SW5mb3JtYXRpb24gU2VydmljZXMsPGJyPkNhcmRpZmYgVW5pdmVyc2l0eSwgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Q6ICs0NCAoMCkgMjkgMjA4NyAwMTI2PGJy PjM5LTQxIFBhcmsgUGxhY2UsIENhcmRpZmYsICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmOiArNDQgKDApIDI5IDIw ODcgNDI4NTxicj5DRjEwIDNCQiwgVW5pdGVkIEtpbmdkb20uICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtt OiArNDQgKDApIDc5NjggMDg3IDgyMTxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPjxicj48YnI+PGJyPjxi cj48YnI+ ------=_Part_0_1309879575828-- From smith@Cardiff.ac.uk Tue Jul 5 08:38:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FBB11E80E5 for ; Tue, 5 Jul 2011 08:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQEmtew5asc9 for ; Tue, 5 Jul 2011 08:38:43 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id BF6E521F8505 for ; Tue, 5 Jul 2011 08:38:42 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Qe7hy-0005Sx-5T; Tue, 05 Jul 2011 16:38:42 +0100 Received: from [86.184.20.181] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qe7hy-0004o9-0f; Tue, 05 Jul 2011 16:38:42 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rhys Smith In-Reply-To: <20110705152555.566EE53831@xenon11.um.es> Date: Tue, 5 Jul 2011 16:38:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110705152555.566EE53831@xenon11.um.es> To: gabilm@um.es X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] First draft of Usability I-D submitted 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 Jul 2011 15:38:43 -0000 Personally I store all passphrases in my head encrypted with ECC. Makes = typing it in a very long process as I mentally decrypt with the help of = post-it notes each time I need to use them... ;-) R. On 5 Jul 2011, at 16:26, gabilm@um.es wrote: > Ok.=20 >=20 > But you should not store the passphrase. It should be in your head :) >=20 > Enviado desde mi HTC >=20 > ----- Reply message ----- > De: "Rhys Smith" > Fecha: mar., jul. 5, 2011 17:17 > Asunto: [abfab] First draft of Usability I-D submitted > Para: > CC: >=20 >=20 > I guess protecting the identity selector/container with a passphrase = is definitely a possibility someone implementing such a beast would = consider, and therefore usability aspects should be discussed, so should = probably be in the next draft. >=20 > How such a passphrase would be stored securely would be, of course, = implementation specific and out of scope for this doc I think... >=20 > R. >=20 >=20 > On 5 Jul 2011, at 15:43, gabilm@um.es wrote: >=20 > > Hi.=20 > >=20 > > Is the password or the identity container protected by some = passphrase? I suppose it is not stored in clear text. > >=20 > > Regards, Gabi=20 > >=20 > > Enviado desde mi HTC > >=20 > > ----- Reply message ----- > > De: "Rhys Smith" > > Fecha: lun., jul. 4, 2011 20:07 > > Asunto: [abfab] First draft of Usability I-D submitted > > Para: > >=20 > > Hi all, > >=20 > > I volunteered to pull together the document in the abfab charter = around usability of abfab technologies. I've just posted a -00 draft of = the doc, which can be found here: > >=20 > > = http://www.ietf.org/id/draft-smith-abfab-usability-ui-considerations-00.tx= t > >=20 > > At the moment, it's pretty rough and ready and is more of a straw = man around structure and type of content than anything else. You can = consider every single paragraph as "todo". > >=20 > > I've split the document up into what I see as the three main areas = of usability of a client that helps users perform abfab magic - managing = identities, managing service to identity mappings, and handling errors. = Each area definitely needs a lot more work. > >=20 > > So please, all reviews and comments most welcome. Usability is one = of those particularly thorny areas that is hard to tie down, but will = quite likely make or break this technology when it comes to user = acceptance, so I think it's pretty important. > >=20 > > I will definitely be harassing those of you who have expressed an = interest (or got shanghaied into being interested) over the coming month = or so for feedback and suggestions :-). > >=20 > > Kind Regards, > > Rhys. > > -- > > = ---------------------------------------------------------------------- > > Dr Rhys Smith e: = smith@cardiff.ac.uk > > Engineering Consultant: Identity & Access Management = (GPG:0xDE2F024C) > > Information Services, > > Cardiff University, t: +44 (0) 29 2087 = 0126 > > 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 = 4285 > > CF10 3BB, United Kingdom. m: +44 (0) 7968 087 = 821 > > = ---------------------------------------------------------------------- > >=20 > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab > >=20 > >=20 >=20 > -- > ---------------------------------------------------------------------- > Dr Rhys Smith e: smith@cardiff.ac.uk > Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) > Information Services, > Cardiff University, t: +44 (0) 29 2087 0126 > 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 > CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 > ---------------------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From margaretw42@gmail.com Tue Jul 5 09:15:32 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4886122800F for ; Tue, 5 Jul 2011 09:15:32 -0700 (PDT) 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=[AWL=-0.001, 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 tgZdbZ90i+5p for ; Tue, 5 Jul 2011 09:15:31 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCBD228022 for ; Tue, 5 Jul 2011 09:15:27 -0700 (PDT) Received: by gwb20 with SMTP id 20so742767gwb.31 for ; Tue, 05 Jul 2011 09:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=ENDFHyXe42jKmg6WUMKVKNwwQmRbFzJCw0d6jq1FcQw=; b=fay4KRTnG2eCeSzZuL5j9zfCahzL0otuz7sAWg5eBOz3FX1AEjC1z/0Uqhxa1dwv1v yVwQK7HbfcpYnBK+3wZz78JtV8+FrTnW1r04bi5X8IvsAFLd5HXxAwKQoEFxQyD2u7eX 1QqBVc/Sh/EKYzsa5igaQc4McV7x+TfAQx5/I= Received: by 10.236.191.164 with SMTP id g24mr1682826yhn.397.1309882526380; Tue, 05 Jul 2011 09:15:26 -0700 (PDT) Received: from [192.168.1.109] (cpe-72-227-97-191.maine.res.rr.com [72.227.97.191]) by mx.google.com with ESMTPS id f4sm1808890yhn.83.2011.07.05.09.15.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 09:15:23 -0700 (PDT) From: Margaret Wasserman Content-Type: multipart/alternative; boundary=Apple-Mail-10-862839169 Date: Tue, 5 Jul 2011 12:15:20 -0400 Message-Id: <250B82A0-6992-48F2-AAC3-282265855F8B@gmail.com> To: MOONSHOT-COMMUNITY@JISCMAIL.AC.UK, abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 05 Jul 2011 09:25:12 -0700 Subject: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 16:15:32 -0000 --Apple-Mail-10-862839169 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I posted a new Internet-Draft yesterday on ABFAB Multihop Federations. =20= I had to submit the draft via e-mail because of a problem using the ID = submission tool, and it doesn't seem to have been posted to the = Internet-Drafts archive yet. I have posted it on the Project Moonshot = site, though, and it can be found here: = http://www.project-moonshot.org/sites/default/files/draft-mrw-abfab-multih= op-fed-00.txt The abstract for this draft is: Abstract This document describes a mechanism for establishing trust across a multihop federation within the Application Bridging for Federation Beyond the Wed (ABFAB) framework. This document introduces a new ABFAB entity, the Trust Router. Trust Routers exchange information about the availability of Trust Paths across a multiphop federation. They can be queried by a Relying Party to obtain the best Trust Path to reach a RADIUS or RADSEC server in a given realm. They also provide temporary identities that can be used by a Relying Party to traverse a Trust Path. This document is currently limited to discussing a proposed mechanism to achieve a multihop federation in the ABFAB framework. Later versions of this document (or companion documents) will describe the protocols and algorithms in more detail. The document doesn't, yet, contain a full protocol specification, just = a high-level "boxes and arrows" description of how a multihop federation could work. This = draft intentionally subsumes the role of the Key Negotiation Protocol = (KNP) into a new ABFAB entity called a Trust Router. Hopefully this will serve as a useful starting place for further = discussion. Feedback will be appreciated! Margaret --Apple-Mail-10-862839169 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Hi All,

I posted a new Internet-Draft yesterday on ABFAB Multihop Federations.  

I had to submit the draft via e-mail because of a problem using the ID submission tool, and it doesn't seem to have been posted to the Internet-Drafts archive yet.  I have posted it on the Project Moonshot site, though, and it can be found here:


The abstract for this draft is:
Abstract

   This document describes a mechanism for establishing trust across a
   multihop federation within the Application Bridging for Federation
   Beyond the Wed (ABFAB) framework.

   This document introduces a new ABFAB entity, the Trust Router.  Trust
   Routers exchange information about the availability of Trust Paths
   across a multiphop federation.  They can be queried by a Relying
   Party to obtain the best Trust Path to reach a RADIUS or RADSEC
   server in a given realm.  They also provide temporary identities that
   can be used by a Relying Party to traverse a Trust Path.

   This document is currently limited to discussing a proposed mechanism
   to achieve a multihop federation in the ABFAB framework.  Later
   versions of this document (or companion documents) will describe the
   protocols and algorithms in more detail.
The document doesn't, yet, contain a full protocol specification,  just a high-level "boxes and
arrows" description of how a multihop federation could work.   This draft intentionally subsumes the role of the Key Negotiation Protocol (KNP) into a new ABFAB entity called a Trust Router.

Hopefully this will serve as a useful starting place for further discussion.  Feedback will be appreciated!

Margaret





--Apple-Mail-10-862839169-- From Josh.Howlett@ja.net Tue Jul 5 13:19:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB73821F890A for ; Tue, 5 Jul 2011 13:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.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 MEhgt-KS7k-R for ; Tue, 5 Jul 2011 13:19:42 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57321F8903 for ; Tue, 5 Jul 2011 13:19:41 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 42BBA4A6B6C_E1371D8B; Tue, 5 Jul 2011 20:19:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 270D64A6B39_E1371D8F; Tue, 5 Jul 2011 20:19:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Tue, 5 Jul 2011 21:18:38 +0100 From: Josh Howlett To: Margaret Wasserman , "abfab@ietf.org" , "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" Thread-Topic: [abfab] New Internet-Draft on Multihop Federations Thread-Index: AQHMOzAN9g27fH9tQUi8rcHoOqA795TeK1SA Date: Tue, 5 Jul 2011 20:18:37 +0000 Message-ID: In-Reply-To: <250B82A0-6992-48F2-AAC3-282265855F8B@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <57A1591C31362B42B2D95B3FA3C3626C@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 20:19:43 -0000 Hi Margaret, Some feedback, as requested: - Section 1 Sorry if this seems trivial! The term 'federation' is quite overloaded and means different things to different people. I suggest explicitly calling out what I think you mean, which is a 'multihop AAA fabric'. It's an ugly circumlocution, but at least it can't be misunderstood or (worse) misinterpreted. - Section 1.1 Step 3. Substitute 'does not have direct access' with 'does not share a relationship with'? 'Access' is perhaps too ambiguous. Steps 4-6. I think it would be useful to explain why the RP is using an identity to "contact" the trust routers in the consecutive realms. It might not be obvious to the reader that the RP is building a transitive chain of trust by walking the trust path. I suggest explaining this right at the start of section 1.1. Obviously an understanding of KNP is an essential part of this. I wonder if it's worth including some discussion of KNP. On a more general note, what is your opinion as to how this draft and KNP inter-relate - should they remain distinct documents, or be combined somehow? (Great ASCII art in that figure BTW) - Section 4 Why can't realm names be hierarchal? It's true that the NAI has no concept of a hierarchal realm component, but couldn't we choose to interpret a hierarchy here? Trust Path aggregation could be useful. - Section 5 Why query (pull) rather than push? One drawback with pull, perhaps, is that nervous relying parties will tend towards polling as fast as they can, rather than as regularly as the upstream trust router itself receives updates from its peers (which would be more efficient). Hope that helps, Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From internet-drafts@ietf.org Tue Jul 5 13:50:39 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E58D21F8934; Tue, 5 Jul 2011 13:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 elpdUz8ERnTP; Tue, 5 Jul 2011 13:50:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDB121F892D; Tue, 5 Jul 2011 13:50:38 -0700 (PDT) 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: 3.55 Message-ID: <20110705205038.19999.52894.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 13:50:38 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-usecases-01.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, 05 Jul 2011 20:50:39 -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 Ac= cess Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond web (AB= FAB) Use Cases Author(s) : Rhys Smith Filename : draft-ietf-abfab-usecases-01.txt Pages : 11 Date : 2011-07-05 Federated authentication is most commonly associated with Web-based services, but there is growing interest in the application of federated authentication for non-Web services. The goal of this document is to document the wide variety of contexts where the user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-usecases-01.txt From smith@Cardiff.ac.uk Tue Jul 5 13:54:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA821F891C for ; Tue, 5 Jul 2011 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRPLKkTkQd7M for ; Tue, 5 Jul 2011 13:54:09 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 945E421F88D5 for ; Tue, 5 Jul 2011 13:54:09 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QeCdE-0004BC-S1 for abfab@ietf.org; Tue, 05 Jul 2011 21:54:08 +0100 Received: from [86.184.20.181] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QeCdE-0001h0-QV for abfab@ietf.org; Tue, 05 Jul 2011 21:54:08 +0100 From: Rhys Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 21:54:02 +0100 References: <20110705205038.19999.2458.idtracker@ietfa.amsl.com> To: abfab@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] New version (-01) of use case I-D 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 Jul 2011 20:54:10 -0000 Just posted a -01 of the use case doc. See App A for details of changes = - added a few use cases as suggested during and since the last IETF = gathering, and rewording some bits here and there. Still some to do... = Comments obviously welcome! http://www.ietf.org/id/draft-ietf-abfab-usecases-01.txt Regards, Rhys. -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From nico@cryptonector.com Tue Jul 5 15:32:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D821F87B2 for ; Tue, 5 Jul 2011 15:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 QMdB5Gj7yY0y for ; Tue, 5 Jul 2011 15:32:28 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 852B021F87B1 for ; Tue, 5 Jul 2011 15:32:28 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 5A1A86B0078 for ; Tue, 5 Jul 2011 15:32:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XxgeknTYGctaEaslpeFDDHPXqFEFtPF35z9eoK3n5pcX GU3hE/V1QShqWs1vjsFmF1gUOmq8DFudomR906n2iBFk/oIsYJbXA0MmOXH1zZOq WfESL20RJu65g/dhsdtdT4uMhpNth6N4D7YceSEyXImmbar8vfx9//ROEQDttac= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=NJw1Ac+3lad1ApHiUllulh/2hdw=; b=pOUBr4huRPH xccIYwV29tSpq1P1z72+RXgmhHhRtrOngolKx3fiIdAe5HZg3XMmEGLHqwDXn4a1 m69OrSJkW1lJbBXTrWjrxsUeWZw2imXj3RcAQt58YkFNX0+iVCR4gh0F2x7dHWy0 /Lp/IBx2Zdfz/TIot6JLYEj4+zyQBWUY= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 3A8F46B0059 for ; Tue, 5 Jul 2011 15:32:28 -0700 (PDT) Received: by pzk5 with SMTP id 5so2702040pzk.31 for ; Tue, 05 Jul 2011 15:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.197 with SMTP id v5mr9514022pbo.387.1309905147851; Tue, 05 Jul 2011 15:32:27 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Tue, 5 Jul 2011 15:32:27 -0700 (PDT) In-Reply-To: References: <250B82A0-6992-48F2-AAC3-282265855F8B@gmail.com> Date: Tue, 5 Jul 2011 17:32:27 -0500 Message-ID: From: Nico Williams To: Josh Howlett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , "abfab@ietf.org" , Margaret Wasserman Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 22:32:29 -0000 On Tue, Jul 5, 2011 at 3:18 PM, Josh Howlett wrote: > =C2=A0- Section 1 > > Sorry if this seems trivial! The term 'federation' is quite overloaded an= d > means different things to different people. I suggest explicitly calling > out what I think you mean, which is a 'multihop AAA fabric'. It's an ugly > circumlocution, but at least it can't be misunderstood or (worse) > misinterpreted. "Federation" is a difficult word. Would it be fair to say here that "federation" means "set of trust cross-domain/realm paths"? Nico -- From hartmans@painless-security.com Tue Jul 5 15:53:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8079D21F8922 for ; Tue, 5 Jul 2011 15:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls8BFIIC00X4 for ; Tue, 5 Jul 2011 15:53:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 09E7621F88FA for ; Tue, 5 Jul 2011 15:53:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5D5CD202D8; Tue, 5 Jul 2011 18:53:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 97142437D; Tue, 5 Jul 2011 18:53:38 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <250B82A0-6992-48F2-AAC3-282265855F8B@gmail.com> Date: Tue, 05 Jul 2011 18:53:38 -0400 In-Reply-To: (Nico Williams's message of "Tue, 5 Jul 2011 17:32:27 -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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Margaret Wasserman , "abfab@ietf.org" , "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 22:53:42 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Tue, Jul 5, 2011 at 3:18 PM, Josh Howlett wrote: >>  - Section 1 >> >> Sorry if this seems trivial! The term 'federation' is quite overloaded and >> means different things to different people. I suggest explicitly calling >> out what I think you mean, which is a 'multihop AAA fabric'. It's an ugly >> circumlocution, but at least it can't be misunderstood or (worse) >> misinterpreted. Nico> "Federation" is a difficult word. Would it be fair to say here that Nico> "federation" means "set of trust cross-domain/realm paths"? I think we should be consistent with the proposed abfab architecture draft. That document uses the term federation. I think we should too and refer back to that document for its meaning. From gabilm@um.es Wed Jul 6 01:28:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0A121F869A for ; Wed, 6 Jul 2011 01:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 74rpx0uV48Qo for ; Wed, 6 Jul 2011 01:28:55 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBDC21F8419 for ; Wed, 6 Jul 2011 01:28:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8F8315D5C2; Wed, 6 Jul 2011 10:28:52 +0200 (CEST) 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 5NaCeBaY+tSj; Wed, 6 Jul 2011 10:28:52 +0200 (CEST) Received: from inf-205-135.inf.um.es (inf-205-135.inf.um.es [155.54.205.135]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id 9D99C5D5C6; Wed, 6 Jul 2011 10:28:47 +0200 (CEST) Message-ID: <4E141D7D.6000504@um.es> Date: Wed, 06 Jul 2011 10:31:57 +0200 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Margaret Wasserman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" , "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 08:28:56 -0000 Hi, El 05/07/11 22:18, Josh Howlett escribió: > > Steps 4-6. I think it would be useful to explain why the RP is using an > identity to "contact" the trust routers in the consecutive realms. It > might not be obvious to the reader that the RP is building a transitive > chain of trust by walking the trust path. I suggest explaining this right > at the start of section 1.1. > > Obviously an understanding of KNP is an essential part of this. I wonder > if it's worth including some discussion of KNP. On a more general note, > what is your opinion as to how this draft and KNP inter-relate - should > they remain distinct documents, or be combined somehow? > A few comments: Section 1: - I think this document should include, in section 1 or in a motivation section, a clear text of why it is necessary this multihop infrastructure. I mean, What is the target problem or use-case to be solved? For people who has not read before this idea is very difficult to catch the motivation. - It is not clear what the Trust Router is. Advanced production routers running in institutions? or Is it a new entity every institution should deploy? - Does the term Trust Path refer to the AAA path/TRs path/mixed? Section 1.1. - I think the RADIUS or RadSec server should be included in the diagram (even if it is co-located with the idP) - " 4. The Relying Party contacts a trust router in Realm B (using its permanent identity in Realm A)" So Trust Router in realm B should "delegate" the authentication of RP to realm A, an so on ....? Section 1.2 Does the term Trust Router Protocol refer to a "secure" routing protocol? Section 4: - The list of security properties required by the Trust Routers would help to a better understanding of the protocol :) Sections 5 and 6: - Do you have in mind some transport and communication protocols for the Trust Path Query and Temporaly Identity Request? I understand this document describes the general idea, the questions are just to know if you have in mind some answers already thought. Why does the RP ask every router in the federation? I mean, if requesting TR A, which by means of some "advanced" routing protocol is able to know the better path from A to D, after the first request the RP knows TR D or even idP. Section 6. "When a Temporary Identity is requested, a Trust Router will provision a new identity in its local RADIUS infrastructure that can be used by the Relying Party to communicate with the Trust Router or RADIUS/RADSEC server that represents the next step in the Trust Path." Then, every institution hosts a TR and a Radius/RadSec server, this should be clarified in the diagram and the introduction. It is not clear for me the relationship between Trust Path Queries and Temporaly Identity Requests. When are they sent from the RP to the TR? What is the global number of message exchanged between RP, TRs, RADIUs, etc..? Sorry, maybe these are fool questions, as said before, I understand this is the general idea, I just try to understand it :) Thanks in advance and regards, Gabi. -- ---------------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From gabilm@um.es Wed Jul 6 01:38:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8121F8680 for ; Wed, 6 Jul 2011 01:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 t52WV12STUUq for ; Wed, 6 Jul 2011 01:38:55 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id EFC9E21F8666 for ; Wed, 6 Jul 2011 01:38:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 7F7815D651; Wed, 6 Jul 2011 10:38:52 +0200 (CEST) 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 TNJC74Crb00T; Wed, 6 Jul 2011 10:38:51 +0200 (CEST) Received: from inf-205-135.inf.um.es (inf-205-135.inf.um.es [155.54.205.135]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPSA id 7F05E5D614; Wed, 6 Jul 2011 10:38:49 +0200 (CEST) Message-ID: <4E141FD8.6020704@um.es> Date: Wed, 06 Jul 2011 10:42:00 +0200 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Rhys Smith References: <20110705205038.19999.2458.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------050203070607060107020906" Cc: abfab@ietf.org Subject: Re: [abfab] New version (-01) of use case I-D 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 Jul 2011 08:38:57 -0000 This is a multi-part message in MIME format. --------------050203070607060107020906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi Rhys, Alejandro sent a few months ago the campus use-case. I see it is not included in the -01 version. Just to know whether do you think this case is not interesting for abfab, pending to be added, or it is just a mistake :) Best regards, Gabi. El 05/07/11 22:54, Rhys Smith escribió: > Just posted a -01 of the use case doc. See App A for details of changes - added a few use cases as suggested during and since the last IETF gathering, and rewording some bits here and there. Still some to do... Comments obviously welcome! > > http://www.ietf.org/id/draft-ietf-abfab-usecases-01.txt > > Regards, > Rhys. > -- > ---------------------------------------------------------------------- > Dr Rhys Smith e: smith@cardiff.ac.uk > Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) > Information Services, > Cardiff University, t: +44 (0) 29 2087 0126 > 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 > CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 --------------050203070607060107020906 Content-Type: message/rfc822; name="Mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Mensaje adjunto" Return-Path: X-Original-To: gabilm@um.es Delivered-To: gabilm@pop.um.es Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by myotis22.um.es (Postfix) with ESMTP id CD8AE2FACB for ; Tue, 29 Mar 2011 13:31:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id AC89B5D4B4 for ; Tue, 29 Mar 2011 13:31:00 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-4 required=5 tests=[none] 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 0+Eu7f40rV46 for ; Tue, 29 Mar 2011 13:31:00 +0200 (CEST) Received: from pique.puc.rediris.es (pique.puc.rediris.es [130.206.18.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by xenon13.um.es (Postfix) with ESMTPS id CA8EB5D48A for ; Tue, 29 Mar 2011 13:30:58 +0200 (CEST) Received: from [64.170.98.32] (helo=mail.ietf.org) by pique.puc.rediris.es with esmtp (Exim 4.63) (envelope-from ) id 1Q4X8S-0000P5-Hy; Tue, 29 Mar 2011 13:30:57 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A320028C13D; Tue, 29 Mar 2011 04:29:14 -0700 (PDT) X-Envelope-From: abfab-bounces@ietf.org X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E0A28C0FB for ; Tue, 29 Mar 2011 04:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywHwSplRZQ5I for ; Tue, 29 Mar 2011 04:29:11 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 0DFD13A67C2 for ; Tue, 29 Mar 2011 04:29:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 34B794BB09 for ; Tue, 29 Mar 2011 13:30:45 +0200 (CEST) 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 KiAEvN5Q9OdN for ; Tue, 29 Mar 2011 13:30:42 +0200 (CEST) Received: from [155.54.205.224] (inf-205-224.inf.um.es [155.54.205.224]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id ACACB4B8E6 for ; Tue, 29 Mar 2011 13:30:41 +0200 (CEST) Message-ID: <4D91C2E3.70608@um.es> Date: Tue, 29 Mar 2011 13:30:43 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> In-Reply-To: <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: abfab-bounces@ietf.org Errors-To: abfab-bounces@ietf.org X-Spamina-Bogosity: Ham X-Spamina-History: list, noInbox X-Spamina-Service-Type: pyme X-Spamina-Destination: list, noInbox SGkgUmh5cywKCmZvbGxvd2luZyB5b3UgY2FuIGZpbmQgVU1VJ3MgZmlyc3QgZHJhZnQgZm9yIHRo ZSBjYW1wdXMgdXNlIGNhc2UuIApDb21tZW50cyBhcmUgd2VsY29tZS4KCgpDQU1QVVMgVVNFIENB U0UKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpVbml2ZXJzaXRpZXMgdXN1YWxs eSBvZmZlciBkaWZmZXJlbnQga2luZCBvZiBzZXJ2aWNlcyB0byB0aGVpciBzdHVkZW50cyAKYW5k IHN0YWZmLCByYW5naW5nIGZyb20gYmFzaWMgbmV0d29yayBhY2Nlc3MgdG8gdGhlIG1vcmUgYWR2 YW5jZWQgY2FtcHVzIAppbnRyYW5ldCwgcGFzc2luZyB0aHJvdWdoIHNlcnZpY2VzIHN1Y2ggYXMg cmVtb3RlIGNvbXB1dGluZyBzeXN0ZW1zLCAKc3RvcmFnZSwgbWFpbCBhbmQgcHJpbnRpbmcgc2Vy dmljZXMsIGV0Yy4gQWNjZXNzIGNvbnRyb2wgdG8gdGhlc2UgCnNlcnZpY2VzIGlzIHVzdWFsbHkg bWFuYWdlZCBieSBtZWFucyBvZiBlbmQgdXNlcuKAmXMgbG9naW4gYW5kIHBhc3N3b3JkLgoKQWx0 aG91Z2ggaXQgaXMgZmFpcmx5IGV4dGVuZGVkIHRoYXQgdXNlcnMgY2FuIG1ha2UgdXNlIG9mIHRo ZSBzYW1lIApjcmVkZW50aWFscyB0byBhY2Nlc3MgZGlmZmVyZW50IHNlcnZpY2VzLCB0aGFua3Mg dG8gYSBjZW50cmFsIGlkZW50aXR5IAppbmZvcm1hdGlvbiBzdG9yYWdlIGNlbnRlciB3aXRoaW4g ZWFjaCB1bml2ZXJzaXR5IChlLmcuIExEQVAgb3IgCmRhdGFiYXNlKSwgdGhlIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbSB1c3VhbGx5IGRpZmZlcnMgZm9yIGVhY2ggCnNlcnZpY2UuIFRoaXMgaGV0 ZXJvZ2VuZWl0eSBsZWFkcyB0byBkZXBsb3ltZW50IGFuZCB1c2FiaWxpdHkgcHJvYmxlbXMsIAph cyBtb3N0IG9mIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBmdW5jdGlvbmFs aXR5IG11c3QgYmUgCmltcGxlbWVudGVkIG9uIGVhY2ggc2VydmljZSB0aGF0IHRoZSB1bml2ZXJz aXR5IGRlcGxveXMuIFVzYWJpbGl0eSAKaXNzdWVzIGFyZSByZWxhdGVkIHdpdGggdGhlIGxhY2sg b2YgYSBTaW5nbGUgU2lnbi1PbiAoU1NPKSBzZXJ2aWNlLCAKYXZvaWRpbmcgdXNlcnMgdG8gcmUt aW50cm9kdWNlIHRoZWlyIGNyZWRlbnRpYWxzIG9uIGVhY2ggc2VydmljZSBhY2Nlc3MsIAphbmQg dGhlIGV4aXN0ZW5jZSBvZiBzZXZlcmFsIGNvbmZpZ3VyYXRpb24gcG9pbnRzIHdoZXJlIHRoZSB1 c2VyIG5lZWRzIAp0byBjb25maWd1cmUgYXV0aGVudGljYXRpb24tcmVsYXRlZCBhc3BlY3RzICh3 ZWIgYnJvd3NlciwgbmV0d29yayAKc3VwcGxpY2FudCwgbWFpbCB1c2VyIGFnZW50LCByZW1vdGUg YWNjZXNzIHNvZnR3YXJlLCBldGMuLi4pLgoKVGhlIGlzc3VlcyBkZXNjcmliZWQgYWJvdmUgYXJl IG1vdGl2YXRpbmcgc2VydmljZSBhZG1pbmlzdHJhdG9ycyB0byBsb29rIApmb3IgYWNjZXNzIGNv bnRyb2wgc29sdXRpb25zIHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gYSB3aWRlciByYW5nZSBvZiAK c2VydmljZXMuIEFuIGV4YW1wbGUgb2YgdGhpcyB3b3VsZCBiZSB0aGUgZGVwbG95bWVudCBvZiBD QVMg4oCTIENlbnRyYWwgCkF1dGhlbnRpY2F0aW9uIFNlcnZpY2UgKGh0dHA6Ly93d3cuamFzaWcu b3JnL2NhcykgYXMgYW4gYXV0aGVudGljYXRpb24gCmFuZCBTU08gc29sdXRpb24gc3VpdGFibGUg Zm9yIHdlYiBzZXJ2aWNlcywgb3IgS2VyYmVyb3MgW1JGQyA0MTIwXSwgCmJyb2FkbHkgdXNlZCB0 byBwcm92aWRlIGF1dGhlbnRpY2F0aW9uIGFuZCBTU08gZm9yIHNlcnZpY2VzIGxpa2UgU1NILCAK U01UUCBvciBQT1AuIEhvd2V2ZXIsIGFuIGludGVncmF0ZWQgc29sdXRpb24gdGhhdCBjYW4gYmUg YXBwbGllZCB0byBhIAp3aWRlciByYW5nZSBvZiBzZXJ2aWNlcyBpcyBzdGlsbCBtaXNzaW5nLgoK QmVzaWRlLCBpbiBvcmRlciB0byBoZWxwIG1vYmlsaXR5IG9mIHN0dWRlbnRzIGFuZCBzdGFmZiBi ZXR3ZWVuIApkaWZmZXJlbnQgdW5pdmVyc2l0aWVzLCB0aGVyZSBleGlzdHMgYW4gaW5jcmVhc2lu ZyBpbnRlcmVzdCB0byBwcm92aWRlIAp0aGVzZSBzZXJ2aWNlcyBhbHNvIHRvIHVzZXJzIGNvbWlu ZyBmcm9tIG90aGVyIHVuaXZlcnNpdGllcyBvciAKb3JnYW5pemF0aW9ucy4gVGhlc2UgL2ZvcmVp Z24gL3VzZXJzIHNob3VsZCBiZSBhYmxlIHRvIGFjY2VzcyB0aGUgCnNlcnZpY2VzIGF0IHRoZSAv cmVtb3RlIC9pbnN0aXR1dGlvbiBtYWtpbmcgdXNlIG9mIHRoZSBjcmVkZW50aWFscyAKcHJvdmlk ZWQgYnkgdGhlaXIgL2hvbWUvIFVuaXZlcnNpdHksIHdpdGhvdXQgdGhlIG5lZWQgb2YgY3JlYXRp bmcgYSBuZXcgCnVzZXIgcHJvZmlsZSBmb3IgdGhlbSBpbiB0aGUgdmlzaXRlZCBvbmUuIFRoaXMg aW50ZXJlc3QgZm9yIGZlZGVyYXRlZCAKc2VydmljZXMgaGFzIGFscmVhZHkgYmVlbiBkZW1vbnN0 cmF0ZWQgd2l0aCB0aGUgZXhwYW5zaW9uIG9mIC9lZHVyb2FtIAovKF93d3cuZWR1cm9hbS5vciA8 aHR0cDovL3d3dy5lZHVyb2FtLm9yLz5fZyksIHRoZSBzZWN1cmUgaW50ZXJuYXRpb25hbCAKcm9h bWluZyBuZXR3b3JrIHNlcnZpY2UgdGhhdCBhbGxvd3MgdXNlcnMgYmVsb25naW5nIHRvIG9uZSBp bnN0aXR1dGlvbiAKdG8gZ2V0IG5ldHdvcmsgYWNjZXNzIHdoZW4gdmlzaXRpbmcgYW5vdGhlciBp bnN0aXR1dGlvbi4gVGhpcyBmZWRlcmF0aW9uIAppcyBiYXNlZCBvbiB0aGUgZGVwbG95bWVudCBv ZiBFQVAgKEV4dGVuc2libGUgQXV0aGVudGljYXRpb24gUHJvdG9jb2wpIApmb3IgYXV0aGVudGlj YXRpb24gYW5kIGEgaGllcmFyY2h5IG9mIFJBRElVUyBzZXJ2ZXJzIGZvciBhdXRob3JpemF0aW9u IAphbmQgYWNjb3VudGluZy4gSG93ZXZlciwgZWR1cm9hbSBvbmx5IGNvdmVycyB0aGUgbmV0d29y ayBhY2Nlc3MgY29udHJvbCwgCmJ1dCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGFjY2VzcyBjb250 cm9sIHRvIHVwcGVyIGxheWVyIHNlcnZpY2VzLiAKQmVzaWRlcywgc2V2ZXJhbCBhcHByb2FjaGVz IHRvIGZlZGVyYXRlIHRoZXNlIHVwcGVyIGxheWVyIHNlcnZpY2VzIGV4aXN0IAooZS5nLiBTaGli Ym9sZXRoLCBPcGVuSUQuLi4pLCBhbmQgc29tZSBvZiB0aGVtIGhhdmUgZXZlbiBiZWVuIGRlcGxv eWVkIAppbiBzZXZlcmFsIHVuaXZlcnNpdGllcyB0byBtYW5hZ2UgYWNjZXNzIHRvIHNwZWNpZmlj IHNlcnZpY2VzIFtTSVJdLCBidXQgCnRoZXkgYXJlIGludGVuZGVkIGZvciB3ZWItYmFzZWQgb3Jp ZW50ZWQgc2VydmljZXMgYW5kIGRvIG5vdCBhcHBseSB0byAKb3RoZXIgYXBwbGljYXRpb24gc2Vy dmljZXMuCgpGb3IgZXhhbXBsZSwgc29tZSB1bml2ZXJzaXRpZXMgaGF2ZSBzaG93biBpbnRlcmVz dCBmb3IgdXNpbmcgZmVkZXJhdGVkIApTU0guIFJlZElyaXMgKGh0dHA6Ly93d3cucmVkaXJpcy5l cykgZGVwbG95ZWQgYSBwcm9wb3NhbCAoRmVkU1NIKSBmb3IgCnRoZSBTcGFuaXNoIFN1cGVyY29t cHV0aW5nIE5ldHdvcmsuIEFsc28sIHRoZSBJbnRlcm5ldDIgd2ViIHBhZ2UgCmRlc2NyaWJlcyBm dXR1cmUgd29yayBvbiBhIEZlZGVyYXRlZCBTU0ggdG9vbHNldCAKKF9odHRwczovL3NwYWNlcy5p bnRlcm5ldDIuZWR1L2Rpc3BsYXkvQ09tYW5hZ2UvRnVuY3Rpb25hbCtSb2FkbWFwXykuIApPdGhl ciBmZWRlcmF0ZWQgc2VydmljZXMgb2YgaW50ZXJlc3QsIGJlc2lkZXMgU1NIIGFuZCB3ZWItYmFz ZWQgCnNlcnZpY2VzLCBhcmUgbmV0d29yayBzdG9yYWdlICh3aGVyZSBzdHVkZW50cyBjYW4gc3Rv cmUgZmlsZXMgcmVsYXRlZCAKd2l0aCBkaWZmZXJlbnQgc3ViamVjdHMgYW5kIGFjY2VzcyB0aGVt IGZyb20gYW55IHBsYWNlIHdpdGhpbiB0aGUgCmNhbXB1cykgYmFzZWQgb24gTkZTIChOZXR3b3Jr IEZpbGUgU3lzdGVtKSBvciBDSUZTIChDb21tb24gSW50ZXJuZXQgRmlsZSAKU3lzdGVtKS4KCkhl bmNlLCBpdCBpcyBlbnZpc2lvbmVkIHRoYXQgdW5pdmVyc2l0aWVzIHdpbGwgYmUgdmVyeSBpbnRl cmVzdGVkIG9uIGEgCnNvbHV0aW9uIHRoYXQgY2FuIHByb3ZpZGUgYW4gdW5pZmllZCBhbmQgZmVk ZXJhdGVkIGFjY2VzcyB0byB0aGVpciAKc2VydmljZXMgYmFzZWQgb24gdGhlIGFscmVhZHkgZGVw bG95ZWQgQUFBIGluZnJhc3RydWN0dXJlIChpLmUuIAplZHVyb2FtKSwgcHJvdmlkaW5nIGFuIGhv bW9nZW5lb3VzIGF1dGhlbnRpY2F0aW9uIGFuZCBTU08gYWx0ZXJuYXRpdmUgCnRoYXQsIG9uIHRo ZSBvbmUgaGFuZCwgc2ltcGxpZmllcyBkZXBsb3ltZW50IG9mIG5ldyBzZXJ2aWNlcywgYW5kIG9u IHRoZSAKb3RoZXIsIGltcHJvdmVzIHRoZWlyIHVzYWJpbGl0eS4KCgpCZXN0IHJlZ2FyZHMsCkFs ZWphbmRybwoKCj4gT2J2aW91c2x5IGhhcHB5IHRvIHJlY2VpdmUgYW55IGFkZGl0aW9uYWwgdXNl IGNhc2UgdGV4dCBwZW9wbGUgdGhpbmsgaXMgaW1wb3J0YW50Lgo+Cj4gRmVkZXJhdGVkIHNzaCBp cyBzb21ldGhpbmcgdGhhdCBpcyBhIHByaW1lIGZhY3RvciBvZiB0aGUgR3JpZCBhbmQvb3IgSFBD IHVzZS1jYXNlcyBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSAwMCBkcmFmdCAtIHRob3VnaCBib3Ro IHVzZSBjYXNlcyBkb24ndCBjdXJyZW50bHkgbWVudGlvbiBhbnkgc3BlY2lmaWMgdGVjaG5vbG9n aWVzIChlLmcuIHRoZSBjdXJyZW50IHRleHQgb2YgImZlZGVyYXRlZCBhY2Nlc3MgdG8gSFBDIHN5 c3RlbXMiIGlzIHByZXR0eSB2YWd1ZSkuIFRob3NlIHRlY2hub2xvZ2llcywgaW5jbHVkaW5nIGZl ZGVyYXRlZCBTU0gsIHNob3VsZCBwcm9iYWJseSBiZSBtb3JlIHNwZWNpZmljYWxseSBlbnVtZXJh dGVkIGluIHRoZSBuZXh0IGRyYWZ0Li4uCj4KPiBCdXQgYSBtb3JlIGdlbmVyaWMgdXNlIGNhc2Ug ZGlzY3Vzc2luZyBmZWRlcmF0ZWQgYWNjZXNzIHRvIG9yZ2FuaXNhdGlvbmFsIHNlcnZpY2VzIHN1 Y2ggYXMgU1NILCBTTVRQLCBhbmQgd2hhdG5vdCBkb2VzIHNlZW0gcHJvYmFibHkgd29ydGggaW5j bHVkaW5nLiBBbGwgdGV4dCBncmF0ZWZ1bGx5IHJlY2VpdmVkIQo+Cj4gUmVnYXJkcywKPiBSLgo+ Cj4KPiBPbiA4IE1hciAyMDExLCBhdCAwNzozOCwgR2FicmllbCBMw7NwZXogd3JvdGU6Cj4KPj4g SGksCj4+Cj4+IEkgYWx3YXlzIHRob3VnaHQgaW4gdGhlIGNhbXB1cyB1c2UgY2FzZSBsaWtlIGEg Z29vZCBleGFtcGxlIGZvciB0aGlzIHdnLiBJIG1lYW4sIHN0dWRlbnRzIGFuZCBwcm9mZXNzb3Jz IHJvYW1pbmcgYmV0d2VlbiB1bml2ZXJzaXRpZXMgYW5kIHJlcXVlc3RpbmcgZmVkZXJhdGVkIGFj Y2VzcyB0byBzZXJ2aWNlIHN1Y2ggYXMgRlRQLCBTU0gsIFNNVFAsIGV0Yy4gZXRjLiBTb21ldGhp bmcgdGhhdCBlZHVyb2FtIGlzIG5vdCBwcm92aWRpbmcgY3VycmVudGx5LiBEbyB5b3UgcGxhbiBv biB0aGUgZGVzY3JpcHRpb24gb2YgdGhpcyBzY2VuYXJpbyBpbiB0aGUgZHJhZnQ/Cj4+Cj4+IEJl c3QgcmVnYXJkcywgR2FiaS4KPj4KPj4gRWwgMDgvMDMvMTEgMDI6MzAsSW50ZXJuZXQtRHJhZnRz QGlldGYub3JnICBlc2NyaWJpw7M6Cj4+PiBBIG5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuCj4+PiBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBcHBsaWNhdGlvbiBCcmlkZ2luZyBmb3IgRmVk ZXJhdGVkIEFjY2VzcyBCZXlvbmQgd2ViIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuCj4+Pgo+ Pj4gICAgICBUaXRsZSAgICAgICAgIDogQXBwbGljYXRpb24gQnJpZGdpbmcgZm9yIEZlZGVyYXRl ZCBBY2Nlc3MgQmV5b25kIHdlYiAoQUJGQUIpIFVzZSBDYXNlcwo+Pj4KPj4+ICAgICAgQXV0aG9y KHMpICAgICA6IFIuIFNtaXRoLCBldCBhbAo+Pj4gICAgICBGaWxlbmFtZSAgICAgIDogZHJhZnQt aWV0Zi1hYmZhYi11c2VjYXNlcy0wMC50eHQKPj4+ICAgICAgUGFnZXMgICAgICAgICA6IDcKPj4+ ICAgICAgRGF0ZSAgICAgICAgICA6IDIwMTEtMDMtMDcKPj4+Cj4+PiBGZWRlcmF0ZWQgYXV0aGVu dGljYXRpb24gaXMgbW9zdCBjb21tb25seSBhc3NvY2lhdGVkIHdpdGggV2ViLWJhc2VkCj4+PiAg ICAgc2VydmljZXMsIGJ1dCB0aGVyZSBpcyBncm93aW5nIGludGVyZXN0IGluIHRoZSBhcHBsaWNh dGlvbiBvZgo+Pj4gICAgIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBmb3Igbm9uLVdlYiBzZXJ2 aWNlcy4gIFRoZSBnb2FsIG9mIHRoaXMKPj4+ICAgICBkb2N1bWVudCBpcyB0byBkcml2ZSB0aGUg ZGV2ZWxvcG1lbnQgb2YgcmVxdWlyZW1lbnRzLgo+Pj4KPj4+IEEgVVJMIGZvciB0aGlzIEludGVy bmV0LURyYWZ0IGlzOgo+Pj4KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtYWJmYWItdXNlY2FzZXMtMDAudHh0Cj4+Pgo+Pj4KPj4+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoKPj4+Cj4+PiBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLwo+Pj4KPj4+Cj4+PiBCZWxvdyBpcyB0aGUg ZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyCj4+PiBp bXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9u IG9mIHRoZQo+Pj4gSW50ZXJuZXQtRHJhZnQuCj4+Pgo+Pj4KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBhYmZhYiBtYWlsaW5nIGxpc3QKPj4+ Cj4+PiBhYmZhYkBpZXRmLm9yZwo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hYmZhYgo+PiAtLSAKPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+PiBHYWJyaWVsIEzDs3BleiBNaWxsw6FuCj4+ IERlcGFydGFtZW50byBkZSBJbmdlbmllcsOtYSBkZSBsYSBJbmZvcm1hY2nDs24geSBsYXMgQ29t dW5pY2FjaW9uZXMKPj4gVW5pdmVyc2l0eSBvZiBNdXJjaWEKPj4gU3BhaW4KPj4gVGVsOiArMzQg ODY4ODg4NTA0Cj4+IEZheDogKzM0IDg2ODg4NDE1MQo+PiBlbWFpbDoKPj4gZ2FiaWxtQHVtLmVz Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IGFi ZmFiIG1haWxpbmcgbGlzdAo+PiBhYmZhYkBpZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiCj4gLS0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gRHIgUmh5cyBT bWl0aCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZTpzbWl0aEBjYXJkaWZmLmFj LnVrCj4gRW5naW5lZXJpbmcgQ29uc3VsdGFudDogSWRlbnRpdHkmICBBY2Nlc3MgTWFuYWdlbWVu dCAgKEdQRzoweERFMkYwMjRDKQo+IEluZm9ybWF0aW9uIFNlcnZpY2VzLAo+IENhcmRpZmYgVW5p dmVyc2l0eSwgICAgICAgICAgICAgICAgICAgICAgICAgICAgdDogKzQ0ICgwKSAyOSAyMDg3IDAx MjYKPiAzOS00MSBQYXJrIFBsYWNlLCBDYXJkaWZmLCAgICAgICAgICAgICAgICAgICAgIGY6ICs0 NCAoMCkgMjkgMjA4NyA0Mjg1Cj4gQ0YxMCAzQkIsIFVuaXRlZCBLaW5nZG9tLiAgICAgICAgICAg ICAgICAgICAgICBtOiArNDQgKDApIDc5NjggMDg3IDgyMQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gYWJmYWIgbWFp bGluZyBsaXN0Cj4gYWJmYWJAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FiZmFiCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCmFiZmFiIG1haWxpbmcgbGlzdAphYmZhYkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiCg== --------------050203070607060107020906-- From Josh.Howlett@ja.net Wed Jul 6 01:53:51 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA4221F8704 for ; Wed, 6 Jul 2011 01:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 Z9wHgLCJas3h for ; Wed, 6 Jul 2011 01:53:50 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 91A2121F8681 for ; Wed, 6 Jul 2011 01:53:50 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0FB884A6B6C_E14229CB; Wed, 6 Jul 2011 08:53:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id EBA0B4A6B4A_E14229BF; Wed, 6 Jul 2011 08:53:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 6 Jul 2011 09:52:49 +0100 From: Josh Howlett To: Moonshot community list , "abfab@ietf.org" Thread-Topic: [abfab] New Internet-Draft on Multihop Federations Thread-Index: AQHMOzAN9g27fH9tQUi8rcHoOqA795TeK1SAgAAUXoCAABZ5sIAAp+IA Date: Wed, 6 Jul 2011 08:52:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 08:53:51 -0000 (Adding Abfab to the distribution, on the assumption that Sam accidentally dropped it in his response) > >> Sorry if this seems trivial! The term 'federation' is quite >overloaded and > >> means different things to different people. I suggest explicitly >calling > >> out what I think you mean, which is a 'multihop AAA fabric'. It's >an ugly > >> circumlocution, but at least it can't be misunderstood or (worse) > >> misinterpreted. > > Nico> "Federation" is a difficult word. Would it be fair to say here >that > Nico> "federation" means "set of trust cross-domain/realm paths"? The draft seems to use that meaning and also one of the defined SAML meanings (from the SAML Glossary): This term is used in two senses in SAML: a) The act of establishing a relationship between two entities. b) An association comprising any number of service providers and identity providers. BGP has an unambiguous taxonomy (autonomous systems, confederations and so forth) to describe these kinds of actors and associations in the routing world, and I suspect we need to develop something similar or we'll have terrible confusion. It's possible (and I hope) that we may be able to borrow isomorphic terms from established taxonomies, but this will require some thought. >I think we should be consistent with the proposed abfab architecture >draft. > >That document uses the term federation. I think we should too and refer >back to that document for its meaning. Having said all that, I do agree with Sam that consistency trumps accuracy, at least for now. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From leifj@sunet.se Wed Jul 6 02:51:09 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4368921F8509 for ; Wed, 6 Jul 2011 02:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZlxVLf3QLLL for ; Wed, 6 Jul 2011 02:51:08 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1D621F8505 for ; Wed, 6 Jul 2011 02:51:08 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p669p2N5008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2011 11:51:06 +0200 (CEST) Message-ID: <4E143006.1090003@sunet.se> Date: Wed, 06 Jul 2011 11:51:02 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] proposed agenda for Quebec 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 Jul 2011 09:51:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Here is the proposed agenda for Quebec. We are meeting on Friday and we have a 2.5 hour slot. Leif and Klaas abfab (Friday - 2,5 hrs) * Agenda bashing and Note Well (5 min) * Current Document Status (60 mins) - - draft-ietf-abfab-gss-eap (Sam Hartman) - - draft-hartman-gss-eap-naming (Sam Hartman) - - draft-winter-abfab-eapapplicability (Stefan Winter) - - draft-ietf-abfab-aaa-saml (Josh Howlett) - - draft-jones-diameter-abfab (Mark Jones and Hannes Tschofenig) * Propsed and New Documents (75 mins) - - draft-smith-abfab-oidregistry (Rhys Smith) - - draft-smith-abfab-usability-ui-considerations (Rhys Smith) - - draft-perez-abfab-eap-gss-preauth (Gabriel Lopez) - - draft-wei-abfab-fcla (Yinxing Wei) - - draft-mrw-abfab-multihop-fed (Margaret Wasserman) * Adminsistrivia and AOB (10 min) - - Updating the milestones and timeline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4UMAYACgkQ8Jx8FtbMZnfSuQCfRTbyZ/ckepzBuj98QZ1HqiiI TY4Anj6xCrWTeW4TSwh7CQehz0cAXwAX =hrsL -----END PGP SIGNATURE----- From alex@um.es Wed Jul 6 02:53:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627AC21F86BE for ; Wed, 6 Jul 2011 02:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRP2o4rm2I2g for ; Wed, 6 Jul 2011 02:53:00 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id AF22121F8604 for ; Wed, 6 Jul 2011 02:53:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 884415360A for ; Wed, 6 Jul 2011 11:52:58 +0200 (CEST) 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 kJKdjyABW8N9 for ; Wed, 6 Jul 2011 11:52:58 +0200 (CEST) Received: from [155.54.205.224] (inf-205-224.inf.um.es [155.54.205.224]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id 11C4353760 for ; Wed, 6 Jul 2011 11:52:56 +0200 (CEST) Message-ID: <4E143078.2080203@um.es> Date: Wed, 06 Jul 2011 11:52:56 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: abfab@ietf.org References: <4E143006.1090003@sunet.se> In-Reply-To: <4E143006.1090003@sunet.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] proposed agenda for Quebec 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 Jul 2011 09:53:01 -0000 Hi Leif, It would be me the one presenting draft-perez-abfab-eap-gss-preauth, instead of Gabriel Lopez. Best regards, Alejandro > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Folks, > > Here is the proposed agenda for Quebec. We are meeting on > Friday and we have a 2.5 hour slot. > > Leif and Klaas > > > abfab (Friday - 2,5 hrs) > > * Agenda bashing and Note Well (5 min) > > * Current Document Status (60 mins) > - - draft-ietf-abfab-gss-eap (Sam Hartman) > - - draft-hartman-gss-eap-naming (Sam Hartman) > - - draft-winter-abfab-eapapplicability (Stefan Winter) > - - draft-ietf-abfab-aaa-saml (Josh Howlett) > - - draft-jones-diameter-abfab (Mark Jones and Hannes Tschofenig) > > * Propsed and New Documents (75 mins) > - - draft-smith-abfab-oidregistry (Rhys Smith) > - - draft-smith-abfab-usability-ui-considerations (Rhys Smith) > - - draft-perez-abfab-eap-gss-preauth (Gabriel Lopez) > - - draft-wei-abfab-fcla (Yinxing Wei) > - - draft-mrw-abfab-multihop-fed (Margaret Wasserman) > > * Adminsistrivia and AOB (10 min) > - - Updating the milestones and timeline > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4UMAYACgkQ8Jx8FtbMZnfSuQCfRTbyZ/ckepzBuj98QZ1HqiiI > TY4Anj6xCrWTeW4TSwh7CQehz0cAXwAX > =hrsL > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Wed Jul 6 03:10:33 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69C21F8685 for ; Wed, 6 Jul 2011 03:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.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 FKdwnwsiFwRX for ; Wed, 6 Jul 2011 03:10:32 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6663421F861C for ; Wed, 6 Jul 2011 03:10:32 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 901D91A9C20B_E143496B; Wed, 6 Jul 2011 10:10:30 +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 7FCCE1A9C177_E143496F; Wed, 6 Jul 2011 10:10:30 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 6 Jul 2011 11:09:31 +0100 From: Josh Howlett To: "wei.yinxing@zte.com.cn" , "abfab@ietf.org" Thread-Topic: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded Thread-Index: AQHMOkAlHXWUhwXhTkum/FtV0b6G+5TfFVqA Date: Wed, 6 Jul 2011 10:09:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 10:10:33 -0000 Hi, This is an interesting use-case. What do you think is the benefit to dynamic cross-layer provisioning of credentials (which I think is what you're describing) over an out-of-band pre-provisioning of credentials? For example, the network operator already presumably includes some credentials in the end user's device for accessing the network (such as a SIM). Why not just use the same credential for applications? Doesn't this bring the same stakeholder benefits that you describe at the end of section 2? Josh. On 04/07/2011 12:47, "wei.yinxing@zte.com.cn" wrote: > >Hi, all > > A new draft is uploaded into abfab, >please review it. Any comments are welcome! > >------------------------------------------------------- > http://www.ietf.org/id/draft-wei-abfab-fcla-00.txt >ABFAB=20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > Y. Wei, Ed. >Internet-Draft=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > ZTE Corporation >Intended status: Informational > July 4, 2011 >Expires: January 5, 2012 > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > Federated Cross-Layer Access >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > draft-wei-abfab-fcla-00 > >Abstract > > Network stratum and application stratum form a federation to > faciliate user's access. Network operator acts as Identity >Provider > (IdP), and application reuses underlying network's security > capabilities to simlify application's access. This document >is to > introduce such federated cross-layer access use case. > > >-------------------------------------------------------- >ZTE Information Security Notice: The information contained in this mail >is solely property of the sender's organization. This mail communication >is confidential. Recipients named above are obligated to maintain secrecy >and are not permitted to disclose the contents of this communication to >others. >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they are >addressed. If you have received this email in error please notify the >originator of the message. Any views expressed in this message are those >of the individual sender. >This message has been scanned for viruses and Spam by ZTE Anti-Spam >system. >_______________________________________________ >abfab mailing list >abfab@ietf.org >https://www.ietf.org/mailman/listinfo/abfab JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Wed Jul 6 04:23:00 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9018521F872B for ; Wed, 6 Jul 2011 04:23:00 -0700 (PDT) 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 sBvkykgHr1hc for ; Wed, 6 Jul 2011 04:22:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4921F8734 for ; Wed, 6 Jul 2011 04:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=3573; q=dns/txt; s=iport; t=1309951379; x=1311160979; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=iU0EE0E9A1v3JieV2D7KR7FOpOSzOOuo6oRinm2tXl0=; b=h1oLSNtbbHLbTekBtnudnPEuuNKdaSLn6/sm1baxKGMnc6iUg1cGAJuL ppxmHiZW9dkQxSPKZSAdbhvji/i0ddrEDMXCfoMt1pfVInG4UAgMlRHuL q85MY36MQ0/WGAhwN8DIR2PgtJh+FCugLtzZvym4os3ou2sZCNDunCBGg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPdEFE6Q/khM/2dsb2JhbABGDagDd4h6pU6eL4MigxQEkkGQPg X-IronPort-AV: E=Sophos;i="4.65,486,1304294400"; d="scan'208";a="99909902" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2011 11:22:58 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p66BMwAf024422 for ; Wed, 6 Jul 2011 11:22:58 GMT Message-ID: <4E144592.5080700@cisco.com> Date: Wed, 06 Jul 2011 13:22:58 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 11:23:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/11 12:09 PM, Josh Howlett wrote: Josh, > This is an interesting use-case. > > What do you think is the benefit to dynamic cross-layer provisioning > of credentials (which I think is what you're describing) over an > out-of-band pre-provisioning of credentials? For example, the network > operator already presumably includes some credentials in the end > user's device for accessing the network (such as a SIM). Why not just > use the same credential for applications? Doesn't this bring the same > stakeholder benefits that you describe at the end of section 2? I don't really understand your question. I assume that the service provider and the IdP are in different administrative domains, so surely you don't want to exchange user credentials across those? The way I have read the draft is that they want to take a network authentication and use that to authenticate to applications, both in and outside the administrative domain of the operator. Klaas > > Josh. > > On 04/07/2011 12:47, "wei.yinxing@zte.com.cn" > wrote: > >> >> Hi, all >> >> A new draft is uploaded into abfab, please review it. Any comments >> are welcome! >> >> ------------------------------------------------------- >> http://www.ietf.org/id/draft-wei-abfab-fcla-00.txt ABFAB >> >> >> Y. Wei, Ed. Internet-Draft >> >> ZTE Corporation Intended status: Informational July 4, 2011 >> Expires: January 5, 2012 >> >> >> Federated Cross-Layer Access >> >> draft-wei-abfab-fcla-00 >> >> Abstract >> >> Network stratum and application stratum form a federation to >> faciliate user's access. Network operator acts as Identity >> Provider (IdP), and application reuses underlying network's >> security capabilities to simlify application's access. This >> document is to introduce such federated cross-layer access use >> case. >> >> >> -------------------------------------------------------- ZTE >> Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents >> of this communication to others. This email and any files >> transmitted with it are confidential and intended solely for the >> use of the individual or entity to whom they are addressed. If you >> have received this email in error please notify the originator of >> the message. Any views expressed in this message are those of the >> individual sender. This message has been scanned for viruses and >> Spam by ZTE Anti-Spam system. >> _______________________________________________ abfab mailing list >> abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab > > > JANET(UK) is a trading name of The JNT Association, a company > limited by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ abfab mailing list > abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4URZEACgkQH2Wy/p4XeFIcFgCcDr1xNBBYng2nhfDcOBh+QdHk 4NEAnA57KV1ALKPT3tD+z/ndlvRofwCb =Aaut -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Wed Jul 6 04:31:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15C421F8507 for ; Wed, 6 Jul 2011 04:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 SCSQz5oblVOZ for ; Wed, 6 Jul 2011 04:31:13 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA4E21F8508 for ; Wed, 6 Jul 2011 04:31:13 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B4B7A4A6B65_E14477EB; Wed, 6 Jul 2011 11:31:10 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id A4DE44A6B63_E14477EF; Wed, 6 Jul 2011 11:31:10 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 6 Jul 2011 12:30:12 +0100 From: Josh Howlett To: Klaas Wierenga , "abfab@ietf.org" Thread-Topic: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded Thread-Index: AQHMOkAlHXWUhwXhTkum/FtV0b6G+5TfFVqAgAADfwCAABMLgA== Date: Wed, 6 Jul 2011 11:30:11 +0000 Message-ID: In-Reply-To: <4E144592.5080700@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <0ED86C43542F064BA33D32E044EF1A13@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 11:31:14 -0000 Hi Klaas, >> This is an interesting use-case. >>=20 >> What do you think is the benefit to dynamic cross-layer provisioning >> of credentials (which I think is what you're describing) over an >> out-of-band pre-provisioning of credentials? For example, the network >> operator already presumably includes some credentials in the end >> user's device for accessing the network (such as a SIM). Why not just >> use the same credential for applications? Doesn't this bring the same >> stakeholder benefits that you describe at the end of section 2? > >I don't really understand your question. I assume that the service >provider and the IdP are in different administrative domains, so surely >you don't want to exchange user credentials across those? Doesn't Abfab solve that use-case? E.g. I use my operator-provisioned SIM credentials to authenticate (using Abfab) to the service provider. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Wed Jul 6 04:38:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0EC21F867C for ; Wed, 6 Jul 2011 04:38:31 -0700 (PDT) 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 B9m9ote4puvb for ; Wed, 6 Jul 2011 04:38:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 933A021F8680 for ; Wed, 6 Jul 2011 04:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1661; q=dns/txt; s=iport; t=1309952310; x=1311161910; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9yOaaMy/y12QzCM6fdt3TlFROF+eXhuFmo2Qd5d9//Q=; b=EkVjVuA7yz6dlaLkxQs5Es56JtK1QC2/65V7pBfsPwNaCAOTvCMMdIQD DuCGZzovRPGE2VPOBbGe9yBg10oBnn8Ud3kS46xlzZq1kJLNt8TS6J1Md iS8k8mXo4ReMksHMBLnmBpvwEiEoFkMjHtCCSSl4jyICqpnoxnCIEVkj9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIlIFE6Q/khR/2dsb2JhbABGDagDd4h6pVCeLoMigxQEkkGQPg X-IronPort-AV: E=Sophos;i="4.65,486,1304294400"; d="scan'208";a="99912181" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2011 11:38:29 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p66BcSCc014552; Wed, 6 Jul 2011 11:38:28 GMT Message-ID: <4E144934.7090206@cisco.com> Date: Wed, 06 Jul 2011 13:38:28 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 11:38:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josh, >>> This is an interesting use-case. >>> >>> What do you think is the benefit to dynamic cross-layer >>> provisioning of credentials (which I think is what you're >>> describing) over an out-of-band pre-provisioning of credentials? >>> For example, the network operator already presumably includes >>> some credentials in the end user's device for accessing the >>> network (such as a SIM). Why not just use the same credential for >>> applications? Doesn't this bring the same stakeholder benefits >>> that you describe at the end of section 2? >> >> I don't really understand your question. I assume that the service >> provider and the IdP are in different administrative domains, so >> surely you don't want to exchange user credentials across those? > > Doesn't Abfab solve that use-case? E.g. I use my operator-provisioned > SIM credentials to authenticate (using Abfab) to the service > provider. I think so yes, that is why I believe it is proposed in abfab. The draft says: "Inspired by the previous work, this document considers a use case which telecom operator acts as Identity provider (IdP) and federates with non-Web applications, e.g. Email, Messaging." So I think Yinxing proposes an abfab use-case.... but probably Yinxing can better answer that himself.... Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4USTQACgkQH2Wy/p4XeFKTywCgzC1s0IK5Zyr4kXELVWiJIcFU fTAAn0brdXmAbaGD+n45+apn8BIQ/ZsV =wnjf -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Wed Jul 6 05:02:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1A21F86E0 for ; Wed, 6 Jul 2011 05:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 xbm51VArJdba for ; Wed, 6 Jul 2011 05:02:25 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7840721F8602 for ; Wed, 6 Jul 2011 05:02:25 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9AEE91A9D3B8_E144ED0B; Wed, 6 Jul 2011 12:02:24 +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 8DC991A9ACE6_E144ED0F; Wed, 6 Jul 2011 12:02:24 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 6 Jul 2011 13:01:25 +0100 From: Josh Howlett To: Klaas Wierenga Thread-Topic: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded Thread-Index: AQHMOkAlHXWUhwXhTkum/FtV0b6G+5TfFVqAgAADfwCAABMLgP//8UoAgAAXcIA= Date: Wed, 6 Jul 2011 12:01:25 +0000 Message-ID: In-Reply-To: <4E144934.7090206@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F8D86687E793E448CB08E73B28EED1C@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 12:02:26 -0000 >So I think Yinxing proposes an abfab use-case.... That makes sense to me. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From gabilm@um.es Wed Jul 6 05:10:25 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF6E21F86E6 for ; Wed, 6 Jul 2011 05:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 98+oVayuNpoK for ; Wed, 6 Jul 2011 05:10:24 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7195721F873D for ; Wed, 6 Jul 2011 05:10:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 2145B5D49D; Wed, 6 Jul 2011 14:10:23 +0200 (CEST) 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 6twVBHvJUFCR; Wed, 6 Jul 2011 14:10:20 +0200 (CEST) Received: from inf-205-135.inf.um.es (inf-205-135.inf.um.es [155.54.205.135]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id 020AC5D625; Wed, 6 Jul 2011 14:10:17 +0200 (CEST) Message-ID: <4E145168.7080503@um.es> Date: Wed, 06 Jul 2011 14:13:28 +0200 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Klaas Wierenga , abfab@ietf.org References: <4E144592.5080700@cisco.com> In-Reply-To: <4E144592.5080700@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [abfab] A new draft (draft-wei-abfab-fcla-00) is uploaded 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 Jul 2011 12:10:26 -0000 El 06/07/11 13:22, Klaas Wierenga escribió: > On 7/6/11 12:09 PM, Josh Howlett wrote: > > Josh, > > > This is an interesting use-case. > > > What do you think is the benefit to dynamic cross-layer provisioning > > of credentials (which I think is what you're describing) over an > > out-of-band pre-provisioning of credentials? For example, the network > > operator already presumably includes some credentials in the end > > user's device for accessing the network (such as a SIM). Why not just > > use the same credential for applications? Doesn't this bring the same > > stakeholder benefits that you describe at the end of section 2? > > I don't really understand your question. I assume that the service > provider and the IdP are in different administrative domains, so surely > you don't want to exchange user credentials across those? > > The way I have read the draft is that they want to take a network > authentication and use that to authenticate to applications, both in and > outside the administrative domain of the operator. Regarding this use-case you could consider interesting the work done in DAMe and DAMe-2 Let this paper serves as an summary: http://www.sciencedirect.com/science/article/pii/S0920548908000305 The idea behind this work was to authenticate the network access and, making use of the EAP tunnel between the end user supplicant and the home RADIUS server, to distribute a SAML authentication token which was securely stored in the end user supplicant. Once the token is available, the end user could make use of it to request SSO access to non-web applications. Indeed we are currently integrating this idea with the Kerberos scenario Best regards, Gabi. > > Klaas > > > > Josh. > > > On 04/07/2011 12:47, "wei.yinxing@zte.com.cn" > > wrote: > > >> > >> Hi, all > >> > >> A new draft is uploaded into abfab, please review it. Any comments > >> are welcome! > >> > >> ------------------------------------------------------- > >> http://www.ietf.org/id/draft-wei-abfab-fcla-00.txt ABFAB > >> > >> > >> Y. Wei, Ed. Internet-Draft > >> > >> ZTE Corporation Intended status: Informational July 4, 2011 > >> Expires: January 5, 2012 > >> > >> > >> Federated Cross-Layer Access > >> > >> draft-wei-abfab-fcla-00 > >> > >> Abstract > >> > >> Network stratum and application stratum form a federation to > >> faciliate user's access. Network operator acts as Identity > >> Provider (IdP), and application reuses underlying network's > >> security capabilities to simlify application's access. This > >> document is to introduce such federated cross-layer access use > >> case. > >> > >> > >> -------------------------------------------------------- ZTE > >> Information Security Notice: The information contained in this > >> mail is solely property of the sender's organization. This mail > >> communication is confidential. Recipients named above are obligated > >> to maintain secrecy and are not permitted to disclose the contents > >> of this communication to others. This email and any files > >> transmitted with it are confidential and intended solely for the > >> use of the individual or entity to whom they are addressed. If you > >> have received this email in error please notify the originator of > >> the message. Any views expressed in this message are those of the > >> individual sender. This message has been scanned for viruses and > >> Spam by ZTE Anti-Spam system. > >> _______________________________________________ abfab mailing list > >> abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab > > > > JANET(UK) is a trading name of The JNT Association, a company > > limited by guarantee which is registered in England under No. 2881024 > > and whose Registered Office is at Lumen House, Library Avenue, > > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > > _______________________________________________ abfab mailing list > > abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ 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 smith@Cardiff.ac.uk Wed Jul 6 10:49:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326AB21F89F0 for ; Wed, 6 Jul 2011 10:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 qdDUXG6vJg7i for ; Wed, 6 Jul 2011 10:49:30 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5216821F89ED for ; Wed, 6 Jul 2011 10:49:30 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QeWE3-0001GB-Sc; Wed, 06 Jul 2011 18:49:27 +0100 Received: from [86.184.20.181] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QeWE3-0005Aa-OF; Wed, 06 Jul 2011 18:49:27 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rhys Smith In-Reply-To: <4E141FD8.6020704@um.es> Date: Wed, 6 Jul 2011 18:49:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110705205038.19999.2458.idtracker@ietfa.amsl.com> <4E141FD8.6020704@um.es> To: =?iso-8859-1?Q?Gabriel_L=F3pez?= X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] New version (-01) of use case I-D 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 Jul 2011 17:49:31 -0000 I haven't added it yet; mostly because to me it reads more like a series = of use cases applicable to a single context as it stands. Personally I think it's better to concentrate on the individual use = cases (e.g. ABFABbed printing, ABFABbed database/directory access, = ABFABbed HPC services, ABFABbed SIP, etc) which are valid in any domain = (be it campus or enterprise or whatever) than on describing a variety of = use cases in specific contexts (e.g. the campus use case, the small = enterprise case, the large enterprise case, the health provider case, = etc. etc.). The reason for that is that I fear that people out of the academic = environment may not empathise with it if it's framed as a "campus" use = case even when the details may be very applicable to them. Hence why I'm = trying to draw out each particular use case separately and make it = applicable in a variety of contexts. Also, there's going to be some = degree of overlap in use cases between contexts. I'm obviously happy to change this if the consensus is to do so, but I'm = currently of the opinion that this is the better way to do it - anybody = have any thoughts? R. On 6 Jul 2011, at 09:42, Gabriel L=F3pez wrote: > Hi Rhys, >=20 > Alejandro sent a few months ago the campus use-case. I see it is not > included in the -01 version. > Just to know whether do you think this case is not interesting for > abfab, pending to be added, or it is just a mistake :) >=20 > Best regards, Gabi. >=20 > El 05/07/11 22:54, Rhys Smith escribi=F3: >> Just posted a -01 of the use case doc. See App A for details of = changes - added a few use cases as suggested during and since the last = IETF gathering, and rewording some bits here and there. Still some to = do... Comments obviously welcome! >>=20 >> http://www.ietf.org/id/draft-ietf-abfab-usecases-01.txt >>=20 >> Regards, >> Rhys. >> -- >> = ---------------------------------------------------------------------- >> Dr Rhys Smith e: = smith@cardiff.ac.uk >> Engineering Consultant: Identity & Access Management = (GPG:0xDE2F024C) >> Information Services, >> Cardiff University, t: +44 (0) 29 2087 = 0126 >> 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 = 4285 >> CF10 3BB, United Kingdom. m: +44 (0) 7968 087 = 821 >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 > --=20 > ---------------------------------------------------------------- > Gabriel L=F3pez Mill=E1n > Departamento de Ingenier=EDa de la Informaci=F3n y las Comunicaciones > University of Murcia > Spain > Tel: +34 868888504 > Fax: +34 868884151 > email: gabilm@um.es >=20 > -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From hartmans@painless-security.com Wed Jul 6 13:22:02 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8721F8B53 for ; Wed, 6 Jul 2011 13:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 OcvKITTZ5DcC for ; Wed, 6 Jul 2011 13:22:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 77ABE21F8BC0 for ; Wed, 6 Jul 2011 13:22:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3AFBC201B1; Wed, 6 Jul 2011 16:21:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A12C3437D; Wed, 6 Jul 2011 16:21:49 -0400 (EDT) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <4E141D7D.6000504@um.es> Date: Wed, 06 Jul 2011 16:21:49 -0400 In-Reply-To: <4E141D7D.6000504@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22'?= =?iso-8859-1?Q?s?= message of "Wed, 06 Jul 2011 10:31:57 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , "abfab@ietf.org" , Margaret Wasserman Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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 Jul 2011 20:22:02 -0000 >>>>> "Gabriel" == Gabriel López writes: Gabriel> - It is not clear what the Trust Router is. Advanced production routers Gabriel> running in institutions? or Is it a new entity every institution should Gabriel> deploy? Every institution must have a trust router announcing its routes and a trust router that it can use for queries. It plays the role of SAML metadata in our system. It could be outsourced. For example if a SAML federation also wanted to run ABFAB using AAA credentials [1] they could run one trust router that everyone in their federation used. They'd probably want to make it redundant. We expect multiple trust routers will esentially be required for inter-federation use cases. We expect that some organizations will want to run their own trust router, so even in the single federation use case it is unlikely that there will be only one trust router. However it is not required that every institution needs to deploy a trust router. Gabriel> - Does the term Trust Path refer to the AAA path/TRs path/mixed? Not exactly. I'm a security person so I think of things in terms of attacks. The trust path is an ordered set of realms who are in a position to man-in-the-middle your communication. We probably want a definition that's more positive than that, but I believe that other than explaining why the set is ordered, my definition is accurate. Your AAA message goes from something near the RP to the radsec server near or at the IDP assuming you're actually using RADSEC. However other realms help set up the technical and policy trust required to send that message. Gabriel> - " 4. The Relying Party contacts a trust router in Realm B (using its Gabriel> permanent identity in Realm A)" Gabriel> So Trust Router in realm B should "delegate" the authentication of Gabriel> RP to realm A, an so on ....? Sometimes. We're in ABFAB, so we would be delighted if people used draft-ietf-abfab-gss-eap for this authentication. In that case, yes, the authentication is delegated. however, you could also imagine using some other mechanism: TLS with client certs, Scott's SAML ECP mechanism, etc. I'd expect that draft-ietf-abfab-gss-eap will be the mandatory to implement mechanism here. Gabriel> Section 4: Gabriel> - The list of security properties required by the Trust Routers Gabriel> would help to a better understanding of the protocol :) * hop-by-hop integrity * peer entity authentication * for some deployments confidentiality We do not plan to provide end-to-end data origin authentication because one of the assumptions here is that there's no global credential infrastructure shared by everyone that could be used to validate that. We also tend to require attribute exchange from the authentication process; something that can use GSS with naming extensions or use attribute certificates or SAML assertions ends up being fairly close to required. Gabriel> Sections 5 and 6: Gabriel> - Do you have in mind some transport and communication protocols for the Gabriel> Trust Path Query and Temporaly Identity Request? I understand this Gabriel> document describes the general idea, the questions are just to know if Gabriel> you have in mind some answers already thought. Yes. see draft-howlett-radsec-knp for one approach. Alan has proposed doing this entirely within RADIUS as well. Gabriel> Why does the RP ask every router in the federation? I mean, if Gabriel> requesting TR A, which by means of some "advanced" routing protocol is Gabriel> able to know the better path from A to D, after the first request the RP Gabriel> knows TR D or even idP. I don't think it does query every router in the federation. It does establish an identity with every router it needs to talk to. Gabriel> Section 6. Gabriel> "When a Temporary Identity is requested, a Trust Router Gabriel> will provision a new identity in its local RADIUS infrastructure that Gabriel> can be used by the Relying Party to communicate with the Trust Router Gabriel> or RADIUS/RADSEC server that represents the next step in the Trust Gabriel> Path." Gabriel> Then, every institution hosts a TR and a Radius/RadSec server, this Gabriel> should be clarified in the diagram and the introduction. Every TR needs to be able to provision identities somewhere. See above for how many TRs you need. Gabriel> It is not clear for me the relationship between Trust Path Queries and Gabriel> Temporaly Identity Requests. When are they sent from the RP to the TR? Gabriel> What is the global number of message exchanged between RP, TRs, RADIUs, Gabriel> etc..? OK, let's take the example from Margaret's draft. I'm going to try and enumerate all the traffic . 1) Trust routers exchange and flood routes. I don't know what the order of messages of this exchange is, but I'm sure people familiar with routing protocols do. This is amortized across all uses of the trust infrastructure. Messages are generated when routes change. 2) RP queries Tr A to get the path. Assuming local authentication probably effectively 2 messages. Not two packets; authentication protocols and TCP can be chatty, but I'm going to use this as the base for number of messages. 3) RP asks TR B for identity (2 messages); amortized across all uses of this identity 3a) TR B proxies eap back to A (2 messages) 4) RP asks TR C for identity (2 messages) 4A) TR C proxies back to B (2 messages) 5) RP asks TR D for radsec ID (2 messages) 5A) proxy back to C for auth (2 messages) 6) Subject authentications to RP (2 messages) 6A) Proxy that from RP to D's radsec server (2 messages) Caching is important. You want temporary identities to be reused. So on the next time the same user authenticates: I) RP notices it has a credential cached (0 messages) II) Subject authentication to RP (2 messages) II.1) Proxy directly to D RADSEC (2 messages) From gabilm@um.es Wed Jul 6 23:52:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010521F88C9 for ; Wed, 6 Jul 2011 23:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 TUfjHKCW7JXd for ; Wed, 6 Jul 2011 23:52:06 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3609821F88C7 for ; Wed, 6 Jul 2011 23:52:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id E2EC65D511; Thu, 7 Jul 2011 08:52:02 +0200 (CEST) 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 QNS7hOvahFF9; Thu, 7 Jul 2011 08:52:02 +0200 (CEST) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPSA id 81B055D47A; Thu, 7 Jul 2011 08:51:56 +0200 (CEST) Message-ID: <4E15584B.3040604@um.es> Date: Thu, 07 Jul 2011 08:55:07 +0200 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Sam Hartman References: <4E141D7D.6000504@um.es> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , "abfab@ietf.org" , Margaret Wasserman Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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, 07 Jul 2011 06:52:06 -0000 Hi Sam, El 06/07/11 22:21, Sam Hartman escribió: > > It plays the role of SAML metadata in our system. ok, although it runs federation routing and topology information, and forwards eap authentications. It plays a lot of roles :) > However it is not required that every institution needs to deploy a trust router. > ok > Gabriel> - Does the term Trust Path refer to the AAA path/TRs path/mixed? > > Your AAA message goes from something near the RP to the radsec server > near or at the IDP assuming you're actually using RADSEC. > However other realms help set up the technical and policy trust required > to send that message. I can understand the AAA path in this case, but l think this mixed path is very complicated. If every realm implements this functionality like a AAA server it would be more interesting. > > Gabriel> Section 4: > > Gabriel> - The list of security properties required by the Trust Routers > Gabriel> would help to a better understanding of the protocol :) > > * hop-by-hop integrity > * peer entity authentication > * for some deployments confidentiality The last comments clarifies this point > > OK, let's take the example from Margaret's draft. > I'm going to try and enumerate all the traffic . > > 1) Trust routers exchange and flood routes. I don't know what the order > of messages of this exchange is, but I'm sure people familiar with > routing protocols do. This is amortized across all uses of the trust > infrastructure. Messages are generated when routes change. This is an important point that may required another important number of exchanges, in order to build and exchange the federation topology (I'm thinking here in something like eduroam) and to query that path by the RP (although I suppose here only 2 messages are needed) > > Have you analysed how this process (I count 18 messages for 4 realms without routing and attribute request exchanges) could affect specific services like SIP? Thanks a lot for your comments Sam, I think this explanation (completed with the routing part) should appear in the next version. Best regards, Gabi. -- ---------------------------------------------------------------- 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 leifj@sunet.se Thu Jul 7 00:49:04 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D021F88C3 for ; Thu, 7 Jul 2011 00:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Q1NTRTauep for ; Thu, 7 Jul 2011 00:49:03 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69521F88B9 for ; Thu, 7 Jul 2011 00:49:02 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p677mvR4002532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Jul 2011 09:49:00 +0200 (CEST) Message-ID: <4E1564E9.2010705@sunet.se> Date: Thu, 07 Jul 2011 09:48:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: abfab@ietf.org References: <4E143006.1090003@sunet.se> In-Reply-To: <4E143006.1090003@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] proposed agenda for Quebec 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, 07 Jul 2011 07:49:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/06/2011 11:51 AM, Leif Johansson wrote: > > Folks, > > Here is the proposed agenda for Quebec. We are meeting on > Friday and we have a 2.5 hour slot. > We've only gotten a few nits for the agenda and those have now been pushed to the agenda online at http://www.ietf.org/proceedings/81/agenda/abfab.txt Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4VZOYACgkQ8Jx8FtbMZndxnwCgsge/+KUNKAKyYqA7xGw6GLGy IQgAn1cWhqlXVoczRERfyGHR1/THctJp =H1nw -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Jul 7 07:56:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7714921F867E for ; Thu, 7 Jul 2011 07:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 Aohg+FksXISq for ; Thu, 7 Jul 2011 07:56:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 56FEC21F8641 for ; Thu, 7 Jul 2011 07:56:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D1AE5202C9; Thu, 7 Jul 2011 10:55:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 325E7437D; Thu, 7 Jul 2011 10:56:16 -0400 (EDT) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <4E141D7D.6000504@um.es> <4E15584B.3040604@um.es> Date: Thu, 07 Jul 2011 10:56:16 -0400 In-Reply-To: <4E15584B.3040604@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22'?= =?iso-8859-1?Q?s?= message of "Thu, 07 Jul 2011 08:55:07 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , "abfab@ietf.org" , Margaret Wasserman Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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, 07 Jul 2011 14:56:30 -0000 >>>>> "Gabriel" == Gabriel López writes: Gabriel> Hi Sam, Gabriel> El 06/07/11 22:21, Sam Hartman escribió: >> >> It plays the role of SAML metadata in our system. Gabriel> ok, although it runs federation routing and topology information, and Gabriel> forwards eap authentications. It plays a lot of roles :) The trust router does *not* forward eap authentications to the end service or user's IDP, no. A trust router will act as a service and in that role may handle authentications the same as any other service. >> However it is not required that every institution needs to deploy a trust router. >> Gabriel> ok Gabriel> - Does the term Trust Path refer to the AAA path/TRs path/mixed? >> >> Your AAA message goes from something near the RP to the radsec server >> near or at the IDP assuming you're actually using RADSEC. >> However other realms help set up the technical and policy trust required >> to send that message. Gabriel> I can understand the AAA path in this case, but l think this mixed path Gabriel> is very complicated. If every realm implements this functionality like a Gabriel> AAA server it would be more interesting. It would have significantly worse privacy and performance characteristics. Gabriel> Have you analysed how this process (I count 18 messages for 4 realms Gabriel> without routing and attribute request exchanges) could affect specific Gabriel> services like SIP? So, currently ABFAB does not target SIP. In general I'd expect you to use the same SIP registration server regardless of your current location. However if we did target SIP and you did happen to use a registration server far away from your IDP, it would mean that you'd need 18 messages and introduce some delay for your first registration. In most sip deployments beyond that, the number of messages would be the same as it is with some central authentication server after that because the registration would be cached. so, it might take a couple of seconds longer the first time your phone boots in the morning. From nico@cryptonector.com Thu Jul 7 08:20:38 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8284F21F873D for ; Thu, 7 Jul 2011 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Nu5mrAc1NoYb for ; Thu, 7 Jul 2011 08:20:37 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E2C2A21F873A for ; Thu, 7 Jul 2011 08:20:37 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id B03AC678069 for ; Thu, 7 Jul 2011 08:20:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AajqfLocvGskUoXI8/3KuTNJzT+ldcPa7vjTfQiw5A7R LS4lk6GFKGB2+vm8kpn4KySte/VEjMC4nsWhf+K0PyYNajkSnmzJqtJ9+6tWsb34 oHFH+Rye6//BgbgoNQgSExGBxkyxx0pYLt2ubivPmxceVCA9g/BBUVz+VQXL5+I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=TL43Ls8Xd0OGTFObZFyAkzko9g0=; b=wjBoiNPX64H lvBI30mLkEhMl4zQYwUZiKxoijmBCZCmakoFhhaBPm8W/16vL+1dqWlNW7tc1CxC Kgjt8Hd3enaR9OrJLixyaFWi5oM6RdBUO3l6ISU+adMPq6hhL3o+khdxA34SAXb7 8/OZ0hxooj1IacYLaEoHRfjixnnQsF8Y= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 8EFC9678056 for ; Thu, 7 Jul 2011 08:20:37 -0700 (PDT) Received: by pvh18 with SMTP id 18so685495pvh.31 for ; Thu, 07 Jul 2011 08:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.36 with SMTP id e4mr1245231pbj.320.1310052037225; Thu, 07 Jul 2011 08:20:37 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Thu, 7 Jul 2011 08:20:37 -0700 (PDT) In-Reply-To: References: <4E141D7D.6000504@um.es> <4E15584B.3040604@um.es> Date: Thu, 7 Jul 2011 10:20:37 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman , "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , "abfab@ietf.org" Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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, 07 Jul 2011 15:20:38 -0000 On Thu, Jul 7, 2011 at 9:56 AM, Sam Hartman wrote: >>>>>> "Gabriel" =3D=3D Gabriel L=C3=B3pez writes: > =C2=A0 =C2=A0Gabriel> Have you analysed how this process (I count 18 mess= ages for 4 realms > =C2=A0 =C2=A0Gabriel> without routing and attribute request exchanges) co= uld affect specific > =C2=A0 =C2=A0Gabriel> services like SIP? > > So, currently ABFAB does not target SIP. > In general I'd expect you to use the same SIP registration server > regardless of your current location. > > However if we did target SIP and you did happen to use a registration > server far away from your IDP, it would mean that you'd need 18 messages > and introduce some delay for your first registration. =C2=A0In most sip > deployments beyond that, the number of messages would be the same as it > is with some central authentication server after that because the > registration would be cached. Also, presumably the trust path routes won't change/flap anywhere near as often as IP routes, right? So it should be safe to cache these paths for quite a while. Also, validation of cached paths could be done asynchronously, in the background. Nico -- From hartmans@painless-security.com Thu Jul 7 08:33:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3DC21F88AC for ; Thu, 7 Jul 2011 08:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ADIXuiBkH-BB for ; Thu, 7 Jul 2011 08:33:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B1EC021F88A7 for ; Thu, 7 Jul 2011 08:33:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 750DD2034A; Thu, 7 Jul 2011 11:32:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 10A49437D; Thu, 7 Jul 2011 11:32:52 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4E141D7D.6000504@um.es> <4E15584B.3040604@um.es> Date: Thu, 07 Jul 2011 11:32:52 -0400 In-Reply-To: (Nico Williams's message of "Thu, 7 Jul 2011 10:20:37 -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: Margaret Wasserman , "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , "abfab@ietf.org" Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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, 07 Jul 2011 15:33:01 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Also, presumably the trust path routes won't change/flap anywhere near Nico> as often as IP routes, right? So it should be safe to cache these Nico> paths for quite a while. Also, validation of cached paths could be Nico> done asynchronously, in the background. Well, I'd just cachec the end-to-end key and what realm it mapped to. No need to cache the root; caching the key gets you the same effect. But yes, you *could* cache the route and validate asynchronously. Nico> Nico Nico> -- From aland@deployingradius.com Thu Jul 7 10:05:03 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31C721F874A for ; Thu, 7 Jul 2011 10:05:03 -0700 (PDT) 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 KG60VuFchvYy for ; Thu, 7 Jul 2011 10:05:03 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3562E21F8745 for ; Thu, 7 Jul 2011 10:05:03 -0700 (PDT) Message-ID: <4E15E73D.4040507@deployingradius.com> Date: Thu, 07 Jul 2011 19:05:01 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <4E141D7D.6000504@um.es> <4E15584B.3040604@um.es> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "MOONSHOT-COMMUNITY@JISCMAIL.AC.UK" , Margaret Wasserman , "abfab@ietf.org" Subject: Re: [abfab] New Internet-Draft on Multihop Federations 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, 07 Jul 2011 17:05:03 -0000 Nico Williams wrote: > Also, presumably the trust path routes won't change/flap anywhere near > as often as IP routes, right? The commercial integrators take *months* to set up a new connection. So changes should be rare. > So it should be safe to cache these > paths for quite a while. A TTL of a day or so would probably be fine. Alan DeKok. From hartmans@painless-security.com Thu Jul 7 10:47:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC41F0C44 for ; Thu, 7 Jul 2011 10:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 uazN2tlas7E7 for ; Thu, 7 Jul 2011 10:47:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E503B1F0C3E for ; Thu, 7 Jul 2011 10:47:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8F6F82034A for ; Thu, 7 Jul 2011 13:47:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1CA43437D; Thu, 7 Jul 2011 13:47:29 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Thu, 07 Jul 2011 13:47:29 -0400 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] Interactions between EAP and GSS EAP state machines 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, 07 Jul 2011 17:47:36 -0000 Hi. I've always been a bit confused about RFC 3748 and protected result indications and how that all works in practice. I'm wondering how GSS-EAP should know when authentication has succeeded or failed. If I'm understanding RFC 3748 you end up sending an eap success or failure packet even if the method supports protected result indication. Is my understanding correct? First, how should we handle cases where the protected result disagrees with the failure/success message? Secondly, we should wait for the failure/success message before deciding whether the context is established or not? From nico@cryptonector.com Thu Jul 7 11:46:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5E821F8569 for ; Thu, 7 Jul 2011 11:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Yv35TWcziqQU for ; Thu, 7 Jul 2011 11:46:09 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86E21F855C for ; Thu, 7 Jul 2011 11:46:09 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 26E82438081 for ; Thu, 7 Jul 2011 11:46:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=k5TVAhijlLS+UdmzIl3hR 9U54y+zQH59IK/pQeVsTMynrGwJZf1G8pu8eRVVNRnAP6BxT3LVfcuA97KxTi1rl STViCFpbI90KcaSc3I0qVwqqHOCTxZtTL7NGCvy0GcnPx74ad48+bq2Z2UjgxUZM 5vH5A9jbkdH1Zk0jco6eKU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6Lv2mDY5FEMEaVb1aDu/ SxT4IzM=; b=vMUti+cMsE24aFVyW6n0RwUGiE8XgtfBQ3JL88UBArsVMdgvRG6O /kYxtJdZAyne+mOtvPG/m1S4fm2Wa0E94mAz+NWpDbJyl8+6VW9OOrDlD+92cuxg CAeKiWJBYSN+EHxhfrUhx7lA8DlyBpx61lCKswOlQCNEn8Josr5oxDo= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 0CA6843806C for ; Thu, 7 Jul 2011 11:46:09 -0700 (PDT) Received: by pvh18 with SMTP id 18so914629pvh.31 for ; Thu, 07 Jul 2011 11:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.161 with SMTP id f1mr1570252pbm.186.1310064363630; Thu, 07 Jul 2011 11:46:03 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Thu, 7 Jul 2011 11:46:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Jul 2011 13:46:03 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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, 07 Jul 2011 18:46:10 -0000 On Thu, Jul 7, 2011 at 12:47 PM, Sam Hartman wrote: > If I'm understanding RFC 3748 you end up sending an eap success or > failure packet even if the method supports protected result indication. > Is my understanding correct? Looking at RFC2716 (EAP-TLS), yes, that exactly so. I don't know how representative EAP-TLS is, but there we have protected _failure_ notifications only, followed by an unprotected echo of it, well, IIUC. I don't see a protected success message... > First, how should we handle cases where the protected result disagrees > with the failure/success message? If we get a shared key out of the method then GSS-EAP should probably use it to construct its own protected success and failure messages (which should be sent in addition to, and in parallel with the EAP messages). If not then GSS-EAP should use EAP as it is, with all the same exact issues as EAP. > Secondly, we should wait for the failure/success message before deciding > whether the context is established or not? Yes. But the security context could be PROT_READY before that. Nico -- From lukeh@padl.com Thu Jul 7 11:48:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1F71F0C8D for ; Thu, 7 Jul 2011 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ryb5OAVPCWgu for ; Thu, 7 Jul 2011 11:48:57 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5D21C1F0C55 for ; Thu, 7 Jul 2011 11:48:57 -0700 (PDT) Received: by us.padl.com with ESMTP id p67ImnA6032141; Thu, 7 Jul 2011 14:48:53 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 7 Jul 2011 18:48:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <841F2CCE-A91D-4990-A512-CADB69EF04F6@padl.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: abfab@ietf.org Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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, 07 Jul 2011 18:48:58 -0000 > If we get a shared key out of the method then GSS-EAP should probably > use it to construct its own protected success and failure messages > (which should be sent in addition to, and in parallel with the EAP > messages). AFAIK we only get a shared key on success. We do send unprotected error = messages at present. I need to check the code to see if we send protected error messages in = the post-EAP exchange. If we don't we probably should, this isn't too = hard as that exchange is already protected anyway. Perhaps it just works = :-) -- Luke= From hartmans@painless-security.com Thu Jul 7 12:02:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA8921F85F5 for ; Thu, 7 Jul 2011 12:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 r0fVrMHStdgB for ; Thu, 7 Jul 2011 12:02:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7821F0CC1 for ; Thu, 7 Jul 2011 12:01:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DC02520156; Thu, 7 Jul 2011 15:00:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 64050437D; Thu, 7 Jul 2011 15:01:17 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org,lukeh@padl.com Date: Thu, 07 Jul 2011 15:01:17 -0400 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] token encoding 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, 07 Jul 2011 19:02:43 -0000 As discussed we're looking at having a MIC token in the final message that indicates the checksum of everything in the last token. It's format currently is * DER encoding of the mechanism OID * 2 byte outer token type Then for each inner token besides the MIC token: * 4 byte type * value of the token In particular, the length of the subtokens are not included. I think we should either include the lengths in the MIC or have a convincing argument why you can't move bytes around between one subtoken and other by attacking the lengths. I think this is safe; I'd appreciate though if someone else would explain why they think it's safe and see if that matches up with my understanding. Alternatively, say that you want the length included. From nico@cryptonector.com Thu Jul 7 12:10:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65F721F8583 for ; Thu, 7 Jul 2011 12:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 jUCsPw-0Q00z for ; Thu, 7 Jul 2011 12:10:08 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6521F8524 for ; Thu, 7 Jul 2011 12:10:07 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 2C0E9674070 for ; Thu, 7 Jul 2011 12:10:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Ff1us2NSOSJacGbx9ancZ pIsIVK3DQ+MYwX5CeR90wO/DXigWmliWRqiNmiIeW6pt34n7/fg9oCDr2/mAy5Ic zpZmGHhwgWwQobssbOxXtEAYR3HtoJTB4DWEhsvpNpznHKwoERDzx84+oicGuSZA OPL53Vx9ZFhv/+W2ZsoP3k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=G59fR3NmIFi8gT5Hb602 +9pzVBA=; b=jvc/Udun8ofQ03Tk/bir9yi8Uijnx6Ooalw49vhaGXe9as2TLmxj FwLTeuD1gtFSr5e4RTyS+CEiiZjHeIB5CBxIXm9ysD/DMGKxdsGXkHOzU8vKsyiS 3NonCHsbPt7qfhWXBx/05kH1wpt7fXkh/p/9d9+gX/NflJa9z1gm6AM= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id B284D674078 for ; Thu, 7 Jul 2011 12:10:04 -0700 (PDT) Received: by pvh18 with SMTP id 18so937432pvh.31 for ; Thu, 07 Jul 2011 12:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.0.234 with SMTP id 10mr1602214pbh.52.1310065804095; Thu, 07 Jul 2011 12:10:04 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Thu, 7 Jul 2011 12:10:04 -0700 (PDT) In-Reply-To: <841F2CCE-A91D-4990-A512-CADB69EF04F6@padl.com> References: <841F2CCE-A91D-4990-A512-CADB69EF04F6@padl.com> Date: Thu, 7 Jul 2011 14:10:04 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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, 07 Jul 2011 19:10:09 -0000 On Thu, Jul 7, 2011 at 1:48 PM, Luke Howard wrote: >> If we get a shared key out of the method then GSS-EAP should probably >> use it to construct its own protected success and failure messages >> (which should be sent in addition to, and in parallel with the EAP >> messages). > > AFAIK we only get a shared key on success. We do send unprotected error messages at present. It seems that with EAP-TLS you get a shared key (between the peer and server) before success or failure is determined. I guess that's because success/failure hinges on authorization decisions made after the TLS handshake succeeds. OTOH, if the TLS handshake fails, it fails. This probably all depends heavily on which method we're talking about, which is why I said "if" we get a shared key... > I need to check the code to see if we send protected error messages in the post-EAP exchange. If we don't we probably should, this isn't too hard as that exchange is already protected anyway. Perhaps it just works :-) :) Nico -- From Josh.Howlett@ja.net Fri Jul 8 00:23:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E8C21F8781 for ; Fri, 8 Jul 2011 00:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, 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 V9ibEP51sZQR for ; Fri, 8 Jul 2011 00:23:30 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id ADAE121F8592 for ; Fri, 8 Jul 2011 00:23:27 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 51DFF1A9C3D7_E16B06EB; Fri, 8 Jul 2011 07:23:26 +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 41EB01A9BFE3_E16B06EF; Fri, 8 Jul 2011 07:23:26 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 8 Jul 2011 08:23:24 +0100 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Interactions between EAP and GSS EAP state machines Thread-Index: AQHMPM4Bbtw+LiDz1km2K/w1QEgaFJTiBjUA Date: Fri, 8 Jul 2011 07:23:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <4FE720ACB329064988D10C31A580BB40@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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 Jul 2011 07:23:31 -0000 >First, how should we handle cases where the protected result disagrees >with the failure/success message? It was my understanding that the protected response is authoritative, and the unprotected response is ignored. Alan? >Secondly, we should wait for the failure/success message before deciding >whether the context is established or not? Hmm, isn't the context establishment ultimately dependent on receipt of the MSK? The protected response is within the tunnel, the MSK is outside the tunnel. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Fri Jul 8 06:51:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3319D21F8A1B for ; Fri, 8 Jul 2011 06:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Jzb1qxQdgxWi for ; Fri, 8 Jul 2011 06:51:16 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 58CAB21F8A18 for ; Fri, 8 Jul 2011 06:51:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A5F792033D; Fri, 8 Jul 2011 09:50:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4E9DE437D; Fri, 8 Jul 2011 09:51:05 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Fri, 08 Jul 2011 09:51:05 -0400 In-Reply-To: (Josh Howlett's message of "Fri, 8 Jul 2011 07:23:23 +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] Interactions between EAP and GSS EAP state machines 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 Jul 2011 13:51:17 -0000 >>>>> "Josh" == Josh Howlett writes: >> First, how should we handle cases where the protected result disagrees >> with the failure/success message? Josh> It was my understanding that the protected response is authoritative, and Josh> the unprotected response is ignored. Alan? >> Secondly, we should wait for the failure/success message before deciding >> whether the context is established or not? Josh> Hmm, isn't the context establishment ultimately dependent on receipt of Josh> the MSK? The protected response is within the tunnel, the MSK is outside Josh> the tunnel. What is this tunnel of which you speak? At this layer, both passthrough authenticators and tunnel methods are somewhat invisible to us. That's absolutely true on the initiator. On the acceptor, it's more complex; we want to write guidance that works with a full or passthrough authenticator. From hartmans@painless-security.com Fri Jul 8 06:53:19 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0321F88BF for ; Fri, 8 Jul 2011 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 QAA8siEYUXpt for ; Fri, 8 Jul 2011 06:53:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A24D221F8890 for ; Fri, 8 Jul 2011 06:53:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6171D2033D; Fri, 8 Jul 2011 09:52:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2B437437D; Fri, 8 Jul 2011 09:53:10 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org References: Date: Fri, 08 Jul 2011 09:53:10 -0400 In-Reply-To: (Sam Hartman's message of "Thu, 07 Jul 2011 15:01:17 -0400") 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: Re: [abfab] token encoding 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 Jul 2011 13:53:19 -0000 >>>>> "Sam" == Sam Hartman writes: Sam> As discussed we're looking at having a MIC token in the final message Sam> that indicates the checksum of everything in the last token. Sam> It's format currently is Sam> * DER encoding of the mechanism OID Sam> * 2 byte outer token type Sam> Then for each inner token besides the MIC token: Sam> * 4 byte type Sam> * value of the token Sam> In particular, the length of the subtokens are not included. Sam> I think we should either include the lengths in the MIC or have a Sam> convincing argument why you can't move bytes around between one subtoken Sam> and other by attacking the lengths. No, this encoding is not safe. As far as I can tell you can simply increase the length of one subtoken to cover other subtokens. For example you could cause a vendor ID to eat some subtoken you didn't like as an attacker. Other attacks also may be possible. However I think we need to include the length. I'll write the spec accordingly and will update the code. From aland@deployingradius.com Fri Jul 8 07:54:34 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7C21F86D7 for ; Fri, 8 Jul 2011 07:54:34 -0700 (PDT) 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 zKRqn3Vax2Dd for ; Fri, 8 Jul 2011 07:54:33 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6821F86C5 for ; Fri, 8 Jul 2011 07:54:33 -0700 (PDT) Message-ID: <4E171A24.5040802@deployingradius.com> Date: Fri, 08 Jul 2011 16:54:28 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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 Jul 2011 14:54:34 -0000 Josh Howlett wrote: >> First, how should we handle cases where the protected result disagrees >> with the failure/success message? > > It was my understanding that the protected response is authoritative, and > the unprotected response is ignored. Alan? They should match, and the unprotected response needs to be sent for the EAP state machine to finish. But that should be it. Alan DeKok. From internet-drafts@ietf.org Mon Jul 11 16:22:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DEC11E839B; Mon, 11 Jul 2011 16:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Gi-lTtXJ4B75; Mon, 11 Jul 2011 16:22:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B714111E838C; Mon, 11 Jul 2011 16:22:25 -0700 (PDT) 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: 3.55 Message-ID: <20110711232225.16863.55966.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 16:22:25 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 23:22:26 -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 Ac= cess Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-02.txt Pages : 32 Date : 2011-07-11 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-02.txt From Josh.Howlett@ja.net Tue Jul 12 02:15:24 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEF621F90B6 for ; Tue, 12 Jul 2011 02:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 vy8kj1k9cI-Q for ; Tue, 12 Jul 2011 02:15:23 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id A480721F90B0 for ; Tue, 12 Jul 2011 02:15:23 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0F5CB4A6B65_E1C10A9B; Tue, 12 Jul 2011 09:15:21 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 00F4B4A6B4E_E1C10A9F; Tue, 12 Jul 2011 09:15:21 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Tue, 12 Jul 2011 10:15:11 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Interactions between EAP and GSS EAP state machines Thread-Index: AQHMPM4Bbtw+LiDz1km2K/w1QEgaFJTiBjUAgABsbgSABfwxgA== Date: Tue, 12 Jul 2011 09:15:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 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] Interactions between EAP and GSS EAP state machines 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 Jul 2011 09:15:24 -0000 > >> Secondly, we should wait for the failure/success message before >deciding > >> whether the context is established or not? > > Josh> Hmm, isn't the context establishment ultimately dependent on >receipt of > Josh> the MSK? The protected response is within the tunnel, the MSK >is outside > Josh> the tunnel. > >What is this tunnel of which you speak? The method; I was assuming a tunnelled method. >At this layer, both passthrough >authenticators and tunnel methods are somewhat invisible to us. That's >absolutely true on the initiator. On the acceptor, it's more complex; we >want to write guidance that works with a full or passthrough >authenticator. Isn't it sufficient for the acceptor to conclude success if the method exposes the keying material and parameters per section 2 of RFC5247? That's true for both full and passthrough authenticators. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Jul 12 05:33:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F4D21F8FD6 for ; Tue, 12 Jul 2011 05:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knTnyr6BUZm1 for ; Tue, 12 Jul 2011 05:33:49 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82521F8FD3 for ; Tue, 12 Jul 2011 05:33:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BB90620378; Tue, 12 Jul 2011 08:33:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D48D5437D; Tue, 12 Jul 2011 08:33:34 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Tue, 12 Jul 2011 08:33:34 -0400 In-Reply-To: (Josh Howlett's message of "Tue, 12 Jul 2011 09:15:10 +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] Interactions between EAP and GSS EAP state machines 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 Jul 2011 12:33:50 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> Isn't it sufficient for the acceptor to conclude success if the method Josh> exposes the keying material and parameters per section 2 of RFC5247? Josh> That's true for both full and passthrough authenticators. It needs to happen in consistent timing with the initiator. I think Alan is right hear: the state machine is far simpler if you wait for the actual success message. Note that since the RADIUS server is going to wait for that before sending you access accept, you don't have much of a choice. --Sam From Josh.Howlett@ja.net Tue Jul 12 08:22:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CAB21F856A for ; Tue, 12 Jul 2011 08:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 Q+u6++vq93Vj for ; Tue, 12 Jul 2011 08:22:29 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id CA68321F8568 for ; Tue, 12 Jul 2011 08:22:28 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 765904A6B6C_E1C66B3B; Tue, 12 Jul 2011 15:22:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 691304A6B65_E1C66B3F; Tue, 12 Jul 2011 15:22:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Tue, 12 Jul 2011 16:22:17 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Interactions between EAP and GSS EAP state machines Thread-Index: AQHMPM4Bbtw+LiDz1km2K/w1QEgaFJTiBjUAgABsbgSABfwxgIAAN3BXgAAvHQA= Date: Tue, 12 Jul 2011 15:22:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 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] Interactions between EAP and GSS EAP state machines 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 Jul 2011 15:22:29 -0000 On 12/07/2011 13:33, "Sam Hartman" wrote: >>>>>> "Josh" =3D=3D Josh Howlett writes: > > > Josh> Isn't it sufficient for the acceptor to conclude success if the >method > Josh> exposes the keying material and parameters per section 2 of >RFC5247? > Josh> That's true for both full and passthrough authenticators. > >It needs to happen in consistent timing with the initiator. I think >Alan is right hear: the state machine is far simpler if you wait for the >actual success message. Note that since the RADIUS server is going to >wait for that before sending you access accept, you don't have much of a >choice. Perhaps we're talking cross-purposes here; which success message are we talk about here? I was assuming the EAP Success message. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Jul 12 18:32:12 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07A21F8606 for ; Tue, 12 Jul 2011 18:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IPJvgpFfPaK for ; Tue, 12 Jul 2011 18:32:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0C33121F85FE for ; Tue, 12 Jul 2011 18:32:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 256AF2016A; Tue, 12 Jul 2011 21:31:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A77D2437D; Tue, 12 Jul 2011 21:32:09 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Tue, 12 Jul 2011 21:32:09 -0400 In-Reply-To: (Josh Howlett's message of "Tue, 12 Jul 2011 15:22:17 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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 Jul 2011 01:32:12 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> Perhaps we're talking cross-purposes here; which success message are we Josh> talk about here? I was assuming the EAP Success message. I am too. My point is that you have to wait for the EAP success message even though it's a half round trip or more beyond where you'd ideally terminate things in a fully protected result method with a fully optimized state machine. However, you have to build in too much method knowledge to do anything else and you have to have non-standard AAA behavior. From nico@cryptonector.com Tue Jul 12 18:35:37 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3727821F8B4B for ; Tue, 12 Jul 2011 18:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 dxpkuJ3TCVwP for ; Tue, 12 Jul 2011 18:35:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9D021F862E for ; Tue, 12 Jul 2011 18:35:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id C827A350072 for ; Tue, 12 Jul 2011 18:35:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=QbLyKqdtTG9yoXVr0UnMQKZLklUIgeaE2bNV+ry7T+Y5 WaLZa++ISw2gdCwtuoxUU1y1va59dUkpl4kgR8LBZ8Sv24YuMU6nA7G8AQdT1ugB rfENaiEVLizuc/E88MPhR6ZRUx9rNTyOAiPN1r99TXa45FUGXMfaHGH78WrnWTg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=DnCIMlInHseqS77aTt8cCjCts50=; b=KkD/8l/iFk8 ARTqJxuPtQ89dvUGjANyio+c9jiYetphvw9AATpoE6yR0wu1cLAldOf7i0P9VsdG y39dhO3E+rRqmwztqh2UajnA5WqkoYTB64MleCmElHf2PqJP3BQkTgaNi0fjAJUk dDdPoDpyy3gbsLvOCvnHUaWZl39TfB6o= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id ACD5F350056 for ; Tue, 12 Jul 2011 18:35:32 -0700 (PDT) Received: by pzk5 with SMTP id 5so6181346pzk.31 for ; Tue, 12 Jul 2011 18:35:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.103 with SMTP id d7mr624603pbm.119.1310520932340; Tue, 12 Jul 2011 18:35:32 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Tue, 12 Jul 2011 18:35:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jul 2011 20:35:32 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "abfab@ietf.org" Subject: Re: [abfab] Interactions between EAP and GSS EAP state machines 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 Jul 2011 01:35:37 -0000 On Tue, Jul 12, 2011 at 8:32 PM, Sam Hartman wrote: >>>>>> "Josh" =3D=3D Josh Howlett writes: > > =C2=A0 =C2=A0Josh> Perhaps we're talking cross-purposes here; which succe= ss message are we > =C2=A0 =C2=A0Josh> talk about here? I was assuming the EAP Success messag= e. > > I am too. =C2=A0My point is that you have to wait for the EAP success mes= sage > even though it's a half round trip or more beyond where you'd ideally > terminate things in a fully protected result method with a fully > optimized state machine. =C2=A0However, you have to build in too much met= hod > knowledge to do anything else and you have to have non-standard AAA > behavior. Right. That half-round-trip is a price to pay for using EAP/AAA. And it's another reason to want fast re-auth. Nico -- From ietf@augustcellars.com Fri Jul 22 11:10:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2A021F8AEC for ; Fri, 22 Jul 2011 11:10:48 -0700 (PDT) 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 qnBvg5imUv0O for ; Fri, 22 Jul 2011 11:10:42 -0700 (PDT) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFDF21F8880 for ; Fri, 22 Jul 2011 11:10:42 -0700 (PDT) Received: from TITUS (unknown [216.226.38.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id BB5F92CA4B for ; Fri, 22 Jul 2011 11:10:41 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 22 Jul 2011 14:09:42 -0400 Message-ID: <005301cc489a$88b21f40$9a165dc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxImMPhW6dWx4aMQZ+am/JglM7xyQ== Content-Language: en-us Subject: [abfab] Architecture Document Issue 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 Jul 2011 18:10:48 -0000 I have been reading more documents (always a bad idea) and I think that = the architecture document probably needs to cover some requirements on = the host protocol to be used with ABFAB. At this point in time I have = the following issues that I think need to be checked: 1. What is the assumption that EAP uses when being transported over = RADIUS/DIAMETER. Specifically does it make assumption that the = transport is reliable and thus no retries ever need to be made. If this = is the case then the same assumption would need to either be placed on = the host protocol or on the service provider. 2. What are the trade-offs when running the server as an EAP = pass-through service verses as a tunnel. Specifically what are the = security and functionality requirements that are imposed. Two issues = that I can think of are 1) is the EAP data masked from the server and 2) = if the host protocol is not reliable, does the pass-through service need = to provide the retry service. 3. It would do well to re-state the requirements from GSSAPI in the = document - specifically that it is required the host protocol provide a = reliable service that will deliver items to GSSAP in order. This means = that an underlying protocol that wants to use UDP for some reason will = have additional requirements placed on it that are not there for a TCP = based service. 4. Can a host protocol be writing as a pure query/response system or = does it need to support full bi-directional, full duplex functionality. = Specifically are there any requirements from ABFAB itself (say from EAP) = that make it impossible to run as a query/response system. For example, = if an EAP server needs to do a re-try and generates a message to be sent = down, can this occur? Is this going to be allowed by Radius/Diameter? = Is it an issue for the host protocol to understand. These are issues = that can be lost if one is looking just at the requirements of the host = protocol. (I do not currently know if this is an issue for creating of = a GSS-API context or not.) Jim From Josh.Howlett@ja.net Fri Jul 22 12:26:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C76F21F86A6 for ; Fri, 22 Jul 2011 12:26:27 -0700 (PDT) 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 pAThSNEvqt4W for ; Fri, 22 Jul 2011 12:26:26 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7521F8450 for ; Fri, 22 Jul 2011 12:26:07 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4B34C1A9DEBE_E29CECEB; Fri, 22 Jul 2011 19:26:06 +0000 (GMT) Received: from EXC002.atlas.ukerna.ac.uk (exc002.atlas.ukerna.ac.uk [194.81.3.18]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 330AA1A9AD03_E29CECEF; Fri, 22 Jul 2011 19:26:06 +0000 (GMT) Received: from EXC002.atlas.ukerna.ac.uk ([169.254.2.67]) by EXC002.atlas.ukerna.ac.uk ([169.254.2.67]) with mapi id 14.01.0289.001; Fri, 22 Jul 2011 20:26:06 +0100 From: Josh Howlett To: Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] Architecture Document Issue Thread-Index: AcxImMPhW6dWx4aMQZ+am/JglM7xyQADG1cA Date: Fri, 22 Jul 2011 19:26:05 +0000 Message-ID: In-Reply-To: <005301cc489a$88b21f40$9a165dc0$@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.12.0.110505 x-originating-ip: [194.81.3.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <2A1A1CDAFC62004FAA945BA6FD6F8178@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 19:26:27 -0000 Jim, >1. What is the assumption that EAP uses when being transported over >RADIUS/DIAMETER. Specifically does it make assumption that the transport >is reliable and thus no retries ever need to be made. No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit." I'm not sufficiently familiar with Diameter to comment, but I hope that someone who is will be able to chip in... >2. What are the trade-offs when running the server as an EAP >pass-through service verses as a tunnel. Specifically what are the >security and functionality requirements that are imposed. Two issues >that I can think of are 1) is the EAP data masked from the server and 2) >if the host protocol is not reliable, does the pass-through service need >to provide the retry service. I'm not sure what you mean by tunnel in this context; could you clarify please? >3. It would do well to re-state the requirements from GSSAPI in the >document - specifically that it is required the host protocol provide a >reliable service that will deliver items to GSSAP in order. This means >that an underlying protocol that wants to use UDP for some reason will >have additional requirements placed on it that are not there for a TCP >based service. I have no problem with that. >4. Can a host protocol be writing as a pure query/response system or >does it need to support full bi-directional, full duplex functionality. >Specifically are there any requirements from ABFAB itself (say from EAP) >that make it impossible to run as a query/response system. Not that I can think of. > For example, if an EAP server needs to do a re-try and generates a >message to be sent down, can this occur? I'm not sure what you mean by a "re-try"? Do you mean a re-transmission following an assumed packet loss? Or some kind of unsolicited message? > Is this going to be allowed by Radius/Diameter? Is it an issue for the >host protocol to understand. Regretfully I'm not sure what you mean. Do you have a specific use-case or requirement in mind that we can work through? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Sat Jul 23 12:49:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4BA21F8B38 for ; Sat, 23 Jul 2011 12:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcGnQ7Xtkll5 for ; Sat, 23 Jul 2011 12:49:55 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7D21F87D3 for ; Sat, 23 Jul 2011 12:49:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (16.sub-75-254-153.myvzw.com [75.254.153.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 708E4202B2; Sat, 23 Jul 2011 15:49:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3EAAE422B; Sat, 23 Jul 2011 15:49:50 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <005301cc489a$88b21f40$9a165dc0$@augustcellars.com> Date: Sat, 23 Jul 2011 15:49:50 -0400 In-Reply-To: <005301cc489a$88b21f40$9a165dc0$@augustcellars.com> (Jim Schaad's message of "Fri, 22 Jul 2011 14:09:42 -0400") 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] Architecture Document Issue 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 Jul 2011 19:49:56 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I have been reading more documents (always a bad idea) and I Jim> think that the architecture document probably needs to cover Jim> some requirements on the host protocol to be used with ABFAB. Jim> At this point in time I have the following issues that I think Jim> need to be checked: 1. What is the assumption that EAP uses Jim> when being transported over RADIUS/DIAMETER. Specifically does Jim> it make assumption that the transport is reliable and thus no Jim> retries ever need to be made. If this is the case then the Jim> same assumption would need to either be placed on the host Jim> protocol or on the service provider. No, the RADIUS server would retransmit. GSS does need to reliably transport context tokens. IF 2743 doesn't say that we need to say that here. If 2743 does say that adding a reference seems fine. Jim> 2. What are the trade-offs when running the server as an EAP Jim> pass-through service verses as a tunnel. Specifically what are Jim> the security and functionality requirements that are imposed. Jim> Two issues that I can think of are 1) is the EAP data masked Jim> from the server and 2) if the host protocol is not reliable, Jim> does the pass-through service need to provide the retry Jim> service. Jim> 3. It would do well to re-state the requirements from GSSAPI Jim> in the document - specifically that it is required the host Jim> protocol provide a reliable service that will deliver items to Jim> GSSAP in order. This means that an underlying protocol that Jim> wants to use UDP for some reason will have additional Jim> requirements placed on it that are not there for a TCP based Jim> service. Context tokens must be delivered in order. Per-message tokens need not be delivered in order. s Jim> 4. Can a host protocol be writing as a pure query/response Jim> system or does it need to support full bi-directional, full Jim> duplex functionality. Specifically are there any requirements Jim> from ABFAB itself (say from EAP) that make it impossible to run Jim> as a query/response system. For example, if an EAP server Jim> needs to do a re-try and generates a message to be sent down, Jim> can this occur? Is this going to be allowed by Jim> Radius/Diameter? Is it an issue for the host protocol to Jim> understand. These are issues that can be lost if one is Jim> looking just at the requirements of the host protocol. (I do Jim> not currently know if this is an issue for creating of a Jim> GSS-API context or not.) The GSS-API context protocol is query-response. Per-message protocols can be whatever they like. Jim> Jim Jim> _______________________________________________ abfab mailing Jim> list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Sat Jul 23 14:21:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E20A21F8BB0 for ; Sat, 23 Jul 2011 14:21:21 -0700 (PDT) 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 gEUOXpRRFM3s for ; Sat, 23 Jul 2011 14:21:20 -0700 (PDT) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9135521F8B90 for ; Sat, 23 Jul 2011 14:21:20 -0700 (PDT) Received: from TITUS (unknown [130.129.67.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id C46A82C9FD; Sat, 23 Jul 2011 14:21:19 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , References: <005301cc489a$88b21f40$9a165dc0$@augustcellars.com> In-Reply-To: Date: Sat, 23 Jul 2011 17:20:18 -0400 Message-ID: <009b01cc497e$540962f0$fc1c28d0$@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: AQMhcSlpjt+GrzW6u6Swbt/6UP4N3JJPv5fQ Content-Language: en-us Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 21:21:21 -0000 Josh, Good to hear from you. > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@ja.net] > Sent: Friday, July 22, 2011 3:26 PM > To: Jim Schaad; abfab@ietf.org > Subject: Re: [abfab] Architecture Document Issue > > Jim, > > >1. What is the assumption that EAP uses when being transported over > >RADIUS/DIAMETER. Specifically does it make assumption that the > >transport is reliable and thus no retries ever need to be made. > > No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if an EAP > packet is lost in transit between the authenticating peer and the NAS (or vice > versa), the NAS will retransmit." > > I'm not sufficiently familiar with Diameter to comment, but I hope that > someone who is will be able to chip in... Actually that would make the assumption be true. If it is the job of the NAS to do the retransmit then the assumption is that the RADIUS layer is going to be a reliable transport. > > >2. What are the trade-offs when running the server as an EAP > >pass-through service verses as a tunnel. Specifically what are the > >security and functionality requirements that are imposed. Two issues > >that I can think of are 1) is the EAP data masked from the server and > >2) if the host protocol is not reliable, does the pass-through service > >need to provide the retry service. > > I'm not sure what you mean by tunnel in this context; could you clarify > please? Ok - from the response to the above statement, it means that the NAS MUST operate according to the rules of being an EAP pass-through service. It cannot just blindly pass the EAP packets on to the acceptor w/o ever looking at them. It needs to filter out known bad packets as well as dealing with the rules of retransmission. > > >3. It would do well to re-state the requirements from GSSAPI in the > >document - specifically that it is required the host protocol provide a > >reliable service that will deliver items to GSSAP in order. This means > >that an underlying protocol that wants to use UDP for some reason will > >have additional requirements placed on it that are not there for a TCP > >based service. > > I have no problem with that. > > >4. Can a host protocol be writing as a pure query/response system or > >does it need to support full bi-directional, full duplex functionality. > >Specifically are there any requirements from ABFAB itself (say from > >EAP) that make it impossible to run as a query/response system. > > Not that I can think of. > > > For example, if an EAP server needs to do a re-try and generates a > >message to be sent down, can this occur? > > I'm not sure what you mean by a "re-try"? Do you mean a re-transmission > following an assumed packet loss? Or some kind of unsolicited message? > > > Is this going to be allowed by Radius/Diameter? Is it an issue for > >the host protocol to understand. > > Regretfully I'm not sure what you mean. Do you have a specific use-case or > requirement in mind that we can work through? We can change the questions a bit at this point. Based on your responses we can make the following assumptions: 1. EAP over Radius is assumed to be running on a reliable transport. 2. EAP over GSS-API is assumed to be running on a reliable transport. If the transport is not reliable then it must be made reliable by the host protocol according to the rules of using GSS-API. 3. The current assumption is that the NAS (using the Radius terminology) and the GSS-API acceptor are in the same location thus there is no transport between them. This removes much of the issue that I was worried about as we can now assume there is never a reason for an EAP server to retransmit an EAP message. The only reason for this not to be true would be if statement 3 was not true AND there was an unreliable transport between the terminus of the Radius system and the service. This means that the GSS-API acceptor is not the NAS. The NAS is going to do retransmission of EAP messages. The GSS-API would need to potentially need to catch the retransmission and remove duplicate messages. Ok - if we make the above assumptions then it might not be necessary to have a "NAS" that does the retransmission of EAP messages. There would never be any reason to assume that they are ever going to be lost and thus need to get retransmitted as we have defined that there is a reliable transport all of the way through. The next question then is does the server need to act as a EAP pass-through agent, or can it just tunnel the messages from the EAP side to the GSS-API side w/o ever looking at the content of the message and following the rules of an EAP pass-through agent (i.e. drop messages on the floor due to the value of the code field and so forth). Jim > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited by > guarantee which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG From leifj@sunet.se Sun Jul 24 18:24:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A821F85E3 for ; Sun, 24 Jul 2011 18:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnzAR1aUIprX for ; Sun, 24 Jul 2011 18:24:41 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6628621F85DB for ; Sun, 24 Jul 2011 18:24:41 -0700 (PDT) Received: from [10.255.255.58] ([70.25.120.2]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p6P1OKWt028638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jul 2011 03:24:39 +0200 (CEST) Message-ID: <4E2CC5C4.6070301@sunet.se> Date: Mon, 25 Jul 2011 03:24:20 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] slides please... 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 Jul 2011 01:24:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Everyone who is on the agenda should feel free to give slides to the chars in advance of the session starting on Friday. Do not become overly confident and put it off until Thursday! Cheers Leif and Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4sxcQACgkQ8Jx8FtbMZne6gACghxkoLlyRXvRYx8TjL81AzFeW jPwAn3jGny3RkezZ9mS0kb1r/SM0rAnu =Mowg -----END PGP SIGNATURE----- From klaas@wierenga.net Tue Jul 26 10:35:03 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403BC11E810E for ; Tue, 26 Jul 2011 10:35:03 -0700 (PDT) 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 3YBv+wDAmWFN for ; Tue, 26 Jul 2011 10:35:02 -0700 (PDT) Received: from out42-ams.mf.surf.net (out42-ams.mf.surf.net [145.0.1.42]) by ietfa.amsl.com (Postfix) with ESMTP id 522A411E80EC for ; Tue, 26 Jul 2011 10:35:02 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6QHZ00V008503 for ; Tue, 26 Jul 2011 19:35:00 +0200 Received: from 128-107-239-233.cisco.com ([128.107.239.233] helo=sjc-vpnasa-612.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QllWR-000PbR-2S for abfab@ietf.org; Tue, 26 Jul 2011 19:34:23 +0200 Message-ID: <4E2EFAC2.8090100@wierenga.net> Date: Tue, 26 Jul 2011 19:34:58 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vFcFz0bf - 7f339d148655 - 20110726 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.42 Subject: [abfab] abfab final agenda for IETF81 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 Jul 2011 17:35:03 -0000 Hi, Please find below the final (?) agenda. Reminder to the presenters that have not done so yet, please upload your slides! Klaas & Leif --- Friday 9.00-11.30 room 204 B Agenda bashing and Note Well (5 min) Current Document Status (50 mins) - draft-ietf-abfab-gss-eap ( 15 mins, Sam Hartman) - draft-ietf-abfab-gss-eap-naming (15 mins, Sam Hartman) - draft-winter-abfab-eapapplicability (5 mins, Joe Salowey) - draft-ietf-abfab-aaa-saml (5 mins, Sam Hartman) - draft-jones-diameter-abfab (5 mins, Hannes Tschofenig) - draft-lear-abfab-arch (5 min, Chairs) Proposed and New Documents (80 mins) - draft-smith-abfab-oidregistry (5 mins, Rhys Smith) - draft-smith-abfab-usability-ui-considerations (15 mins, Rhys Smith) - draft-perez-abfab-eap-gss-preauth (20 mins, Alejandro Perez Mendez) - draft-wei-abfab-fcla (20 mins, Yinxing Wei) - draft-mrw-abfab-multihop-fed (20 mins, Margaret Wasserman) Administrivia and AOB (15 min) - Updating the milestones and timeline From leifj@sunet.se Tue Jul 26 10:35:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8311E8119 for ; Tue, 26 Jul 2011 10:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBZr9290VrIV for ; Tue, 26 Jul 2011 10:35:12 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8B11E80EC for ; Tue, 26 Jul 2011 10:35:12 -0700 (PDT) Received: from [130.129.17.132] ([130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p6QHZ6jD019781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 19:35:10 +0200 (CEST) Message-ID: <4E2EFAC9.80307@sunet.se> Date: Tue, 26 Jul 2011 19:35:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] updated agenda 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 Jul 2011 17:35:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've updated the agenda based on some minor late-minute changes. Nothing major, cf https://datatracker.ietf.org/meeting/81/materials.html Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk4u+skACgkQ8Jx8FtbMZneDhACfUQWnFjx++HOlrYz9T7YJwTfC 8jYAmK2WiiNYUPi7zBL/csj2YdilTOY= =d+MC -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Wed Jul 27 05:44:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDAD21F8B07 for ; Wed, 27 Jul 2011 05:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 GymwP5E2esLZ for ; Wed, 27 Jul 2011 05:44:35 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0127021F8ACE for ; Wed, 27 Jul 2011 05:44:35 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 24AA71A9B47F_E300831B; Wed, 27 Jul 2011 12:44:33 +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 DD5151A9B459_E300830F; Wed, 27 Jul 2011 12:44:32 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 13:44:32 +0100 From: Josh Howlett To: Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] Architecture Document Issue Thread-Index: AcxImMPhW6dWx4aMQZ+am/JglM7xyQADG1cAADQvyQAAuT7MgA== Date: Wed, 27 Jul 2011 12:44:30 +0000 Message-ID: In-Reply-To: <009b01cc497e$540962f0$fc1c28d0$@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.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 12:44:36 -0000 Jim, >>=20 >> >1. What is the assumption that EAP uses when being transported over >> >RADIUS/DIAMETER. Specifically does it make assumption that the >> >transport is reliable and thus no retries ever need to be made. >>=20 >> No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if an EAP >> packet is lost in transit between the authenticating peer and the NAS >>(or >vice >> versa), the NAS will retransmit." >>=20 >> I'm not sufficiently familiar with Diameter to comment, but I hope that >> someone who is will be able to chip in... > >Actually that would make the assumption be true. If it is the job of the >NAS to do the retransmit then the assumption is that the RADIUS layer is >going to be a reliable transport. That's not the conclusion I would draw, but perhaps I'm misunderstanding you. The fact that the NAS has to consider retransmission is a consequence of the fact that the underlying transport is not reliable. >>=20 >> >2. What are the trade-offs when running the server as an EAP >> >pass-through service verses as a tunnel. Specifically what are the >> >security and functionality requirements that are imposed. Two issues >> >that I can think of are 1) is the EAP data masked from the server and >> >2) if the host protocol is not reliable, does the pass-through service >> >need to provide the retry service. >>=20 >> I'm not sure what you mean by tunnel in this context; could you clarify >> please? > >Ok - from the response to the above statement, it means that the NAS MUST >operate according to the rules of being an EAP pass-through service. It >cannot just blindly pass the EAP packets on to the acceptor w/o ever >looking >at them. It needs to filter out known bad packets as well as dealing with >the rules of retransmission. Yes; this is laid out in RFC 3748; specifically section 2.3 ('Pass-Through Behaviour'). >>=20 >> >3. It would do well to re-state the requirements from GSSAPI in the >> >document - specifically that it is required the host protocol provide a >> >reliable service that will deliver items to GSSAP in order. This means >> >that an underlying protocol that wants to use UDP for some reason will >> >have additional requirements placed on it that are not there for a TCP >> >based service. >>=20 >> I have no problem with that. >>=20 >> >4. Can a host protocol be writing as a pure query/response system or >> >does it need to support full bi-directional, full duplex functionality. >> >Specifically are there any requirements from ABFAB itself (say from >> >EAP) that make it impossible to run as a query/response system. >>=20 >> Not that I can think of. >>=20 >> > For example, if an EAP server needs to do a re-try and generates a >> >message to be sent down, can this occur? >>=20 >> I'm not sure what you mean by a "re-try"? Do you mean a re-transmission >> following an assumed packet loss? Or some kind of unsolicited message? >>=20 >> > Is this going to be allowed by Radius/Diameter? Is it an issue for >> >the host protocol to understand. >>=20 >> Regretfully I'm not sure what you mean. Do you have a specific use-case >>or >> requirement in mind that we can work through? > >We can change the questions a bit at this point. Based on your responses >we >can make the following assumptions: > >1. EAP over Radius is assumed to be running on a reliable transport. >2. EAP over GSS-API is assumed to be running on a reliable transport. If >the transport is not reliable then it must be made reliable by the host >protocol according to the rules of using GSS-API. These aren't assumptions of the architecture, although I believe it will end up being true in practice. >3. The current assumption is that the NAS (using the Radius terminology) >and the GSS-API acceptor are in the same location thus there is no >transport >between them. Correct. Although bear in mind there could be intermediate RADIUS proxies between the NAS and the EAP server. >This removes much of the issue that I was worried about as we can now >assume >there is never a reason for an EAP server to retransmit an EAP message. I think this is, in practice, unlikely but not impossible if unreliable RADIUS transport is used (ie. RADIUS over TCP). >The only reason for this not to be true would be if statement 3 was not >true >AND there was an unreliable transport between the terminus of the Radius >system and the service. This means that the GSS-API acceptor is not the >NAS. The NAS is going to do retransmission of EAP messages. The GSS-API >would need to potentially need to catch the retransmission and remove >duplicate messages. I think I would disagree with this characterisation; the GSS acceptor is acting very much like a NAS at a protocol level. In terms of implementation, it could looks quite different, of course. In our GSS EAP implementation, the acceptor will eventually call out to a completely separate process (the Identity Selector) which will manage the EAP state machine. >Ok - if we make the above assumptions then it might not be necessary to >have >a "NAS" that does the retransmission of EAP messages. There would never >be >any reason to assume that they are ever going to be lost and thus need to >get retransmitted as we have defined that there is a reliable transport >all >of the way through. I agree, although not for the reasons you state! It's more likely that reliable transport will be deployed (ie. RADIUS over TCP, rather than UDP as is commonly the case today). >The next question then is does the server need to act as a EAP >pass-through >agent, or can it just tunnel the messages from the EAP side to the GSS-API >side w/o ever looking at the content of the message and following the >rules >of an EAP pass-through agent (i.e. drop messages on the floor due to the >value of the code field and so forth). It could do that, but it wouldn't conform to the existing architecture. Why would you want to do this? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Wed Jul 27 07:31:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC5C21F855A for ; Wed, 27 Jul 2011 07:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOkMdFuEmyiu for ; Wed, 27 Jul 2011 07:31:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A465821F854F for ; Wed, 27 Jul 2011 07:31:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1330.meeting.ietf.org [130.129.19.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B4A3E2034A; Wed, 27 Jul 2011 10:33:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5EC0C422B; Wed, 27 Jul 2011 10:31:08 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Wed, 27 Jul 2011 10:31:08 -0400 In-Reply-To: (Josh Howlett's message of "Wed, 27 Jul 2011 12:44:30 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 14:31:10 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> Jim, >>> >>> >1. What is the assumption that EAP uses when being transported >>> over >RADIUS/DIAMETER. Specifically does it make assumption >>> that the >transport is reliable and thus no retries ever need to >>> be made. >>> >>> No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if >>> an EAP packet is lost in transit between the authenticating peer >>> and the NAS (or >> vice >>> versa), the NAS will retransmit." >>> >>> I'm not sufficiently familiar with Diameter to comment, but I >>> hope that someone who is will be able to chip in... >> >> Actually that would make the assumption be true. If it is the >> job of the NAS to do the retransmit then the assumption is that >> the RADIUS layer is going to be a reliable transport. Josh> That's not the conclusion I would draw, but perhaps I'm Josh> misunderstanding you. The fact that the NAS has to consider Josh> retransmission is a consequence of the fact that the Josh> underlying transport is not reliable. What Jim is saying is that RADIUS provides a reliable service to EAP. That is, RADIUS is responsible for making sure that messages reliably get from the NAS to the EAP server and back. I believe he's approximately right and that the differences are not things we need to worry abuot. >>> >>> >3. It would do well to re-state the requirements from GSSAPI >>> in the >document - specifically that it is required the host >>> protocol provide a >reliable service that will deliver items to >>> GSSAP in order. This means >that an underlying protocol that >>> wants to use UDP for some reason will >have additional >>> requirements placed on it that are not there for a TCP >based >>> service. >>> >>> I have no problem with that. >>> >>> >4. Can a host protocol be writing as a pure query/response >>> system or >does it need to support full bi-directional, full >>> duplex functionality. >Specifically are there any requirements >>> from ABFAB itself (say from >EAP) that make it impossible to run >>> as a query/response system. >>> >>> Not that I can think of. >>> >>> > For example, if an EAP server needs to do a re-try and >>> generates a >message to be sent down, can this occur? >>> >>> I'm not sure what you mean by a "re-try"? Do you mean a >>> re-transmission following an assumed packet loss? Or some kind >>> of unsolicited message? >>> >>> > Is this going to be allowed by Radius/Diameter? Is it an >>> issue for >the host protocol to understand. >>> >>> Regretfully I'm not sure what you mean. Do you have a specific >>> use-case or requirement in mind that we can work through? >> >> We can change the questions a bit at this point. Based on your >> responses we can make the following assumptions: >> >> 1. EAP over Radius is assumed to be running on a reliable >> transport. 2. EAP over GSS-API is assumed to be running on a >> reliable transport. If the transport is not reliable then it >> must be made reliable by the host protocol according to the rules >> of using GSS-API. Josh> These aren't assumptions of the architecture, although I Josh> believe it will end up being true in practice. I actually believe these are carefully crafted aspects of the architecture. Making sure both the above could be assumed was something I have been very careful to try and achieve since the issues were discussed in the feasibility analysis. >> 3. The current assumption is that the NAS (using the Radius >> terminology) and the GSS-API acceptor are in the same location >> thus there is no transport between them. Josh> Correct. Although bear in mind there could be intermediate Josh> RADIUS proxies between the NAS and the EAP server. >> This removes much of the issue that I was worried about as we can >> now assume there is never a reason for an EAP server to >> retransmit an EAP message. Josh> I think this is, in practice, unlikely but not impossible if Josh> unreliable RADIUS transport is used (ie. RADIUS over TCP). There is never a case where an EAP retransmission is visible at the GSS layer. I think that's enough to get the properties Jim is interested in. Arguing about whether a duplicate EAP request is a RADIUS retransmission or an EAP server retransmission is implementation pedantry; I think 3748 resolves it as a RADIUS issue, but it doesn't much matter. >> The only reason for this not to be true would be if statement 3 >> was not true AND there was an unreliable transport between the >> terminus of the Radius system and the service. This means that >> the GSS-API acceptor is not the NAS. The NAS is going to do >> retransmission of EAP messages. The GSS-API would need to >> potentially need to catch the retransmission and remove duplicate >> messages. Josh> I think I would disagree with this characterisation; the GSS Josh> acceptor is acting very much like a NAS at a protocol Josh> level. In terms of implementation, it could looks quite Josh> different, of course. In our GSS EAP implementation, the Josh> acceptor will eventually call out to a completely separate Josh> process (the Identity Selector) which will manage the EAP Josh> state machine. >> Ok - if we make the above assumptions then it might not be >> necessary to have a "NAS" that does the retransmission of EAP >> messages. There would never be any reason to assume that they >> are ever going to be lost and thus need to get retransmitted as >> we have defined that there is a reliable transport all of the way >> through. Josh> I agree, although not for the reasons you state! It's more Josh> likely that reliable transport will be deployed (ie. RADIUS Josh> over TCP, rather than UDP as is commonly the case today). >> The next question then is does the server need to act as a EAP >> pass-through agent, or can it just tunnel the messages from the >> EAP side to the GSS-API side w/o ever looking at the content of >> the message and following the rules of an EAP pass-through agent >> (i.e. drop messages on the floor due to the value of the code >> field and so forth). Josh> It could do that, but it wouldn't conform to the existing Josh> architecture. Why would you want to do this? Josh> Josh. Josh> JANET(UK) is a trading name of The JNT Association, a company Josh> limited by guarantee which is registered in England under Josh> No. 2881024 and whose Registered Office is at Lumen House, Josh> Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG Josh> _______________________________________________ abfab mailing Josh> list abfab@ietf.org Josh> https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Wed Jul 27 08:01:22 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B28021F896E for ; Wed, 27 Jul 2011 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=-0.308, 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 p9NTSM2Fi+Xc for ; Wed, 27 Jul 2011 08:01:22 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id F321421F8922 for ; Wed, 27 Jul 2011 08:01:21 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C01E04A6B85_E302840B; Wed, 27 Jul 2011 15:01:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id AE7A54A6B84_E302840F; Wed, 27 Jul 2011 15:01:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 16:01:20 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Architecture Document Issue Thread-Index: AcxImMPhW6dWx4aMQZ+am/JglM7xyQADG1cAADQvyQAAuT7MgAADu/bUAAELkwA= Date: Wed, 27 Jul 2011 15:01:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 15:01:22 -0000 > >What Jim is saying is that RADIUS provides a reliable service to >EAP. That is, RADIUS is responsible for making sure that messages >reliably get from the NAS to the EAP server and back. >I believe he's approximately right and that the differences are not >things we need to worry abuot. Right. > Josh> These aren't assumptions of the architecture, although I > Josh> believe it will end up being true in practice. > >I actually believe these are carefully crafted aspects of the >architecture. Really? Neither RADIUS nor some potential host protocols use reliable transports. It's obviously possible to use transports that are reliable, but we don't constrain the architecture to require the use of those. It's true that the GSS acceptor is hidden from this by the API abstraction, but it's possible for a GSS operation to fail because a token is lost by the unreliable transport. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Wed Jul 27 10:16:28 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB22121F876A for ; Wed, 27 Jul 2011 10:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2prQjJ-aBdhW for ; Wed, 27 Jul 2011 10:16:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 61E8921F8760 for ; Wed, 27 Jul 2011 10:16:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1704.meeting.ietf.org [130.129.23.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7CA902034A; Wed, 27 Jul 2011 13:19:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 410B9422B; Wed, 27 Jul 2011 13:16:21 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Wed, 27 Jul 2011 13:16:21 -0400 In-Reply-To: (Josh Howlett's message of "Wed, 27 Jul 2011 15:01:20 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 17:16:29 -0000 >>>>> "Josh" == Josh Howlett writes: >> >> What Jim is saying is that RADIUS provides a reliable service to >> EAP. That is, RADIUS is responsible for making sure that messages >> reliably get from the NAS to the EAP server and back. I believe >> he's approximately right and that the differences are not things >> we need to worry abuot. Josh> Right. Josh> These aren't assumptions of the architecture, although I Josh> believe it will end up being true in practice. >> >> I actually believe these are carefully crafted aspects of the >> architecture. Josh> Really? Neither RADIUS nor some potential host protocols use Josh> reliable transports. It's obviously possible to use transports Josh> that are reliable, but we don't constrain the architecture to Josh> require the use of those. It's true that the GSS acceptor is Josh> hidden from this by the API abstraction, but it's possible for Josh> a GSS operation to fail because a token is lost by the Josh> unreliable transport. No, if RADIUS or the host protocol lose a message they are responsible for retransmitting. It's possible that a connection can fail because retransmissions fail and RADIUS or the host protocol returns a protocol error. Josh> Josh. Josh> JANET(UK) is a trading name of The JNT Association, a company Josh> limited by guarantee which is registered in England under Josh> No. 2881024 and whose Registered Office is at Lumen House, Josh> Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Wed Jul 27 10:25:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28B21F86CA for ; Wed, 27 Jul 2011 10:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 Ub-uWf2p4iht for ; Wed, 27 Jul 2011 10:25:07 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id AA58821F854E for ; Wed, 27 Jul 2011 10:25:07 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AA8644A6B88_E3049F2B; Wed, 27 Jul 2011 17:25:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 988E14A6B84_E3049F2F; Wed, 27 Jul 2011 17:25:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 18:25:06 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Architecture Document Issue Thread-Index: AcxImMPhW6dWx4aMQZ+am/JglM7xyQADG1cAADQvyQAAuT7MgAADu/bUAAELkwAABLlktgAAS9aA Date: Wed, 27 Jul 2011 17:25:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 17:25:08 -0000 >No, if RADIUS or the host protocol lose a message they are responsible >for retransmitting. >It's possible that a connection can fail because retransmissions fail >and RADIUS or the host protocol returns a protocol error. And that to me constitutes an assumption that the transport is not necessarily reliable! Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From alex@um.es Wed Jul 27 10:36:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803E721F8A4D for ; Wed, 27 Jul 2011 10:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxBG-RcYOLEm for ; Wed, 27 Jul 2011 10:36:44 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id A8A5621F8A4B for ; Wed, 27 Jul 2011 10:36:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 3EE975D476 for ; Wed, 27 Jul 2011 19:36:43 +0200 (CEST) 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 t1tvoYicwULq for ; Wed, 27 Jul 2011 19:36:42 +0200 (CEST) Received: from [10.255.254.39] (unknown [216.209.201.186]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 1B5455D474 for ; Wed, 27 Jul 2011 19:36:40 +0200 (CEST) Message-ID: <4E304C85.90308@um.es> Date: Wed, 27 Jul 2011 13:36:05 -0400 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 17:36:45 -0000 Hi Josh, That is also our interpretation of what rfc2743 says: The GSS-API is independent of underlying protocols and addressing structure, and depends on its callers to transport GSS-API-provided data elements. As a result of these factors, it is a caller responsibility to parse communicated messages, separating GSS-API- related data elements from caller-provided data. The GSS-API is independent of connection vs. connectionless orientation of the underlying communications service. Hence, we understand that no assumptions at all can be done regarding the transport. For example, the transport for a GSS-API security association could be as unreliable as RAW UDP packets. Therefore, is our understanding that each GSS mechanism should provide enough information within their tokens to be able to detect and recover from these situations. Indeed, you can see that GSS_API defines the following error codes: GSS_S_DUPLICATE_TOKEN GSS_S_OLD_TOKEN that would be consequently sent when one of the mentioned situations were detected. Just my 2 cents. Regards, Alejandro El 27/07/11 13:25, Josh Howlett escribió: >> No, if RADIUS or the host protocol lose a message they are responsible >> for retransmitting. >> It's possible that a connection can fail because retransmissions fail >> and RADIUS or the host protocol returns a protocol error. > And that to me constitutes an assumption that the transport is not > necessarily reliable! > > Josh. > > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Jul 27 11:14:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7961521F8BE2 for ; Wed, 27 Jul 2011 11:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD0mpCl20FE7 for ; Wed, 27 Jul 2011 11:14:40 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0A58A21F877F for ; Wed, 27 Jul 2011 11:14:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1704.meeting.ietf.org [130.129.23.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 49E3720424; Wed, 27 Jul 2011 14:17:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E2FC8422B; Wed, 27 Jul 2011 14:14:35 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Wed, 27 Jul 2011 14:14:35 -0400 In-Reply-To: (Josh Howlett's message of "Wed, 27 Jul 2011 17:25:05 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Architecture Document Issue 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 Jul 2011 18:14:40 -0000 >>>>> "Josh" == Josh Howlett writes: >> No, if RADIUS or the host protocol lose a message they are >> responsible for retransmitting. It's possible that a connection >> can fail because retransmissions fail and RADIUS or the host >> protocol returns a protocol error. Josh> And that to me constitutes an assumption that the transport is Josh> not necessarily reliable! In that sense there exist no reliable transports. TCP has the same failure. Typically what we mean by reliable transport is that the transport will either deliver a message or signal failure. From hartmans@painless-security.com Wed Jul 27 11:16:51 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50921F8BB9 for ; Wed, 27 Jul 2011 11:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLcED49jv76N for ; Wed, 27 Jul 2011 11:16:51 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3C21F8867 for ; Wed, 27 Jul 2011 11:16:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1704.meeting.ietf.org [130.129.23.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8B2FF20424; Wed, 27 Jul 2011 14:19:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 486D7422B; Wed, 27 Jul 2011 14:16:50 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <4E304C85.90308@um.es> Date: Wed, 27 Jul 2011 14:16:50 -0400 In-Reply-To: <4E304C85.90308@um.es> (Alejandro Perez Mendez's message of "Wed, 27 Jul 2011 13:36:05 -0400") 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] Architecture Document Issue 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 Jul 2011 18:16:51 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> Hence, we understand that no assumptions at all can be Alejandro> done regarding the transport. For example, the transport Alejandro> for a GSS-API security association could be as unreliable Alejandro> as RAW UDP packets. Therefore, is our understanding that Alejandro> each GSS mechanism should provide enough information Alejandro> within their tokens to be able to detect and recover from Alejandro> these situations. Detect yes. Recover from, no. I'm not aware of any existing GSS mechanism that can recover from a lost or corrupted context token. From lear@cisco.com Thu Jul 28 06:57:05 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBD421F8BF1 for ; Thu, 28 Jul 2011 06:57:05 -0700 (PDT) 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.001, 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 LjAJOe68L0YJ for ; Thu, 28 Jul 2011 06:57:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7977C21F8BF0 for ; Thu, 28 Jul 2011 06:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=543; q=dns/txt; s=iport; t=1311861424; x=1313071024; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=q6fHQ413+pONvafgIbgKLPzKIm7WMsG8wbfVkVyJ8Ns=; b=LukZy84rYzZ0c9s4z3p+otHi6B9q9qgLP3r2A+YIhFDsf5CQNEy/aLR/ 3hXFGKgTP6ECvdYu68QSQ0nDnpvrRuvWVCUsZUJANCIAtaDdo7PdM9lUP hkqQsrwI/4lHiwPfTFT6Yvr6yJ827VfLYweemsbk5dyue6RChf0oscNN3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIHAJlpMU6tJV2b/2dsb2JhbABPARRbMAgCBSILAgsDAgECAQI+DQ0ODwEBH4QvowFwB6szgSONJJE3gSuEBoEQBJJ5kQA X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7385587" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2011 13:57:04 +0000 Received: from che-vpn-cluster-2-246.cisco.com (che-vpn-cluster-2-246.cisco.com [10.86.242.246]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SDv2dj019083 for ; Thu, 28 Jul 2011 13:57:03 GMT Message-ID: <4E316AB4.1010205@cisco.com> Date: Thu, 28 Jul 2011 09:57:08 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [abfab] moving forward with abfab architecture 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 Jul 2011 13:57:05 -0000 Dear everyone, I won't be at the ABFAB meeting, but I have discussed with the chairs and authors an approach to move the document forward. As people will recall, we sort of snagged on normative language. The authors have agreed to work to remove that language. What I propose is the following: 1. A new draft that does so in August; 2. Adoption of this document as a working group document; and 3. Track all issues, including those sent in by Jim Schaad. And then regular updates based on the evolution of ABFAB. Eliot From klaas@cisco.com Thu Jul 28 07:01:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D7321F8C2A for ; Thu, 28 Jul 2011 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+z1xm-c8JyJ for ; Thu, 28 Jul 2011 07:01:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9FE21F8C28 for ; Thu, 28 Jul 2011 07:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1015; q=dns/txt; s=iport; t=1311861713; x=1313071313; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5oe5kQwRoBQ2S8QEwCCozAzIZs0lLgSV+CdSaS2/QO0=; b=TsqUQUjNL6k8/BoEtFMq/N73H668xcyA63kQvf4yVVnBnocIRbYrNgsJ Om7k5IroA4bbGHfAUcbJ6bnm0d0439raasaEqmXHkU/EKs0rhWo/X4icn VfxpzlJheUWFPflzJXnKRwzMudb4eWFn7uRszeznkUIDQ11220D3igo3V A=; X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7386649" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jul 2011 14:01:52 +0000 Received: from sjc-vpnasa-556.cisco.com (sjc-vpnasa-556.cisco.com [10.21.106.47]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SE1ppY012373; Thu, 28 Jul 2011 14:01:51 GMT Message-ID: <4E316BCF.3020201@cisco.com> Date: Thu, 28 Jul 2011 16:01:51 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Eliot Lear References: <4E316AB4.1010205@cisco.com> In-Reply-To: <4E316AB4.1010205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] moving forward with abfab architecture 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 Jul 2011 14:01:53 -0000 On 7/28/11 3:57 PM, Eliot Lear wrote: Eliot, > I won't be at the ABFAB meeting, but I have discussed with the chairs > and authors an approach to move the document forward. As people will > recall, we sort of snagged on normative language. The authors have > agreed to work to remove that language. What I propose is the following: > > 1. A new draft that does so in August; > 2. Adoption of this document as a working group document; and So you are not asking to adopt the document as WG document at this time? Why don't you think the draft is far enough ahead to hand over change control to the WG? It seems to me that the issue of the normative language can also be solved for a WG doc.... Klaas > 3. Track all issues, including those sent in by Jim Schaad. > > And then regular updates based on the evolution of ABFAB. > > Eliot > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lear@cisco.com Thu Jul 28 07:29:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB0821F8CAA for ; Thu, 28 Jul 2011 07:29:21 -0700 (PDT) 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 IUXaVmMbF0HX for ; Thu, 28 Jul 2011 07:29:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C5EFC21F8CA2 for ; Thu, 28 Jul 2011 07:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=922; q=dns/txt; s=iport; t=1311863361; x=1313072961; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+WYDwwOG7Rnukk8bbY+jVxVb3O0I47na0yWA/KCSb58=; b=BSf58DlsP38s3cIHqoS2FwO1wbEyrXinwoaiTEbPSgnGHOOEb0Z/z2MS SvW+cDtltyrX8IG97UUR9XHd7rU/dGZRbb6yDD62DyaAwZo6sSesR0pap 02v4ux6YrK/Kve0WhxnhWNckbw9NoqJKX+KEzRIdo/TJfVGt7/KvLMkQd M=; X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7397475" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2011 14:29:16 +0000 Received: from elear-mac.local (che-vpn-cluster-2-287.cisco.com [10.86.243.32]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SETGUQ000369; Thu, 28 Jul 2011 14:29:16 GMT Message-ID: <4E317242.3090309@cisco.com> Date: Thu, 28 Jul 2011 10:29:22 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Klaas Wierenga References: <4E316AB4.1010205@cisco.com> <4E316BCF.3020201@cisco.com> In-Reply-To: <4E316BCF.3020201@cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] moving forward with abfab architecture 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 Jul 2011 14:29:21 -0000 On 7/28/11 10:01 AM, Klaas Wierenga wrote: > On 7/28/11 3:57 PM, Eliot Lear wrote: > > Eliot, > >> I won't be at the ABFAB meeting, but I have discussed with the chairs >> and authors an approach to move the document forward. As people will >> recall, we sort of snagged on normative language. The authors have >> agreed to work to remove that language. What I propose is the >> following: >> >> 1. A new draft that does so in August; >> 2. Adoption of this document as a working group document; and > > So you are not asking to adopt the document as WG document at this > time? Why don't you think the draft is far enough ahead to hand over > change control to the WG? It seems to me that the issue of the > normative language can also be solved for a WG doc.... I would be happy if the WG adopted the draft now, with the understanding that the normative language will be removed. Eliot From leifj@sunet.se Thu Jul 28 10:13:33 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636185E800F for ; Thu, 28 Jul 2011 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WkAjuTyQUhK for ; Thu, 28 Jul 2011 10:13:32 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7146F5E800D for ; Thu, 28 Jul 2011 10:13:32 -0700 (PDT) Received: from [130.129.17.132] (dhcp-1184.meeting.ietf.org [130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p6SHDP8F008554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jul 2011 19:13:30 +0200 (CEST) Message-ID: <4E3198B5.2050604@sunet.se> Date: Thu, 28 Jul 2011 19:13:25 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: abfab@ietf.org References: <4E316AB4.1010205@cisco.com> <4E316BCF.3020201@cisco.com> <4E317242.3090309@cisco.com> In-Reply-To: <4E317242.3090309@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] moving forward with abfab architecture 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 Jul 2011 17:13:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I would be happy if the WG adopted the draft now, with the understanding > that the normative language will be removed. OK so I think we have input for the meeting. Thanks! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4xmLUACgkQ8Jx8FtbMZncnfwCgqKlCB1uxC1ij8cyj8r08HDJc ADcAoK2EKfa/5poB3De60weD/KYdJQuM =R7Mk -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Jul 28 13:14:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A685321F8A70 for ; Thu, 28 Jul 2011 13:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teMers+4WUCK for ; Thu, 28 Jul 2011 13:14:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0A21F8564 for ; Thu, 28 Jul 2011 13:14:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1208.meeting.ietf.org [130.129.18.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6A39A2033D; Thu, 28 Jul 2011 16:17:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 41CD5422B; Thu, 28 Jul 2011 16:14:34 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <4E316AB4.1010205@cisco.com> <4E316BCF.3020201@cisco.com> <4E317242.3090309@cisco.com> Date: Thu, 28 Jul 2011 16:14:34 -0400 In-Reply-To: <4E317242.3090309@cisco.com> (Eliot Lear's message of "Thu, 28 Jul 2011 10:29:22 -0400") 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] moving forward with abfab architecture 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 Jul 2011 20:14:36 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> On 7/28/11 10:01 AM, Klaas Wierenga wrote: >> On 7/28/11 3:57 PM, Eliot Lear wrote: > > Eliot, >> >>> I won't be at the ABFAB meeting, but I have discussed with the >>> chairs and authors an approach to move the document forward. As >>> people will recall, we sort of snagged on normative language. >>> The authors have agreed to work to remove that language. What I >>> propose is the following: >>> >>> 1. A new draft that does so in August; 2. Adoption of this >>> document as a working group document; and >> >> So you are not asking to adopt the document as WG document at >> this time? Why don't you think the draft is far enough ahead to >> hand over change control to the WG? It seems to me that the issue >> of the normative language can also be solved for a WG doc.... Eliot> I would be happy if the WG adopted the draft now, with the Eliot> understanding that the normative language will be removed. If by normative language we're talking about requirements on EAP methods that have moved into draft-ietf-abfab-gss-eap, then I agree. Regardless I'd encourage the WG to adopt now. From internet-drafts@ietf.org Fri Jul 29 08:23:22 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040B811E8090; Fri, 29 Jul 2011 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 ww4seVlXabwF; Fri, 29 Jul 2011 08:23:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0E211E807A; Fri, 29 Jul 2011 08:23:21 -0700 (PDT) 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: 3.57 Message-ID: <20110729152321.12672.57794.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2011 08:23:21 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-00.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, 29 Jul 2011 15:23:22 -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 Ac= cess 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 Filename : draft-ietf-abfab-arch-00.txt Pages : 37 Date : 2011-07-29 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 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 RADIUS, Diameter, GSS, GS2, EAP and 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-arch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-arch-00.txt From leifj@sunet.se Fri Jul 29 10:28:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C373921F8B35 for ; Fri, 29 Jul 2011 10:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 AdmWMioTO1oc for ; Fri, 29 Jul 2011 10:28:06 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id DD83C21F8B1B for ; Fri, 29 Jul 2011 10:28:05 -0700 (PDT) Received: from [130.129.17.132] (dhcp-1184.meeting.ietf.org [130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p6THRxWD001324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jul 2011 19:28:03 +0200 (CEST) Message-ID: <4E32ED9E.5000008@sunet.se> Date: Fri, 29 Jul 2011 19:27:58 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: abfab@ietf.org References: <20110729152321.12672.57794.idtracker@ietfa.amsl.com> In-Reply-To: <20110729152321.12672.57794.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-arch-00.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, 29 Jul 2011 17:28:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/2011 05:23 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. > > Title : Application Bridging for Federated Access Beyond Web (ABFAB) Architecture The chairs approved this version as a WG document based on discussion in the abfab meeting today and the belief based on our review that it now does not contain normative language. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4y7ZsACgkQ8Jx8FtbMZnfw+gCgu1I1C5lLECXaj599sit0ROrp iH8AoMBYbxLn5lyXUXmIniZD62q2ifyl =JKQN -----END PGP SIGNATURE----- From leifj@sunet.se Fri Jul 29 21:13:37 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EBE21F8CB7 for ; Fri, 29 Jul 2011 21:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hHNxvuRMmEh for ; Fri, 29 Jul 2011 21:13:36 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id 59C4021F8CA4 for ; Fri, 29 Jul 2011 21:13:31 -0700 (PDT) Received: from [10.255.255.58] ([70.25.120.2]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p6U4C6wE005297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Jul 2011 06:12:12 +0200 (CEST) Message-ID: <4E338495.30704@sunet.se> Date: Sat, 30 Jul 2011 06:12:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] minutes 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, 30 Jul 2011 04:13:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 from the meeting today are available from the meeting materials page. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4zhJUACgkQ8Jx8FtbMZneaKwCeKMQHEaiV850JiJqebNQWgLQ6 kPsAn3+lr6PHW+S6GPetIIyDEZLPU2tG =AbRJ -----END PGP SIGNATURE-----