From ietf@augustcellars.com Tue Sep 4 23:12:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFDA11E80E1 for ; Tue, 4 Sep 2012 23:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8O9HrwIlK87 for ; Tue, 4 Sep 2012 23:12:11 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2241511E80DE for ; Tue, 4 Sep 2012 23:12:10 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3E46E2C9BE; Tue, 4 Sep 2012 23:12:10 -0700 (PDT) From: "Jim Schaad" To: "'Joseph Salowey \(jsalowey\)'" , References: <3E8B557B-AC35-482E-9A32-79ACDABAC662@cisco.com> In-Reply-To: <3E8B557B-AC35-482E-9A32-79ACDABAC662@cisco.com> Date: Tue, 4 Sep 2012 23:10:47 -0700 Message-ID: <024901cd8b2d$322b4c60$9681e520$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlL1H+LS0RcfY48zy/MsNflhcC5ZZL+gPQ Content-Language: en-us Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:12:11 -0000 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, August 21, 2012 9:18 PM > To: abfab@ietf.org > Cc: Jim Schaad > Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt > > Hi Jim, > > Thanks for the review, > > Somehow I lost the original message so I've reproduced it from the archives > below: > > > Abstract. > > 1. Expand the EAP and ABFAB > > 2. Do you really want to talk about the use cases in the sentence? > > > > How about: > > "This document updates the Extensible Authentication Protocol (EAP) > applicability statement from RFC3748 to reflect recent usage of the EAP > protocol in the Application Bridging for Federated Access Beyond web > (ABFAB) working group." > Looks fine > > > Uses of EAP for Application-Layer Access 1. It is not clear to me > > that using channel bindings informs the peer what services are > > provided by an authenticator. What I think is given is that the peer > > can validate that A specific service is provided. > > > > [Joe] There is something wrong with the text, this should be better: > > "Without channel bindings, a peer cannot verify if an authenticator is > authorized to provide an advertised service. " > Looks good and I think matches what is in the architecture doc. > > > 2. para #2 says that which service is needed, but the previous > > paragraph is talking about different services not different qualities > > of a specific service. I don't think this follows well. > > > > 3. Swapping sentences 2 and 3 in para #2 might be reasonable - this > > describing that the quality of service can be important and then > > giving an example of why that is true. > > > > [Joe] ????? > > > 4. Do we have the ability to discuss the security implications in > > channel binding? In order for this to be true you need to have the > > ability to have a distinct name of the service between the low and > > high value versions of the same service. This would mean multiple names > for the "print" service. > > It is not clear that this is how people are going to do this. > > > > [Joe] You have to have some way of differentiating the types of services. > This could be by name or it could be by some other parameter. for example > you can have a print service with a confidential attribute which may be true > or false. There are many other approaches as well. I'm not sure that this is > the document that should detail this. > > > > 5. After reading this for a while, I think that part of my problem is > > that I am picking up a different meaning for the word service. I > > think of service as a print service, not of as "The high security > > print service running on machine foo.example.com". If this is the > > case then that might be the clarification that removes the above > comments. > > > > [Joe] OK, so would the following help: > > "However as additional services use EAP for authentication, the > distinction of which service is being contacted becomes more > important. Application services might have different properties. > Consider an environment with multiple printers some of which provide a > confidential service to output documents to a controlled location. If a peer > sent a document to the wrong service then potentially sensitive > information might be printed in an uncontrolled location and be disclosed. > In addition, it > might be more likely that a low-value service is compromised than > some high value service. If the high-value service could be > impersonated by a low-value service then the security of the overall > system would be limited by the security of the lower value service." > Yes I think that is much better > > 6. I think that you might talk about the cases where channel binding > > COULD be required even for network authentication. The fact that it > > is not required does not mean that it cannot be used. One issue is > > going to be how an IdP identifies a network authentication service > > from a different service for the purposes of deciding if channel binding is > going to be required. > > > > [Joe] I agree with the discussion on the list that says this is out of scope for > this document. Unhappy but I can live with it. > > > 7. Is it just important to prove that the EAP MSK is mutually held, > > or is it REQUIRED? What are the implications of not doing so? > > > > [Joe] REQUIRED, > > "It is REQUIRED for the application layer to prove possession of the > EAP MSK between the EAP Peer and EAP Authenticator. Failing to validate > the possession of the EAP MSK can allow an attacker to insert himself into > the conversation and impersonate the peer or authenticator. > Ok > > Security Considerations > > 1. When doing channel binding, it is highly desirable (required?) that > > the authenticator is not able to modify (and potentially to see?) the > > channel binding data passed from the peer to the authenticator (or > > reverse) as part of the authentication process. > > [Joe] I don't think confidentiality is required. How about: > > "When doing channel binding it is REQUIRED that the authenticator is not > able to modify the channel binding data passed between the peer to the > authenticator as part of the authentication process. " OK - I still worry about the possibility that the service will attempt to change its own name (parameters) based on the parameters passed from the peer to the authenticator, but this is probably an issue in my own head and may not be a real one. Jim From leifj@sunet.se Wed Sep 5 00:53:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF1E21F865C for ; Wed, 5 Sep 2012 00:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiQqGD8gin6I for ; Wed, 5 Sep 2012 00:53:31 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id 263B021F865B for ; Wed, 5 Sep 2012 00:53:30 -0700 (PDT) Received: from [145.96.3.16] (host-16-3.eduroamers.nl [145.96.3.16]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q857q661002891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 09:52:10 +0200 (CEST) Message-ID: <504704A6.5010200@sunet.se> Date: Wed, 05 Sep 2012 09:52:06 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: abfab@ietf.org References: <3E8B557B-AC35-482E-9A32-79ACDABAC662@cisco.com> <024901cd8b2d$322b4c60$9681e520$@augustcellars.com> In-Reply-To: <024901cd8b2d$322b4c60$9681e520$@augustcellars.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:53:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can we cut a new version soon-ish? Stuff is hanging on this... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBHBKYACgkQ8Jx8FtbMZndWogCeMwK06ZB/YxFQpWgd4wj+Zu0M CYUAoIVRT/NkXzQi4JcLIbaPu0oJnlsh =Qprg -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Thu Sep 6 01:49:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3AD21F8566 for ; Thu, 6 Sep 2012 01:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emXjQNFshmJ1 for ; Thu, 6 Sep 2012 01:49:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9651B21F853F for ; Thu, 6 Sep 2012 01:49:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 428FB171485 for ; Thu, 6 Sep 2012 09:49:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1346921349; bh=DrFyaFzwAGCTlRnl71TT/rMu 2jXAwIwmRcZgTHL5A9s=; b=vFYGr0ikKlm41Ztn+vtsE8KB7d8jtSK9Kagd4xYD AB6iuz5n80IkCdAA/SHkZyEi3S/utwv1hiHtEbFVXmykzWRD9bMIA3aSbdmD7Khh 4EHPDWpGkOkBq5cnVgoyGsJ1jMDAR1aCfo1aCfumf7jEJmDLxLs5kjnvwY7Zng96 h9ZDYNqc8EVreAgrWv+hHDRaUkkij2uM8GQd8AWYdlOOXUrkL0JaxgmTinrsEYeu QKFzaqpuRf/Uo13aFFpWfJHJ4k89HtS3A1fcaWyD49FVHOLuO8Pik+jDVo1rABg2 t92Kq8HndfqlMeS/Mgiac8AykaO6rqKZs7/cV4Zgko/y0g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id wrUmVLvDWLEB for ; Thu, 6 Sep 2012 09:49:09 +0100 (IST) Received: from [109.79.93.255] (unknown [109.79.93.255]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A561F17147B for ; Thu, 6 Sep 2012 09:49:09 +0100 (IST) Message-ID: <50486382.3050203@cs.tcd.ie> Date: Thu, 06 Sep 2012 09:49:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] AD review of draft-ietf-abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:49:14 -0000 Hi all, My review of this is below. I do think a couple of things at least(1st two) need fixing before IETF LC, so I'll mark this as revised ID needed unless you want to argue with me about that. Note that I sent an early version of this to the authors and chairs, and have incorporated some feedback I got from Sam below. Cheers, S. AD review of draft-ietf-abfab-gss-eap-naming-04 2012-09-06 General, but I think need fixing before IETF LC: - Examples are very very badly needed. Maybe some GSS calls and showing the values that'll be produced. - 6.2, can't there be more spaces after the first two in this case? Calling that out would seem better. General, comment-like: - As presented, this looks very complex. I think the presentation could do with work to make this an easier read. - Ought this be made specific to the currently known GSS mechtypes that use RADIUS or SAML? I mean for example a statment like "This specification only applies for GSS-EAP or SAML-EC." That might well simplify a lot of things since I reckon some of the complexity mentioned above comes from what might be premature generalisation. questions: - 2nd para of section 4: what does "MUST make a policy decision" mean? Maybe you mean that a service MUST have a way to decide which IdPs are trusted for which "asserted values"? (And what exactly are "asserted values"?) - How do I implement the "MUST NOT" in the last para of section 4? I'm told that's meant for mechanism spec. writers so making that clear would be good. "Closely associated" seems too vague. "Can assume" in the example also seems pretty vague. - Section 5, 1st para: what does "undefined" mean? If I call the relevant GSS function too early (before access-accept) what do I get? Maybe say here which GSS calls are meant? - 6.1, How can a GSS API extension spec assert that authentication only succeeds if the SAML or AAA exchange is successfully authenticated? Sam suggested: "This attribute MUST always be authenticated when present in mechanism names complying with this specification." which I think would be better. - 6.2: Maybe I need to check SAML again, but the " element's Name XML attribute" is used at the end of para 1, but later paras talks about the - are they the same or not? - 6.2: What does "sufficiently validated" mean? Adding more clarity here would be good. Sam suggested: "what we're saying or trying to say here is that a mechanism of GSS-EAP should mark attributes carried according to draft-ietf-abfab-aaa-saml as authenticated in the return from GSS_Get_Name_attribute without needing to do normal SAML validation." - 6.2: last sentence talks about "this assertion" buts its not clear to me if you mean the entire assertion or just the attribute? - 6.3: Why the SHOULD in the first para? - section 8, what is "paramname"? nits and whinges: - ID-nits complains about a few things. No show stoppers at this point but please fix after IETF LC. - worth calling out that %20 is not a separator in 2nd para of section 3? - Section 4, 2nd last para: whenever academics (like me:-) throw in "context" or "policy" alarm bells ought go off. Here you're saying a trust-context is a type of context and context is a property of an attribute. Don't you find that all a bit overly-generic? Then you say attributes with different contexts need different names. Does that mean that the name is also a property of the attribute? Is there no way to get rid of some of that veribage and reduce this to what a programmer needs to know? (Ok, you can feel free to ignore this, its just a whinge and I'm sorry;-) - section 8, all but 1st sentence of 1st para should go From ietf@augustcellars.com Fri Sep 7 16:41:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3057E21F85B1 for ; Fri, 7 Sep 2012 16:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn71PmV1BXII for ; Fri, 7 Sep 2012 16:41:35 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4B621F85C4 for ; Fri, 7 Sep 2012 16:41:35 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A06B92CA18; Fri, 7 Sep 2012 16:41:34 -0700 (PDT) From: "Jim Schaad" To: "'Stephen Farrell'" , References: <50486382.3050203@cs.tcd.ie> In-Reply-To: <50486382.3050203@cs.tcd.ie> Date: Fri, 7 Sep 2012 16:40:13 -0700 Message-ID: <039201cd8d52$209e1c80$61da5580$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMIFhmNSLM3iQno5RjCH6P4Wrin4ZUJ9wOQ Content-Language: en-us Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 23:41:36 -0000 Some comments inline > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, September 06, 2012 1:49 AM > To: > Subject: [abfab] AD review of draft-ietf-abfab-gss-eap-naming > > > Hi all, > > My review of this is below. I do think a couple of things at least(1st two) need > fixing before IETF LC, so I'll mark this as revised ID needed unless you want to > argue with me about that. > > Note that I sent an early version of this to the authors and chairs, and have > incorporated some feedback I got from Sam below. > > Cheers, > S. > > > AD review of draft-ietf-abfab-gss-eap-naming-04 > 2012-09-06 > > General, but I think need fixing before IETF LC: > > - Examples are very very badly needed. Maybe some GSS calls and showing > the values that'll be produced. > > - 6.2, can't there be more spaces after the first two in this case? Calling that > out would seem better. I am not sure what you mean here. It seems to me that we have Where are you planning to put the additional spaces? After the last string? It might be interesting to say if you could put multiple space characters in the location where the is, but that is not something that I would necessarily expect. Yes I think it would be reasonable to state that spaces in URIs must be encoded as %20, but I thought that was obvious, although it might be an error that I made at some point in the future if I just did a copy of the string from the XML to here without checking for embedded whitespace. > > General, comment-like: > > - As presented, this looks very complex. I think the presentation could do > with work to make this an easier read. In order to access this, I would need to know where you felt it was complex. At this point it is, for better or worse, rather easy to read. > > - Ought this be made specific to the currently known GSS mechtypes that use > RADIUS or SAML? I mean for example a statment like "This specification only > applies for GSS-EAP or SAML-EC." That might well simplify a lot of things since > I reckon some of the complexity mentioned above comes from what might > be premature generalisation. > > questions: > > - 2nd para of section 4: what does "MUST make a policy decision" mean? > Maybe you mean that a service MUST have a way to decide which IdPs are > trusted for which "asserted values"? (And what exactly are "asserted > values"?) Thus, a service MUST make a policy based decision: Is this IdP permitted to assert this attribute and is the value permitted. > > - How do I implement the "MUST NOT" in the last para of section 4? I'm told > that's meant for mechanism spec. writers so making that clear would be > good. "Closely associated" > seems too vague. "Can assume" in the example also seems pretty vague. I don't have good text here at this point. > > - Section 5, 1st para: what does "undefined" mean? If I call the relevant GSS > function too early (before access-accept) what do I get? Maybe say here > which GSS calls are meant? If you make the call too early, you might get an answer that would change after the access-accept message. You might get an error. We are not saying what the correct behavior is. While the current deployments are setup to just get information back, for Plasma we are looking at situations where we are going to want to ask more questions and the way to do this is not currently defined. > > - 6.1, How can a GSS API extension spec assert that authentication only > succeeds if the SAML or AAA exchange is successfully authenticated? Sam > suggested: "This attribute MUST always be authenticated when present in > mechanism names complying with this specification." which I think would be > better. > I had asked a similar question in the past, and I think that Sam's response is incorrect in that it does not match with what he told me in the past. There is a possibility that some mechanism will have a SAML statement it receives that it cannot authenticate either via the AAA exchange or by validating the signature on the SAML statement. In this case the attribute would not be returned as authenticated. However I would be willing for this behavior to be dropped. But given that we are talking about how to query for the attribute, I don't think that the suggested sentence from Sam would be correct. Perhaps 1. Make this a new paragraph 2. Updated text This attribute is authenticated only when the mechanism can successfully authenticated the SAML statement. For the GSS-EAP mechanism this is true if the AAA exchange has successfully authenticated. However, uses of the GSS-API MUST confirm that the attribute is marked authenticated as other mechanisms MAY permit an initiator to provide an unauthenticated SAML statement. > - 6.2: Maybe I need to check SAML again, but the " > element's Name XML attribute" is used at the end of para 1, but later paras > talks about the - are they the same or not? They are not the same. > > - 6.2: What does "sufficiently validated" mean? Adding more clarity here > would be good. Sam suggested: "what we're saying or trying to say here is > that a mechanism of GSS-EAP should mark attributes carried according to > draft-ietf-abfab-aaa-saml as authenticated in the return from > GSS_Get_Name_attribute without needing to do normal SAML validation." > That probably is what Sam said, not what he suggested as text. Text: In the GSS-EAP mechanism, a SAML assert carried in an integrity-protected and authenticated AAA protocol SHALL be considered successfully validated. > - 6.2: last sentence talks about "this assertion" buts its not clear to me if you > mean the entire assertion or just the attribute? I think that when Sam wrote the text he was thinking of the SAML assertion. I think however it would be more correct in the current content to substitute attribute for assertion as it needs to be clear than local policy may kill an attribute. I would suggest the following changes: 1. Add the following to the end of section 6.1 "An implementation MAY apply local policy checks to a SAML assertion and discard it if it fails the local policy checks." 2. Change the text at the end of section 6.2 to "An implementation MAY apply local policy checks to each attribute contained in a SAML assertion and discard the attribute if it fails the local policy checks. > > - 6.3: Why the SHOULD in the first para? A mechanism can choose not to expose some name forms to the acceptor. In this case the GSS name attribute would not be present. > > - section 8, what is "paramname"? If a parameter "paramname" is registered in this registry then its URN will be "urn:ietf:gss:paramname". > > nits and whinges: > > - ID-nits complains about a few things. No show stoppers at this point but > please fix after IETF LC. > > - worth calling out that %20 is not a separator in 2nd para of section 3? > > - Section 4, 2nd last para: whenever academics (like me:-) throw in "context" > or "policy" alarm bells ought go off. Here you're saying a trust-context is a > type of context and context is a property of an attribute. Don't you find that > all a bit overly-generic? Then you say attributes with different contexts need > different names. Does that mean that the name is also a property of the > attribute? Is there no way to get rid of some of that veribage and reduce this > to what a programmer needs to know? (Ok, you can feel free to ignore this, > its just a whinge and I'm sorry;-) > > - section 8, all but 1st sentence of 1st para should go > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From stephen.farrell@cs.tcd.ie Sun Sep 9 07:08:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEBF21F851A for ; Sun, 9 Sep 2012 07:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMZMf42zs+TW for ; Sun, 9 Sep 2012 07:08:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2921F843A for ; Sun, 9 Sep 2012 07:08:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A8658171478; Sun, 9 Sep 2012 15:08:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347199701; bh=k/46UbNpCSgnhk 71daX7iP8xnrJ1nRWFexo5kktfvQQ=; b=nABMYkclU9bWjs4lgOKvEcALBtuna3 go+y18YVKoox3TpgukqEAtH2Xf2X8oM8nmWdlYq4JoEVHjJEMT/ezRNA736Xf5Ha v3wAaKIVxNPUpy+T7JwAvn/cjsZMhDWIM9Doib9CqTAxdqtIOAQRBKuVQP60jjfn bThAZs3Srs0g/AAy40RsvgEjbGlZZ7LXilbP1KrhVygJo7puiN9DHRwGdoVvWHxS NzvIUav1tLr9OW8BiwvjI/sujiEvQeY1eo+pQjC3PVVZNpqzLLK7RTz1ZKf8VmDH dQer2CUoH/dEpwhhv0G5Mi78hDqPMJCzj71srhQQg2PR8G+MYoNRVNNg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id nvMNjamSnf-q; Sun, 9 Sep 2012 15:08:21 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.74.43]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0D11F171471; Sun, 9 Sep 2012 15:08:19 +0100 (IST) Message-ID: <504CA2D3.7000601@cs.tcd.ie> Date: Sun, 09 Sep 2012 15:08:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Jim Schaad References: <50486382.3050203@cs.tcd.ie> <039201cd8d52$209e1c80$61da5580$@augustcellars.com> In-Reply-To: <039201cd8d52$209e1c80$61da5580$@augustcellars.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 14:08:25 -0000 Hi Jim, On 09/08/2012 12:40 AM, Jim Schaad wrote: > Some comments inline > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, September 06, 2012 1:49 AM >> To: >> Subject: [abfab] AD review of draft-ietf-abfab-gss-eap-naming >> >> >> Hi all, >> >> My review of this is below. I do think a couple of things at least(1st > two) need >> fixing before IETF LC, so I'll mark this as revised ID needed unless you > want to >> argue with me about that. >> >> Note that I sent an early version of this to the authors and chairs, and > have >> incorporated some feedback I got from Sam below. >> >> Cheers, >> S. >> >> >> AD review of draft-ietf-abfab-gss-eap-naming-04 >> 2012-09-06 >> >> General, but I think need fixing before IETF LC: >> >> - Examples are very very badly needed. Maybe some GSS calls and showing >> the values that'll be produced. >> >> - 6.2, can't there be more spaces after the first two in this case? > Calling that >> out would seem better. > > I am not sure what you mean here. It seems to me that we have > The last string can have a space embedded in some cases I think. It says: "The final part is the element's Name XML attribute" which as I read it says this 3rd part is an XML attribute value, which can have spaces. If that's right then I think we need to tell coders about it. > > Where are you planning to put the additional spaces? After the last string? > It might be interesting to say if you could put multiple space characters in > the location where the is, but that is not something that I would > necessarily expect. > > Yes I think it would be reasonable to state that spaces in URIs must be > encoded as %20, but I thought that was obvious, although it might be an > error that I made at some point in the future if I just did a copy of the > string from the XML to here without checking for embedded whitespace. > >> >> General, comment-like: >> >> - As presented, this looks very complex. I think the presentation could do >> with work to make this an easier read. > > In order to access this, I would need to know where you felt it was complex. > At this point it is, for better or worse, rather easy to read. Our reading experiences differ then. If its just me then that's fine but I think (as I say below) that the attempt to be generic here causes fairly tortured language to be needed. I'll leave the rest of the comments for the list, since they're just comments and I'm not sure Jim is really talking to me so much as the list for some of 'em:-) Cheers, S. >> - Ought this be made specific to the currently known GSS mechtypes that > use >> RADIUS or SAML? I mean for example a statment like "This specification > only >> applies for GSS-EAP or SAML-EC." That might well simplify a lot of things > since >> I reckon some of the complexity mentioned above comes from what might >> be premature generalisation. >> >> questions: >> >> - 2nd para of section 4: what does "MUST make a policy decision" mean? >> Maybe you mean that a service MUST have a way to decide which IdPs are >> trusted for which "asserted values"? (And what exactly are "asserted >> values"?) > > Thus, a service MUST make a policy based decision: Is this IdP permitted to > assert this attribute and is the value permitted. > >> >> - How do I implement the "MUST NOT" in the last para of section 4? I'm > told >> that's meant for mechanism spec. writers so making that clear would be >> good. "Closely associated" >> seems too vague. "Can assume" in the example also seems pretty vague. > > > I don't have good text here at this point. > >> >> - Section 5, 1st para: what does "undefined" mean? If I call the relevant > GSS >> function too early (before access-accept) what do I get? Maybe say here >> which GSS calls are meant? > > If you make the call too early, you might get an answer that would change > after the access-accept message. You might get an error. We are not saying > what the correct behavior is. While the current deployments are setup to > just get information back, for Plasma we are looking at situations where we > are going to want to ask more questions and the way to do this is not > currently defined. > >> >> - 6.1, How can a GSS API extension spec assert that authentication only >> succeeds if the SAML or AAA exchange is successfully authenticated? Sam >> suggested: "This attribute MUST always be authenticated when present in >> mechanism names complying with this specification." which I think would be >> better. >> > > I had asked a similar question in the past, and I think that Sam's response > is incorrect in that it does not match with what he told me in the past. > There is a possibility that some mechanism will have a SAML statement it > receives that it cannot authenticate either via the AAA exchange or by > validating the signature on the SAML statement. In this case the attribute > would not be returned as authenticated. However I would be willing for this > behavior to be dropped. But given that we are talking about how to query > for the attribute, I don't think that the suggested sentence from Sam would > be correct. > > Perhaps > 1. Make this a new paragraph > 2. Updated text > > This attribute is authenticated only when the mechanism can successfully > authenticated the SAML statement. For the GSS-EAP mechanism this is true if > the AAA exchange has successfully authenticated. However, uses of the > GSS-API MUST confirm that the attribute is marked authenticated as other > mechanisms MAY permit an initiator to provide an unauthenticated SAML > statement. > >> - 6.2: Maybe I need to check SAML again, but the " >> element's Name XML attribute" is used at the end of para 1, but later > paras >> talks about the - are they the same or not? > > They are not the same. > >> >> - 6.2: What does "sufficiently validated" mean? Adding more clarity here >> would be good. Sam suggested: "what we're saying or trying to say here is >> that a mechanism of GSS-EAP should mark attributes carried according to >> draft-ietf-abfab-aaa-saml as authenticated in the return from >> GSS_Get_Name_attribute without needing to do normal SAML validation." >> > > That probably is what Sam said, not what he suggested as text. > > Text: In the GSS-EAP mechanism, a SAML assert carried in an > integrity-protected and authenticated AAA protocol SHALL be considered > successfully validated. > >> - 6.2: last sentence talks about "this assertion" buts its not clear to me > if you >> mean the entire assertion or just the attribute? > > I think that when Sam wrote the text he was thinking of the SAML assertion. > I think however it would be more correct in the current content to > substitute attribute for assertion as it needs to be clear than local policy > may kill an attribute. I would suggest the following changes: > > 1. Add the following to the end of section 6.1 > "An implementation MAY apply local policy checks to a SAML assertion and > discard it if it fails the local policy checks." > 2. Change the text at the end of section 6.2 to > "An implementation MAY apply local policy checks to each attribute > contained in a SAML assertion and discard the attribute if it fails the > local policy checks. > >> >> - 6.3: Why the SHOULD in the first para? > > A mechanism can choose not to expose some name forms to the acceptor. In > this case the GSS name attribute would not be present. > >> >> - section 8, what is "paramname"? > > If a parameter "paramname" is registered in this registry then its URN will > be "urn:ietf:gss:paramname". > > >> >> nits and whinges: >> >> - ID-nits complains about a few things. No show stoppers at this point but >> please fix after IETF LC. >> >> - worth calling out that %20 is not a separator in 2nd para of section 3? >> >> - Section 4, 2nd last para: whenever academics (like me:-) throw in > "context" >> or "policy" alarm bells ought go off. Here you're saying a trust-context > is a >> type of context and context is a property of an attribute. Don't you find > that >> all a bit overly-generic? Then you say attributes with different contexts > need >> different names. Does that mean that the name is also a property of the >> attribute? Is there no way to get rid of some of that veribage and reduce > this >> to what a programmer needs to know? (Ok, you can feel free to ignore this, >> its just a whinge and I'm sorry;-) >> >> - section 8, all but 1st sentence of 1st para should go >> >> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > > > From hartmans@mit.edu Thu Sep 13 07:58:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED721F8504 for ; Thu, 13 Sep 2012 07:58:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "Date" X-Spam-Flag: NO X-Spam-Score: 4.29 X-Spam-Level: **** X-Spam-Status: No, score=4.29 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, MISSING_DATE=0.001, MISSING_MID=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+BuJr3NAgVT for ; Thu, 13 Sep 2012 07:58:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5D46D21F84D6 for ; Thu, 13 Sep 2012 07:58:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C02E92010F for ; Thu, 13 Sep 2012 10:58:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 66D4B4149; Thu, 13 Sep 2012 10:58:04 -0400 (EDT) Resent-To: abfab@ietf.org Resent-From: Sam Hartman Resent-Date: Thu, 13 Sep 2012 10:58:04 -0400 Resent-Message-ID: X-From-Line: nobody Wed Sep 12 23:13:46 2012 From: Sam Hartman To: Stephen Farrell References: <50486382.3050203@cs.tcd.ie> In-Reply-To: <50486382.3050203@cs.tcd.ie> (Stephen Farrell's message of "Thu, 06 Sep 2012 09:49:06 +0100") User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 5 Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 13 Sep 2012 14:58:21 -0000 X-List-Received-Date: Thu, 13 Sep 2012 14:58:21 -0000 As a FYI, there has been action on this. I'm updating the Moonshot implementation to make sure it is consistent with this draft and with the approved draft-ietf-abfab-gss-eap so I can generate examples. Mostly done. One more change; hope to have examples Friday or this weekend. From lukeh@padl.com Sat Sep 15 20:02:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE2221E803F for ; Sat, 15 Sep 2012 20:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RL3+ytnlP3v for ; Sat, 15 Sep 2012 20:02:16 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 45EED21F84FC for ; Sat, 15 Sep 2012 20:02:16 -0700 (PDT) Received: by us.padl.com with ESMTP id q8G32Cw3020359; Sat, 15 Sep 2012 23:02:14 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Sun, 16 Sep 2012 13:02:09 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9658DB0A-58BA-44B3-B1B2-AF3C8C26CF31@padl.com> References: <4FA80F12-F592-4894-B6B5-107A1AD13C9F@padl.com> <54D29185-5D49-4BE8-9B66-F046809A2A1F@padl.com> To: "abfab@ietf.org" X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: [abfab] Capitalisation error in gss-eap-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 03:02:16 -0000 GSS-Acceptor-Service-specifics in 7.4 should probably be = GSS-Acceptor-Service-Specifics. -- Luke= From lukeh@padl.com Sat Sep 15 20:43:18 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C992C21E8047 for ; Sat, 15 Sep 2012 20:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVbczWfKZxhT for ; Sat, 15 Sep 2012 20:43:18 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1359C21E803F for ; Sat, 15 Sep 2012 20:43:17 -0700 (PDT) Received: by us.padl.com with ESMTP id q8G3h60q022095; Sat, 15 Sep 2012 23:43:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <9658DB0A-58BA-44B3-B1B2-AF3C8C26CF31@padl.com> Date: Sun, 16 Sep 2012 13:43:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA80F12-F592-4894-B6B5-107A1AD13C9F@padl.com> <54D29185-5D49-4BE8-9B66-F046809A2A1F@padl.com> <9658DB0A-58BA-44B3-B1B2-AF3C8C26CF31@padl.com> To: "abfab@ietf.org" X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [abfab] Capitalisation error in gss-eap-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 03:43:18 -0000 On 16/09/2012, at 1:02 PM, Luke Howard wrote: > GSS-Acceptor-Service-specifics in 7.4 should probably be = GSS-Acceptor-Service-Specifics. Also, s/(CRK.)/(CRK)./ -- misplaced full stop, I think. -- Luke= From hartmans@painless-security.com Wed Sep 19 11:44:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4758D21F855E for ; Wed, 19 Sep 2012 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.673 X-Spam-Level: **** X-Spam-Status: No, score=4.673 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_31=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfFzhT9vnI0l for ; Wed, 19 Sep 2012 11:44:47 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2921F855B for ; Wed, 19 Sep 2012 11:44:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7D4FE202A0; Wed, 19 Sep 2012 14:44:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C30A643E5; Wed, 19 Sep 2012 14:43:58 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <50486382.3050203@cs.tcd.ie> <039201cd8d52$209e1c80$61da5580$@augustcellars.com> Date: Wed, 19 Sep 2012 14:43:58 -0400 In-Reply-To: <039201cd8d52$209e1c80$61da5580$@augustcellars.com> (Jim Schaad's message of "Fri, 7 Sep 2012 16:40:13 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:44:48 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Some comments inline >> -----Original Message----- From: abfab-bounces@ietf.org >> - Examples are very very badly needed. Maybe some GSS calls and >> showing the values that'll be produced. >> I've tried to add some. >> >> - 6.2, can't there be more spaces after the first two in this >> case? Jim> Calling that >> out would seem better. Jim> I am not sure what you mean here. It seems to me that we have Jim> Jim> Where are you planning to put the additional spaces? After the Jim> last string? It might be interesting to say if you could put Jim> multiple space characters in the location where the is, Jim> but that is not something that I would necessarily expect. I agree with Stephen that the last string can for some name formats contain spaces. Text clarified. Tried to clarify this too. >> >> General, comment-like: >> >> - As presented, this looks very complex. I think the presentation >> could do with work to make this an easier read. Jim> In order to access this, I would need to know where you felt it Jim> was complex. At this point it is, for better or worse, rather Jim> easy to read. >> >> - Ought this be made specific to the currently known GSS >> mechtypes that Jim> use >> RADIUS or SAML? I mean for example a statment like "This >> specification Jim> only >> applies for GSS-EAP or SAML-EC." That might well simplify a lot >> of things Jim> since >> I reckon some of the complexity mentioned above comes from what >> might be premature generalisation. I think there's a huge cost for future applications if we do that and come up with related SAML mechanisms or stack these SAML mechanisms in for example a GSS mechanism providing data compression or the like. Also, consider the interaction with NegoEx or SPNEGO. Applications can and will find these attributes with mechanism names with a much broader set of underlying mechanism. >> >> questions: >> I've added text that hopefully clarifies. >> >> - How do I implement the "MUST NOT" in the last para of section >> 4? I'm Jim> told >> that's meant for mechanism spec. writers so making that clear >> would be good. "Closely associated" seems too vague. "Can assume" >> in the example also seems pretty vague. Jim> I don't have good text here at this point. I've proposed something in the soon-to-be-uploaded 05. >> >> - Section 5, 1st para: what does "undefined" mean? If I call the >> relevant Jim> GSS >> function too early (before access-accept) what do I get? Maybe >> say here which GSS calls are meant? Jim> If you make the call too early, you might get an answer that Jim> would change after the access-accept message. You might get an Jim> error. We are not saying what the correct behavior is. While Jim> the current deployments are setup to just get information back, Jim> for Plasma we are looking at situations where we are going to Jim> want to ask more questions and the way to do this is not Jim> currently defined. I've tried to clarify that we're specifying behavior for what happens if you look for these attributes on the src_name returned from GSS_Accept_Sec_context after GSS_S_COMPLETE. >> >> - 6.1, How can a GSS API extension spec assert that >> authentication only succeeds if the SAML or AAA exchange is >> successfully authenticated? Sam suggested: "This attribute MUST >> always be authenticated when present in mechanism names complying >> with this specification." which I think would be better. >> Jim> Jim>I had asked a similar question in the past, and I think that Sam's response Jim> is incorrect in that it does not match with what he told me in Jim> the past. There is a possibility that some mechanism will have Jim> a SAML statement it receives that it cannot authenticate either Jim> via the AAA exchange or by validating the signature on the SAML Jim> statement. In this case the attribute would not be returned as Jim> authenticated. However I would be willing for this behavior to Jim> be dropped. But given that we are talking about how to query Jim> for the attribute, I don't think that the suggested sentence Jim> from Sam would be correct. Hmm. I thought what I said in the past is that the SAML assertion attribute would be dropped if the mechanism didn't like the assertion, but that you'd typically expect the RADIUS attribute carrying the assertion to remain at least for GSS-EAP. Although I guess that was more about local policy checks than validation faliures. Jim> Perhaps 1. Make this a new paragraph 2. Updated text Jim> This attribute is authenticated only when the mechanism can Jim> successfully authenticated the SAML statement. For the GSS-EAP Jim> mechanism this is true if the AAA exchange has successfully Jim> authenticated. However, uses of the GSS-API MUST confirm that Jim> the attribute is marked authenticated as other mechanisms MAY Jim> permit an initiator to provide an unauthenticated SAML Jim> statement. >> - 6.2: Maybe I need to check SAML again, but the >> " element's Name XML attribute" is used at the >> end of para 1, but later Jim> paras >> talks about the - are they the same or not? Jim> They are not the same. >> >> - 6.2: What does "sufficiently validated" mean? Adding more >> clarity here would be good. Sam suggested: "what we're saying or >> trying to say here is that a mechanism of GSS-EAP should mark >> attributes carried according to draft-ietf-abfab-aaa-saml as >> authenticated in the return from GSS_Get_Name_attribute without >> needing to do normal SAML validation." >> That probably is what Sam said, not what he suggested as text. Jim> Text: In the GSS-EAP mechanism, a SAML assert carried in an Jim> integrity-protected and authenticated AAA protocol SHALL be Jim> considered successfully validated. >> - 6.2: last sentence talks about "this assertion" buts its not >> clear to me Jim> if you >> mean the entire assertion or just the attribute? Jim> I think that when Sam wrote the text he was thinking of the Jim> SAML assertion. I think however it would be more correct in Jim> the current content to substitute attribute for assertion as it Jim> needs to be clear than local policy may kill an attribute. I Jim> would suggest the following changes: Jim> 1. Add the following to the end of section 6.1 "An Jim> implementation MAY apply local policy checks to a SAML Jim> assertion and discard it if it fails the local policy checks." Jim> 2. Change the text at the end of section 6.2 to "An Jim> implementation MAY apply local policy checks to each attribute Jim> contained in a SAML assertion and discard the attribute if it Jim> fails the local policy checks. >> >> - 6.3: Why the SHOULD in the first para? Jim> A mechanism can choose not to expose some name forms to the Jim> acceptor. In this case the GSS name attribute would not be Jim> present. >> >> - section 8, what is "paramname"? Jim> If a parameter "paramname" is registered in this registry then Jim> its URN will be "urn:ietf:gss:paramname". >> >> nits and whinges: >> - section 8, all but 1st sentence of 1st para should go >> Will do, but Stephen is taking full responsibility for resolving any confusion by people trying to put it somewhere else.:-) From internet-drafts@ietf.org Wed Sep 19 11:51:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBA21F85F9; Wed, 19 Sep 2012 11:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAqJNKkCjtKa; Wed, 19 Sep 2012 11:51:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D1F21F8602; Wed, 19 Sep 2012 11:51:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919185110.22931.84315.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 11:51:10 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-05.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:51:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Name Attributes for the GSS-API EAP mechanism Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-naming-05.txt Pages : 16 Date : 2012-09-19 Abstract: The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-naming-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Wed Sep 19 11:54:49 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FBC21F8605 for ; Wed, 19 Sep 2012 11:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.393 X-Spam-Level: **** X-Spam-Status: No, score=4.393 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oBmf1k-4HgF for ; Wed, 19 Sep 2012 11:54:48 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 635B521F8602 for ; Wed, 19 Sep 2012 11:54:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 29AAB202A0; Wed, 19 Sep 2012 14:54:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A9AA04149; Wed, 19 Sep 2012 14:54:16 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org,abfab-ads@tools.ietf.org References: <20120919185110.22931.84315.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 14:54:16 -0400 In-Reply-To: <20120919185110.22931.84315.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 19 Sep 2012 11:51:10 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-05.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:54:49 -0000 In looking over my commits to implement this for Moonshot and comparing against the draft, Luke Howard noticed that there were places in the draft where I used urn:ietf:gss not urn:ietf:params:gss. I think I got all those fixed in 05, but if there are any remaining, please call them out because they are very wrong and IANA/the URN folks will choke on them. --Sam From stephen.farrell@cs.tcd.ie Thu Sep 20 06:28:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30B721F8674 for ; Thu, 20 Sep 2012 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afEpBE5Oi3-A for ; Thu, 20 Sep 2012 06:28:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 009CB21F84FC for ; Thu, 20 Sep 2012 06:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 445D2171476; Thu, 20 Sep 2012 14:28:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1348147722; bh=2rYDuIRE4SUDS2 EDY8uVz5gAYX6qxc31lMynXj7FgZw=; b=fRorNZtnvn83H7E7hgxfydEspfXqNi 3jiaaPI0NnJ897qC9f/1mpn47zfDFwny+fK65UVZkAIMDXhJ8CUDPP+M2LLXjeOj cM259B+VukTzYuCTmzafpMwZyFFPe11Ri9GYHpiUQN19joHf2wD0Xlrt4C/vWGy4 BA8RDo8VifBGF+evRaavsSe/NwTlrNyyje1Op5tg9BWOj+9KXALlLFQjLRKoEovc nomrf3XkvxEzk0IVLHmfL2Op8yqUD1a1Bc3wbDLQUikC2t4JWmaNCXKz7l4o0nT2 1CckIb0Wnw+dJnzjZ8fsETCgesfN+zRb1sKSR0hMKOeFvh8NVkUt6umw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s4If+1beVHBe; Thu, 20 Sep 2012 14:28:42 +0100 (IST) Received: from [192.6.10.171] (bri-event-72.hpl.hp.com [192.6.10.171]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 966EF171473; Thu, 20 Sep 2012 14:28:41 +0100 (IST) Message-ID: <505B1A08.4040705@cs.tcd.ie> Date: Thu, 20 Sep 2012 14:28:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Sam Hartman References: <20120919185110.22931.84315.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, abfab-ads@tools.ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-05.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 13:28:43 -0000 Thanks Sam, I've requested IETF LC. Cheers, S. On 09/19/2012 07:54 PM, Sam Hartman wrote: > > > In looking over my commits to implement this for Moonshot and comparing > against the draft, Luke Howard noticed that there were places in the > draft where I used urn:ietf:gss not urn:ietf:params:gss. I think I got > all those fixed in 05, but if there are any remaining, please call them > out because they are very wrong and IANA/the URN folks will choke on > them. > > --Sam > From iesg-secretary@ietf.org Thu Sep 20 07:17:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F040421F8798; Thu, 20 Sep 2012 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E3FiVJKVCog; Thu, 20 Sep 2012 07:17:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7730221F86E5; Thu, 20 Sep 2012 07:17:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920141717.4821.29598.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 07:17:17 -0700 Cc: abfab@ietf.org Subject: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:17:25 -0000 The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Name Attributes for the GSS-API EAP mechanism' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/ballot/ No IPR declarations have been submitted directly on this I-D. From simon@josefsson.org Thu Sep 20 15:15:27 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C2921E80A5; Thu, 20 Sep 2012 15:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.871 X-Spam-Level: X-Spam-Status: No, score=-99.871 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwlk+HzrPYSe; Thu, 20 Sep 2012 15:15:27 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id C046521E803C; Thu, 20 Sep 2012 15:15:25 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q8KMFGUq029866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Sep 2012 00:15:18 +0200 From: Simon Josefsson To: ietf@ietf.org References: <20120920141717.4821.29598.idtracker@ietfa.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120920:ietf@ietf.org::ZJ9qPi94zPtEvUGQ:1PaJ X-Hashcash: 1:22:120920:abfab@ietf.org::duoE3tSFmeVx7mLe:8yI+ X-Hashcash: 1:22:120920:ietf-announce@ietf.org::9XbAlBcDeESGZQnu:JkTn Date: Fri, 21 Sep 2012 00:15:16 +0200 In-Reply-To: <20120920141717.4821.29598.idtracker@ietfa.amsl.com> (The IESG's message of "Thu, 20 Sep 2012 07:17:17 -0700") Message-ID: <87fw6c9w97.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: abfab@ietf.org Subject: Re: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:15:28 -0000 I found no major issues with this document. I support publishing it if the minor issues below are resolved. The document is written in a rather information dense style, but I can't come up with any easy way to make it more accessible. More examples and illustrations would help, but I don't see this as sufficient reason to not move forward. /Simon Minor issues: The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the ^ insert SPC mechanism allows an Authentication/Authorization/Accounting peer to ^ ... [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/ Accounting peer to provide authorization attributes along side an ^ add '(AAA)'. Otherwise the AAA acronym is not expanded. The first is a URI describing the format of the name. The second ^^^ Expand acronym on first use. The first is a URN indicating that the name is a SAML attribute and ^^^ Expand acronym on first use. context Section 4 are issued by the same party performing the ^ ^ I believe parenthesis should be inserted here. information is combined from AAA and SAML sources. The SAML IDP and ^^^ Expand acronym on first use. GSS_S_COMPLETE. Attributes MAy be absent or values MAY change in ^ Typo. value of this attribute would first wait until GSS- ^^^^ _Accept_sec_Context returned GSS_S_COMPLETE. Then the application ^^^^^^^^^^^^^^^^^^^ Typo, should be 'GSS_Accept_sec_context'. Check this throughout the document, there are more incorrect uses. GSS_Get_Name_attribute passing this name and an attribute of ^ Typo, should be 'GSS_Get_name_attribute'. Check this throughout the document, there are more incorrect uses. This attribute is returned with the authenticatedoutput of ^ Typo. assertion, then An attribute with the name ^ Typo. "urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2.0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.7 " could be returned from ^ Should there really be a SPC at the end? It is also not clear that there is a SPC between the parts since they terminate the line. GSS_Inquire_Name. If an application calls GSS_Get_Name_attribute ^ Typo, 'GSS_Inquire_name' (and 'GSS_Get_name_attribute'...). If the value is not simple or is empty, then the raw value(s) of the GSS name attribute MUST be the well-formed serialization of the element(s) encoded as UTF-8. The "display" values are implementation-defined. Question: what serialization is intended here? An example here would make this more clear. mechanisms are permitted to perform local policy checks on SAML ^ Typo, capitalize to 'M'. choices for non-IETf work. Expert review is permitted mainly to ^ Typo. From hartmans@painless-security.com Fri Sep 21 22:09:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF821F87EA for ; Fri, 21 Sep 2012 22:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.36 X-Spam-Level: **** X-Spam-Status: No, score=4.36 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZlZ+fe4I3WC for ; Fri, 21 Sep 2012 22:09:08 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 912CF21F87E8 for ; Fri, 21 Sep 2012 22:09:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D498520161 for ; Sat, 22 Sep 2012 01:08:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B94FF414A; Sat, 22 Sep 2012 01:08:34 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Sat, 22 Sep 2012 01:08:34 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Implementation concern: acceptor name response in extensions state and realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 05:09:09 -0000 Hi. Luke discovered a bit of a problem. Jim proposed that acceptors echo back their name rather than simply relying on the name match in channel bindings. The intent is to prevent a malicious actor from being able to connect one GSS-EAP peer to another in a situation where channel binding is not enforced properly. That is, we want man-in-the-middle defense always even if we're not going to get malicious NAS defense because channel binding is not happening. The issue is that the initiator and/or acceptor may not know the acceptor's realm yet. My recommended implementation strategy is that if the realm name is present on both the initiator and acceptor it must match. Luke notes that it is easier to compare ignoring the realm. I'm concerned that for some realm-based services that might allow substitution of one realm for another. Either way, I think it's probably too late in the process to do anything about this in terms of spec text. This will probably be our first Erato. However I'd like to get community input on what implementations should do. From lukeh@padl.com Fri Sep 21 22:19:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90D721F880D for ; Fri, 21 Sep 2012 22:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V0KhyvmZUy2 for ; Fri, 21 Sep 2012 22:19:13 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id F29BA21F880B for ; Fri, 21 Sep 2012 22:19:12 -0700 (PDT) Received: by us.padl.com with ESMTP id q8M5J7eh013384; Sat, 22 Sep 2012 01:19:10 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Sat, 22 Sep 2012 15:19:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9E609476-1513-49AA-9E56-71E4FA18050D@padl.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Implementation concern: acceptor name response in extensions state and realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 05:19:13 -0000 On 22/09/2012, at 3:08 PM, Sam Hartman = wrote: > Jim proposed that acceptors echo back their name rather than simply > relying on the name match in channel bindings. Your recommended implementation strategy (ignore realm if absent on = either side) is easy to implement, no problem there. In the case of hostname (or more generally, SPN) aliases, then the = initiator will fail if the acceptor returns its canonical service = principal name, because it has no way of validating one against the = other (a simple comparison may fail and the canonicalisation logic = belongs on the server side). (Historical anecdote: between W2K and W2K3 Microsoft changed the = behaviour of the canonicalize KDC option in a TGS-REQ so that it would = effectively be ignored, i.e. not canonicalize the service principal name = in the response.) -- Luke= From hartmans@painless-security.com Fri Sep 21 23:31:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143BA21F8830 for ; Fri, 21 Sep 2012 23:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.356 X-Spam-Level: **** X-Spam-Status: No, score=4.356 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYOCnivHXQy8 for ; Fri, 21 Sep 2012 23:31:11 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9B58C21F882E for ; Fri, 21 Sep 2012 23:31:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 84A8020161; Sat, 22 Sep 2012 02:31:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8C3AE414A; Sat, 22 Sep 2012 02:30:38 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <9E609476-1513-49AA-9E56-71E4FA18050D@padl.com> Date: Sat, 22 Sep 2012 02:30:38 -0400 In-Reply-To: <9E609476-1513-49AA-9E56-71E4FA18050D@padl.com> (Luke Howard's message of "Sat, 22 Sep 2012 15:19:04 +1000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Implementation concern: acceptor name response in extensions state and realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 06:31:12 -0000 >>>>> "Luke" == Luke Howard writes: Luke> In the case of hostname (or more generally, SPN) aliases, then Luke> the initiator will fail if the acceptor returns its canonical Luke> service principal name, because it has no way of validating Luke> one against the other (a simple comparison may fail and the Luke> canonicalisation logic belongs on the server side). Right. That's why the initiator is recommended to send its preferred name in the initial state. Actually, perhaps a better implementation strategy is for the acceptor to look at what the initiator sends, see if it likes that, and if so, return exactly that name in extensions state. If the acceptor doesn't have a good handle on its own aliases, it's probably better that it not return a response in extensions state (it has that option). From ietf@augustcellars.com Sat Sep 22 15:45:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8121F8625 for ; Sat, 22 Sep 2012 15:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU-UdzGwIc8V for ; Sat, 22 Sep 2012 15:45:58 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2E21F8624 for ; Sat, 22 Sep 2012 15:45:58 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 0D9032C9FB; Sat, 22 Sep 2012 15:45:58 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Sat, 22 Sep 2012 15:44:10 -0700 Message-ID: <001901cd9913$d69798a0$83c6c9e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKgfhCweAkiTXsr1Y4ilVWGFt6QzJXxF27A Content-Language: en-us Subject: Re: [abfab] Implementation concern: acceptor name response in extensions state and realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 22:45:59 -0000 I am having a problem understanding what is being said here. The case that we are in here is 1. The initiator knows the realm it wants the acceptor to be in, but it does not tell the acceptor that 2. The acceptor does not know which of multiple realms the initiator wants to connect to. If the initiator does not know the realm of the acceptor, then it does not matter what realm is returned by the acceptor. If the initiator tells the realm to the acceptor, then it should always know what to send back. If the acceptor returns a different realm that it gives to the IdP, then channel binding would fail or the initiator would fail. As long as the acceptor returns a consistent value then there should not be any problem. If the acceptor does not return a realm, but gives one to the channel binding, then a channel binding failure could be expected if it uses the wrong one. I don't know that there is any way to say that we should send multiple different realms to the IdP to say that I could be any of the following. What problem is being solved by your proposed errata? Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Friday, September 21, 2012 10:09 PM > To: abfab@ietf.org > Subject: [abfab] Implementation concern: acceptor name response in > extensions state and realm > > > Hi. > Luke discovered a bit of a problem. > Jim proposed that acceptors echo back their name rather than simply relying > on the name match in channel bindings. > The intent is to prevent a malicious actor from being able to connect one > GSS-EAP peer to another in a situation where channel binding is not > enforced properly. > That is, we want man-in-the-middle defense always even if we're not going > to get malicious NAS defense because channel binding is not happening. > > The issue is that the initiator and/or acceptor may not know the acceptor's > realm yet. > > My recommended implementation strategy is that if the realm name is > present on both the initiator and acceptor it must match. > Luke notes that it is easier to compare ignoring the realm. > I'm concerned that for some realm-based services that might allow > substitution of one realm for another. > > Either way, I think it's probably too late in the process to do anything about > this in terms of spec text. > This will probably be our first Erato. > However I'd like to get community input on what implementations should > do. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Sat Sep 22 17:57:56 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5CF21F8592 for ; Sat, 22 Sep 2012 17:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtCYTTMpP-3S for ; Sat, 22 Sep 2012 17:57:56 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 489C221F8573 for ; Sat, 22 Sep 2012 17:57:56 -0700 (PDT) Received: by us.padl.com with ESMTP id q8N0vq2N027771; Sat, 22 Sep 2012 20:57:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Sun, 23 Sep 2012 10:57:53 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E609476-1513-49AA-9E56-71E4FA18050D@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Implementation concern: acceptor name response in extensions state and realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 00:57:56 -0000 On 22/09/2012, at 4:30 PM, Sam Hartman = wrote: > If the acceptor doesn't have a good handle on its own aliases, it's > probably better that it not return a response in extensions state (it > has that option). OK, this makes sense. The client-not-knowing-the-realm thing can be handled as both Sam and = Jim suggested, and I've updated the Moonshot implementation to reflect = this. -- Luke= From internet-drafts@ietf.org Tue Sep 25 09:21:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3D621F8868; Tue, 25 Sep 2012 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVUlnhwqzyxq; Tue, 25 Sep 2012 09:21:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0276421F87FC; Tue, 25 Sep 2012 09:21:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120925162112.23143.55215.idtracker@ietfa.amsl.com> Date: Tue, 25 Sep 2012 09:21:12 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-usecases-05.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 16:21:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond web (AB= FAB) Use Cases Author(s) : Rhys Smith Filename : draft-ietf-abfab-usecases-05.txt Pages : 14 Date : 2012-09-25 Abstract: Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-usecases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-usecases-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-usecases-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Sep 25 15:46:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7901F0C8C; Tue, 25 Sep 2012 15:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRDAMiT0ePnt; Tue, 25 Sep 2012 15:46:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2201B1F0C9F; Tue, 25 Sep 2012 15:46:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120925224622.8105.49923.idtracker@ietfa.amsl.com> Date: Tue, 25 Sep 2012 15:46:22 -0700 Cc: abfab mailing list , abfab chair , RFC Editor Subject: [abfab] Document Action: 'Application Bridging for Federated Access Beyond web (ABFAB) Use Cases' to Informational RFC (draft-ietf-abfab-usecases-05.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 22:46:23 -0000 The IESG has approved the following document: - 'Application Bridging for Federated Access Beyond web (ABFAB) Use Cases' (draft-ietf-abfab-usecases-05.txt) as Informational RFC This document is the product of the Application Bridging for Federated Access Beyond web Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ Technical Summary Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. Working Group Summary There has been some WG discussion around the Telecoms use case and the extent to which it should figure in this draft. The current text has WG consensus on that. Document Quality Given that this is a use-cases document there are no implementation plans. The contributors of use-cases have been credited. The document has been presented on a number of occasions which have led to inclusion of the Plasma and Telecoms use cases. The WGLC did not result in any voicing of discent, nor in consent for that matter. But that is probably not a problem given earlier on list and at meeting discussions and the nature of the document. Personnel Document Shepherd: Klaas Wierenga AD: Stephen Farrell