From wmills@yahoo-inc.com Fri Jul 1 13:10:48 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B636111E80D1 for ; Fri, 1 Jul 2011 13:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.499 X-Spam-Level: X-Spam-Status: No, score=-11.499 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWh6fWxLGvOd for ; Fri, 1 Jul 2011 13:10:41 -0700 (PDT) Received: from nm9-vm3.bullet.mail.ne1.yahoo.com (nm9-vm3.bullet.mail.ne1.yahoo.com [98.138.91.139]) by ietfa.amsl.com (Postfix) with SMTP id 19FF911E818A for ; Fri, 1 Jul 2011 13:10:41 -0700 (PDT) Received: from [98.138.90.52] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jul 2011 20:10:37 -0000 Received: from [98.138.89.161] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jul 2011 20:10:37 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 01 Jul 2011 20:10:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 897172.6238.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 16042 invoked by uid 60001); 1 Jul 2011 20:10:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1309551037; bh=XXfTSGeRKVURrns0depTK7HQnzX0GJwwZ8ZygTfKasQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=IHzuy8yQmIL2QevVfuPlvaBRleX7FM/kmZFQUl7ziDUszhjfOdyBAHJAaGik+EdXgz+J0QP7UeCvYSBZnfi/YVeDfHuxMpUaXV4lTE0y0UGzFbY7NBCMpVdNWY1J7gT3MYju0eGt0c5wIecR+GgoegmpyfTgpND1AQ7yAdH9Y+U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Y4bAHiwqhjludIeemPuBH2zm8LnTCIi7Dp2j+drkTU9eBmrz2+Feecz2D3u7ft4To9c1mFPOaAy9bLcToBFvGVG3lFb3ic7QAwFawn7B+8xQo/36Orcc4o4q8n4yxSw/bYsYMo/RWu9tcSr9q8KQp3R+LtV8xDXTX2HDVM1h1GI=; X-YMail-OSG: lLAh9c4VM1mFavuDNphMEofBbF4k5gMHuhcUJVxrZ6P.QrX aTZ3AaqQHQBDf2T7ER7tSTXQzohbU1C2xYyKVY1.fW2nNVOfKgEO0DA6o4SA 1ljQq_afcbCoTqdRnsNV4rKlBJLyv69xQZg.Tx0WWk2Qx4cLapUNzPrWqhuM rZV0DFdbwE_KfxM4EwzpjvN8hwouWlB8MLKzX5Jh7uBAEFW1m9GSSeUxdihm DqFDCVUZulX_VxJj6B9_Wwt6EN13FQg4LjuzJPMQ5C.X13PfgaI1b4dz75Mb x125LUEzPr2VArnO5_KcPvUP.BEvjCyPCWQj4erX_1gsKl2KVk3s7kXOkreg Nwfba7ENXTb0fAv62xzkv56WZMopuZn3QGDxa4krQjIpy Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Fri, 01 Jul 2011 13:10:37 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.310352 Message-ID: <1309551037.53973.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Fri, 1 Jul 2011 13:10:37 -0700 (PDT) From: "William J. Mills" To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1826041792-1309551037=:53973" Subject: [kitten] How long should the confirmation email take for a submission? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:10:48 -0000 --0-1826041792-1309551037=:53973 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I submitted a new draft and have not seen the confirmation mail yet?=A0 It = was pretty immediate the previous times...=A0 how long should it take?=0A= =0AThanks,=0A=0A-bill=0A --0-1826041792-1309551037=:53973 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I su= bmitted a new draft and have not seen the confirmation mail yet?  It w= as pretty immediate the previous times...  how long should it take?

Thanks,

-bill
--0-1826041792-1309551037=:53973-- From shawn.emery@oracle.com Wed Jul 6 10:22:50 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2991121F88D5 for ; Wed, 6 Jul 2011 10:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hxYlFtYK+HP for ; Wed, 6 Jul 2011 10:22:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id A133F21F88D4 for ; Wed, 6 Jul 2011 10:22:49 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p66HMlNN017431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Jul 2011 17:22:49 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p66HMlA9024136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2011 17:22:47 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p66HMfNv004457 for ; Wed, 6 Jul 2011 12:22:41 -0500 Received: from [10.7.250.160] (/10.7.250.160) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Jul 2011 10:22:41 -0700 Message-ID: <4E1499D9.4030905@oracle.com> Date: Wed, 06 Jul 2011 11:22:33 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110609 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: kitten@ietf.org References: <1309551037.53973.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1309551037.53973.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------060601000000010306060508" X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A02020A.4E1499E9.0078:SCFMA922111,ss=1,re=-4.000,fgs=0 Subject: Re: [kitten] How long should the confirmation email take for a submission? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:22:50 -0000 This is a multi-part message in MIME format. --------------060601000000010306060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/ 1/11 02:10 PM, William J. Mills wrote: > I submitted a new draft and have not seen the confirmation mail yet? > It was pretty immediate the previous times... how long should it take? I'll check w/the tools administrator. Shawn. -- --------------060601000000010306060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/ 1/11 02:10 PM, William J. Mills wrote:
I submitted a new draft and have not seen the confirmation mail yet?  It was pretty immediate the previous times...  how long should it take?

I'll check w/the tools administrator.

Shawn.
--
--------------060601000000010306060508-- From wmills@yahoo-inc.com Thu Jul 7 11:53:02 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933861F0CA7 for ; Thu, 7 Jul 2011 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg78iR6B3v3T for ; Thu, 7 Jul 2011 11:53:01 -0700 (PDT) Received: from nm25-vm0.bullet.mail.ac4.yahoo.com (nm25-vm0.bullet.mail.ac4.yahoo.com [98.139.52.240]) by ietfa.amsl.com (Postfix) with SMTP id 896291F0CA5 for ; Thu, 7 Jul 2011 11:53:01 -0700 (PDT) Received: from [98.139.52.194] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jul 2011 18:52:56 -0000 Received: from [98.139.52.177] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jul 2011 18:52:56 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 07 Jul 2011 18:52:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 873081.81608.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 35233 invoked by uid 60001); 7 Jul 2011 18:52:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1310064776; bh=iGwDGreXJd53k8qV5xPo0KX6Klh1FMR/uJM9bHt5Hl4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=VcERXK3pJeywj66hpZGGp+4mDFadw8ZHEHCmKWhid0XY6VVHFBC+Fiz7rC1l1/7po/DsCpaEIvzy0P+EfCsoSq2ac2YpX23z8NtqP0MlaF5iJ4uUENi2uOylgogsftbgnSeFnUnEzJ+oos3L2+TTaXkyZgcpdr7EQxeCgcpLj5E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=iGo0+FGOIIc4fwfVChLfwh299/ARNc918CKAlVuZs+nD4m20pFKsATGpdJQ0uTKEgCj1cAxcxlfSF37f0FKRqv3xbMK8P2Vey8WPXJQW+U1/ntb/IBUqSjo5wG5qCsEBftGA30i3PBm40y3zM2Oxf22xUE/RKHkfWik/fLcabLk=; X-YMail-OSG: Y6E10GQVM1mJZPJi2mve8f3ErSAacevD_AStQ.6mWIKD765 g75c8B.tz0ppag1Hfiw271V_WUuUS9rp5pkzqf7oNCsIaViwhGpTeJID5sfc DRLpIpOHwfTBkj7VI3R2YOKCTuJFd2drlQ_ZUAyzUhFLb_A6.yzB7Nyl7IvM U412_ru9SbeSl0XOym.vXAI4x.AYYlWBpqOZKc_413OwZh5JiC1H7JKokAA5 ZF_ze3fSfhmxWzK7ELUm1n_00TtcZqf.LKfdoJhSyia1MOpJ4U4TCSfAUIOH PA80oW94Xvyz8flBoBBoSUPhujz_gKtltyOKHcbtURZxn2uwoiI8youdgWQw raNYFNi9Lsf7Kbk1wlbWNgxPtvy93GnpbnJd3q4F93AZioOkJezuY2QyW6H9 MzlyKRw0MMZV1e1eZcILnsoq3HFUjVMwS8ZsEmlUdjP9DYsqRoevCVq8MS1c CnptrjthF_ocfJwMuEv0- Received: from [216.145.52.206] by web31801.mail.mud.yahoo.com via HTTP; Thu, 07 Jul 2011 11:52:56 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.310352 Message-ID: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 7 Jul 2011 11:52:56 -0700 (PDT) From: "William J. Mills" To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-182988272-1310064776=:32123" Subject: [kitten] New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:53:02 -0000 --0-182988272-1310064776=:32123 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI've posted a new draft.=A0 I believe there is one open issue, and= that is whether we're going to include text defining how Tunneled HTTP aut= hentication (started as OAuth) works with GSS-API. I am coming more and mor= e to the opinion that the GSS-API definition is going to be very auth mecha= nism specific.=A0 This draft only defines what SASL needs currently, which = is user auth.=A0 GSS-API has message integrity as well, and possibly other = things that can be mapped into HTTP auth schemes, and I think it's going to= be=A0 required that the auth schemes define their capabilities and GSS_API= mappings.=0A=0AThe draft also fixes the channel binding text, not tls-uniq= ue specific. Also defining how the CB data is properly generated.=0A=0ASub= ject to the open issue above (which could be significant) I think this is c= lose to a last call.=0A=0ADoes this draft need some discussion time in Queb= ec?=A0 If so I'll need to make travel plans.=0A=0AThanks,=0A=0A-bill=0A=0A= =0AMeta-Data from the Draft=0ADocumentdraft-mills-kitten-sasl-oauth =0A[Vie= w first two pages] =0A=09* [Txt version ]=0A=09* [Pdf version ]=0A=09* [Xml= version ] =0ARevision03 =0AWGIndividual Submission =0ADocument date2011-07= -01 =0ASubmission date2011-07-02 =0ATitleTunneled HTTP Authentication For S= ASL =0AAuthor information=0AAuthor 1William Mills = =0AAuthor 2Tim Showalter =0AAuthor 3Hannes Tschofen= ig =0AAbstractSimple Authentication and Securit= y Layer (SASL) is a framework for=0Aproviding authentication and data secur= ity services in connection-=0Aoriented protocols via replaceable mechanisms= . OAuth is a protocol=0Aframework for delegated HTTP authentication and th= ereby provides a=0Amethod for clients to access a protected resource on beh= alf of a=0Aresource owner.=0A=0AThis document defines the use of HTTP authe= ntication over SASL, and=0Aadditionally defines authorization and token iss= uing endpoint=0Adiscovery. Thereby, it enables schemes defined within the = OAuth=0Aframework for non-HTTP-based application protocols.=0A=0AA signific= ant benefit of OAuth for usage in clients that usually=0Astore passwords is= storing tokens instead of passwords. This is much=0Alower risk since toke= ns can be more limited in scope of access and=0Acan be managed and revoked = separately from the user credential=0A(password).=0A =0APages24 --0-182988272-1310064776=:32123 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I've posted a new draft.  I believe there is one open issue, and tha= t is whether we're going to include text defining how Tunneled HTTP authent= ication (started as OAuth) works with GSS-API. I am coming more and more to= the opinion that the GSS-API definition is going to be very auth mechanism= specific.  This draft only defines what SASL needs currently, which i= s user auth.  GSS-API has message integrity as well, and possibly othe= r things that can be mapped into HTTP auth schemes, and I think it's going = to be  required that the auth schemes define their capabilities and GS= S_API mappings.

