From shawn.emery@oracle.com Fri Aug 6 22:56:44 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2687F3A69C0; Fri, 6 Aug 2010 22:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lqYlwpI0L44A; Fri, 6 Aug 2010 22:56:42 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E767A3A69F4; Fri, 6 Aug 2010 22:53:13 -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 o775rWfQ017596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Aug 2010 05:53:33 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 o773X4iT006800; Sat, 7 Aug 2010 05:53:32 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 493594131281160321; Fri, 06 Aug 2010 22:52:01 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Aug 2010 22:52:01 -0700 Message-ID: <4C5CF47F.5040102@oracle.com> Date: Fri, 06 Aug 2010 23:51:59 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100610 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: "kitten@ietf.org" , sasl@ietf.org Content-Type: multipart/alternative; boundary="------------060008070807000208090700" Subject: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 05:56:44 -0000 This is a multi-part message in MIME format. --------------060008070807000208090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We are looking for consensus on whether the Kitten WG should adopt the following drafts as work items: draft-cantor-ietf-sasl-saml-ec draft-mills-kitten-sasl-oauth You can respond to lists (kitten or SASL), but please indicate your decision regardless if you are for or against the proposal. If we do decide to shepherd these drafts then we will recharter again to include the following patch: @@ -50,10 +50,14 @@ * A SASL Mechanism for OpenID draft-lear-ietf-sasl-openid-00 * A SASL Mechanism for SAML draft-wierenga-ietf-sasl-saml-00 +* A SASL Mechanism for SAML Enhanced Client + draft-cantor-ietf-sasl-saml-ec +* A SASL Mechanism for OAuth + draft-mills-kitten-sasl-oauth The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). Shawn. -- --------------060008070807000208090700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We are looking for consensus on whether the Kitten WG should adopt the following drafts as work items:

    draft-cantor-ietf-sasl-saml-ec
    draft-mills-kitten-sasl-oauth

You can respond to lists (kitten or SASL), but please indicate your decision regardless if you are for or against the proposal.

If we do decide to shepherd these drafts then we will recharter again to include the following patch:

@@ -50,10 +50,14 @@
 
 * A SASL Mechanism for OpenID
     draft-lear-ietf-sasl-openid-00
 * A SASL Mechanism for SAML
     draft-wierenga-ietf-sasl-saml-00
+* A SASL Mechanism for SAML Enhanced Client
+    draft-cantor-ietf-sasl-saml-ec
+* A SASL Mechanism for OAuth
+    draft-mills-kitten-sasl-oauth
 
 The transition from SASL to GSS-API mechanisms will allow a greater set of
 applications to utilize said mechanisms with SASL implementations that support
 the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).

Shawn.
--
 --------------060008070807000208090700-- From shawn.emery@oracle.com Fri Aug 6 23:32:04 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0603A6937; Fri, 6 Aug 2010 23:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 Xky-TtPdNULJ; Fri, 6 Aug 2010 23:32:02 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C0EDD3A684D; Fri, 6 Aug 2010 23:32:02 -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 o776WWo9008700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Aug 2010 06:32:34 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 o772Vtef020608; Sat, 7 Aug 2010 06:32:32 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 493658761281162679; Fri, 06 Aug 2010 23:31:19 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Aug 2010 23:31:18 -0700 Message-ID: <4C5CFDB5.5010307@oracle.com> Date: Sat, 07 Aug 2010 00:31:17 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100610 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: "kitten@ietf.org" , sasl@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sasl] WGLC on draft-ietf-kitten-digest-to-historic-00 X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 06:32:04 -0000 This message officially starts the Kitten Working Group Last Call for the following document: Moving DIGEST-MD5 to Historic http://tools.ietf.org/html/draft-ietf-kitten-digest-to-historic-00 The Working Group Last Call for this document starts today on Saturday, August 7th and will end on Saturday, August 21st. Please send any comments to the Kitten or SASL mailing list or directly to the chairs. Reviews that found no issues are also welcome, so if you review the document and find it acceptable, please let the mailing list or chairs know as well. Thank you, Tom Yu and Shawn Emery, Kitten WG chairs -- From klaas@cisco.com Sat Aug 7 00:22:04 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C1B3A6819; Sat, 7 Aug 2010 00:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=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 tFcCr8P8fMyh; Sat, 7 Aug 2010 00:22:03 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 0A60F3A686D; Sat, 7 Aug 2010 00:22:03 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=[10.55.220.245]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OhdjN-000AQx-7q; Sat, 07 Aug 2010 09:22:09 +0200 References: <4C5CF47F.5040102@oracle.com> Message-Id: <56C516BE-37B4-4E34-B66F-EB92C7CB3FE2@cisco.com> From: Klaas Wierenga To: Shawn Emery In-Reply-To: <4C5CF47F.5040102@oracle.com> Content-Type: multipart/alternative; boundary=Apple-Mail-5-63394487 Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Sat, 7 Aug 2010 09:23:08 +0200 X-Antivirus: no malware found Cc: "kitten@ietf.org" , "sasl@ietf.org" Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 07:22:04 -0000 --Apple-Mail-5-63394487 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I support adopting both drafts. Klaas Sent from my iPad On Aug 7, 2010, at 7:57 AM, "Shawn Emery" = wrote: >=20 > We are looking for consensus on whether the Kitten WG should adopt the = following drafts as work items: >=20 > draft-cantor-ietf-sasl-saml-ec > draft-mills-kitten-sasl-oauth >=20 > You can respond to lists (kitten or SASL), but please indicate your = decision regardless if you are for or against the proposal. >=20 > If we do decide to shepherd these drafts then we will recharter again = to include the following patch: >=20 > @@ -50,10 +50,14 @@ > =20 > * A SASL Mechanism for OpenID > draft-lear-ietf-sasl-openid-00 > * A SASL Mechanism for SAML > draft-wierenga-ietf-sasl-saml-00 > +* A SASL Mechanism for SAML Enhanced Client > + draft-cantor-ietf-sasl-saml-ec > +* A SASL Mechanism for OAuth > + draft-mills-kitten-sasl-oauth > =20 > The transition from SASL to GSS-API mechanisms will allow a greater = set of > applications to utilize said mechanisms with SASL implementations = that support > the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). >=20 > Shawn. > -- > _______________________________________________ > sasl mailing list > sasl@ietf.org > https://www.ietf.org/mailman/listinfo/sasl --Apple-Mail-5-63394487 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I support adopting both drafts.

