From hartmans@painless-security.com Wed Sep 1 12:15:26 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74AC3A68DF; Wed, 1 Sep 2010 12:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq5jGD7U5ulN; Wed, 1 Sep 2010 12:15:25 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 5D3D93A680B; Wed, 1 Sep 2010 12:15:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5893920411; Wed, 1 Sep 2010 15:15:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 47A154761; Wed, 1 Sep 2010 15:15:52 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org, kitten@ietf.org Date: Wed, 01 Sep 2010 15:15:52 -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] Review of draft-johannson-http-gss X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 19:15:27 -0000 This is a review of an expired draft Leif wrote a while ago. I'm writing the review because Moonshot's implementation would like to consume some technology like this. First, I would like to revisit the overall approach. At this point, Microsoft have started using channel binding in negotiate authentication. As best I can tell the major advantage of this draft is the ability to handle multi-round-trip mechanisms without assuming the same connection is used and to do fast reauth. Both of those are really important benefits. There were some issues and limitations about how the server challenge could be expanded without breaking IE. Do we remember what those are? I wonder whether it would be easier to simply provide a mechanism to give a context identifier and then entirely reuse the RFC 4559 headers? How does a client know whether a server supports channel binding? Perhaps the server could indicate this (insecurely) in the initial challenge. For Kerberos we could always include CB even if the server claims not to support it on the grounds that they can probably deal and will have to deal in order to play nice with microsoft. For non-Kerberos (particularly Moonshot) I'm not sure what to do. One approach would be to do something GS2-like: the client MUST include CB and the server MUST check them. There is a format that includes the indication from the server of whether CB is accepted plus if it is the actually CB data. You'd either need MS's buy-in to do this all the time for non-Kerberos or you'd need to use a different scheme name after all. How does the client know that the server checked the CB? One possibility is to wrap something like "CB-VERIFIED" if the mechanism supports that. The GS2 approach is not quite good enough in two ways. First, it doesn't help you for Kerberos. Secondly, if Microsoft does permit other GSS mechs to be used with old-style negotiate, then you don't get channel binding confirmation if CB is disabled in IIS. We can probably ignore the second issue. We could fix the first issue by including gss_pseudo_random of a constant string in a response header. This is far more ugly that I'd like. I wonder if we could get a conference call together to see if we could come up with a non-ugly version of this. If we do go with the GS2 approach, do we want to support clients that cannot do CB? If you're going to do CB, you might well want to generate a request that will let you do GSS authentication before exposing the URI or request body you want to expose. Specific comments: 3.2: How does gss-nt-hostbased-service deal with a trailing port? Shouldn't the server include a unique identifier of the context even if no session protection or cb? How do you do multi-round-trip without that? You should probably mention that the unique identifier can be uite large if it is going to be an exported context. From Nicolas.Williams@oracle.com Wed Sep 1 13:22:31 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4329D3A6918; Wed, 1 Sep 2010 13:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1waGynDBOu0; Wed, 1 Sep 2010 13:22:28 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 816963A6900; Wed, 1 Sep 2010 13:22:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o81KMvwW018721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Sep 2010 20:22:58 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o81KMuZd012433; Wed, 1 Sep 2010 20:22:56 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 568874931283372493; Wed, 01 Sep 2010 13:21:33 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Sep 2010 13:21:33 -0700 Date: Wed, 1 Sep 2010 15:21:28 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100901202128.GL1198@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review of draft-johannson-http-gss X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 20:22:31 -0000 On Wed, Sep 01, 2010 at 03:15:52PM -0400, Sam Hartman wrote: > I wonder whether it would be easier to simply provide a mechanism to > give a context identifier and then entirely reuse the RFC 4559 > headers? Sounds worthwhile to me. You could have a request header to request a context identifier, a request header to refer to a given context by context identifier, and a response header to indicate a server-assigned context identifier. > How does a client know whether a server supports channel binding? > Perhaps the server could indicate this (insecurely) in the initial > challenge. If you're using TLS and can stronly authenticate the server, then you can live without channel binding. Otherwise you must insist on channel binding. That's exactly what MSFT did, relying on the fact that the Kerberos V GSS mechanism acceptor can ignore the initiator's channel bindings. > For Kerberos we could always include CB even if the server claims not to > support it on the grounds that they can probably deal and will have to > deal in order to play nice with microsoft. Right. > For non-Kerberos (particularly Moonshot) I'm not sure what to do. One > approach would be to do something GS2-like: the client MUST include CB > and the server MUST check them. There is a format that includes the > indication from the server of whether CB is accepted plus if it is the > actually CB data. You'd either need MS's buy-in to do this all the time > for non-Kerberos or you'd need to use a different scheme name after all. If MSFT doesn't implement the non-Kerberos mechanisms in question then it doesn't matter now... > How does the client know that the server checked the CB? For a mechanism like SCRAM the acceptor must have used the same CB as the initiator. But since we have mechs for which that's not true (that is, where the acceptor can ignore CB), I think it'd be nice to have a per-msg token or PRF output by which the server can indicate, via an HTTP response header, that it really did check CB. > We could fix the first issue by including gss_pseudo_random of a > constant string in a response header. Yes. > This is far more ugly that I'd like. :( > I wonder if we could get a conference call together to see if we could > come up with a non-ugly version of this. I can think of other things, but none less ugly or easier to implement. > If we do go with the GS2 approach, do we want to support clients that > cannot do CB? I don't think so. > If you're going to do CB, you might well want to generate a request that > will let you do GSS authentication before exposing the URI or request > body you want to expose. I say: GET a well-known URL. > Specific comments: > > 3.2: How does gss-nt-hostbased-service deal with a trailing port? It... doesn't. Why should it? > Shouldn't the server include a unique identifier of the context even if > no session protection or cb? How do you do multi-round-trip without that? Yes. Luck helps. > You should probably mention that the unique identifier can be uite large > if it is going to be an exported context. Sure. For Kerberos an exported context could consist of: the initiator's Ticket (or the cleartext enc-part of it), the session keys, context flags, sequence numbers and sequence number windows -- all encrypted and authenticated. Incidentally, you can't enforce out-of- secquence (OOS) detection, or even replay detection, if you export/ import contexts on every request! Unless the server keeps a replay cache, but then why bother exporting contexts? Replay caching is much more onerous than keeping around sec contexts. Not being able to detect replays could be a big problem. Nico -- From turners@ieca.com Thu Sep 2 05:43:15 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239123A69FA for ; Thu, 2 Sep 2010 05:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRvsyIpMh4Bi for ; Thu, 2 Sep 2010 05:43:14 -0700 (PDT) Received: from smtp115.biz.mail.mud.yahoo.com (smtp115.biz.mail.mud.yahoo.com [209.191.68.75]) by core3.amsl.com (Postfix) with SMTP id 2D3B63A696E for ; Thu, 2 Sep 2010 05:43:14 -0700 (PDT) Received: (qmail 56110 invoked from network); 2 Sep 2010 12:43:41 -0000 Received: from thunderfish.local (turners@71.191.0.104 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 02 Sep 2010 05:43:41 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 7ayTB7UVM1ko6Dn2nynfJavAAQo.j3B1bv1r.GbqQ85kHbl BvHO915HA7DovjriDaJ6rTn5hoCwb5SjVJ10r6avXtaTonfQg1q0DZ7A8cO6 dpzC1OJrFrngiYDS3tOL6uYJeYV8FaB_YIEVRKWPXjMRPRiR6lX2TT7zWz2U AN2_sZuwsCCjHNtvUGNdnz04erHXhA_h4Sj_m4iRji7Dqt64LACycPw2mr6n lIYg_uikD35idkijR0Fnmi31z_wR6_v3zg41pTSsZ5Mo02MQGrGKzjnq5x8f jvmtUFcz0WPgkzn26BwDd0y4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C7F9BFC.2090303@ieca.com> Date: Thu, 02 Sep 2010 08:43:40 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 12:43:15 -0000 I reviewed the charter and like it. I am not sure of all the IESG hot buttons wrt new charters, but the new WG charter discussions I have observed targeted ensuring that success (or at least initial success) could be declared and that there is enough effort to get the work done. I think the 1st paragraph of constraints and the deliverables are clear about what needs to gets done first to declare success. What I'd like to reconfirm here, on the list, is that there are in fact still enough authors and interested reviewers for the 8 WG items listed. So, please indicate your willingness to author a draft and/or review particular drafts listed in the charter. Cheers, spt From Josh.Howlett@ja.net Thu Sep 2 09:23:03 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFF43A6816 for ; Thu, 2 Sep 2010 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.368 X-Spam-Level: X-Spam-Status: No, score=-100.368 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y86-pS6oGQQ0 for ; Thu, 2 Sep 2010 09:23:02 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id CEB8A3A6803 for ; Thu, 2 Sep 2010 09:22:58 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 17E6E4A6B3C_C7FCF7FB; Thu, 2 Sep 2010 16:23:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id EF2B04A6A7C_C7FCF7DF; Thu, 2 Sep 2010 16:23:25 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Thu, 2 Sep 2010 17:23:35 +0100 From: Josh Howlett To: Sean Turner , "abfab@ietf.org" Thread-Topic: [abfab] Moving the Charter Forward Thread-Index: AQHLSpyM8oOxExsB1kWK5QS54Zv+7JL+4EEA Date: Thu, 2 Sep 2010 16:23:21 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E605E18A@EXC001.atlas.ukerna.ac.uk> References: <4C7F9BFC.2090303@ieca.com> In-Reply-To: <4C7F9BFC.2090303@ieca.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 16:23:03 -0000 Sean wrote: > So, please indicate your willingness to author a draft and/or > review particular drafts listed in the charter. I am willing to author: * A document describing applicable use cases. (Dec 2010) * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (Dec 2010) * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011) * A standards track solution for using EAP methods to provide authentication within the application (May 2011) I am willing to review: * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case (May 2011) * An update to the EMSK root key applicability statement in RFC 5295 (Aug 2= 011) * A standards-track description of GSS names and name attributes required by the solution (Aug 2011) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From Nicolas.Williams@oracle.com Thu Sep 2 09:34:38 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495C23A6951 for ; Thu, 2 Sep 2010 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcDRSMbF-asH for ; Thu, 2 Sep 2010 09:34:34 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BD4823A6816 for ; Thu, 2 Sep 2010 09:34:34 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o82GZ1q7013375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Sep 2010 16:35:03 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o82GYxKP000544; Thu, 2 Sep 2010 16:35:00 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 571603081283445292; Thu, 02 Sep 2010 09:34:52 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Sep 2010 09:34:52 -0700 Date: Thu, 2 Sep 2010 11:34:47 -0500 From: Nicolas Williams To: Sean Turner Message-ID: <20100902163446.GR1198@oracle.com> References: <4C7F9BFC.2090303@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7F9BFC.2090303@ieca.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 16:34:38 -0000 On Thu, Sep 02, 2010 at 08:43:40AM -0400, Sean Turner wrote: > I reviewed the charter and like it. I am not sure of all the IESG > hot buttons wrt new charters, but the new WG charter discussions I > have observed targeted ensuring that success (or at least initial > success) could be declared and that there is enough effort to get > the work done. I think the 1st paragraph of constraints and the > deliverables are clear about what needs to gets done first to > declare success. What I'd like to reconfirm here, on the list, is > that there are in fact still enough authors and interested reviewers > for the 8 WG items listed. So, please indicate your willingness to > author a draft and/or review particular drafts listed in the > charter. I'm willing to review most documents produced by this WG. From linus@nordberg.se Mon Sep 6 06:47:54 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859C63A6918 for ; Mon, 6 Sep 2010 06:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xOLYA6IeZEy for ; Mon, 6 Sep 2010 06:47:53 -0700 (PDT) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by core3.amsl.com (Postfix) with ESMTP id BE9803A6915 for ; Mon, 6 Sep 2010 06:47:52 -0700 (PDT) Received: from maatuska (unknown [192.36.125.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "maatuska.nordberg.se", Issuer "Mail.Nordberg CA" (verified OK)) by smtp.nordberg.se (Postfix) with ESMTPS id 77F2011512; Mon, 6 Sep 2010 15:48:19 +0200 (CEST) Received: by maatuska (Postfix, from userid 1000) id E2FC984370; Mon, 6 Sep 2010 15:48:18 +0200 (CEST) From: Linus Nordberg To: Sean Turner References: <4C7F9BFC.2090303@ieca.com> Date: Mon, 06 Sep 2010 15:48:15 +0200 In-Reply-To: <4C7F9BFC.2090303@ieca.com> (Sean Turner's message of "Thu, 02 Sep 2010 08:43:40 -0400") Message-ID: <87fwxnq8yo.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 13:47:55 -0000 --=-=-= Sean Turner wrote Thu, 02 Sep 2010 08:43:40 -0400: | listed. So, please indicate your willingness to author a draft and/or | review particular drafts listed in the charter. I'm willing to review stuff related to RADIUS/RadSec. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMhPEfAAoJEB6L80kjKRJlAeoQAMeVe/VsKqy+0rRLbNZsb1bf T1m+S+1npA6xFmTG10uad1Na5sLh66LDe3RfpIZiXMNzolOcJ6W2YZJFMpKTmPnv zojko6nxK9WLzyWAecUSrAuAehSSZkzW+xKDI8+OH9mvdNCC9fY1FpD9na338Caz KcbTyxu2LgFrG7IDCGvHPLeY0u31HTc6m+h4viUofyYiWedGnnd/+TjXPwyiYZWZ P6lj6Q23GgSFRDewPozNagCKQV7+WUHJ80XwD/UXFkRtgggSz8TzYUlMt3CMaiMO 4r5jWvlFzGGbwrlKsMBH9veN6p0WNxh5XCtL8c/JYpvXfzHrIwlH8Tn4RlJ7UuGv fC7SRe+bwycfxO5iKxMFg4AmM5DosqCCIoq3kWK0TjaqmkMHRasiL4Al5kEaztXM kW/b6Ws3AshUk6EWrkjsYSDj91VVys31BhRcGB0w/huHaR8rWEfSnX4Ogt0S/qVn Em8TKLCGP+e5gRFV63ISF4hA606RYZXnIEeXj6lDhcFyBe1pVcbx9X84XOvHL/wZ WI141KgiYIQ2y+Iq68oSZnXN4xT0l4QUkjLktCK9ewSsBDO1taa/OBgKJmKqFEjA LwasIAK2qiv+MmT3e7O4yhnY9rJWdkExP/aL9uGNZzOUlIHwMZXMbBg+/9d0WNDg 7JDUJi6AWxX9StvuBxAx =9Z9A -----END PGP SIGNATURE----- --=-=-=-- From lear@cisco.com Mon Sep 6 06:49:56 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CD83A6915 for ; Mon, 6 Sep 2010 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.351 X-Spam-Level: X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiN0LkFSf6Au for ; Mon, 6 Sep 2010 06:49:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3EEFE3A67D6 for ; Mon, 6 Sep 2010 06:49:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGaOhExAZnwN/2dsb2JhbACDGJ16caEAiXuQaYEigyd0BIoY X-IronPort-AV: E=Sophos;i="4.56,325,1280707200"; d="scan'208";a="155939576" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Sep 2010 13:50:23 +0000 Received: from dhcp-10-55-95-106.cisco.com (dhcp-10-55-95-106.cisco.com [10.55.95.106]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o86DoMvk012536; Mon, 6 Sep 2010 13:50:23 GMT Message-ID: <4C84F1AC.3040409@cisco.com> Date: Mon, 06 Sep 2010 15:50:36 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Josh Howlett References: <4C7F9BFC.2090303@ieca.com> <40AC324AA6D81B4A8CF133BCFB7526E605E18A@EXC001.atlas.ukerna.ac.uk> In-Reply-To: <40AC324AA6D81B4A8CF133BCFB7526E605E18A@EXC001.atlas.ukerna.ac.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 13:49:56 -0000 Hi Josh & Sean, First, I support the charter. On 9/2/10 6:23 PM, Josh Howlett wrote: > > * An architecture document describing how the components of the solution > fit together to address the use cases and open issues that will require > future changes to the architecture (Dec 2010) I'd like to assist Josh on the above item. I personally think December 2010 is a bit aggressive, but perhaps not by much. Eliot From lukeh@padl.com Mon Sep 6 12:52:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F3D3A696D for ; Mon, 6 Sep 2010 12:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg4sdbyRZpWW for ; Mon, 6 Sep 2010 12:52:22 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id A60DB3A68E2 for ; Mon, 6 Sep 2010 12:52:22 -0700 (PDT) Received: by us.padl.com with ESMTP id o86JqcJU014213; Mon, 6 Sep 2010 15:52:42 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4C7F9BFC.2090303@ieca.com> Date: Mon, 6 Sep 2010 21:52:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4B5CA910-F349-4A74-B586-4CBE789493A2@padl.com> References: <4C7F9BFC.2090303@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 19:52:23 -0000 Hi Sean, I'm willing to review * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2010) * A standards track solution for using EAP methods to provide authentication within the application (May 2011) * A standards-track description of GSS names and name attributes required by the solution (Aug 2011) -- Luke From cantor.2@osu.edu Mon Sep 6 13:48:22 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F863A6862 for ; Mon, 6 Sep 2010 13:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arYRa7Of4CHx for ; Mon, 6 Sep 2010 13:48:16 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by core3.amsl.com (Postfix) with ESMTP id 665173A6946 for ; Mon, 6 Sep 2010 13:48:15 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o86KmehY030846; Mon, 6 Sep 2010 16:48:40 -0400 Received: from SNOWDOG ([128.146.178.55]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o86Kmda9030904; Mon, 6 Sep 2010 16:48:39 -0400 From: "Scott Cantor" To: "'Sean Turner'" References: <4C7F9BFC.2090303@ieca.com> <4B5CA910-F349-4A74-B586-4CBE789493A2@padl.com> In-Reply-To: <4B5CA910-F349-4A74-B586-4CBE789493A2@padl.com> Date: Mon, 6 Sep 2010 16:48:41 -0400 Organization: The Ohio State University Message-ID: <076201cb4e04$e3ccda00$ab668e00$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-index: AQJfGLphox4ywWE0b2ntDGv8fxkmUAJ4N9I7kcoVU1A= X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 20:48:23 -0000 I'm willing to contribute to or review: * A standards-track protocol for carrying SAML messages in RADIUS and Diameter * A standards-track description of GSS names and name attributes required by the solution * Informational descriptions of usability and user-interface concerns related to this work My input would principally be in SAML-related areas. -- Scott From kouril@ics.muni.cz Tue Sep 7 04:16:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FBD3A68D3 for ; Tue, 7 Sep 2010 04:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.25 X-Spam-Level: X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZecAFlbL4PSV for ; Tue, 7 Sep 2010 04:15:56 -0700 (PDT) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by core3.amsl.com (Postfix) with ESMTP id E28EF3A6974 for ; Tue, 7 Sep 2010 04:15:55 -0700 (PDT) Received: from w54-165.fi.muni.cz (w54-165.fi.muni.cz [147.251.54.165]) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id o87BGJ66028936; Tue, 7 Sep 2010 13:16:20 +0200 Received: by w54-165.fi.muni.cz (Postfix, from userid 501) id F20AA2D7BD0; Tue, 7 Sep 2010 13:16:18 +0200 (CEST) Date: Tue, 7 Sep 2010 13:16:18 +0200 From: Daniel Kouril To: "'Sean Turner'" Message-ID: <20100907111618.GB33258@w54-165.fi.muni.cz> References: <4C7F9BFC.2090303@ieca.com> <4B5CA910-F349-4A74-B586-4CBE789493A2@padl.com> <076201cb4e04$e3ccda00$ab668e00$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <076201cb4e04$e3ccda00$ab668e00$@osu.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-Muni-Spam-TestIP: 147.251.54.165 X-Muni-Envelope-From: kouril@ics.muni.cz X-Muni-Virus-Test: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Tue, 07 Sep 2010 13:16:20 +0200 (CEST) Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 11:16:01 -0000 >From the documents proposed in the charter I'm willing to contribute to preparation and/or review of: * A document describing applicable use cases. (Dec 2010) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) Daniel From smith@Cardiff.ac.uk Tue Sep 7 10:44:20 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5313A63EB for ; Tue, 7 Sep 2010 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXEfb3k3O+zZ for ; Tue, 7 Sep 2010 10:44:18 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by core3.amsl.com (Postfix) with ESMTP id 072DE3A67FB for ; Tue, 7 Sep 2010 10:44:16 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Ot2Ds-0007ZR-2k; Tue, 07 Sep 2010 18:44:44 +0100 Received: from [131.251.122.195] (helo=vpn-195.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Ot2Dr-0001Dt-Mn; Tue, 07 Sep 2010 18:44:44 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rhys Smith In-Reply-To: <4C7F9BFC.2090303@ieca.com> Date: Tue, 7 Sep 2010 18:43:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <273D6DD3-FDFF-4AF8-8F1E-5F5D3F32EAC3@cardiff.ac.uk> References: <4C7F9BFC.2090303@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1081) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 17:44:20 -0000 I am happy to contribute towards: * A document describing applicable use cases. (Dec 2010) * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (Dec 2010) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011) I am willing to review all documents produced by the WG. Best Regards, Rhys. -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From hartmans@painless-security.com Tue Sep 7 11:04:38 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535EF3A685B for ; Tue, 7 Sep 2010 11:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNlvlCQn+Dmj for ; Tue, 7 Sep 2010 11:04:37 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3106C3A68DD for ; Tue, 7 Sep 2010 11:04:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 27D10204AF for ; Tue, 7 Sep 2010 14:05:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EB0AA4761; Tue, 7 Sep 2010 14:04:52 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 07 Sep 2010 14:04:52 -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] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 18:04:38 -0000 Are there any reasons to have an RFC 4121-style acceptor subkey in GSS-EAP? --Sam From Nicolas.Williams@oracle.com Tue Sep 7 11:17:49 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB853A6896 for ; Tue, 7 Sep 2010 11:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSD8HVLboMGy for ; Tue, 7 Sep 2010 11:17:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7D0183A6902 for ; Tue, 7 Sep 2010 11:17:37 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o87II3iW013524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Sep 2010 18:18:04 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o879Jino006621; Tue, 7 Sep 2010 18:18:02 GMT Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 571671991283883479; Tue, 07 Sep 2010 11:17:59 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Sep 2010 11:17:58 -0700 Date: Tue, 7 Sep 2010 13:17:54 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100907181753.GO1198@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 18:17:49 -0000 On Tue, Sep 07, 2010 at 02:04:52PM -0400, Sam Hartman wrote: > Are there any reasons to have an RFC 4121-style acceptor subkey in > GSS-EAP? The initiator and acceptor will both share a high-quality (one hopes) MSK/EMSK from which to derive 'specific keys'[*]. I see no reason to have the acceptor (nor initiator) provide additional 'protocol keys'[*]. [*] 'Protocol key' and 'specific key' are terms from RFC3961 (the crypto framework that RFC4121 uses). Specific keys are the keys actually used for AES/whatever encryption/decryption, and are derived from protocol keys. Protocol keys are the keys that are the result of key exchanges, sent around in protocol messages, etcetera. Here MSK/EMSK are protocol keys, from which we'd derive specific keys for use in RFC4121 per-message tokens (and for keying the PRF too). We might want to derive RFC4121 protocol keys from MSK/EMSK, rather than directly derive RFC4121 specific keys from MSK/EMSK, that way more of RFC4121 implementations can be re-used and the interface to them can be simpler. From Josh.Howlett@ja.net Tue Sep 7 12:40:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635DF3A6956 for ; Tue, 7 Sep 2010 12:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.335 X-Spam-Level: X-Spam-Status: No, score=-100.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoCtZM9ooJF4 for ; Tue, 7 Sep 2010 12:40:52 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id D91DA3A6A4A for ; Tue, 7 Sep 2010 12:40:43 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3C5454A6B66_C869556B; Tue, 7 Sep 2010 19:41:10 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 2A2D24A6B60_C869555F; Tue, 7 Sep 2010 19:41:09 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 7 Sep 2010 20:41:09 +0100 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Does GSS-EAP need an acceptor subkey Thread-Index: AQHLTrdUXaJ0tRRFakO4ffcYZcQHP5MG6CqQ Date: Tue, 7 Sep 2010 19:41:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 19:40:53 -0000 Sam, > Are there any reasons to have an RFC 4121-style acceptor subkey in > GSS-EAP? I think this is quite orthogonal to your question, but it's somewhat relate= d and so may be helpful nonetheless. When I started sketching the GSS-EAP m= echanism I was unsure about the appropriate use of key usage values in the = case of non-Kerberos protocol keys being applied with RFC3961. Nico set me = straight: http://www.ietf.org/mail-archive/web/kitten/current/msg01579.html I don't think I captured this in the initial sketch of the mechanism. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Sep 7 12:52:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221023A696A for ; Tue, 7 Sep 2010 12:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Tz23lOT8jtE for ; Tue, 7 Sep 2010 12:52:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 576EF3A6A4D for ; Tue, 7 Sep 2010 12:52:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2011620C02; Tue, 7 Sep 2010 15:53:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E62084761; Tue, 7 Sep 2010 15:52:59 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <20100907181753.GO1198@oracle.com> Date: Tue, 07 Sep 2010 15:52:59 -0400 In-Reply-To: <20100907181753.GO1198@oracle.com> (Nicolas Williams's message of "Tue, 7 Sep 2010 13:17:54 -0500") 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] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 19:52:46 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Here MSK/EMSK are protocol keys, from which we'd derive Nicolas> specific keys for use in RFC4121 per-message tokens (and Nicolas> for keying the PRF too). No, they are random bit strings converted into protocol keys using random-to-key (also from RFC 3961). Nicolas> We might want to derive RFC4121 Nicolas> protocol keys from MSK/EMSK, rather than directly derive Nicolas> RFC4121 specific keys from MSK/EMSK, that way more of Nicolas> RFC4121 implementations can be re-used and the interface to Yes, we might want to do this. From Nicolas.Williams@oracle.com Tue Sep 7 13:03:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3EA3A6AA5 for ; Tue, 7 Sep 2010 13:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Msf10jqt4os for ; Tue, 7 Sep 2010 13:03:00 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DBE2A3A6AB1 for ; Tue, 7 Sep 2010 13:02:59 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o87K3O30020570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Sep 2010 20:03:26 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o87EZl4Z026791; Tue, 7 Sep 2010 20:03:24 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 572039341283889694; Tue, 07 Sep 2010 13:01:34 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Sep 2010 13:01:33 -0700 Date: Tue, 7 Sep 2010 15:01:29 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100907200128.GR1198@oracle.com> References: <20100907181753.GO1198@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 07 Sep 2010 20:03:01 -0000 On Tue, Sep 07, 2010 at 03:52:59PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> Here MSK/EMSK are protocol keys, from which we'd derive > Nicolas> specific keys for use in RFC4121 per-message tokens (and > Nicolas> for keying the PRF too). > > No, they are random bit strings converted into protocol keys using > random-to-key (also from RFC 3961). Well, yes, I skipped a step (that one could glean from reading RFC3961), but only as a way to indicate that I'd much rather derive RFC4121 protocol keys: > Nicolas> We might want to derive RFC4121 > Nicolas> protocol keys from MSK/EMSK, rather than directly derive > Nicolas> RFC4121 specific keys from MSK/EMSK, that way more of > Nicolas> RFC4121 implementations can be re-used and the interface to > > Yes, we might want to do this. My main point was that if you have an API to construct Kerberos-less (i.e., just for the per-message tokens and PRF, thanks) RFC4121 security contexts, then you'd want to have to pass in only protocol keys, not specific keys. Nico -- From lukeh@padl.com Wed Sep 8 02:54:03 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D013A681F for ; Wed, 8 Sep 2010 02:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugrTKyTrIjbn for ; Wed, 8 Sep 2010 02:54:02 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 2771F3A6811 for ; Wed, 8 Sep 2010 02:54:01 -0700 (PDT) Received: by us.padl.com with ESMTP id o889sJ6T018187; Wed, 8 Sep 2010 05:54:23 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Wed, 8 Sep 2010 11:54:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> References: To: Josh Howlett X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 09:54:03 -0000 Noted, I'll use different usage numbers. #define KEY_USAGE_ACCEPTOR_SEAL 512 #define KEY_USAGE_ACCEPTOR_SIGN 513 #define KEY_USAGE_INITIATOR_SEAL 514 #define KEY_USAGE_INITIATOR_SIGN 515 On 07/09/2010, at 9:41 PM, Josh Howlett wrote: > Sam, >=20 >> Are there any reasons to have an RFC 4121-style acceptor subkey in >> GSS-EAP? >=20 > I think this is quite orthogonal to your question, but it's somewhat = related and so may be helpful nonetheless. When I started sketching the = GSS-EAP mechanism I was unsure about the appropriate use of key usage = values in the case of non-Kerberos protocol keys being applied with = RFC3961. Nico set me straight: >=20 > http://www.ietf.org/mail-archive/web/kitten/current/msg01579.html >=20 > I don't think I captured this in the initial sketch of the mechanism. >=20 > Josh. >=20 > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024=20 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab >=20 -- www.padl.com | www.thisismagnolia.net From hartmans@painless-security.com Wed Sep 8 05:50:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7343A681E for ; Wed, 8 Sep 2010 05:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8ntArcfILUs for ; Wed, 8 Sep 2010 05:50:33 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id DEE163A6899 for ; Wed, 8 Sep 2010 05:50:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5BF952017A; Wed, 8 Sep 2010 08:50:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D52C64761; Wed, 8 Sep 2010 08:50:23 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> Date: Wed, 08 Sep 2010 08:50:23 -0400 In-Reply-To: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> (Luke Howard's message of "Wed, 8 Sep 2010 11:54:23 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 12:50:37 -0000 >>>>> "Luke" == Luke Howard writes: Luke> Noted, I'll use different usage numbers. #define wait won't using different usage numbers make sharing code with 4121 harder? Wouldn't it be easier to just make sure that the context root key has gone through some sort of PRF that is specific to gss-eap? --Sam From lukeh@padl.com Wed Sep 8 06:03:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8923A68A0 for ; Wed, 8 Sep 2010 06:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JBdVNtc-X3z for ; Wed, 8 Sep 2010 06:03:36 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 7B13A3A68E2 for ; Wed, 8 Sep 2010 06:03:36 -0700 (PDT) Received: by us.padl.com with ESMTP id o88D3sf1015514; Wed, 8 Sep 2010 09:03:58 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Wed, 8 Sep 2010 15:03:58 +0200 Content-Transfer-Encoding: 7bit Message-Id: <33D73588-CDFF-4D8E-BC3A-C98D9ECAAA74@padl.com> References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 13:03:37 -0000 On 08/09/2010, at 2:50 PM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > > Luke> Noted, I'll use different usage numbers. #define > > > wait won't using different usage numbers make sharing code with 4121 > harder? > Wouldn't it be easier to just make sure that the context root key has > gone through some sort of PRF that is specific to gss-eap? Ack -- luke From lukeh@padl.com Wed Sep 8 06:29:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82EB3A689C for ; Wed, 8 Sep 2010 06:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcJueWsqL7+S for ; Wed, 8 Sep 2010 06:29:10 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id A61163A690D for ; Wed, 8 Sep 2010 06:29:10 -0700 (PDT) Received: by us.padl.com with ESMTP id o88DTSSF013513; Wed, 8 Sep 2010 09:29:32 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Wed, 8 Sep 2010 15:29:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 13:29:11 -0000 What about random-to-key(rfc3961-prf(random-to-key([e]msk), "rfc4121-gss-eap")) ? L On 08/09/2010, at 2:50 PM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > > Luke> Noted, I'll use different usage numbers. #define > > > wait won't using different usage numbers make sharing code with 4121 > harder? > Wouldn't it be easier to just make sure that the context root key has > gone through some sort of PRF that is specific to gss-eap? > > --Sam > -- www.padl.com | www.thisismagnolia.net From hartmans@painless-security.com Wed Sep 8 07:51:09 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4383A685C for ; Wed, 8 Sep 2010 07:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQGVLPD2INgf for ; Wed, 8 Sep 2010 07:51:07 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B1ECB3A694D for ; Wed, 8 Sep 2010 07:51:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A444C20BBE; Wed, 8 Sep 2010 10:51:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4F7794761; Wed, 8 Sep 2010 10:51:25 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> Date: Wed, 08 Sep 2010 10:51:25 -0400 In-Reply-To: (Luke Howard's message of "Wed, 8 Sep 2010 15:29:32 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 14:51:09 -0000 >>>>> "Luke" == Luke Howard writes: Luke> What about random-to-key(rfc3961-prf(random-to-key([e]msk), Luke> "rfc4121-gss-eap")) Luke> ? That works for me. --Sam From Nicolas.Williams@oracle.com Wed Sep 8 07:56:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16E73A6861 for ; Wed, 8 Sep 2010 07:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxMGJ+d-nQ5U for ; Wed, 8 Sep 2010 07:56:22 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 42C733A685C for ; Wed, 8 Sep 2010 07:56:22 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o88Eul0n013995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Sep 2010 14:56:49 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o88EukR1011801; Wed, 8 Sep 2010 14:56:47 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 588078471283957794; Wed, 08 Sep 2010 07:56:34 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Sep 2010 07:56:27 -0700 Date: Wed, 8 Sep 2010 09:56:23 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100908145619.GY1198@oracle.com> References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 14:56:24 -0000 On Wed, Sep 08, 2010 at 10:51:25AM -0400, Sam Hartman wrote: > >>>>> "Luke" == Luke Howard writes: > > Luke> What about random-to-key(rfc3961-prf(random-to-key([e]msk), > Luke> "rfc4121-gss-eap")) > > Luke> ? > That works for me. And me. From dhc@dcrocker.net Thu Sep 9 08:42:58 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADA03A68AF for ; Thu, 9 Sep 2010 08:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN9OaSXiyOdI for ; Thu, 9 Sep 2010 08:42:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id D9EFA3A692A for ; Thu, 9 Sep 2010 08:42:56 -0700 (PDT) Received: from [192.168.1.14] (ppp-68-120-198-81.dsl.pltn13.pacbell.net [68.120.198.81]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o89FhJnH001207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 08:43:24 -0700 Message-ID: <4C890095.2020108@dcrocker.net> Date: Thu, 09 Sep 2010 08:43:17 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: abfab@ietf.org References: <4C7F9BFC.2090303@ieca.com> In-Reply-To: <4C7F9BFC.2090303@ieca.com> 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.17]); Thu, 09 Sep 2010 08:43:24 -0700 (PDT) Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 09 Sep 2010 15:42:58 -0000 On 9/2/2010 5:43 AM, Sean Turner wrote: >What I'd like to reconfirm here, on the list, is that there > are in fact still enough authors and interested reviewers for the 8 WG items > listed. to add to the list record: I think this is a worthwhile effort and I'd be interested in participating. I'd expect to mostly do that as a reviewer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From leifj@mnt.se Fri Sep 10 03:27:42 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A533A67B7 for ; Fri, 10 Sep 2010 03:27:42 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45OaRwh2GcrS for ; Fri, 10 Sep 2010 03:27:41 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 74A663A67F7 for ; Fri, 10 Sep 2010 03:27:40 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o8AAS1IZ023236 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 12:28:03 +0200 (CEST) Message-ID: <4C8A0831.2040206@mnt.se> Date: Fri, 10 Sep 2010 12:28:01 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Sean Turner X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: [abfab] Are we in the IESG comfort-zone? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 10:27:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean: Do you think we are in the IESG comfort-zone wrt volunteers? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyKCDEACgkQ8Jx8FtbMZndyswCfUYKXNZ8U7p+3HayOIJvW+hgj 7lgAoMZfX89GL6vbB2cxoFThgby1R32a =uF34 -----END PGP SIGNATURE----- From hartmans@painless-security.com Fri Sep 10 11:21:02 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EB53A6819 for ; Fri, 10 Sep 2010 11:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dXF5OI-m0nt for ; Fri, 10 Sep 2010 11:21:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 711843A67EB for ; Fri, 10 Sep 2010 11:21:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 43A1E201B0 for ; Fri, 10 Sep 2010 14:21:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5AB3F41D0; Fri, 10 Sep 2010 14:21:13 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 10 Sep 2010 14:21:13 -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] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 18:21:03 -0000 Does the EAP GSS mechanism need to support address based channel binding or just application data? --Sam From sxw@inf.ed.ac.uk Fri Sep 10 11:26:15 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A3A3A67EB for ; Fri, 10 Sep 2010 11:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUP5-rGsVyyI for ; Fri, 10 Sep 2010 11:26:14 -0700 (PDT) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by core3.amsl.com (Postfix) with ESMTP id AE7403A6819 for ; Fri, 10 Sep 2010 11:26:13 -0700 (PDT) Received: from adsl-212-20-248-63.lumison.co.uk ([212.20.248.63] helo=[192.168.0.5] country=GB ident=simon$pop3$sxw*org$uk) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4c8a785f.496c.2; Fri, 10 Sep 2010 19:26:39 +0100 (envelope-sender ) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Simon Wilkinson In-Reply-To: Date: Fri, 10 Sep 2010 19:26:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1260A0DE-E69E-4817-BBD4-50C0E0EE295F@inf.ed.ac.uk> References: To: Sam Hartman X-Mailer: Apple Mail (2.1078) Cc: abfab@ietf.org Subject: Re: [abfab] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 18:26:15 -0000 On 10 Sep 2010, at 19:21, Sam Hartman wrote: > Does the EAP GSS mechanism need to support address based channel = binding > or just application data? Do address based channel bindings actually have any value in this day = and age? Simon. From hartmans@painless-security.com Fri Sep 10 11:28:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16D33A68B3 for ; Fri, 10 Sep 2010 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5J6dZwclLL9 for ; Fri, 10 Sep 2010 11:28:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EB6BE3A68AB for ; Fri, 10 Sep 2010 11:28:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EA96A20BAC; Fri, 10 Sep 2010 14:29:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 443CA41D0; Fri, 10 Sep 2010 14:28:52 -0400 (EDT) From: Sam Hartman To: Simon Wilkinson References: <1260A0DE-E69E-4817-BBD4-50C0E0EE295F@inf.ed.ac.uk> Date: Fri, 10 Sep 2010 14:28:52 -0400 In-Reply-To: <1260A0DE-E69E-4817-BBD4-50C0E0EE295F@inf.ed.ac.uk> (Simon Wilkinson's message of "Fri, 10 Sep 2010 19:26:39 +0100") 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] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 18:28:36 -0000 >>>>> "Simon" == Simon Wilkinson writes: Simon> On 10 Sep 2010, at 19:21, Sam Hartman wrote: > Does the EAP GSS mechanism need to support address based channel binding >> or just application data? Simon> Do address based channel bindings actually have any value in Simon> this day and age? If you're binding to an IPv6 CGA and using something like draft-dong-savi-cga, yes. However it would be easy to register an RFc 5056 channel type for that. I'd probably choose not to support addresses if it were up to me. From Nicolas.Williams@oracle.com Fri Sep 10 11:45:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411EA3A688C for ; Fri, 10 Sep 2010 11:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjqmz-oBS17V for ; Fri, 10 Sep 2010 11:45:00 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 249843A6869 for ; Fri, 10 Sep 2010 11:44:58 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8AIjLYb026756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Sep 2010 18:45:23 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8AIjLfV022119; Fri, 10 Sep 2010 18:45:21 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 584786421284144233; Fri, 10 Sep 2010 11:43:53 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Sep 2010 11:43:53 -0700 Date: Fri, 10 Sep 2010 13:43:48 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100910184348.GJ1121@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 18:45:01 -0000 On Fri, Sep 10, 2010 at 02:21:13PM -0400, Sam Hartman wrote: > Does the EAP GSS mechanism need to support address based channel binding > or just application data? If you can do channel bindings at all, then supporting the crappy network address fields of the old RFC2744 (or new RFC5554) cb struct is also doable. Of course, I'd happily deprecate network address CB. Nico -- From Nicolas.Williams@oracle.com Fri Sep 10 11:45:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595BC3A6869 for ; Fri, 10 Sep 2010 11:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ztZqBQRKCZI for ; Fri, 10 Sep 2010 11:45:00 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 00EE23A67F4 for ; Fri, 10 Sep 2010 11:44:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8AIjLAf026760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Sep 2010 18:45:23 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8A0j7kc014211; Fri, 10 Sep 2010 18:45:21 GMT Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 584789541284144296; Fri, 10 Sep 2010 11:44:56 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Sep 2010 11:44:55 -0700 Date: Fri, 10 Sep 2010 13:44:51 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100910184450.GK1121@oracle.com> References: <1260A0DE-E69E-4817-BBD4-50C0E0EE295F@inf.ed.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 18:45:01 -0000 On Fri, Sep 10, 2010 at 02:28:52PM -0400, Sam Hartman wrote: > >>>>> "Simon" == Simon Wilkinson writes: > > Simon> On 10 Sep 2010, at 19:21, Sam Hartman wrote: > > > Does the EAP GSS mechanism need to support address based channel binding > >> or just application data? > > Simon> Do address based channel bindings actually have any value in > Simon> this day and age? > > If you're binding to an IPv6 CGA and using something like > draft-dong-savi-cga, yes. However it would be easy to register an RFc > 5056 channel type for that. I'd probably choose not to support > addresses if it were up to me. +1. End-point CB types should be used as "application-data" CB. Nico -- From Nicolas.Williams@oracle.com Fri Sep 10 11:47:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019553A6A62 for ; Fri, 10 Sep 2010 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5J42LIdDKQq for ; Fri, 10 Sep 2010 11:47:09 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 095A53A6869 for ; Fri, 10 Sep 2010 11:47:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8AIlXeI032036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Sep 2010 18:47:35 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8AIlVtT028961; Fri, 10 Sep 2010 18:47:31 GMT Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 595862491284144366; Fri, 10 Sep 2010 11:46:06 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Sep 2010 11:46:06 -0700 Date: Fri, 10 Sep 2010 13:45:57 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100910184557.GA1132@oracle.com> References: <1260A0DE-E69E-4817-BBD4-50C0E0EE295F@inf.ed.ac.uk> <20100910184450.GK1121@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910184450.GK1121@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 18:47:10 -0000 Ah, and RFC5554 says: Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), then the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above, rather than some encoding of GSS-CHANNEL-BINDINGS. ... However, it is important that "end-point channel bindings" not be modeled as network addresses; otherwise, such channel bindings may not be useable with all language bindings of the GSS-API. Nico -- From lukeh@padl.com Fri Sep 10 13:22:57 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46813A68E0 for ; Fri, 10 Sep 2010 13:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekStVISww5kx for ; Fri, 10 Sep 2010 13:22:56 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id BB37F3A682A for ; Fri, 10 Sep 2010 13:22:56 -0700 (PDT) Received: by us.padl.com with ESMTP id o8AKM3X7007188; Fri, 10 Sep 2010 16:23:18 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20100910184348.GJ1121@oracle.com> Date: Fri, 10 Sep 2010 22:23:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20100910184348.GJ1121@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 20:22:57 -0000 On 10/09/2010, at 8:43 PM, Nicolas Williams wrote: > On Fri, Sep 10, 2010 at 02:21:13PM -0400, Sam Hartman wrote: >> Does the EAP GSS mechanism need to support address based channel binding >> or just application data? > > If you can do channel bindings at all, then supporting the crappy > network address fields of the old RFC2744 (or new RFC5554) cb struct is > also doable. > > Of course, I'd happily deprecate network address CB. +1 From hartmans@painless-security.com Fri Sep 10 14:01:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427A63A6AAC for ; Fri, 10 Sep 2010 14:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8keJT8IqQo4 for ; Fri, 10 Sep 2010 14:01:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 60CA33A682A for ; Fri, 10 Sep 2010 14:01:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 35FF720BAA; Fri, 10 Sep 2010 17:01:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B12FF41D0; Fri, 10 Sep 2010 17:01:14 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <20100910184348.GJ1121@oracle.com> Date: Fri, 10 Sep 2010 17:01:14 -0400 In-Reply-To: <20100910184348.GJ1121@oracle.com> (Nicolas Williams's message of "Fri, 10 Sep 2010 13:43:48 -0500") 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] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 21:01:01 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Fri, Sep 10, 2010 at 02:21:13PM -0400, Sam Hartman wrote: >> Does the EAP GSS mechanism need to support address based channel >> binding or just application data? Nicolas> If you can do channel bindings at all, then supporting the Nicolas> crappy network address fields of the old RFC2744 (or new Nicolas> RFC5554) cb struct is also doable. Right. I agree we should support the struct. My question is whether we should actually do anything with the network address fields. From Nicolas.Williams@oracle.com Fri Sep 10 14:31:31 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8373A6B25 for ; Fri, 10 Sep 2010 14:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dTMA6DSnIu1 for ; Fri, 10 Sep 2010 14:31:29 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1423F3A6884 for ; Fri, 10 Sep 2010 14:31:29 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8ALVqHn019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Sep 2010 21:31:54 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8ALVnh0030470; Fri, 10 Sep 2010 21:31:52 GMT Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 585261661284154311; Fri, 10 Sep 2010 14:31:51 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Sep 2010 14:31:51 -0700 Date: Fri, 10 Sep 2010 16:31:47 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100910213146.GL1121@oracle.com> References: <20100910184348.GJ1121@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 10 Sep 2010 21:31:31 -0000 On Fri, Sep 10, 2010 at 05:01:14PM -0400, Sam Hartman wrote: > Right. > I agree we should support the struct. > My question is whether we should actually do anything with the network > address fields. As RFC5554 says, end-point CB, even if the end-point CB happen to be CGA-like network addresses. Nico -- From stefan.winter@restena.lu Mon Sep 13 00:28:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BB83A6925 for ; Mon, 13 Sep 2010 00:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.189 X-Spam-Level: X-Spam-Status: No, score=-1.189 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QehLDWA726hi for ; Mon, 13 Sep 2010 00:28:58 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id 818493A6914 for ; Mon, 13 Sep 2010 00:28:58 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id AF0AF10588 for ; Mon, 13 Sep 2010 09:29:21 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9B92B10586 for ; Mon, 13 Sep 2010 09:29:21 +0200 (CEST) Message-ID: <4C8DD2D1.4010807@restena.lu> Date: Mon, 13 Sep 2010 09:29:21 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: abfab@ietf.org References: <4C7F9BFC.2090303@ieca.com> In-Reply-To: <4C7F9BFC.2090303@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 07:28:59 -0000 Hi, > I reviewed the charter and like it. I am not sure of all the IESG hot > buttons wrt new charters, but the new WG charter discussions I have > observed targeted ensuring that success (or at least initial success) > could be declared and that there is enough effort to get the work > done. I think the 1st paragraph of constraints and the deliverables > are clear about what needs to gets done first to declare success. What > I'd like to reconfirm here, on the list, is that there are in fact > still enough authors and interested reviewers for the 8 WG items > listed. So, please indicate your willingness to author a draft and/or > review particular drafts listed in the charter. I'm willing to review wg output, particularly anything related to RADIUS. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From simon@josefsson.org Mon Sep 13 04:08:43 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAFC83A697D for ; Mon, 13 Sep 2010 04:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw5iSQMyLWkm for ; Mon, 13 Sep 2010 04:08:42 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2B8363A6909 for ; Mon, 13 Sep 2010 04:08:42 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o8DB8tEO005795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Sep 2010 13:08:58 +0200 From: Simon Josefsson To: Sean Turner References: <4C7F9BFC.2090303@ieca.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100913:abfab@ietf.org::DYO95wS8iMgMm5Vq:7qB3 X-Hashcash: 1:22:100913:turners@ieca.com::ogamm3sEIr5DbCeu:k3bh Date: Mon, 13 Sep 2010 13:08:55 +0200 Message-ID: <87y6b5q4s8.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: abfab@ietf.org Subject: Re: [abfab] Moving the Charter Forward X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 11:08:43 -0000 Sean Turner writes: > I reviewed the charter and like it. I am not sure of all the IESG hot > buttons wrt new charters, but the new WG charter discussions I have > observed targeted ensuring that success (or at least initial success) > could be declared and that there is enough effort to get the work > done. I think the 1st paragraph of constraints and the deliverables > are clear about what needs to gets done first to declare success. What > I'd like to reconfirm here, on the list, is that there are in fact > still enough authors and interested reviewers for the 8 WG items > listed. So, please indicate your willingness to author a draft and/or > review particular drafts listed in the charter. I'll review drafts, and could be talked into authoring too if necessary. My focus will be on GSS-API, EAP, SAML and the application side. /Simon From turners@ieca.com Mon Sep 13 07:47:06 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FDA3A69A8 for ; Mon, 13 Sep 2010 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtAkepU-mFbD for ; Mon, 13 Sep 2010 07:47:03 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id B91FF3A69C3 for ; Mon, 13 Sep 2010 07:47:02 -0700 (PDT) Received: (qmail 49108 invoked from network); 13 Sep 2010 14:47:20 -0000 Received: from thunderfish.local (turners@96.241.1.67 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 13 Sep 2010 07:47:20 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 2h9nhK4VM1mMGmjMhKMx4xZWnqaVw828i.QSWf672X8AJ7A lJssvwzuOGRQHZ3rHL98eBw07ytAHLbJCYPzWLC.W_A7ZcnnRgojqe8bFVr7 9LiFeW9YACymWu8gbomS7afQ.fbjkttakAUyR2Nbi4ujuEc_m73etIucPTKh AMOBIHHOS384emUVdiwfsrYqnCkKLoXUlDi73Z7gst4h877coMaUtRFkVRZK F9gt4SOOArfmA6kGLa3670AdkYB3xCPuCqkfmA.7DN7ie8YKCXTRofpmqtyY EWy__CcQhPSv33JDw1h3BlkIx.T1Szgb4aQMU2PB.oEhxcNYrfiJa8REgjA- - X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8E3977.6020206@ieca.com> Date: Mon, 13 Sep 2010 10:47:19 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leif Johansson References: <4C8A0831.2040206@mnt.se> In-Reply-To: <4C8A0831.2040206@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Are we in the IESG comfort-zone? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 14:47:06 -0000 Leif, I believe we had enough people volunteer to author and review each document in the charter. I'm going to continue to socialize the draft charter and I will be adding this charter to the 2010-09-23 telechat. spt Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Sean: Do you think we are in the IESG comfort-zone wrt volunteers? > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkyKCDEACgkQ8Jx8FtbMZndyswCfUYKXNZ8U7p+3HayOIJvW+hgj > 7lgAoMZfX89GL6vbB2cxoFThgby1R32a > =uF34 > -----END PGP SIGNATURE----- > From leifj@sunet.se Mon Sep 13 11:45:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CEC3A6A8D for ; Mon, 13 Sep 2010 11:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg+BHTp6oVDv for ; Mon, 13 Sep 2010 11:45:26 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id AF5C83A6A7E for ; Mon, 13 Sep 2010 11:45:16 -0700 (PDT) Received: from kerio.nordu.net (kerio.nordu.net [109.105.111.52]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o8DIjaj5025832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2010 20:45:39 +0200 (CEST) Received: from [83.227.179.169] ([83.227.179.169]) by kerio.nordu.net; Mon, 13 Sep 2010 20:45:33 +0200 References: <4C8A0831.2040206@mnt.se> <4C8E3977.6020206@ieca.com> Content-Transfer-Encoding: quoted-printable From: "Leif Johansson" Content-Type: text/plain; charset=us-ascii In-Reply-To: <4C8E3977.6020206@ieca.com> Message-Id: <53376433-F1F6-4C65-B48C-BFF6553ACD30@sunet.se> Date: Mon, 13 Sep 2010 20:45:25 +0200 To: Sean Turner Mime-Version: 1.0 (iPhone Mail 8A400) Cc: "abfab@ietf.org" Subject: Re: [abfab] Are we in the IESG comfort-zone? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 18:45:29 -0000 Great! 13 sep 2010 kl. 16:47 skrev Sean Turner : > Leif, >=20 > I believe we had enough people volunteer to author and review each documen= t in the charter. I'm going to continue to socialize the draft charter and I= will be adding this charter to the 2010-09-23 telechat. >=20 > spt >=20 > Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Sean: Do you think we are in the IESG comfort-zone wrt volunteers? >> Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> iEYEARECAAYFAkyKCDEACgkQ8Jx8FtbMZndyswCfUYKXNZ8U7p+3HayOIJvW+hgj >> 7lgAoMZfX89GL6vbB2cxoFThgby1R32a >> =3DuF34 >> -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Mon Sep 13 16:18:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AB63A683A for ; Mon, 13 Sep 2010 16:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cujx70o2q8F for ; Mon, 13 Sep 2010 16:18:34 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 114AD3A681D for ; Mon, 13 Sep 2010 16:18:32 -0700 (PDT) Received: by us.padl.com with ESMTP id o8DNImjs018379; Mon, 13 Sep 2010 19:18:52 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20100908145619.GY1198@oracle.com> Date: Tue, 14 Sep 2010 01:18:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AE2DE8E-CAF2-4512-A7FA-B3FA3A2BE7F8@padl.com> References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> <20100908145619.GY1198@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 23:18:36 -0000 Notwithstanding my confusion reading RFC 3961 s.5.3 and exactly how the = message size m (which for RFC 3962 is one byte) relates to the the PRF = length... For key derivation where PRF length !=3D key length, we need to do = something similar to RFC 4402. So I'm proposing we do that = (counter-based PRF). On 08/09/2010, at 4:56 PM, Nicolas Williams wrote: > On Wed, Sep 08, 2010 at 10:51:25AM -0400, Sam Hartman wrote: >>>>>>> "Luke" =3D=3D Luke Howard writes: >>=20 >> Luke> What about random-to-key(rfc3961-prf(random-to-key([e]msk), >> Luke> "rfc4121-gss-eap")) >>=20 >> Luke> ? >> That works for me. >=20 > And me. >=20 -- www.padl.com | www.thisismagnolia.net From hartmans@painless-security.com Tue Sep 14 05:45:02 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA5A3A67EC for ; Tue, 14 Sep 2010 05:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h58YQjj6kRWD for ; Tue, 14 Sep 2010 05:45:01 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8C7C33A698A for ; Tue, 14 Sep 2010 05:45:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 264762017A; Tue, 14 Sep 2010 08:45:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 11ED941D3; Tue, 14 Sep 2010 08:45:07 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <1DA3B0A9-54C7-4276-A310-924A68A9B43A@padl.com> <20100908145619.GY1198@oracle.com> <5AE2DE8E-CAF2-4512-A7FA-B3FA3A2BE7F8@padl.com> Date: Tue, 14 Sep 2010 08:45:07 -0400 In-Reply-To: <5AE2DE8E-CAF2-4512-A7FA-B3FA3A2BE7F8@padl.com> (Luke Howard's message of "Tue, 14 Sep 2010 01:18:51 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josh Howlett , "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Does GSS-EAP need an acceptor subkey X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Sep 2010 12:45:02 -0000 >>>>> "Luke" == Luke Howard writes: Luke> Notwithstanding my confusion reading RFC 3961 s.5.3 and Luke> exactly how the message size m (which for RFC 3962 is one Luke> byte) relates to the the PRF length... For key derivation Luke> where PRF length != key length, we need to do something Luke> similar to RFC 4402. So I'm proposing we do that Luke> (counter-based PRF). Uh, yes. Sorry about not noticing that. From hartmans@mit.edu Tue Sep 14 07:23:18 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6DA3A6912 for ; Tue, 14 Sep 2010 07:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXg0Lb3Qz-+k for ; Tue, 14 Sep 2010 07:23:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E162E3A6909 for ; Tue, 14 Sep 2010 07:23:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8541F201C9 for ; Tue, 14 Sep 2010 10:23:40 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2504741D3; Tue, 14 Sep 2010 10:23:23 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Cc: References: <87zkvzvkge.fsf@nordberg.se> <40AC324AA6D81B4A8CF133BCFB7526E605E41B@EXC001.atlas.ukerna.ac.uk> <874oe7umyf.fsf@nordberg.se> <8E9B0731-80DB-4224-BAD9-7959E1181943@PADL.COM> <87wrqq4m03.fsf@nordberg.se> <93DD1B4C-BB4F-401C-9658-C0E5015504FC@padl.com> <878w3538od.fsf@nordberg.se> <3C5F5012-784C-4122-8801-D73813B68585@padl.com> Date: Tue, 14 Sep 2010 10:23:23 -0400 In-Reply-To: <3C5F5012-784C-4122-8801-D73813B68585@padl.com> (Luke Howard's message of "Tue, 14 Sep 2010 15:26:16 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Validation of acceptor names for the initiator X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Sep 2010 14:23:18 -0000 >>>>> "Luke" == Luke Howard writes: Luke asked how mutual authentication works and whether you needed the server to echo back some confirmation about it. Here's my answer. Yes, I think so. We may decide to "trust" the server for basic channel binding and mutual authentication. (Or we may not. It's a question of whether we want to fail-useful or fail-secure.) However for things like MTP, where we're depending on the AAA infrastructure to undersatnd a name form more complex than GSS_NT_HOSTBASED_SERVICE,we absolutely need to have some way to validate that. So, for the basic case (GSS_NT_HOSTBASED_SERVICE), the client is depending on: * A radius server near the NAS to validate the mapping of host name and probably to assert a realm * A server near the IDP to validate that the realm in question is permitted to claim that host * A server near the IDP to do any desired policy enforcement about whether the realm in question is permitted to provide the service in question to the user The initiator's interaction here are to give its idea of the acceptor name as an input to the channel binding operation via EAP. Based on discussion in emu, it looks like the initiator will receive an indication back from the EAP method about what attributes were used in performing channel binding. I.E. if it sees whatever AVP it sent the server name there in the message back from the EAP server, then it can assume mutual auth. Otherwise perhaps it should not. I don't think the acceptor/NAS is depending on anything new not already in wide EAP deployment. The only exception is that we'll need to clearly specify how the acceptor gets the initiator's name. For something like MTP, We need a way for the initiator to explain to the GSS mechanism that service-specific validation is required--presumably setting a name attribute with some token describing the expected form of validation. Then, we'll send that in our AVP and expect to see the server ack it. Actually, perhaps I'm over thinking this. Perhaps it's sufficient to simply require that if you're doing validation of a moonshot name that has more than just a host, service and realm, you must understand and accept the extra parts or you must fail the validation. That way we need no special name attributes or anything strange like that. Here's where I expect to see this appear in specs: * The next version of draft-ietf-emu-chbind should talk about the interface and indicate that you can send channel binding attributes to a server and get a set of attributes it used back * draft-howlett-eap-gss should talk about what AVPs you send the acceptor identity in as well as initiator behavior regarding channel binding and the mutual_auth bit. --Sam From turners@ieca.com Tue Sep 14 14:11:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAA93A696C for ; Tue, 14 Sep 2010 14:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo0h58WWXCCn for ; Tue, 14 Sep 2010 14:11:33 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 6FD6E3A687C for ; Tue, 14 Sep 2010 14:11:33 -0700 (PDT) Received: (qmail 21676 invoked from network); 14 Sep 2010 21:11:56 -0000 Received: from thunderfish.local (turners@96.231.127.24 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 14 Sep 2010 14:11:56 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: SXYfVt0VM1mdBayXM.2Bm2.r75Oge54XDvM8EpdNj3a.Rpi sCLLT5jkQy8vn2nL3q3xqdRuA4Ap_ta9PYMwbOnMkgs2gssS9C5F0v9AWoiw FWwy5eBCjoJN.U7G7tqBCcikdT3.ONflTtqv_cUWMLV6plx4Xa8XOzvXq.qs j98fllKITMQdqHkw6xvIYd8vD_Rr8vicrn4pYJtdT_I5mqWcpPGMZq4hTKZu _kKAFJOEZwrdUQKALZ4GOVAfaBw28_7RQnpZYgPagCLFRrf1cMZWgIzZaflG jUkDXrdDcawhBG32IUs8B4Upo5i8GBWuM7qfx3WT55_WqnIS7c_GRuA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8FE51B.903@ieca.com> Date: Tue, 14 Sep 2010 17:11:55 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leif Johansson References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> <4C7A11CC.5030003@mnt.se> In-Reply-To: <4C7A11CC.5030003@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Sep 2010 21:11:34 -0000 I'm going to reorder them before I submit them. I'm also going to do the charter/wg swap. spt Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/29/2010 03:58 AM, Keith Hazelton wrote: >> I notice that all other delivery estimates are in chronological order. Should the following: >> >> "* A standards-track protocol for carrying SAML messages in RADIUS and >> Diameter (Dec 2011)" >> >> read Dec 2010? > > Yes, somebody already pointed that out and it will go into the published > version. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkx6EcwACgkQ8Jx8FtbMZndN0wCaA6SLNpkL+iRzUkq3QJca7D+1 > xMgAmwZycF/hol04Md9rnv5hMPFYoDWf > =fJFX > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From turners@ieca.com Tue Sep 14 14:19:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC30C3A6AC1 for ; Tue, 14 Sep 2010 14:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHgmouekqRDl for ; Tue, 14 Sep 2010 14:19:08 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id CF6C43A6AA9 for ; Tue, 14 Sep 2010 14:19:08 -0700 (PDT) Received: (qmail 9700 invoked from network); 14 Sep 2010 21:19:32 -0000 Received: from thunderfish.local (turners@96.231.127.24 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 14 Sep 2010 14:19:31 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: uJAG9EEVM1kb_SbCoKFZF53ebzq1BcNooLwCD.Z7SL1gP5U 4NzZ6ziFXysWONtRIhXsoemgybQJt7MZedaNk3iPD2A7lsJpyCo5l1LcwcU1 AwHJ9dHk1KDJnCDB_tchs4OpYWh4QME51ECMdt06TkK4AJOQnCCvSnrL2IRu q0tzA3rr88K18eC4RZEbK6k33aDZ9pKk2DCF1QDIexPOqxxYc11FUfVTuSfg 19_dHV9duDVTyGZZ9WROFthHDlL1lkeAEy.tAqqOVKSHJWadzEqePs91aXlr 4GWdWtJZU7_xHlZAMJMsiigB1NbBBTJDR9VVWZr40xU.yhGPzu63XNQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8FE6E2.5050506@ieca.com> Date: Tue, 14 Sep 2010 17:19:30 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leif Johansson References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> <4C7A11CC.5030003@mnt.se> <4C8FE51B.903@ieca.com> In-Reply-To: <4C8FE51B.903@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Sep 2010 21:19:10 -0000 And I'm switching the date format to be more like others: Dec 2010 instead of (Dec 2010) at the end. One final question: Are these dates for submission to the IESG or for initial submissions? spt Sean Turner wrote: > I'm going to reorder them before I submit them. I'm also going to do > the charter/wg swap. > > spt > > Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/29/2010 03:58 AM, Keith Hazelton wrote: >>> I notice that all other delivery estimates are in chronological >>> order. Should the following: >>> >>> "* A standards-track protocol for carrying SAML messages in RADIUS and >>> Diameter (Dec 2011)" >>> >>> read Dec 2010? >> >> Yes, somebody already pointed that out and it will go into the published >> version. >> >> Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkx6EcwACgkQ8Jx8FtbMZndN0wCaA6SLNpkL+iRzUkq3QJca7D+1 >> xMgAmwZycF/hol04Md9rnv5hMPFYoDWf >> =fJFX >> -----END PGP SIGNATURE----- >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >> > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From turners@ieca.com Wed Sep 15 04:42:49 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A788F3A694E for ; Wed, 15 Sep 2010 04:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.03 X-Spam-Level: X-Spam-Status: No, score=-102.03 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFZD7qxKqX8u for ; Wed, 15 Sep 2010 04:42:47 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id E0D2F3A6830 for ; Wed, 15 Sep 2010 04:42:47 -0700 (PDT) Received: (qmail 61529 invoked from network); 15 Sep 2010 11:43:13 -0000 Received: from thunderfish.local (turners@96.231.127.24 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 15 Sep 2010 04:43:12 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: P7lxbN0VM1m4QT9cz0m.rvFCzYrvjvrNXt_8OXB9LkGhJ8Z qJhFu.9Jh5VHGFS03FmGAQ9xtcXIXl53sGoibzfQ_HwCUb6MvFgO5ahfn4a1 cPBBs9jm9QPYCZSV959AaDanLfSSBMxZ72peSppwKL2pRiV0gQYSpYQynjjU xvapWTOlS.SOWgj.12VosC3oObmd5_MIK14TSnTLx6gJNU5gRTXkvqqcS6aY Il0oAavojug9fkdXagDJONkCpF9lr6mSwjjdDzZWrrplTQqVE8SsgbUTKa3u 7FARaTWbohfOkjunJ0rEJLTmyOClYJWrcJvKyvKNQJ4U9lI17G7YITA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C90B14F.9080401@ieca.com> Date: Wed, 15 Sep 2010 07:43:11 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: abfab@ietf.org References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> <4C7A11CC.5030003@mnt.se> <4C8FE51B.903@ieca.com> <4C8FE6E2.5050506@ieca.com> In-Reply-To: <4C8FE6E2.5050506@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 11:42:49 -0000 I'm going to tweak a couple of things in the Deliverables and Goals/Milestones: * First, I split them - most charters I've been seeing do so so I'm going with the flow. * Second, I think we need to indicate whether each deliverable is headed for informational/standards tracks. 4 had no indication. I added them in between * * (will remove the * * when I send it in for review (tomorrow)). I assumed that the use cases and architecture drafts will be informational and that the drafts that updated existing standards track RFCs will, of course, be standards track. * Third, added initial submission as WG item and IESG submission times. I slid the IESG submission times to the right a bit. If we're early great. Any raging objections to the following tweaks: Deliverables ------------ 1. An *informational* document describing applicable use cases. 2. An *informational* architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture. 3. A *standards-track* update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case. 4. A standards-track solution for using EAP methods to provide authentication within the application. 5. A *standards-track* update to the EMSK root key applicability statement in RFC 5295. 6. A standards-track description of GSS names and name attributes required by the solution. 7. Informational descriptions of usability and user-interface concerns related to this work. 8. A standards-track protocol for carrying SAML messages in RADIUS and Diameter. Goals and Milestones -------------------- Oct 2010 Submit Internet draft describing applicable use cases as initial WG item. Oct 2010 Submit Internet draft describing the architecture as initial WG item. Oct 2010 Submit Internet draft that updates the EAP applicability statement as initial WG item. Oct 2010 Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item. Oct 2010 Submit Internet draft that updates the EMSK root key applicability statement as initial WG item. Oct 2010 Submit Internet draft that describes GSS names and name attributes as initial WG item. Oct 2010 Submit Internet draft for usability and user-interface concerns as initial WG item. Oct 2010 Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item. Mar 2011 Submit Internet draft describing applicable use cases to the IESG for consideration. Mar 2011 Submit Internet draft describing the architecture to the IESG for consideration. Aug 2011 Submit Internet draft that updates the EAP applicability statement to the IESG for consideration. Aug 2011 Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration. Nov 2011 Submit Internet draft that updates the EMSK root key applicability statement to the IESG for consideration. Nov 2011 Submit Internet draft that describes GSS names and name attributes to the IESG for consideration. Nov 2011 Submit Internet draft for usability and user-interface concerns to the IESG for consideration. Mar 2012 Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration. spt Sean Turner wrote: > And I'm switching the date format to be more like others: > > Dec 2010 instead of (Dec 2010) at the end. > > One final question: Are these dates for submission to the IESG or for > initial submissions? > > spt > > Sean Turner wrote: >> I'm going to reorder them before I submit them. I'm also going to do >> the charter/wg swap. >> >> spt >> >> Leif Johansson wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 08/29/2010 03:58 AM, Keith Hazelton wrote: >>>> I notice that all other delivery estimates are in chronological >>>> order. Should the following: >>>> >>>> "* A standards-track protocol for carrying SAML messages in RADIUS and >>>> Diameter (Dec 2011)" >>>> >>>> read Dec 2010? >>> >>> Yes, somebody already pointed that out and it will go into the published >>> version. >>> >>> Cheers Leif >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.10 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkx6EcwACgkQ8Jx8FtbMZndN0wCaA6SLNpkL+iRzUkq3QJca7D+1 >>> xMgAmwZycF/hol04Md9rnv5hMPFYoDWf >>> =fJFX >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >> > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From leifj@sunet.se Wed Sep 15 04:59:05 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F643A6BA6 for ; Wed, 15 Sep 2010 04:59:05 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtkZ3Qu5H3Zn for ; Wed, 15 Sep 2010 04:59:04 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 1FD673A6950 for ; Wed, 15 Sep 2010 04:59:03 -0700 (PDT) Received: from [91.206.174.169] (g7.hq.kirei.se [91.206.174.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o8FBxP4d010071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 15 Sep 2010 13:59:27 +0200 (CEST) Message-ID: <4C90B51C.7040503@sunet.se> Date: Wed, 15 Sep 2010 13:59:24 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: abfab@ietf.org References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> <4C7A11CC.5030003@mnt.se> <4C8FE51B.903@ieca.com> <4C8FE6E2.5050506@ieca.com> <4C90B14F.9080401@ieca.com> In-Reply-To: <4C90B14F.9080401@ieca.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 11:59:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/15/2010 01:43 PM, Sean Turner wrote: > I'm going to tweak a couple of things in the Deliverables and > Goals/Milestones: > > * First, I split them - most charters I've been seeing do so so I'm > going with the flow. That was always the intent - I kept them together to keep the thing short for the discussions. > > * Second, I think we need to indicate whether each deliverable is > headed for informational/standards tracks. 4 had no indication. I added > them in between * * (will remove the * * when I send it in for review > (tomorrow)). I assumed that the use cases and architecture drafts will > be informational and that the drafts that updated existing standards > track RFCs will, of course, be standards track. > > * Third, added initial submission as WG item and IESG submission > times. I slid the IESG submission times to the right a bit. If we're > early great. > Sounds good! For the record I don't have any objections to the deliverables or timeline. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyQtRgACgkQ8Jx8FtbMZndbxQCfXZJ4LYs/GE3+e0aEtbWsoToL 9dAAn0cZ6wXP47VsPd+WvL5K4DhM1Rdw =b4UA -----END PGP SIGNATURE----- From klaas@cisco.com Wed Sep 15 05:35:26 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244B13A6BDA for ; Wed, 15 Sep 2010 05:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyKgSuu0T7uO for ; Wed, 15 Sep 2010 05:35:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3C65B3A6BCE for ; Wed, 15 Sep 2010 05:35:12 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwGAMpakExAZnwM/2dsb2JhbACUF41bcaYbnAyFQQSKLA X-IronPort-AV: E=Sophos;i="4.56,371,1280707200"; d="scan'208";a="159526607" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Sep 2010 12:35:37 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8FCZaai014179 for ; Wed, 15 Sep 2010 12:35:37 GMT Message-ID: <4C90BD98.1010001@cisco.com> Date: Wed, 15 Sep 2010 14:35:36 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: abfab@ietf.org References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> <4C7A11CC.5030003@mnt.se> <4C8FE51B.903@ieca.com> <4C8FE6E2.5050506@ieca.com> <4C90B14F.9080401@ieca.com> <4C90B51C.7040503@sunet.se> In-Reply-To: <4C90B51C.7040503@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 12:35:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/15/10 1:59 PM, Leif Johansson wrote: looks good! > On 09/15/2010 01:43 PM, Sean Turner wrote: >> I'm going to tweak a couple of things in the Deliverables and >> Goals/Milestones: > >> * First, I split them - most charters I've been seeing do so so I'm >> going with the flow. > > That was always the intent - I kept them together to keep the thing > short for the discussions. > > >> * Second, I think we need to indicate whether each deliverable is >> headed for informational/standards tracks. 4 had no indication. I added >> them in between * * (will remove the * * when I send it in for review >> (tomorrow)). I assumed that the use cases and architecture drafts will >> be informational and that the drafts that updated existing standards >> track RFCs will, of course, be standards track. > >> * Third, added initial submission as WG item and IESG submission >> times. I slid the IESG submission times to the right a bit. If we're >> early great. > > > Sounds good! > > For the record I don't have any objections to the deliverables or > timeline. > > Cheers Leif > _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyQvZgACgkQH2Wy/p4XeFIaXwCfZ6Za8q+imNJlN7GV87eCEtG2 CJQAn3sbGvPf10kjx70f+bZSBE+7sToc =kAcv -----END PGP SIGNATURE----- From hartmans@painless-security.com Wed Sep 15 05:43:14 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0C13A6965 for ; Wed, 15 Sep 2010 05:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofPUIya4Ig5m for ; Wed, 15 Sep 2010 05:43:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CD0B43A6BC7 for ; Wed, 15 Sep 2010 05:43:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2982F20008; Wed, 15 Sep 2010 08:43:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D4E95412A; Wed, 15 Sep 2010 08:43:14 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> <4C7A11CC.5030003@mnt.se> <4C8FE51B.903@ieca.com> <4C8FE6E2.5050506@ieca.com> <4C90B14F.9080401@ieca.com> Date: Wed, 15 Sep 2010 08:43:14 -0400 In-Reply-To: <4C90B14F.9080401@ieca.com> (Sean Turner's message of "Wed, 15 Sep 2010 07:43:11 -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 Cc: abfab@ietf.org Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 12:43:14 -0000 Somehow in all these edits, the set of documents that the working group will produce has been codified in the charter. That's bad. The set of deliverables should be in the charter. That is' we're delivering an GSS EAP mechanism. However, it should not take a recharter if we want to split that across two documents for some reason. So, the word document should basically never appear in the deliverables section. It's fine for it to appear in milestones. I mostly agree with your assumptions about track. I suspect that the applicability updates may be BCPs--not so much because of strong level of consensus, but because I don't know how to have an interoperable applicability statement. The AS updates definitely cannot be informational. - --Sam From hannes.tschofenig@gmx.net Thu Sep 23 08:46:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7820F3A6A11 for ; Thu, 23 Sep 2010 08:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.974 X-Spam-Level: X-Spam-Status: No, score=-100.974 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcSfQpZQR+mu for ; Thu, 23 Sep 2010 08:46:09 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 042E23A6810 for ; Thu, 23 Sep 2010 08:46:08 -0700 (PDT) Received: (qmail invoked by alias); 23 Sep 2010 15:46:37 -0000 Received: from unknown (EHLO [10.254.0.174]) [192.100.123.77] by mail.gmx.net (mp061) with SMTP; 23 Sep 2010 17:46:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Et/ZSoCNERx01BL0/U3Mjc5ogNR/YeYNXQLUH1N n1GLExhawg4rAm Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Thu, 23 Sep 2010 18:46:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8761945B-5A81-4972-A0EF-349BE0EF41BD@gmx.net> References: <20100920210002.96EF53A6876@core3.amsl.com> To: abfab@ietf.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [abfab] Fwd: Internet Privacy Workshop: 8 and 9 December 2010 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 15:46:10 -0000 Hi all,=20 I believe that this workshop is relevant to this group. You may consider = submitting a position paper.=20 Ciao Hannes Begin forwarded message: > From: IETF Secretariat > Date: September 21, 2010 12:00:02 AM GMT+03:00 > To: ietf-announce@ietf.org > Subject: Internet Privacy Workshop: 8 and 9 December 2010=20 >=20 > The Internet Architecture Board (IAB), World Wide Web Consortium = (W3C), > Internet Society (ISOC) and Massachusetts Institute of Technology = (MIT) > will hold a joint Internet privacy workshop on 8 and 9 December 2010 = at > MIT, Cambridge, Massachusetts on the question: >=20 > "How Can Technology Help to Improve Privacy on the Internet?" >=20 > Information about who we are, what we own, what we have experienced, = how > we behave, where we are located, and how we can be reached are among = the > most personal pieces of information about us. This information is > increasingly being made more easily available electronically via the > Internet, often without the consent of the subject. >=20 > The question for the workshop therefore is: How can we ensure that > architectures and technologies for the Internet, including the World > Wide Web, are developed in ways that respects users=82 intentions = about > their privacy? >=20 > This workshop aims to explore the experience and approaches taken by > developers of Internet including Web technology, when designing = privacy > into these protocols and architectures. Engineers know that many = design > considerations need to be taken into account when developing = solutions. > Balancing between the conflicting goals of openness, privacy, = economics, > and security is often difficult, as illustrated by Clark, et al. in > "Tussle in Cyberspace: Defining Tomorrow's Internet", see > http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > As a member of the technical community, we invite you to share your > experiences by participating in this important workshop. Workshop > participants will focus on the core privacy challenges, the approaches > taken to deal with them, and the status of the work in the field. The > objective is to draw a relationship with other application areas and > other privacy work in an effort to discuss how specific approaches can > be generalized. >=20 > Interested parties must submit a brief contribution describing their > work or approach as it relates to the workshop theme. We welcome > visionary ideas for how to tackle Internet privacy problems, as well = as > write-ups of existing concepts, deployed technologies, and > lessons-learned from successful or failed attempts at deploying = privacy > technologies. Contributions are not required to be original in = content. >=20 > Submitters of accepted position papers will be invited to the = workshop. > The workshop will be structured as a series of working sessions, > punctuated by invited speakers, who will present relevant background > information or controversial ideas that will motivate participants to > reach a deeper understanding of the subject. The organizing committee > may ask submitters of particularly topical papers to present their = ideas > and experiences to the workshop. >=20 > We will publish submitted position papers and slides together with a > summary report of the workshop. >=20 > There are no plans for any remote participation in this workshop. >=20 > To be invited to the workshop, please submit position papers to > privacy@iab.org by November, 5th 2010. >=20 > More detailed information about the workshop, including further = details > about the position paper requirements, is available at: > http://www.iab.org/about/workshops/privacy/ >=20 > We look forward to your input, > Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), = Karen > O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen > Sollins (MIT), Hannes Tschofenig (IAB) > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From root@core3.amsl.com Tue Sep 28 10:00:03 2010 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1F0643A6D7B; Tue, 28 Sep 2010 10:00:02 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100928170003.1F0643A6D7B@core3.amsl.com> Date: Tue, 28 Sep 2010 10:00:02 -0700 (PDT) Cc: abfab@ietf.org Subject: [abfab] WG Review: Application Bridging for Federated Access Beyond web (abfab) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@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: Tue, 28 Sep 2010 17:00:03 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 5, 2010. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ Status: Proposed Working Group Last updated: 2010-09-16 v7 Chairs Leif Johansson Klaas Wierenga Security Area Directors: Sean Turner Tim Polk Security Area Advisor: Sean Turner Mailing Lists: General Discussion: abfab@ietf.org To Subscribe: Archive: Problem Statement Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter. Constraints ----------- Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for Pseudo Random Function (PRF) is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL (RFC 4422) applications, which can use GSS- API mechanisms through GS2 (RFC5081). Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC) and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ 1. Descriptions of applicable use cases (informational). 2. An architecture that describes how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (informational). 3. A standards-track update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case. 4. A standards-track solution for using EAP methods to provide authentication within the application. 5. A standards-track update to the EMSK root key applicability statement in RFC 5295. 6. A standards-track description of GSS names and name attributes required by the solution. 7. Descriptions of usability and user-interface concerns related to this work (informational). 8. A standards-track protocol for carrying SAML messages in RADIUS and Diameter. Goals and Milestones -------------------- Oct 2010 Submit Internet draft describing applicable use cases as initial WG item. Oct 2010 Submit Internet draft describing the architecture as initial WG item. Oct 2010 Submit Internet draft that updates the EAP applicability statement as initial WG item. Oct 2010 Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item. Oct 2010 Submit Internet draft that updates the EMSK root key applicability statement as initial WG item. Oct 2010 Submit Internet draft that describes GSS names and name attributes as initial WG item. Oct 2010 Submit Internet draft for usability and user-interface concerns as initial WG item. Oct 2010 Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item. Dec 2010 Submit Internet draft describing applicable use cases to the IESG for consideration. Dec 2010 Submit Internet draft describing the architecture to the IESG for consideration. May 2011 Submit Internet draft that updates the EAP applicability statement to the IESG for consideration. May 2011 Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration. Aug 2011 Submit Internet draft that updates the EMSK root key applicability statement to the IESG for consideration. Aug 2011 Submit Internet draft that describes GSS names and name attributes to the IESG for consideration. Aug 2011 Submit Internet draft for usability and user-interface concerns to the IESG for consideration. Dec 2011 Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration.