From nobody Mon Mar 3 17:09:34 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 C5C891A022A for ; Mon, 3 Mar 2014 17:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, SPF_PASS=-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 PzROD7CQ8ehT for ; Mon, 3 Mar 2014 17:09:27 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3102A1A02C3 for ; Mon, 3 Mar 2014 17:08:31 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id m20so4346697qcx.21 for ; Mon, 03 Mar 2014 17:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=eHC33iP8XkKaB7r9ScJ9BWC0QB4UZII9LGpDX7Y0vOY=; b=pljD5eZMZF/18knwxZQc0SHltn/uORYRO3kczVrn//4QPOm+uAP06AXpRAbi8XonvV DeVCEQXzZnWyGXNiXi/mT+teEinbjn2i1ASnmfjzLmGBvVxjL84oS8t+SjUeJX+2Ms4Y LiLApCpw5I0lWhsvFsVqCugQjmCyEdbY73fC2cgFFDZpAiRJ74wqjaXruv+DCRVDWiWm US60xMtgqqJ0NgV/xynZHPtrCI0FD2sUlp2/M51gqe4JQASy6jqsIPZHKJeNUi+RzhrQ 7n5Jk/R/OLG0sbo9eo9nIJGZmI7bAthz8mdBOEnrhIINvyliDkXzvvrLRNLcorZho9RG LXqQ== MIME-Version: 1.0 X-Received: by 10.224.167.80 with SMTP id p16mr18351013qay.62.1393895307828; Mon, 03 Mar 2014 17:08:27 -0800 (PST) Sender: kevin.r.wasserman@gmail.com Received: by 10.140.39.11 with HTTP; Mon, 3 Mar 2014 17:08:27 -0800 (PST) Date: Mon, 3 Mar 2014 20:08:27 -0500 X-Google-Sender-Auth: UBJQSG31htNiahdjBrwwc8uPyq0 Message-ID: From: Kevin Wasserman To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/GBPv2YpEYfRZ3-yawqqOfNCyZqg Subject: [abfab] Comments on draft-ietf-abfab-usability-ui-considerations-00.txt 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, 04 Mar 2014 01:09:30 -0000 Sorry for the lateness; hopefully these comments may still be useful. Overall the draft is very clear and logical. 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. 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? 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? 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 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"? 7. "This potentially complex many-to-many association between is not easily comprehended by the user" Should be "...between identities and services" 8. "can really effect" should be "can really affect" Kevin Wasserman Painless Security, LLC From nobody Mon Mar 3 19:03:49 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 00F631A02DF for ; Mon, 3 Mar 2014 19:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 npRSaMdNrSeg for ; Mon, 3 Mar 2014 19:03:42 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3522D1A0126 for ; Mon, 3 Mar 2014 19:03:41 -0800 (PST) Received: from mail190-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 03:03:38 +0000 Received: from mail190-va3 (localhost [127.0.0.1]) by mail190-va3-R.bigfish.com (Postfix) with ESMTP id 7D3823400D2 for ; Tue, 4 Mar 2014 03:03:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: VPS7(z579ehf7Izd772hzz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz31izz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch1b1cn1b1bi1155h) Received-SPF: pass (mail190-va3: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail190-va3 (localhost.localdomain [127.0.0.1]) by mail190-va3 (MessageSwitch) id 1393902215935296_8915; Tue, 4 Mar 2014 03:03:35 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.240]) by mail190-va3.bigfish.com (Postfix) with ESMTP id CD93D48008F for ; Tue, 4 Mar 2014 03:03:35 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 03:03:35 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id E4D292E0079 for ; Mon, 3 Mar 2014 22:03:34 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0174.001; Mon, 3 Mar 2014 22:03:34 -0500 From: "Cantor, Scott" To: "" Thread-Topic: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt Thread-Index: AQHPN1ZUGfEijGS6jEeSGs8zPDlDCw== Date: Tue, 4 Mar 2014 03:03:34 +0000 Message-ID: References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> In-Reply-To: <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> 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: <1265829DB32FB44491611C233A17A02C@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% Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/CXlHw4KFo6hb5mG1PNj4-xXddGg Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt 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, 04 Mar 2014 03:03:48 -0000 Some additional review... Big question: how much to do with ABFAB does this really have, vs. essentially any really usable client UI for a non-trivial GSS-API mechanism? More to the point, is this open to contributions from other perspectives to broaden the document's applicability? I got the sense that other than mentioning an NAI a fair bit, there's not much specific to ABFAB here. Section 3: Is the trust anchor about verifying a service, or about verifying the authentication service (avoiding the "IdP" term, but you know what I mean)? I thought the latter, and that service verification was a by-product of ABFAB being a mutual-auth mech. Think this text could be clearer if so. Section 4: Starts awkwardly. Suggest excising the first clause ("When using the ABFAB architecture to perform federated authentication to some service,") It specifically says you're not trying to recommend the use of "identity selector" as a term, but the document sure focuses on that term. Is there a good reason not to recommend that? Or are you talking mostly about how a user would perceive it? Still seems like unifying that makes sense; the web is helped by the fact that the thing you use to access it is "a browser". Section 6.3 I suggest reconsidering the use of "provisioning" here. It's a well-understood term, even in this exact context of provisioning, say, wireless authentication info, into clients. I think it's fine to use it. Section 6.3.2: Implies a free lunch: "In this case, trust anchors could be directly provided through the provisioning mechanism to help establish the trust relationship in a secure manner." If there were actually any way to do that, you'd already have the trust anchors. This just moves the problem to a different set of trust anchors. Section 6.3.3: I can't really see the norm being auto-provisioning the password itself into clients. I would think it much more likely the password would be left out of that step and the user would enter it then or later, so there's no confusion likely. Maybe this is tied up with the need for a way to verify identities provisioned into the selector. Section 6.5: Is it really impossible to verify identities somehow? Authentication at least should be verifiable; it certainly would be with other federated mechanisms. Section 7: Delving firmly into opinion, consider that familiar apps like mail and IM clients all feature the multiple account dialog these days. On the one hand, it seems like success depends on an ABFAB "identity" being yet another account option in those apps. Maybe that needs some discussion. If it's not possible to hope for this, why not? And why shouldn't that raise red flags for me as a reader? How has this worked or not worked for, say, Kerberos? Can we learn anything from that? -- Scott From nobody Tue Mar 4 07:55:01 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 ACABB1A0194 for ; Tue, 4 Mar 2014 07:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 tRIOqwVYK8FS for ; Tue, 4 Mar 2014 07:54:47 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E563F1A0202 for ; Tue, 4 Mar 2014 07:54:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id F1ABE206A6 for ; Tue, 4 Mar 2014 10:50:17 -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 F4Zv5sY1aj2P for ; Tue, 4 Mar 2014 10:50:17 -0500 (EST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org [31.133.165.38]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mark@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA for ; Tue, 4 Mar 2014 10:50:17 -0500 (EST) Message-ID: <5315F73D.4030709@painless-security.com> Date: Tue, 04 Mar 2014 15:54:37 +0000 From: Mark Donnelly User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: abfab@ietf.org References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> In-Reply-To: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/G9PNW6x2UmxtuNlJfTDF-J3vjfg Subject: [abfab] Comments on draft-ietf-abfab-usability-ui-considerations-00.txt 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, 04 Mar 2014 15:54:49 -0000 Hey all: 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. * Section 7.5 contains, "...to identify which the identity is used..." The word "the" should be removed. 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! * 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. 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? * 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). * 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. Cheers, --Mark From nobody Wed Mar 5 13:30:32 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 233041A076A for ; Wed, 5 Mar 2014 13:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 z5ryPdu2tYcE for ; Wed, 5 Mar 2014 13:30:29 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE41A074D for ; Wed, 5 Mar 2014 13:30:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 17A90206A8; Wed, 5 Mar 2014 16:25:57 -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 9RjyaRQWGJMO; Wed, 5 Mar 2014 16:25:56 -0500 (EST) Received: from [130.129.153.179] (unknown [130.129.153.179]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mark@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA; Wed, 5 Mar 2014 16:25:56 -0500 (EST) Message-ID: <5317976E.8010606@painless-security.com> Date: Wed, 05 Mar 2014 21:30:22 +0000 From: Mark Donnelly User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kevin Wasserman , abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/cUVqOiDwTQhnai6CAGbGNsOhZD8 Subject: Re: [abfab] Comments on draft-ietf-abfab-usability-ui-considerations-00.txt 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, 05 Mar 2014 21:30:31 -0000 On 3/4/2014 1:08 AM, Kevin Wasserman wrote: > 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? Oh, and further - what if you're using multiple services, with different identities, at the same time? -- Cheers, --Mark From nobody Thu Mar 6 23:19: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 7A3C71A0239 for ; Thu, 6 Mar 2014 23:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 l57lodmF-I-1 for ; Thu, 6 Mar 2014 23:18:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 513F01A0200 for ; Thu, 6 Mar 2014 23:18:59 -0800 (PST) Received: from [192.168.0.2] (client-82-26-219-147.pete.adsl.virginm.net [82.26.219.147]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s277Ih0p024614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 23:18:49 -0800 Message-ID: <53197290.9050905@dcrocker.net> Date: Fri, 07 Mar 2014 07:17:36 +0000 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rhys Smith , "" References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 06 Mar 2014 23:18:50 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/cC8Crw7OrCugUeQ2M9f9OwYaUUs Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 07:19:01 -0000 On 3/4/2014 3:03 AM, Cantor, Scott wrote: > Big question: how much to do with ABFAB does this really have, vs. > essentially any really usable client UI for a non-trivial GSS-API > mechanism? More to the point, is this open to contributions from other > perspectives to broaden the document's applicability? I got the sense that > other than mentioning an NAI a fair bit, there's not much specific to > ABFAB here. Nicely phrased. To carry it further: Usability is very difficult specialty, often finding that counter-intuitive results are best. My standard example is that we typically assume it is always better to give users more information, but in fact it isn't. (Think of the classic Bell curve. Hitting the statistical peak, for users' cognitive load, means not too little information and not too much.) Although entirely well-intentioned, the draft suffers from either offering very generic suggestions, such as: "Implementers of an identity selector will need to carefully consider their intended audience..." or very specific advice that is given without empirical justification and possibly contrary to empirical evidence, such as: "Friendly icon for identity: To allow the user to differentiate between the set of identities they have they should be able to set an icon for that particular identity." I chose that latter example because it is so obviously reasonable; it's difficult to believe that it's not a good suggestion. However my understanding is that users often are actually delayed or confused by designs with icon usage, like this, that hasn't first been tested for efficacy. So, sometimes, the icons are a good idea. Sometimes they aren't. Guidance about making the choice is where the hard work is. The draft offers no citations for HCI, UX, UCD or Usec research or experience. That's an indication that it has the best of intentions, but lacks both theoretical and empirical underpinnings, for a topic that is acknowledged by its leaders to require both, when doing design. And as difficult as usability is generally, it is much worse for usable security... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 7 01:27:28 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 C06BC1A0175 for ; Fri, 7 Mar 2014 01:27:26 -0800 (PST) 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 92DWyJOB76Lu for ; Fri, 7 Mar 2014 01:27:23 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) by ietfa.amsl.com (Postfix) with ESMTP id D2BD11A0164 for ; Fri, 7 Mar 2014 01:27:22 -0800 (PST) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB133.eurprd02.prod.outlook.com (10.242.93.14) with Microsoft SMTP Server (TLS) id 15.0.893.10; Fri, 7 Mar 2014 09:27:17 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.72]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.72]) with mapi id 15.00.0893.001; Fri, 7 Mar 2014 09:27:17 +0000 From: Rhys Smith To: "dcrocker@bbiw.net" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt Thread-Index: AQHPOeduJvaBOA1od02Z3jQgQuMmpw== Date: Fri, 7 Mar 2014 09:27:17 +0000 Message-ID: References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> <53197290.9050905@dcrocker.net> In-Reply-To: <53197290.9050905@dcrocker.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:152:810f:fae6:de25:8570] x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(252514010)(54164003)(479174003)(377454003)(24454002)(189002)(199002)(54356001)(79102001)(53806001)(2656002)(74366001)(87936001)(69226001)(56816005)(51856001)(90146001)(92566001)(95416001)(83072002)(97186001)(74876001)(77982001)(33656001)(97336001)(81542001)(59766001)(81342001)(85852003)(74482001)(95666003)(81816001)(83322001)(4396001)(31966008)(76796001)(63696002)(46102001)(47446002)(19580395003)(74502001)(50986001)(19580405001)(94946001)(74706001)(83716003)(92726001)(74662001)(36756003)(54316002)(82746002)(87266001)(77096001)(81686001)(80976001)(47976001)(86362001)(85306002)(76482001)(76786001)(93136001)(47736001)(49866001)(80022001)(56776001)(93516002)(94316002)(65816001)(3826001)(80792004); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR02MB133; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:2001:67c:370:152:810f:fae6:de25:8570; FPR:DCB2D005.87D293A1.A9F22DBB.CAE5E46A.2048C; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: cardiff.ac.uk does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_478D46FB-B8FA-4A32-BD74-CB0E945B276E"; 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/GnsFxMb9bXeBp9UH2G3KgH_f6Yw Cc: "" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt 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, 07 Mar 2014 09:27:27 -0000 --Apple-Mail=_478D46FB-B8FA-4A32-BD74-CB0E945B276E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 First, thanks to everyone for the feedback. I=92ll deal with all the = smaller comments. The one major comment is Scott=92s, and Dave=92s response. Can discuss = in the WG meeting later this morning. But my comments back would be - > On 3/4/2014 3:03 AM, Cantor, Scott wrote: >> Big question: how much to do with ABFAB does this really have, vs. >> essentially any really usable client UI for a non-trivial GSS-API >> mechanism? More to the point, is this open to contributions from = other >> perspectives to broaden the document's applicability? I got the sense = that >> other than mentioning an NAI a fair bit, there's not much specific to >> ABFAB here. My thought here is that yes, very little of it is ABFAB specific in that = sense. With relatively few modifications it could probably also provide = relevant guidance for other GSS-API mechs that would use an identity = selector-like thing. On 7 Mar 2014, at 07:17, Dave Crocker wrote: > [=85] > The draft offers no citations for HCI, UX, UCD or Usec research or = experience. That's an indication that it has the best of intentions, = but lacks both theoretical and empirical underpinnings, for a topic that = is acknowledged by its leaders to require both, when doing design. Short response - the draft currently is not really about recommending = design solutions, it=92s more about helping define the problem and = throwing in a few recommendations that we currently think look like best = practice. Longer respones - from our experience with UIs in the world of SAML = federations, there are two major things you can do to improve the UX: 1) = Improve the UI directly using established UX research (obviously), but = also 2) Consistency. To some extent, it doesn=92t *matter* how good or = bad the UI is as long as it=92s consistent across implementations. This paper is currently more addressing 2) than 1). It=92s simply an = attempt to pull together the scope of the problem of designing a UI = based on the experience we=92ve had in designing such a beast for = Moonshot (our ABFAB implementation). The aim is that others who might = come along and tread the same path can understand the scope of the = problem and our thought processes when producing an implementation, in = the hope that end users might benefit from having some commonality = between implementations.=20 Don=92t get me wrong, I=92m not saying that the other type of work is = not valuable; far from it. It=92s just that=92s a design specification = document is somewhat of a different doc from the considerations doc in = its current form and would require input from people more versed in the = current state of the art in UX design that me and the current reviewers = we=92ve had. Thinking through this, a few changes could probably be made to make this = a bit clearer - removing all normative keywords, for example, so that = we=92re not forcing design choices on implementors which may later prove = to be incorrect, wrong, or just plain stupid in hindsight=85 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=_478D46FB-B8FA-4A32-BD74-CB0E945B276E 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 iQIcBAEBCAAGBQJTGZDzAAoJEJzS5DEs203hjhcP/Amacz+rmbag8u1sy4hk7WEQ FnM+G7i4Z3EPquQvszjk0NHwwSPOjKMuAXwE0UsBG7xa2lmdpiaHUqIdLnntBw3d 9I1WUhuUFhVwKXGYRfxkYVXo3f7sqdX72G8u+tH0mCZj1pEb2a92/8eL4jJ8CaqA N3LDEd9VIz40/+cx+mWqV8rZN7JLckkGZLi3DLCz8kSzUC51BmbjTswaMT+apaDx DGrgxBWT5+A9iwjpoG901wcNHR2EihlX7CeKisDKyD+fJXIU17X96OQ7aYQsDjX+ PinZZzjBpUO/xE02IHjMqTSZ04pqkP5ScNDYIdCrAphFQNUA9E/9n3FV/OHKt9+e vULXsxmGKvekWWj2DEFppEBRNNCxnrpCwmsG8OC2mWiZtJlRUD9R0TigyUfyov3d +5FopMhb4xWGA1J6DtV9G0JhpbYVKIuncSJ23p1VeeGazXgzXpaXddMYUUFlcFu3 re31DFZTTRLphK+KOet2L26vIsCZi+tr86syQfX5DJXr3eILcb/iD2L4BZBexkEw srC5WRm2tE9tfiYJQjgAoiOCQVNTXJWkVHJ8igacZtwdW/M/4KbDIRVCiHHE8IHI 0aUHDp0dq4z/Bk6CiKuGVGFwZ20FJSs7rPlrS3PK1UxhSFAICi5piQCbP9MXTCQC 80Nr0wW4q10PgAwmW85P =uNzi -----END PGP SIGNATURE----- --Apple-Mail=_478D46FB-B8FA-4A32-BD74-CB0E945B276E-- From nobody Fri Mar 7 04:05:41 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 C4BFA1A0205 for ; Fri, 7 Mar 2014 04:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 dwxgCOwpD8DB for ; Fri, 7 Mar 2014 04:05:38 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 17FFF1A01EF for ; Fri, 7 Mar 2014 04:05:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3F0A9206AC for ; Fri, 7 Mar 2014 07:01:01 -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 JdIByWgxLogz for ; Fri, 7 Mar 2014 07:01:00 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9ca7.meeting.ietf.org [31.133.156.167]) (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 ; Fri, 7 Mar 2014 07:01:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D431583F0C; Fri, 7 Mar 2014 07:05:30 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Fri, 07 Mar 2014 07:05:30 -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 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/OwzshG27SiijfJ1nnTKuVaFkJMI Subject: [abfab] Authentication attributes and 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: Fri, 07 Mar 2014 12:05:39 -0000 Josh, the meeting was very confused about how aaa-saml interacts with the requirement from 2865 to have an authentication attribute in access-request. Where does that come up for this draft? --Sam From nobody Fri Mar 7 08:56:49 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 84C181A02BB for ; Fri, 7 Mar 2014 08:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 WV7t7EfIUl_6 for ; Fri, 7 Mar 2014 08:56:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9BD1A01E7 for ; Fri, 7 Mar 2014 08:56:39 -0800 (PST) Received: from [192.168.0.2] (client-82-26-219-147.pete.adsl.virginm.net [82.26.219.147]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s27GuKK4013028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Mar 2014 08:56:26 -0800 Message-ID: <5319F9F0.3080206@dcrocker.net> Date: Fri, 07 Mar 2014 16:55:12 +0000 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rhys Smith References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> <53197290.9050905@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 07 Mar 2014 08:56:27 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/ENgNwXNkE08ZljVnCZaCZJrvdVs Cc: "" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:56:41 -0000 Sorry I couldn't make the session. Inline... On 3/7/2014 9:27 AM, Rhys Smith wrote: > On 7 Mar 2014, at 07:17, Dave Crocker wrote: >> […] The draft offers no citations for HCI, UX, UCD or Usec research >> or experience. That's an indication that it has the best of >> intentions, but lacks both theoretical and empirical underpinnings, >> for a topic that is acknowledged by its leaders to require both, >> when doing design. > > Short response - the draft currently is not really about recommending > design solutions, it’s more about helping define the problem and > throwing in a few recommendations that we currently think look like > best practice. Calling for icons is a very specific design solution recommendation. > Longer respones - from our experience with UIs in the world of SAML > federations, there are two major things you can do to improve the UX: > 1) Improve the UI directly using established UX research (obviously), > but also 2) Consistency. To some extent, it doesn’t *matter* how good > or bad the UI is as long as it’s consistent across implementations. If you have studies on efficacy that are applicable, please include them. That something was /done/ might be interesting, but what is essential is a basis for judging whether it was /useful/. > This paper is currently more addressing 2) than 1). Oh? That would mean that there was a framework, rather than a varying list of different things to consider. It also means that the nature of the framework has some relevant field history so that its applicability to the current activity can be judged. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 12 01:18:41 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 022841A090D for ; Wed, 12 Mar 2014 01:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 vS-nMwT5xZhf for ; Wed, 12 Mar 2014 01:18:34 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 54DA41A08FA for ; Wed, 12 Mar 2014 01:18:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 7932F3FAAC for ; Wed, 12 Mar 2014 09:18:25 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nyUOo2eNYk+I for ; Wed, 12 Mar 2014 09:18:25 +0100 (CET) Received: from [155.54.205.49] (inf-205-49.inf.um.es [155.54.205.49]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 626853F806 for ; Wed, 12 Mar 2014 09:18:24 +0100 (CET) Message-ID: <53201850.2070702@um.es> Date: Wed, 12 Mar 2014 09:18:24 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060608030002000402040302" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/0c5JzUQnCowa5E06CQQSnD8Ua-4 Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 08:18:38 -0000 This is a multi-part message in MIME format. --------------060608030002000402040302 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Josh, the meeting was very confused about how aaa-saml interacts with > the requirement from 2865 to have an authentication attribute in > access-request. > > Where does that come up for this draft? Dear all, during last IETF meeting I had no chance to properly explain the issue with the ietf-abfab-aaa-saml and RFC 2865 due to some remote audio problems, thus I was requested to do it on the list. Let me complete Sam's question with further information. This issue is related with the one we had with our RADIUS fragmentation draft, and debated in RADEXT. However, I think that it may require a different solution than the one took for our draft, as they happen at different levels. RFC 2865 specifies that: An Access-Request MUST contain either a User-Password or a CHAP- Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password. This implies that an Access-Request packet will be invalid if it does not contain any authentication attribute. In section 7.3.2., ietf-abfab-aaa-saml defines how the RP uses a RADIUS Access-Request message to communicate with the IdP, prior the EU authentication, and provide the . In section 8.3.2, the contents of this Access-Request message are described as: * MUST use User-Name (not authentication attribute) * MUST include Service-Type = Authorize-Only (Not authentication attribute) * SHOULD include RADIUS State (authentication attribute, but not available when sent before the principal is authenticated; i.e. before EAP). Therefore, this message may not contain any authentication attribute, and therefore in those cases might be considered as invalid by entities following RFC 2865 to the letter. However, as RFC 2865 leaves the door open for new attributes to be considered as authentication, we think that a feasible solution for this issue would be declaring SAML-Message and/or the SAML-Assertion attributes as authentication attributes. We think this would make sense as as they might affect how the subsequent authentication process will be performed. Regards, Alejandro > --Sam > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------060608030002000402040302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Josh, the meeting was very confused about how aaa-saml interacts with
the requirement from 2865 to have an authentication attribute in
access-request.