Klaas

Sent from my iPad

On Aug 7, 2010, at 7:57 AM, "Shawn Emery" <shawn.emery@oracle.com> wrote:


We are looking for consensus on whether the Kitten WG should adopt the following drafts as work items:

    draft-cantor-ietf-sasl-saml-ec
    draft-mills-kitten-sasl-oauth

You can respond to lists (kitten or SASL), but please indicate your decision regardless if you are for or against the proposal.

If we do decide to shepherd these drafts then we will recharter again to include the following patch:

@@ -50,10 +50,14 @@
 
 * A SASL Mechanism for OpenID
     draft-lear-ietf-sasl-openid-00
 * A SASL Mechanism for SAML
     draft-wierenga-ietf-sasl-saml-00
+* A SASL Mechanism for SAML Enhanced Client
+    draft-cantor-ietf-sasl-saml-ec
+* A SASL Mechanism for OAuth
+    draft-mills-kitten-sasl-oauth
 
 The transition from SASL to GSS-API mechanisms will allow a greater set of
 applications to utilize said mechanisms with SASL implementations that support
 the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).

Shawn.
--
_______________________________________________
sasl mailing list
sasl@ietf.org
https://www.ietf.org/mailman/listinfo/sasl
--Apple-Mail-5-63394487-- From simon@josefsson.org Sat Aug 7 04:30:34 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A4D3A68B1; Sat, 7 Aug 2010 04:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAE0W79Dv1zO; Sat, 7 Aug 2010 04:30:33 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id B0E313A6846; Sat, 7 Aug 2010 04:30:32 -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 o77BUqOR016996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 Aug 2010 13:30:55 +0200 From: Simon Josefsson To: Shawn Emery References: <4C5CFDB5.5010307@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100807:sasl@ietf.org::Z0GNzBP1wLrOd2Mf:qIV X-Hashcash: 1:22:100807:shawn.emery@oracle.com::Drad3FWVjr9JfpZv:2QMQ X-Hashcash: 1:22:100807:kitten@ietf.org::JetaYbKEARqODLdn:TFsL Date: Sat, 07 Aug 2010 13:30:48 +0200 In-Reply-To: <4C5CFDB5.5010307@oracle.com> (Shawn Emery's message of "Sat, 07 Aug 2010 00:31:17 -0600") Message-ID: <877hk2pslz.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (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: "kitten@ietf.org" , sasl@ietf.org Subject: Re: [sasl] WGLC on draft-ietf-kitten-digest-to-historic-00 X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 11:30:35 -0000 I have re-read the document and this version looks good to me. Two comments below. 1) I believe the document should contain a pointer to SCRAM, RFC 5802. Then readers will understand that they are supposed to be implementing SCRAM instead of DIGEST-MD5. I suggest adding at the end of section 1: The SCRAM mechanism [RFC 5802] has been developed to provide similar features as DIGEST-MD5 but with a better design. 2) In section 1, I would add the following bullet under 8: C. The DES cipher for the security layer is considered insecure due to its small key space. /Simon From shawn.emery@oracle.com Sat Aug 7 20:49:02 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4387928C132; Sat, 7 Aug 2010 20:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 v2JIbwHgZ0iW; Sat, 7 Aug 2010 20:49:01 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1D7DB28C12F; Sat, 7 Aug 2010 20:49:01 -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 o783nWNr003212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Aug 2010 03:49:33 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 o782cFEl026326; Sun, 8 Aug 2010 03:49:32 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 476269961281239306; Sat, 07 Aug 2010 20:48:26 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Aug 2010 20:48:26 -0700 Message-ID: <4C5E2908.10507@oracle.com> Date: Sat, 07 Aug 2010 21:48:24 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100610 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: "kitten@ietf.org" , sasl@ietf.org Content-Type: multipart/alternative; boundary="------------010706060103010601000605" Subject: [sasl] IETF 78 - Kitten Minutes X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 03:49:02 -0000 This is a multi-part message in MIME format. --------------010706060103010601000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've uploaded the session minutes for Kitten: http://www.ietf.org/proceedings/78/minutes/kitten.txt Please let us know if you have any updates/corrections. Shawn. -- --------------010706060103010601000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I've uploaded the session minutes for Kitten:

http://www.ietf.org/proceedings/78/minutes/kitten.txt

Please let us know if you have any updates/corrections.

Shawn.
--
 --------------010706060103010601000605-- From alexey.melnikov@isode.com Mon Aug 9 01:15:51 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B803A6891; Mon, 9 Aug 2010 01:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.53 X-Spam-Level: X-Spam-Status: No, score=-101.53 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_20=-0.74, 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 S4VoVTzHosyP; Mon, 9 Aug 2010 01:15:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 59BF13A685A; Mon, 9 Aug 2010 01:15:50 -0700 (PDT) Received: from [10.0.0.111] (204.80-202-212.nextgentel.com [80.202.212.204]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Aug 2010 09:16:23 +0100 Message-ID: <4C5FB94F.4080003@isode.com> Date: Mon, 09 Aug 2010 09:16:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <4C5CFDB5.5010307@oracle.com> <877hk2pslz.fsf@mocca.josefsson.org> In-Reply-To: <877hk2pslz.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , sasl@ietf.org Subject: Re: [sasl] WGLC on draft-ietf-kitten-digest-to-historic-00 X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:15:51 -0000 Simon Josefsson wrote: >I have re-read the document and this version looks good to me. Two >comments below. > >1) > >I believe the document should contain a pointer to SCRAM, RFC 5802. >Then readers will understand that they are supposed to be implementing >SCRAM instead of DIGEST-MD5. I suggest adding at the end of section 1: > > The SCRAM mechanism [RFC 5802] has been developed to provide similar > features as DIGEST-MD5 but with a better design. > >2) > >In section 1, I would add the following bullet under 8: > > C. The DES cipher for the security layer is considered insecure > due to its small key space. > I am happy to add these. Tim Polk also suggested 1) to me verbally. From alexey.melnikov@isode.com Mon Aug 9 01:35:40 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E633A6AA3; Mon, 9 Aug 2010 01:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 8A+mq9mjumND; Mon, 9 Aug 2010 01:35:39 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B51E83A6A99; Mon, 9 Aug 2010 01:35:39 -0700 (PDT) Received: from [10.0.0.111] (204.80-202-212.nextgentel.com [80.202.212.204]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Aug 2010 09:36:12 +0100 Message-ID: <4C5FBDF0.9010909@isode.com> Date: Mon, 09 Aug 2010 09:36:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shawn Emery References: <4C5CF47F.5040102@oracle.com> In-Reply-To: <4C5CF47F.5040102@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:35:40 -0000 Shawn Emery wrote: > We are looking for consensus on whether the Kitten WG should adopt the > following drafts as work items: > > draft-cantor-ietf-sasl-saml-ec > draft-mills-kitten-sasl-oauth > > You can respond to lists (kitten or SASL), but please indicate your > decision regardless if you are for or against the proposal. > > If we do decide to shepherd these drafts then we will recharter again > to include the following patch: > > @@ -50,10 +50,14 @@ > > * A SASL Mechanism for OpenID > draft-lear-ietf-sasl-openid-00 > * A SASL Mechanism for SAML > draft-wierenga-ietf-sasl-saml-00 > +* A SASL Mechanism for SAML Enhanced Client > + draft-cantor-ietf-sasl-saml-ec I think IESG might want to know why there are 2 separate SAML mechanisms. While I can be convinced that both of them might be needed, the WG should have some good arguments to defend this. I think both of the documents should be discussed in the WG. > +* A SASL Mechanism for OAuth > + draft-mills-kitten-sasl-oauth I am also happy to take this one as a WG item. > The transition from SASL to GSS-API mechanisms will allow a greater > set of > applications to utilize said mechanisms with SASL implementations > that support > the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). > > Shawn. From lear@cisco.com Mon Aug 9 02:12:17 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4305A3A6AB7; Mon, 9 Aug 2010 02:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.398 X-Spam-Level: X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dDpxojSNTvJk; Mon, 9 Aug 2010 02:12: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 849E63A68C3; Mon, 9 Aug 2010 02:12:15 -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: Av0EAD5jX0xAZnwN/2dsb2JhbACDFZ0vcac7iVKRD4RHcwSJOw X-IronPort-AV: E=Sophos;i="4.55,341,1278288000"; d="scan'208,217";a="145158696" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2010 09:12:49 +0000 Received: from dhcp-10-61-97-133.cisco.com (dhcp-10-61-97-133.cisco.com [10.61.97.133]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o799CmGa000905; Mon, 9 Aug 2010 09:12:48 GMT Message-ID: <4C5FC699.8060902@cisco.com> Date: Mon, 09 Aug 2010 11:12:57 +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: Shawn Emery References: <4C5CF47F.5040102@oracle.com> In-Reply-To: <4C5CF47F.5040102@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------070407040704040805060506" Cc: "kitten@ietf.org" , sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 09:12:17 -0000 This is a multi-part message in MIME format. --------------070407040704040805060506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > We are looking for consensus on whether the Kitten WG should adopt the > following drafts as work items: > > draft-cantor-ietf-sasl-saml-ec > draft-mills-kitten-sasl-oauth > > You can respond to lists (kitten or SASL), but please indicate your > decision regardless if you are for or against the proposal. I support the inclusion of both drafts in our milestones. To answer Alexey's reaonable question, draft-wierenga-ietf-sasl-saml attempts to rely on existing infrastructure as much as possible, both on the client and on the IdP, while requiring some substantial changes to the RP. draft-cantor-ietf-sasl-saml-ec requires more substantial changes to the client, but keeps SAML within the application protocol. The implication of the design choices relate more to how actual authentication gets performed between the SASL client and the IdP. Existing IdPs make use of HTTP/HTML and unstructured exchanges for that authentication. In Scott's draft, that occurs in step (4). This requires the client to have substantially more capabilities than it might have today with either a fully functional web browser either built into the application or tied to the application via some form of IPC with sufficient semantic abilities to discern when to move through step 4 to step 5, but at the same time, provides for an overall simpler protocol flow than the document that Klaas and I have put forth. Discovery is also handled in Scott's draft. That is something that we should consider incorporating into the other. Eliot --------------070407040704040805060506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

We are looking for consensus on whether the Kitten WG should adopt the following drafts as work items:

    draft-cantor-ietf-sasl-saml-ec
    draft-mills-kitten-sasl-oauth

You can respond to lists (kitten or SASL), but please indicate your decision regardless if you are for or against the proposal.

I support the inclusion of both drafts in our milestones.  To answer Alexey's reaonable question, draft-wierenga-ietf-sasl-saml attempts to rely on existing infrastructure as much as possible, both on the client and on the IdP, while requiring some substantial changes to the RP.   draft-cantor-ietf-sasl-saml-ec requires more substantial changes to the client, but keeps SAML within the application protocol.  The implication of the design choices relate more to how actual authentication gets performed between the SASL client and the IdP.  Existing IdPs make use of HTTP/HTML and unstructured exchanges for that authentication.

In Scott's draft, that occurs in step (4).  This requires the client to have substantially more capabilities than it might have today with either a fully functional web browser either built into the application or tied to the application via some form of IPC with sufficient semantic abilities to discern when to move through step 4 to step 5, but at the same time, provides for an overall simpler protocol flow than the document that Klaas and I have put forth.  

Discovery is also handled in Scott's draft.  That is something that we should consider incorporating into the other.

Eliot

--------------070407040704040805060506-- From alexey.melnikov@isode.com Mon Aug 9 05:58:37 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420363A6ACC; Mon, 9 Aug 2010 05:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.206 X-Spam-Level: X-Spam-Status: No, score=-102.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 hL1HzKTX8gVO; Mon, 9 Aug 2010 05:58:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D73F33A69B0; Mon, 9 Aug 2010 05:58:35 -0700 (PDT) Received: from [10.0.0.112] (204.80-202-212.nextgentel.com [80.202.212.204]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Aug 2010 13:59:08 +0100 Message-ID: <4C5FFB8F.6030406@isode.com> Date: Mon, 09 Aug 2010 14:58:55 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eliot Lear References: <4C5CF47F.5040102@oracle.com> <4C5FC699.8060902@cisco.com> In-Reply-To: <4C5FC699.8060902@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:58:37 -0000 Hi Eliot, Eliot Lear wrote: >> We are looking for consensus on whether the Kitten WG should adopt >> the following drafts as work items: >> >> draft-cantor-ietf-sasl-saml-ec >> draft-mills-kitten-sasl-oauth >> >> You can respond to lists (kitten or SASL), but please indicate your >> decision regardless if you are for or against the proposal. > > I support the inclusion of both drafts in our milestones. To answer > Alexey's reaonable question, draft-wierenga-ietf-sasl-saml attempts to > rely on existing infrastructure as much as possible, both on the > client and on the IdP, while requiring some substantial changes to the > RP. draft-cantor-ietf-sasl-saml-ec requires more substantial changes > to the client, but keeps SAML within the application protocol. The > implication of the design choices relate more to how actual > authentication gets performed between the SASL client and the IdP. > Existing IdPs make use of HTTP/HTML and unstructured exchanges for > that authentication. > > In Scott's draft, that occurs in step (4). This requires the client > to have substantially more capabilities than it might have today with > either a fully functional web browser either built into the > application or tied to the application via some form of IPC with > sufficient semantic abilities to discern when to move through step 4 > to step 5, but at the same time, provides for an overall simpler > protocol flow than the document that Klaas and I have put forth. Yes, I've seen this argument on the mailing list. Two documents suggest reasonable solutions for the assumption made. However I am not yet fully convinced that the assumption is something important enough to warrant having 2 documents. > Discovery is also handled in Scott's draft. That is something that we > should consider incorporating into the other. Right. From cantor.2@osu.edu Mon Aug 9 06:55:25 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE333A6AD6; Mon, 9 Aug 2010 06:55:25 -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 0as1Z3Yumxhr; Mon, 9 Aug 2010 06:55:24 -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 747D63A67FB; Mon, 9 Aug 2010 06:55:24 -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 o79DtuCT003344; Mon, 9 Aug 2010 09:55:56 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79Dtuu8008647; Mon, 9 Aug 2010 09:55:56 -0400 From: "Scott Cantor" To: "'Eliot Lear'" , "'Shawn Emery'" References: <4C5CF47F.5040102@oracle.com> <4C5FC699.8060902@cisco.com> In-Reply-To: <4C5FC699.8060902@cisco.com> Date: Mon, 9 Aug 2010 09:55:58 -0400 Organization: The Ohio State University Message-ID: <012a01cb37ca$984ce9d0$c8e6bd70$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJ85rZC8rLev/gGs0jS+zIiq+O3tALDC0ypkV+ugtA= Content-language: en-us 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: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:55:25 -0000 > In Scott's draft, that occurs in step (4). This requires the client = to have > substantially more capabilities than it might have today with either a = fully > functional web browser either built into the application or tied to = the > application via some form of IPC with sufficient semantic abilities to > discern when to move through step 4 to step 5, but at the same time, > provides for an overall simpler protocol flow than the document that = Klaas > and I have put forth. My proposal uses ECP, which means the exchange with the IdP is generally = (and can be required to be) SOAP over HTTP. There is generally no need = for a web browser in the client, or anything like that. That's the IPC = you're referring to. =20 > Discovery is also handled in Scott's draft. That is something that we > should consider incorporating into the other. I believe the latest draft of Klaas' proposal does this, though in a = different way from ECP of course. -- Scott From cantor.2@osu.edu Mon Aug 9 07:06:12 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249673A67FB; Mon, 9 Aug 2010 07:06:12 -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 jsgmEjJBQxMv; Mon, 9 Aug 2010 07:06:11 -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 2D3BB3A67AE; Mon, 9 Aug 2010 07:06:09 -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 o79E6ctx008112; Mon, 9 Aug 2010 10:06:38 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79E6bLV015560; Mon, 9 Aug 2010 10:06:37 -0400 From: "Scott Cantor" To: "'Eliot Lear'" , "'Shawn Emery'" References: <4C5CF47F.5040102@oracle.com> <4C5FC699.8060902@cisco.com> <012a01cb37ca$984ce9d0$c8e6bd70$@osu.edu> In-Reply-To: <012a01cb37ca$984ce9d0$c8e6bd70$@osu.edu> Date: Mon, 9 Aug 2010 10:06:40 -0400 Organization: The Ohio State University Message-ID: <012f01cb37cc$16954b10$43bfe130$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJ85rZC8rLev/gGs0jS+zIiq+O3tALDC0ypAgaOvy2RT31pEA== Content-language: en-us 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: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 14:06:12 -0000 > My proposal uses ECP, which means the exchange with the IdP is generally > (and can be required to be) SOAP over HTTP. There is generally no need for a > web browser in the client, or anything like that. That's the IPC you're > referring to. Actually rereading you meant IPC between the client and some local agent. What I'm trying to say is that the client/IdP exchange is structured (SOAP), not unstructured (HTML). The client requirements of my mechanism proposal are trivial (until/unless we add holder of key or other kinds of security options). -- Scott From hannes.tschofenig@gmx.net Mon Aug 9 06:37:18 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E8F3A695A for ; Mon, 9 Aug 2010 06:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 8UsmOVATGiTL for ; Mon, 9 Aug 2010 06:37:17 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 8AE553A6927 for ; Mon, 9 Aug 2010 06:37:16 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2010 13:37:49 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.5]) [88.115.222.204] by mail.gmx.net (mp070) with SMTP; 09 Aug 2010 15:37:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/PIsYRMILP8leNniaLeDmapGsKizjb+LguSx1xyV RleIVhiGeFgHoD Message-ID: <4C6004AC.2060806@gmx.net> Date: Mon, 09 Aug 2010 16:37:48 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Shawn Emery References: <4C5CF47F.5040102@oracle.com> In-Reply-To: <4C5CF47F.5040102@oracle.com> Content-Type: multipart/alternative; boundary="------------000505030901030302010702" X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Mon, 09 Aug 2010 07:26:22 -0700 Cc: "kitten@ietf.org" , sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:37:18 -0000 This is a multi-part message in MIME format. --------------000505030901030302010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hey Shawn, this makes sense to me (as discussed during the WG session at the recent IETF meeting). Ciao Hannes On 8/7/2010 8:51 AM, Shawn Emery wrote: > > We are looking for consensus on whether the Kitten WG should adopt the > following drafts as work items: > > draft-cantor-ietf-sasl-saml-ec > draft-mills-kitten-sasl-oauth > > You can respond to lists (kitten or SASL), but please indicate your > decision regardless if you are for or against the proposal. > > If we do decide to shepherd these drafts then we will recharter again > to include the following patch: > > @@ -50,10 +50,14 @@ > > * A SASL Mechanism for OpenID > draft-lear-ietf-sasl-openid-00 > * A SASL Mechanism for SAML > draft-wierenga-ietf-sasl-saml-00 > +* A SASL Mechanism for SAML Enhanced Client > + draft-cantor-ietf-sasl-saml-ec > +* A SASL Mechanism for OAuth > + draft-mills-kitten-sasl-oauth > > The transition from SASL to GSS-API mechanisms will allow a greater > set of > applications to utilize said mechanisms with SASL implementations > that support > the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). > > Shawn. > -- > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --------------000505030901030302010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey Shawn,