The draft also fixes the channel binding text, not t= ls-unique specific. Also defining how the CB data is properly generated.
Subject to the open issue above (which could be significant) I think this is close to a last call.

Does this draft need some discu= ssion time in Quebec?  If so I'll need to make travel plans.

Th= anks,

-bill

Meta-Data from the Draft

=0A=0A=0A=0ADocument=0A draft-mil= ls-kitten-sasl-oauth=0A
[View first two pages]=0A=0A=0A=0A=0A=0ARevision03=0AWGIndividual Submission=0A= Document date2011-07-01=0ASubmission dat= e2011-07-02=0ATitleTunneled HTTP Authen= tication For SASL=0AAuthor information= =0A=0A=0A=0AAuthor 1William Mills &l= t;wmills@yahoo-inc.com>=0A=0AAuthor 2= Tim Showalter <timshow@yahoo-inc.com>=0A=0AAuthor 3Hannes Tschofenig <hannes.tschofenig@= gmx.net>=0A=0A=0AAbstract Simple Authentica= tion and Security Layer (SASL) is a framework for
providing authentic= ation and data security services in connection-
oriented protocols vi= a replaceable mechanisms. OAuth is a protocol
framework for delegate= d HTTP authentication and thereby provides a
method for clients to ac= cess a protected resource on behalf of a
resource owner.

Th= is document defines the use of HTTP authentication over SASL, and
add= itionally defines authorization and token issuing endpoint
discovery.= Thereby, it enables schemes defined within the OAuth
framework for = non-HTTP-based application protocols.

A significant benefit of OA= uth for usage in clients that usually
store passwords is storing toke= ns instead of passwords. This is much
lower risk since tokens can be= more limited in scope of access and
can be managed and revoked separ= ately from the user credential
(password).
=0APages24=
--0-182988272-1310064776=:32123-- From wwwrun@rfc-editor.org Fri Jul 8 17:42:39 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE621F8620; Fri, 8 Jul 2011 17:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1btSpF3hz8mY; Fri, 8 Jul 2011 17:42:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id DB77921F8539; Fri, 8 Jul 2011 17:41:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9B82198C52C; Fri, 8 Jul 2011 17:31:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110709003130.9B82198C52C@rfc-editor.org> Date: Fri, 8 Jul 2011 17:31:30 -0700 (PDT) Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 6331 on Moving DIGEST-MD5 to Historic X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:42:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6331 Title: Moving DIGEST-MD5 to Historic Author: A. Melnikov Status: Informational Stream: IETF Date: July 2011 Mailbox: Alexey.Melnikov@isode.com Pages: 6 Characters: 14047 Obsoletes: RFC2831 I-D Tag: draft-ietf-kitten-digest-to-historic-04.txt URL: http://www.rfc-editor.org/rfc/rfc6331.txt This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From shawn.emery@oracle.com Sun Jul 10 23:46:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850CC21F8A66 for ; Sun, 10 Jul 2011 23:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koAnnCyPAEJw for ; Sun, 10 Jul 2011 23:46:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id A122A21F853B for ; Sun, 10 Jul 2011 23:46:29 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6B6kRIh012961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Jul 2011 06:46:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6B6kQFM027221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jul 2011 06:46:27 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6B6kLY8028828 for ; Mon, 11 Jul 2011 01:46:21 -0500 Received: from [10.7.250.160] (/10.7.250.160) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 10 Jul 2011 23:46:21 -0700 Message-ID: <4E1A9C34.3010202@oracle.com> Date: Mon, 11 Jul 2011 00:46:12 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110609 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: kitten@ietf.org References: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------020606000502060400010608" X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E1A9C45.0038:SCFMA922111,ss=1,re=-6.300,fgs=0 Subject: Re: [kitten] New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 06:46:30 -0000 This is a multi-part message in MIME format. --------------020606000502060400010608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/ 7/11 12:52 PM, William J. Mills wrote: > Hi, > > I've posted a new draft. I believe there is one open issue, and that > is whether we're going to include text defining how Tunneled HTTP > authentication (started as OAuth) works with GSS-API. I am coming more > and more to the opinion that the GSS-API definition is going to be > very auth mechanism specific. This draft only defines what SASL needs > currently, which is user auth. GSS-API has message integrity as well, > and possibly other things that can be mapped into HTTP auth schemes, > and I think it's going to be required that the auth schemes define > their capabilities and GSS_API mappings. > > The draft also fixes the channel binding text, not tls-unique > specific. Also defining how the CB data is properly generated. > > Subject to the open issue above (which could be significant) I think > this is close to a last call. > > Does this draft need some discussion time in Quebec? If so I'll need > to make travel plans. Of course it is always helpful to be there, but is not a requirement. There are a number of ways that we have joined remote participants to the sessions in the past; WebEx, Skype, jabber, chair, co-author, etc. However, is it possible that we can resolve the open issue before the session? Shawn. -- > > > Meta-Data from the Draft > > Document draft-mills-kitten-sasl-oauth > [View first two pages] > > > > * [Txt version ] > > * [Pdf version ] > > * [Xml version ] > > > Revision 03 > WG Individual Submission > Document date 2011-07-01 > Submission date 2011-07-02 > Title Tunneled HTTP Authentication For SASL > Author information > Author 1 William Mills > Author 2 Tim Showalter > Author 3 Hannes Tschofenig > Abstract Simple Authentication and Security Layer (SASL) is a > framework for > providing authentication and data security services in connection- > oriented protocols via replaceable mechanisms. OAuth is a protocol > framework for delegated HTTP authentication and thereby provides a > method for clients to access a protected resource on behalf of a > resource owner. > > This document defines the use of HTTP authentication over SASL, and > additionally defines authorization and token issuing endpoint > discovery. Thereby, it enables schemes defined within the OAuth > framework for non-HTTP-based application protocols. > > A significant benefit of OAuth for usage in clients that usually > store passwords is storing tokens instead of passwords. This is much > lower risk since tokens can be more limited in scope of access and > can be managed and revoked separately from the user credential > (password). > Pages 24 > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------020606000502060400010608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/ 7/11 12:52 PM, William J. Mills wrote:
Hi,