Where does that come up for this draft?

Dear all,

during last IETF meeting I had no chance to properly explain the issue with the ietf-abfab-aaa-saml and RFC 2865 due to some remote audio problems, thus I was requested to do it on the list. Let me complete Sam's question with further information.

This issue is related with the one we had with our RADIUS fragmentation draft, and debated in RADEXT. However, I think that it may require a different solution than the one took for our draft, as they happen at different levels.

RFC 2865 specifies that:
An Access-Request MUST contain either a User-Password or a CHAP- Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password.
This implies that an Access-Request packet will be invalid if it does not contain any authentication attribute.

In section 7.3.2., ietf-abfab-aaa-saml defines how the RP uses a RADIUS Access-Request message to communicate with the IdP, prior the EU authentication, and provide the <samlp:AuthnRequest>. In section 8.3.2, the contents of this Access-Request message are described as:
  • MUST use User-Name (not authentication attribute)
  • MUST include Service-Type = Authorize-Only (Not authentication attribute)
  • SHOULD include RADIUS State (authentication attribute, but not available when sent before the principal is authenticated; i.e. before EAP).
Therefore, this message may not contain any authentication attribute, and therefore in those cases might be considered as invalid by entities following RFC 2865 to the letter.

However, as RFC 2865 leaves the door open for new attributes to be considered as authentication, we think that a feasible solution for this issue would be declaring SAML-Message and/or the SAML-Assertion attributes as authentication attributes. We think this would make sense as as they might affect how the subsequent authentication process will be performed.