this makes sense to me (as discussed during the WG session at the recent IETF meeting).

Ciao
Hannes

On 8/7/2010 8:51 AM, Shawn Emery wrote:

We are looking for consensus on whether the Kitten WG should adopt the following drafts as work items:

    draft-cantor-ietf-sasl-saml-ec
    draft-mills-kitten-sasl-oauth

You can respond to lists (kitten or SASL), but please indicate your decision regardless if you are for or against the proposal.

If we do decide to shepherd these drafts then we will recharter again to include the following patch:

@@ -50,10 +50,14 @@
 
 * A SASL Mechanism for OpenID
     draft-lear-ietf-sasl-openid-00
 * A SASL Mechanism for SAML
     draft-wierenga-ietf-sasl-saml-00
+* A SASL Mechanism for SAML Enhanced Client
+    draft-cantor-ietf-sasl-saml-ec
+* A SASL Mechanism for OAuth
+    draft-mills-kitten-sasl-oauth
 
 The transition from SASL to GSS-API mechanisms will allow a greater set of
 applications to utilize said mechanisms with SASL implementations that support
 the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).

Shawn.
--
 

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

--------------000505030901030302010702-- From jhutz@cmu.edu Mon Aug 9 11:40:07 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B936E3A69D1; Mon, 9 Aug 2010 11:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 q7IUz1gCxJji; Mon, 9 Aug 2010 11:40:05 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 03E3B3A683C; Mon, 9 Aug 2010 11:40:04 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o79IeZkb024867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Aug 2010 14:40:36 -0400 (EDT) Date: Mon, 09 Aug 2010 14:40:35 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Eliot Lear Message-ID: <4C6210AE12B6E901D2025331@atlantis.pc.cs.cmu.edu> In-Reply-To: <17613_1281358755_o79CxEZL028303_4C5FFB8F.6030406@isode.com> References: <4C5CF47F.5040102@oracle.com> <4C5FC699.8060902@cisco.com> <17613_1281358755_o79CxEZL028303_4C5FFB8F.6030406@isode.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:40:07 -0000 --On Monday, August 09, 2010 02:58:55 PM +0200 Alexey Melnikov wrote: > Hi Eliot, > > Eliot Lear wrote: > >>> We are looking for consensus on whether the Kitten WG should adopt >>> the following drafts as work items: >>> >>> draft-cantor-ietf-sasl-saml-ec >>> draft-mills-kitten-sasl-oauth >>> >>> You can respond to lists (kitten or SASL), but please indicate your >>> decision regardless if you are for or against the proposal. >> >> I support the inclusion of both drafts in our milestones. To answer >> Alexey's reaonable question, draft-wierenga-ietf-sasl-saml attempts to >> rely on existing infrastructure as much as possible, both on the >> client and on the IdP, while requiring some substantial changes to the >> RP. draft-cantor-ietf-sasl-saml-ec requires more substantial changes >> to the client, but keeps SAML within the application protocol. The >> implication of the design choices relate more to how actual >> authentication gets performed between the SASL client and the IdP. >> Existing IdPs make use of HTTP/HTML and unstructured exchanges for >> that authentication. >> >> In Scott's draft, that occurs in step (4). This requires the client >> to have substantially more capabilities than it might have today with >> either a fully functional web browser either built into the >> application or tied to the application via some form of IPC with >> sufficient semantic abilities to discern when to move through step 4 >> to step 5, but at the same time, provides for an overall simpler >> protocol flow than the document that Klaas and I have put forth. > > Yes, I've seen this argument on the mailing list. Two documents suggest > reasonable solutions for the assumption made. However I am not yet fully > convinced that the assumption is something important enough to warrant > having 2 documents. The failure here is not in having two documents to discuss, but in insisting on having specific documents listed by name in the charter. A charter work item should be something like "produce a SAML-based GSS-API mechanism", which could be satisfied by either of these documents by the time we're done with them. Perhaps in the end we'll choose one or the other, or perhaps we'll decide that two mechanisms really are necessary, in which case we'll make the case to the IESG as to why both should by published. -- Jeff From alexey.melnikov@isode.com Mon Aug 9 11:42:13 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D671D3A6940; Mon, 9 Aug 2010 11:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs5vjN1uV6en; Mon, 9 Aug 2010 11:42:12 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 922D83A683C; Mon, 9 Aug 2010 11:42:12 -0700 (PDT) Received: from [172.16.2.104] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 9 Aug 2010 19:42:44 +0100 Message-ID: <4C604BEF.8050503@isode.com> Date: Mon, 09 Aug 2010 20:41:51 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Jeffrey Hutzelman References: <4C5CF47F.5040102@oracle.com> <4C5FC699.8060902@cisco.com> <17613_1281358755_o79CxEZL028303_4C5FFB8F.6030406@isode.com> <4C6210AE12B6E901D2025331@atlantis.pc.cs.cmu.edu> In-Reply-To: <4C6210AE12B6E901D2025331@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] New Work Items - Kitten Recharter X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:42:13 -0000 Jeffrey Hutzelman wrote: > --On Monday, August 09, 2010 02:58:55 PM +0200 Alexey Melnikov > wrote: > >> Hi Eliot, >> >> Eliot Lear wrote: >> >>>> We are looking for consensus on whether the Kitten WG should adopt >>>> the following drafts as work items: >>>> >>>> draft-cantor-ietf-sasl-saml-ec >>>> draft-mills-kitten-sasl-oauth >>>> >>>> You can respond to lists (kitten or SASL), but please indicate your >>>> decision regardless if you are for or against the proposal. >>> >>> >>> I support the inclusion of both drafts in our milestones. To answer >>> Alexey's reaonable question, draft-wierenga-ietf-sasl-saml attempts to >>> rely on existing infrastructure as much as possible, both on the >>> client and on the IdP, while requiring some substantial changes to the >>> RP. draft-cantor-ietf-sasl-saml-ec requires more substantial changes >>> to the client, but keeps SAML within the application protocol. The >>> implication of the design choices relate more to how actual >>> authentication gets performed between the SASL client and the IdP. >>> Existing IdPs make use of HTTP/HTML and unstructured exchanges for >>> that authentication. >>> >>> In Scott's draft, that occurs in step (4). This requires the client >>> to have substantially more capabilities than it might have today with >>> either a fully functional web browser either built into the >>> application or tied to the application via some form of IPC with >>> sufficient semantic abilities to discern when to move through step 4 >>> to step 5, but at the same time, provides for an overall simpler >>> protocol flow than the document that Klaas and I have put forth. >> >> Yes, I've seen this argument on the mailing list. Two documents suggest >> reasonable solutions for the assumption made. However I am not yet fully >> convinced that the assumption is something important enough to warrant >> having 2 documents. > > The failure here is not in having two documents to discuss, but in > insisting on having specific documents listed by name in the charter. > A charter work item should be something like "produce a SAML-based > GSS-API mechanism", which could be satisfied by either of these > documents by the time we're done with them. Perhaps in the end we'll > choose one or the other, or perhaps we'll decide that two mechanisms > really are necessary, in which case we'll make the case to the IESG as > to why both should by published. Yes, I was about to suggest the same. Not naming specific documents would be better in this case. From hannes.tschofenig@nsn.com Wed Aug 11 03:41:35 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911073A6A6B; Wed, 11 Aug 2010 03:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=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 gC1xDUiecgrI; Wed, 11 Aug 2010 03:41:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 26E0B3A6807; Wed, 11 Aug 2010 03:41:33 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg9m4012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 12:42:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg39Y025777; Wed, 11 Aug 2010 12:42:09 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:42:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3941.D619A9C7" Date: Wed, 11 Aug 2010 13:38:12 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E5D295@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback solicited for Privacy and Identity Management Terminology Thread-Index: Acs5PcCKKP+5/l6FR0Cr0uxjuLJ03Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , X-OriginalArrivalTime: 11 Aug 2010 10:42:05.0378 (UTC) FILETIME=[D70CAA20:01CB3941] Subject: [sasl] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:41:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3941.D619A9C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have just submitted a new version of the privacy and identity management terminology document: http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-01. txt =20 The full document titel is "Terminology for Talking about Privacy by Data Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management" and here is the abstract:=20 This document is an attempt to consolidate terminology in the field privacy by data minimization. It motivates and develops definitions for anonymity/identifiability, (un)linkability, (un)detectability, (un)observability, pseudonymity, identity, partial identity, digital identity and identity management. Starting the definitions from the anonymity and unlinkability perspective and not from a definition of identity (the latter is the obvious approach to some people) reveals some deeper structures in this field. =20 Please let us know whether the terminology is useful and complete. Your input is highly appreciated! Ciao Hannes ------_=_NextPart_001_01CB3941.D619A9C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Feedback solicited for Privacy and Identity Management = Terminology