I've posted a new draft.  I believe there is one open issue, and that is whether we're going to include text defining how Tunneled HTTP authentication (started as OAuth) works with GSS-API. I am coming more and more to the opinion that the GSS-API definition is going to be very auth mechanism specific.  This draft only defines what SASL needs currently, which is user auth.  GSS-API has message integrity as well, and possibly other things that can be mapped into HTTP auth schemes, and I think it's going to be  required that the auth schemes define their capabilities and GSS_API mappings.

The draft also fixes the channel binding text, not tls-unique specific. Also defining how the CB data is properly generated.

Subject to the open issue above (which could be significant) I think this is close to a last call.

Does this draft need some discussion time in Quebec?  If so I'll need to make travel plans.

Of course it is always helpful to be there, but is not a requirement.  There are a number of ways that we have joined remote participants to the sessions in the past; WebEx, Skype, jabber, chair, co-author, etc.  However, is it possible that we can resolve the open issue before the session?

Shawn.
--

Meta-Data from the Draft

Document draft-mills-kitten-sasl-oauth
[View first two pages]
Revision 03
WG Individual Submission
Document date 2011-07-01
Submission date 2011-07-02
Title Tunneled HTTP Authentication For SASL
Author information
Author 1 William Mills <wmills@yahoo-inc.com>
Author 2 Tim Showalter <timshow@yahoo-inc.com>
Author 3 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Abstract Simple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in connection-
oriented protocols via replaceable mechanisms. OAuth is a protocol
framework for delegated HTTP authentication and thereby provides a
method for clients to access a protected resource on behalf of a
resource owner.

This document defines the use of HTTP authentication over SASL, and
additionally defines authorization and token issuing endpoint
discovery. Thereby, it enables schemes defined within the OAuth
framework for non-HTTP-based application protocols.

A significant benefit of OAuth for usage in clients that usually
store passwords is storing tokens instead of passwords. This is much
lower risk since tokens can be more limited in scope of access and
can be managed and revoked separately from the user credential
(password).
Pages 24 

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

