From kjk@internet2.edu Fri Nov 1 20:31:43 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD28C11E8181 for ; Fri, 1 Nov 2013 20:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 c2psIqWp+OLr for ; Fri, 1 Nov 2013 20:31:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id ED3CE21E80C6 for ; Fri, 1 Nov 2013 20:31:28 -0700 (PDT) Received: from BLUPR08MB309.namprd08.prod.outlook.com (10.141.48.143) by BLUPR08MB309.namprd08.prod.outlook.com (10.141.48.143) with Microsoft SMTP Server (TLS) id 15.0.815.6; Sat, 2 Nov 2013 03:31:19 +0000 Received: from BLUPR08MB309.namprd08.prod.outlook.com ([169.254.11.41]) by BLUPR08MB309.namprd08.prod.outlook.com ([169.254.11.41]) with mapi id 15.00.0815.000; Sat, 2 Nov 2013 03:31:19 +0000 From: Ken Klingenstein To: "abfab@ietf.org" Thread-Topic: comments on UI considerations for ABFAB Thread-Index: AQHO13v+HPsi3egzA0a8J9/pLIKlqw== Date: Sat, 2 Nov 2013 03:31:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.208.17.141] x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(83072001)(77096001)(56816003)(81686001)(74706001)(16236675002)(76176001)(36756003)(76786001)(76796001)(2656002)(85306002)(87266001)(76482001)(80976001)(81816001)(83322001)(47446002)(79102001)(74662001)(51856001)(31966008)(59766001)(74366001)(81542001)(77982001)(56776001)(54316002)(80022001)(65816001)(63696002)(66066001)(81342001)(75432001)(54356001)(74502001)(69226001)(4396001)(53806001)(47976001)(46102001)(50986001)(74876001)(47736001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR08MB309; H:BLUPR08MB309.namprd08.prod.outlook.com; CLIP:71.208.17.141; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE99CE2315E38kjkinternet2edu_" MIME-Version: 1.0 X-OriginatorOrg: internet2.edu X-Mailman-Approved-At: Fri, 01 Nov 2013 23:34:13 -0700 Subject: [abfab] comments on UI considerations for ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Nov 2013 03:31:43 -0000 --_000_CE99CE2315E38kjkinternet2edu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rhys et al, I've done my homework (fearing Leif's steely eye) and reviewed the draft = on the UI considerations (Sept 25 version). I'll be at IETF Sunday night th= rough Wednesday, in case you'd like to chat further about this, but have to= leave before the ABFAB session on Thursday. There's a lot of "still to do" sections in the draft, as you know - I'd b= e glad to look at them. A few overarching comments, and then some specifics on the draft. 1. I'm glad that you're looking at the larger discovery problem issue= s rather than just the ABFAB use case. That said, it does bring the discuss= ion close to other efforts such as AccountChooser. In speaking to John Brad= ley recently, they have many of the concerns that you mention (most notably= they are now considering how to control what IdP's can register with an SP= or an accountchooser location - trying to get into a dynamic process such = as the one you mention, etc. Some reference to those discussions might be u= seful. 2. There is almost no mention of privacy related issues. As a matter = of form, there should be such as a section. Maybe mention the issues around= hiding IdP's (we've had instances where people wanted to conceal their IdP= choices from interested governments -certainly not in the US :)) - to whet= her an IdP follows privacy principles (via an end-entity tag or some other = information that might want to be shown to the user.) One of the other ways= this could be brought out is via some mention of identifiers. In your terminology section, I would introduce the identifier vs identity= distinction, one I'm trying to hammer on in NSTIC. You mention that a user= MAY have multiple identities. It would be good to say that an identity MAY= have multiple identifiers associated with it, in order to preserve privacy= , etc. The first sentence in section 4 could use some smoothing - seems like an = awkward sentence. In that same section, you talk about a headless mode oper= ation, but don't define it (and I, as a semi-knowledgeable reader don't kno= w what it means.) The first sentence in section 6 uses "firstly" - not English on this side= of the pond. And at the end of section 6.1, a typo (exmaple instead of exa= mple). In section 7, first sentence needs the word "tell" to be singular (tells= ). Also, the many-many scenario you talk about, in terms of complexities, m= ight be best addressed with a single identity and a mechanisms for that ide= ntity to convey the role its in. Maybe hard in an ABFAB case, but maybe not= and worth a mention as an alternative. Again, willing to review new sections as they are added. A topic close to= home for me. Ken --_000_CE99CE2315E38kjkinternet2edu_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <74FF0319B8610E45953FF2AAA919F563@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Rhys et al,
  I've done my homework (fearing Leif's steely eye) and reviewed = the draft on the UI considerations (Sept 25 version). I'll be at IETF Sunda= y night through Wednesday, in case you'd like to chat further about this, b= ut have to leave before the ABFAB session on Thursday. 
  There's a lot of "still to do" sections in the draft,= as you know – I'd be glad to look at them.
  A few overarching comments, and then some specifics on the draf= t.
      1. I'm glad that you're looking at the larger dis= covery problem issues rather than just the ABFAB use case. That said, it do= es bring the discussion close to other efforts such as AccountChooser. In s= peaking to John Bradley recently, they have many of the concerns that you mention (most notably they are now considering ho= w to control what IdP's can register with an SP or an accountchooser locati= on – trying to get into a dynamic process such as the one you mention= , etc. Some reference to those discussions might be useful.
      2. There is almost no mention of privacy related = issues. As a matter of form, there should be such as a section. Maybe menti= on the issues around hiding IdP's (we've had instances where people wanted = to conceal their IdP choices from interested governments –certainly not in the US :)) - to whether an IdP follows privacy pri= nciples (via an end-entity tag or some other information that might want to= be shown to the user.) One of the other ways this could be brought out is = via some mention of identifiers.
  In your terminology section, I would introduce the identifier v= s identity distinction, one I'm trying to hammer on in NSTIC. You mention t= hat a user MAY have multiple identities. It would be good to say that an id= entity MAY have multiple identifiers associated with it, in order to preserve privacy, etc. 
  The first sentence in section 4 could use some smoothing –= ; seems like an awkward sentence. In that same section, you talk about a he= adless mode operation, but don't define it (and I, as a semi-knowledgeable = reader don't know what it means.)
  The first sentence in section 6 uses "firstly" - not = English on this side of the pond. And at the end of section 6.1, a typo (ex= maple instead of example).
   In section 7, first sentence needs the word "tell&qu= ot; to be singular (tells). Also, the many-many scenario you talk about, in= terms of complexities, might be best addressed with a single identity and = a mechanisms for that identity to convey the role its in. Maybe hard in an ABFAB case, but maybe not and worth a mention as an a= lternative.
  Again, willing to review new sections as they are added. A topi= c close to home for me.

             Ken

--_000_CE99CE2315E38kjkinternet2edu_-- From kjk@internet2.edu Sat Nov 2 10:15:08 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6521F9B9F for ; Sat, 2 Nov 2013 10:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fUSG71247jQp for ; Sat, 2 Nov 2013 10:15:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 646D611E8218 for ; Sat, 2 Nov 2013 10:14:58 -0700 (PDT) Received: from BLUPR08MB309.namprd08.prod.outlook.com (10.141.48.143) by BLUPR08MB310.namprd08.prod.outlook.com (10.141.48.149) with Microsoft SMTP Server (TLS) id 15.0.815.6; Sat, 2 Nov 2013 17:14:57 +0000 Received: from BLUPR08MB309.namprd08.prod.outlook.com ([169.254.11.41]) by BLUPR08MB309.namprd08.prod.outlook.com ([169.254.11.41]) with mapi id 15.00.0815.000; Sat, 2 Nov 2013 17:14:56 +0000 From: Ken Klingenstein To: "abfab@ietf.org" Thread-Topic: comments on UI considerations for ABFAB Thread-Index: AQHO1+8NnrYVgZ5p4E+czQUI8PwD1w== Date: Sat, 2 Nov 2013 17:14:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.208.17.141] x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(81542001)(76786001)(31966008)(69226001)(76482001)(81686001)(76796001)(74366001)(59766001)(77982001)(83322001)(74662001)(56776001)(16236675002)(80976001)(81816001)(2656002)(65816001)(66066001)(36756003)(56816003)(76176001)(54316002)(80022001)(79102001)(87266001)(53806001)(51856001)(54356001)(4396001)(85306002)(63696002)(50986001)(74502001)(46102001)(77096001)(75432001)(83072001)(47736001)(74706001)(74876001)(49866001)(47446002)(81342001)(47976001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR08MB310; H:BLUPR08MB309.namprd08.prod.outlook.com; CLIP:71.208.17.141; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE9A8F0615E53kjkinternet2edu_" MIME-Version: 1.0 X-OriginatorOrg: internet2.edu Subject: [abfab] comments on UI considerations for ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Nov 2013 17:15:08 -0000 --_000_CE9A8F0615E53kjkinternet2edu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rhys et al, I've done my homework (fearing Leif's steely eye) and reviewed the draft = on the UI considerations (Sept 25 version). I'll be at IETF Sunday night th= rough Wednesday, in case you'd like to chat further about this, but have to= leave before the ABFAB session on Thursday. There's a lot of "still to do" sections in the draft, as you know - I'd b= e glad to look at them. A few overarching comments, and then some specifics on the draft. 1. I'm glad that you're looking at the larger discovery problem issue= s rather than just the ABFAB use case. That said, it does bring the discuss= ion close to other efforts such as AccountChooser. In speaking to John Brad= ley recently, they have many of the concerns that you mention (most notably= they are now considering how to control what IdP's can register with an SP= or an accountchooser location - trying to get into a dynamic process such = as the one you mention, etc.) Some reference to those discussions might be= useful. 2. There is almost no mention of privacy related issues. As a matter = of form, there should be such as a section. Maybe mention the issues around= hiding IdP's (we've had instances where people wanted to conceal their IdP= choices from interested governments -certainly not in the US :)) - to whet= her an IdP follows privacy principles (via an end-entity tag or some other = information that might want to be shown to the user.) One of the other ways= this could be brought out is via some mention of identifiers. In your terminology section, I would introduce the identifier vs identity= distinction, one I'm trying to hammer on in NSTIC. You mention that a user= MAY have multiple identities. It would be good to say that an identity MAY= have multiple identifiers associated with it, in order to preserve privacy= , etc. The first sentence in section 4 could use some smoothing - seems like an = awkward sentence. In that same section, you talk about a headless mode oper= ation, but don't define it (and I, as a semi-knowledgeable reader don't kno= w what it means.) The first sentence in section 6 uses "firstly" - not English on this side= of the pond. And at the end of section 6.1, a typo (exmaple instead of exa= mple). In section 7, first sentence needs the word "tell" to be singular (tells= ). Also, the many-many scenario you talk about, in terms of complexities, m= ight be best addressed with a single identity and a mechanisms for that ide= ntity to convey the role its in. Maybe hard in an ABFAB case, but maybe not= and worth a mention as an alternative. Again, willing to review new sections as they are added. A topic close to= home for me. Ken --_000_CE9A8F0615E53kjkinternet2edu_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <45A675C84B9AF647B43233C89211F491@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Rhys et al,
  I've done my homework (fearing Leif's steely eye) and reviewed = the draft on the UI considerations (Sept 25 version). I'll be at IETF Sunda= y night through Wednesday, in case you'd like to chat further about this, b= ut have to leave before the ABFAB session on Thursday. 
  There's a lot of "still to do" sections in the draft,= as you know – I'd be glad to look at them.
  A few overarching comments, and then some specifics on the draf= t.
      1. I'm glad that you're looking at the larger dis= covery problem issues rather than just the ABFAB use case. That said, it do= es bring the discussion close to other efforts such as AccountChooser. In s= peaking to John Bradley recently, they have many of the concerns that you mention (most notably they are now considering ho= w to control what IdP's can register with an SP or an accountchooser locati= on – trying to get into a dynamic process such as the one you mention= , etc.)  Some reference to those discussions might be useful.
      2. There is almost no mention of privacy related = issues. As a matter of form, there should be such as a section. Maybe menti= on the issues around hiding IdP's (we've had instances where people wanted = to conceal their IdP choices from interested governments –certainly not in the US :)) - to whether an IdP follows privacy pri= nciples (via an end-entity tag or some other information that might want to= be shown to the user.) One of the other ways this could be brought out is = via some mention of identifiers.
  In your terminology section, I would introduce the identifier v= s identity distinction, one I'm trying to hammer on in NSTIC. You mention t= hat a user MAY have multiple identities. It would be good to say that an id= entity MAY have multiple identifiers associated with it, in order to preserve privacy, etc. 
  The first sentence in section 4 could use some smoothing –= ; seems like an awkward sentence. In that same section, you talk about a he= adless mode operation, but don't define it (and I, as a semi-knowledgeable = reader don't know what it means.)
  The first sentence in section 6 uses "firstly" - not = English on this side of the pond. And at the end of section 6.1, a typo (ex= maple instead of example).
   In section 7, first sentence needs the word "tell&qu= ot; to be singular (tells). Also, the many-many scenario you talk about, in= terms of complexities, might be best addressed with a single identity and = a mechanisms for that identity to convey the role its in. Maybe hard in an ABFAB case, but maybe not and worth a mention as an a= lternative.
  Again, willing to review new sections as they are added. A topi= c close to home for me.

             Ken