Hi all,

we have just submitted a new = version of the privacy and identity management terminology = document:
http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology= -01.txt
 
The full document titel is = "Terminology for Talking about Privacy by Data Minimization: = Anonymity, Unlinkability, Undetectability, Unobservability, = Pseudonymity, and Identity Management" and here is the abstract: =

   This document is an = attempt to consolidate terminology in the field
   privacy by data = minimization.  It motivates and develops definitions
   for = anonymity/identifiability, (un)linkability, (un)detectability,
   (un)observability, = pseudonymity, identity, partial identity, digital
   identity and = identity management.  Starting the definitions from the
   anonymity and = unlinkability perspective and not from a definition of
   identity (the = latter is the obvious approach to some people) reveals
   some deeper = structures in this field.
  
Please let us know whether the = terminology is useful and complete. Your input is highly = appreciated!

Ciao
Hannes


------_=_NextPart_001_01CB3941.D619A9C7-- From william.polk@nist.gov Mon Aug 23 10:08:33 2010 Return-Path: X-Original-To: sasl@core3.amsl.com Delivered-To: sasl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427E23A687E for ; Mon, 23 Aug 2010 10:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JOxrTZYH88YH for ; Mon, 23 Aug 2010 10:08:29 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 7EE703A6829 for ; Mon, 23 Aug 2010 10:08:29 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o7NH8q6e030248 for ; Mon, 23 Aug 2010 13:08:52 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 23 Aug 2010 13:08:35 -0400 From: "Polk, William T." To: "sasl@ietf.org" Date: Mon, 23 Aug 2010 13:08:49 -0400 Thread-Topic: Closing WG, redirecting list traffic Thread-Index: ActC5dpxGbNkdOVNQECig0vZlriLNA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C89823611AE42wpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [sasl] Closing WG, redirecting list traffic X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:08:33 -0000 --_000_C89823611AE42wpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I just wanted to give you all a "heads up". I will be sending the secretar= iat a request to close the sasl wg and redirect email sent to this list to = the kitten wg list. I will also be asking the secretariat to add current s= asl subscribers with their current preferences (e.g., digest, etc...) to th= e kitten list if they are not currently subscribed. Those of you that are not interested in joining kitten will need to unsubsc= ribe - my apologies, but that seemed the best way forward for the majority = of the sasl participants. If you are currently subscribed to both lists un= der different aliases, you will also need to unsubscribe one or the other. = Again, my apologies for the inconvenience! Thanks, Tim Polk --_000_C89823611AE42wpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Closing WG, redirecting list traffic Folks,

