From klaas@cisco.com Tue Aug 2 05:23:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3721F8D66 for ; Tue, 2 Aug 2011 05:23:58 -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 XsOUxC8BpQ86 for ; Tue, 2 Aug 2011 05:23:57 -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 41E1E21F8D65 for ; Tue, 2 Aug 2011 05:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=2217; q=dns/txt; s=iport; t=1312287846; x=1313497446; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=egAa5LKU5IdVBiJBO2sncdpQMzXw7CrN3mKLmLPdeos=; b=DDKJripx8o3vX74p3wzKoQ61tHiEgLZlfMgn3WqJQO+Fcc64S7uJawn+ TXjqVyrRZZI9xmoJhKWeIcQFppNFZ7wktcxOfeq1+f+vIZowm5udJK2fw U7nEHsFKNb4oIglqmbJJagJJM2qrSBAqDCxAi9jyPxbApsw+12XLEHdAz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GAGPrN06Q/khM/2dsb2JhbABCmFGPEHeBQAEBAQECAQEBAQ8BJzQQCxwBAgECLyciBAIIGQkZh0oEoXwBnxCFY18EknuQZg X-IronPort-AV: E=Sophos;i="4.67,306,1309737600"; d="scan'208";a="106168610" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2011 12:24:05 +0000 Received: from ams-kwiereng-8712.cisco.com (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p72CO5dA020570 for ; Tue, 2 Aug 2011 12:24:05 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 2 Aug 2011 14:24:03 +0200 References: <4E37B1F7.9070405@cisco.com> To: abfab@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [abfab] Fwd: [saag] abfab meeting summary 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, 02 Aug 2011 12:23:58 -0000 FYI Begin forwarded message: > From: Klaas Wierenga > Subject: [saag] abfab meeting summary for IETF81 > Date: August 2, 2011 10:14:47 AM GMT+02:00 > To: saag@ietf.org > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Abfab met in the morning session on Friday 29th of July > > The progress of the WG documents was discussed (progressing well) as > well as 3 proposals for new work: > > - - gss-eap as Kerberos pre-authentication > (draft-perez-abfab-eap-gss-preauth) > > This work proposes to use gss-eap as Kerberos pre-authentication in > order to use Kerberos in a federated environment. It is as of yet > unclear in what WG (Kerberos, Kitten or Abfab) this work fits best, but > this approach solves a number of real world problems and as such is > worth pursuing. > > - - federated cross layer access (draft-wei-abfab-fcla) > > This draft proposes to use the authentication mechanisms of mobile > operators (GBA) in combination with Abfab to authenticate to application > son the Internet. The draft is very sketchy at the moment, and the > author was urged to provide more detail. > > - - multihop federations (draft-mrw-abfab-multihop-fed) > > This draft explains an architecture that allows for the establishment of > technical trust between AAA-servers by using so-called trust routers, > entities that act as introducers to other trust routers or AAA-servers > and that learn the paths to them. > > All three of these drafts are currently not being taken on as WG docs, > but may so after the work on WG documents has sufficiently progressed. > > Detailed minutes can be found at: > > http://www.ietf.org/proceedings/81/minutes/abfab.txt > > Klaas Wierenga & Leif Johansson (co-chairs abfab) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk43sfUACgkQH2Wy/p4XeFIovgCdFB/F8+Kf1P52zMzDFkjdKOaR > 1aEAnjsSEC+yozbrC0WQhXaNDtbVPq5u > =O3Ns > -----END PGP SIGNATURE----- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From wei.yinxing@zte.com.cn Tue Aug 2 17:54: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 84CC711E8108 for ; Tue, 2 Aug 2011 17:54:02 -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 usAW91T9mrdM for ; Tue, 2 Aug 2011 17:54:01 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AD23D11E8111 for ; Tue, 2 Aug 2011 17:53:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 4864967931198; Wed, 3 Aug 2011 08:51:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 22013.4122726756; Wed, 3 Aug 2011 08:54:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p730rww5039960; Wed, 3 Aug 2011 08:53:58 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) To: smith@cardiff.ac.uk MIME-Version: 1.0 X-KeepSent: 5C7111FD:1C36D5AA-482578E1:0003EF73; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Wed, 3 Aug 2011 08:53:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-03 08:53:58, Serialize complete at 2011-08-03 08:53:58 Content-Type: multipart/alternative; boundary="=_alternative 0004F150482578E1_=" X-MAIL: mse02.zte.com.cn p730rww5039960 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:54:02 -0000 This is a multipart message in MIME format. --=_alternative 0004F150482578E1_= Content-Type: text/plain; charset="US-ASCII" Dear Rhys Smith, According to the action in IETF#81, I summarized the use case in draft-wei-abfab-fcla-00 as an input to draft-ietf-abfab-usecases-01. Please review it. Thanks! Yinxing Wei ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4.x. Federated Cross-Layer Access Telecom operators have a communication network infrastructures to provider users with a wealthy of access methods. Telecom operators have a huge number of registered users, and they can provide trusted identity and higher security. Therefore they have a natural advantage to act as an Identity Provider (IdP) to serve for service providers. On the contrary most service providers on the Internet have limited amount of users and can not assure the security of user identity, but they can provide abundant kinds of service. Furthermore, user is reluctant to register too many accounts because it is inconvenient to remember dozens of passwords. Telecom network supports Web or non-Web application. In some cases user prefers to choose non-Web application, e.g. Messaging service, VoIP, EMail service, etc. Based on the result of network stratum authentication and authorization, User equipment (UE) can access applications without doing another authentication and authorization procedure. In this way, the system can implement federated cross-layer access. Firstly mutual authentication is performed between UE and Network, secondly UE accesses Application based on the result of network stratum's authentication. In this case, a federation is formed between Network and Application. The brief steps are as follows: 1. When UE attaches the Network, mutual authentication is performed master session key is created between them. 2. UE visits non-Web Application, e.g Messaging service, VoIP service, or Email service. 3. Application has no information about the UE. The Application contacts Network to validate the authentication result in the network stratum. Application can find Network according to the configuration or dynamical discovery protocol. 4. Network responds to Application with authentication result. 5. UE is authorized to access the Application. For federated cross-layer access, Network can assure the Application of the authenticity of user's identity, share some of use profile with Application. These can bring some benefits to stakeholders: o For telecom operators, they can provide identity service, trusted security service, mobile payment service and sharing some user profiles according user's preferences. Telecom operators is not just providing pipeline for communication, but also become a part of service value chain as an Identity Provider. o For service providers, they can focus on core business and reuse capabilities provided by telecom operators without worrying about sources of users. o For end users, they can enjoy seamless service experiences and improve security and privacy. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------- 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 0004F150482578E1_= Content-Type: text/html; charset="US-ASCII"
Dear Rhys Smith,

According to the action in IETF#81, I summarized the use case in
draft-wei-abfab-fcla-00 as an input to draft-ietf-abfab-usecases-01.
Please review it.

Thanks!

Yinxing Wei

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4.x. Federated Cross-Layer Access

   Telecom operators have a communication network infrastructures to
   provider users with a wealthy of access methods. Telecom operators
   have a huge number of registered users, and they can provide trusted
   identity and higher security. Therefore they have a natural advantage
   to act as an Identity Provider (IdP) to serve for service providers.
   On the contrary most service providers on the Internet have limited
   amount of users and can not assure the security of user identity, but
   they can provide abundant kinds of service. Furthermore, user is
   reluctant to register too many accounts because it is inconvenient to
   remember dozens of passwords.

   Telecom network supports Web or non-Web application.  In some cases
   user prefers to choose non-Web application, e.g.  Messaging service,
   VoIP, EMail service, etc. Based on the result of network stratum
   authentication and authorization, User equipment (UE) can access
   applications without doing another authentication and authorization
   procedure. In this way, the system can implement federated cross-layer
   access. Firstly mutual authentication is performed between UE and
   Network, secondly UE accesses Application based on the result of
   network stratum's authentication. In this case, a federation is formed
   between Network and Application. The brief steps are as follows:

   1.  When UE attaches the Network, mutual authentication is performed
       master session key is created between them.
   2.  UE visits non-Web Application, e.g Messaging service, VoIP
       service, or Email service.
   3.  Application has no information about the UE.  The Application
       contacts Network to validate the authentication result in the
       network stratum.  Application can find Network according to the
       configuration or dynamical discovery protocol.
   4.  Network responds to Application with authentication result.
   5.  UE is authorized to access the Application.

   For federated cross-layer access, Network can assure the Application
   of the authenticity of user's identity, share some of use profile
   with Application.  These can bring some benefits to stakeholders:

   o  For telecom operators, they can provide identity service, trusted
      security service, mobile payment service and sharing some user
      profiles according user's preferences. Telecom operators is not
      just providing pipeline for communication, but also become a part of
      service value chain as an Identity Provider.
   o  For service providers,  they can focus on core business and reuse
      capabilities provided by telecom operators without worrying about
      sources of users.
   o  For end users, they can enjoy seamless service experiences and
      improve security and privacy.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--------------------------------------------------------
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 0004F150482578E1_=-- From hartmans@mit.edu Wed Aug 3 06:34: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 AFF6A21F85AE for ; Wed, 3 Aug 2011 06:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.974 X-Spam-Level: X-Spam-Status: No, score=-103.974 tagged_above=-999 required=5 tests=[AWL=-1.709, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 nnLwrJW5NZzI for ; Wed, 3 Aug 2011 06:34:57 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 15D5D21F8512 for ; Wed, 3 Aug 2011 06:34:56 -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 79ADC203C0; Wed, 3 Aug 2011 09:37:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B329422B; Wed, 3 Aug 2011 09:34:51 -0400 (EDT) From: Sam Hartman To: wei.yinxing@zte.com.cn References: Date: Wed, 03 Aug 2011 09:34:51 -0400 In-Reply-To: (wei yinxing's message of "Wed, 3 Aug 2011 08:53:00 +0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:34:57 -0000 I think this text goes way too much into solution territory rather than just focusing on the use case. for example, the following all seem to be solution details: 1) There is an initial authentication with the network provider 2) An MSK is established with the network provider 3) The service provider finds the network provider based on configuration or discovery protocol. These details also go against the current ABFAB architecture. As best I can tell, the current abfab architecture does support the network provider leveraging their identities and the service provider using their identities. However under that architecture it would look more like: 1) user goes to service and begins abfab authentication 2) User provides network provider's realm to service 3) User engages in an EAP exchange with the network provider tunneled through the service and AAA infrastructure 4) If authentication succeeds, a MSK is generated and given to the service and user. These details would also be inappropriate to include in the use case document; I include them in this message only to illustrate how things differ and why we want to avoid solution focus in use-case text. If you believe that my proposed flow would not work for your use case, then let's focus on what the aspects of the use case are that would make these details inappropriate. From ietf@augustcellars.com Wed Aug 3 19:24: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 8A96921F874A; Wed, 3 Aug 2011 19:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 auuDJhgaVLDG; Wed, 3 Aug 2011 19:24:29 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0311E80BE; Wed, 3 Aug 2011 19:24:28 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 2F3D02CA64; Wed, 3 Aug 2011 19:24:41 -0700 (PDT) From: "Jim Schaad" To: References: <20110804021935.31037.48432.idtracker@ietfa.amsl.com> In-Reply-To: <20110804021935.31037.48432.idtracker@ietfa.amsl.com> Date: Wed, 3 Aug 2011 19:58:46 -0700 Message-ID: <005f01cc5252$6ed6ab60$4c840220$@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: AQC3pAGtK7/84McoI5riLyxIww0dIJc1W8Hg Content-Language: en-us Cc: abfab@ietf.org, smime@ietf.org Subject: [abfab] FW: New Version Notification for draft-freeman-message-access-control-req-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 02:24:29 -0000 Please note there is a new version of this document posted. Trevor and = I did not get finished doing all of the updates that I thought were = necessary before he went on vacation, but we did get much farther = towards a document I would consider acceptable. Please review the document with strong focus on the use cases, the model = and the requirements. Please feel free to send comments to me and Trevor, but please remove = the abfab and smime mailing lists and just leave the plasma list in your = mail. I am sending this mail to a wider set of people to try and get = more reviews. Thanks Jim -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, August 03, 2011 7:20 PM To: ietf@augustcellars.com Cc: ppatterson@carillon.ca; ietf@augustcellars.com; = trevorf@microsoft.com Subject: New Version Notification for = draft-freeman-message-access-control-req-02.txt A new version of I-D, draft-freeman-message-access-control-req-02.txt = has been successfully submitted by Jim Schaad and posted to the IETF = repository. Filename: draft-freeman-message-access-control-req Revision: 02 Title: Requirements for Message Access Control Creation date: 2011-08-03 WG ID: Individual Submission Number of pages: 33 Abstract: There are many situations where organizations want to protect information with robust access control, either for implementation of intellectual property right protections, enforcement of information contractual confidentiality agreements or because of externally imposed legal regulations. The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism which is enforced by the recipient's client after decryption of the message. The ESS = mechanism therefore is dependent on the correct access policy configuration of every recipient's client. This mechanism also provides full = access to the data to all recipients prior to the access control check which is considered to be inadequate for due to the difficulty in demonstrating policy compliance. This document lays out the deficiencies of the current ESS security label, and presents requirements for new model for doing access control to messages where the access check is performed prior to message content decryption. This new model also does not require policy configuration on the client to simplify deployment and compliance verification. The proposed model additionally provides a method where non-X.509 certificate credentials can be used for encryption/decryption of S/MIME messages. = =20 The IETF Secretariat From wei.yinxing@zte.com.cn Wed Aug 3 22:18:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2A121F86C4 for ; Wed, 3 Aug 2011 22:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.807 X-Spam-Level: X-Spam-Status: No, score=-98.807 tagged_above=-999 required=5 tests=[AWL=-3.031, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIzefr3AzFd7 for ; Wed, 3 Aug 2011 22:18:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7714F11E80E2 for ; Wed, 3 Aug 2011 22:18:05 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 13132967931198; Thu, 4 Aug 2011 13:08:30 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 85690.2001115653; Thu, 4 Aug 2011 13:17:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p745Hx3k025158; Thu, 4 Aug 2011 13:17:59 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-KeepSent: 47C2FB0E:31AFED71-482578E2:001A1B3C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Thu, 4 Aug 2011 13:16:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-04 13:18:00, Serialize complete at 2011-08-04 13:18:00 Content-Type: multipart/alternative; boundary="=_alternative 001D1D71482578E2_=" X-MAIL: mse02.zte.com.cn p745Hx3k025158 Cc: abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:18:08 -0000 This is a multipart message in MIME format. --=_alternative 001D1D71482578E2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFNhbQ0KDQogIFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyEgSSBhZ3JlZSB3aXRoIHlvdXIg cG9pbnRzIHRoYXQgdXNlIGNhc2UgDQpkb2N1bWVudCANCiBzaG91bGQgYXZvaWQgaW50cm9kdWNp bmcgc29sdXRpb24gZGV0YWlscy4gDQoNCiAgVGhlIHJlYXNvbiB0byBwcm92aWRlIGEgZmV3IGRl dGFpbHMgaW4gdGhlIHByZXZpb3VzIHVzZSBjYXNlIGRvY3VtZW50IGlzIA0KDQpqdXN0IHRvIG1h a2UgaXQgY2xlYXIgYW5kIHVuZGVyc3RhbmRhYmxlLiBBY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0 aW9uLCBJIA0KcmV2aXNlZCANCnRoZSB0ZXh0IHNob3duIGFzIGJlbG93IGluIG9yZGVyIHRvIG1h a2UgaXQgc3VpdGFibGUgaW4gdGhlIGN1cnJlbnQgdXNlIA0KY2FzZSBkb2N1bWVudC4gDQpJIGhv cGUgaXQgaXMgYWNjZXB0YWJsZSBub3cuDQoNCkFueSBjb21tZW50cyBhcmUgd2VsY29tZSENCg0K WWlueGluZyBXZWkhDQotLS0tLS0tLS0tLS0NCg0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KDQo0 LnguIEZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3MgDQoNCiAgIFRlbGVjb20gb3BlcmF0b3Jz IGhhdmUgYSBjb21tdW5pY2F0aW9uIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmVzIHRvIA0KICAgcHJv dmlkZXIgdXNlcnMgd2l0aCBhIHdlYWx0aHkgb2YgYWNjZXNzIG1ldGhvZHMuIFRlbGVjb20gb3Bl cmF0b3JzIA0KICAgaGF2ZSBhIGh1Z2UgbnVtYmVyIG9mIHJlZ2lzdGVyZWQgdXNlcnMsIGFuZCB0 aGV5IGNhbiBwcm92aWRlIHRydXN0ZWQgDQogICBpZGVudGl0eSBhbmQgaGlnaGVyIHNlY3VyaXR5 LiBUaGVyZWZvcmUgdGhleSBoYXZlIGEgbmF0dXJhbCBhZHZhbnRhZ2UgDQogICB0byBhY3QgYXMg YW4gSWRlbnRpdHkgUHJvdmlkZXIgKElkUCkgdG8gc2VydmUgZm9yIHNlcnZpY2UgcHJvdmlkZXJz LiANCiAgIE9uIHRoZSBjb250cmFyeSBtb3N0IHNlcnZpY2UgcHJvdmlkZXJzIG9uIHRoZSBJbnRl cm5ldCBoYXZlIGxpbWl0ZWQgDQogICBhbW91bnQgb2YgdXNlcnMgYW5kIGNhbiBub3QgYXNzdXJl IHRoZSBzZWN1cml0eSBvZiB1c2VyIGlkZW50aXR5LCBidXQgDQogICB0aGV5IGNhbiBwcm92aWRl IGFidW5kYW50IGtpbmRzIG9mIHNlcnZpY2UuIEZ1cnRoZXJtb3JlLCB1c2VyIGlzIA0KICAgcmVs dWN0YW50IHRvIHJlZ2lzdGVyIHRvbyBtYW55IGFjY291bnRzIGJlY2F1c2UgaXQgaXMgaW5jb252 ZW5pZW50IHRvIA0KICAgcmVtZW1iZXIgZG96ZW5zIG9mIHBhc3N3b3Jkcy4gDQoNCiAgIFRlbGVj b20gbmV0d29yayBzdXBwb3J0cyBXZWIgb3Igbm9uLVdlYiBhcHBsaWNhdGlvbi4gIEluIHNvbWUg Y2FzZXMgDQogICB1c2VyIHByZWZlcnMgdG8gY2hvb3NlIG5vbi1XZWIgYXBwbGljYXRpb24sIGUu Zy4gIE1lc3NhZ2luZyBzZXJ2aWNlLCANCiAgIFZvSVAsIEVNYWlsIHNlcnZpY2UsIGV0Yy4gQmFz ZWQgb24gdGhlIHJlc3VsdCBvZiBuZXR3b3JrIHN0cmF0dW0gDQogICBhdXRoZW50aWNhdGlvbiBh bmQgYXV0aG9yaXphdGlvbiwgVXNlciBlcXVpcG1lbnQgKFVFKSBjYW4gYWNjZXNzIA0KICAgYXBw bGljYXRpb25zIHdpdGhvdXQgZG9pbmcgYW5vdGhlciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9y aXphdGlvbiANCiAgIHByb2NlZHVyZS4gSW4gdGhpcyB3YXksIHRoZSBzeXN0ZW0gY2FuIGltcGxl bWVudCBmZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgDQogICBhY2Nlc3MuIEZpcnN0bHkgbXV0dWFsIGF1 dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBiZXR3ZWVuIFVFIGFuZCANCiAgIE5ldHdvcmssIHNl Y29uZGx5IFVFIGFjY2Vzc2VzIEFwcGxpY2F0aW9uIGJhc2VkIG9uIHRoZSByZXN1bHQgb2YgDQog ICBuZXR3b3JrIHN0cmF0dW0ncyBhdXRoZW50aWNhdGlvbi4gSW4gdGhpcyBjYXNlLCBhIGZlZGVy YXRpb24gaXMgZm9ybWVkIA0KICAgYmV0d2VlbiBOZXR3b3JrIGFuZCBBcHBsaWNhdGlvbi4gDQoN CiAgIEZvciBmZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgYWNjZXNzLCBOZXR3b3JrIGNhbiBhc3N1cmUg dGhlIEFwcGxpY2F0aW9uIA0KICAgb2YgdGhlIGF1dGhlbnRpY2l0eSBvZiB1c2VyJ3MgaWRlbnRp dHksIHNoYXJlIHNvbWUgb2YgdXNlIHByb2ZpbGUgDQogICB3aXRoIEFwcGxpY2F0aW9uLiAgVGhl c2UgY2FuIGJyaW5nIHNvbWUgYmVuZWZpdHMgdG8gc3Rha2Vob2xkZXJzOiANCg0KICAgbyAgRm9y IHRlbGVjb20gb3BlcmF0b3JzLCB0aGV5IGNhbiBwcm92aWRlIGlkZW50aXR5IHNlcnZpY2UsIHRy dXN0ZWQgDQogICAgICBzZWN1cml0eSBzZXJ2aWNlLCBtb2JpbGUgcGF5bWVudCBzZXJ2aWNlIGFu ZCBzaGFyaW5nIHNvbWUgdXNlciANCiAgICAgIHByb2ZpbGVzIGFjY29yZGluZyB1c2VyJ3MgcHJl ZmVyZW5jZXMuIFRlbGVjb20gb3BlcmF0b3JzIGlzIG5vdCANCiAgICAgIGp1c3QgcHJvdmlkaW5n IHBpcGVsaW5lIGZvciBjb21tdW5pY2F0aW9uLCBidXQgYWxzbyBiZWNvbWUgYSBwYXJ0IG9mIA0K DQogICAgICBzZXJ2aWNlIHZhbHVlIGNoYWluIGFzIGFuIElkZW50aXR5IFByb3ZpZGVyLiANCiAg IG8gIEZvciBzZXJ2aWNlIHByb3ZpZGVycywgIHRoZXkgY2FuIGZvY3VzIG9uIGNvcmUgYnVzaW5l c3MgYW5kIHJldXNlIA0KICAgICAgY2FwYWJpbGl0aWVzIHByb3ZpZGVkIGJ5IHRlbGVjb20gb3Bl cmF0b3JzIHdpdGhvdXQgd29ycnlpbmcgYWJvdXQgDQogICAgICBzb3VyY2VzIG9mIHVzZXJzLiAN CiAgIG8gIEZvciBlbmQgdXNlcnMsIHRoZXkgY2FuIGVuam95IHNlYW1sZXNzIHNlcnZpY2UgZXhw ZXJpZW5jZXMgYW5kIA0KICAgICAgaW1wcm92ZSBzZWN1cml0eSBhbmQgcHJpdmFjeS4gDQoNCn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn4NCiANCiANCiANCg0KDQoNCg0KU2FtIEhhcnRtYW4gPGhhcnRt YW5zLWlldGZAbWl0LmVkdT4gDQoyMDExLTA4LTAzIDIxOjM0DQoNCsrVvP7Iyw0Kd2VpLnlpbnhp bmdAenRlLmNvbS5jbg0Ks63LzQ0KYWJmYWJAaWV0Zi5vcmcNCtb3zOINClJlOiBQbGVhc2UgcmV2 aWV3IHRoZSB1c2UgY2FzZSAiNC54IEZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3MiDQoNCg0K DQoNCg0KDQpJIHRoaW5rIHRoaXMgdGV4dCBnb2VzIHdheSB0b28gbXVjaCBpbnRvIHNvbHV0aW9u IHRlcnJpdG9yeSByYXRoZXIgdGhhbg0KanVzdCBmb2N1c2luZyBvbiB0aGUgdXNlIGNhc2UuDQoN CmZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIGFsbCBzZWVtIHRvIGJlIHNvbHV0aW9uIGRldGFp bHM6DQoNCjEpIFRoZXJlIGlzIGFuIGluaXRpYWwgYXV0aGVudGljYXRpb24gd2l0aCB0aGUgbmV0 d29yayBwcm92aWRlcg0KDQoyKSBBbiBNU0sgaXMgZXN0YWJsaXNoZWQgd2l0aCB0aGUgbmV0d29y ayBwcm92aWRlcg0KDQozKSBUaGUgc2VydmljZSBwcm92aWRlciBmaW5kcyB0aGUgbmV0d29yayBw cm92aWRlciBiYXNlZCBvbg0KY29uZmlndXJhdGlvbiBvciBkaXNjb3ZlcnkgcHJvdG9jb2wuDQoN ClRoZXNlIGRldGFpbHMgYWxzbyBnbyBhZ2FpbnN0IHRoZSBjdXJyZW50IEFCRkFCIGFyY2hpdGVj dHVyZS4NCg0KQXMgYmVzdCBJIGNhbiB0ZWxsLCB0aGUgY3VycmVudCBhYmZhYiBhcmNoaXRlY3R1 cmUgIGRvZXMgc3VwcG9ydCB0aGUNCm5ldHdvcmsgcHJvdmlkZXIgbGV2ZXJhZ2luZyB0aGVpciBp ZGVudGl0aWVzIGFuZCB0aGUgc2VydmljZSBwcm92aWRlcg0KdXNpbmcgdGhlaXIgaWRlbnRpdGll cy4gSG93ZXZlciB1bmRlciB0aGF0IGFyY2hpdGVjdHVyZSBpdCB3b3VsZCBsb29rDQptb3JlIGxp a2U6DQoNCjEpIHVzZXIgZ29lcyB0byBzZXJ2aWNlIGFuZCBiZWdpbnMgYWJmYWIgYXV0aGVudGlj YXRpb24NCg0KMikgVXNlciBwcm92aWRlcyBuZXR3b3JrIHByb3ZpZGVyJ3MgcmVhbG0gdG8gc2Vy dmljZQ0KDQozKSBVc2VyIGVuZ2FnZXMgaW4gYW4gRUFQIGV4Y2hhbmdlIHdpdGggdGhlIG5ldHdv cmsgcHJvdmlkZXIgdHVubmVsZWQNCnRocm91Z2ggdGhlIHNlcnZpY2UgYW5kIEFBQSBpbmZyYXN0 cnVjdHVyZQ0KDQo0KSBJZiBhdXRoZW50aWNhdGlvbiBzdWNjZWVkcywgYSBNU0sgaXMgZ2VuZXJh dGVkIGFuZCBnaXZlbiB0byB0aGUNCnNlcnZpY2UgYW5kIHVzZXIuDQoNClRoZXNlIGRldGFpbHMg d291bGQgYWxzbyBiZSBpbmFwcHJvcHJpYXRlIHRvIGluY2x1ZGUgaW4gIHRoZSB1c2UgY2FzZQ0K ZG9jdW1lbnQ7IEkgaW5jbHVkZSB0aGVtIGluIHRoaXMgbWVzc2FnZSBvbmx5IHRvIGlsbHVzdHJh dGUgaG93IHRoaW5ncw0KZGlmZmVyIGFuZCB3aHkgd2Ugd2FudCB0byBhdm9pZCBzb2x1dGlvbiBm b2N1cyBpbiB1c2UtY2FzZSB0ZXh0Lg0KDQpJZiB5b3UgYmVsaWV2ZSB0aGF0IG15IHByb3Bvc2Vk IGZsb3cgd291bGQgbm90IHdvcmsgZm9yIHlvdXIgdXNlIGNhc2UsDQp0aGVuIGxldCdzIGZvY3Vz IG9uIHdoYXQgdGhlIGFzcGVjdHMgb2YgdGhlIHVzZSBjYXNlIGFyZSB0aGF0IHdvdWxkIG1ha2UN CnRoZXNlIGRldGFpbHMgaW5hcHByb3ByaWF0ZS4NCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 001D1D71482578E2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBTYW08L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBUaGFua3MgZm9yIHlv dXIgY29tbWVudHMhIEkgYWdyZWUNCndpdGggeW91ciBwb2ludHMgdGhhdCB1c2UgY2FzZSBkb2N1 bWVudCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO3No b3VsZCBhdm9pZCBpbnRyb2R1Y2luZyBzb2x1dGlvbg0KZGV0YWlscy4gPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgVGhlIHJlYXNvbiB0byBw cm92aWRlIGEgZmV3IGRldGFpbHMNCmluIHRoZSBwcmV2aW91cyB1c2UgY2FzZSBkb2N1bWVudCBp cyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmp1c3QgdG8gbWFr ZSBpdCBjbGVhciBhbmQgdW5kZXJzdGFuZGFibGUuDQpBY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0 aW9uLCBJIHJldmlzZWQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij50aGUgdGV4dCBzaG93biBhcyBiZWxvdyBpbiBvcmRlciB0bw0KbWFrZSBpdCBzdWl0YWJsZSBp biB0aGUgY3VycmVudCB1c2UgY2FzZSBkb2N1bWVudC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGhvcGUgaXQgaXMgYWNjZXB0YWJsZSBub3cuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbnkgY29tbWVudHMgYXJl IHdlbGNvbWUhPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5ZaW54aW5nIFdlaSE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pi0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+NC54LiBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNzIDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwO1RlbGVjb20gb3BlcmF0b3JzIGhhdmUNCmEgY29tbXVuaWNhdGlvbiBuZXR3b3JrIGluZnJh c3RydWN0dXJlcyB0byA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDtwcm92aWRlciB1c2VycyB3aXRoIGEgd2VhbHRoeQ0Kb2YgYWNjZXNzIG1l dGhvZHMuIFRlbGVjb20gb3BlcmF0b3JzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2hhdmUgYSBodWdlIG51bWJlciBvZiByZWdpc3RlcmVk DQp1c2VycywgYW5kIHRoZXkgY2FuIHByb3ZpZGUgdHJ1c3RlZCA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtpZGVudGl0eSBhbmQgaGlnaGVy IHNlY3VyaXR5Lg0KVGhlcmVmb3JlIHRoZXkgaGF2ZSBhIG5hdHVyYWwgYWR2YW50YWdlIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RvIGFj dCBhcyBhbiBJZGVudGl0eSBQcm92aWRlcg0KKElkUCkgdG8gc2VydmUgZm9yIHNlcnZpY2UgcHJv dmlkZXJzLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtPbiB0aGUgY29udHJhcnkgbW9zdCBzZXJ2aWNlDQpwcm92aWRlcnMgb24gdGhlIElu dGVybmV0IGhhdmUgbGltaXRlZCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDthbW91bnQgb2YgdXNlcnMgYW5kIGNhbg0Kbm90IGFzc3VyZSB0 aGUgc2VjdXJpdHkgb2YgdXNlciBpZGVudGl0eSwgYnV0IDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RoZXkgY2FuIHByb3ZpZGUgYWJ1bmRh bnQNCmtpbmRzIG9mIHNlcnZpY2UuIEZ1cnRoZXJtb3JlLCB1c2VyIGlzIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3JlbHVjdGFudCB0byBy ZWdpc3RlciB0b28NCm1hbnkgYWNjb3VudHMgYmVjYXVzZSBpdCBpcyBpbmNvbnZlbmllbnQgdG8g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 cmVtZW1iZXIgZG96ZW5zIG9mIHBhc3N3b3Jkcy4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RlbGVjb20gbmV0d29yayBzdXBw b3J0cw0KV2ViIG9yIG5vbi1XZWIgYXBwbGljYXRpb24uICZuYnNwO0luIHNvbWUgY2FzZXMgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7dXNl ciBwcmVmZXJzIHRvIGNob29zZQ0Kbm9uLVdlYiBhcHBsaWNhdGlvbiwgZS5nLiAmbmJzcDtNZXNz YWdpbmcgc2VydmljZSwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7Vm9JUCwgRU1haWwgc2VydmljZSwgZXRjLg0KQmFzZWQgb24gdGhlIHJl c3VsdCBvZiBuZXR3b3JrIHN0cmF0dW0gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24s DQpVc2VyIGVxdWlwbWVudCAoVUUpIGNhbiBhY2Nlc3MgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YXBwbGljYXRpb25zIHdpdGhvdXQgZG9p bmcNCmFub3RoZXIgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7cHJvY2VkdXJlLiBJ biB0aGlzIHdheSwNCnRoZSBzeXN0ZW0gY2FuIGltcGxlbWVudCBmZWRlcmF0ZWQgY3Jvc3MtbGF5 ZXIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7YWNjZXNzLiBGaXJzdGx5IG11dHVhbA0KYXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkIGJl dHdlZW4gVUUgYW5kIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO05ldHdvcmssIHNlY29uZGx5IFVFIGFjY2Vzc2VzDQpBcHBsaWNhdGlvbiBi YXNlZCBvbiB0aGUgcmVzdWx0IG9mIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwO25ldHdvcmsgc3RyYXR1bSdzIGF1dGhlbnRpY2F0aW9uLg0K SW4gdGhpcyBjYXNlLCBhIGZlZGVyYXRpb24gaXMgZm9ybWVkIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2JldHdlZW4gTmV0d29yayBhbmQg QXBwbGljYXRpb24uDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtGb3IgZmVkZXJhdGVkIGNyb3NzLWxheWVyDQphY2Nlc3MsIE5l dHdvcmsgY2FuIGFzc3VyZSB0aGUgQXBwbGljYXRpb24gPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b2YgdGhlIGF1dGhlbnRpY2l0eSBvZg0K dXNlcidzIGlkZW50aXR5LCBzaGFyZSBzb21lIG9mIHVzZSBwcm9maWxlIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3dpdGggQXBwbGljYXRp b24uICZuYnNwO1RoZXNlDQpjYW4gYnJpbmcgc29tZSBiZW5lZml0cyB0byBzdGFrZWhvbGRlcnM6 IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwO28gJm5ic3A7Rm9yIHRlbGVjb20gb3BlcmF0b3JzLA0KdGhleSBjYW4gcHJvdmlkZSBp ZGVudGl0eSBzZXJ2aWNlLCB0cnVzdGVkIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VjdXJpdHkgc2VydmljZSwNCm1vYmls ZSBwYXltZW50IHNlcnZpY2UgYW5kIHNoYXJpbmcgc29tZSB1c2VyIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvZmlsZXMg YWNjb3JkaW5nDQp1c2VyJ3MgcHJlZmVyZW5jZXMuIFRlbGVjb20gb3BlcmF0b3JzIGlzIG5vdCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7IGp1c3QgcHJvdmlkaW5nDQpwaXBlbGluZSBmb3IgY29tbXVuaWNhdGlvbiwgYnV0IGFs c28gYmVjb21lIGEgcGFydCBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlcnZpY2UgdmFsdWUgY2hhaW4NCmFzIGFuIElk ZW50aXR5IFByb3ZpZGVyLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDtvICZuYnNwO0ZvciBzZXJ2aWNlIHByb3ZpZGVycywNCiZuYnNwO3Ro ZXkgY2FuIGZvY3VzIG9uIGNvcmUgYnVzaW5lc3MgYW5kIHJldXNlIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FwYWJpbGl0 aWVzIHByb3ZpZGVkDQpieSB0ZWxlY29tIG9wZXJhdG9ycyB3aXRob3V0IHdvcnJ5aW5nIGFib3V0 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgc291cmNlcyBvZiB1c2Vycy4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7Rm9yIGVuZCB1c2VycywNCnRoZXkg Y2FuIGVuam95IHNlYW1sZXNzIHNlcnZpY2UgZXhwZXJpZW5jZXMgYW5kIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW1wcm92 ZSBzZWN1cml0eQ0KYW5kIHByaXZhY3kuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5TYW0gSGFydG1hbiAmbHQ7aGFydG1hbnMt aWV0ZkBtaXQuZWR1Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDExLTA4LTAzIDIxOjM0PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPndlaS55aW54aW5nQHp0ZS5jb20uY248L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPmFiZmFiQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogUGxlYXNlIHJl dmlldyB0aGUgdXNlIGNhc2UgJnF1b3Q7NC54DQpGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNz JnF1b3Q7PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5JIHRoaW5rIHRoaXMgdGV4dCBnb2VzIHdheSB0b28gbXVjaCBpbnRvIHNvbHV0aW9u DQp0ZXJyaXRvcnkgcmF0aGVyIHRoYW48YnI+DQpqdXN0IGZvY3VzaW5nIG9uIHRoZSB1c2UgY2Fz ZS48YnI+DQo8YnI+DQpmb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBhbGwgc2VlbSB0byBiZSBz b2x1dGlvbiBkZXRhaWxzOjxicj4NCjxicj4NCjEpIFRoZXJlIGlzIGFuIGluaXRpYWwgYXV0aGVu dGljYXRpb24gd2l0aCB0aGUgbmV0d29yayBwcm92aWRlcjxicj4NCjxicj4NCjIpIEFuIE1TSyBp cyBlc3RhYmxpc2hlZCB3aXRoIHRoZSBuZXR3b3JrIHByb3ZpZGVyPGJyPg0KPGJyPg0KMykgVGhl IHNlcnZpY2UgcHJvdmlkZXIgZmluZHMgdGhlIG5ldHdvcmsgcHJvdmlkZXIgYmFzZWQgb248YnI+ DQpjb25maWd1cmF0aW9uIG9yIGRpc2NvdmVyeSBwcm90b2NvbC48YnI+DQo8YnI+DQpUaGVzZSBk ZXRhaWxzIGFsc28gZ28gYWdhaW5zdCB0aGUgY3VycmVudCBBQkZBQiBhcmNoaXRlY3R1cmUuPGJy Pg0KPGJyPg0KQXMgYmVzdCBJIGNhbiB0ZWxsLCB0aGUgY3VycmVudCBhYmZhYiBhcmNoaXRlY3R1 cmUgJm5ic3A7ZG9lcyBzdXBwb3J0IHRoZTxicj4NCm5ldHdvcmsgcHJvdmlkZXIgbGV2ZXJhZ2lu ZyB0aGVpciBpZGVudGl0aWVzIGFuZCB0aGUgc2VydmljZSBwcm92aWRlcjxicj4NCnVzaW5nIHRo ZWlyIGlkZW50aXRpZXMuIEhvd2V2ZXIgdW5kZXIgdGhhdCBhcmNoaXRlY3R1cmUgaXQgd291bGQg bG9vazxicj4NCm1vcmUgbGlrZTo8YnI+DQo8YnI+DQoxKSB1c2VyIGdvZXMgdG8gc2VydmljZSBh bmQgYmVnaW5zIGFiZmFiIGF1dGhlbnRpY2F0aW9uPGJyPg0KPGJyPg0KMikgVXNlciBwcm92aWRl cyBuZXR3b3JrIHByb3ZpZGVyJ3MgcmVhbG0gdG8gc2VydmljZTxicj4NCjxicj4NCjMpIFVzZXIg ZW5nYWdlcyBpbiBhbiBFQVAgZXhjaGFuZ2Ugd2l0aCB0aGUgbmV0d29yayBwcm92aWRlciB0dW5u ZWxlZDxicj4NCnRocm91Z2ggdGhlIHNlcnZpY2UgYW5kIEFBQSBpbmZyYXN0cnVjdHVyZTxicj4N Cjxicj4NCjQpIElmIGF1dGhlbnRpY2F0aW9uIHN1Y2NlZWRzLCBhIE1TSyBpcyBnZW5lcmF0ZWQg YW5kIGdpdmVuIHRvIHRoZTxicj4NCnNlcnZpY2UgYW5kIHVzZXIuPGJyPg0KPGJyPg0KVGhlc2Ug ZGV0YWlscyB3b3VsZCBhbHNvIGJlIGluYXBwcm9wcmlhdGUgdG8gaW5jbHVkZSBpbiAmbmJzcDt0 aGUgdXNlIGNhc2U8YnI+DQpkb2N1bWVudDsgSSBpbmNsdWRlIHRoZW0gaW4gdGhpcyBtZXNzYWdl IG9ubHkgdG8gaWxsdXN0cmF0ZSBob3cgdGhpbmdzPGJyPg0KZGlmZmVyIGFuZCB3aHkgd2Ugd2Fu dCB0byBhdm9pZCBzb2x1dGlvbiBmb2N1cyBpbiB1c2UtY2FzZSB0ZXh0Ljxicj4NCjxicj4NCklm IHlvdSBiZWxpZXZlIHRoYXQgbXkgcHJvcG9zZWQgZmxvdyB3b3VsZCBub3Qgd29yayBmb3IgeW91 ciB1c2UgY2FzZSw8YnI+DQp0aGVuIGxldCdzIGZvY3VzIG9uIHdoYXQgdGhlIGFzcGVjdHMgb2Yg dGhlIHVzZSBjYXNlIGFyZSB0aGF0IHdvdWxkIG1ha2U8YnI+DQp0aGVzZSBkZXRhaWxzIGluYXBw cm9wcmlhdGUuPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1Ro ZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMm bmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJz cDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtw ZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJz cDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpU aGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0 dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5k Jm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3Rv Jm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJz cDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtp biZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2lu YXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZu YnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJz cDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRo aXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3Im bmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50 aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001D1D71482578E2_=-- From ietf@augustcellars.com Mon Aug 15 18:47: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 8677321F8C63 for ; Mon, 15 Aug 2011 18:47:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ4K9U6koyat for ; Mon, 15 Aug 2011 18:47:45 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id A14CC21F8C58 for ; Mon, 15 Aug 2011 18:47:44 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 7B9B638EF4; Mon, 15 Aug 2011 18:48:31 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" , "Josh Howlett" Date: Mon, 15 Aug 2011 19:22:53 -0700 Message-ID: <005b01cc5bbb$68e67f10$3ab37d30$@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: AcxbuiAGVOlouSACTvu/GwiTs8EU7g== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on the draft abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Aug 2011 01:47:45 -0000 I think that I have some issues with this document. 1. I am reviewing the private copy that I was given by Sam. This document has expired and should be republished - even with no changes - ASAP. 2. In section 3 - you state that the naming used in SAMLCORE has two parts - a URI describing the format of the name - the actual name in a format described above. I believe this is totally incorrect. Based on my reading of the document an attribute contains the following information: - A string name of an attribute - with any luck this will be a uri but there is no requirement that it be so - a URI describing the format of the attribute value - the actual attribute value There are some additional fields that can be included such as a Friendly Name (a string). I think that above discrepancy has some drastic changes in parts of the draft. Note that one of the things that is listed above is a text based attribute name. Thus there is nothing that says that a single name cannot be used by different IdPs in a different manner. I would not expect the same to be true for a uri based attribute name. I think that this means you need the following elements: a) An (optional) IdP name to identify a domain that the attribute is coming from b) A text string identifying the attribute name -this may be pure text or it may be a uri c) A format for the attribute value The question then arises should you query first the name for the value type and then for the value? Jim From cantor.2@osu.edu Mon Aug 15 18:52:47 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B4D21F8C16 for ; Mon, 15 Aug 2011 18:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS8MY3wrUDkJ for ; Mon, 15 Aug 2011 18:52:47 -0700 (PDT) Received: from defang17.it.ohio-state.edu (defang17.it.ohio-state.edu [128.146.216.131]) by ietfa.amsl.com (Postfix) with ESMTP id 387C221F886A for ; Mon, 15 Aug 2011 18:52:47 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang17.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p7G1rJdK030444; Mon, 15 Aug 2011 21:53:29 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%13]) with mapi; Mon, 15 Aug 2011 21:53:24 -0400 From: "Cantor, Scott" To: Jim Schaad , Sam Hartman , Josh Howlett Thread-Topic: [abfab] Comments on the draft abfab-gss-eap-naming Thread-Index: AcxbuiAGVOlouSACTvu/GwiTs8EU7v//+k2A Date: Tue, 16 Aug 2011 01:53:21 +0000 Message-ID: In-Reply-To: <005b01cc5bbb$68e67f10$3ab37d30$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.131 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on the draft abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Aug 2011 01:52:47 -0000 On 8/15/11 10:22 PM, "Jim Schaad" wrote: > >2. In section 3 - you state that the naming used in SAMLCORE has two >parts > - a URI describing the format of the name > - the actual name in a format described above. > >I believe this is totally incorrect. It is correct, if a perpetual annoyance to its author. > Based on my reading of the document an >attribute contains the following information: > - A string name of an attribute - with any luck this will be a uri >but there is no requirement that it be so > - a URI describing the format of the attribute value > - the actual attribute value No, the NameFormat describes the name, not the value. I'm not sure from where your confusion arises. -- Scott From ietf@augustcellars.com Mon Aug 15 18:56: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 B590E21F8C8E for ; Mon, 15 Aug 2011 18:56:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY9leYzuqxXh for ; Mon, 15 Aug 2011 18:56:17 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27DCB21F8C75 for ; Mon, 15 Aug 2011 18:56:17 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 454A42C9C5; Mon, 15 Aug 2011 18:57:04 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Josh Howlett'" References: <005b01cc5bbb$68e67f10$3ab37d30$@augustcellars.com> In-Reply-To: <005b01cc5bbb$68e67f10$3ab37d30$@augustcellars.com> Date: Mon, 15 Aug 2011 19:31:28 -0700 Message-ID: <005f01cc5bbc$9a7a5730$cf6f0590$@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: AQHY3H0KfpNjNpUIsMWiQ553KkHlMZUFwDDQ Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on the draft abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Aug 2011 01:56:17 -0000 Then again I may be wrong. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Jim Schaad > Sent: Monday, August 15, 2011 7:23 PM > To: Sam Hartman; Josh Howlett > Cc: abfab@ietf.org > Subject: [abfab] Comments on the draft abfab-gss-eap-naming > > I think that I have some issues with this document. > > 1. I am reviewing the private copy that I was given by Sam. This document > has expired and should be republished - even with no changes - ASAP. > > 2. In section 3 - you state that the naming used in SAMLCORE has two parts > - a URI describing the format of the name > - the actual name in a format described above. > > I believe this is totally incorrect. Based on my reading of the document an > attribute contains the following information: > - A string name of an attribute - with any luck this will be a uri but > there is no requirement that it be so > - a URI describing the format of the attribute value > - the actual attribute value > > There are some additional fields that can be included such as a Friendly Name > (a string). > > I think that above discrepancy has some drastic changes in parts of the draft. > Note that one of the things that is listed above is a text based attribute > name. Thus there is nothing that says that a single name cannot be used by > different IdPs in a different manner. I would not expect the same to be true > for a uri based attribute name. I think that this means you need the > following elements: > > a) An (optional) IdP name to identify a domain that the attribute is coming > from > b) A text string identifying the attribute name -this may be pure text or it > may be a uri > c) A format for the attribute value > > The question then arises should you query first the name for the value type > and then for the value? > > Jim > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From cantor.2@osu.edu Mon Aug 15 18:57: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 1CBA421F8779 for ; Mon, 15 Aug 2011 18:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3yhJf+nZnuh for ; Mon, 15 Aug 2011 18:57:18 -0700 (PDT) Received: from defang18.it.ohio-state.edu (defang18.it.ohio-state.edu [128.146.216.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7316421F8782 for ; Mon, 15 Aug 2011 18:57:18 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang18.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p7G1w2CR003271; Mon, 15 Aug 2011 21:58:02 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%13]) with mapi; Mon, 15 Aug 2011 21:58:02 -0400 From: "Cantor, Scott" To: Jim Schaad , Sam Hartman , Josh Howlett Thread-Topic: [abfab] Comments on the draft abfab-gss-eap-naming Thread-Index: AcxbuiAGVOlouSACTvu/GwiTs8EU7v//+5kA Date: Tue, 16 Aug 2011 01:58:00 +0000 Message-ID: In-Reply-To: <005b01cc5bbb$68e67f10$3ab37d30$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.132 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on the draft abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Aug 2011 01:57:19 -0000 On 8/15/11 10:22 PM, "Jim Schaad" wrote: > >I think that above discrepancy has some drastic changes in parts of the >draft. Note that one of the things that is listed above is a text based >attribute name. Thus there is nothing that says that a single name cannot >be used by different IdPs in a different manner. I would not expect the >same to be true for a uri based attribute name. I should say that that much is definitely true. But as a fine point, any name means only what people agree that it means. A URI is unique, but there's only so much you can do to enforce the assignment of meaning to them. But non-unique names, of course, can collide by accident and are ill-suited to federation. -- Scott From jimsch@nwlink.com Wed Aug 17 16:02: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 8321E11E8081 for ; Wed, 17 Aug 2011 16:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+tdzE3IXo9h for ; Wed, 17 Aug 2011 16:02:31 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61821F8548 for ; Wed, 17 Aug 2011 16:02:31 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.pacifier.net (Postfix) with ESMTPS id 360BC2CA1E; Wed, 17 Aug 2011 16:03:19 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "Josh Howlett" Date: Wed, 17 Aug 2011 16:37:46 -0700 Message-ID: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.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: AcxdLL7/uxu2AHvmQ1SmW8sa3fWK/A== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 23:02:32 -0000 Ok - let's try this again - only without the big mistake from last time. 1. Republish the document even if it has no changes so it can be found = on the working group page. 2. SAML attributes are named by a naming type and a name value, but = they may also be thought of as being named by the issuing authority. In = the event a urn such as = urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used, then the = meaning is (hopefully) well understood and common to all authorizes. = However if a string such as "Major" is used, the meaning and set of = values may be highly dependent on the issuing authority. 3. Traveling all the way back to Beijing, I believe it was stated that = we would only ever have a single SAML assertion that is transported from = the IDP to the service, however it could contain nested statements. Is = this still a working assumption for the group. Note: I do not believe = that this has ever been explicitly stated in any documents. What = happens if AAA transports back two different SAML statements? 4. For SAML attributes - What happens if there are multiple values for = a single attribute. These could be multiple values within a single SAML = assertion (i.e. two different clauses with the same name but = with different values such as two different email names (which would be = required to be transported as two different attributes). Or they could = be given by two different SAML statement issuers, but the items are = nested. In this case the values could be either the same or different, = but the issuer name for the attribute would be different. In this case = should they be treated as alternate values for a single attribute or as = different attributes which are scoped by the issuer name. 5. Are we defining a property in the GSS EAP namespace that can contain = the set of attributes that the service wants to have returned by the = IDP? This could take the value of the SAML Request to be sent to the = IDP. 6. I don't understand how an independent check could be made on any = SAML assertions without pulling out the total SAML assertion, checking = it and then pulling the attributes from it. How could one check the = value of a single attribute (per last sentence of section 5.2 para 2 - = An implementation MAY apply local policy checks to this assertion and = discard it if it is unacceptable according to these checks.) 7. I am not sure what section 5.3 is saying - Is this just a to be = written place holder? 8. We are establishing a new registry in this document. What are the = rules we are going to define for this. I assume we want expert review = but I don't remember there ever being a discussion. =20 From hartmans@painless-security.com Wed Aug 17 17: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 33D6221F8BD5 for ; Wed, 17 Aug 2011 17:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l45NuXNlVtkX for ; Wed, 17 Aug 2011 17:21:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4BE21F8BCD for ; Wed, 17 Aug 2011 17:21:20 -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 626E7201CB; Wed, 17 Aug 2011 20:24:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 422FC42B7; Wed, 17 Aug 2011 20:22:05 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> Date: Wed, 17 Aug 2011 20:22:05 -0400 In-Reply-To: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> (Jim Schaad's message of "Wed, 17 Aug 2011 16:37:46 -0700") 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, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 00:21:21 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> 2. SAML attributes are named by a naming type and a name Jim> value, but they may also be thought of as being named by the Jim> issuing authority. In the event a urn such as Jim> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used, Jim> then the meaning is (hopefully) well understood and common to Jim> all authorizes. However if a string such as "Major" is used, Jim> the meaning and set of values may be highly dependent on the Jim> issuing authority. True. Keep in mind that the name attribute is in the context of a name. In the case of gss-eap, the realm in which the name is interpreted should be reasonably obvious from the name. For SAML EC, it may be a bit more tricky, but honestly, if you use a non-globally-unique name attribute you may run into trouble. Jim> 3. Traveling all the way back to Beijing, I believe it was Jim> stated that we would only ever have a single SAML assertion Jim> that is transported from the IDP to the service, I don't remember that so much as saying that was what we are specifying now. Jim> however it Jim> could contain nested statements. Is this still a working Jim> assumption for the group. Note: I do not believe that this has Jim> ever been explicitly stated in any documents. What happens if Jim> AAA transports back two different SAML statements? I'm confused: I thought an assertion was a kind of statement. If we have multiple assertions, I would expect that draft-ietf-gss-eap-naming would not really apply or would only apply to the core-/main assertion. I'd expect other assertions would typically have a different context. Jim> 4. For SAML attributes - What happens if there are multiple Jim> values for a single attribute. These could be multiple values Jim> within a single SAML assertion (i.e. two different Jim> clauses with the same name but with different values such as Jim> two different email names (which would be required to be Jim> transported as two different attributes). Or they could be Jim> given by two different SAML statement issuers, but the items Jim> are nested. In this case the values could be either the same Jim> or different, but the issuer name for the attribute would be Jim> different. In this case should they be treated as alternate Jim> values for a single attribute or as different attributes which Jim> are scoped by the issuer name. GSS naming extensions does not really support this; I'd say the behavior should be undefined until GSS has a story for this. Jim> 5. Are we defining a property in the GSS EAP namespace that Jim> can contain the set of attributes that the service wants to Jim> have returned by the IDP? This could take the value of the Jim> SAML Request to be sent to the IDP. It's my understanding we are not currently doing that. I'd prefer to have someone say that they would implement before we spend energy specifying this. Jim> 6. I don't understand how an independent check could be made Jim> on any SAML assertions without pulling out the total SAML Jim> assertion, checking it and then pulling the attributes from it. Jim> How could one check the value of a single attribute (per last Jim> sentence of section 5.2 para 2 - An implementation MAY apply Jim> local policy checks to this assertion and discard it if it is Jim> unacceptable according to these checks.) Someone wants to log in as root. Your local policy doesn't believe they should be authorized to do so. Jim> 7. I am not sure what section 5.3 is saying - Is this just a Jim> to be written place holder? I think it's a TBD. Jim> 8. We are establishing a new registry in this document. What Jim> are the rules we are going to define for this. I assume we Jim> want expert review but I don't remember there ever being a Jim> discussion. Are you talking about the URN registry? If so, I'd assume ietf consensus or standards action. It's just a URI registry; you shouldn't need ours unless you're publishing our documents. If you are on your own, use your own. Jim> _______________________________________________ abfab mailing Jim> list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From cantor.2@osu.edu Wed Aug 17 20:08: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 AE1935E8004 for ; Wed, 17 Aug 2011 20:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ah7Ygth1ePn for ; Wed, 17 Aug 2011 20:08:08 -0700 (PDT) Received: from defang11.it.ohio-state.edu (defang11.it.ohio-state.edu [128.146.216.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF7B25E8003 for ; Wed, 17 Aug 2011 20:08:07 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang11.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p7I38vLO021274; Wed, 17 Aug 2011 23:08:57 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%11]) with mapi; Wed, 17 Aug 2011 23:08:57 -0400 From: "Cantor, Scott" To: Sam Hartman , Jim Schaad Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AcxdLL7/uxu2AHvmQ1SmW8sa3fWK/AAMaOiA///rjoA= Date: Thu, 18 Aug 2011 03:08:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <865ccefc-95b4-4996-8175-088ea454ba7f> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.18 Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 03:08:09 -0000 On 8/17/11 8:22 PM, "Sam Hartman" wrote: > >I'm confused: I thought an assertion was a kind of statement. An assertion is (most of the time) a set of zero or more statements by an issuer about a subject. If they're attribute statements, all the statements are essentially just the same thing, and the attributes they contain can be pooled together. The syntax of multiple statements is notational, but there are no semantics to having 3 attributes in one statement and 2 in another. You wouldn't generally see it, and if you did, it doesn't mean anything different than one statement with 5 attributes. Multiple assertions by one issuer are therefore similarly poolable if they're referring to the same subject, apart from any distinct conditions they might have or other content that would limit or influence their validity. Multiple assertions by different issuers are of course a wholly different animal. That means exactly the messy, complex thing you would expect it to mean. One of the important things is to determine whether all the assertions, if there can in fact by more than one, must all refer to the same principal. And if they do, does that imply that all the Subjects must be identical? Or is the surrounding protocol providing a guarantee that whatever identifiers appear in the subjects, even if different, refer to the same principal. Some people will argue strongly that unless the Subjects match identically, it's impossible for a relying party to treat them as referring to one principal. I don't share that view, I think that's something that can be defined by the protocol as a whole. -- Scott From ietf@augustcellars.com Wed Aug 17 22:49: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 690265E8003 for ; Wed, 17 Aug 2011 22:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am+Vv5ip8QyW for ; Wed, 17 Aug 2011 22:49:27 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 598255E8002 for ; Wed, 17 Aug 2011 22:49:27 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2914E38EF1; Wed, 17 Aug 2011 22:50:17 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> In-Reply-To: Date: Wed, 17 Aug 2011 23:24:57 -0700 Message-ID: <00a801cc5d6f$8eebc1b0$acc34510$@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: AQKisnnhwVGAYcr+6kBUM1VkLvvKkgEzM+Vwk2vZgCA= Content-Language: en-us Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 05:49:28 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, August 17, 2011 5:22 PM > To: Jim Schaad > Cc: abfab@ietf.org; 'Sam Hartman' > Subject: Re: [abfab] EAP naming attribute document > > >>>>> "Jim" == Jim Schaad writes: > > Jim> 2. SAML attributes are named by a naming type and a name > Jim> value, but they may also be thought of as being named by the > Jim> issuing authority. In the event a urn such as > Jim> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used, > Jim> then the meaning is (hopefully) well understood and common to > Jim> all authorizes. However if a string such as "Major" is used, > Jim> the meaning and set of values may be highly dependent on the > Jim> issuing authority. > > True. > Keep in mind that the name attribute is in the context of a name. > In the case of gss-eap, the realm in which the name is interpreted should be > reasonably obvious from the name. > For SAML EC, it may be a bit more tricky, but honestly, if you use a non- > globally-unique name attribute you may run into trouble. So your claim is that knowledge of the REALM of the IDP is sufficient to determine what, if any, interpretation of the name should be. We should probably state this in the document. > > Jim> 3. Traveling all the way back to Beijing, I believe it was > Jim> stated that we would only ever have a single SAML assertion > Jim> that is transported from the IDP to the service, > > I don't remember that so much as saying that was what we are specifying > now. > > > Jim> however it > Jim> could contain nested statements. Is this still a working > Jim> assumption for the group. Note: I do not believe that this has > Jim> ever been explicitly stated in any documents. What happens if > Jim> AAA transports back two different SAML statements? > > I'm confused: I thought an assertion was a kind of statement. > If we have multiple assertions, I would expect that draft-ietf-gss-eap-naming > would not really apply or would only apply to the core-/main assertion. > I'd expect other assertions would typically have a different context. My bad - I meant to type -- What happens if AAA transports back two different SAML assertions. I am still getting statement and assertion confused. What I am looking at is draft-howlett-radius-saml-attr, it is currently documented as saying that all of the data bytes of all of the Radius packets in a AAA message are concatenated together. This means that it is not possible for two SAML assertions to be returned (successful) in that the second one would be appended to the first one and you would basically have two XML constructs concatenated. One could either modify that draft or modify the XML parsing code to deal with two SAML assertions being returned but that is not presently stated. Thus I believe that only one (the first) would be successfully found and parsed under today's specifications. However (Scott please help me here), in Beijing I was informed that for the use case that I had it would be possible for the IDP to next a SAML assertion from a different issuer within its own assertion. I don't know the syntax that would be expected to ensue (but I really do want to know). > > > Jim> 4. For SAML attributes - What happens if there are multiple > Jim> values for a single attribute. These could be multiple values > Jim> within a single SAML assertion (i.e. two different > Jim> clauses with the same name but with different values such as > Jim> two different email names (which would be required to be > Jim> transported as two different attributes). Or they could be > Jim> given by two different SAML statement issuers, but the items > Jim> are nested. In this case the values could be either the same > Jim> or different, but the issuer name for the attribute would be > Jim> different. In this case should they be treated as alternate > Jim> values for a single attribute or as different attributes which > Jim> are scoped by the issuer name. > > GSS naming extensions does not really support this; I'd say the behavior > should be undefined until GSS has a story for this. So I would expect that current GSS behavior would be to say randomly return one of them rather than fail. An issue to potentially raise on kitten. > > > Jim> 5. Are we defining a property in the GSS EAP namespace that > Jim> can contain the set of attributes that the service wants to > Jim> have returned by the IDP? This could take the value of the > Jim> SAML Request to be sent to the IDP. > > It's my understanding we are not currently doing that. > I'd prefer to have someone say that they would implement before we spend > energy specifying this. Plasma is probably going to want this as soon as we start implementations. The current concept is that the service is going to ask the IdP for the set of attributes that it needs to evaluate the set of policies applied to a message. The expectation is that one would not wish to send all attributes that might be needed to evaluate random policies in generation. Additionally it is expected that SAML assertion issues might map statements from their space onto the service providers space. Thus this is something that should become important to me quickly. > > Jim> 6. I don't understand how an independent check could be made > Jim> on any SAML assertions without pulling out the total SAML > Jim> assertion, checking it and then pulling the attributes from it. > Jim> How could one check the value of a single attribute (per last > Jim> sentence of section 5.2 para 2 - An implementation MAY apply > Jim> local policy checks to this assertion and discard it if it is > Jim> unacceptable according to these checks.) > > Someone wants to log in as root. > Your local policy doesn't believe they should be authorized to do so. Ok - I misunderstood this. My assumption was not that this statement was dealing with how local policy is applied to the attributes in the course of making a local policy decision about a request from the client. But was about the question of if the local policy server thought that the IdP was competent to make the attribute statement and if there was sufficient checking on the SAML assertion that it could be used. > > > Jim> 7. I am not sure what section 5.3 is saying - Is this just a > Jim> to be written place holder? > > I think it's a TBD. > > Jim> 8. We are establishing a new registry in this document. What > Jim> are the rules we are going to define for this. I assume we > Jim> want expert review but I don't remember there ever being a > Jim> discussion. > > Are you talking about the URN registry? > If so, I'd assume ietf consensus or standards action. > It's just a URI registry; you shouldn't need ours unless you're publishing our > documents. > If you are on your own, use your own. Yes I was looking at the URN registry established by this document. So I would be happy with IETF consensus as an addition rule. Jim > > > > > > Jim> _______________________________________________ abfab > mailing > Jim> list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Thu Aug 18 01:43: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 48CD621F889A for ; Thu, 18 Aug 2011 01:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHTjsTkrkN3o for ; Thu, 18 Aug 2011 01:43:55 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7827721F8A35 for ; Thu, 18 Aug 2011 01:43:55 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B8D751A9A666_E4CD0FEB; Thu, 18 Aug 2011 08:44:46 +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 90DF91A9A60F_E4CD0FEF; Thu, 18 Aug 2011 08:44:46 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 18 Aug 2011 09:44:46 +0100 From: Josh Howlett To: "Cantor, Scott" , Sam Hartman , Jim Schaad Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AcxdLL7/uxu2AHvmQ1SmW8sa3fWK/AAECpGnAAO3vYAADdLgAA== Date: Thu, 18 Aug 2011 08:44:45 +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: <49BFE6435DDF83498F5248BEF931677B@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 08:43:56 -0000 >Some people will argue strongly that unless the Subjects match >identically, it's impossible for a relying party to treat them as >referring to one principal. I don't share that view, I think that's >something that can be defined by the protocol as a whole. +1. An identifier is semantically a special purpose attribute statement. It's reasonable (and often desirable) for different issuers to know the same subject by different identifiers. That may not be convenient for relying parties where identifier equivalence is clearly convenient; but if it causes problems they can fix it at the business level. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Thu Aug 18 02:23:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C384C21F8A64 for ; Thu, 18 Aug 2011 02:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF5TCDGIlEYS for ; Thu, 18 Aug 2011 02:23:57 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15221F8AC9 for ; Thu, 18 Aug 2011 02:23:56 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 578894A6B64_E4CDA5FB; Thu, 18 Aug 2011 09:24:47 +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 E8B204A6B62_E4CDA5EF; Thu, 18 Aug 2011 09:24:46 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Thu, 18 Aug 2011 10:24:46 +0100 From: Josh Howlett To: Jim Schaad , Sam Hartman Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AcxdLL7/uxu2AHvmQ1SmW8sa3fWK/AAECpGnAAqQaoAACF/UAA== Date: Thu, 18 Aug 2011 09:24:45 +0000 Message-ID: In-Reply-To: <00a801cc5d6f$8eebc1b0$acc34510$@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: <742F6E03752F334487E2607E00778CE9@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" , 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 09:23:58 -0000 >My bad - I meant to type -- What happens if AAA transports back two >different SAML assertions. I am still getting statement and assertion >confused. A statement is basically a strongly typed value. An assertion is an envelope for >0 statements that provides the rest of the context; who does those statements describe, who is making the claim, how long is this claim valid for, etc. >What I am looking at is draft-howlett-radius-saml-attr, it is currently >documented as saying that all of the data bytes of all of the Radius >packets >in a AAA message are concatenated together. This means that it is not >possible for two SAML assertions to be returned (successful) in that the >second one would be appended to the first one and you would basically have >two XML constructs concatenated. One could either modify that draft or >modify the XML parsing code to deal with two SAML assertions being >returned >but that is not presently stated. Thus I believe that only one (the >first) >would be successfully found and parsed under today's specifications. draft-howlett-radius-saml-attr transports SAML protocol messages. A single protocol message can certainly contain >1 assertion. >However (Scott please help me here), in Beijing I was informed that for >the >use case that I had it would be possible for the IDP to next a SAML >assertion from a different issuer within its own assertion. I don't know >the syntax that would be expected to ensue (but I really do want to know). It's certainly possible to do that using the element (see 2.6.1 of SAMLCore). I don't know whether it makes sense for your use case. >>=20 >>=20 >> Jim> 5. Are we defining a property in the GSS EAP namespace that >> Jim> can contain the set of attributes that the service wants to >> Jim> have returned by the IDP? This could take the value of the >> Jim> SAML Request to be sent to the IDP. >>=20 >> It's my understanding we are not currently doing that. >> I'd prefer to have someone say that they would implement before we spend >> energy specifying this. > >Plasma is probably going to want this as soon as we start implementations. >The current concept is that the service is going to ask the IdP for the >set >of attributes that it needs to evaluate the set of policies applied to a >message. The expectation is that one would not wish to send all >attributes >that might be needed to evaluate random policies in generation. You can trivially specify the required attributes in an message issued by the RP to the IdP, using draft-howlett-radius-saml-attr. (The Moonshot GSS EAP implementation doesn't currently support an application to signal its attribute requirements, mainly because as Sam implies (I think) the GSS API doesn't currently support this; but a local AAA proxy that knew the application's requirement could inject this. I believe it would be better for the application to do this, though) >Additionally it is expected that SAML assertion issues might map >statements >from their space onto the service providers space. Thus this is something >that should become important to me quickly. I think that's an implementation issue. (FYI, the Moonshot implementation supports this; one of the benefits of using Scott's SP) 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 lukeh@padl.com Thu Aug 18 03:06:23 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4304C21F8AE1 for ; Thu, 18 Aug 2011 03:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yMjpM0ITRO8 for ; Thu, 18 Aug 2011 03:06:22 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8421F8AD2 for ; Thu, 18 Aug 2011 03:06:22 -0700 (PDT) Received: by us.padl.com with ESMTP id p7IA7731010079; Thu, 18 Aug 2011 06:07:11 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> Date: Thu, 18 Aug 2011 10:07:08 +0000 Content-Transfer-Encoding: 7bit Message-Id: <432EC99B-2F2D-4672-A958-DCB0DBEA7CFD@padl.com> References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1244.3) 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, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 10:06:23 -0000 >> GSS naming extensions does not really support this; I'd say the behavior >> should be undefined until GSS has a story for this. > > So I would expect that current GSS behavior would be to say randomly return > one of them rather than fail. An issue to potentially raise on kitten. GSS naming extensions does support multiple valued attributes. -- Luke From hartmans@painless-security.com Thu Aug 18 05:48: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 BA2CF21F8AB0 for ; Thu, 18 Aug 2011 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9h6fvwZyPFz for ; Thu, 18 Aug 2011 05:48:50 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4527E21F8A62 for ; Thu, 18 Aug 2011 05:48:49 -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 0BA562016A; Thu, 18 Aug 2011 08:52:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6F4AD42B7; Thu, 18 Aug 2011 08:49:35 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> <432EC99B-2F2D-4672-A958-DCB0DBEA7CFD@padl.com> Date: Thu, 18 Aug 2011 08:49:35 -0400 In-Reply-To: <432EC99B-2F2D-4672-A958-DCB0DBEA7CFD@padl.com> (Luke Howard's message of "Thu, 18 Aug 2011 10:07:08 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , 'Sam Hartman' , abfab@ietf.org Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 12:48:50 -0000 >>>>> "Luke" == Luke Howard writes: >>> GSS naming extensions does not really support this; I'd say the >>> behavior should be undefined until GSS has a story for this. >> >> So I would expect that current GSS behavior would be to say >> randomly return one of them rather than fail. An issue to >> potentially raise on kitten. Luke> GSS naming extensions does support multiple valued attributes. I don't think it's reasonable to use that support if different values come from different issuers. From lukeh@padl.com Thu Aug 18 06:01:49 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8821F8B3B for ; Thu, 18 Aug 2011 06:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD1M4mxEaxbX for ; Thu, 18 Aug 2011 06:01:45 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36A21F8B32 for ; Thu, 18 Aug 2011 06:01:45 -0700 (PDT) Received: by us.padl.com with ESMTP id p7ID2V9F021584; Thu, 18 Aug 2011 09:02:35 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 18 Aug 2011 13:02:31 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1EA07D89-B8E7-4CB6-B188-2E0EEA88D2EC@padl.com> References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> <432EC99B-2F2D-4672-A958-DCB0DBEA7CFD@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1244.3) 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: Jim Schaad , 'Sam Hartman' , abfab@ietf.org Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 13:01:49 -0000 Right you are. On 18/08/2011, at 12:49 PM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > >>>> GSS naming extensions does not really support this; I'd say the >>>> behavior should be undefined until GSS has a story for this. >>> >>> So I would expect that current GSS behavior would be to say >>> randomly return one of them rather than fail. An issue to >>> potentially raise on kitten. > > Luke> GSS naming extensions does support multiple valued attributes. > > I don't think it's reasonable to use that support if different values > come from different issuers. -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From leifj@mnt.se Thu Aug 18 06:17: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 4089921F8AE6 for ; Thu, 18 Aug 2011 06:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHyP7KaNlX1O for ; Thu, 18 Aug 2011 06:17:55 -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 49E9321F8ABB for ; Thu, 18 Aug 2011 06:17:55 -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 p7IDIhSv029108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Aug 2011 15:18:48 +0200 (CEST) Message-ID: <4E4D1133.1000805@mnt.se> Date: Thu, 18 Aug 2011 15:18:43 +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: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> <432EC99B-2F2D-4672-A958-DCB0DBEA7CFD@padl.com> <1EA07D89-B8E7-4CB6-B188-2E0EEA88D2EC@padl.com> In-Reply-To: <1EA07D89-B8E7-4CB6-B188-2E0EEA88D2EC@padl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 13:17:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2011 03:02 PM, Luke Howard wrote: > Right you are. > > On 18/08/2011, at 12:49 PM, Sam Hartman wrote: > >>>>>>> "Luke" == Luke Howard writes: >> >>>>> GSS naming extensions does not really support this; I'd say the >>>>> behavior should be undefined until GSS has a story for this. >>>> >>>> So I would expect that current GSS behavior would be to say >>>> randomly return one of them rather than fail. An issue to >>>> potentially raise on kitten. >> >> Luke> GSS naming extensions does support multiple valued attributes. >> >> I don't think it's reasonable to use that support if different values >> come from different issuers. +1 that actually sounds like something that should go into a security considerations text somewhere. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5NETMACgkQ8Jx8FtbMZndjaQCgl/SSTfkWYx04lsI9yyBKffie 32sAn0s9ve4DUn8wM9IyfP2hj8GmBhF6 =7CqP -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Aug 18 10:36: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 6B8A511E80A0 for ; Thu, 18 Aug 2011 10:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sZPANasKmbd for ; Thu, 18 Aug 2011 10:36:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC2411E809E for ; Thu, 18 Aug 2011 10:36:53 -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 405B42016A; Thu, 18 Aug 2011 13:40:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5147C42B7; Thu, 18 Aug 2011 13:37:39 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> Date: Thu, 18 Aug 2011 13:37:39 -0400 In-Reply-To: <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> (Jim Schaad's message of "Wed, 17 Aug 2011 23:24:57 -0700") 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, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 17:36:54 -0000 OK. 1) I think we should say somewhere that you shouldn't send back multiple assertions unless it's appropriate to just combine them together. I.E. assertions from the same IDP about the same subject are probably OK, at least until we figure out what we want to do in those cases. 2) It sounds like we should start doing design work on the case of attributes coming from multiple sources at least enough to support your use cases. My personal suspicion is that I want a bit more AAA framing than we do for the single issuer case. I don't have a problem doing that standardization now. However I want to make sure that is not mandatory-to-implement and that a RP can easily tell if a situation it does not implement is happening. 3) I agree we should add a statement about non-unique name attributes to the draft. 4) I agree the comments about policy should be clarified. 5) I agree the IANA section needs all the standard things including a registration process. --Sam From ietf@augustcellars.com Thu Aug 18 15:29:46 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC23C21F880C for ; Thu, 18 Aug 2011 15:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02a1-O-2wPKe for ; Thu, 18 Aug 2011 15:29:46 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 33C1B21F87F9 for ; Thu, 18 Aug 2011 15:29:46 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id DFF2838F22; Thu, 18 Aug 2011 15:30:40 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> In-Reply-To: Date: Thu, 18 Aug 2011 16:05:26 -0700 Message-ID: <013201cc5dfb$516a30b0$f43e9210$@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: AQKisnnhwVGAYcr+6kBUM1VkLvvKkgEzM+VwAqfqdvwBT/yEepNNOJeA Content-Language: en-us Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute 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, 18 Aug 2011 22:29:46 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Thursday, August 18, 2011 10:38 AM > To: Jim Schaad > Cc: abfab@ietf.org; 'Sam Hartman' > Subject: Re: [abfab] EAP naming attribute document > > OK. > > 1) I think we should say somewhere that you shouldn't send back multiple > assertions unless it's appropriate to just combine them together. > I.E. assertions from the same IDP about the same subject are probably OK, at > least until we figure out what we want to do in those cases. > > 2) It sounds like we should start doing design work on the case of attributes > coming from multiple sources at least enough to support your use cases. My > personal suspicion is that I want a bit more AAA framing than we do for the > single issuer case. I don't have a problem doing that standardization now. > However I want to make sure that is not mandatory-to-implement and that a > RP can easily tell if a situation it does not implement is happening. As long as they come back, I don't think that I need any more support (other than query). My expectation is that we are just going to extract the entire SAML assertion intact and process it w/o the aid of GSS. Jim > > 3) I agree we should add a statement about non-unique name attributes to > the draft. > > 4) I agree the comments about policy should be clarified. > > > 5) I agree the IANA section needs all the standard things including a > registration process. > > --Sam From hartmans@painless-security.com Thu Aug 18 19:57: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 8AC9A11E8085 for ; Thu, 18 Aug 2011 19:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECWV5FEiivLG for ; Thu, 18 Aug 2011 19:57:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2053B11E8082 for ; Thu, 18 Aug 2011 19:57:55 -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 17AAF2016A; Thu, 18 Aug 2011 23:01:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BC8CC42B7; Thu, 18 Aug 2011 22:58:43 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> <013201cc5dfb$516a30b0$f43e9210$@augustcellars.com> Date: Thu, 18 Aug 2011 22:58:43 -0400 In-Reply-To: <013201cc5dfb$516a30b0$f43e9210$@augustcellars.com> (Jim Schaad's message of "Thu, 18 Aug 2011 16:05:26 -0700") 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, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:57:56 -0000 OK. If the advice element is good enough for you then I agree nothing needs doing. From hartmans@painless-security.com Thu Aug 18 19:59: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 E3D2A11E808C for ; Thu, 18 Aug 2011 19:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1YO1kviWqFg for ; Thu, 18 Aug 2011 19:59:31 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0111E8082 for ; Thu, 18 Aug 2011 19:59:31 -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 EF2E32016A; Thu, 18 Aug 2011 23:02:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C44F542B7; Thu, 18 Aug 2011 23:00:21 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> <013201cc5dfb$516a30b0$f43e9210$@augustcellars.com> Date: Thu, 18 Aug 2011 23:00:21 -0400 In-Reply-To: <013201cc5dfb$516a30b0$f43e9210$@augustcellars.com> (Jim Schaad's message of "Thu, 18 Aug 2011 16:05:26 -0700") 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, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:59:32 -0000 Also, Josh implied that GSS doesn't have a way to ask the IDP for attributes. I actually think we can set an attribute on the acceptor credential's name to indicate what we want to query the IDP for. From ietf@augustcellars.com Thu Aug 18 23:56:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B925E8003 for ; Thu, 18 Aug 2011 23:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfUwsE4kc+Iz for ; Thu, 18 Aug 2011 23:56:14 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 583E25E8002 for ; Thu, 18 Aug 2011 23:56:14 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B2ABA38F35 for ; Thu, 18 Aug 2011 23:57:08 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 19 Aug 2011 00:31:53 -0700 Message-ID: <015d01cc5e42$13a05970$3ae10c50$@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: AcxeQVWYIwJZaalSSb2aLjriD3LynQ== Content-Language: en-us Subject: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 06:56:14 -0000 I note that this document focuses on the AttributeStatement exclusively. While I don't see any need to have AuthzDecisionStatements to be exposed, is there going to be a desire to expose the contents of AuthenStatements - Authentication statements? Doing so would allow for an IdP to advertise to the server exactly what EAP method was used in authenticating the client. This may be of interest to the server if it wishes to know what level of authentication was obtained in order to determine if access should be allowed. Specifically, some servers may have policy that says that the client needs to validate to the IdP using two-factor authentication or better (Level 3 for NIST SP 800-63) or access will be denied as being insufficiently authenticated. Jim From Josh.Howlett@ja.net Fri Aug 19 02:43: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 6728621F876F for ; Fri, 19 Aug 2011 02:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.834 X-Spam-Level: X-Spam-Status: No, score=-102.834 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDX4fh9KOHW7 for ; Fri, 19 Aug 2011 02:43:45 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id D403521F854F for ; Fri, 19 Aug 2011 02:43:44 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D53901A9A8AC_E4E3086B for ; Fri, 19 Aug 2011 09:44:38 +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 E14CB1A9A8B8_E4E3085F for ; Fri, 19 Aug 2011 09:44:37 +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, 19 Aug 2011 10:44:37 +0100 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AcxeQVWYIwJZaalSSb2aLjriD3LynQAE0RYA Date: Fri, 19 Aug 2011 09:44:37 +0000 Message-ID: In-Reply-To: <015d01cc5e42$13a05970$3ae10c50$@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: <46070E17B0FA0649911F1B4969717F98@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 09:43:45 -0000 Jim, >I note that this document focuses on the AttributeStatement exclusively. >While I don't see any need to have AuthzDecisionStatements to be exposed, >is >there going to be a desire to expose the contents of AuthenStatements - >Authentication statements? I agree. Section 5.2 should be generalised to deal with SAML statements in general. >Doing so would allow for an IdP to advertise to the server exactly what >EAP >method was used in authenticating the client. I don't think there's a SAML Authentication Context defined for EAP, let alone the multitude of methods. However, like you say, it might actually be useful to define one. Perhaps a composite value consisting of the EAP type plus one of the existing SAML Authentication Contexts to signal the type of credential? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Aug 19 08:43:52 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE97821F8AF8 for ; Fri, 19 Aug 2011 08:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOeIzAkGqesa for ; Fri, 19 Aug 2011 08:43:52 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31021F8AEC for ; Fri, 19 Aug 2011 08:43:52 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id BFD201A9D66D_E4E84EFB; Fri, 19 Aug 2011 15:44:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 6699A1A9D64F_E4E84EFF; Fri, 19 Aug 2011 15:44:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 19 Aug 2011 16:44:47 +0100 From: Josh Howlett To: Sam Hartman , Jim Schaad Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AQHMXc2Guxu2AHvmQ1SmW8sa3fWK/JUkUjuA Date: Fri, 19 Aug 2011 15:44:46 +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="iso-8859-1" Content-ID: <5BF84A806CF8324CAB503E29D4970960@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" , 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 15:43:52 -0000 >1) I think we should say somewhere that you shouldn't send back multiple >assertions unless it's appropriate to just combine them together. >I.E. assertions from the same IDP about the same subject are probably >OK, at least until we figure out what we want to do in those cases. I think we need to be circumspect how we choose to constrain the protocol. If we need it for technical interoperability, fine. Otherwise I'd prefer to leave anything to do with the semantics of the messages to the application to worry about. I don=B9t think its the business of the transport or framing to dictate that. >2) It sounds like we should start doing design work on the case of >attributes coming from multiple sources at least enough to support your >use cases. My personal suspicion is that I want a bit more AAA framing >than we do for the single issuer case. I don't have a problem doing >that standardization now. However I want to make sure that is not >mandatory-to-implement and that a RP can easily tell if a situation >it does not implement is happening. I agree. However I think we already partially support the case of assertions from multiple issuers within a single transaction, where a AAA server has aggregated assertions from multiple IdPs and is sending them along to the AAA client. That's just a bunch of assertions in a single SAML response message over the AAA response. We don't support the case where the client needs to specify to the AAA server which statements it needs from which IdPs. However, we also need to consider the case where the AAA client is aggregating assertions from multiple AAA servers. In the general case, this is my preferred aggregation strategy. We've touched on this in the past, but not really taken it anywhere. 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 Aug 19 09:24: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 C63B021F8A36 for ; Fri, 19 Aug 2011 09:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT6ru6rYsaRv for ; Fri, 19 Aug 2011 09:24:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 533C521F886A for ; Fri, 19 Aug 2011 09:24:34 -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 6943C201CB; Fri, 19 Aug 2011 12:27:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6DD0C42B7; Fri, 19 Aug 2011 12:25:22 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Fri, 19 Aug 2011 12:25:22 -0400 In-Reply-To: (Josh Howlett's message of "Fri, 19 Aug 2011 15:44:46 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Jim Schaad , 'Sam Hartman' , "abfab@ietf.org" Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:24:34 -0000 >>>>> "Josh" == Josh Howlett writes: >> 1) I think we should say somewhere that you shouldn't send back >> multiple assertions unless it's appropriate to just combine them >> together. I.E. assertions from the same IDP about the same >> subject are probably OK, at least until we figure out what we >> want to do in those cases. Josh> I think we need to be circumspect how we choose to constrain Josh> the protocol. If we need it for technical interoperability, Josh> fine. Otherwise I'd prefer to leave anything to do with the Josh> semantics of the messages to the application to worry about. I Josh> don¹t think its the business of the transport or framing to Josh> dictate that. In principle I'd agree with you. However in practice I think it is very difficult for the application to understand these semantics in an interoperable manner (something we very much need applications to do) unless the framing explains that to the application. I have no problem introducing a semantics code or purpose code or something so we can define new semantics in the future and reuse the framing. However the semantics fairly clearly need to be nailed down well enough to understand whether we can use the naming context implied in draft-ietf-gss-eap-naming. That context today only deals with attributes and SAML messages that are about the subject of the authentication vouched for by an IDP sufficiently tied into the authentication process that the RP need not care about the distinction. If you throw in an assertion about someone else, or from someone else, we don't know how an application should interpret it; we won't be able to write interoperable applications in that case. Also, even if you throw in an unrelated SAML message, we won't know how to process it. Even if in some cases such information could be distinguished with careful application of metadata, it's far easier for the sender to explain what the sender is doing than for the recipient to try and interoperably infer it. --Sam From Josh.Howlett@ja.net Fri Aug 19 09:39: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 2B51B21F8B31 for ; Fri, 19 Aug 2011 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-4qrpmkgp0O for ; Fri, 19 Aug 2011 09:39:16 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 956DA21F8B1B for ; Fri, 19 Aug 2011 09:39:16 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3AA481A9D68A_E4E91EDB; Fri, 19 Aug 2011 16:40:13 +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 1D34F1A9D685_E4E91EDF; Fri, 19 Aug 2011 16:40:13 +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, 19 Aug 2011 17:40:12 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AQHMXc2Guxu2AHvmQ1SmW8sa3fWK/JUkUjuAgAALbAGAAAQOgA== Date: Fri, 19 Aug 2011 16:40:11 +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: <79FFD67B6184934BB13A48B61AB928CE@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad , 'Sam Hartman' , "abfab@ietf.org" Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:39:17 -0000 I think that's a perfectly compelling argument from technical interoperability. 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 ietf@augustcellars.com Fri Aug 19 14:01:07 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 0F8C91F0C3B for ; Fri, 19 Aug 2011 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klUWED44N1du for ; Fri, 19 Aug 2011 14:01:06 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8553B1F0C34 for ; Fri, 19 Aug 2011 14:01:06 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 245322CA95; Fri, 19 Aug 2011 14:02:04 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , References: <015d01cc5e42$13a05970$3ae10c50$@augustcellars.com> In-Reply-To: Date: Fri, 19 Aug 2011 14:36:55 -0700 Message-ID: <01b601cc5eb8$1e1c3420$5a549c60$@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: AQHvbok7eVf8XDLDTIKVD/u1h0qZc5Tekr8A Content-Language: en-us Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:01:07 -0000 I suggested having the EAP because it is what we are using for authentication, however I think that using one of the existing authentication methods is probably sufficient. The IdP would need to know how to map from the EAP method used to a SAML Authentication Context profile, but that is out of scope for our group. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Josh Howlett > Sent: Friday, August 19, 2011 2:45 AM > To: abfab@ietf.org > Subject: Re: [abfab] EAP naming attribute document > > Jim, > > >I note that this document focuses on the AttributeStatement exclusively. > >While I don't see any need to have AuthzDecisionStatements to be > >exposed, is there going to be a desire to expose the contents of > >AuthenStatements - Authentication statements? > > I agree. Section 5.2 should be generalised to deal with SAML statements in > general. > > > >Doing so would allow for an IdP to advertise to the server exactly what > >EAP method was used in authenticating the client. > > I don't think there's a SAML Authentication Context defined for EAP, let > alone the multitude of methods. However, like you say, it might actually be > useful to define one. Perhaps a composite value consisting of the EAP type > plus one of the existing SAML Authentication Contexts to signal the type of > credential? > > 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 ietf@augustcellars.com Fri Aug 19 14:12:59 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC80711E80C7 for ; Fri, 19 Aug 2011 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVQ3bWs8lDeD for ; Fri, 19 Aug 2011 14:12:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFB811E80C6 for ; Fri, 19 Aug 2011 14:12:59 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A22B02CA98; Fri, 19 Aug 2011 14:13:53 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , "'Sam Hartman'" References: In-Reply-To: Date: Fri, 19 Aug 2011 14:48:44 -0700 Message-ID: <01b701cc5eb9$c5464820$4fd2d860$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJwxrkLpTicRb/jyderKq5kODIInZPb44IA Content-Language: en-us Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:12:59 -0000 > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@ja.net] > Sent: Friday, August 19, 2011 8:45 AM > To: Sam Hartman; Jim Schaad > Cc: abfab@ietf.org; 'Sam Hartman' > Subject: Re: [abfab] EAP naming attribute document >=20 > >1) I think we should say somewhere that you shouldn't send back > >multiple assertions unless it's appropriate to just combine them together. > >I.E. assertions from the same IDP about the same subject are probably > >OK, at least until we figure out what we want to do in those cases. >=20 > I think we need to be circumspect how we choose to constrain the = protocol. > If we need it for technical interoperability, fine. Otherwise I'd = prefer to leave > anything to do with the semantics of the messages to the application = to > worry about. I don=B9t think its the business of the transport or = framing to > dictate that. I tend to agree with Sam here. Given that different subject values = could refer to the same subject, there is no way for the service to know which SAML statements would be for the client and which are extraneous without such a constraint being stated. >=20 > >2) It sounds like we should start doing design work on the case of > >attributes coming from multiple sources at least enough to support = your > >use cases. My personal suspicion is that I want a bit more AAA = framing > >than we do for the single issuer case. I don't have a problem doing > >that standardization now. However I want to make sure that is not > >mandatory-to-implement and that a RP can easily tell if a situation = it > >does not implement is happening. >=20 > I agree. However I think we already partially support the case of assertions > from multiple issuers within a single transaction, where a AAA server = has > aggregated assertions from multiple IdPs and is sending them along to = the > AAA client. That's just a bunch of assertions in a single SAML = response > message over the AAA response. We don't support the case where the = client > needs to specify to the AAA server which statements it needs from = which > IdPs. >=20 > However, we also need to consider the case where the AAA client is > aggregating assertions from multiple AAA servers. In the general case, this is > my preferred aggregation strategy. We've touched on this in the past, = but > not really taken it anywhere. I don't understand your usage case here. I can understand the case of = the AAA server at the IdP aggregating multiple statements together based on = a SAML query that came with the EAP message, however having the AAA client doing this functionality I don't understand. How it would take place? Are you suggesting that the server ought to be able to send multiple = SAML queries through the AAA client to get multiple statements? Or are you saying that GSS-EAP should somehow do this? Jim >=20 > Josh. >=20 >=20 >=20 > 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 Josh.Howlett@ja.net Sat Aug 20 06:15:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3421F880C for ; Sat, 20 Aug 2011 06:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkq65FsUwzwV for ; Sat, 20 Aug 2011 06:15:40 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2A21F8804 for ; Sat, 20 Aug 2011 06:15:39 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 267C81A9A992_E4FB3B6B; Sat, 20 Aug 2011 13:16:38 +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 867021A9A286_E4FB3B4F; Sat, 20 Aug 2011 13:16: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; Sat, 20 Aug 2011 14:16:36 +0100 From: Josh Howlett To: Jim Schaad , Sam Hartman Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AQHMXc2Guxu2AHvmQ1SmW8sa3fWK/JUkUjuAgABU7gCAARP9AA== Date: Sat, 20 Aug 2011 13:16:35 +0000 Message-ID: In-Reply-To: <01b701cc5eb9$c5464820$4fd2d860$@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=UTF-8 Content-ID: <33CD658067D10545A39D011708B02BB6@ukerna.ac.uk> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "abfab@ietf.org" , 'Sam Hartman' Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 13:15:41 -0000 DQo+PiANCj4+IEkgdGhpbmsgd2UgbmVlZCB0byBiZSBjaXJjdW1zcGVjdCBob3cgd2UgY2hvb3Nl IHRvIGNvbnN0cmFpbiB0aGUNCj4+cHJvdG9jb2wuDQo+PiBJZiB3ZSBuZWVkIGl0IGZvciB0ZWNo bmljYWwgaW50ZXJvcGVyYWJpbGl0eSwgZmluZS4gT3RoZXJ3aXNlIEknZCBwcmVmZXINCj50byBs ZWF2ZQ0KPj4gYW55dGhpbmcgdG8gZG8gd2l0aCB0aGUgc2VtYW50aWNzIG9mIHRoZSBtZXNzYWdl cyB0byB0aGUgYXBwbGljYXRpb24gdG8NCj4+IHdvcnJ5IGFib3V0LiBJIGRvbsK5dCB0aGluayBp dHMgdGhlIGJ1c2luZXNzIG9mIHRoZSB0cmFuc3BvcnQgb3IgZnJhbWluZw0KPj50bw0KPj4gZGlj dGF0ZSB0aGF0Lg0KPg0KPkkgdGVuZCB0byBhZ3JlZSB3aXRoIFNhbSBoZXJlLiAgR2l2ZW4gdGhh dCBkaWZmZXJlbnQgc3ViamVjdCB2YWx1ZXMgY291bGQNCj5yZWZlciB0byB0aGUgc2FtZSBzdWJq ZWN0LCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBzZXJ2aWNlIHRvIGtub3cgd2hpY2gNCj5TQU1M IHN0YXRlbWVudHMgd291bGQgYmUgZm9yIHRoZSBjbGllbnQgYW5kIHdoaWNoIGFyZSBleHRyYW5l b3VzIHdpdGhvdXQNCj5zdWNoIGEgY29uc3RyYWludCBiZWluZyBzdGF0ZWQuDQoNCkkgZG9uJ3Qg dGhpbmsgd2UgZGlzYWdyZWUsIHdlJ3JlIGp1c3Qgc2F5aW5nIHNsaWdodGx5IGRpZmZlcmVudCB0 aGluZ3MuDQoNCkkgdGhpbmsgU2FtIHdhcyBzYXlpbmcgdGhhdCAtIGFzIGEgYmFzZWxpbmUgLSB3 ZSBzaG91bGQgY29uc3RyYWluIHRoZQ0KcHJvdG9jb2wgc28gdGhhdCB0aGUgc2VydmljZSBjYW4g YXNzdW1lIHRoYXQgYXNzZXJ0aW9ucyB3aXRoIGRpZmZlcmVudA0KY2xhaW1lZCBzdWJqZWN0cyBy ZWZlciB0byB0aGUgc2FtZSBwcmluY2lwYWwgKG5vdGUgdGhhdCB0aGF0IGRvZXNuJ3QNCnJlcXVp cmUsIGF0IHRoZSBwYXlsb2FkIGxldmVsLCB0aGF0IHR3byBvciBtb3JlIGFzc2VydGlvbnMgbXVz dCBoYXZlIHRoZQ0Kc2FtZSBzdWJqZWN0IHZhbHVlKS4gSSB3YXMgc2F5aW5nIHRoYXQgc2Vydmlj ZSBzaG91bGQgYmUgZnJlZSB0byBpZ25vcmUNCnRoZSBzdWJqZWN0IHZhbHVlIGNsYWltZWQgYnkg dGhlIHN5c3RlbSwgYW5kIGluZmVyIHRoZSB1c2Ugb2YgYW5vdGhlcg0KdmFsdWUgb24gdGhlIGJh c2lzIG9mIG90aGVyIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgcHJvdG9jb2wgb3IgcGF5bG9hZA0K Y29udGV4dCwgZm9yIGl0cyBvd24gcHVycG9zZXMgKHdoYXRldmVyIHRoZXkgbWlnaHQgYmUpLg0K DQpUaGUgb3JpZ2luYWwgaW50ZW50IHdhcyB0byB1c2UgU0FNTCdzIG1vZGVsLCB3aGVyZSBzY2Vu YXJpby1zcGVjaWZpYw0KY29uc3RyYWludHMgYXJlIGRlZmluZWQgc2VwYXJhdGVseSBmcm9tIHRo ZSB0cmFuc3BvcnQgYW5kIGZyYW1pbmcNCiJCaW5kaW5nIiBzcGVjaWZpY2F0aW9ucyB3aXRoaW4g IlByb2ZpbGUiIHNwZWNpZmljYXRpb25zLiBXaGlsZSB0aGlzDQpwcm92aWRlcyBhIHNlcGFyYXRp b24gb2YgY29uY2VybnMgYW5kIG90aGVyIGdvb2Qgc3R1ZmYsIGl0J3MgYWxzbyBhIGxvdCBvZg0K d29yayBhbmQgSSBkb24ndCB0aGluayB3ZSd2ZSBoYWQgYSBtb3RpdmF0aW5nIHVzZS1jYXNlIHVu dGlsIG5vdy4gSXQgY291bGQNCmJlIHRoYXQgd2UgbmVlZCB0byBsb29rIGF0IHRoaXMgYWdhaW4g c28gdGhhdCB3ZSBjYW4sIGFzIFNhbSBzYXlzLCAiZGVmaW5lDQpuZXcgc2VtYW50aWNzIGluIHRo ZSBmdXR1cmUgYW5kIHJldXNlIHRoZSBmcmFtaW5nIi4NCg0KPj4gDQo+PiA+MikgSXQgc291bmRz IGxpa2Ugd2Ugc2hvdWxkIHN0YXJ0IGRvaW5nIGRlc2lnbiB3b3JrIG9uIHRoZSBjYXNlIG9mDQo+ PiA+YXR0cmlidXRlcyBjb21pbmcgZnJvbSBtdWx0aXBsZSBzb3VyY2VzIGF0IGxlYXN0IGVub3Vn aCB0byBzdXBwb3J0IHlvdXINCj4+ID51c2UgY2FzZXMuICBNeSBwZXJzb25hbCBzdXNwaWNpb24g aXMgdGhhdCBJIHdhbnQgYSBiaXQgbW9yZSBBQUEgZnJhbWluZw0KPj4gPnRoYW4gd2UgZG8gZm9y IHRoZSBzaW5nbGUgaXNzdWVyIGNhc2UuICBJIGRvbid0IGhhdmUgYSBwcm9ibGVtIGRvaW5nDQo+ PiA+dGhhdCBzdGFuZGFyZGl6YXRpb24gbm93LiBIb3dldmVyIEkgd2FudCB0byBtYWtlIHN1cmUg dGhhdCBpcyBub3QNCj4+ID5tYW5kYXRvcnktdG8taW1wbGVtZW50IGFuZCB0aGF0IGEgUlAgY2Fu IGVhc2lseSB0ZWxsIGlmIGEgc2l0dWF0aW9uIGl0DQo+PiA+ZG9lcyBub3QgaW1wbGVtZW50IGlz IGhhcHBlbmluZy4NCj4+IA0KPj4gSSBhZ3JlZS4gSG93ZXZlciBJIHRoaW5rIHdlIGFscmVhZHkg cGFydGlhbGx5IHN1cHBvcnQgdGhlIGNhc2Ugb2YNCj5hc3NlcnRpb25zDQo+PiBmcm9tIG11bHRp cGxlIGlzc3VlcnMgd2l0aGluIGEgc2luZ2xlIHRyYW5zYWN0aW9uLCB3aGVyZSBhIEFBQSBzZXJ2 ZXINCj4+aGFzDQo+PiBhZ2dyZWdhdGVkIGFzc2VydGlvbnMgZnJvbSBtdWx0aXBsZSBJZFBzIGFu ZCBpcyBzZW5kaW5nIHRoZW0gYWxvbmcgdG8NCj4+dGhlDQo+PiBBQUEgY2xpZW50LiBUaGF0J3Mg anVzdCBhIGJ1bmNoIG9mIGFzc2VydGlvbnMgaW4gYSBzaW5nbGUgU0FNTCByZXNwb25zZQ0KPj4g bWVzc2FnZSBvdmVyIHRoZSBBQUEgcmVzcG9uc2UuIFdlIGRvbid0IHN1cHBvcnQgdGhlIGNhc2Ug d2hlcmUgdGhlDQo+PmNsaWVudA0KPj4gbmVlZHMgdG8gc3BlY2lmeSB0byB0aGUgQUFBIHNlcnZl ciB3aGljaCBzdGF0ZW1lbnRzIGl0IG5lZWRzIGZyb20gd2hpY2gNCj4+IElkUHMuDQo+PiANCj4+ IEhvd2V2ZXIsIHdlIGFsc28gbmVlZCB0byBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSB0aGUgQUFB IGNsaWVudCBpcw0KPj4gYWdncmVnYXRpbmcgYXNzZXJ0aW9ucyBmcm9tIG11bHRpcGxlIEFBQSBz ZXJ2ZXJzLiBJbiB0aGUgZ2VuZXJhbCBjYXNlLA0KPnRoaXMgaXMNCj4+IG15IHByZWZlcnJlZCBh Z2dyZWdhdGlvbiBzdHJhdGVneS4gV2UndmUgdG91Y2hlZCBvbiB0aGlzIGluIHRoZSBwYXN0LA0K Pj5idXQNCj4+IG5vdCByZWFsbHkgdGFrZW4gaXQgYW55d2hlcmUuDQo+DQo+SSBkb24ndCB1bmRl cnN0YW5kIHlvdXIgdXNhZ2UgY2FzZSBoZXJlLiAgSSBjYW4gdW5kZXJzdGFuZCB0aGUgY2FzZSBv ZiB0aGUNCj5BQUEgc2VydmVyIGF0IHRoZSBJZFAgYWdncmVnYXRpbmcgbXVsdGlwbGUgc3RhdGVt ZW50cyB0b2dldGhlciBiYXNlZCBvbiBhDQo+U0FNTCBxdWVyeSB0aGF0IGNhbWUgd2l0aCB0aGUg RUFQIG1lc3NhZ2UsIGhvd2V2ZXIgaGF2aW5nIHRoZSBBQUEgY2xpZW50DQo+ZG9pbmcgdGhpcyAg ZnVuY3Rpb25hbGl0eSBJIGRvbid0IHVuZGVyc3RhbmQuICAgSG93IGl0IHdvdWxkIHRha2UgcGxh Y2U/DQo+QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhlIHNlcnZlciBvdWdodCB0byBiZSBhYmxl IHRvIHNlbmQgbXVsdGlwbGUgU0FNTA0KPnF1ZXJpZXMgdGhyb3VnaCB0aGUgQUFBIGNsaWVudCB0 byBnZXQgbXVsdGlwbGUgc3RhdGVtZW50cz8NCg0KWWVzOyB0aGVyZSB3YXMgc29tZSBtYWlsIGFi b3V0IHRoZSB1c2Ugb2YgdGhlIEF1dGhvcml6ZS1Pbmx5IGZhY2lsaXR5DQpwcmV2aW91c2x5Og0K DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWJmYWIvY3VycmVudC9tc2cw MDM2Ni5odG1sDQoNCkkgZG9uJ3QgdGhpbmsgd2UgcmVzb2x2ZWQgd2hldGhlciB0aGlzIHdhcyBh IHJlYXNvbmFibGUgdXNlIG9mIHRoaXMNCmZhY2lsaXR5IGluIHRoYXQgdGhlIEF1dGhvcml6ZS1P bmx5IHJlcXVlc3QgaXNuJ3QgZ29pbmcgdG8gdGhlIG9yaWdpbmFsDQphdXRoZW50aWNhdGlvbiBz ZXJ2ZXIsIGJ1dCBhbm90aGVyIEFBQSBzZXJ2ZXIuIEkndmUgYmVlbiBtZWFuaW5nIHRvIGFzaw0K QWxhbiB0byBzZWVrIGhpcyBvcGluaW9uLi4uDQoNCkpvc2guDQoNCg0KCkpBTkVUKFVLKSBpcyBh IHRyYWRpbmcgbmFtZSBvZiBUaGUgSk5UIEFzc29jaWF0aW9uLCBhIGNvbXBhbnkgbGltaXRlZApi eSBndWFyYW50ZWUgd2hpY2ggaXMgcmVnaXN0ZXJlZCBpbiBFbmdsYW5kIHVuZGVyIE5vLiAyODgx MDI0IAphbmQgd2hvc2UgUmVnaXN0ZXJlZCBPZmZpY2UgaXMgYXQgTHVtZW4gSG91c2UsIExpYnJh cnkgQXZlbnVlLApIYXJ3ZWxsIE94Zm9yZCwgRGlkY290LCBPeGZvcmRzaGlyZS4gT1gxMSAwU0cK Cg== From gabilm@um.es Tue Aug 30 04:14: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 2133721F8ADE for ; Tue, 30 Aug 2011 04:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3gA36h-UwFR for ; Tue, 30 Aug 2011 04:14:36 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20621F8AD3 for ; Tue, 30 Aug 2011 04:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id DCE364BDC9 for ; Tue, 30 Aug 2011 13:15:53 +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 7yBHmXRdurcl for ; Tue, 30 Aug 2011 13:15:53 +0200 (CEST) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPSA id 30B2E4BCE1 for ; Tue, 30 Aug 2011 13:15:51 +0200 (CEST) Message-ID: <4E5CC65E.40601@um.es> Date: Tue, 30 Aug 2011 13:15:42 +0200 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: abfab@ietf.org References: <015d01cc5e42$13a05970$3ae10c50$@augustcellars.com> In-Reply-To: <015d01cc5e42$13a05970$3ae10c50$@augustcellars.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [abfab] EAP naming attribute 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: Tue, 30 Aug 2011 11:14:37 -0000 Hi, What I think is missing in the documents is the SAML profile for abfab. The architecture document says that SAML requests may or not may appear as RADIUS attributes in the request, but it is quite ambiguos. The home AAA server has to know if a SAML attribute, authentication or authorization statement should be returned, and it has to be specified in the RADIUS request. I mean, there should be in some place, a description of the SAML queries to be used, statement to be returned and, for example, if they has to be signed or encrypted. It could also imply a problem if the assertion is too big to be transported over the radius message (even if fragmentation occurs). Regards, Gabi. El 19/08/11 09:31, Jim Schaad escribió: > I note that this document focuses on the AttributeStatement exclusively. > While I don't see any need to have AuthzDecisionStatements to be exposed, is > there going to be a desire to expose the contents of AuthenStatements - > Authentication statements? > > Doing so would allow for an IdP to advertise to the server exactly what EAP > method was used in authenticating the client. This may be of interest to > the server if it wishes to know what level of authentication was obtained in > order to determine if access should be allowed. Specifically, some servers > may have policy that says that the client needs to validate to the IdP using > two-factor authentication or better (Level 3 for NIST SP 800-63) or access > will be denied as being insufficiently authenticated. > > Jim > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From hartmans@painless-security.com Tue Aug 30 09:00: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 5454521F8D1A for ; Tue, 30 Aug 2011 09:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AVBSmQzOtUu for ; Tue, 30 Aug 2011 09:00:55 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DC54921F8D18 for ; Tue, 30 Aug 2011 09:00:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [206.29.182.129]) (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 11B7B201F1; Tue, 30 Aug 2011 12:04:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4668742B7; Tue, 30 Aug 2011 12:02:09 -0400 (EDT) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <015d01cc5e42$13a05970$3ae10c50$@augustcellars.com> <4E5CC65E.40601@um.es> Date: Tue, 30 Aug 2011 12:02:09 -0400 In-Reply-To: <4E5CC65E.40601@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22's?= message of "Tue, 30 Aug 2011 13:15:42 +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: abfab@ietf.org Subject: Re: [abfab] EAP naming attribute 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: Tue, 30 Aug 2011 16:00:56 -0000 >>>>> "Gabriel" == Gabriel López writes: Gabriel> Hi, Gabriel> What I think is missing in the documents is the SAML Gabriel> profile for abfab. The architecture document says that Gabriel> SAML requests may or not may appear as RADIUS attributes in Gabriel> the request, but it is quite ambiguos. The home AAA server Gabriel> has to know if a SAML attribute, authentication or Gabriel> authorization statement should be returned, and it has to Gabriel> be specified in the RADIUS request. I mean, there should Gabriel> be in some place, a description of the SAML queries to be Gabriel> used, statement to be returned and, for example, if they Gabriel> has to be signed or encrypted. It could also imply a Gabriel> problem if the assertion is too big to be transported over Gabriel> the radius message (even if fragmentation occurs). I agree some of this needs to be specified. In particular, enough needs to be specified that the RP knows what it can rely on. I think that draft-ietf-abfab-aaa-saml is probably the right place for that. --Sam