From nobody Fri Jul 4 09:35:20 2014 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 B74551A0327; Fri, 4 Jul 2014 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RUlEQadOI6AA; Fri, 4 Jul 2014 09:35:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CFB1A028B; Fri, 4 Jul 2014 09:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704163515.28435.37508.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 09:35:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/jxm2Ia3ZK3QlTbyckrDHFCOSF5Y Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:35:16 -0000 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) Usability and User Interface Considerations Author : Rhys Smith Filename : draft-ietf-abfab-usability-ui-considerations-01.txt Pages : 19 Date : 2014-07-04 Abstract: The real world use of ABFAB-based technologies requires that any identity to be used to authenticate be configured on the ABFAB- enabled client device. Achieving this requires software on that device (either built into the operating system or a standalone utility) that will interact with the user, managing their identity information and identity-to-service mappings. All designers of software to fulfil this role will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some degree of consistency between implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-usability-ui-considerations/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-usability-ui-considerations-01 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 nobody Fri Jul 4 09:39:58 2014 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 C5C131A04D2 for ; Fri, 4 Jul 2014 09:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 XFBEunqUC1TP for ; Fri, 4 Jul 2014 09:39:51 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80531A0342 for ; Fri, 4 Jul 2014 09:39:50 -0700 (PDT) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB024.eurprd02.prod.outlook.com (10.242.81.153) with Microsoft SMTP Server (TLS) id 15.0.974.11; Fri, 4 Jul 2014 16:39:48 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.23]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.23]) with mapi id 15.00.0974.002; Fri, 4 Jul 2014 16:39:48 +0000 From: Rhys Smith To: "" Thread-Topic: UI draft -01 Thread-Index: AQHPl6aR2hFV5Cfh6ECjACinwrjIuw== Date: Fri, 4 Jul 2014 16:39:48 +0000 Message-ID: <7CE2544C-F0E4-4996-A4ED-162C45391287@cardiff.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [86.156.183.212] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(252514010)(189002)(199002)(55674002)(76482001)(101416001)(85306003)(77096002)(15975445006)(82746002)(33656002)(229853001)(107046002)(107886001)(110136001)(106356001)(106116001)(95666004)(74662001)(551544002)(105586002)(74502001)(20776003)(64706001)(92726001)(80022001)(74482001)(66066001)(86362001)(2656002)(83716003)(19580405001)(19580395003)(83322001)(87936001)(83072002)(85852003)(21056001)(54356999)(77982001)(50986999)(99936001)(99396002)(79102001)(81342001)(81542001)(4396001)(46102001)(36756003)(566174002)(104396001)(491001)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB024; H:AMSPR02MB022.eurprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_5B72355A-3A71-4A3A-8D15-08635A18E78C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/HkQvtAT9mpUR9VhDWjoKCC11Dcw Subject: [abfab] UI draft -01 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: Fri, 04 Jul 2014 16:39:54 -0000 --Apple-Mail=_5B72355A-3A71-4A3A-8D15-08635A18E78C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Not working to a deadline or anything, obviously=85 ! draft-ietf-abfab-usability-ui-considerations-01 has been uploaded; = available in all the usual places, including = https://datatracker.ietf.org/doc/draft-ietf-abfab-usability-ui-considerati= ons/ Thanks to those who reviewed the doc, we=92ve now had several more pairs = of eyes look through it than we previously have had, which is great. I=92ve done a tidy up of the document to get it into an almost-ready = state, and finished the majority of the TODOs. It also addresses the = feedback I received post-London (see below). Changelog at the bottom = lists the main changes. So in my opinion, it=92s getting pretty close = now. What=92s left? Three final main TODOs remain - security & privacy = considerations, which I=92ll be working on ASAP, and the handling of = errors & successes sections which I was going to get some help with but = I think it=92s fallen through the cracks in the meantime (both mine and = the offerer of the help) so that=92ll be for the next iteration of the = doc. Addressing specific feedback from Kevin, Mark, Dave: =3D=3D=3D=3D=3D =46rom Kevin: > Sections 3, 4, and 6 refer to the identity selector as a 'mechanism' = used by > GSS-API to obtain identity information. This is potentially confusing = since > the identity selector is not a mechanism in the GSS-API sense of the = term. > Especially since in section 6.5 "...error messages provided by the = mechanism > may not be helpful enough..." does use 'mechanism' in the GSS-API = sense of > the term. Agreed, changed throughout. > Section 7.5 says the ui should indicate when an identity is 'currently = in use,' > but it is unclear to me how that can be determined. The selector knows = when it > has sent an identity and can be informed when an authentication is = successful > or fails, but how can it know for how long that authentication remains = valid > or in use? Agreed, added a caveat to that effect. > Implementing sections 7.1, 8, and 9 would require that the GSS-API = mechanism > report back to the identity selector when the authentication = completes. The > mechanism needs to provide a unique key which can be used to look up = the > identity the the selector previously provided at the start of the > authentication. Would it make sense for the draft to specify that the = NAI alone > should be sufficient for this purpose? I.e., that the identity = selector MUST > NOT store different identities that use the same NAI? Agreed, added. > There are numerous cases of lowercase "should" thoughout the document. > It is unclear whether these ought to be uppercase SHOULD or even MUST. > e.g. 6.6.1, 7.3, 7.4 If I=92ve used SHOULD or MUST then it=92s RFC2119. If i=92ve used should = or must, then it=92s not :-). > Minor grammar/style nits: > 1. "This document aims to document these challenges with the > aim of producing well-thought out UIs with some degree of > consistency." > Awkward. Maybe replace "aims to document" with "addresses=94? Problem is that we=92re not addressing the challenges, we=92re = enumerating them. > 7. "This potentially complex many-to-many association between is not > easily comprehended by the user" > Should be "...between identities and services=94 Yep! > 8. "can really effect" should be "can really affect" Gah, good catch. =3D=3D=3D=3D=3D =46rom Mark: > First, I have some easy editorial remarks: > * Section 6.3.2 mentions provisioning several times, but section 6.3 > says that the draft won't be using the term provisioning. Heh, oops :-). Sorted. > * Section 7.5 contains, "...to identify which the identity is used..." > The word "the" should be removed. Done. > Next, some quick content remarks: > * Section 4 lists that "there are of course two methods that could be > employed to configure identities and associated information." I can > imagine more than that! Changed to =93at least=94=85 Interested in whether you think some of the = other methods that you can think of should be added to the doc? > * Section 6.3.3, "Fully Automated Addition," discusses that users = might > be confused when they can access services without a password prompt. > I disagree - Windows Networking, SPNEGO under Internet Explorer, > browser cookies, and browsers remembering your credentials all offer > access to services without prompting for credentials. I would not be > surprised to discover that access without specific credential > prompting is more common than with. I do only say =93could=94 be confused, and I stick by that - because = we=92re moving from within the enterprise to a global federated = ecosystem where existing authentication mechanisms to the variety of = services that are relevant to ABFAB have existing methods and practices = and we=92re changing those here. >=20 > Now, some topics for discussion: > * The end of Section 6.1 suggests helpful links that might be = presented for each identity, such as a password changing URL and > Helpdesk URL. Where do you suggest that we get these values? Would = that be in the authentication response? Would that just use = conventional paths? Included in the automated identity provisioning^Wpopulation = configuration. You could push these out alongside the trust anchors and = whatnot. That would seem more sensible than adding it to the = authentication process itself to me. > * Section 6.5 talks about verifying the identity, and how there's no > way to verify a NAI and credential tuple. Is that really true? > Couldn't we create one? Maybe set up a do-nothing GSS server on the > machine with the Identity Selector, and then specify that any ABFAB > RADIUS system MUST allow access to that localsystem (say, > localhost.localdomain/test). Mmm good idea. In which case, there=92s no *current* way to do it, but = that might be something worth working on because it could be pretty = useful. > * Section 7.3 (Listing Services and Identities) - I'd like to see this > have some more detail. For instance, it could discuss how the nature > of the many-to-many associations between identities and services > creates a need to list out the identities with their associated > servers, and also list out the services, with their associated > identities. I'd be happy to add this. Cool, happy to take some text! For the next draft now, obviously. > Oh, and further - what if you're using multiple services, with = different identities, at the same time? Mmm that one paragraph is turning out to be a bit of a minefield... It=92s= definitely an aspiration rather than a concrete suggestion, given that = it seems rather impossible to actually implement at the moment. =3D=3D=3D=3D=3D =46rom Dave: > Calling for icons is a very specific design solution recommendation. Agreed. I=92ve tried to tidy up the language a bit throughout the = document to explicitly point out that the role of the document is to = enumerate the issues, and the examples of things you might want to do in = a UI are just that - simply examples, and they do not in any way replace = good solid HCI/UX design work. Best, 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: 0x4638C985 --Apple-Mail=_5B72355A-3A71-4A3A-8D15-08635A18E78C 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 iQIcBAEBCAAGBQJTttjTAAoJEJzS5DEs203hvjEQAMKhJM5v1/lHGoSwIYtjmVH4 DpADd6A3C5xesO/LHVjK863Ooqcqp1rycAPqK/rXlWPLEmIGNn7vY3em6y8IoP4D c6fh2V2jU9lD3mTCo5Vm218IwSH7tM6dXyEYvG7jD0NZtrPx3nr+/DEeRKx6RbOt Mfjz4Q+y1lCG2NYn5mmntCys9lZ0VbL008zhWjBn3FOsIqE9RFf4at6ogFBN2LNN BgSd6A4i2jNwTnKQPpmAe/Z23Soyw4s3y1nXo3qK4grbiT65nWuHAQ3Qjh+5YUlL yWlbrYoGvDTgNfGVRbl6YCboXqpxobjDkALGp3otuVGDTp6fagg+o5fnU5yMpK1E 30i3DNRj/2Xk7WQzneF36T5o3Nguzqf1zljlpyT4ibieyyRioPNp2jvl73AkkI2X uhMiyA19qUvtDXJGFk4Xo59Xr0eLinVlR5iDzh/1CA+oAEkh+Eh9Lqh4IxF9m6BO 42KSmW7jWjjWQIbcuYrdhYJRoaBp7r6D+54RE8Yj23cuBqhtllM3/KzhDWEUxFC5 HdXLLhAHYWdDtBa3Y4IuVXthzx6TX/eXAWGkrZ8RNzjCSkkAZnclmFegBHoKxlR8 JB/QZDPZpa7yfdbZuQ5nTx/nBnMot1XShUtHEtiAM7Te/WKnl2jp3gc9h22InIEN 6sxxeHhFmTIABlN/e0R9 =2TTK -----END PGP SIGNATURE----- --Apple-Mail=_5B72355A-3A71-4A3A-8D15-08635A18E78C-- From nobody Sun Jul 13 11:39:59 2014 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 00AB21A00C6 for ; Sun, 13 Jul 2014 11:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.477 X-Spam-Level: X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no 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 bMzxfqm49crO for ; Sun, 13 Jul 2014 11:39:54 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1161A00C5 for ; Sun, 13 Jul 2014 11:39:53 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s6DIdo8I017783 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 13 Jul 2014 20:39:50 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s6DIdlg2005714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Jul 2014 20:39:50 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [172.20.10.3] ([2.67.51.205]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)) for abfab@ietf.org; Sun, 13 Jul 2014 20:39:46 +0200 Message-ID: <53C2D271.70701@sunet.se> Date: Sun, 13 Jul 2014 20:39:45 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, 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: 09MpSDOTf - f2dc29077a9a - 20140713 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/85N4CJz4vz3VlQnSpMWEtnGcSCo Subject: [abfab] agenda for Toronto 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: Sun, 13 Jul 2014 18:39:56 -0000 Folks, We've only got a 1hr slot for Toronto and there are 3 major items to cover: - finish up architecture draft - aaa-saml - ui-considerations I know Sam will present remotely on the first item and I believe Rhys will be in the room (?) to cover the last. Who is willing and able to cover aaa-saml? Cheers Leif From nobody Mon Jul 21 07:07:39 2014 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 A00311A005D; Mon, 21 Jul 2014 07:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 p9hJYDz3DGBJ; Mon, 21 Jul 2014 07:07:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D981A00E2; Mon, 21 Jul 2014 07:05:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721140543.32210.29345.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 07:05:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/uVsDMx31ADWjk1S2m_yQ--qqCk0 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-13.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:07:36 -0000 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 Authors : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-13.txt Pages : 44 Date : 2014-07-21 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 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) the Generic Security Service Application Program Interface (GSS-API), 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-13 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 nobody Mon Jul 21 07:09:03 2014 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 58B7D1A0043 for ; Mon, 21 Jul 2014 07:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 XRdeWmn1vKP9 for ; Mon, 21 Jul 2014 07:08:54 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055781A0005 for ; Mon, 21 Jul 2014 07:07:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 55FF120758 for ; Mon, 21 Jul 2014 10:05:02 -0400 (EDT) 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 uwq6ELSRGsVe for ; Mon, 21 Jul 2014 10:05:02 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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 ; Mon, 21 Jul 2014 10:05:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A4D981C5F; Mon, 21 Jul 2014 10:07:43 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Mon, 21 Jul 2014 10:07:43 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/SJkAG-TZWJx60VYg73_HbePpzwc Subject: [abfab] New version of arch posted 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, 21 Jul 2014 14:09:00 -0000 This includes some minor wording fixes as well as hopefully resolving some minor IESG comments from Adrian and one of the ops ads. I'd appreciate it if one of the chairs would check this version against the outstanding comments before we send it forward. From nobody Thu Jul 24 06:35:44 2014 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 F35941A0320 for ; Thu, 24 Jul 2014 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no 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 Tu0V40EUtYuQ for ; Thu, 24 Jul 2014 06:35:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6441A0361 for ; Thu, 24 Jul 2014 06:35:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 62E3720188 for ; Thu, 24 Jul 2014 09:32:46 -0400 (EDT) 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 tph_iUTPZ1rz for ; Thu, 24 Jul 2014 09:32:45 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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, 24 Jul 2014 09:32:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 590F880C97; Thu, 24 Jul 2014 09:35:32 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Thu, 24 Jul 2014 09:35:32 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/eoQzPHijjNGyho6KgocucrhL_rk Subject: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 13:35:39 -0000 hi. I was very surprised to hear Rhys's presentation on draft-ietf-abfab-aaa-saml today, because Josh proposed to solve a different problem than we've been working on over the last year. Also, I do not feel very comfortable about the proposed solution. As I understand it, in the case where we're not using SAML metadata, and where we're relying on the AA trust fabric, we make the requirement that the AAA entities correspond to the SAML entities. So, we don't need to constrain the SAML naming because the AAA entities are making the assertions that the SAML names also correspond to the AAA names. In the case where we're trusting SAML metadata or policy, the issue is that we need to avoid a cut&paste attack where a SAML message intended for one party is intended for another party. The issue we are trying to solve is how to indicate in SAML messages or metadata that a particular AAA endpoint was a valid destination for a binding or entity. This issue is handled in the web profile by having the IDP redirect back to the service provider. We have more complexity because rather than sending the message directly over HTTPS, the home AAA server sends the message back over AAA. we need to make sure that the home AAA server is not man-in-the-middling the IDP--being a legitimate SP towards the IDP, getting an assertion, and then using that assertion to give one of its users access. We've had a lot of discussion on this already, and I am fairly sure we already rejected the approach of constraining the entity identifiers of the SAML endpoints. The approach proposed today is one that I prefer less well than approaches Josh, Rhys and I have discussed offline. From nobody Thu Jul 24 08:41:53 2014 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 CF9801A02D6 for ; Thu, 24 Jul 2014 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_35=0.6] autolearn=no 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 UMis31hw_Mqn for ; Thu, 24 Jul 2014 08:41:33 -0700 (PDT) Received: from har003676.ukerna.ac.uk (smtp-relay.ukerna.ac.uk [194.82.140.75]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E51C1A0398 for ; Thu, 24 Jul 2014 08:41:16 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 903C54A6BA8_3D1291AB; Thu, 24 Jul 2014 15:41: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 344C04A6BA6_3D1291AF; Thu, 24 Jul 2014 15:41:14 +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, 24 Jul 2014 16:41:13 +0100 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Significant concerns about aaa-saml presentation Thread-Index: AQHPp0Q+1F64zp9z1U+y7xv7CyQ7QJuvS01A Date: Thu, 24 Jul 2014 15:41:12 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/5i0YtwOimBoHctg3MsmSOGYB5fw Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 15:41:40 -0000 Hi Sam, > As I understand it, in the case where we're not using SAML metadata, and > where we're relying on the AA trust fabric, we make the requirement that = the > AAA entities correspond to the SAML entities. > So, we don't need to constrain the SAML naming because the AAA entities > are making the assertions that the SAML names also correspond to the AAA > names. Yes, but I believe that we also need to constrain SAML naming to the extent= that SAML entities are making claims about their names to other entities i= n a way that is consistent with the underlying AAA system. For example, in a model where AAA trust is assumed sufficient, a relying pa= rty could consume the same SAML name from two entities. This isn't a proble= m if a relying party is just interested in consuming the rest of the assert= ion (attributes, etc.) that relate to an authenticated principal but, for e= xample, it would impede a subsequent SAML exchange where all the requestor = has is a SAML name for an entity whose semantics say nothing about how to r= each it using AAA. =20 > In the case where we're trusting SAML metadata or policy, the issue is th= at > we need to avoid a cut&paste attack where a SAML message intended for > one party is intended for another party. The issue we are trying to solv= e is > how to indicate in SAML messages or metadata that a particular AAA > endpoint was a valid destination for a binding or entity. Ah yes, the slides were not explicit about this, sorry. The assertion would= be scoped to an (the valid destination) using the proposed form= at, signed by the issuer, and use a standard SAML entity identifier to iden= tify itself. The recipient, having validated the signature against the meta= data, could validate itself as the intended . 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 nobody Thu Jul 24 08:54:43 2014 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 E8E561A03D6 for ; Thu, 24 Jul 2014 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rXG84GEIGCCJ for ; Thu, 24 Jul 2014 08:54:39 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85141A0301 for ; Thu, 24 Jul 2014 08:54:38 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so2945493wes.18 for ; Thu, 24 Jul 2014 08:54:36 -0700 (PDT) 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=YfpwuiWQaofsUzysH49lenceEnNMJ1WpahiF9pitGls=; b=ekEPAQC1yYA8972sIARPp2wnyMPQ0Mn6SyzAjBPiJJc7ReVibJQ2aSY5Cl1NbgxWrA gtEoE6Y/1yd/HLXzFKFuISa9qiNSZNa8wA3Uau7lKtnhYiRPqP9+A+XzVVh2PKf3nqEp 702gLHCll6cCvj7UdA+dZBnwkCV2oZ1Hi0qP+TEOXAqFEuKgqelwPJTR4ERVerLJ98US DbobmS+gNqx5nWyVxAPVg+9nG7sgVUY9aiHo50dEdvUzIgAVLUiDj5HoK4euxXvVzxJD IccrSwizhWrHqef2SWU9qdrWHwrxoFOj/PWeJD36I9Sapisyg71LT6acT4YPLu9AepCQ h4MA== X-Gm-Message-State: ALoCoQkbdqS0w1NJoYkvaWaNpdNnv77b07IfPGrxsalTlR0W3mgTj4RYKClC+b6YqF+TjnK3e/Q8 X-Received: by 10.194.6.134 with SMTP id b6mr14023211wja.64.1406217276186; Thu, 24 Jul 2014 08:54:36 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:35b5:42f4:844b:de48? ([2001:67c:370:152:35b5:42f4:844b:de48]) by mx.google.com with ESMTPSA id h3sm16937145wjn.10.2014.07.24.08.54.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jul 2014 08:54:35 -0700 (PDT) Message-ID: <53D12C37.20309@mnt.se> Date: Thu, 24 Jul 2014 17:54:31 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: abfab@ietf.org References: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/6TrT9E4cBgOYshVwDPEOtB343gc Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 15:54:41 -0000 On 2014-07-24 17:41, Josh Howlett wrote: > Hi Sam, (not speaking as chair) > >> As I understand it, in the case where we're not using SAML metadata, and >> where we're relying on the AA trust fabric, we make the requirement that the >> AAA entities correspond to the SAML entities. >> So, we don't need to constrain the SAML naming because the AAA entities >> are making the assertions that the SAML names also correspond to the AAA >> names. > > Yes, but I believe that we also need to constrain SAML naming to the extent that SAML entities are making claims about their names to other entities in a way that is consistent with the underlying AAA system. > Fair enough but I believe your cure is much worse than the affliction of having to deal with SAML metadata. Cheers Leif From nobody Thu Jul 24 09:03:51 2014 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 AF4471A0347 for ; Thu, 24 Jul 2014 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 CjEOmyNqxUOh for ; Thu, 24 Jul 2014 09:03:46 -0700 (PDT) Received: from har003676.ukerna.ac.uk (smtp-relay.ukerna.ac.uk [194.82.140.75]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6513F1A03AD for ; Thu, 24 Jul 2014 09:03:40 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7FEF24A6B8E_3D12E5AB; Thu, 24 Jul 2014 16:03:38 +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 554704A6B32_3D12E5AF; Thu, 24 Jul 2014 16:03:38 +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, 24 Jul 2014 17:03:37 +0100 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] Significant concerns about aaa-saml presentation Thread-Index: AQHPp0Q+1F64zp9z1U+y7xv7CyQ7QJuvS01AgAAEg4CAABMOYA== Date: Thu, 24 Jul 2014 16:03:36 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3A67AB8A3@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> <53D12C37.20309@mnt.se> In-Reply-To: <53D12C37.20309@mnt.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/7gqwzvKMR1ccR1YFpcIXrtxoJrA Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 16:03:49 -0000 Hi Leif, > Fair enough but I believe your cure is much worse than the affliction of > having to deal with SAML metadata. Could you elaborate? 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 nobody Thu Jul 24 09:04:47 2014 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 2B38D1A0176 for ; Thu, 24 Jul 2014 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 fN1I9wZnCJ62 for ; Thu, 24 Jul 2014 09:04:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468791A01E2 for ; Thu, 24 Jul 2014 09:04:40 -0700 (PDT) Received: from BN1AFFO11FD048.protection.gbl (10.58.52.31) by BN1AFFO11HUB038.protection.gbl (10.58.52.149) with Microsoft SMTP Server (TLS) id 15.0.980.11; Thu, 24 Jul 2014 16:04:33 +0000 Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BN1AFFO11FD048.mail.protection.outlook.com (10.58.53.63) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Thu, 24 Jul 2014 16:04:33 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf08.osuad.osu.edu (Postfix) with ESMTPS id 3E0BB2E0074; Thu, 24 Jul 2014 12:04:32 -0400 (EDT) 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.0174.001; Thu, 24 Jul 2014 12:04:31 -0400 From: "Cantor, Scott" To: Josh Howlett , Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Significant concerns about aaa-saml presentation Thread-Index: AQHPp0RFz7iT6MhLX0CPW3lnAWg8zJuvn+kA///DdIA= Date: Thu, 24 Jul 2014 16:04:31 +0000 Message-ID: References: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <1959BCF4DBE09E4A9570728D3D626758@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.222; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(979002)(6009001)(438002)(24454002)(377454003)(199002)(189002)(479174003)(51704005)(95666004)(107046002)(19580405001)(46102001)(83322001)(46406003)(106116001)(88552001)(21056001)(106466001)(85306003)(109096001)(93346002)(50466002)(89122001)(77096002)(92566001)(87936001)(83072002)(77982001)(107886001)(97756001)(76176999)(50986999)(74662001)(74502001)(36756003)(92726001)(2656002)(54356999)(31966008)(86362001)(99396002)(23726002)(81342001)(76482001)(47776003)(19580395003)(44976005)(79102001)(85852003)(6806004)(64706001)(20776003)(75432001)(66066001)(4396001)(80022001)(81542001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB038; H:cio-tnc-pf08.osuad.osu.edu; FPR:; MLV:ovrnspm; PTR:cio-tnc-pf08.osuad.osu.edu; A:1; MX:1; LANG:en; X-OriginatorOrg: osu.edu X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 028256169F Received-SPF: Pass (: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=cantor.2@osu.edu; Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/OlDxY7gYDhT7bT9Euy9TaURIrN4 Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 16:04:46 -0000 On 7/24/14, 11:41 AM, "Josh Howlett" wrote: > >Ah yes, the slides were not explicit about this, sorry. The assertion >would be scoped to an (the valid destination) using the >proposed format, signed by the issuer, and use a standard SAML entity >identifier to identify itself. The recipient, having validated the >signature against the metadata, could validate itself as the intended >. I'm not sure what your threat model is, but that doesn't really prevent a MITM. The binding-level protections in SAML are not Audience, but Destination/Recipient attributes, because those are actual network endpoints. Audience is like a message-level constraint on the very end of the chain of hops, but it can't limit the chain of hops. If I understand the point of Sam's comment, he's concerned about the same problem I can't really solve in SAML-EC, which is that the client is essentially driving the bus here, and not the IdP, so there isn't any way to control what endpoint(s) the message can be delivered to. The only fix for me was channel binding as a backstop to prevent MITM attacks, because in my model the IdP is the one validating the channel binding for the two parties trying to communicate. (If I'm not talking about the same problem, just dismiss my comment.) -- Scott From nobody Thu Jul 24 09:17:44 2014 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 07ACF1A0345 for ; Thu, 24 Jul 2014 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no 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 A7iwkIN499Mv for ; Thu, 24 Jul 2014 09:17:39 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0FA1A0058 for ; Thu, 24 Jul 2014 09:17:38 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s6OGHZg8026222 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jul 2014 18:17:35 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s6OGHWxF005607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jul 2014 18:17:35 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [31.133.159.212] ([31.133.159.212]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128 bits)) for abfab@ietf.org; Thu, 24 Jul 2014 18:17:32 +0200 Message-ID: <53D1319A.10008@sunet.se> Date: Thu, 24 Jul 2014 18:17:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: abfab@ietf.org References: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> <53D12C37.20309@mnt.se> <55DC663C2F4F9F439F23543E0078E8B3A67AB8A3@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3A67AB8A3@EXC001> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, 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: 09Mughzti - ced37abda810 - 20140724 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/y6i_3HN010ulKjk1vBvNFFNd_pQ Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 16:17:41 -0000 On 2014-07-24 18:03, Josh Howlett wrote: > Hi Leif, > >> Fair enough but I believe your cure is much worse than the affliction of >> having to deal with SAML metadata. > > Could you elaborate? I think you are hoping for a way to establish canonical names for AAA-SAML entities based on properties of the endpoint that makes the name unique. I believe that will be ultimately a fruitless exercise and I believe the practice of SAML metadata management doesn't introduce enough pain to warrant introducing a complex naming scheme for endpoints to avoid it (if that is indeed your proposal). The normal approach for a SAML binding would be to define a Binding URI for the new endpoint. The signature on SAML metadata would provide name2key binding between the entityID and the Binding element. This approach requires a URI representation of EAP endpoints but I assume that wouldn't be hard. What is wrong with that approach and what (if any) problems remain if we choose to go that way for ABFAB? Cheers Leif From nobody Thu Jul 24 09:19:09 2014 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 55C521A0366 for ; Thu, 24 Jul 2014 09:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 0RQwb0W3qNZV for ; Thu, 24 Jul 2014 09:19:02 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE261A0199 for ; Thu, 24 Jul 2014 09:19:01 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so33272wiv.4 for ; Thu, 24 Jul 2014 09:19:00 -0700 (PDT) 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=NRtRvHxA0ZCEl04kWHSVaAIcvrG4PxLnwTbC+/DMM4M=; b=Ky6X/rEQ16AQgT4zzYKYxltv9s8M9quDU9CdukqoYhqs/BXS0cXqQ+hzKxsOYKLXcS DaqeZcSldslLlqL8grZNJ6bEzMsC7Fnm75OGxvyNd9LBRyapJz/ji4jFlE4/1ZKf5Uof rXcd3KMu34Pm90qNP539NPh68mB4e+MR/c5lmoqwBO0Syadb3iU5FhtlSTo9vq5eyr4e 2VznqpS57+8R1f3sLcceE/8AmOp2ac3m3QcsXlO5LMuCrAb+38IongogAwlnOXs/zPa2 2kBGQjmhOMLvbHfEpOCs9+zuCjT44gfT4lrg5Q70rZ754n+WMXBFsoN8hiszKLc/LCdU u6SA== X-Gm-Message-State: ALoCoQnxPfogHLydrcL/ETkn0YJJiuAfZlo8hUnsASDTYh790f908B2+TMFq2csf5YAdHZBJ6N5i X-Received: by 10.180.108.13 with SMTP id hg13mr7101275wib.28.1406218740235; Thu, 24 Jul 2014 09:19:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:35b5:42f4:844b:de48? ([2001:67c:370:152:35b5:42f4:844b:de48]) by mx.google.com with ESMTPSA id cd1sm17095027wjc.19.2014.07.24.09.18.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jul 2014 09:18:59 -0700 (PDT) Message-ID: <53D131F1.4090801@mnt.se> Date: Thu, 24 Jul 2014 18:18:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: abfab@ietf.org References: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> <53D12C37.20309@mnt.se> <55DC663C2F4F9F439F23543E0078E8B3A67AB8A3@EXC001> <53D1319A.10008@sunet.se> In-Reply-To: <53D1319A.10008@sunet.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/Ags-PI7cZdW49MBbJbVuBbawyQg Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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, 24 Jul 2014 16:19:03 -0000 > name2key binding between the entityID and the Binding element. This > approach requires a URI representation of EAP endpoints but I assume > that wouldn't be hard. s/name2key//g From nobody Fri Jul 25 08:40:18 2014 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 44E151B2925 for ; Fri, 25 Jul 2014 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8glmRqvTe8Qb for ; Fri, 25 Jul 2014 08:40:14 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2F11B2912 for ; Fri, 25 Jul 2014 08:40:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1897C20186; Fri, 25 Jul 2014 11:37:22 -0400 (EDT) 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 WlYe3vW7UTPZ; Fri, 25 Jul 2014 11:37:21 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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, 25 Jul 2014 11:37:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 06B1E81C12; Fri, 25 Jul 2014 11:40:11 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: <55DC663C2F4F9F439F23543E0078E8B3A67AA744@EXC001> Date: Fri, 25 Jul 2014 11:40:11 -0400 In-Reply-To: (Scott Cantor's message of "Thu, 24 Jul 2014 16:04:31 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/0GEgUvLeovIebSofJAAXa-BKTdc Cc: "abfab@ietf.org" Subject: Re: [abfab] Significant concerns about aaa-saml presentation 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: Fri, 25 Jul 2014 15:40:16 -0000 So, What I think we need to say in the SAML is: In an assertion: 1) I expect the foo.bar.example.com IDP realm to interact with this message. 2) Possibly/probably I expect the baz.example.net RP realm to receive this message eventually. I'm happy to let the RP evaluate the trust of the AAA fabric between the IDP and RP and to evaluate whether the fabric in use provides sufficient trust for the IDP. I think it's important make sure the message was intended to be handed to the given IDP and probably/possibly/I'm not 100% sure to make sure the message was destined for the given RP. It's clear that we need to make sure the destination of the message at the SAML layer, but possibly not at the AAA layer. However, we definitely care about the injection point into the AAA layer because that may be the only AAA name towards the IDP that the RP knows and can validate. --Sam