I just wanted to give you all a “heads up”.  I will be sen= ding the secretariat a request to close the sasl wg and redirect email sent= to this list to the kitten wg list.  I will also be asking the secret= ariat to add current sasl subscribers with their current preferences (e.g.,= digest, etc...) to the kitten list if they are not currently subscribed. &= nbsp;

Those of you that are not interested in joining kitten will need to unsubsc= ribe – my apologies, but that seemed the best way forward for the maj= ority of the sasl participants.  If you are currently subscribed to bo= th lists under different aliases, you will also need to unsubscribe one or = the other.  Again, my apologies for the inconvenience!

Thanks,

Tim Polk
 --_000_C89823611AE42wpolknistgov_-- From wwwrun@core3.amsl.com Mon Aug 23 13:24:41 2010 Return-Path: X-Original-To: sasl@ietf.org Delivered-To: sasl@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 86EAD3A6AF6; Mon, 23 Aug 2010 13:24:41 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100823202441.86EAD3A6AF6@core3.amsl.com> Date: Mon, 23 Aug 2010 13:24:41 -0700 (PDT) Cc: sasl@ietf.org, kurt.zeilenga@isode.com Subject: [sasl] WG Action: Conclusion of Simple Authentication and Security Layer (sasl) X-BeenThere: sasl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SASL Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:24:42 -0000 The Simple Authentication and Security Layer (sasl) working group in the Security Area has concluded. The IESG contact persons are Tim Polk and Sean Turner. The sasl working group has completed its initial charter items, and is merging with the kitten working group. As future sasl work items will be processed in kitten, the sasl working group is officially closing and future discussions will occur on the kitten mailing list. The sasl working group was primarily focused on revising the Simple Authentication and Security Layer (SASL), as defined in RFC 2222, and key SASL mechanisms for publication as a standards track RFCs. The working group published seven RFCs, including the revised SASL specification as RFC 4422, GSSAPI (RFC 4752), GS2 (RFC 5801), and Salted Challenge Response Authentication Mechanism (SCRAM) (RFC 5802). Sean and I thank all of the IETF participants who have contributed to the various documents produced by the sasl working group and to the successful completion of these important deliverables. We especially thank Kurt Zeilenga and Tom Yu who have chaired the working group since its formation. Tom will be continuing as kitten co-chair, so there should be continuity! sasl mailing list traffic will be redirected to the kitten wg list, and current sasl mailing list members will be added to the kitten wg list. The list archive will be retained. - Tim Polk, Security AD