Regards,
Alejandro

--Sam

_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab

--------------060608030002000402040302-- From nobody Wed Mar 12 06:19:06 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 AB1691A0994 for ; Wed, 12 Mar 2014 06:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 vvhEWZG8VrgS for ; Wed, 12 Mar 2014 06:19:04 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DE2B41A0960 for ; Wed, 12 Mar 2014 06:19:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4B96920687; Wed, 12 Mar 2014 09:14:12 -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 OS4EXFSD26sp; Wed, 12 Mar 2014 09:14:12 -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; Wed, 12 Mar 2014 09:14:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CA3A383F58; Wed, 12 Mar 2014 09:18:55 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <53201850.2070702@um.es> Date: Wed, 12 Mar 2014 09:18:55 -0400 In-Reply-To: <53201850.2070702@um.es> (Alejandro Perez Mendez's message of "Wed, 12 Mar 2014 09:18:24 +0100") 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 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/CXOcc07KCAk1niyo1Z5w6boz5Hk Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 13:19:05 -0000 We're discussing section 8 of draft-ietf-abfab-aaa-saml. > this issue would be declaring SAML-Message and/or the SAML-Assertion > attributes as authentication attributes. We think this would make sense > as as they might affect how the subsequent authentication process will > be performed. I don't support that approach mostly because it assumes there will be subsiquent authentication. If there is such I'd expect eap-message or similar to be present in the radius access-request My recommendation is that we indicate in section 8 that this draft only covers the case where the request in in the context of an existing session and includes state. In future, the profile can be expanded. I'd probably leave state as a SHOULD with a note about 2865 and indicate that if you're using this profile without state you need a spec describing how to do that and that spec needs to tell you what authentication attributes to include. --Sam From nobody Wed Mar 12 07:20:40 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 1D6F81A07F4 for ; Wed, 12 Mar 2014 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 pE1ZVmfoiqj4 for ; Wed, 12 Mar 2014 07:20:33 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB951A06B2 for ; Wed, 12 Mar 2014 07:20:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 8175EEAA; Wed, 12 Mar 2014 15:20:25 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OnfUaPDjFCMu; Wed, 12 Mar 2014 15:20:25 +0100 (CET) Received: from [10.42.0.19] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id C0DD249; Wed, 12 Mar 2014 15:20:23 +0100 (CET) Message-ID: <53206D26.2000106@um.es> Date: Wed, 12 Mar 2014 15:20:22 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sam Hartman References: <53201850.2070702@um.es> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/jphcMcCxzjcoVMiiQsmlq4sIGoI Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 14:20:39 -0000 El 12/03/14 14:18, Sam Hartman escribió: > We're discussing section 8 of draft-ietf-abfab-aaa-saml. > >> this issue would be declaring SAML-Message and/or the SAML-Assertion >> attributes as authentication attributes. We think this would make sense >> as as they might affect how the subsequent authentication process will >> be performed. > I don't support that approach mostly because it assumes there will be > subsiquent authentication. If there is such I'd expect eap-message or > similar to be present in the radius access-request Following Alan's suggestions, we decided for our draft that it was better to do not mix things up and keep RADIUS-EAP (and other authenticaiton mechanisms) completely unmodified. > My recommendation is that we indicate in section 8 that this draft only > covers the case where the request in in the context of an existing > session and includes state. > In future, the profile can be expanded. I'd probably leave state as a > SHOULD with a note about 2865 and indicate that if you're using this > profile without state you need a spec describing how to do that and that > spec needs to tell you what authentication attributes to include. > > --Sam From nobody Wed Mar 12 07:22:25 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 DA3EB1A070A for ; Wed, 12 Mar 2014 07:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 qQzgtsTg4ZUg for ; Wed, 12 Mar 2014 07:22:17 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D6FF31A06B2 for ; Wed, 12 Mar 2014 07:22:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4BCB4206B3; Wed, 12 Mar 2014 10:17:26 -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 EYIn3GgaZaiJ; Wed, 12 Mar 2014 10:17:25 -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; Wed, 12 Mar 2014 10:17:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9620883F58; Wed, 12 Mar 2014 10:22:09 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <53201850.2070702@um.es> <53206D26.2000106@um.es> Date: Wed, 12 Mar 2014 10:22:09 -0400 In-Reply-To: <53206D26.2000106@um.es> (Alejandro Perez Mendez's message of "Wed, 12 Mar 2014 15:20:22 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/Q-u5LRpumGQx9M77WYiMJWGGmwI Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 14:22:22 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> El 12/03/14 14:18, Sam Hartman escribió: >> We're discussing section 8 of draft-ietf-abfab-aaa-saml. >> >>> this issue would be declaring SAML-Message and/or the >>> SAML-Assertion attributes as authentication attributes. We think >>> this would make sense as as they might affect how the subsequent >>> authentication process will be performed. >> I don't support that approach mostly because it assumes there >> will be subsiquent authentication. If there is such I'd expect >> eap-message or similar to be present in the radius access-request Alejandro> Following Alan's suggestions, we decided for our draft Alejandro> that it was better to do not mix things up and keep Alejandro> RADIUS-EAP (and other authenticaiton mechanisms) Alejandro> completely unmodified. Right. I don't understand how that applies to aaa-saml. From nobody Wed Mar 12 07:30:55 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 9E0DF1A0804 for ; Wed, 12 Mar 2014 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 0EOLXKKflDGG for ; Wed, 12 Mar 2014 07:30:49 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E41A0727 for ; Wed, 12 Mar 2014 07:30:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id CD340B7E6; Wed, 12 Mar 2014 15:30:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h5d1g1JCYjzN; Wed, 12 Mar 2014 15:30:28 +0100 (CET) Received: from [155.54.205.226] (inf-205-226.inf.um.es [155.54.205.226]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon24.um.es (Postfix) with ESMTPSA id E6C5B1D0F; Wed, 12 Mar 2014 15:30:27 +0100 (CET) Message-ID: <53206F83.9070000@um.es> Date: Wed, 12 Mar 2014 15:30:27 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sam Hartman , Alejandro Perez Mendez References: <53201850.2070702@um.es> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=8D119153 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WAdbOEVeXunv6mw9JNj8NM3bmP1X5Vpld" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/SzeAjD14AA1tjUWT2DyIzZiRl58 Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 14:30:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WAdbOEVeXunv6mw9JNj8NM3bmP1X5Vpld Content-Type: multipart/mixed; boundary="------------070807030909090402070103" This is a multi-part message in MIME format. --------------070807030909090402070103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sam, On 03/12/2014 02:18 PM, Sam Hartman wrote: > We're discussing section 8 of draft-ietf-abfab-aaa-saml. >=20 >> this issue would be declaring SAML-Message and/or the SAML-Assertion= >> attributes as authentication attributes. We think this would make se= nse >> as as they might affect how the subsequent authentication process wi= ll >> be performed. >=20 >=20 > I don't support that approach mostly because it assumes there will be > subsiquent authentication. If there is such I'd expect eap-message or > similar to be present in the radius access-request >=20 > My recommendation is that we indicate in section 8 that this draft only= > covers the case where the request in in the context of an existing > session and includes state. What's about an initial SAMLAuthRequest from the RP to the idP (before the EAP exchange) pointing out, for example, some kind of LoA requirement? I though it was one of the motivations for the use of SAML here. In this case there is not a "state" attribute. Regards, Gabi. > In future, the profile can be expanded. I'd probably leave state as a > SHOULD with a note about 2865 and indicate that if you're using this > profile without state you need a spec describing how to do that and tha= t > spec needs to tell you what authentication attributes to include. > =09 > --Sam >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab >=20 --=20 Gabriel L=F3pez Mill=E1n, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888504 Fax: +34868884151 e-mail: gabilm@um.es --------------070807030909090402070103 Content-Type: application/pgp-keys; name="0x8D119153.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8D119153.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) 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+OMuAp4sCy7xRJqXziQE+BBMBAgAoBQJN nshIAhsvBQkSz/eABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDFGKqEjRGR U/FaB/9AtkdAyNqEp9X3ARkHm7GGaX8B4BLiYOy01OueLII7ImT467oj98t2Dkhn 42tkG+HS9LM5o/bLm1XUeBpQEpQ3VXwMBewHlahgd9bd5+CS2oOpCY0t9Ya6DIDk g3k1p5VDrrMc067u/+J12WpA/eYIL6xvjHZr/cl6ESq3M28DnviSLYW4N0M8gpSd WmMyQcOc9MlgjCkZ+AeYNPFQQtoKihOA7mfAh5b00SOEJWlmf8pBanB5jt/dNLmk YpJBUtHyXe8uvSHOATFgYI+O0nrYSnSBQHHVDyC2C6fIwL6MrzC+GsM7BmJn/Fys HeLi72gI3usFHQL28jnQ96esVFC/uQENBE2mqCUBCADSLo5gXbBkS/drtAf3nEVO aVy56cmruPfli/eZhEZT5vKNdW+5t1rUUa8wCTTiqv0yiLHwknU0ZeQhkK65ixQb 6NjqEnC1COfE5NBTA+hqanoUBST/dItWPB2fnhg16Emv1jSWxe19K7jgyGx2Cj56 l0b/Te3uxRhyXnqmlF9X2Wz+ntbvDPz7OtSaDiMb1hawdXLGxWE0AdPmZEvFHAXw EUQfIzW+i7OTdPJCo5eiIC+OsZTbBNs2pzsl6s5/2y+1/gnxtxF5Ep6BVk74tKJA BfQ8ntrzGY87uRrdoZ/BtYGet8jFZQUEesUj4rNojXj0Icbpl33oYB3VJbij1jxx ABEBAAGJASUEGAECAA8FAk2mqCUCGwwFCRLP94AACgkQxRiqhI0RkVOagAgA53T0 JwSatOY2i2CqGPJGZzs85oHjBTFrEDJ+Axc1JhsEZ8YPebjMOPHp5On/BgeoByTf PnA3DU9J9z4twq3nXpJeGLcB2+rGPCM5HPAd3ahbwj/S3xJ6T1EURCdINoHaJbKg 8Hu018S5VkSO76R8n8dFLPMY0Ed5MJq1SdySJSQyjtoOJe5BCgTcHZbpBDNXGIqI s+r8UbkLCcB4iiAS2l3AuaMHih0wPk5R/jDNrQzfCKr8phdNPXM/9rr8mdmMlQBh 8+AnlGcZyXbaLmk+aNRx8E2olRVa0ilnn0JZXsbWsafjwRr/7UOb6C6LHK5ctTHL MOUtgvBs+YvHTM36yw=3D=3D =3DcnPU -----END PGP PUBLIC KEY BLOCK----- --------------070807030909090402070103-- --WAdbOEVeXunv6mw9JNj8NM3bmP1X5Vpld Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIG+DAAoJEMUYqoSNEZFTTasH/ApwbzcxCAt5FYduKSblLes0 c9IKOc3PDOiAFMP6vuNCI8HUadilVzVNOPC4y2l9XB4Gx/KRyFxzob8F7FAuzvT4 w+Z8YYmAdAohT1oKM4RHoSEyqjBfyyCDjdQ48ijf6LjAtqys7t/sJq9e/Fx+6JoI 9Q0jQpTrR/2M0wL6oOTFOUN4/T70jHQ20u+GY1FJN6c6kaOdumwEHd+JuSKD0hIQ 9uuLbALsUujbaztbHpYSU3+h/8m/YHMb6kPDGzg31ZSyrF9NCwVc0wnVlZm3HA2T AycReoHwZPB7oyphy3b7TInEdGQEpOctUSJV2afgVQjncaIWm9F7Iu8MwJloFto= =P8yw -----END PGP SIGNATURE----- --WAdbOEVeXunv6mw9JNj8NM3bmP1X5Vpld-- From nobody Wed Mar 12 07:39: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 C74501A09A3 for ; Wed, 12 Mar 2014 07:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 atHTmR8LusZk for ; Wed, 12 Mar 2014 07:39:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7CF1A08AF for ; Wed, 12 Mar 2014 07:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DC38E20687; Wed, 12 Mar 2014 10:34:43 -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 yMIwZ31pHf06; Wed, 12 Mar 2014 10:34:43 -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; Wed, 12 Mar 2014 10:34:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4298283F58; Wed, 12 Mar 2014 10:39:27 -0400 (EDT) From: Sam Hartman To: Gabriel Lopez References: <53201850.2070702@um.es> <53206F83.9070000@um.es> Date: Wed, 12 Mar 2014 10:39:27 -0400 In-Reply-To: <53206F83.9070000@um.es> (Gabriel Lopez's message of "Wed, 12 Mar 2014 15:30:27 +0100") 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 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/ruoO4tIH88bGicczKf6ZAAGtBso Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 14:39:42 -0000 >>>>> "Gabriel" == Gabriel Lopez writes: Gabriel> What's about an initial SAMLAuthRequest from the RP to Gabriel> the idP (before the EAP exchange) pointing out, for Gabriel> example, some kind of LoA requirement? I though it was one Gabriel> of the motivations for the use of SAML here. In this case Gabriel> there is not a "state" attribute. That would be inconsistent with the profile described in section 8. That would be more consistent with the profile in section 7. There, though, I'd expect the SAML request and EAP message to be in the same initial access-request. From nobody Wed Mar 12 08:05:08 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 759FA1A08AF for ; Wed, 12 Mar 2014 08:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 eb1eDfvmDM9s for ; Wed, 12 Mar 2014 08:05:02 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA2D1A072C for ; Wed, 12 Mar 2014 08:05:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 3DB30B940; Wed, 12 Mar 2014 16:04:55 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vYAJOeUme8kF; Wed, 12 Mar 2014 16:04:55 +0100 (CET) Received: from [155.54.205.226] (inf-205-226.inf.um.es [155.54.205.226]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon23.um.es (Postfix) with ESMTPSA id 7D704B8A9; Wed, 12 Mar 2014 16:04:48 +0100 (CET) Message-ID: <53207790.8050603@um.es> Date: Wed, 12 Mar 2014 16:04:48 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sam Hartman References: <53201850.2070702@um.es> <53206F83.9070000@um.es> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=8D119153 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3PnBToPTBKitghAqsh1WEi0UJ3RUOK4pU" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/3OYqWyNzGKdG8vYvhcTXqVrT8TU Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 15:05:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3PnBToPTBKitghAqsh1WEi0UJ3RUOK4pU Content-Type: multipart/mixed; boundary="------------050602000607070901040901" This is a multi-part message in MIME format. --------------050602000607070901040901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/12/2014 03:39 PM, Sam Hartman wrote: >>>>>> "Gabriel" =3D=3D Gabriel Lopez writes: >=20 > Gabriel> What's about an initial SAMLAuthRequest from the RP to > Gabriel> the idP (before the EAP exchange) pointing out, for > Gabriel> example, some kind of LoA requirement? I though it was one= > Gabriel> of the motivations for the use of SAML here. In this case= > Gabriel> there is not a "state" attribute. >=20 > That would be inconsistent with the profile described in section 8. > That would be more consistent with the profile in section 7. right > There, though, I'd expect the SAML request and EAP message to be in the= > same initial access-request. ok, so what would happen if the SAMLAuthRequest has to be fragmented? the first message would include the EAP message? btw, Does It preclude the use of a pre-authorization exchange in this context? Regards, Gabi. >=20 --=20 Gabriel L=F3pez Mill=E1n, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888504 Fax: +34868884151 e-mail: gabilm@um.es --------------050602000607070901040901 Content-Type: application/pgp-keys; name="0x8D119153.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8D119153.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) 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+OMuAp4sCy7xRJqXziQE+BBMBAgAoBQJN nshIAhsvBQkSz/eABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDFGKqEjRGR U/FaB/9AtkdAyNqEp9X3ARkHm7GGaX8B4BLiYOy01OueLII7ImT467oj98t2Dkhn 42tkG+HS9LM5o/bLm1XUeBpQEpQ3VXwMBewHlahgd9bd5+CS2oOpCY0t9Ya6DIDk g3k1p5VDrrMc067u/+J12WpA/eYIL6xvjHZr/cl6ESq3M28DnviSLYW4N0M8gpSd WmMyQcOc9MlgjCkZ+AeYNPFQQtoKihOA7mfAh5b00SOEJWlmf8pBanB5jt/dNLmk YpJBUtHyXe8uvSHOATFgYI+O0nrYSnSBQHHVDyC2C6fIwL6MrzC+GsM7BmJn/Fys HeLi72gI3usFHQL28jnQ96esVFC/uQENBE2mqCUBCADSLo5gXbBkS/drtAf3nEVO aVy56cmruPfli/eZhEZT5vKNdW+5t1rUUa8wCTTiqv0yiLHwknU0ZeQhkK65ixQb 6NjqEnC1COfE5NBTA+hqanoUBST/dItWPB2fnhg16Emv1jSWxe19K7jgyGx2Cj56 l0b/Te3uxRhyXnqmlF9X2Wz+ntbvDPz7OtSaDiMb1hawdXLGxWE0AdPmZEvFHAXw EUQfIzW+i7OTdPJCo5eiIC+OsZTbBNs2pzsl6s5/2y+1/gnxtxF5Ep6BVk74tKJA BfQ8ntrzGY87uRrdoZ/BtYGet8jFZQUEesUj4rNojXj0Icbpl33oYB3VJbij1jxx ABEBAAGJASUEGAECAA8FAk2mqCUCGwwFCRLP94AACgkQxRiqhI0RkVOagAgA53T0 JwSatOY2i2CqGPJGZzs85oHjBTFrEDJ+Axc1JhsEZ8YPebjMOPHp5On/BgeoByTf PnA3DU9J9z4twq3nXpJeGLcB2+rGPCM5HPAd3ahbwj/S3xJ6T1EURCdINoHaJbKg 8Hu018S5VkSO76R8n8dFLPMY0Ed5MJq1SdySJSQyjtoOJe5BCgTcHZbpBDNXGIqI s+r8UbkLCcB4iiAS2l3AuaMHih0wPk5R/jDNrQzfCKr8phdNPXM/9rr8mdmMlQBh 8+AnlGcZyXbaLmk+aNRx8E2olRVa0ilnn0JZXsbWsafjwRr/7UOb6C6LHK5ctTHL MOUtgvBs+YvHTM36yw=3D=3D =3DcnPU -----END PGP PUBLIC KEY BLOCK----- --------------050602000607070901040901-- --3PnBToPTBKitghAqsh1WEi0UJ3RUOK4pU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIHeQAAoJEMUYqoSNEZFTLB8IAKu8/A1yX0HnSRJgK+wioi0q ae+Mvb6dFtLEQ4xe3Y51hJfzIw5idIPReO+myaM2GUvXF9tVqENPZEvg6r5B2ceU ZvUyZ1GJUXpbWRwSnA5sU5iMmodBfIywJLB4r2jVd+dS35BLrWaEkMvOI1WwsGNM z6byV8YiC4OibEkKrG/IrF0+TZDDBBzdTETDrAB6nXi0mAq0gjtJSgQmzBrZO4Gr XgJy7aXakHYv3IjqdpkKIjMPEIuJ0M0Q3xF/lUyiR1x+r2pi1qn/oe4mDnLMZrv3 BTbCGSs3vIiXf75Gq8ZNKjJscKfoZyHKi8lZDLOV7VnUGyEFwLU35XrddJp/QUs= =eaGv -----END PGP SIGNATURE----- --3PnBToPTBKitghAqsh1WEi0UJ3RUOK4pU-- From nobody Wed Mar 12 08:13:14 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 9F58F1A045D for ; Wed, 12 Mar 2014 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 mRvF2g_fsEkJ for ; Wed, 12 Mar 2014 08:13:07 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 570331A073C for ; Wed, 12 Mar 2014 08:13:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id B70DCB8A3; Wed, 12 Mar 2014 16:13:00 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vtADToqUsDom; Wed, 12 Mar 2014 16:13:00 +0100 (CET) Received: from [192.168.1.4] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 16ED6B8A2; Wed, 12 Mar 2014 16:12:59 +0100 (CET) Message-ID: <5320797A.6060706@um.es> Date: Wed, 12 Mar 2014 16:12:58 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sam Hartman References: <53201850.2070702@um.es> <53206D26.2000106@um.es> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/dPjDUyWJfdfXEsRo_fXHmXZSsNQ Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 15:13:12 -0000 El 12/03/14 15:22, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > Alejandro> El 12/03/14 14:18, Sam Hartman escribió: > >> We're discussing section 8 of draft-ietf-abfab-aaa-saml. > >> > >>> this issue would be declaring SAML-Message and/or the > >>> SAML-Assertion attributes as authentication attributes. We think > >>> this would make sense as as they might affect how the subsequent > >>> authentication process will be performed. > >> I don't support that approach mostly because it assumes there > >> will be subsiquent authentication. If there is such I'd expect > >> eap-message or similar to be present in the radius access-request > > Alejandro> Following Alan's suggestions, we decided for our draft > Alejandro> that it was better to do not mix things up and keep > Alejandro> RADIUS-EAP (and other authenticaiton mechanisms) > Alejandro> completely unmodified. > > Right. > I don't understand how that applies to aaa-saml. Because you are suggesting to include in the same packet EAP information with SAML. Am I wrong? Therefore, that would be against Alan's suggestion. From nobody Wed Mar 12 08:19:27 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 DC38B1A073C for ; Wed, 12 Mar 2014 08:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 Fm0JhMaOf4ly for ; Wed, 12 Mar 2014 08:19:11 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F41A046F for ; Wed, 12 Mar 2014 08:19:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 69EA738AA; Wed, 12 Mar 2014 16:18:58 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KZfplKYMQ-fX; Wed, 12 Mar 2014 16:18:58 +0100 (CET) Received: from inf-205-206.inf.um.es (inf-205-206.inf.um.es [155.54.205.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon22.um.es (Postfix) with ESMTPSA id 1D02E256C; Wed, 12 Mar 2014 16:18:57 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rafa Marin Lopez In-Reply-To: Date: Wed, 12 Mar 2014 16:18:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53201850.2070702@um.es> <53206F83.9070000@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/A6n3Rbizd-b6w2BHZCNJie5pU9Q Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 15:19:21 -0000 Hi Sam: Then, there will not be a "pre-authorization phase prior an = authentication" use case/profile in this draft, correct? I ask you this since you showed some time ago your interest in this case = (pre-authz prior authentication). I thought you had an use case/profile = in mind in the context of aaa-saml. Best Regards. El 12/03/2014, a las 15:39, Sam Hartman = escribi=F3: >>>>>> "Gabriel" =3D=3D Gabriel Lopez writes: >=20 > Gabriel> What's about an initial SAMLAuthRequest from the RP to > Gabriel> the idP (before the EAP exchange) pointing out, for > Gabriel> example, some kind of LoA requirement? I though it was one > Gabriel> of the motivations for the use of SAML here. In this case > Gabriel> there is not a "state" attribute. >=20 > That would be inconsistent with the profile described in section 8. > That would be more consistent with the profile in section 7. > There, though, I'd expect the SAML request and EAP message to be in = the > same initial access-request. >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Mar 12 08:27:17 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 634981A09A6 for ; Wed, 12 Mar 2014 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 Kf1lMoyM_cWG for ; Wed, 12 Mar 2014 08:27:10 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6151A074B for ; Wed, 12 Mar 2014 08:27:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BB589206B2; Wed, 12 Mar 2014 11:22:19 -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 ZU79j32TbAXq; Wed, 12 Mar 2014 11:22:19 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (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, 12 Mar 2014 11:22:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B97783F58; Wed, 12 Mar 2014 11:27:03 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <53201850.2070702@um.es> <53206F83.9070000@um.es> Date: Wed, 12 Mar 2014 11:27:03 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Wed, 12 Mar 2014 16:18:57 +0100") 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 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/6P1NvbaOcR_6zgcv19wmtxFaP7w Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 15:27:15 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: Then, there will not be a "pre-authorization phase Rafa> prior an authentication" use case/profile in this draft, Rafa> correct? If you need fragmentation, then you should follow the rules of draft-ietf-radext-radius-fragmentation. And there, yes the SAML would come before EAP, and you'd end up violating the MUST in 2865 as we discussed in radext last week. However, from the standpoint of draft-ietf-abfab-aaa-saml, by the time the fragmented packet is reassembled, but authentication and saml attributes will be present. My understanding of Alan's concern is that you didn't want to intermix fragmentation of authorization information with fragmentation of EAP. For example, you didn't want to have an EAP and SAML conversation going on at the same time. --Sam From nobody Wed Mar 12 08:33:15 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 5A28D1A074B for ; Wed, 12 Mar 2014 08:33:12 -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 v07o-wy5anbB for ; Wed, 12 Mar 2014 08:33:07 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63C1A045D for ; Wed, 12 Mar 2014 08:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C7D122240149; Wed, 12 Mar 2014 16:32:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhlReJlBI9rC; Wed, 12 Mar 2014 16:32:28 +0100 (CET) Received: from Thor.local (unknown [70.50.218.22]) by power.freeradius.org (Postfix) with ESMTPSA id 89B4B22400E6; Wed, 12 Mar 2014 16:32:28 +0100 (CET) Message-ID: <53207E0C.9040902@deployingradius.com> Date: Wed, 12 Mar 2014 11:32:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <53201850.2070702@um.es> <53206F83.9070000@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/ZUev4qMTUEvP4W6Fw1mTbIbklw0 Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 15:33:12 -0000 Sam Hartman wrote: > My understanding of Alan's concern is that you didn't want to intermix > fragmentation of authorization information with fragmentation of EAP. > For example, you didn't want to have an EAP and SAML conversation going > on at the same time. Yes. I would avoid that as much as possible. Alan DeKok. From nobody Wed Mar 12 09:05:49 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 CA8891A09D9 for ; Wed, 12 Mar 2014 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 mEaPWxNngB69 for ; Wed, 12 Mar 2014 09:05:40 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 076831A09CC for ; Wed, 12 Mar 2014 09:05:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 32A233FAAF; Wed, 12 Mar 2014 17:05:25 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TOIEcPxAe7Ja; Wed, 12 Mar 2014 17:05:25 +0100 (CET) Received: from inf-205-206.inf.um.es (inf-205-206.inf.um.es [155.54.205.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 964F23FAAD; Wed, 12 Mar 2014 17:05:24 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rafa Marin Lopez In-Reply-To: Date: Wed, 12 Mar 2014 17:05:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4479F8CC-B872-4273-AD95-55B93ABE3B51@um.es> References: <53201850.2070702@um.es> <53206F83.9070000@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/jKFhK6brEkBght_zBPAWDgXk9Vc Cc: abfab@ietf.org Subject: Re: [abfab] Authentication attributes and 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, 12 Mar 2014 16:05:46 -0000 Hi Sam El 12/03/2014, a las 16:27, Sam Hartman = escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: Then, there will not be a "pre-authorization phase > Rafa> prior an authentication" use case/profile in this draft, > Rafa> correct? >=20 > If you need fragmentation, then you should follow the rules of > draft-ietf-radext-radius-fragmentation. > And there, yes the SAML would come before EAP, and you'd end up > violating the MUST in 2865 as we discussed in radext last week. Yes, that is clear. >=20 > However, from the standpoint of draft-ietf-abfab-aaa-saml, by the time > the fragmented packet is reassembled, but authentication and saml > attributes will be present. So, in the end, there won't be pre-authz prior an authentication in = aaa-saml. That is what I wanted to make sure. Thanks. >=20 > My understanding of Alan's concern is that you didn't want to intermix > fragmentation of authorization information with fragmentation of EAP. > For example, you didn't want to have an EAP and SAML conversation = going > on at the same time. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------