--_000_CE9A8F0615E53kjkinternet2edu_-- From internet-drafts@ietf.org Sun Nov 3 20:00:36 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405AA11E8151; Sun, 3 Nov 2013 20:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 HMQK2KHIIchC; Sun, 3 Nov 2013 20:00:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D80C11E817B; Sun, 3 Nov 2013 20:00:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104040027.8017.42691.idtracker@ietfa.amsl.com> Date: Sun, 03 Nov 2013 20:00:27 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-08.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 04:00:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond Web (AB= FAB) Architecture Author(s) : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-08.txt Pages : 45 Date : 2013-11-03 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-arch-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 4 01:54:01 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB6311E82D2; Mon, 4 Nov 2013 01:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 u5N82RExp1D2; Mon, 4 Nov 2013 01:53:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C45921F9339; Mon, 4 Nov 2013 01:52:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104095209.10172.88386.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 01:52:09 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-07.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 09:54:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding, Profiles, Name Identifier F= ormat, and Confirmation Methods for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-07.txt Pages : 22 Date : 2013-11-04 Abstract: This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, user or machine principals. These principals may be named using an NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. These artifacts have been defined to permit application in AAA scenarios other than ABFAB, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-aaa-saml-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Mon Nov 4 07:56:49 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597FE11E815B for ; Mon, 4 Nov 2013 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IBBbBHPEMXx for ; Mon, 4 Nov 2013 07:56:44 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id C813621E8174 for ; Mon, 4 Nov 2013 07:56:36 -0800 (PST) Received: from Philemon (dhcp-8840.meeting.ietf.org [31.133.136.64]) (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 8ABF138EA6 for ; Mon, 4 Nov 2013 07:56:36 -0800 (PST) From: "Jim Schaad" To: References: <20131104040027.8017.42691.idtracker@ietfa.amsl.com> In-Reply-To: <20131104040027.8017.42691.idtracker@ietfa.amsl.com> Date: Mon, 4 Nov 2013 07:55:14 -0800 Message-ID: <006201ced976$412d28d0$c3877a70$@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: AQIOX4oWZpZsWB18PeD28ptzTA1N9pmWLUkg Content-Language: en-us Subject: [abfab] FW: I-D Action: draft-ietf-abfab-arch-08.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:56:49 -0000 Sam and I believe that this version takes care of all last call comments. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Sunday, November 03, 2013 8:00 PM > To: i-d-announce@ietf.org > Cc: abfab@ietf.org > Subject: [abfab] I-D Action: draft-ietf-abfab-arch-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Application Bridging for Federated Access > Beyond web Working Group of the IETF. > > Title : Application Bridging for Federated Access Beyond Web > (ABFAB) Architecture > Author(s) : Josh Howlett > Sam Hartman > Hannes Tschofenig > Eliot Lear > Jim Schaad > Filename : draft-ietf-abfab-arch-08.txt > Pages : 45 > Date : 2013-11-03 > > Abstract: > Over the last decade a substantial amount of work has occurred in the > space of federated access management. Most of this effort has > focused on two use cases: network access and web-based access. > However, the solutions to these use cases that have been proposed and > deployed tend to have few common building blocks in common. > > This memo describes an architecture that makes use of extensions to > the commonly used security mechanisms for both federated and non- > federated access management, including the Remote Authentication Dial > In User Service (RADIUS) and the Diameter protocol, the Generic > Security Service (GSS), the Extensible Authentication Protocol (EAP) > and the Security Assertion Markup Language (SAML). The architecture > addresses the problem of federated access management to primarily > non-web-based services, in a manner that will scale to large numbers > of identity providers, relying parties, and federations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-abfab-arch > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-abfab-arch-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Mon Nov 4 09:15:09 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5C21E825D for ; Mon, 4 Nov 2013 09:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNtc9r2odhi6 for ; Mon, 4 Nov 2013 09:14:56 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1572E21E8239 for ; Mon, 4 Nov 2013 09:08:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B0F272052B; Mon, 4 Nov 2013 12:06:30 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-kW-oRF52fs; Mon, 4 Nov 2013 12:06:29 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9c4b.meeting.ietf.org [31.133.156.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 4 Nov 2013 12:06:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ABF6787F99; Mon, 4 Nov 2013 12:08:52 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 04 Nov 2013 12:08:52 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: William Atwood Subject: [abfab] MBONED presentation on using EAP for multicast receiver access Control X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:15:09 -0000 Bill is giving a presentation in the mboned session this afternoon from 14:50 until 17:20. I think this overlaps somewhat with the sorts of things ABFAB has been doing, and people here might be interested in the effort. --Sam From Josh.Howlett@ja.net Mon Nov 4 12:06:58 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121DD11E8224 for ; Mon, 4 Nov 2013 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.619 X-Spam-Level: X-Spam-Status: No, score=-98.619 tagged_above=-999 required=5 tests=[AWL=2.120, BAYES_20=-0.74, 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 ifdDQqSMdivZ for ; Mon, 4 Nov 2013 12:06:51 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8FC11E8147 for ; Mon, 4 Nov 2013 12:06:51 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 54F074A6B7F_277FE59B; Mon, 4 Nov 2013 20:06:49 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 09C964A6B1C_277FE58F; Mon, 4 Nov 2013 20:06:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:06:47 +0000 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] MBONED presentation on using EAP for multicast receiver access Control Thread-Index: AQHO2ZljF79CY0iMpEe9h48m7VUulw== Date: Mon, 4 Nov 2013 20:06: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.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <5BDC684949DC4B40A548C6BD4405695D@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: William Atwood Subject: Re: [abfab] MBONED presentation on using EAP for multicast receiver access Control X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:06:58 -0000 > >I think this overlaps somewhat with the sorts of things ABFAB has been >doing, and people here might be interested in the effort. Would greatly appreciate links to any slides, drafts, etc, if available. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From Josh.Howlett@ja.net Mon Nov 4 12:32:00 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C82221E81CB for ; Mon, 4 Nov 2013 12:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.609 X-Spam-Level: X-Spam-Status: No, score=-100.609 tagged_above=-999 required=5 tests=[AWL=1.990, 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 OqCSHIAdJFlt for ; Mon, 4 Nov 2013 12:31:45 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 391B111E82A7 for ; Mon, 4 Nov 2013 12:31:45 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6C3374A6B7F_2780430B; Mon, 4 Nov 2013 20:31:44 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 31C5E4A6B7D_2780430F; Mon, 4 Nov 2013 20:31:44 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:31:43 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: [abfab] MBONED presentation on using EAP for multicast receiver access Control Thread-Index: AQHO2ZljF79CY0iMpEe9h48m7VUul5oVhLoAgAABxwA= Date: Mon, 4 Nov 2013 20:31:42 +0000 Message-ID: In-Reply-To: <527802A8.7050309@concordia.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <32675601496F5D459269E4E0B7B2A2EE@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: William Atwood Subject: [abfab] FW: MBONED presentation on using EAP for multicast receiver access Control X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:32:00 -0000 Thanks Bill. And forwarding at his request... On 04/11/2013 20:25, "William Atwood" wrote: >Josh, > >Here are the links for my presentation in MBONED: >http://www.ietf.org/proceedings/88/slides/slides-88-mboned-1.pptx > >Here are the relevant drafts: >https://datatracker.ietf.org/doc/draft-atwood-mboned-mrac-req/ >https://datatracker.ietf.org/doc/draft-atwood-mboned-mrac-arch/ >https://datatracker.ietf.org/doc/draft-atwood-pim-sigmp/ > >I will also make a presentation of the SIGMP-oriented aspects in PIM on >Friday. The slides are not yet posted in the PIM area of "Meeting >Materials", but a copy is at: >http://users.encs.concordia.ca/~bill/IETF/IETF88-PIM-atwood.pptx > > >I am not a recipient of abfab, so I cannot post to it; if you can >re-post this message that would be good. > > > > Bill Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From Smith@cardiff.ac.uk Mon Nov 4 14:07:45 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6E21E81BB for ; Mon, 4 Nov 2013 14:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id entHjx9tapkA for ; Mon, 4 Nov 2013 14:07:39 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3605221E81B8 for ; Mon, 4 Nov 2013 14:07:31 -0800 (PST) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB021.eurprd02.prod.outlook.com (10.242.81.145) with Microsoft SMTP Server (TLS) id 15.0.815.6; Mon, 4 Nov 2013 22:07:29 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.152]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.235]) with mapi id 15.00.0815.000; Mon, 4 Nov 2013 22:07:29 +0000 From: Rhys Smith To: Ken Klingenstein Thread-Topic: [abfab] comments on UI considerations for ABFAB Thread-Index: AQHO1+8NHPsi3egzA0a8J9/pLIKlq5oVpKCA Date: Mon, 4 Nov 2013 22:07:28 +0000 Message-ID: <0E69B2DE-9A49-42BD-91F4-3BDE73905997@cardiff.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [193.63.63.238] x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(252514010)(51914003)(199002)(189002)(69234005)(81686001)(19580395003)(83322001)(19580405001)(36756003)(63696002)(69226001)(82746002)(2656002)(80976001)(66066001)(83072001)(79102001)(74366001)(77982001)(81816001)(76482001)(51856001)(74876001)(81342001)(54316002)(46102001)(56776001)(47976001)(50986001)(74482001)(4396001)(31966008)(47446002)(74502001)(74662001)(47736001)(49866001)(80022001)(65816001)(33656001)(77096001)(59766001)(56816003)(76796001)(76786001)(81542001)(85306002)(83716003)(54356001)(53806001)(74706001)(87266001)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB021; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:193.63.63.238; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_EEB04B87-6A0F-4E35-B0DF-FF12ADC9F0FD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Cc: "" Subject: Re: [abfab] comments on UI considerations for ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:07:45 -0000 --Apple-Mail=_EEB04B87-6A0F-4E35-B0DF-FF12ADC9F0FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the feedback Ken, very useful. Would be good to catch up over = a coffee or something before you leave. A few quick comments below, but will answer more substantially when I = start to cut the next draft and look at your points in more detail. > Rhys, > I've done my homework (fearing Leif's steely eye) and reviewed the = draft on the UI considerations (Sept 25 version). I'll be at IETF Sunday = night through Wednesday, in case you'd like to chat further about this, = but have to leave before the ABFAB session on Thursday.=20 > There's a lot of "still to do" sections in the draft, as you know =96 = I'd be glad to look at them. > A few overarching comments, and then some specifics on the draft. > 1. I'm glad that you're looking at the larger discovery problem = issues rather than just the ABFAB use case. That said, it does bring the = discussion close to other efforts such as AccountChooser. In speaking to = John Bradley recently, they have many of the concerns that you mention = (most notably they are now considering how to control what IdP's can = register with an SP or an accountchooser location =96 trying to get into = a dynamic process such as the one you mention, etc. Some reference to = those discussions might be useful. > 2. There is almost no mention of privacy related issues. As a = matter of form, there should be such as a section. Maybe mention the = issues around hiding IdP's (we've had instances where people wanted to = conceal their IdP choices from interested governments =96certainly not = the US :)) - to whether an IdP follows privacy principles (via an = end-entity tag or some other information that might want to be shown to = the user.) One of the other ways this could be brought out is via some = mention of identifiers. Absolutely, given I=92m one of the authors of 6973, not having a privacy = section just wouldn=92t be right :-). > In your terminology section, I would introduce the identifier vs = identity distinction, one I'm trying to hammer on in NSTIC. You mention = that a user MAY have multiple identities. It would be good to say that = an identity MAY have multiple identifiers associated with it, in order = to preserve privacy, etc.=20 Good point, agree totally. > The first sentence in section 4 could use some smoothing =96 seems = like an awkward sentence. In that same section, you talk about a = headless mode operation, but don't define it (and I, as a = semi-knowledgeable reader don't know what it means.) OK I=92ll try to sort that out. FYI, headless mode operation would be - = how do you do authentication in a world without a GUI? (e.g. machine to = machine authentication via ABFAB).=20 > The first sentence in section 6 uses "firstly" - not English on this = side of the pond. And at the end of section 6.1, a typo (exmaple instead = of example). > In section 7, first sentence needs the word "tell" to be singular = (tells). Also, the many-many scenario you talk about, in terms of = complexities, might be best addressed with a single identity and a = mechanisms for that identity to convey the role its in. Maybe hard in an = ABFAB case, but maybe not and worth a mention as an alternative. > Again, willing to review new sections as they are added. A topic = close to home for me. Super. Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_EEB04B87-6A0F-4E35-B0DF-FF12ADC9F0FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJ4Gp8ACgkQ3fEsO94vAkziywCg6apr/TT5qsEzWjr1b3pv8xhr vSQAoJR/aYICkVkXSFkqCTj0kxNLLK7k =rNbx -----END PGP SIGNATURE----- --Apple-Mail=_EEB04B87-6A0F-4E35-B0DF-FF12ADC9F0FD-- From hartmans@mit.edu Thu Nov 7 08:27:50 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D808F11E80DC for ; Thu, 7 Nov 2013 08:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaMwD39N8Bvm for ; Thu, 7 Nov 2013 08:27:45 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2921E81AA for ; Thu, 7 Nov 2013 08:27:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 46FE82052F for ; Thu, 7 Nov 2013 11:24:58 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBzZmL-9JvHw for ; Thu, 7 Nov 2013 11:24:58 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9540.meeting.ietf.org [31.133.149.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Thu, 7 Nov 2013 11:24:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C11F831C7; Thu, 7 Nov 2013 11:27:28 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Thu, 07 Nov 2013 11:27:28 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:27:51 -0000 Section 4: The following text does not parse The RADIUS SAML binding defined by this binding Section 5 uses two attributes to convey SAML assertions and protocol messages [OASIS.saml-core-2.0-os] respectively. I think it would be more clear if we move the reference after respectively. I don't think it's right to say that more and reserved are ignored. More for example will be set often and reserved should be handled as in RFC 6929. Section 5: "A SAML Responder that refuses to perform a message exchange with the SAML requester MUST silently discard the request" Please clarify we mean ignore the attribute, not drop the entire RADIUS packet on the floor. It may well be that we generate an access reject as a result, but silent discard at the radius level is not really what we want. Section 5.3.1 Isn't the AAA server a SAML consumer of an authentication request? If so, it seems like it's more realistic for it to apply policy based on the NAS identity rather than the NAI realm as described in the text. I wonder whether requester and responder might be better than issuer and consumer in this section. old: A digitally signed request alone is not sufficient. new: A digitally signed request alone is not sufficient. A AAA entity can include a SAML message that it observes that is never intended by the issuing SAML entity for this AAA session. How exactly would one include a realm identifier in metadata? That is, is there well defined way to name a realm in SAML? Section 7.3.1`: Is this request in the initial access-accept? Every access-accept? Section 7.3.3: Wait. You're saying that my RADIUS server MUST look inside the SAML message and if a certain attribute is present go change my EAP state machine? I don't think anyone will ever implement that. Also, how does it interact with semi-long-term elements like Kerberos TGTs or TEAP tickets? Section 7.3.4: Is the simple system model inside or outside the scope of this profile? This also (and more importantly) applies to the requirements for the response. Ah, I see that this is handled later. There are still a lot of todos. From cantor.2@osu.edu Thu Nov 7 09:23:22 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FDB11E8208 for ; Thu, 7 Nov 2013 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvwY6AJQkz4c for ; Thu, 7 Nov 2013 09:23:15 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8811E8210 for ; Thu, 7 Nov 2013 09:22:43 -0800 (PST) Received: from mail201-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 17:22:42 +0000 Received: from mail201-tx2 (localhost [127.0.0.1]) by mail201-tx2-R.bigfish.com (Postfix) with ESMTP id 953D3A40207; Thu, 7 Nov 2013 17:22:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.218; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf04; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail201-tx2: domain of osu.edu designates 164.107.81.218 as permitted sender) client-ip=164.107.81.218; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf04 ; cio-tnc-pf04 ; Received: from mail201-tx2 (localhost.localdomain [127.0.0.1]) by mail201-tx2 (MessageSwitch) id 1383844960596404_21421; Thu, 7 Nov 2013 17:22:40 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.228]) by mail201-tx2.bigfish.com (Postfix) with ESMTP id 8D901540034; Thu, 7 Nov 2013 17:22:40 +0000 (UTC) Received: from cio-tnc-pf04 (164.107.81.218) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 17:22:40 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf04 (Postfix) with ESMTP id 98F3538004D; Thu, 7 Nov 2013 12:22:39 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 12:22:39 -0500 From: "Cantor, Scott" To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29ZStagnZ58GgE6D1k8C+7opdpoZ83qA Date: Thu, 7 Nov 2013 17:22:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <80048647A4733446AB39B491F2C33599@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:23:22 -0000 On 11/7/13, 11:27 AM, "Sam Hartman" wrote: > >How exactly would one include a realm identifier in metadata? That is, >is there well defined way to name a realm in SAML? No, not really. Historically we took some plains to not tie SAML entities to DNS domains because in a lot of cases what we were really doing was deciding whether to go along with the rest of the planet and conflate email address with identity. There are a bunch of things surrounding this notion that overlap with IdP discovery (which can be realm based, like in edugain, but is that really not just email address? And if not, do users understand the difference?) and with how you do filtering of attributes. At the end of the day, Shibboleth is the only implementation that really ever leveraged anything like a "Realm" and we called it "Scope" and defined a metadata extension for it that allows an IdP to have a many to one relationship with a set of Scopes. Which in practice are domains, though not by definition. -- Scott From cantor.2@osu.edu Thu Nov 7 10:04:48 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF911E8261 for ; Thu, 7 Nov 2013 10:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHLWvJEOdb6N for ; Thu, 7 Nov 2013 10:04:34 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0420911E8216 for ; Thu, 7 Nov 2013 10:04:33 -0800 (PST) Received: from mail208-tx2-R.bigfish.com (10.9.14.227) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 18:04:33 +0000 Received: from mail208-tx2 (localhost [127.0.0.1]) by mail208-tx2-R.bigfish.com (Postfix) with ESMTP id 531452402BA; Thu, 7 Nov 2013 18:04:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzd9hz1de098h8275bh1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail208-tx2: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail208-tx2 (localhost.localdomain [127.0.0.1]) by mail208-tx2 (MessageSwitch) id 1383847471528979_22546; Thu, 7 Nov 2013 18:04:31 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.239]) by mail208-tx2.bigfish.com (Postfix) with ESMTP id 73988540040; Thu, 7 Nov 2013 18:04:31 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 18:04:31 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf02 (Postfix) with ESMTP id 4C05520049; Thu, 7 Nov 2013 13:04:30 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 13:04:30 -0500 From: "Cantor, Scott" To: "Cantor, Scott" , Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29ZStagnZ58GgE6D1k8C+7opdpoZ83qAgAALsQA= Date: Thu, 7 Nov 2013 18:04:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <78BD3F826FD75D488ECC5E4158AF19E6@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:04:48 -0000 On 11/7/13, 12:22 PM, "Cantor, Scott" wrote: >On 11/7/13, 11:27 AM, "Sam Hartman" >wrote: >> >>How exactly would one include a realm identifier in metadata? That is, >>is there well defined way to name a realm in SAML? > >No, not really. Historically we took some plains to not tie SAML entities That should have been "we took some pains". ;-) -- Scott From hartmans@painless-security.com Thu Nov 7 10:13:12 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA321E8228 for ; Thu, 7 Nov 2013 10:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7HqJRxwx7XI for ; Thu, 7 Nov 2013 10:13:03 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CBD7921E8204 for ; Thu, 7 Nov 2013 10:10:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9E7672052B; Thu, 7 Nov 2013 13:08:07 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyT2nNxuc1lr; Thu, 7 Nov 2013 13:08:07 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9c4b.meeting.ietf.org [31.133.156.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 7 Nov 2013 13:08:07 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A089F831C7; Thu, 7 Nov 2013 13:10:37 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Thu, 07 Nov 2013 13:10:37 -0500 In-Reply-To: (Scott Cantor's message of "Thu, 7 Nov 2013 17:22:38 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:13:12 -0000 OK. So, we're telling people that they should confirm that the realm portion of the NAI is in the response or metadata for the IDP, but we have no way to express that name in either interoperably? That's possibly OK, but might need to be called out. From cantor.2@osu.edu Thu Nov 7 10:25:03 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA3B11E81C4 for ; Thu, 7 Nov 2013 10:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 iWB2+xazGxSd for ; Thu, 7 Nov 2013 10:24:57 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 52B5A11E80FB for ; Thu, 7 Nov 2013 10:24:54 -0800 (PST) Received: from mail204-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 18:24:53 +0000 Received: from mail204-va3 (localhost [127.0.0.1]) by mail204-va3-R.bigfish.com (Postfix) with ESMTP id 82218B20195; Thu, 7 Nov 2013 18:24:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail204-va3: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail204-va3 (localhost.localdomain [127.0.0.1]) by mail204-va3 (MessageSwitch) id 1383848691375826_8284; Thu, 7 Nov 2013 18:24:51 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.246]) by mail204-va3.bigfish.com (Postfix) with ESMTP id 54E20780055; Thu, 7 Nov 2013 18:24:51 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 18:24:49 +0000 Received: from CIO-KRC-HT03.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf06 (Postfix) with ESMTP id 7952C3C0064; Thu, 7 Nov 2013 13:22:45 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 13:24:48 -0500 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29ZStagnZ58GgE6D1k8C+7opdpoZ83qAgAAeMeD///MtgA== Date: Thu, 7 Nov 2013 18:24:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:25:03 -0000 On 11/7/13, 1:10 PM, "Sam Hartman" wrote: >OK. >So, we're telling people that they should confirm that the realm >portion of the NAI is in the response or metadata for the IDP, but we >have no way to express that name in either interoperably? > >That's possibly OK, but might need to be called out. Or define something, yes. There are reasons to think something's going to be needed. Realm-based discovery seems likely to be the path forward in other areas. -- Scott From internet-drafts@ietf.org Thu Nov 7 12:35:45 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D0B21E81CE; Thu, 7 Nov 2013 12:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 2Unt0nCvm0o5; Thu, 7 Nov 2013 12:35:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F8921E809F; Thu, 7 Nov 2013 12:35:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107203518.21885.43902.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 12:35:18 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-08.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 20:35:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding, Profiles, Name Identifier F= ormat, and Confirmation Methods for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-08.txt Pages : 24 Date : 2013-11-07 Abstract: This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, user or machine principals. These principals may be named using an NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. These artifacts have been defined to permit application in AAA scenarios other than ABFAB, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-aaa-saml-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Thu Nov 7 13:08:33 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446EE21F9F6C for ; Thu, 7 Nov 2013 13:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j7RAa-J92ZR for ; Thu, 7 Nov 2013 13:08:08 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B2D8C11E81B3 for ; Thu, 7 Nov 2013 13:08:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 721F22052B for ; Thu, 7 Nov 2013 16:05:26 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWLd03rIobsE for ; Thu, 7 Nov 2013 16:05:26 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9c4b.meeting.ietf.org [31.133.156.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Thu, 7 Nov 2013 16:05:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E46FD8352D; Thu, 7 Nov 2013 16:07:56 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Cc: References: <20131107203518.21885.43902.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 16:07:56 -0500 In-Reply-To: <20131107203518.21885.43902.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu, 07 Nov 2013 12:35:18 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-08.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, 07 Nov 2013 21:08:33 -0000 08 was published to address my comments that seemed to have obvious solutions. while I had the document open I took a first crack at privacy and security considerations. From leifj@mnt.se Thu Nov 7 13:32:49 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A23421E8169 for ; Thu, 7 Nov 2013 13:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYms45w9tfMV for ; Thu, 7 Nov 2013 13:32:43 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id BE64911E8127 for ; Thu, 7 Nov 2013 13:32:43 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so1219683pad.11 for ; Thu, 07 Nov 2013 13:32:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Spx20dr77xQiXm6JuW7V8AHM3dKZFk5PoK6fzdgiGPk=; b=YckO77k0djIPu+USXQWxPkyUonalsSkAmTrCwIowkELNcotRRD3rJLOypJD6Kttarv rBtut5Lo3Lgu6b3BRVHjVL4P36tKQlzz+BJO4C4bDoaBbxJ9fAvqpcvb8HRqvbhAGOms JxHdvSklEdZZwlQGOuDmjBe6vziLZDU2MDxXklR/KuUotvFUPgBNkwcuazCmjRGtJ00H WqdPNgRFGvVc/k8ukwmwZcaDJYnnXIT/+A5FfKMz0aVhmofelWPV1BR02kYJbpb4Wi8T a7F2Npv1Cn5l5y6ozpB+w8Gyp+ob+1Pj0XODtUzePczJPdN8J0Bdr8TXRtf1GjWH8nMO HO5w== X-Gm-Message-State: ALoCoQkybFKJ878WYCZ+C6q+msT21eZaOyDt/ORhTFQWnVzbMS0diraAWim9i7eoFaCMaVaU8YjZ X-Received: by 10.68.12.100 with SMTP id x4mr11221314pbb.7.1383859963293; Thu, 07 Nov 2013 13:32:43 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:e0e6:901:2deb:925d? ([2001:67c:370:160:e0e6:901:2deb:925d]) by mx.google.com with ESMTPSA id fb3sm7250925pbc.29.2013.11.07.13.32.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 13:32:42 -0800 (PST) Message-ID: <527C06F8.20603@mnt.se> Date: Thu, 07 Nov 2013 22:32:40 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:32:49 -0000 On 11/07/2013 07:24 PM, Cantor, Scott wrote: > On 11/7/13, 1:10 PM, "Sam Hartman" wrote: > >> OK. >> So, we're telling people that they should confirm that the realm >> portion of the NAI is in the response or metadata for the IDP, but we >> have no way to express that name in either interoperably? >> >> That's possibly OK, but might need to be called out. > Or define something, yes. There are reasons to think something's going to > be needed. Realm-based discovery seems likely to be the path forward in > other areas. > > I would't be surprised to see people asking to overloading Scope for this as it gets deployed. From cantor.2@osu.edu Thu Nov 7 15:11:35 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21E611E81C9 for ; Thu, 7 Nov 2013 15:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FqDtJJ-xc0y for ; Thu, 7 Nov 2013 15:11:28 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF011E8197 for ; Thu, 7 Nov 2013 15:11:27 -0800 (PST) Received: from mail94-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 23:11:14 +0000 Received: from mail94-tx2 (localhost [127.0.0.1]) by mail94-tx2-R.bigfish.com (Postfix) with ESMTP id 7DE5D180094; Thu, 7 Nov 2013 23:11:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail94-tx2: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail94-tx2 (localhost.localdomain [127.0.0.1]) by mail94-tx2 (MessageSwitch) id 1383865872200455_26240; Thu, 7 Nov 2013 23:11:12 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.238]) by mail94-tx2.bigfish.com (Postfix) with ESMTP id 1E9E6C0063; Thu, 7 Nov 2013 23:11:12 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 23:11:11 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf02 (Postfix) with ESMTP id CD94720047; Thu, 7 Nov 2013 18:11:10 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 18:11:10 -0500 From: "Cantor, Scott" To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29ZStagnZ58GgE6D1k8C+7opdpoZ83qAgAAeMeD///MtgIAAmRIA///HtgA= Date: Thu, 7 Nov 2013 23:11:10 +0000 Message-ID: In-Reply-To: <527C06F8.20603@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.31.0.111] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:11:35 -0000 On 11/7/13, 4:32 PM, "Leif Johansson" wrote: > >I would't be surprised to see people asking to overloading Scope for >this as it gets deployed. Almost certainly, which I think is not a good fit. But I don't fully grasp the requirements involved here. I know that Scope is not a direct fit for doing domain-based discovery though. The problem is that it will *usually* be a fit, which for too many people means "good enough". -- Scott From leifj@sunet.se Thu Nov 7 15:43:31 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F021E8195 for ; Thu, 7 Nov 2013 15:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 vPgdpmyGZ8aV for ; Thu, 7 Nov 2013 15:42:59 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4511E8255 for ; Thu, 7 Nov 2013 15:40:36 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id rA7Ne5uv005492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Nov 2013 00:40:05 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id rA7Ne27n019672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Nov 2013 00:40:04 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [31.133.152.76] ([31.133.152.76]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Fri, 8 Nov 2013 00:40:00 +0100 Message-ID: <527C24CD.2000803@sunet.se> Date: Fri, 08 Nov 2013 00:39:57 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KKLE5ui - b549c371d178 - 20131108 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:43:33 -0000 On 11/08/2013 12:11 AM, Cantor, Scott wrote: > On 11/7/13, 4:32 PM, "Leif Johansson" wrote: >> I would't be surprised to see people asking to overloading Scope for >> this as it gets deployed. > Almost certainly, which I think is not a good fit. But I don't fully grasp > the requirements involved here. I know that Scope is not a direct fit for > doing domain-based discovery though. agreed > > The problem is that it will *usually* be a fit, which for too many people > means "good enough". I predict it will be a match about as often as Scope matches the email domain which is increasingly the case. There are several technology trends that tend to push orgs to less complex domain structure and this will make it more likely that Scope == Realm == maildomain over time. > -- Scott > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From d.w.chadwick@kent.ac.uk Thu Nov 7 21:24:23 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8C721E81BD for ; Thu, 7 Nov 2013 21:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLG-1b8FQDcH for ; Thu, 7 Nov 2013 21:24:19 -0800 (PST) Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05E21E80DE for ; Thu, 7 Nov 2013 21:24:05 -0800 (PST) Received: from [223.197.71.5] (helo=[172.16.11.20]) by mx3.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VeeY5-0003oI-Gz; Fri, 08 Nov 2013 05:24:01 +0000 Message-ID: <527C757D.5020000@kent.ac.uk> Date: Fri, 08 Nov 2013 05:24:13 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Cantor, Scott" , Sam Hartman , "abfab@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 05:24:24 -0000 On 07/11/2013 17:22, Cantor, Scott wrote: > On 11/7/13, 11:27 AM, "Sam Hartman" wrote: >> >> How exactly would one include a realm identifier in metadata? That is, >> is there well defined way to name a realm in SAML? > > No, not really. Historically we took some plains to not tie SAML entities > to DNS domains because in a lot of cases what we were really doing was > deciding whether to go along with the rest of the planet and conflate > email address with identity. > > There are a bunch of things surrounding this notion that overlap with IdP > discovery (which can be realm based, like in edugain, but is that really > not just email address? And if not, do users understand the difference?) > and with how you do filtering of attributes. The attributes issue, of how the SP's required set is indicated to the IDP(s) and to the user, and user consent and choice (if alternatives exist) is a much bigger issue than the naming of realms. In fact I would say they are orthogonal. It would be nice to address both in ABFAB David > > At the end of the day, Shibboleth is the only implementation that really > ever leveraged anything like a "Realm" and we called it "Scope" and > defined a metadata extension for it that allows an IdP to have a many to > one relationship with a set of Scopes. Which in practice are domains, > though not by definition. > > -- Scott > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Fri Nov 8 13:04:17 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145CB21E8139 for ; Fri, 8 Nov 2013 13:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2guCCv-OB2V for ; Fri, 8 Nov 2013 13:04:11 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3895321E8082 for ; Fri, 8 Nov 2013 13:04:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C68CD2052F; Fri, 8 Nov 2013 16:01:34 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqeyxL7S_yLo; Fri, 8 Nov 2013 16:01:34 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [64.88.227.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 8 Nov 2013 16:01:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9F0028352D; Fri, 8 Nov 2013 16:03:40 -0500 (EST) From: Sam Hartman To: David Chadwick References: <527C757D.5020000@kent.ac.uk> Date: Fri, 08 Nov 2013 16:03:40 -0500 In-Reply-To: <527C757D.5020000@kent.ac.uk> (David Chadwick's message of "Fri, 08 Nov 2013 05:24:13 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:04:17 -0000 >>>>> "David" == David Chadwick writes: David> The attributes issue, of how the SP's required set is David> indicated to the IDP(s) and to the user, and user consent and David> choice (if alternatives exist) is a much bigger issue than David> the naming of realms. In fact I would say they are David> orthogonal. It would be nice to address both in ABFAB Naming of realms is important because if you don't handle it correctly significant security attacks exist where one RP can get attributes intended for another or one users attributes can be substituted for another. From leifj@mnt.se Sun Nov 10 13:05:39 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6426221E8151 for ; Sun, 10 Nov 2013 13:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cge4szpg+H5L for ; Sun, 10 Nov 2013 13:05:32 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E521E814D for ; Sun, 10 Nov 2013 13:05:32 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rp16so4316021pbb.3 for ; Sun, 10 Nov 2013 13:05:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=a3a1xCyPLqMFk8C7m3X8BuhUz/xbTIMO85c27fnh51U=; b=mcLiUJuiooeq4Nbj03uTRMfUnRl/uwKrT7DbkwNDAcYE3dN5qwN9Y9l0OF/IBeBpJx TmtBrepY+Ps0gzVk1YiBedQczPO3IA6DGjZAcwiVN/ZaKtPnjCjBMZkGzrvNbBP9hPHC vflT+7/Y7j4yNweXQVcfD7xJCSpmfuCUmRI6/TwHU3pKk0xPGwuODjpV+kgCnFI0oQtZ cTJpVe07uC6YeWqWg5pfrd5m7aMkvZzEopv4zqSFuxtEEgw0Yp6oTdvpkEwWT1/FC2No DKrx+vCfZH+6nYpNWWkhGRoI1VQWAzOG4DaCPg8NOrAI/48bJTyhRSWi5isWUO7HaU0x wyYw== X-Gm-Message-State: ALoCoQkMFkiQ5ZGnwa5kRQNMl5rpD7QyufiEIHyLUf6WRHB37hxnBlkdbLapRTPws2DGxUKdhQ7H X-Received: by 10.66.102.9 with SMTP id fk9mr27832131pab.41.1384117532018; Sun, 10 Nov 2013 13:05:32 -0800 (PST) Received: from [10.199.5.227] (209-82-80-116.dedicated.allstream.net. [209.82.80.116]) by mx.google.com with ESMTPSA id ka3sm26180739pbc.32.2013.11.10.13.05.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 13:05:31 -0800 (PST) Message-ID: <527FF519.4030104@mnt.se> Date: Sun, 10 Nov 2013 22:05:29 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] WGLC of draft-ietf-abfab-arch-08 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 21:05:39 -0000 This starts a 2 week Working Group Last Call on draft-ietf-abfab-arch-08. The WGLC ends on Monday 25:th of November 2013. Get your comments on the draft in by then. Leif & Klaas From d.w.chadwick@kent.ac.uk Sun Nov 10 13:47:16 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC8121F9FD5 for ; Sun, 10 Nov 2013 13:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxMQzPcRzQ82 for ; Sun, 10 Nov 2013 13:47:08 -0800 (PST) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 89D4521E815D for ; Sun, 10 Nov 2013 13:47:04 -0800 (PST) Received: from [87.113.53.139] (helo=[192.168.1.65]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VfcqS-0006H6-FG; Sun, 10 Nov 2013 21:47:00 +0000 Message-ID: <527FFEE5.6090409@kent.ac.uk> Date: Sun, 10 Nov 2013 21:47:17 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Sam Hartman References: <527C757D.5020000@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 21:47:16 -0000 Sam there are at least two issues here 1. Ensuring that a claimed name really belongs to the claimant 2. Not having similar names that can confuse users which are you most concerned with? David On 08/11/2013 21:03, Sam Hartman wrote: >>>>>> "David" == David Chadwick writes: > > > David> The attributes issue, of how the SP's required set is > David> indicated to the IDP(s) and to the user, and user consent and > David> choice (if alternatives exist) is a much bigger issue than > David> the naming of realms. In fact I would say they are > David> orthogonal. It would be nice to address both in ABFAB > > Naming of realms is important because if you don't handle it correctly > significant security attacks exist where one RP can get attributes > intended for another or one users attributes can be substituted for > another. > From leifj@mnt.se Sun Nov 10 13:52:19 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787FD21E80B1 for ; Sun, 10 Nov 2013 13:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] 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 3nk43zQoOsBI for ; Sun, 10 Nov 2013 13:52:13 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92621F9DAD for ; Sun, 10 Nov 2013 13:52:13 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so4359107pdj.19 for ; Sun, 10 Nov 2013 13:52:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8XtQQpaE/CfFGx2P9euWJf2Rj75tb9zJl51dp4D3yhw=; b=eBMVTr80NevN/saK/N7KNfYms0a3amL2FHT5k48cavaihA2qJDJ9If1wlKZxD6WTBf +yysgdGtpb2HPZ4mchA8odwyTRQPTqZV4uJ20KrClBQt77qHEPE6s1D3azEFye4E+Cqz oKaXbpJe7la/UTjUPgUoWRQ8fdp7ePToO3L6c8SDLNz+Gtbxk1HoWHK+V7jAlCavjWC9 Lf/zO1Rql1iYB/aPqrvEdUtffZTsPxxiWZthEojgFES/D01DdIrwGCovewhp1RW66m+D xIWqFBhBQIQ/gC6sCKGEecTJHRSAwRGBIrNfdIAsD2vv278ijeWw3t7TsB4NN+UPkOT+ JaYQ== X-Gm-Message-State: ALoCoQntdx/0aaa6QXAjF0NrrIO7cbHwj1tr2kwY1U/XMtoGsS9fGor8hkh+35h8JAPaIFaobnhu X-Received: by 10.68.133.230 with SMTP id pf6mr20470809pbb.64.1384120332907; Sun, 10 Nov 2013 13:52:12 -0800 (PST) Received: from [10.199.5.227] (209-82-80-116.dedicated.allstream.net. [209.82.80.116]) by mx.google.com with ESMTPSA id so2sm26336347pbc.5.2013.11.10.13.52.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 13:52:12 -0800 (PST) Message-ID: <52800008.1010204@mnt.se> Date: Sun, 10 Nov 2013 22:52:08 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> In-Reply-To: <527FFEE5.6090409@kent.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 21:52:19 -0000 On 11/10/2013 10:47 PM, David Chadwick wrote: > Sam > > there are at least two issues here > > 1. Ensuring that a claimed name really belongs to the claimant > 2. Not having similar names that can confuse users > We're talking about names for entities so 1. From d.w.chadwick@kent.ac.uk Sun Nov 10 13:55:45 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF021E815D for ; Sun, 10 Nov 2013 13:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v728v9lgklKb for ; Sun, 10 Nov 2013 13:55:40 -0800 (PST) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD0E21E80B1 for ; Sun, 10 Nov 2013 13:55:40 -0800 (PST) Received: from [87.113.53.139] (helo=[192.168.1.65]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vfcyo-0006nE-K1; Sun, 10 Nov 2013 21:55:38 +0000 Message-ID: <528000EB.8040009@kent.ac.uk> Date: Sun, 10 Nov 2013 21:55:55 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Leif Johansson , abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> In-Reply-To: <52800008.1010204@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 21:55:45 -0000 In a PKI this is the responsibility of the CA. In the case of ABFAB, its the responsibility of the trust router. On 10/11/2013 21:52, Leif Johansson wrote: > On 11/10/2013 10:47 PM, David Chadwick wrote: >> Sam >> >> there are at least two issues here >> >> 1. Ensuring that a claimed name really belongs to the claimant >> 2. Not having similar names that can confuse users >> > We're talking about names for entities so 1. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From leifj@mnt.se Sun Nov 10 14:17:49 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8A521E80E9 for ; Sun, 10 Nov 2013 14:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 s4jUxAFaECRU for ; Sun, 10 Nov 2013 14:17:43 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3FF21E80B6 for ; Sun, 10 Nov 2013 14:17:42 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz1so1035725pad.17 for ; Sun, 10 Nov 2013 14:17:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9t6WvuaZCxz2v2t3hXx/0pLZ9TzR9GLSGJD2qV2hBL4=; b=lQSVKjl4d1SJkPWixtI+F85WBBvvqgglgE8m84gW11VM7C0es2UebvQzQ53rTkE+FN R4mvMnaicDCupXaZ3a8quG45MlfYNy/T2aMytu2gskEgIHyZd9VaQ55BhlbkE7M8S4Lg Vp4ZRhtPidizPXtms2OMilLYq9sNpPhzHD1wFxu88vm2twEucom7UoARgjqHteXavcen CT8Jhd5BWPtt/Dkc4G55n2PSSxDI1UlnkHFkpW15lI3QGE/5mwIXu2rbqUW/ft3gydxB XBLpw45KFLG9gqy/a0T9yCzgePfypu8NNzSUaPYcCMPDL3wFzTmBd++Av3aKSv3ZTJ95 PYxw== X-Gm-Message-State: ALoCoQlUQYQjFVnqOzhclhqJ7SdB4OdqclWXjaWQDwtMxUUGXr4hVHA4wQ9c2bGHCA2N6OdrvgtV X-Received: by 10.68.130.234 with SMTP id oh10mr27339222pbb.0.1384121853225; Sun, 10 Nov 2013 14:17:33 -0800 (PST) Received: from [10.199.5.227] (209-82-80-116.dedicated.allstream.net. [209.82.80.116]) by mx.google.com with ESMTPSA id xv2sm26365542pbb.39.2013.11.10.14.17.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 14:17:32 -0800 (PST) Message-ID: <528005FB.6070106@mnt.se> Date: Sun, 10 Nov 2013 23:17:31 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: David Chadwick , abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> <528000EB.8040009@kent.ac.uk> In-Reply-To: <528000EB.8040009@kent.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 22:17:49 -0000 On 11/10/2013 10:55 PM, David Chadwick wrote: > In a PKI this is the responsibility of the CA. In the case of ABFAB, > its the responsibility of the trust router. The latter statement doesn't make sense. There is no trust router when you use SAML metadata to manage trust in abfab which is what this discussion is about. From d.w.chadwick@kent.ac.uk Sun Nov 10 23:20:57 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0521E811A for ; Sun, 10 Nov 2013 23:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOHy-NNGXTrw for ; Sun, 10 Nov 2013 23:20:51 -0800 (PST) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30C21E80E7 for ; Sun, 10 Nov 2013 23:20:47 -0800 (PST) Received: from [87.113.53.139] (helo=[192.168.1.65]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vflnh-0006X4-Im; Mon, 11 Nov 2013 07:20:45 +0000 Message-ID: <5280855F.8050405@kent.ac.uk> Date: Mon, 11 Nov 2013 07:21:03 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Leif Johansson , abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> <528000EB.8040009@kent.ac.uk> <528005FB.6070106@mnt.se> In-Reply-To: <528005FB.6070106@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 07:20:57 -0000 Here is the rationale for my answer 1. the user types in the name of the remote realm to the RP 2. the RP trusts the trust router to set up the DH keys with some remote entity that purports to answer for this realm 3. This remote entity authenticates the user and sends the answer to the RP along with unsigned SAML assertions about the same user in a Radius response 4. Since the SAML assertions are unsigned the RP has no PKI to rely on. It only has the trust router. Consequently it is the responsibility of the trust router (admin) to check that this remote entity: a) is the correct one to answer requests for this realm b) does authenticate it users correctly c) does issue correct SAML assertions for its users, regardless of the IDP name that accompanies the assertion This implies that the trust router (admin) should publish the IDP name that is used by the realm when issuing its SAML assertions i.e. the trust router publishes realm name to IDP name mappings. An RP can then use this information to compare the names in SAML metadate. regards David On 10/11/2013 22:17, Leif Johansson wrote: > On 11/10/2013 10:55 PM, David Chadwick wrote: >> In a PKI this is the responsibility of the CA. In the case of ABFAB, >> its the responsibility of the trust router. > The latter statement doesn't make sense. There is no trust router when > you use SAML metadata to manage trust in abfab which is what this > discussion is about. > From gabilm@um.es Mon Nov 11 04:25:24 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDC421E81DA for ; Mon, 11 Nov 2013 04:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl9IG+-yu+M2 for ; Mon, 11 Nov 2013 04:25:19 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85621E80EC for ; Mon, 11 Nov 2013 04:25:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id DE4495D51E; Mon, 11 Nov 2013 13:25:16 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vi4zGoQcqWNE; Mon, 11 Nov 2013 13:25:16 +0100 (CET) Received: from vpn_bib-192-209.inf.um.es (vpn_bib-192-209.inf.um.es [155.54.192.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id 68A315D4DC; Mon, 11 Nov 2013 13:25:14 +0100 (CET) Message-ID: <5280CCD1.1010603@um.es> Date: Mon, 11 Nov 2013 13:25:53 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Sam Hartman , abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=8D119153 Content-Type: multipart/mixed; boundary="------------030506040602020703050209" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:25:24 -0000 This is a multi-part message in MIME format. --------------030506040602020703050209 Content-Type: multipart/alternative; boundary="------------000207050500070809080609" --------------000207050500070809080609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, some comments El 07/11/13 17:27, Sam Hartman escribió: > > > > Section 5.3.1 > > Isn't the AAA server a SAML consumer of an authentication request? section 1.4.5 in draft-ietf-abfab-arch-08 says that: "The RP sends ...., and it may send a SAML Attribute Request in a AAA attribute. The AAA network checks that the identity claimed by the RP is valid." I guess the draft (arch-08) should say SAML AuthNRequest and, optionally, AttributeRequest, if what the RP is waiting for is an authentication statement, and optionally, attribute statements. In general, the exchange of SAML messages between RP and IdP is not clear in the drafts. > > > > Section 7.3.3: > Wait. You're saying that my RADIUS server MUST look inside the SAML > message and if a certain attribute is present go change my EAP state > machine? > > I don't think anyone will ever implement that. > Also, how does it interact with semi-long-term elements like Kerberos > TGTs or TEAP tickets? What your concern is about? RADIUS server looking inside SAML sentences? or changing EAP state machine? The first one is necessary if the RADIUS server has to take into account things such as LoA specified by the RP Although I suppose an independent RADIUS module is in charge of the SAML stuff. Regards, Gabi. > > > Section 7.3.4: > > Is the simple system model inside or outside the scope of this profile? > This also (and more importantly) applies to the requirements for the > response. > > Ah, I see that this is handled later. > > There are still a lot of todos. > > > _______________________________________________ > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSgMzQAAoJEMUYqoSNEZFTgDAIAOACZs776GdTvEv5Ro0ypPH9 ukZJJ9y5qGGNCXH3YR7GbULhdH6MUPvh8a3xLDBB+/0JVa810RN5r1564rMENv7i j/1Rc60h4CrYyb65PrkcZ9DV3ISgYsqcLGBw5KICW02Gjv9SYXlweCAslcudlaRd dtzROBx9+s+BhP1zr+nySIyo1eRVFIYVo/POgQI11oGHNIlWGzXFSmY7F29PCC1N Glx3OxblsUON4pcTGhrNkeuxAcYLGVimW75py/w1GQSABJ0YV3Zjx8AlJdAOtABp m4mdcr/XIMdwomaJ1KpbnCkDCK8LjqA8vm16ujS2c3dv3Ntc2mKXMqpOkqdLIzc= =6XAk -----END PGP SIGNATURE----- --------------000207050500070809080609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


    Hi,
 
    some comments

El 07/11/13 17:27, Sam Hartman escribió:
>
>
>
> Section 5.3.1
>
> Isn't the AAA server a SAML consumer of an authentication request?

section 1.4.5 in draft-ietf-abfab-arch-08 says that:
"The RP sends ...., and it may send a SAML Attribute Request in a AAA attribute.  The AAA network checks that the identity claimed by the RP is valid."

I guess the draft (arch-08) should say SAML AuthNRequest and, optionally, AttributeRequest, if what the RP is waiting for is an authentication statement, and optionally, attribute statements.
In general, the exchange of SAML messages between RP and IdP is not clear in the drafts.
>
>
>
> Section 7.3.3:
> Wait.  You're saying that my RADIUS server MUST look inside the SAML
> message and if a certain attribute is present go change my EAP state
> machine?
>
> I don't think anyone will ever implement that.
> Also, how does it interact with semi-long-term elements like Kerberos
> TGTs or TEAP tickets?

What your concern is about? RADIUS server looking inside SAML sentences? or changing EAP state machine?
The first one is necessary if the RADIUS server has to take into account things such as LoA specified by the RP
Although I suppose an independent RADIUS module is in charge of the SAML stuff.

Regards, Gabi.
>
>
> Section 7.3.4:
>
> Is the simple system model inside or outside the scope of this profile?
> This also (and more importantly) applies to the requirements for the
> response.
>
> Ah, I see that this is handled later.
>
> There are still a lot of todos.
>
>
> _______________________________________________
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSgMzQAAoJEMUYqoSNEZFTgDAIAOACZs776GdTvEv5Ro0ypPH9
ukZJJ9y5qGGNCXH3YR7GbULhdH6MUPvh8a3xLDBB+/0JVa810RN5r1564rMENv7i
j/1Rc60h4CrYyb65PrkcZ9DV3ISgYsqcLGBw5KICW02Gjv9SYXlweCAslcudlaRd
dtzROBx9+s+BhP1zr+nySIyo1eRVFIYVo/POgQI11oGHNIlWGzXFSmY7F29PCC1N
Glx3OxblsUON4pcTGhrNkeuxAcYLGVimW75py/w1GQSABJ0YV3Zjx8AlJdAOtABp
m4mdcr/XIMdwomaJ1KpbnCkDCK8LjqA8vm16ujS2c3dv3Ntc2mKXMqpOkqdLIzc=
=6XAk
-----END PGP SIGNATURE-----

--------------000207050500070809080609-- --------------030506040602020703050209 Content-Type: application/pgp-keys; name="0x8D119153.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0x8D119153.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org mQENBE2eyEgBCADqNVu4SRFBENGp+qgXlziaoIQsCfZGQvh7MyWY1cZRI6PTUUGC 7FSYbFkOhQCGZ+/ARAc8zNoIVuywWBN/rtB1pHVXwqd1xDIDfoTIkE6nXc54hCvo umv4oI4XsqHpLzlmJYJCfcB17RV6HmcgxZY3d+z+Oy7cegt5NHW0a2f2JeTcmfsG B0yqI/oThsvwJ3+8Ys54q4JD8BNulHDYA18rPAqBSm3T0S+E01GF55pGLriEUrbA gKNxmPzIyYkgMUKqtSAALn/TXBkQECIiB+yr1pz7nnM9R457KYO8rmQl45rAw71+ SXvHIf1PCM0TNtBEw7ZR9cZzYrJl6PB3w0uPABEBAAG0I0p1YW4gc2luIG1pZWRv IDxqdWFuc2lubWllZG9AdW0uZXM+iQE+BBMBAgAoBQJQtLmZAhsvBQkSz/eABgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDFGKqEjRGRU1cIB/9x8aaGHHrPAebJ rWDJq6ojFayTN5DgDMkhUJUqmgSx1aNrHHk48YMJI/6CNZGnxMPXpuOxfU48H6Ks whCzo5l0Wp+c1L0gdnPmr3Sn5KZbOV6v4yUi64fIYXMnyHeIHCroGaRlsgY4H3C9 vncxMS+VbWPSC07D79ewiUlnzHux+b/cgww0TiKL+KhhRmTZcUcAqYvjKn/j9ZDZ nsu4q8k58q+WaZc4i3sgKPMDVEGCH6/9ZS2bdHqG0gTeetGGCcZo+lMwPuwW1JoL S/kc24WWGOM8C8I1hCZ1MI3+2YblIS3aD0SKf+YlJoZienMhSYQrS1mf5IQHT9f+ PnwpNF5ZtChHYWJyaWVsIExvcGV6IChDbGF2ZSBQR1ApIDxnYWJpbG1AdW0uZXM+ iQFBBBMBAgArAhsvBQkSz/eABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCULS5 nQIZAQAKCRDFGKqEjRGRU6UzB/47vsn2E6wlpOnyzCJRIfCm+o8jEInaWuNPUSfH oRdG/bdJnUnv4UaKCQLKDWxb16jtp4D88HdYxRYLUDvK5+wpi4KYy4wqPE7j8jy9 a/wtvr9ujUbIDe4iftyl7MSTowU60zonRfV0HNMZLNILTaX46Qdm3JAvOwlcbM4D g5nJTTLEatFLRn4lKzXgvs+cKLGF8ALJE0tx+X4pl15TvGpFDPmCA9mw1GWY6laD cdgdlUgpzE9yWPfrRjqoBcfuW+sqKzPT2nAj6YPUzOrB+N682Zxt4sW3VYaySFoq fcXyJAHq9PTAn/osX6dIHyfRYlAg//4+OMuAp4sCy7xRJqXzuQENBE2mqCUBCADS Lo5gXbBkS/drtAf3nEVOaVy56cmruPfli/eZhEZT5vKNdW+5t1rUUa8wCTTiqv0y iLHwknU0ZeQhkK65ixQb6NjqEnC1COfE5NBTA+hqanoUBST/dItWPB2fnhg16Emv 1jSWxe19K7jgyGx2Cj56l0b/Te3uxRhyXnqmlF9X2Wz+ntbvDPz7OtSaDiMb1haw dXLGxWE0AdPmZEvFHAXwEUQfIzW+i7OTdPJCo5eiIC+OsZTbBNs2pzsl6s5/2y+1 /gnxtxF5Ep6BVk74tKJABfQ8ntrzGY87uRrdoZ/BtYGet8jFZQUEesUj4rNojXj0 Icbpl33oYB3VJbij1jxxABEBAAGJASUEGAECAA8FAk2mqCUCGwwFCRLP94AACgkQ xRiqhI0RkVOagAgA53T0JwSatOY2i2CqGPJGZzs85oHjBTFrEDJ+Axc1JhsEZ8YP ebjMOPHp5On/BgeoByTfPnA3DU9J9z4twq3nXpJeGLcB2+rGPCM5HPAd3ahbwj/S 3xJ6T1EURCdINoHaJbKg8Hu018S5VkSO76R8n8dFLPMY0Ed5MJq1SdySJSQyjtoO Je5BCgTcHZbpBDNXGIqIs+r8UbkLCcB4iiAS2l3AuaMHih0wPk5R/jDNrQzfCKr8 phdNPXM/9rr8mdmMlQBh8+AnlGcZyXbaLmk+aNRx8E2olRVa0ilnn0JZXsbWsafj wRr/7UOb6C6LHK5ctTHLMOUtgvBs+YvHTM36yw== =grvC -----END PGP PUBLIC KEY BLOCK----- --------------030506040602020703050209-- From leifj@sunet.se Mon Nov 11 08:58:14 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE2521E81DD for ; Mon, 11 Nov 2013 08:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 yqYQ71kHJSto for ; Mon, 11 Nov 2013 08:58:08 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 525B211E80E4 for ; Mon, 11 Nov 2013 08:58:07 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id rABGw3Xs019564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Nov 2013 17:58:03 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id rABEERg2001313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Nov 2013 15:14:30 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [172.20.9.190] ([12.177.140.253]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Mon, 11 Nov 2013 17:57:59 +0100 Message-ID: <52810C94.6010205@sunet.se> Date: Mon, 11 Nov 2013 17:57:56 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> <528000EB.8040009@kent.ac.uk> <528005FB.6070106@mnt.se> <5280855F.8050405@kent.ac.uk> In-Reply-To: <5280855F.8050405@kent.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KMgW39p - 8d13cfac1122 - 20131111 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 16:58:14 -0000 On 11/11/2013 08:21 AM, David Chadwick wrote: > Here is the rationale for my answer > > 1. the user types in the name of the remote realm to the RP > 2. the RP trusts the trust router to set up the DH keys with some > remote entity that purports to answer for this realm We are not talking about trust router on this mailinglist at this time. We're talking about using SAML metadata for abfab. Do you have comments about name-to-key binding in that context? From d.w.chadwick@kent.ac.uk Mon Nov 11 09:35:23 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384521E80C0 for ; Mon, 11 Nov 2013 09:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG9J5I2D7lIO for ; Mon, 11 Nov 2013 09:35:07 -0800 (PST) Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by ietfa.amsl.com (Postfix) with ESMTP id AA66521E80CD for ; Mon, 11 Nov 2013 09:34:54 -0800 (PST) Received: from edue6ab.kent.ac.uk ([129.12.230.171]) by mx3.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VfvO1-0007Ov-ID; Mon, 11 Nov 2013 17:34:53 +0000 Message-ID: <52811552.2090605@kent.ac.uk> Date: Mon, 11 Nov 2013 17:35:14 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Leif Johansson , abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> <528000EB.8040009@kent.ac.uk> <528005FB.6070106@mnt.se> <5280855F.8050405@kent.ac.uk> <52810C94.6010205@sunet.se> In-Reply-To: <52810C94.6010205@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:35:23 -0000 I dont understand what your trust model is, if you dont have a PKI or a trust router, then how can an RP trust any SAML metadata that it has obtained from anywhere? It has to get this from a trustworthy source. I thought that the trustrouter (admin) was this TTP. If not, then who is? The federation authority was to my mind the trust router administrator, and was responsible for mapping the IDP name to realm name. The name of a SAML IDP is irrelevant if you dont have a trustworthy source for this information. Similarly an unsigned key is also worthless from a trust perspective unless you get it face to face from the owner. regards david On 11/11/2013 16:57, Leif Johansson wrote: > On 11/11/2013 08:21 AM, David Chadwick wrote: >> Here is the rationale for my answer >> >> 1. the user types in the name of the remote realm to the RP >> 2. the RP trusts the trust router to set up the DH keys with some >> remote entity that purports to answer for this realm > We are not talking about trust router on this mailinglist at this time. > > We're talking about using SAML metadata for abfab. > > Do you have comments about name-to-key binding in that context? > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From leifj@mnt.se Mon Nov 11 09:40:30 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC0C11E81ED for ; Mon, 11 Nov 2013 09:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH-hZ6JLdcaQ for ; Mon, 11 Nov 2013 09:40:24 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id D779211E81A7 for ; Mon, 11 Nov 2013 09:40:18 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so5673843pab.12 for ; Mon, 11 Nov 2013 09:40:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gvzxTy+vo5MXLrrjRkKXzs/50Z6KJ9dg0/qbcIt0oeM=; b=epFyswNSE5s5OB2J7O9pzYdxxjXScGlcX/SFSigtCn3j2UUYPLMl7pWvujlVmDiA9l /Dail/kTjYxj2BMu4VegQydUEhDc3wp0ECMuQITZMLpaIeQWsjvOLnTJ9HxeaRNfq92B 8dBw86BXbYabOppvNmGYINt1J3VMvsUU7O8Ikt3esqGXjooUrcGjOIKtQobV5VZaelfC 25COu2bRsIdzpDBn7Lv+KTVm9aO7csIXydUgjkduMmPXrVmtFly2VGIm3X/aSRb7Pe18 8eK5IPr0cQr6JdE+JRBpnW0oaLNXe1vowKUx6p2XyJsZBtBrH68WvKgQxpExCS2rovLB 2K0A== X-Gm-Message-State: ALoCoQkBwcLe6svYa1m7zyP5WOcZ7Bya1IwaOLOYHAP8S3DSXZAhZI/sf+2u8+kNQVKIsfAuA7ey X-Received: by 10.68.6.66 with SMTP id y2mr31254783pby.60.1384191618692; Mon, 11 Nov 2013 09:40:18 -0800 (PST) Received: from [172.20.9.190] ([12.177.140.253]) by mx.google.com with ESMTPSA id lm2sm37524848pab.2.2013.11.11.09.40.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 09:40:17 -0800 (PST) Message-ID: <52811680.9000604@mnt.se> Date: Mon, 11 Nov 2013 18:40:16 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> <528000EB.8040009@kent.ac.uk> <528005FB.6070106@mnt.se> <5280855F.8050405@kent.ac.uk> <52810C94.6010205@sunet.se> <52811552.2090605@kent.ac.uk> In-Reply-To: <52811552.2090605@kent.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:40:30 -0000 On 11/11/2013 06:35 PM, David Chadwick wrote: > I dont understand what your trust model is, if you dont have a PKI or > a trust router, then how can an RP trust any SAML metadata that it has > obtained from anywhere? It has to get this from a trustworthy source. > I thought that the trustrouter (admin) was this TTP. If not, then who > is? The federation authority was to my mind the trust router > administrator, and was responsible for mapping the IDP name to realm > name. Typically trust in SAML metadata done using signatures or some other form of authentication of the metadata. From cantor.2@osu.edu Mon Nov 11 09:49:17 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C321E8230 for ; Mon, 11 Nov 2013 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv1Rd0IvgAL7 for ; Mon, 11 Nov 2013 09:49:11 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 633F321E8246 for ; Mon, 11 Nov 2013 09:48:41 -0800 (PST) Received: from mail102-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Mon, 11 Nov 2013 17:48:40 +0000 Received: from mail102-tx2 (localhost [127.0.0.1]) by mail102-tx2-R.bigfish.com (Postfix) with ESMTP id 7F19AA03A1 for ; Mon, 11 Nov 2013 17:48:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.218; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf04; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: VPS7(zzzz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail102-tx2: domain of osu.edu designates 164.107.81.218 as permitted sender) client-ip=164.107.81.218; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf04 ; cio-tnc-pf04 ; Received: from mail102-tx2 (localhost.localdomain [127.0.0.1]) by mail102-tx2 (MessageSwitch) id 138419211183010_28009; Mon, 11 Nov 2013 17:48:31 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.226]) by mail102-tx2.bigfish.com (Postfix) with ESMTP id 0A46B80331 for ; Mon, 11 Nov 2013 17:48:31 +0000 (UTC) Received: from cio-tnc-pf04 (164.107.81.218) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 11 Nov 2013 17:48:29 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf04 (Postfix) with ESMTP id 4D61E38004D for ; Mon, 11 Nov 2013 12:48:29 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 12:48:29 -0500 From: "Cantor, Scott" To: "abfab@ietf.org" Thread-Topic: SAML/AAA realm mapping Thread-Index: AQHO3wY614kwBIKWPEmY79rQETSfhQ== Date: Mon, 11 Nov 2013 17:48:29 +0000 Message-ID: In-Reply-To: <20131107203518.21885.43902.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.177.140.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <4FBA924EC2655A41A7B6DC2A78E3AEA9@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [abfab] SAML/AAA realm mapping X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:49:18 -0000 I reviewed the section 5 text that talks about the naming issue, so here's my opinion based on that reading. TL;DR, don't waste time overloading something already there, just define what you need. While I think there might be some tactical ways to do this on the SP side along the lines of what I said in the Jabber room last Thursday, I think ultimately you have a parallel problem on both ends that probably just needs to be solved consistently. In both cases, you have an entityID you're trying to evaluate in the context of a realm, so I think you just need to define a metadata extension to do that. As we've discussed, yes this looks like Scope, and in many cases it will be the same value, but that doesn't mean it's the same thing. That also doesn't address the SP end. There are two obvious choices here: - an explicit extension element - an entity attribute I'm completely ambivalent about which you use. Specifying an entity attribute is less work, but the XML is slightly more verbose in the end. An advantage that is unlikely to be all that important but YMMV is that defining a SAML Attribute for this allows the concept of the realm to be expressed in other contexts in SAML, and using the EntityAttributes extension means you can (but I doubt you would) actually embed a third party attestation to the realm information in the form of an actual SAML Assertion inside the metadata. On the subject of whether you should/need to do this now, I think there are other use cases for getting what amounts to a AAA "realm" mapped in metadata. We should just do it. -- Scott From leifj@mnt.se Mon Nov 11 09:52:32 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996F311E81B2 for ; Mon, 11 Nov 2013 09:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] 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 gNz+IFL6le9W for ; Mon, 11 Nov 2013 09:52:28 -0800 (PST) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1F511E81C0 for ; Mon, 11 Nov 2013 09:52:28 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id q10so2211149pdj.29 for ; Mon, 11 Nov 2013 09:52:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YWEVRe1ovrEHO7Qz8C7fExHHBLeLIp210UwvKgZcPu4=; b=E6l3hMcgUOR84H4MNeP8nPHKIN/d5kjErvnZ2iBW1C8PUChy2XHBDOJ6JkHNQSXT/A ltpa3wZu+bRRDDUzqRBgEibxT0EU2g/h3tJTjTkvndCzDf63MTtqMH6JH9XSQZ3lL6TN fg6nJLqoLWw1ONkUhoc9/w2czPfYa0dKHu0tSwp+Jwyb3GGCAVHQFQ9EhqlTMv80AESI qHjMJ34r+LkbznbXPUnb37QVv3ODkzUEb6u+0jxuOn3ZeuWj2lN0AWFB243LAcc97hZL hbDZvMu0nHzKFdqLLkPhW1ri6G8IcSV7Dmu77o5X5PSVsY78TmVwjpTcd9Gg88NR4FMJ 0HmA== X-Gm-Message-State: ALoCoQlJfia7ambWlx7x40xCT2dEIM4JvZQemXSA/SssU5NJsfgdeqXMLblwzQREfFo+/fBTMrA2 X-Received: by 10.68.191.3 with SMTP id gu3mr7548849pbc.142.1384192348014; Mon, 11 Nov 2013 09:52:28 -0800 (PST) Received: from [172.20.9.190] ([12.177.140.253]) by mx.google.com with ESMTPSA id er3sm32150283pbb.40.2013.11.11.09.52.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 09:52:27 -0800 (PST) Message-ID: <5281195A.6030201@mnt.se> Date: Mon, 11 Nov 2013 18:52:26 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] SAML/AAA realm mapping X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:52:32 -0000 On 11/11/2013 06:48 PM, Cantor, Scott wrote: > I reviewed the section 5 text that talks about the naming issue, so here's > my opinion based on that reading. > > TL;DR, don't waste time overloading something already there, just define > what you need. > > > While I think there might be some tactical ways to do this on the SP side > along the lines of what I said in the Jabber room last Thursday, I think > ultimately you have a parallel problem on both ends that probably just > needs to be solved consistently. > > In both cases, you have an entityID you're trying to evaluate in the > context of a realm, so I think you just need to define a metadata > extension to do that. > > As we've discussed, yes this looks like Scope, and in many cases it will > be the same value, but that doesn't mean it's the same thing. That also > doesn't address the SP end. > > There are two obvious choices here: > > - an explicit extension element > - an entity attribute > > I'm completely ambivalent about which you use. Specifying an entity > attribute is less work, but the XML is slightly more verbose in the end. > An advantage that is unlikely to be all that important but YMMV is that > defining a SAML Attribute for this allows the concept of the realm to be > expressed in other contexts in SAML, and using the EntityAttributes > extension means you can (but I doubt you would) actually embed a third > party attestation to the realm information in the form of an actual SAML > Assertion inside the metadata. > > On the subject of whether you should/need to do this now, I think there > are other use cases for getting what amounts to a AAA "realm" mapped in > metadata. We should just do it. As an individual I'm all for an entity attribute. That also gives us the impetus to finalize the entity category draft (http://macedir.org) > -- Scott > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Mon Nov 11 17:48:14 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D526121E809B for ; Mon, 11 Nov 2013 17:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.604 X-Spam-Level: X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=0.995, 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 L5pr4kBz801d for ; Mon, 11 Nov 2013 17:48:06 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 12ABF21E80D9 for ; Mon, 11 Nov 2013 17:48:06 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E35014A6B8A_28188D3B; Tue, 12 Nov 2013 01:48:03 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id F197A4A6B77_28188D2F; Tue, 12 Nov 2013 01:48:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 01:48:02 +0000 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCr5lEbMSIxEuoTzQjplPBzJohYNcA Date: Tue, 12 Nov 2013 01:48:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <76CC3476BB9B384C8A6FE893AB9502B9@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:48:14 -0000 > >Section 4: >The following text does not parse > The RADIUS SAML binding defined by this binding Section 5 uses two > attributes to convey SAML assertions and protocol messages > [OASIS.saml-core-2.0-os] respectively. > >I think it would be more clear if we move the reference after >respectively. >I don't think it's right to say that more and reserved are ignored. >More for example will be set often and reserved should be handled as in >RFC 6929. I meant ignored in the sense of not depicted within the table, but happy with your change as it is less ambiguous. >Section 5: >"A SAML Responder that refuses to perform a message exchange with the >SAML requester MUST silently discard the request" > >Please clarify we mean ignore the attribute, not drop the entire RADIUS >packet on the floor. Yes, this needs clarifying. >It may well be that we generate an access reject as a result, but silent >discard at the radius level is not really what we want. >Section 5.3.1 > >Isn't the AAA server a SAML consumer of an authentication request? >If so, it seems like it's more realistic for it to apply policy based on >the NAS identity rather than the NAI realm as described in the text. Your following correction cleans this up, I think. >I wonder whether requester and responder might be better than issuer and >consumer in this section. Yes, you're right. I think those bullets now read correctly. >old: >A digitally signed request alone is not sufficient. >new: >A digitally signed request alone is not sufficient. A AAA entity can >include a SAML message that it observes that is never intended by the >issuing SAML entity for this AAA session. The new clarifying text is good. >How exactly would one include a realm identifier in metadata? That is, >is there well defined way to name a realm in SAML? Nope. I'll respond in the other thread. >Section 7.3.1`: >Is this request in the initial access-accept? Every access-accept? On your first question, this is unspecified because I don't think we need to be prescriptive. On your second question, the profile is explicitly defined as a profile of the SAML authentication request protocol, and that would not permit that kind of message exchange. Happy to include clarifying text on both counts. >Section 7.3.3: >Wait. You're saying that my RADIUS server MUST look inside the SAML >message and if a certain attribute is present go change my EAP state >machine? Where are you reading that? The text says "establish the identity [...] using RADIUS authentication" >I don't think anyone will ever implement that. Agreed, but that's not the intent! >Also, how does it interact with semi-long-term elements like Kerberos >TGTs or TEAP tickets? Out of scope. That's a problem at the RADIUS authentication level. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From hartmans@painless-security.com Mon Nov 11 17:53:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA51121E8105 for ; Mon, 11 Nov 2013 17:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 dbMig2LtNIQh for ; Mon, 11 Nov 2013 17:53:20 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BC89011E8189 for ; Mon, 11 Nov 2013 17:53:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 954952052D; Mon, 11 Nov 2013 20:53:16 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiRTCj_MfklH; Mon, 11 Nov 2013 20:53:16 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 11 Nov 2013 20:53:16 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7D2F581942; Mon, 11 Nov 2013 20:53:16 -0500 (EST) From: Sam Hartman To: Josh Howlett References: Date: Mon, 11 Nov 2013 20:53:16 -0500 In-Reply-To: (Josh Howlett's message of "Tue, 12 Nov 2013 01:48:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:53:26 -0000 Josh, since minutes have not been sent out: 1) Everyone seems to think the force authentication text reads as I do and forces ignoring re-authentication state etc. I seem to be the only one who has a concern so I'm in the rough. Also, Alan and I believe that we should say to include the SAML request in the first message. (Discussed in the WG session). From Josh.Howlett@ja.net Mon Nov 11 18:13:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310E621E8136 for ; Mon, 11 Nov 2013 18:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.803 X-Spam-Level: X-Spam-Status: No, score=-101.803 tagged_above=-999 required=5 tests=[AWL=0.796, 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 SWyijRcVjiYs for ; Mon, 11 Nov 2013 18:13:20 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id D24E321E8105 for ; Mon, 11 Nov 2013 18:13:19 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 839031B4D3AE_2818EBEB; Tue, 12 Nov 2013 02:13:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 3DD901B4D3AA_2818EBEF; Tue, 12 Nov 2013 02:13:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 02:13:17 +0000 From: Josh Howlett To: "Cantor, Scott" , Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCr5lEbMSIxEuoTzQjplPBzJoaBDwAgAAOnBqAAALEgIAHUkgA Date: Tue, 12 Nov 2013 02:13:16 +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.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <0FD40461D3E20041AE2ECC4214674283@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:13:26 -0000 >> >>OK. >>So, we're telling people that they should confirm that the realm >>portion of the NAI is in the response or metadata for the IDP, but we >>have no way to express that name in either interoperably? >> >>That's possibly OK, but might need to be called out. > >Or define something, yes. There are reasons to think something's going to >be needed. Realm-based discovery seems likely to be the path forward in >other areas. Having reflected on this some more, I'm now a bit ambivalent about the whole discussion in 5.3.2. The text is assuming a particular SAML deployment model (policy & configuration in signed and trusted metadata) that will be true of some deployments but not others (e.g., a SAML proxy infrastructure). I am pretty sure that rewriting this text for the general case would yield text amounting to "use technical methods to validate that names claimed by other SAML entities are true, to whatever standard constitutes true for you". This is implicit in the text in 5.3.1 for validating AAA names (where the "technical method" is whatever AAA technology you have elected to use), and so I am tempted to apply a similar model for the SAML case. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From hartmans@painless-security.com Mon Nov 11 18:49:13 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8278511E819A for ; Mon, 11 Nov 2013 18:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 sKEExjGbPMzL for ; Mon, 11 Nov 2013 18:48:55 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1871211E8191 for ; Mon, 11 Nov 2013 18:48:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B5ACC2052D; Mon, 11 Nov 2013 21:48:50 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM_onRGXVIzL; Mon, 11 Nov 2013 21:48:50 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 11 Nov 2013 21:48:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3ACF581942; Mon, 11 Nov 2013 21:48:50 -0500 (EST) From: Sam Hartman To: Josh Howlett References: Date: Mon, 11 Nov 2013 21:48:50 -0500 In-Reply-To: (Josh Howlett's message of "Tue, 12 Nov 2013 02:13:16 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:49:13 -0000 >>>>> "Josh" == Josh Howlett writes: >>> >>> OK. So, we're telling people that they should confirm that the >>> realm portion of the NAI is in the response or metadata for the >>> IDP, but we have no way to express that name in either >>> interoperably? >>> >>> That's possibly OK, but might need to be called out. >> >> Or define something, yes. There are reasons to think something's >> going to be needed. Realm-based discovery seems likely to be the >> path forward in other areas. Josh> Having reflected on this some more, I'm now a bit ambivalent Josh> about the whole discussion in 5.3.2. The text is assuming a Josh> particular SAML deployment model (policy & configuration in Josh> signed and trusted metadata) that will be true of some Josh> deployments but not others (e.g., a SAML proxy Josh> infrastructure). Josh> I am pretty sure that rewriting this text for the general case Josh> would yield text amounting to "use technical methods to Josh> validate that names claimed by other SAML entities are true, Josh> to whatever standard constitutes true for you". Unfortunately, I think the above is a compelling argument why we need something reasonably specific. Because in your restatement you've lost the essential security issue. It's not enough that we claim that SAML entities names are true. That's actually not addressed by my reading of 5.3.2.The tricky issue is making sure that when SAML entities produce messages, they intend to allow the AAA entities discussed in 5.3.1 to use those messages. This is more of an issue of GSS-API channel binding than it is SAML naming. Ultimately the SAML naming is a convenience for associating policy with a SAML message. I don't think it does more than that except in so far as names are also attribute-like. Section 5.3.2 is attempting to discuss the importance of making sure the policy is appropriate for this channel as well as appropriate for the named SAML entities however that's handled. --Sam From Josh.Howlett@ja.net Mon Nov 11 19:16:10 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1023511E81B9 for ; Mon, 11 Nov 2013 19:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.936 X-Spam-Level: X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 OEWQ9r5S1W6f for ; Mon, 11 Nov 2013 19:15:50 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id B07C211E8191 for ; Mon, 11 Nov 2013 19:15:50 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id DA4381A9A2B3_2819D65B; Tue, 12 Nov 2013 03:15:49 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id AD6D01A9A2A7_2819D65F; Tue, 12 Nov 2013 03:15:49 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 03:15:48 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCr5lEbMSIxEuoTzQjplPBzJoaBDwAgAAOnBqAAALEgIAHUkgA//+D8nqAAI2MgA== Date: Tue, 12 Nov 2013 03:15:48 +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.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <1AD00B6291226B4580C7758CB69D0C9F@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:16:10 -0000 > >It's not enough that we claim that SAML entities names are true. >That's actually not addressed by my reading of 5.3.2.The tricky issue is >making sure that when SAML entities produce messages, they intend to >allow the AAA entities discussed in 5.3.1 to use those messages. >This is more of an issue of GSS-API channel binding than it is SAML >naming. Yes, you're right. The current text conflates the two issues of the issuer authorising the presenter, versus the consumer identifying the issuer. I think the right way to do this is at the binding level using the response's Recipient attribute, which needs to name the NAS. If Scott agrees (and if my brain does not implode in the interim) I'll propose some text. I think we'll probably also want to extend the NAI Name Identifier Format to accommodate naming the NAS, and use this name form within the recipient attribute. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From cantor.2@osu.edu Mon Nov 11 20:23:12 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341B211E8117 for ; Mon, 11 Nov 2013 20:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 gHbv6abaYwwW for ; Mon, 11 Nov 2013 20:23:00 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4521E80F1 for ; Mon, 11 Nov 2013 20:22:56 -0800 (PST) Received: from mail154-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.22; Tue, 12 Nov 2013 04:22:55 +0000 Received: from mail154-va3 (localhost [127.0.0.1]) by mail154-va3-R.bigfish.com (Postfix) with ESMTP id 7CF9C4E0411; Tue, 12 Nov 2013 04:22:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail154-va3: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3 (MessageSwitch) id 1384230171814455_11848; Tue, 12 Nov 2013 04:22:51 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.227]) by mail154-va3.bigfish.com (Postfix) with ESMTP id C13FF3E0084; Tue, 12 Nov 2013 04:22:51 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 12 Nov 2013 04:22:48 +0000 Received: from CIO-KRC-HT01.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf06 (Postfix) with ESMTP id 795793C005B; Mon, 11 Nov 2013 23:20:41 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 23:22:47 -0500 From: "Cantor, Scott" To: Josh Howlett , Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCoJiFJelWm0mGa+7cgKXk4JoaBDwAgAAOnBqAAALEgIAHUkgA//+D6POAAFtPAP//jJmA Date: Tue, 12 Nov 2013 04:22:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.177.140.253] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 04:23:12 -0000 On 11/11/13, 7:15 PM, "Josh Howlett" wrote: >> >>It's not enough that we claim that SAML entities names are true. >>That's actually not addressed by my reading of 5.3.2.The tricky issue is >>making sure that when SAML entities produce messages, they intend to >>allow the AAA entities discussed in 5.3.1 to use those messages. >>This is more of an issue of GSS-API channel binding than it is SAML >>naming. I haven't yet been able to relate the text there to my understanding (limited that it is) of channel binding. I'll just note that if the requirement is really to carry GSS-API CB data, there's already a slot for that in a SAML protocol extension I defined. But what's the CB data here? All I know of is TLS-based CB. >Yes, you're right. The current text conflates the two issues of the issuer >authorising the presenter, versus the consumer identifying the issuer. I >think the right way to do this is at the binding level using the >response's Recipient attribute, which needs to name the NAS. I thought the goal was to relate the AAA entity sending the message to the SAML entity issuing it, and that wouldn't be Recipient. If you're trying to target the message to a receiving identity that certainly could be Recipient, but if you're not signing, I don't see the relevance of populating that as a security measure. -- Scott From Josh.Howlett@ja.net Mon Nov 11 22:52:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C45F21E8097 for ; Mon, 11 Nov 2013 22:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.031 X-Spam-Level: X-Spam-Status: No, score=-102.031 tagged_above=-999 required=5 tests=[AWL=0.569, 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 l+Uu33HizdjH for ; Mon, 11 Nov 2013 22:52:17 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5421E80C2 for ; Mon, 11 Nov 2013 22:52:17 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7EF2F4A6B72_281D01EB; Tue, 12 Nov 2013 06:52:14 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 602274A6B7F_281D016F; Tue, 12 Nov 2013 06:52:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 06:52:05 +0000 From: Josh Howlett To: "Cantor, Scott" , Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCr5lEbMSIxEuoTzQjplPBzJoaBDwAgAAOnBqAAALEgIAHUkgA//+D8nqAAI2MgP//jJ+AgACvwwA= Date: Tue, 12 Nov 2013 06:52:04 +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.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 06:52:26 -0000 >> >>Yes, you're right. The current text conflates the two issues of the >>issuer >>authorising the presenter, versus the consumer identifying the issuer. I >>think the right way to do this is at the binding level using the >>response's Recipient attribute, which needs to name the NAS. > >I thought the goal was to relate the AAA entity sending the message to the >SAML entity issuing it, and that wouldn't be Recipient. Sigh, I got the Requester and Presenter the wrong way around. Is this then best tackled using subject confirmation? If so, would it be too much of a stretch to use Holder of Key where the KeyInfo contains a KeyName naming the AAA entity? Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From cantor.2@osu.edu Mon Nov 11 23:24:21 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0210721E80B5 for ; Mon, 11 Nov 2013 23:24:21 -0800 (PST) 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 oUBWOwkFlUpY for ; Mon, 11 Nov 2013 23:24:14 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9986921E808F for ; Mon, 11 Nov 2013 23:24:14 -0800 (PST) Received: from mail218-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 12 Nov 2013 07:24:13 +0000 Received: from mail218-ch1 (localhost [127.0.0.1]) by mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 6446A600F6; Tue, 12 Nov 2013 07:24:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail218-ch1: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1 (MessageSwitch) id 1384241051638153_3136; Tue, 12 Nov 2013 07:24:11 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail218-ch1.bigfish.com (Postfix) with ESMTP id 982F43E020B; Tue, 12 Nov 2013 07:24:11 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 12 Nov 2013 07:24:11 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf06 (Postfix) with ESMTP id 54CD03C005B; Tue, 12 Nov 2013 02:22:04 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 02:24:10 -0500 From: "Cantor, Scott" To: Josh Howlett , Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCoJiFJelWm0mGa+7cgKXk4JoaBDwAgAAOnBqAAALEgIAHUkgA//+D6POAAFtPAP//jJmAgACv1AD//4LZAA== Date: Tue, 12 Nov 2013 07:24:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.177.140.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <657011535654E748894B787A4207BB4F@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 07:24:21 -0000 On 11/11/13, 10:52 PM, "Josh Howlett" wrote: > >Sigh, I got the Requester and Presenter the wrong way around. Is this then >best tackled using subject confirmation? If so, would it be too much of a >stretch to use Holder of Key where the KeyInfo contains a KeyName naming >the AAA entity? That only works in one direction, and I think you need both here. If this is *really* channel binding, literally, then there's already an extension for that, but I don't think it's technically CB, just conceptually similar. You have two AAA peers exchanging messages and you want to bind the names of those endpoints to the names in the messages. That's not CB per se, it's name association.. And more to the point, you're not signing the messages, so nothing you put into them is trusted above and beyond the AAA exchange already is. If your requirement is to prevent a AAA entity from subverting the exchange by misusing a message, you need something else to vouch for the relationship. That's metadata, or the equivalent. It can't be in the message. That only works if you're signing them independently of the AAA channel so that you can mutually authenticate the SAML layer. Then you might have channel binding for real because you can bind the channel from the authentication of the exchange on top of it. At least that's my read of it. -- Scott From Josh.Howlett@ja.net Tue Nov 12 03:16:56 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB8C11E813F for ; Tue, 12 Nov 2013 03:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=0.497, 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 dtJOeCkhBSAF for ; Tue, 12 Nov 2013 03:16:49 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id D38BC11E813D for ; Tue, 12 Nov 2013 03:16:41 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D24491A9FA5C_2820E18B; Tue, 12 Nov 2013 11:16:40 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id A7AEB1A9FA58_2820E18F; Tue, 12 Nov 2013 11:16:40 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:16:39 +0000 From: Josh Howlett To: "Cantor, Scott" , Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCr5lEbMSIxEuoTzQjplPBzJoaBDwAgAAOnBqAAALEgIAHUkgA//+D8nqAAI2MgP//jJ+AgACvwwD//4LqAAAY4QKA Date: Tue, 12 Nov 2013 11:16:39 +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.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D5AB7B35B739B4FBE6D307E8CF5A60E@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:16:56 -0000 >> >> >> >>Sigh, I got the Requester and Presenter the wrong way around. Is this >>then >>best tackled using subject confirmation? If so, would it be too much of a >>stretch to use Holder of Key where the KeyInfo contains a KeyName naming >>the AAA entity? > >That only works in one direction, and I think you need both here. Not for the specific issue -- of the AAA entity demonstrating its authority to wield the assertion to the RP -- that Sam highlighted. >If this is *really* channel binding, literally, then there's already an >extension for that, but I don't think it's technically CB, just >conceptually similar. > >You have two AAA peers exchanging messages and you want to bind the names >of those endpoints to the names in the messages. That's not CB per se, >it's name association.. That's the other issue that I previously conflated. I don't believe that is channel binding either (although I think the one above definitely is). The SAML name is (as Sam said) essentially an attribute of the assertion against which policy can be applied. As you say, the level of trust that you have in that name is contingent on your trust in the AAA layer. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From cantor.2@osu.edu Tue Nov 12 08:57:05 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC7121E8253 for ; Tue, 12 Nov 2013 08:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE6cjXhhn2cx for ; Tue, 12 Nov 2013 08:56:58 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA9B21E8122 for ; Tue, 12 Nov 2013 08:56:57 -0800 (PST) Received: from mail168-tx2-R.bigfish.com (10.9.14.227) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Tue, 12 Nov 2013 16:56:57 +0000 Received: from mail168-tx2 (localhost [127.0.0.1]) by mail168-tx2-R.bigfish.com (Postfix) with ESMTP id 58A40E03D5; Tue, 12 Nov 2013 16:56:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.210; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf03; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1de097hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1b1cn1b1bi1155h) Received-SPF: pass (mail168-tx2: domain of osu.edu designates 164.107.81.210 as permitted sender) client-ip=164.107.81.210; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf03 ; cio-krc-pf03 ; Received: from mail168-tx2 (localhost.localdomain [127.0.0.1]) by mail168-tx2 (MessageSwitch) id 1384275416249607_11013; Tue, 12 Nov 2013 16:56:56 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.233]) by mail168-tx2.bigfish.com (Postfix) with ESMTP id 340582009C; Tue, 12 Nov 2013 16:56:56 +0000 (UTC) Received: from cio-krc-pf03 (164.107.81.210) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 12 Nov 2013 16:56:53 +0000 Received: from CIO-KRC-HT03.osuad.osu.edu (localhost [127.0.0.1]) by cio-krc-pf03 (Postfix) with ESMTP id 56FB1C004A; Tue, 12 Nov 2013 11:56:53 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:56:53 -0500 From: "Cantor, Scott" To: Josh Howlett , Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml Thread-Index: AQHO29aCoJiFJelWm0mGa+7cgKXk4JoaBDwAgAAOnBqAAALEgIAHUkgA//+D6POAAFtPAP//jJmAgACv1AD//4LZAAAY4oCA///Y8IA= Date: Tue, 12 Nov 2013 16:56:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.177.140.3] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:57:05 -0000 On 11/12/13, 3:16 AM, "Josh Howlett" wrote: >>> >>>Sigh, I got the Requester and Presenter the wrong way around. Is this >>>then best tackled using subject confirmation? If so, would it be too >>>much of a >>>stretch to use Holder of Key where the KeyInfo contains a KeyName naming >>>the AAA entity? >> >>That only works in one direction, and I think you need both here. > >Not for the specific issue -- of the AAA entity demonstrating its >authority to wield the assertion to the RP -- that Sam highlighted. If it's acting as the entity being authenticated by the assertion, then that would be subject confirmation of some kind, yes. Holder of key can be interpreted pretty generally if it's desired. But I don't see how that entity is really acting as the attesting entity. It's not acting on behalf of the subject of the assertion, is it? -- Scott From hartmans@painless-security.com Fri Nov 15 10:25:12 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA46711E81F3; Fri, 15 Nov 2013 10:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI0uy-NhYJo3; Fri, 15 Nov 2013 10:25:05 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D07B811E8225; Fri, 15 Nov 2013 10:25:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9DEFF20540; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_kKLii6DRh1; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D20E0819E7; Fri, 15 Nov 2013 13:25:01 -0500 (EST) From: Sam Hartman To: kitten@ietf.org,emu@ietf.org, abfab@ietf.org Date: Fri, 15 Nov 2013 13:25:01 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Right place for ABFAB ephemeral keying X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Nov 2013 18:25:12 -0000 Hi. At the most recent ABFAB meeting I brought up the idea of adding ephemeral keying to ABFAB. This would provide the following: * Protect the EAP conversation between the peer and NAS (initiator and acceptor in GSS terms) * Provide a key to protect ABFAB negotiations * Prevent the EAP server or proxies between the EAP server and NAS from observing the resulting session This would help defeat fingerprinting by passive observers as well as minimize the damage that a passive server could do cooperating with the home EAP server. This is more valuable for ABFAB used in protocols like NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used within an TLS session for IMAP, XMPP or SMTP. Stephen thought the general idea of protecting ABFAB sounded good but would prefer that we get better protocol re-use and suggested we look into protecting EAP in general. I was dubious of that but suggested protecting Kerberos GSS in general as an option. After trying to work through how to protect either EAP or Kerberos, I've mostly concluded that I don't know how to get significant protocol re-use. However I do agree with Stephen that it would be better that get protocol re-use if we can still implement relatively quickly and meet all of the above protection goals for ABFAB. So, here are my thoughts on EAP and Kerberos: EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run between the peer and EAP server. We want PFS between the peer and NAS. The endpoints are wrong. We could insert a layer similar to ERP (the hokey produced EAP Reauthentication Protocol) between the peer and NAS. It's been a while since I've looked at ERP, but I seem to recall that ERP runs between the peer and an entity in the visited domain although it does have specific NAS support. That approach would be OK for ABFAB assuming it could be implemented efficiently. It would be a bit ugly because you want to start using the ephemeral key well before EAP has concluded. However, for lower layers that do complex keying after EAP concludes, it's probably the wrong approach. Also, ERP took a long time to specify. I don't want to commit to astandardization effort that complex. Kerberos. I was considering trying to share some tokens for ephemeral keying with Kerberos. keying wants ephemeral keing within a GSS mechanism. You could do that for Kerberos, although you'd need to take advantage of the not-widely-implemented extension to the magic checksum used by GSS for channel binding and (in that magic extension) other extensions. In ABFAb the framing would be different because our context tokens have subtokens. However we could use the same PDU. Except for two things. First, Kerberos probably would be happier with an ap-req and ap-rep extension than a GSS mechanism level extension. Secondly, Kerberos might well want to use pkinit data structures and possibly even run a stripped down client-server version of pkinit for the ephemeral keying. That's way too expensive in terms of implementation complexity if you don't already have a pkinit implementation sitting around. my conclusion from all this is that the right place to do ephemeral keying for an EAP protocol is in the lower layer and that unless I got something wrong or missed an alternative, ABFAb should do its own mechanism. Can anyone see a good way to get protocol re-use here? From hartmans@painless-security.com Mon Nov 18 05:47:44 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711B711E8196; Mon, 18 Nov 2013 05:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 DG+TKseDHdUA; Mon, 18 Nov 2013 05:47:15 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8001911E81A6; Mon, 18 Nov 2013 05:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 7694E20548; Mon, 18 Nov 2013 08:46:35 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCmhVGWMmn0m; Mon, 18 Nov 2013 08:46:35 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 18 Nov 2013 08:46:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 44B9981BF1; Mon, 18 Nov 2013 08:46:51 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 18 Nov 2013 08:46:51 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: [abfab] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 13:47:44 -0000 We use token types 06 01 and 06 02 for initial context tokens. However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in order that you can unambiguously distinguish ASN.1 wrapped framing from other framing. Luke, was this an oops or was something more clever going on. In the specific case of draft-ietf-abfab-gss-eap, section 5 requires all our context tokens have the ASN.1 framing. So, testing the first octet for 06 to determine if ASN.1 framing is present is still a fine test so long as you don't do it recursively. I think we have a couple options: 1) Change the token types we use. I don't know if this is a viable option: I need to contact the moonshot community and figure out if people are willing to invalidate all existing deployments. My suspicion is There would be moderate to infinite push back on this. 2) Register 06 01 and 06 02, reserve 06 00 and 06 03 through 06 ff. I think option 2 is acceptable because our mechanism always happens to use ASN.1 framing. From tlyu@mit.edu Mon Nov 18 13:44:05 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE091AE598; Mon, 18 Nov 2013 13:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xeDcjUT15jj; Mon, 18 Nov 2013 13:44:04 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id EA6251AE597; Mon, 18 Nov 2013 13:44:03 -0800 (PST) X-AuditID: 12074424-b7fa56d000000be4-5c-528a8a1dc2f7 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 86.D8.03044.D1A8A825; Mon, 18 Nov 2013 16:43:57 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rAILhu0o008061; Mon, 18 Nov 2013 16:43:56 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAILhsNg020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Nov 2013 16:43:55 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rAILhsx5006729; Mon, 18 Nov 2013 16:43:54 -0500 (EST) To: Sam Hartman References: From: Tom Yu Date: Mon, 18 Nov 2013 16:43:54 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 18 Nov 2013 08:46:51 -0500") Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrCvb1RVk0LRE0OLj9TeMFjM9LY5u XsXiwOyxZMlPJo/Z31oZA5iiuGxSUnMyy1KL9O0SuDJu3L7JVtDMUvH85Bb2BsYFzF2MnBwS AiYS50+eYISwxSQu3FvP1sXIxSEkMJtJ4vSLq1DORkaJD3svglUJCZxjkjhySBMi0cUoMeHK DrBRIgIGEvNeHWMDsZkFlCUm/XrOAmILC3hK9B79zgLRrCqxdcJvpi5GDg42AWmJo4vLQMIs QOH/S86CtXIKJEt8WL4KzOYVsJCY8bYbbC+PAKfE7klb2SHighInZz5hgVilJXHj30umCYyC s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6iREUruwuKjsYmw8p HWIU4GBU4uGd4N4VJMSaWFZcmXuIUZKDSUmUV7IVKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 93cpUI43JbGyKrUoHyYlzcGiJM57i8M+SEggPbEkNTs1tSC1CCYrw8GhJMG7oQOoUbAoNT21 Ii0zpwQhzcTBCTKcB2j4CZAa3uKCxNzizHSI/ClGRSlx3oMgCQGQREZpHlwvLJ28YhQHekWY 9zxIFQ8wFcF1vwIazAQ0+PjzNpDBJYkIKakGxvBpIax1KXOeRC5devN7spX+VaWPKxTCePM+ 1roqXXYTFiy3e2hz31XKuzaq6OMa9gA2yxvPFlb4nryeZvxCvfX2PYUj6/9w3uJ3WrhM7t+1 s6WaNuseieVr5xe9c6tj5cydonPmj038A4MTW5zWPG22WvXxwMdd/xYXW4pemFLHn6Cz5cRj DSWW4oxEQy3mouJEAHzszdQCAwAA Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:44:05 -0000 Sam Hartman writes: > We use token types 06 01 and 06 02 for initial context tokens. > > However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in > order that you can unambiguously distinguish ASN.1 wrapped framing from > other framing. RFC 4121 Section 4.4 reserves 60 00 through 60 FF. The BER identifier octet for "Application tag 0 (constructed)" is 0x60, not 0x06. (0x06 would be "Universal tag 6 (primitive)", also known as "OBJECT IDENTIFIER".) From mrex@sap.com Mon Nov 18 13:54:40 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86D21AE5E3; Mon, 18 Nov 2013 13:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alt880AkXjJP; Mon, 18 Nov 2013 13:54:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D0D251AE5F8; Mon, 18 Nov 2013 13:54:38 -0800 (PST) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAILsVGt026181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 22:54:31 +0100 (MET) In-Reply-To: To: Tom Yu Date: Mon, 18 Nov 2013 22:54:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131118215431.C9C651AAB2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] [kitten] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:54:40 -0000 Tom Yu wrote: > Sam Hartman writes: > > > We use token types 06 01 and 06 02 for initial context tokens. > > > > However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in > > order that you can unambiguously distinguish ASN.1 wrapped framing from > > other framing. > > RFC 4121 Section 4.4 reserves 60 00 through 60 FF. The BER identifier > octet for "Application tag 0 (constructed)" is 0x60, not 0x06. (0x06 > would be "Universal tag 6 (primitive)", also known as "OBJECT > IDENTIFIER".) Correct. 0x60 will be the first byte of a "generic framing" as it must be present on the initial context token as described in rfc2743, Section 3.1 Mechanism-independent token format (bottom of page 81) http://tools.ietf.org/html/rfc2743#page-81 1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that -- constructed form, definite length encoding follows. The Kerberos rfc1964 gssapi mechanism decided to (re-)use that generic framing on all context-level tokens, plus on all per-message tokens. rfc4121 dropped the generic framing on the per-message token, and the quoted rule (and exemption for token IDs (60 00 -- 60 ff) is to enable a cheap heuristic to recognize whether a generic framing is present on a Kerberos per-message token. -Martin From hartmans@painless-security.com Tue Nov 19 07:00:14 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24161AE000; Tue, 19 Nov 2013 07:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e46CS-I78Nsl; Tue, 19 Nov 2013 07:00:13 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD211ADFE7; Tue, 19 Nov 2013 07:00:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3ECF420397; Tue, 19 Nov 2013 09:59:46 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeW2JukDTnKE; Tue, 19 Nov 2013 09:59:46 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 19 Nov 2013 09:59:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9075780C88; Tue, 19 Nov 2013 10:00:06 -0500 (EST) From: Sam Hartman To: mrex@sap.com References: <20131118215431.C9C651AAB2@ld9781.wdf.sap.corp> Date: Tue, 19 Nov 2013 10:00:06 -0500 In-Reply-To: <20131118215431.C9C651AAB2@ld9781.wdf.sap.corp> (Martin Rex's message of "Mon, 18 Nov 2013 22:54:31 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] [kitten] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Nov 2013 15:00:15 -0000 Yes. I clearly was not awake yesterday and transposed the digits. Thanks Tom and martin for pointing that out. If only I hadn't also been equally alert while refactoring code yesterday morning. I did eventually get that fixed too:-) From hartmans@painless-security.com Wed Nov 20 04:05:44 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A161ADEB4 for ; Wed, 20 Nov 2013 04:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG4EdXtTowYA for ; Wed, 20 Nov 2013 04:05:42 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 32B361ADE88 for ; Wed, 20 Nov 2013 04:05:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EDCA620525; Wed, 20 Nov 2013 07:05:09 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5l4b4hZz2dZ; Wed, 20 Nov 2013 07:05:09 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 20 Nov 2013 07:05:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B3AE282AB6; Wed, 20 Nov 2013 07:05:30 -0500 (EST) From: Sam Hartman To: David Chadwick References: <527C757D.5020000@kent.ac.uk> <527FFEE5.6090409@kent.ac.uk> <52800008.1010204@mnt.se> <528000EB.8040009@kent.ac.uk> <528005FB.6070106@mnt.se> <5280855F.8050405@kent.ac.uk> <52810C94.6010205@sunet.se> <52811552.2090605@kent.ac.uk> Date: Wed, 20 Nov 2013 07:05:30 -0500 In-Reply-To: <52811552.2090605@kent.ac.uk> (David Chadwick's message of "Mon, 11 Nov 2013 17:35:14 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2013 12:05:44 -0000 >>>>> "David" == David Chadwick writes: David> I dont understand what your trust model is, if you dont have David> a PKI or a trust router, then how can an RP trust any SAML David> metadata that it has obtained from anywhere? It has to get David> this from a trustworthy source. I thought that the David> trustrouter (admin) was this TTP. If not, then who is? draft-ietf-abfab-aaa-saml talks about two trust models. The first, AAA trust, is discussed in section 2.1 of draft-ietf-abfab-arch-08 and section 5.3.1 of draft-ietf-abfab-aaa-saml-08. You're correct that Moonshot plans to use trustrouter to instantiate that trust model and currently we are mostly focused around that trust model. It's possible that someone will want to use an existing SAML federation with its own existing trust model (probably based on signed SAML metadata) and send SAML messages over RADIUS. I'm not working on any deployments of that, and I don't know of anyone in the Moonshot community who is going out of their way to make that possible. However the Shibboleth SP already comes with the majority of code you need for that. So, it's probably relatively easy to make that possible. It turns out there are security implications when you give a barrer token like a SAML assertion to a third party. There are several ways of looking at the problems that can result. I've chosen to look at it is confirming the party who gave you the assertion was intended to receive it by someone you trust. Section 5.3.2 of draft-ietf-abfab-aaa-saml, tries to discuss this. We've found it to be a complex discussion. Does this help clarify what's going on? --Sam From hartmans@painless-security.com Wed Nov 20 04:12:41 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6B1ADEC0 for ; Wed, 20 Nov 2013 04:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ragZsd66uMp0 for ; Wed, 20 Nov 2013 04:12:40 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D62F91AD8D8 for ; Wed, 20 Nov 2013 04:12:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A914520568; Wed, 20 Nov 2013 07:12:10 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvT7Ytv6BlvR; Wed, 20 Nov 2013 07:12:10 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 20 Nov 2013 07:12:10 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E2DDF82AB6; Wed, 20 Nov 2013 07:12:31 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Wed, 20 Nov 2013 07:12:31 -0500 In-Reply-To: (Scott Cantor's message of "Tue, 12 Nov 2013 16:56:52 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2013 12:12:41 -0000 I think Scott's desire for a symmetric solution is strongly desirable. The issue (which is conceptually similar to CB but is not technically related to CB) appears in both directions. The RP needs to demonstrate that it SAML message should be presented by the RP's AAA entity. - The IDP needs to demonstrate to the RP that its assertion should come via the expected AAA realm. Both issues matter, and a symmetric solution seems like a win. From Josh.Howlett@ja.net Thu Nov 28 03:52:24 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20DF1AE0D1; Thu, 28 Nov 2013 03:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dueuhi522cT3; Thu, 28 Nov 2013 03:52:21 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 907CF1AE0CF; Thu, 28 Nov 2013 03:52:21 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0A5544A6BA0_2972E74B; Thu, 28 Nov 2013 11:52:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id A21944A6B1C_2972E72F; Thu, 28 Nov 2013 11:52:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 11:52:18 +0000 From: Josh Howlett To: Sam Hartman , "kitten@ietf.org" , "emu@ietf.org" , "abfab@ietf.org" Thread-Topic: [Emu] Right place for ABFAB ephemeral keying Thread-Index: AQHO4jAYN1MIKnIBekG46BO4ULt9e5o6nCiA Date: Thu, 28 Nov 2013 11:52:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <8687A9390B2F9F429FD8BEC1958F0720@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] [Emu] Right place for ABFAB ephemeral keying X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:52:24 -0000 Sam, I agree with your conclusion. There are example of lower layers using EAP-based ephemeral keying, and ABFAB could perhaps look to those for inspiration and perhaps reuse. Josh. On 16/11/2013 02:25, "Sam Hartman" wrote: > >Hi. >At the most recent ABFAB meeting I brought up the idea of adding >ephemeral keying to ABFAB. >This would provide the following: > >* Protect the EAP conversation between the peer and NAS (initiator and > acceptor in GSS terms) > >* Provide a key to protect ABFAB negotiations > >* Prevent the EAP server or proxies between the EAP server and NAS from > observing the resulting session > >This would help defeat fingerprinting by passive observers as well as >minimize the damage that a passive server could do cooperating with the >home EAP server. This is more valuable for ABFAB used in protocols like >NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used >within an TLS session for IMAP, XMPP or SMTP. > > >Stephen thought the general idea of protecting ABFAB sounded good but >would prefer that we get better protocol re-use and suggested we look >into protecting EAP in general. I was dubious of that but suggested >protecting Kerberos GSS in general as an option. > >After trying to work through how to protect either EAP or Kerberos, I've >mostly concluded that I don't know how to get significant protocol >re-use. However I do agree with Stephen that it would be better that >get protocol re-use if we can still implement relatively quickly and >meet all of the above protection goals for ABFAB. > >So, here are my thoughts on EAP and Kerberos: > >EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run >between the peer and EAP server. We want PFS between the peer and NAS. >The endpoints are wrong. > >We could insert a layer similar to ERP (the hokey produced EAP >Reauthentication Protocol) between the peer and NAS. It's been a while >since I've looked at ERP, but I seem to recall that ERP runs between the >peer and an entity in the visited domain although it does have specific >NAS support. > >That approach would be OK for ABFAB assuming it could be implemented >efficiently. It would be a bit ugly because you want to start using the >ephemeral key well before EAP has concluded. However, for lower layers >that do complex keying after EAP concludes, it's probably the wrong >approach. Also, ERP took a long time to specify. I don't want to >commit to astandardization effort that complex. > >Kerberos. I was considering trying to share some tokens for ephemeral >keying with Kerberos. keying wants ephemeral keing within a GSS >mechanism. You could do that for Kerberos, although you'd need to take >advantage of the not-widely-implemented extension to the magic checksum >used by GSS for channel binding and (in that magic extension) other >extensions. In ABFAb the framing would be different because our context >tokens have subtokens. However we could use the same PDU. > >Except for two things. First, Kerberos probably would be happier with >an ap-req and ap-rep extension than a GSS mechanism level extension. >Secondly, Kerberos might well want to use pkinit data structures and >possibly even run a stripped down client-server version of pkinit for >the ephemeral keying. That's way too expensive in terms of >implementation complexity if you don't already have a pkinit >implementation sitting around. > >my conclusion from all this is that the right place to do ephemeral >keying for an EAP protocol is in the lower layer and that unless I got >something wrong or missed an alternative, ABFAb should do its own >mechanism. > >Can anyone see a good way to get protocol re-use here? >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238