--------------020606000502060400010608-- From internet-drafts@ietf.org Mon Jul 11 04:24:29 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1020721F8B07; Mon, 11 Jul 2011 04:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtJM1NcEojUD; Mon, 11 Jul 2011 04:24:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25AD21F8625; Mon, 11 Jul 2011 04:24:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711112428.23068.89439.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 04:24:28 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 11:24:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL & GSS-API Mechanism for OpenID Author(s) : Eliot Lear Hannes Tschofenig Henry Mauldin Simon Josefsson Filename : draft-ietf-kitten-sasl-openid-04.txt Pages : 26 Date : 2011-07-11 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-04.txt From lear@cisco.com Mon Jul 11 04:26:12 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABF021F8B1B for ; Mon, 11 Jul 2011 04:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.604 X-Spam-Level: X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugwr2HWihEB0 for ; Mon, 11 Jul 2011 04:26:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 237A121F8B1A for ; Mon, 11 Jul 2011 04:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1675; q=dns/txt; s=iport; t=1310383572; x=1311593172; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0W4mGzo01bnU2buBytOOhzQ/J694CgKIjR8mHWGM+RA=; b=OBSvuK78/3UIPwcG/ol6BoSbBRjq/5+8Ab5sfTtolvW0BHr4LTolMruF AhScqmqD9NjrHC7H2P34Qgr8JBe020Fh89L913cEQrS4nl4x0IOuAEf19 j/W+N/lmLnductPU753DxpX6tDby2JXA0SXoLBUE8Ucd7qunlp2bwpXxN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwHAPTcGk6Q/khL/2dsb2JhbABGDYRElAGOdHepI40dkEKBK4F4ggiBDwSSVJBJ X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="100693421" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Jul 2011 11:26:11 +0000 Received: from elear-mac.local (dhcp-10-61-97-187.cisco.com [10.61.97.187]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6BBQArf028970 for ; Mon, 11 Jul 2011 11:26:11 GMT Message-ID: <4E1ADDD3.7060207@cisco.com> Date: Mon, 11 Jul 2011 13:26:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: kitten@ietf.org References: <20110711112428.23068.89439.idtracker@ietfa.amsl.com> In-Reply-To: <20110711112428.23068.89439.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 11:26:13 -0000 This version resolves some ABNF issues as well as an IANA consideration for the OID. No substantive changes from WGLC. Eliot On 7/11/11 1:24 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : A SASL & GSS-API Mechanism for OpenID > Author(s) : Eliot Lear > Hannes Tschofenig > Henry Mauldin > Simon Josefsson > Filename : draft-ietf-kitten-sasl-openid-04.txt > Pages : 26 > Date : 2011-07-11 > > OpenID has found its usage on the Internet for Web Single Sign-On. > Simple Authentication and Security Layer (SASL) and the Generic > Security Service Application Program Interface (GSS-API) are > application frameworks to generalize authentication. This memo > specifies a SASL and GSS-API mechanism for OpenID that allows the > integration of existing OpenID Identity Providers with applications > using SASL and GSS-API. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-04.txt > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From internet-drafts@ietf.org Mon Jul 11 06:17:37 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4B621F8B67; Mon, 11 Jul 2011 06:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MVLiSpetSIB; Mon, 11 Jul 2011 06:17:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA121F8B3D; Mon, 11 Jul 2011 06:17:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711131735.32404.17509.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 06:17:35 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:17:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL and GSS-API Mechanism for SAML Author(s) : Klaas Wierenga Eliot Lear Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-04.txt Pages : 25 Date : 2011-07-11 Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-04.txt From klaas@cisco.com Mon Jul 11 06:23:16 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D15C21F8B02 for ; Mon, 11 Jul 2011 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0UeOrS+go27 for ; Mon, 11 Jul 2011 06:23:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A865F21F8B01 for ; Mon, 11 Jul 2011 06:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1577; q=dns/txt; s=iport; t=1310390593; x=1311600193; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Yto98offQGYN9dGqkMttgx31CzWKv7BZwBFbiQbLQNU=; b=bZHI57hwZLQpAKs05qH1fzWJc63nnZSFaNM/TBxyhYtgraJ1XW1AbY9q CGELCM9JAr0brWXM2Y7bLjFuvCaM+9eVILI6KnMLEDtvUz77UV2i/zP8Z 708xprZe6UM3h8JgVznOG0iTVjcc2SL4yrmXAC1shnSzQKMBpzqj/kyQ6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggHAAr5Gk6Q/khR/2dsb2JhbABGDYREonVwB6pTjR2QRoErgXiCCIEPBJJUkEk X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="100717361" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 11 Jul 2011 13:23:10 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6BDN9W9012821 for ; Mon, 11 Jul 2011 13:23:10 GMT Message-ID: <4E1AF93D.20708@cisco.com> Date: Mon, 11 Jul 2011 15:23:09 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20110711131737.32404.49454.idtracker@ietfa.amsl.com> In-Reply-To: <20110711131737.32404.49454.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 X-Forwarded-Message-Id: <20110711131737.32404.49454.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:23:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, New version contains a request for an IANA OID assignment. No substantial changes compared to the previous version. Klaas - -------- Original Message -------- Subject: New Version Notification for draft-ietf-kitten-sasl-saml-04.txt Date: Mon, 11 Jul 2011 06:17:37 -0700 From: internet-drafts@ietf.org To: klaas@cisco.com CC: simon@josefsson.org, klaas@cisco.com, lear@cisco.com A new version of I-D, draft-ietf-kitten-sasl-saml-04.txt has been successfully submitted by Klaas Wierenga and posted to the IETF repository. Filename: draft-ietf-kitten-sasl-saml Revision: 04 Title: A SASL and GSS-API Mechanism for SAML Creation date: 2011-07-11 WG ID: kitten Number of pages: 25 Abstract: Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. The IETF Secretariat -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4a+TwACgkQH2Wy/p4XeFJwDwCfc651F2kQBJaba/yvNIxPzyos GNMAn04UdyP48QkX75/DG2cpv/Jdvbry =Zf1e -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Jul 11 13:18:31 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AC21F85B5 for ; Mon, 11 Jul 2011 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3B7KacFRWy0 for ; Mon, 11 Jul 2011 13:18:30 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0D021F8B93 for ; Mon, 11 Jul 2011 13:18:27 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 1F20642807C for ; Mon, 11 Jul 2011 13:18:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=PmmrArLK0ZZF2WiixINX8lkVhO05vWxRmMCeG7h8dxSt 4Oyby6/RuYSV8gPadWNY4TyTV9GSsO5Z6Yn9yEv7kCQOqSstP95QRncmHwHMjdIK 6WEFdI+sDNzOsz++pYwPDbJ4pgnu8MRnYPHSOMJi4pvMdbNraDe0O7qvMPlKLHs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=c4JyvC6sGQNh9M05EAoQAas4oRI=; b=n82xlpFPPVQ q3IGK1COBjsO3YPGvOSGOB/LlStJ0IoeaHXyT4bHTB0BoacBYH4bh/YwqCFfdml6 Vzg3wA5Lf6NWxUVqSFfzpqOO+siRlVDm8wb/TwWGYUvnpJrRz6In2Q90uQD6cz30 oTBBNacf9b7QsrfBqdQNAJLV3jaVy5QQ= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id BF34442807A for ; Mon, 11 Jul 2011 13:18:26 -0700 (PDT) Received: by pvh18 with SMTP id 18so4433167pvh.31 for ; Mon, 11 Jul 2011 13:18:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.66.130 with SMTP id f2mr5953781pbt.521.1310415506460; Mon, 11 Jul 2011 13:18:26 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Mon, 11 Jul 2011 13:18:26 -0700 (PDT) In-Reply-To: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> References: <1310064776.32123.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Mon, 11 Jul 2011 15:18:26 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:18:31 -0000 On Thu, Jul 7, 2011 at 1:52 PM, William J. Mills wro= te: > I've posted a new draft.=C2=A0 I believe there is one open issue, and tha= t is whether we're going to include text defining how Tunneled HTTP authent= ication (started as OAuth) works with GSS-API. I am coming more and more to= the opinion that the GSS-API definition is going to be very auth mechanism= specific.=C2=A0 This draft only defines what SASL needs currently, which i= s user auth.=C2=A0 GSS-API has message integrity as well, and possibly othe= r things that can be mapped into HTTP auth schemes, and I think it's going = to be=C2=A0 required that the auth schemes define their capabilities and GS= S_API mappings. Per-message tokens in the GSS-API are optional. Not having them makes a mechanism very uninteresting for GSS applications. If your mechanism does have a way to exchange session keys between the initiator and acceptor then you can copy the text from RFC5802 to make your mechanism a GSS mechanism (basically you get to say that the per-message tokens and the PRF are the same as for the Kerberos V5 mechanisms, and you then specify how to get the base protocol key needed to key those things). Any mechanism that can exchange session keys should. I completely agree with you regarding this and the desirability of key exchange. You mention mapping GSS mechanisms onto HTTP authentication. See: a) HTTP/Negotiate (RFC4559) (and what Windows calls Integrated Windows Authentication with Extended Protection), and b) http://tools.ietf.org/html/draft-williams-rest-gss-00 . Nico -- From shawn.emery@oracle.com Tue Jul 12 15:36:28 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B181A1F0C46 for ; Tue, 12 Jul 2011 15:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WunUWxq4kBxQ for ; Tue, 12 Jul 2011 15:36:28 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 146011F0C3F for ; Tue, 12 Jul 2011 15:36:26 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6CMaNGs023670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Jul 2011 22:36:25 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6CMaMVl003337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jul 2011 22:36:23 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6CMaHWV030077 for ; Tue, 12 Jul 2011 17:36:17 -0500 Received: from [10.159.208.12] (/10.159.208.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Jul 2011 15:36:17 -0700 Message-ID: <4E1CCC4E.5000905@oracle.com> Date: Tue, 12 Jul 2011 16:35:58 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110618 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------020709020009040104010404" X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E1CCC69.00AB:SCFSTAT5015188, ss=1, re=-4.000, fgs=0 Subject: [kitten] IETF 81: kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:36:28 -0000 This is a multi-part message in MIME format. --------------020709020009040104010404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The draft agenda can be found here: http://www.ietf.org/proceedings/81/agenda/kitten.txt Please let us know if we need to add anything to the session. As you can see we are light on presenters and there are some unresolved issues with some of the work items. Some new items to the charter should also be covered separately. Shawn, kitten co-chair -- --------------020709020009040104010404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The draft agenda can be found here:

http://www.ietf.org/proceedings/81/agenda/kitten.txt

Please let us know if we need to add anything to the session.  As you can see we are light on presenters and there are some unresolved issues with some of the work items.  Some new items to the charter should also be covered separately.

Shawn,
kitten co-chair
--
 --------------020709020009040104010404-- From stpeter@stpeter.im Tue Jul 19 11:52:42 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE611E8088; Tue, 19 Jul 2011 11:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGyLcrZxoSYz; Tue, 19 Jul 2011 11:52:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29211E807A; Tue, 19 Jul 2011 11:52:20 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0146A4005A; Tue, 19 Jul 2011 12:52:59 -0600 (MDT) Message-ID: <4E25D262.3060401@stpeter.im> Date: Tue, 19 Jul 2011 12:52:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" , IETF Security Area Advisory Group Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: [apps-discuss] i18n intro, Sunday 14:00-16:00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:52:42 -0000 This might be of interest given the use of stringprep in SASL... -------- Original Message -------- Subject: [apps-discuss] i18n intro, Sunday 14:00-16:00 Date: Tue, 19 Jul 2011 12:48:39 -0600 From: Peter Saint-Andre To: apps-discuss@ietf.org You might have noticed a curious item on the agenda at 14:00 on Sunday: "Apps Area Preparatory Meeting for Internationalization Working Groups". At that time, I will present an introduction to internationalization, assisted by Pete Resnick (who will correct me where I go wrong). The intent of this session is to help apps-area folks learn more about internationalization, especially in preparation for the PRECIS WG meeting on Thursday. The room we've been assigned (2103) holds up to 60 people so we should have plenty of space, and there is no need to sign up if you want to attend. If this session goes well, Pete and I might offer a more general tutorial at a future IETF meeting. Consider Sunday's session a dry run. See you in Quebec City! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From stephen.farrell@cs.tcd.ie Wed Jul 20 08:27:37 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E63021F8610 for ; Wed, 20 Jul 2011 08:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUdb2BQfLsst for ; Wed, 20 Jul 2011 08:27:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0206F21F899F for ; Wed, 20 Jul 2011 08:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 73D02171C61 for ; Wed, 20 Jul 2011 16:27:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1311175629; bh=nx7vvyQUAh3HWO223n7/+ybO auWEp5QUOw45lFB/kd8=; b=qTIvxL7VBdjwEx9uwzgyykwK9gjZl9PBoosUisZE 4mDi7r+1HfVkc0uH7nVgvjEI4oNlGWu8TJOgqHBi9niCTMnGgNI1iXySVdZ8DQ1u oYSbbKkw2y2NWn8wFfvvra56JOSSSnJS+UG0Em/eT91mzLKggXHvZUbL82eyQ9A0 plGAhFqsDt3V2DTvrHYHv2nEQtY78iu5PDjvfbW9Ux2v+kI6ZCqP1DU8/WzTbfeq mFr+RGF64PlvrfBYwMyv/8E5ST8vQodmuEv33o/dg/Fw54fvOiVYjOawjkJgOO6K cs3EthSZ8E1aHu71iOUJRs+JM8vayQ4FkFfbUuW064kU+A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8XNKBXDx0dp7 for ; Wed, 20 Jul 2011 16:27:09 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 52D54171BFA for ; Wed, 20 Jul 2011 16:27:05 +0100 (IST) Message-ID: <4E26F3C8.1080009@cs.tcd.ie> Date: Wed, 20 Jul 2011 16:27:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] AD review of draft-ietf-kitten-sasl-openid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:27:37 -0000 Hi all, I've had a read of this and reckon its nearly ok. While I've a bunch of comments, I would expect they can be handled fairly easily. S. Not-quite-major-but-close: 1) The use of TLS needs to be clarified throughout. - 5th para of intro says "It is anticipated that existing security layers, such as Transport Layer Security (TLS) [RFC5246], will continued to be used." - Figure 1 should I think show which channels MUST/SHOULD/MAY use TLS - 1.2 is ambiguous as to which channels MUST use TLS - bullet 9 on p7 says "over HTTP" - not clear if TLS needed here - Unnumbered figure before 2.1 says "- - - = HTTP or HTTPS" are both ok? - 5th para of section 4 says "applications MUST match the TLS server identity..." - the example in section 5 uses mixed http: and https: URIs - 6.2 RECOMMENDs that only "http or https" schemas (sic?) be accepted Not all of those things need to change, but some may and it needs to be crystal clear when TLS is a MUST|SHOULD|MAY to implement and to use and when its ok to not implement or use TLS when its a SHOULD if there are any of those. I think you probably only need to say once that server-auth is a MUST when TLS is used, but you need to say that that covers all uses of TLS, if that is in fact the case. 2) The fact that the GSS-API part is OPTIONAL needs to be more clearly stated. The intro does that right I think but not in 2119 langauge (which is only introduced in 1.1 anyway). Section 4 says "INFORMATIVE" and "NORMATIVE" but those are not 2119 terms. 3) section 2, bullet 3 in 1st list, do clients here have to support DH with the OP or not? Even if OpenID punts on this (I'm not sure) I think you need to say here. (Text currently says "optionally.") Same point for bullet 3 in 2nd list in section 2. 4) section 2, bullet 8 in 2nd list - as per (3) saying "optionally" isn't clear enough. This entire list ought to be using 2119 terms wherever possible I think. (Now, its a mixture.) 5) section 2, bullet 11, in 2nd list - this is the first time SREG is mentioned, some description and a reference would be good even if this is just an openid concept. Is SREG support really a MUST though? 6) section 2.1 is vague - saying "it may be necessary" doesn't make it clear to me what the RP has to implement or use. How are they supposed to know? 7) Last para of 2.2, are implementers supposed to add a transaction id to a return_to URL or not? Who needs to decide/know/check? I think this needs another sentence or two. 8) Do you really need both URI and XRI here? (3.1) If its not needed in reality, why not just allow URIs? If it is needed, is it really clear how to implement that? (I don't know, so I'm asking:-) 9) 3.2 says the SASL server MUST add a transaction id. That seemed to be optional earlier - which is it? When is it ok for that to be guessable or not resistant to attack? (I'd prefer a MUST there if that was ok, hard to code up a SHOULD properly I'd have thought.) 10) 2nd last para of 3.2 - who's doing the rejection that the client MUST handle here? (The OP I assume, but its not quite clear.) 11) 2nd last para of section 4 - I just don't get the mapping from the openid to the GSS-API name. Maybe just adding examples would clarify this enough. 12) Section 6, 1st para - "other literature" is too vague. Please add informative references. (Nice-to-have: repeat the references to SASL and GSS-API in this para too.) 13) In 6.3 would a reference to CORS help against CSRF? In any case, I think some references are needed to help the programmer. 14) Is OpenID directed identity support a MUST or what? (6.5) If so, what'd have to change in the client or RP? I think you need to say if you're mentioning this as a mitigation for colluding RPs. 15) Please give URLs for the references that are not RFCs, mainly OpenID, SREG1.0 and (if it stays) XRI2.0. (I apologise in advance if the RFC editor makes you take 'em out again, but I think they should be stable enough to include and are very useful.) Places where I went "huh?" H1) Intro: "This specification is appropriate for use when a browser is available." Browsers have been continually available since ~1995, so I think you need to state what you mean more clearly. H2) 2nd last para of 2.2 - I don't get what kind of "alternative" you mean - was this something considered but dropped during design or does it need an if-statement in someone's code? (I can guess, but I don't think I should have to guess.) H3) All of 3.4;-) Why is something 4422 "explicitly prohibits" done here? What does "lock step" mean? When does the client send a second "=" message? (If that's what it says.) What is an "application level outcome"? H4) 5th para of section 4. I think you need to clarify who's playing which TLS roles here, but I'm not quite sure that's all. H5) Is the mitigation in 6.1 clear enough? What code wouuld I write here? Maybe you mean that the mitigation depends on the OP implementation but that'd not be ideal really. H6) Last sentence of 6.3 needs something. (Maybe a re-write:-) H7) All of section 7. I just don't get that, but is it worth including in any case? Nits: N1) section 2, bullet 2 in 1st list, what is the "it" in "discovery on it" N2) section 2, 1st para after 1st list, suggest "must change their code" to "have to change their code" to avoid 2119 confusion. Good to do that throughout if you can and generally avoid "must," "should" and "may" except for when you mean the 2119 terms. N3) section 2, 2nd list intro - the steps are not "shown from" they are listed. N4) last para of section 2 (after the unnumbered figure) what is the "it" in "Specifially, it processes..." N5) s/insure/ensure/ N6) s/The astute/The astute [something]/ N7) s/shall/SHALL/ in 2nd para 3.3 N8) s/ambersand/ampersand/ N9) Add a reference for URL encoding in 3.3 N10) 4th para of section 4 is missing some MUSTs - "always have" is not 2119 language and s/alway /always / N11) section 5, p16, where's the Line break that was added in Eliot's email address for clarity? (I do see the full-stop that seems to have been added at the end of that for obscurity:-) N12) 6.2 s/should/SHOULD/ twice N13) s/schemas/schemes/ in 6.2? N14) 6.4 - s/will be track/will be able to track/ N15) 6.5 - 1st sentence - who is "you"? N16) 6.5 - 2nd sentence - s/possible/made easier/ N17) id-nits doesn't like "http://openid.example" (I think) and mentions an obsolete RFC being referenced, if you can check again that'd be good. (3920->6120 is probably right to change.) From cantor.2@osu.edu Thu Jul 28 12:50:37 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D11B21F86A5 for ; Thu, 28 Jul 2011 12:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYw4pXR0MIry for ; Thu, 28 Jul 2011 12:50:35 -0700 (PDT) Received: from defang14.it.ohio-state.edu (defang14.it.ohio-state.edu [128.146.216.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60321F8672 for ; Thu, 28 Jul 2011 12:50:33 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang14.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p6SJoWVn022041 for ; Thu, 28 Jul 2011 15:50:32 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%13]) with mapi; Thu, 28 Jul 2011 15:50:32 -0400 From: "Cantor, Scott E." To: "kitten@ietf.org" Thread-Topic: Status of SAML-EC draft Thread-Index: AQHMTV+chagGs8TXgUaagSIjrFnLUw== Date: Thu, 28 Jul 2011 19:50:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <40055b26-8dbb-4304-b2bd-802a11a3c2ab> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; 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.128 Subject: [kitten] Status of SAML-EC draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:50:37 -0000 I won't be able to remotely-attend the kitten session today, so since it's on the agenda, briefly, I haven't had the necessary time to complete the SAML-EC work and the related OASIS specs on channel binding and so forth since the last IETF meeting. I do intend to, hopefully in the near future. I will probably either do a WG draft with the channel binding material and leave out per-message tokens, or reach out to some experts to bounce some possibilities for that around. -- Scott From leifj@mnt.se Thu Jul 28 15:02:05 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BDB11E807E for ; Thu, 28 Jul 2011 15:02: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLuNqmxsSyZ3 for ; Thu, 28 Jul 2011 15:02:04 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 49E5C11E8182 for ; Thu, 28 Jul 2011 15:02:04 -0700 (PDT) Received: from [130.129.17.132] (dhcp-1184.meeting.ietf.org [130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p6SM1vCt026035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jul 2011 00:02:02 +0200 (CEST) Message-ID: <4E31DC54.8060208@mnt.se> Date: Fri, 29 Jul 2011 00:01:56 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: kitten@ietf.org References: <4DDDF593.5080100@oracle.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:02:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK lets see if I can summarize the proposals that have been floating around in this thread: 1 change the signature for set_attribute 2 add a new method set_attribute_critical 3 clarify the semantics of set_attribute to always require that the attribute be "known" My personal preference is 3,2,1 in that order. My gut feeling is that an implementation should not allow setting of attributes it doesn't have some "knowledge of" but maybe I just haven't thought about the ramifications enough. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4x3FEACgkQ8Jx8FtbMZneDxgCfQUCw29HMhlWx/BkxcrNJq1q3 VkYAnR/6TZTpKEx0DYZHfvgGIBP18d08 =pitX -----END PGP SIGNATURE-----