
From shawn.emery@oracle.com  Wed May  5 14:39:46 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAFC3A6D1A; Wed,  5 May 2010 14:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001,  BAYES_50=0.001, 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 D7bPyBHsbv7z; Wed,  5 May 2010 14:39:45 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AF70D3A6B0F; Wed,  5 May 2010 14:39:43 -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.1) with ESMTP id o45LdSrh025802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 May 2010 21:39:30 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 o45LdRLb012904; Wed, 5 May 2010 21:39:27 GMT
Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 240481351273095497; Wed, 05 May 2010 14:38:17 -0700
Received: from [129.150.48.45] (/129.150.48.45) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:38:17 -0700
Message-ID: <4BE1E547.5030103@oracle.com>
Date: Wed, 05 May 2010 15:38:15 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: kitten@ietf.org, sasl@ietf.org
Subject: SASL and KITTEN-WG Merger
Content-Type: multipart/alternative; boundary="------------020108090802020903040506"
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090207.4BE1E592.009F:SCFMA922111,ss=1,fgs=0
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2010 21:39:46 -0000

This is a multi-part message in MIME format.
--------------020108090802020903040506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Sorry for any cross-posting, but this is unavoidable given the subject line.

During IETF 77, the security ADs suggested that we merge the KITTEN and 
SASL WGs.  This has some potential benefits:

1. ensure efforts of any new work items/extensions
2. both WGs have expertise in security interface design
3. analyze proposed security mechanisms for both set of interfaces

Please respond to both lists if you have any objections to such a 
merger.  The time-out for objections is two weeks from this posting.

Thank you,

Shawn KITTEN co-chair
--

--------------020108090802020903040506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<font size="+1"><tt><br>
<br>
Sorry for any cross-posting, but this is unavoidable given the subject
line.<br>
<br>
During IETF 77, the security ADs suggested that we merge the KITTEN and
SASL WGs.&nbsp; This has some potential benefits:<br>
<br>
1. ensure efforts of any new work items/extensions<br>
2. both WGs have expertise in security interface design<br>
3. analyze proposed security mechanisms for both set of interfaces <br>
<br>
Please respond to both lists if you have any objections to such a
merger.&nbsp; The
time-out for objections is two weeks from this posting.<br>
<br>
Thank you,<br>
<br>
Shawn KITTEN co-chair<br>
--</tt></font><br>
</body>
</html>

--------------020108090802020903040506--

From alexey.melnikov@isode.com  Wed May  5 14:43:20 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388423A6B92; Wed,  5 May 2010 14:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=-0.741,  BAYES_50=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 KW+1fLV9Y1C2; Wed,  5 May 2010 14:43:19 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4F8813A6AD0; Wed,  5 May 2010 14:43:19 -0700 (PDT)
Received: from [92.40.16.136] (92.40.16.136.sub.mbb.three.co.uk [92.40.16.136])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S-HmZwBeGa7w@rufus.isode.com>; Wed, 5 May 2010 22:43:05 +0100
Message-ID: <4BE1E64F.8090101@isode.com>
Date: Wed, 05 May 2010 22:42:39 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <shawn.emery@oracle.com>
Subject: Re: SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com>
In-Reply-To: <4BE1E547.5030103@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
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2010 21:43:21 -0000

Shawn Emery wrote:

> Sorry for any cross-posting, but this is unavoidable given the subject 
> line.
>
> During IETF 77, the security ADs suggested that we merge the KITTEN 
> and SASL WGs.  This has some potential benefits:
>
> 1. ensure efforts of any new work items/extensions
> 2. both WGs have expertise in security interface design
> 3. analyze proposed security mechanisms for both set of interfaces
>
> Please respond to both lists if you have any objections to such a 
> merger.  The time-out for objections is two weeks from this posting.

(Speaking as an individual): I have No Objections.

I suggest the SASL WG should be closed and Kitten should rechater. The 
SASL WG mailing list should stay open though.

> Thank you,
>
> Shawn KITTEN co-chair



From Nicolas.Williams@oracle.com  Thu May  6 09:48:05 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B3E3A6917; Thu,  6 May 2010 09:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1qhuRxosFUl; Thu,  6 May 2010 09:48:04 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AF6223A6921; Thu,  6 May 2010 09:48:04 -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.1) with ESMTP id o46GlnrI010610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 May 2010 16:47:51 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465rq7P013811; Thu, 6 May 2010 16:47:47 GMT
Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 220127231273164393; Thu, 06 May 2010 09:46:33 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:46:33 -0700
Date: Thu, 6 May 2010 11:46:31 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Shawn Emery <shawn.emery@oracle.com>
Subject: Re: SASL and KITTEN-WG Merger
Message-ID: <20100506164630.GU9429@oracle.com>
References: <4BE1E547.5030103@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BE1E547.5030103@oracle.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090204.4BE2F2B7.0172:SCFMA922111,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2010 16:48:05 -0000

On Wed, May 05, 2010 at 03:38:15PM -0600, Shawn Emery wrote:
> Sorry for any cross-posting, but this is unavoidable given the subject line.

:)

> During IETF 77, the security ADs suggested that we merge the KITTEN
> and SASL WGs.  This has some potential benefits:
> 
> 1. ensure efforts of any new work items/extensions
> 2. both WGs have expertise in security interface design
> 3. analyze proposed security mechanisms for both set of interfaces

Note that KITTEN never had mechanism standardization as a
responsibility.  Now its successor will?  This means that the new WG's
charter can't just be a union of the KITTEN and SASL charters.

> Please respond to both lists if you have any objections to such a
> merger.  The time-out for objections is two weeks from this posting.

No objections here.

I would like to see the proposed charter, of course.

I'm also curious as to the name of the new WG.  I'd be fine with keeping
either of KITTEN or SASL as the name for the new WG.  I'd also be happy
with a new name.

Nico
-- 

From lear@cisco.com  Sat May  8 04:57:40 2010
Return-Path: <lear@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97513A6A41; Sat,  8 May 2010 04:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.07
X-Spam-Level: 
X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-2.331,  BAYES_20=-0.74, 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 dnQyVGG7WhP1; Sat,  8 May 2010 04:57:40 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5E0093A6A10; Sat,  8 May 2010 04:57:39 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwBALvt5EuQ/uCWiWdsb2JhbACDGJsBFQEBAQoLEREGHKRDiHSQGoQnbgQ
X-IronPort-AV: E=Sophos;i="4.52,352,1270425600"; d="scan'208,217";a="6981206"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 08 May 2010 11:19:46 +0000
Received: from dhcp-10-61-96-68.cisco.com (dhcp-10-61-96-68.cisco.com [10.61.96.68]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o48BvPXA021492; Sat, 8 May 2010 11:57:25 GMT
Message-ID: <4BE5518B.7060101@cisco.com>
Date: Sat, 08 May 2010 13:56:59 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100507 Lanikai/3.1pre
MIME-Version: 1.0
To: Shawn Emery <shawn.emery@oracle.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com>
In-Reply-To: <4BE1E547.5030103@oracle.com>
Content-Type: multipart/alternative; boundary="------------070805090405080602040306"
X-Mailman-Approved-At: Sat, 08 May 2010 09:00:25 -0700
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 May 2010 11:57:40 -0000

This is a multi-part message in MIME format.
--------------070805090405080602040306
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

  Dear everyone,

I find it hard to have this discussion without understanding what the 
new charter would be.  Is there a pointer somewhere?  We had discussions 
relating to our SAML/OpenID SASL drafts being handled by the new group, 
but I don't know what would be in scope.

Thanks,

Eliot



On 5/5/10 11:38 PM, Shawn Emery wrote:
>
>
> Sorry for any cross-posting, but this is unavoidable given the subject 
> line.
>
> During IETF 77, the security ADs suggested that we merge the KITTEN 
> and SASL WGs.  This has some potential benefits:
>
> 1. ensure efforts of any new work items/extensions
> 2. both WGs have expertise in security interface design
> 3. analyze proposed security mechanisms for both set of interfaces
>
> Please respond to both lists if you have any objections to such a 
> merger.  The time-out for objections is two weeks from this posting.
>
> Thank you,
>
> Shawn KITTEN co-chair
> --
>
>
> _______________________________________________
> sasl mailing list
> sasl@ietf.org
> https://www.ietf.org/mailman/listinfo/sasl

--------------070805090405080602040306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Dear everyone,<br>
    <br>
    I find it hard to have this discussion without understanding what
    the new charter would be.  Is there a pointer somewhere?  We had
    discussions relating to our SAML/OpenID SASL drafts being handled by
    the new group, but I don't know what would be in scope.<br>
    <br>
    Thanks,<br>
    <br>
    Eliot<br>
    <br>
    <br>
    <br>
    On 5/5/10 11:38 PM, Shawn Emery wrote:
    <blockquote cite="mid:4BE1E547.5030103@oracle.com" type="cite">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <font size="+1"><tt><br>
          <br>
          Sorry for any cross-posting, but this is unavoidable given the
          subject
          line.<br>
          <br>
          During IETF 77, the security ADs suggested that we merge the
          KITTEN and
          SASL WGs.  This has some potential benefits:<br>
          <br>
          1. ensure efforts of any new work items/extensions<br>
          2. both WGs have expertise in security interface design<br>
          3. analyze proposed security mechanisms for both set of
          interfaces <br>
          <br>
          Please respond to both lists if you have any objections to
          such a
          merger.  The
          time-out for objections is two weeks from this posting.<br>
          <br>
          Thank you,<br>
          <br>
          Shawn KITTEN co-chair<br>
          --</tt></font><br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
sasl mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sasl@ietf.org">sasl@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/sasl">https://www.ietf.org/mailman/listinfo/sasl</a>
</pre>
    </blockquote>
  </body>
</html>

--------------070805090405080602040306--

From alexey.melnikov@isode.com  Sat May  8 15:36:43 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073B23A685E; Sat,  8 May 2010 15:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579,  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 For+hG2cSYzE; Sat,  8 May 2010 15:36:42 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 217EC3A6812; Sat,  8 May 2010 15:36:42 -0700 (PDT)
Received: from [92.40.175.111] (92.40.175.111.sub.mbb.three.co.uk [92.40.175.111])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S-XnbABeGV9C@rufus.isode.com>; Sat, 8 May 2010 23:36:29 +0100
Message-ID: <4BE5E729.50107@isode.com>
Date: Sat, 08 May 2010 23:35:21 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <lear@cisco.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com>
In-Reply-To: <4BE5518B.7060101@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
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 May 2010 22:36:43 -0000

Eliot Lear wrote:

> Dear everyone,
>
> I find it hard to have this discussion without understanding what the 
> new charter would be.  Is there a pointer somewhere?  We had 
> discussions relating to our SAML/OpenID SASL drafts being handled by 
> the new group, but I don't know what would be in scope.

Hi Eliot,
There is no charter proposal for the merged WG, so at this point we are 
discussing things "in general".


From simon@josefsson.org  Sun May  9 08:15:14 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DCC3A6A26; Sun,  9 May 2010 08:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.716
X-Spam-Level: 
X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_05=-1.11]
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 KphPdJEdmRfn; Sun,  9 May 2010 08:15:13 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id AF7023A6A31; Sun,  9 May 2010 08:13:53 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o49FDYYs004102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 9 May 2010 17:13:35 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Eliot Lear <lear@cisco.com>
Subject: Re: SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100509:lear@cisco.com::BX5Sa9l0d39R6f10:3T72
X-Hashcash: 1:22:100509:sasl@ietf.org::2GFSd8DBOyP0rhQV:BCWW
X-Hashcash: 1:22:100509:kitten@ietf.org::0myMqDPyZmQYyltl:KsR8
X-Hashcash: 1:22:100509:shawn.emery@oracle.com::PxftXpwjZLlWtNZm:PHCI
Date: Sun, 09 May 2010 17:13:33 +0200
In-Reply-To: <4BE5518B.7060101@cisco.com> (Eliot Lear's message of "Sat, 08 May 2010 13:56:59 +0200")
Message-ID: <87ljbtumzm.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 May 2010 15:15:14 -0000

Eliot Lear <lear@cisco.com> writes:

>  Dear everyone,
>
> I find it hard to have this discussion without understanding what the
> new charter would be.  Is there a pointer somewhere?  We had
> discussions relating to our SAML/OpenID SASL drafts being handled by
> the new group, but I don't know what would be in scope.

To me, the SAML/OpenID mechanisms are perhaps the most important work
item for a new working group, so I would be disappointed if it is not
mentioned in the charter.

/Simon

From Nicolas.Williams@oracle.com  Mon May 10 07:57:22 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B783A6995; Mon, 10 May 2010 07:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.245
X-Spam-Level: 
X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.939,  BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpzvmNEeVCtU; Mon, 10 May 2010 07:57:21 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 253863A6951; Mon, 10 May 2010 07:57:21 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AEv4mS012486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 14:57:05 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AEuxAC028383; Mon, 10 May 2010 14:57:02 GMT
Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 227879541273503417; Mon, 10 May 2010 07:56:57 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 07:56:56 -0700
Date: Mon, 10 May 2010 09:56:49 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Simon Josefsson <simon@josefsson.org>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
Message-ID: <20100510145648.GO9429@oracle.com>
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ljbtumzm.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet13.oracle.com [148.87.113.125]
X-CT-RefId: str=0001.0A090208.4BE81EC2.0165:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org, Eliot Lear <lear@cisco.com>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 14:57:22 -0000

On Sun, May 09, 2010 at 05:13:33PM +0200, Simon Josefsson wrote:
> Eliot Lear <lear@cisco.com> writes:
> > I find it hard to have this discussion without understanding what the
> > new charter would be.  Is there a pointer somewhere?  We had
> > discussions relating to our SAML/OpenID SASL drafts being handled by
> > the new group, but I don't know what would be in scope.
> 
> To me, the SAML/OpenID mechanisms are perhaps the most important work
> item for a new working group, so I would be disappointed if it is not
> mentioned in the charter.

I don't care if the work Eliot mentions goes in this WG or a separate
WG as long as the work gets done :)

To start, the proposal to merge these two WGs is fairly straightforward
since merging the two charters presents only one minor conflict and
since both the GSS-API and SASL have been converging to a large degree.
The one minor conflict is that KITTEN was not chartered to work on
mechanisms, but SASL did do work on mechanisms (SCRAM, MD5-DIGEST, ...).
I think that is easy to resolve: let the new WG work on mechanisms in
general, or else list the kinds of mechanisms that the new WG may work
on, or, if we think we don't need any new mechanisms, then don't allow
the new WG to work on any.

Nico
-- 

From Nicolas.Williams@oracle.com  Mon May 10 08:11:06 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6690D3A69FE; Mon, 10 May 2010 08:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.535
X-Spam-Level: 
X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[AWL=2.063,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6YDM78M1kiA; Mon, 10 May 2010 08:11:04 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 846243A6403; Mon, 10 May 2010 08:11:03 -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.1) with ESMTP id o4AFAlaA013021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 15:10:48 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AFAgP4032665; Mon, 10 May 2010 15:10:42 GMT
Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 251611521273504157; Mon, 10 May 2010 08:09:17 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 08:09:11 -0700
Date: Mon, 10 May 2010 10:09:07 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Eliot Lear <lear@cisco.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
Message-ID: <20100510150905.GQ9429@oracle.com>
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com> <4BE82041.9070507@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BE82041.9070507@cisco.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090205.4BE821F9.0015:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 15:11:06 -0000

On Mon, May 10, 2010 at 05:03:29PM +0200, Eliot Lear wrote:
> Thanks for your notes.  I have no problem in principle with the
> merger, and in fact think it makes a whole lot of sense.  But I
> always like to look at the detail.

No problem.  In fact, I asked to see the proposed charter before you did :)

>                                     Also, I'll just point out that
> this is our opportunity for a new SASSY WG name (KITTEN-KABOODLE?)
> ;-)

Heh.  It's been done too much now :) but I'm OK with that.

Nico
-- 

From lear@cisco.com  Mon May 10 08:04:13 2010
Return-Path: <lear@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A94628C19E; Mon, 10 May 2010 08:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Level: 
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[AWL=2.682,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klFI8mqmuc3Q; Mon, 10 May 2010 08:04:12 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CE30C28C166; Mon, 10 May 2010 08:04:11 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkBAD+950uQ/uCWiWdsb2JhbACDF5sIFQEBAQoLEREGHKNZiHSQNIElgwFuBA
X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="60996382"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 May 2010 15:03:59 +0000
Received: from dhcp-10-55-86-118.cisco.com (dhcp-10-55-86-118.cisco.com [10.55.86.118]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AF3xPc011457; Mon, 10 May 2010 15:03:59 GMT
Message-ID: <4BE82041.9070507@cisco.com>
Date: Mon, 10 May 2010 17:03:29 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100509 Lanikai/3.1pre
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com>
In-Reply-To: <20100510145648.GO9429@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 10 May 2010 09:25:12 -0700
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 15:04:13 -0000

  Nico, all,

Thanks for your notes.  I have no problem in principle with the merger, 
and in fact think it makes a whole lot of sense.  But I always like to 
look at the detail.  Also, I'll just point out that this is our 
opportunity for a new SASSY WG name (KITTEN-KABOODLE?) ;-)

Eliot

From jhutz@cmu.edu  Tue May 11 11:13:48 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B703628C200; Tue, 11 May 2010 11:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.019
X-Spam-Level: 
X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUu+530zL3xs; Tue, 11 May 2010 11:13:40 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 8036A3A6C0C; Tue, 11 May 2010 11:12:54 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4BICVQ3024023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 14:12:31 -0400 (EDT)
Date: Tue, 11 May 2010 14:12:31 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Eliot Lear <lear@cisco.com>, Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
Message-ID: <176E8F86825AF9BE457A43D2@minbar.fac.cs.cmu.edu>
In-Reply-To: <11586_1273508712_o4AGPBeI021842_4BE82041.9070507@cisco.com>
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com>	<87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com> <11586_1273508712_o4AGPBeI021842_4BE82041.9070507@cisco.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.196
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 18:13:48 -0000

--On Monday, May 10, 2010 05:03:29 PM +0200 Eliot Lear <lear@cisco.com> 
wrote:

Also, I'll just point out that this is our
> opportunity for a new SASSY WG name (KITTEN-KABOODLE?) ;-)

Absolutely not.  Working group acronyms containing dashes are a major pain.
:-)

From tony@att.com  Tue May 11 13:29:58 2010
Return-Path: <tony@att.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E821D3A67B5; Tue, 11 May 2010 13:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 55dX-XL-HU4i; Tue, 11 May 2010 13:29:57 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9D71F3A69E4; Tue, 11 May 2010 13:28:11 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1273609679!55845038!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 21369 invoked from network); 11 May 2010 20:28:00 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2010 20:28:00 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4BKSC2h027972; Tue, 11 May 2010 16:28:12 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4BKSBVQ027950; Tue, 11 May 2010 16:28:11 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4BKRvaC009722; Tue, 11 May 2010 16:27:57 -0400
Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4BKRrZK009609; Tue, 11 May 2010 16:27:53 -0400
Received: from [135.25.190.148] (njcdtl02ga7127.ugd.att.com[135.25.190.148]) by maillennium.att.com (mailgw1) with ESMTP id <20100511202751gw100b8ilqe> (Authid: tony); Tue, 11 May 2010 20:27:53 +0000
X-Originating-IP: [135.25.190.148]
Message-ID: <4BE9BDC6.7070303@att.com>
Date: Tue, 11 May 2010 16:27:50 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com>	<4BE5518B.7060101@cisco.com>	<87ljbtumzm.fsf@mocca.josefsson.org>	<20100510145648.GO9429@oracle.com>	<11586_1273508712_o4AGPBeI021842_4BE82041.9070507@cisco.com> <176E8F86825AF9BE457A43D2@minbar.fac.cs.cmu.edu>
In-Reply-To: <176E8F86825AF9BE457A43D2@minbar.fac.cs.cmu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 11 May 2010 13:38:27 -0700
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>, sasl@ietf.org, Eliot Lear <lear@cisco.com>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 20:29:59 -0000

what's a good retronym for KABOODLE?

On 5/11/2010 2:12 PM, Jeffrey Hutzelman wrote:
> --On Monday, May 10, 2010 05:03:29 PM +0200 Eliot Lear 
> <lear@cisco.com> wrote:
>
> Also, I'll just point out that this is our
>> opportunity for a new SASSY WG name (KITTEN-KABOODLE?) ;-)
>
> Absolutely not.  Working group acronyms containing dashes are a major 
> pain.
> :-)

From tlyu@mit.edu  Wed May 12 14:42:11 2010
Return-Path: <tlyu@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E353A690C; Wed, 12 May 2010 14:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.445
X-Spam-Level: 
X-Spam-Status: No, score=0.445 tagged_above=-999 required=5 tests=[AWL=0.444,  BAYES_50=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 z3w4oLTRGYGv; Wed, 12 May 2010 14:42:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id F30453A69A4; Wed, 12 May 2010 14:41:55 -0700 (PDT)
X-AuditID: 12074424-b7b9dae000002832-5b-4beb2099cf3c
Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 87.5D.10290.9902BEB4; Wed, 12 May 2010 17:41:45 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o4CLfj7T025473;  Wed, 12 May 2010 17:41:45 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4CLfha7010200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 May 2010 17:41:44 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4CLfhwJ016412; Wed, 12 May 2010 17:41:43 -0400 (EDT)
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 12 May 2010 17:41:43 -0400
In-Reply-To: <20100506164630.GU9429@oracle.com> (Nicolas Williams's message of "Thu, 6 May 2010 11:46:31 -0500")
Message-ID: <ldvfx1w6bmw.fsf@cathode-dark-space.mit.edu>
Lines: 10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: AAAAAA==
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2010 21:42:11 -0000

Nicolas Williams <Nicolas.Williams@oracle.com> writes:

> I'm also curious as to the name of the new WG.  I'd be fine with keeping
> either of KITTEN or SASL as the name for the new WG.  I'd also be happy
> with a new name.

I propose something like

MOGGIES =
Mechanisms Of Generating Generically Interoperable & Effective Security

From lear@cisco.com  Thu May 13 00:41:58 2010
Return-Path: <lear@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1913A6936; Thu, 13 May 2010 00:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level: 
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[AWL=2.590,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPEDPLvaWHww; Thu, 13 May 2010 00:41:57 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 73AC63A67DB; Thu, 13 May 2010 00:41:56 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskBAH9J60uQ/uCWe2dsb2JhbACDF5sTFQEBFiIGHKIEiHSQRIEmgwFrBI89
X-IronPort-AV: E=Sophos;i="4.53,220,1272844800"; d="scan'208";a="61209408"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 May 2010 07:41:45 +0000
Received: from dhcp-10-61-96-203.cisco.com (dhcp-10-61-96-203.cisco.com [10.61.96.203]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4D7fjGs021256; Thu, 13 May 2010 07:41:45 GMT
Message-ID: <4BEBAD17.10908@cisco.com>
Date: Thu, 13 May 2010 09:41:11 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100512 Lanikai/3.1pre
MIME-Version: 1.0
To: Tom Yu <tlyu@MIT.EDU>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com> <ldvfx1w6bmw.fsf@cathode-dark-space.mit.edu>
In-Reply-To: <ldvfx1w6bmw.fsf@cathode-dark-space.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2010 07:41:58 -0000

On 5/12/10 11:41 PM, Tom Yu wrote:
> I propose something like
>
> MOGGIES =
> Mechanisms Of Generating Generically Interoperable&  Effective Security

I like it!

By the way, it sounds like if we're all having this excellent discussion 
over the name, we're all pretty much in agreement as to direction.  Do I 
understand this to be correct?

Eliot

From shawn.emery@oracle.com  Thu May 13 00:47:26 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FAB3A6B60; Thu, 13 May 2010 00:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.566
X-Spam-Level: 
X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=1.544,  BAYES_05=-1.11, 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 y6ol5jNjsAWz; Thu, 13 May 2010 00:47:25 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C7C7C3A6B6B; Thu, 13 May 2010 00:46:44 -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.1) with ESMTP id o4D7kVGv002329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 07:46:33 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4D1kGdZ024662; Thu, 13 May 2010 07:46:30 GMT
Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 261001751273736783; Thu, 13 May 2010 00:46:23 -0700
Received: from [129.150.12.66] (/129.150.12.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 00:46:23 -0700
Message-ID: <4BEBAE4D.1050807@oracle.com>
Date: Thu, 13 May 2010 01:46:21 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com>	<ldvfx1w6bmw.fsf@cathode-dark-space.mit.edu> <4BEBAD17.10908@cisco.com>
In-Reply-To: <4BEBAD17.10908@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090205.4BEBAE59.016D:SCFMA922111,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org, Tom Yu <tlyu@MIT.EDU>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2010 07:47:26 -0000

On 05/13/10 01:41 AM, Eliot Lear wrote:
>
>
> On 5/12/10 11:41 PM, Tom Yu wrote:
>> I propose something like
>>
>> MOGGIES =
>> Mechanisms Of Generating Generically Interoperable&  Effective Security
>
> I like it!
>
> By the way, it sounds like if we're all having this excellent 
> discussion over the name, we're all pretty much in agreement as to 
> direction.  Do I understand this to be correct?

I'm currently drafting charter text for the new WG and should be ready 
for review by KITTEN and SASL WG members some time next week.

Shawn.
--

From tony@att.com  Thu May 13 05:00:40 2010
Return-Path: <tony@att.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF5B3A69A8; Thu, 13 May 2010 05:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.921
X-Spam-Level: 
X-Spam-Status: No, score=-104.921 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_50=0.001, 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 czKL7kv2grh7; Thu, 13 May 2010 05:00:40 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id AFFAA3A680D; Thu, 13 May 2010 05:00:38 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-4.tower-120.messagelabs.com!1273752027!48603704!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 391 invoked from network); 13 May 2010 12:00:28 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 May 2010 12:00:28 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4DC0eqm030463; Thu, 13 May 2010 08:00:40 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4DC0Y1c030360; Thu, 13 May 2010 08:00:34 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4DC0K6k023832; Thu, 13 May 2010 08:00:20 -0400
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4DC0Ejm023447; Thu, 13 May 2010 08:00:14 -0400
Received: from [135.70.233.3] (vpn-135-70-233-3.vpn.east.att.com[135.70.233.3]) by maillennium.att.com (mailgw1) with ESMTP id <20100513120014gw100b8itoe> (Authid: tony); Thu, 13 May 2010 12:00:14 +0000
X-Originating-IP: [135.70.233.3]
Message-ID: <4BEBE9CA.8030902@att.com>
Date: Thu, 13 May 2010 08:00:10 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: kitten@ietf.org, sasl@ietf.org
Subject: Re: [sasl] SASL and KITTEN-WG Merger
References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com>	<ldvfx1w6bmw.fsf@cathode-dark-space.mit.edu> <4BEBAD17.10908@cisco.com>
In-Reply-To: <4BEBAD17.10908@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2010 12:00:40 -0000

I haven't seen any nay-sayers. I'm in the "ok, fine by me" camp myself.

     Tony Hansen

On 5/13/2010 3:41 AM, Eliot Lear wrote:
> On 5/12/10 11:41 PM, Tom Yu wrote:
>> I propose something like
>>
>> MOGGIES =
>> Mechanisms Of Generating Generically Interoperable&  Effective Security
>
> I like it!
>
> By the way, it sounds like if we're all having this excellent 
> discussion over the name, we're all pretty much in agreement as to 
> direction.  Do I understand this to be correct?
>
> Eliot

From mrex@sap.com  Fri May 14 11:13:37 2010
Return-Path: <mrex@sap.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870E43A67BD; Fri, 14 May 2010 11:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.717
X-Spam-Level: 
X-Spam-Status: No, score=-7.717 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmbLTikBSuR3; Fri, 14 May 2010 11:13:36 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 574D53A67AE; Fri, 14 May 2010 11:13:35 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4EIDMfV004103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 20:13:22 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005141813.o4EIDLaP026201@fs4113.wdf.sap.corp>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
To: lear@cisco.com (Eliot Lear)
Date: Fri, 14 May 2010 20:13:21 +0200 (MEST)
In-Reply-To: <4BEBAD17.10908@cisco.com> from "Eliot Lear" at May 13, 10 09:41:11 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: kitten@ietf.org, sasl@ietf.org, tlyu@MIT.EDU
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2010 18:13:37 -0000

Eliot Lear wrote:
> 
> On 5/12/10 11:41 PM, Tom Yu wrote:
> > I propose something like
> >
> > MOGGIES =
> > Mechanisms Of Generating Generically Interoperable&  Effective Security
> 
> I like it!
> 
> By the way, it sounds like if we're all having this excellent discussion 
> over the name, we're all pretty much in agreement as to direction.  Do I 
> understand this to be correct?

I'm fine with whatever active participants and chairs of both WGs seem fit.

IIRC, SASL (rfc2222) was not a chartered work item of CAT, but instead
an individual submission of John Myers.  However, SASL was reviewed
by active CAT participants and CAT meeting time was provided on
IETF Meetings for presenting SASL progress.

-Martin

From hartmans@mit.edu  Fri May 14 12:21:04 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C6E28C160; Fri, 14 May 2010 12:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.285
X-Spam-Level: 
X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2cThnTUVrei; Fri, 14 May 2010 12:21:03 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9D9F03A6BFE; Fri, 14 May 2010 12:19:45 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 76B7B20239; Fri, 14 May 2010 15:19:36 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8E89F43EE; Fri, 14 May 2010 15:19:34 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: saag@mit.edu
Subject: Summary of Federated Authentication BOF at IETF 77
Date: Fri, 14 May 2010 15:19:34 -0400
Message-ID: <tslbpciqojd.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2010 19:21:04 -0000

I'm told there were around 30 people in the room.  That seemed like a
good turn out for Thursday at 9 PM.

Many of the participants had already read some or all of the proposed
documents.
I presented a problem statement based on providing federated
authentication  for non-web applications.
Two solutions were presented.  I presented work on Moonshot, a
technology that combines EAP, GSS-API, RADIUS and SAML to solve the
problem.  Eliot Lear and Klaas Wierenga presented a simpler solution
that uses browser-based SAML and Open ID.

The sense of the room was that these solutions compliment each other.
Moonshot requires more infrastructure and client configuration but
provides several advantages.  The browser-based solutions are something
that requires fewer client changes.

Volunteers were collected from the EAP, GSS and RADIUS communities who
would be interested in working on these problems.  Some of the work
discussed, possibly especially including the Open ID and SAML
browser-based solutions may be able to progress in kitten.  I and I
believe several of the other Moonshot proponents would prefer to focus
the Moonshot work in one working group.  Other solutions could also be
progressed in that group, although we should be careful not to slow down
work that could progress quickly in kitten by moving it into an
as-yet-unchartered group.

There seemed to be strong support for going forward.  However, several
things to address in a BOF were raised with regard to the Moonshot work.

* Steve Bellovin pointed out that we need to be very aware of the
  operational impact and how this fits with the operational model of the
  technologies that are used/extended.

* Klaas pointed out that Moonshot involves changes to a lot of different
  components.  We need to make sure that there are incremental
  advantages to each of these changes so they will be deployed: a system
  where there is no benefit until the end when all the peaces fall
  together is much harder to deploy.

* Klaas pointed out that we need to consider  the operational security
  around how RADIUS federations are deployed.  If network access is not
  considered sensitive today, people may be more lax in the security
  surrounding their RADIUS infrastructure.  If we use that
  infrastructure to secure more sensitive resources we need to have
  practices that tighten up the security of the infrastructure
  sufficiently.

* Someone brought up that this is another one of those authentication
  proposals where user-interface is critical.  While we should not lay
  out dialogues in the IETF, we're going to need to describe the
  usability aspects of this enough to increase the probability of a good
  security solution.

People specifically asked to look at the following:
* Complexity
* What can't be handled with simpler solutions
* Is Moonshot broad enough in scope?
* The UI questions

Since the bar BOF, there has been a lot of traffic on the list and work
continues.
We're definitely going to put together a BOF request for IETF 78.

From hartmans@mit.edu  Fri May 14 12:23:04 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B88D3A683F; Fri, 14 May 2010 12:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.285
X-Spam-Level: 
X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyfWTvsIcCVO; Fri, 14 May 2010 12:23:00 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 021F928C154; Fri, 14 May 2010 12:22:04 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7A74220239; Fri, 14 May 2010 15:21:54 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A663743EE; Fri, 14 May 2010 15:21:52 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: saag@ietf.org
Subject: Summary of Federated Authentication BOF at IETF 77
Date: Fri, 14 May 2010 15:19:34 -0400
Message-ID: <tslbpciqojd.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
X-Brightmail-Tracker: AAAAAA==
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2010 19:23:04 -0000

I'm told there were around 30 people in the room.  That seemed like a
good turn out for Thursday at 9 PM.

Many of the participants had already read some or all of the proposed
documents.
I presented a problem statement based on providing federated
authentication  for non-web applications.
Two solutions were presented.  I presented work on Moonshot, a
technology that combines EAP, GSS-API, RADIUS and SAML to solve the
problem.  Eliot Lear and Klaas Wierenga presented a simpler solution
that uses browser-based SAML and Open ID.

The sense of the room was that these solutions compliment each other.
Moonshot requires more infrastructure and client configuration but
provides several advantages.  The browser-based solutions are something
that requires fewer client changes.

Volunteers were collected from the EAP, GSS and RADIUS communities who
would be interested in working on these problems.  Some of the work
discussed, possibly especially including the Open ID and SAML
browser-based solutions may be able to progress in kitten.  I and I
believe several of the other Moonshot proponents would prefer to focus
the Moonshot work in one working group.  Other solutions could also be
progressed in that group, although we should be careful not to slow down
work that could progress quickly in kitten by moving it into an
as-yet-unchartered group.

There seemed to be strong support for going forward.  However, several
things to address in a BOF were raised with regard to the Moonshot work.

* Steve Bellovin pointed out that we need to be very aware of the
  operational impact and how this fits with the operational model of the
  technologies that are used/extended.

* Klaas pointed out that Moonshot involves changes to a lot of different
  components.  We need to make sure that there are incremental
  advantages to each of these changes so they will be deployed: a system
  where there is no benefit until the end when all the peaces fall
  together is much harder to deploy.

* Klaas pointed out that we need to consider  the operational security
  around how RADIUS federations are deployed.  If network access is not
  considered sensitive today, people may be more lax in the security
  surrounding their RADIUS infrastructure.  If we use that
  infrastructure to secure more sensitive resources we need to have
  practices that tighten up the security of the infrastructure
  sufficiently.

* Someone brought up that this is another one of those authentication
  proposals where user-interface is critical.  While we should not lay
  out dialogues in the IETF, we're going to need to describe the
  usability aspects of this enough to increase the probability of a good
  security solution.

People specifically asked to look at the following:
* Complexity
* What can't be handled with simpler solutions
* Is Moonshot broad enough in scope?
* The UI questions

Since the bar BOF, there has been a lot of traffic on the list and work
continues.
We're definitely going to put together a BOF request for IETF 78.

From Nicolas.Williams@oracle.com  Fri May 14 12:45:36 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BE23A6925; Fri, 14 May 2010 12:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.503
X-Spam-Level: 
X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=0.606,  BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaG0mmm3VknZ; Fri, 14 May 2010 12:45:35 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7E8CC3A68DD; Fri, 14 May 2010 12:45:35 -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.1) with ESMTP id o4EJjJ6r005560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 May 2010 19:45:21 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 o4EI7kGx015373; Fri, 14 May 2010 19:45:16 GMT
Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 266589741273866312; Fri, 14 May 2010 12:45:12 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 May 2010 12:45:12 -0700
Date: Fri, 14 May 2010 14:45:07 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Martin Rex <mrex@sap.com>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
Message-ID: <20100514194507.GI9429@oracle.com>
References: <4BEBAD17.10908@cisco.com> <201005141813.o4EIDLaP026201@fs4113.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201005141813.o4EIDLaP026201@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090204.4BEDA853.0188:SCFMA922111,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org, lear@cisco.com, tlyu@MIT.EDU
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2010 19:45:37 -0000

On Fri, May 14, 2010 at 08:13:21PM +0200, Martin Rex wrote:
> IIRC, SASL (rfc2222) was not a chartered work item of CAT, but instead
> an individual submission of John Myers.  However, SASL was reviewed
> by active CAT participants and CAT meeting time was provided on
> IETF Meetings for presenting SASL progress.

SASL and CAT/KITTEN go really together...

SASL & KITTEN, sitting on a KRB k i s s i n g.
Then a HIP XCON EMU ROLLed by and said
"BFD, I can handle more peers than you two".

From shawn.emery@oracle.com  Mon May 17 22:13:05 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9423A6BF6; Mon, 17 May 2010 22:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.164
X-Spam-Level: 
X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.834,  BAYES_50=0.001, 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 cODgSy5KrY8s; Mon, 17 May 2010 22:12:59 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6DDAB3A6BFC; Mon, 17 May 2010 22:12:55 -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.1) with ESMTP id o4I5CiPL009887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 05:12:46 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HNPG3d024917; Tue, 18 May 2010 05:12:41 GMT
Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 273140181274159555; Mon, 17 May 2010 22:12:35 -0700
Received: from [129.150.48.63] (/129.150.48.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 22:12:34 -0700
Message-ID: <4BF221C1.2090005@oracle.com>
Date: Mon, 17 May 2010 23:12:33 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: kitten@ietf.org, sasl@ietf.org
Subject: MOGGIES Proposed Charter
Content-Type: multipart/mixed; boundary="------------000601080203050901040802"
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090204.4BF221CE.00FA:SCFMA922111,ss=1,fgs=0
Cc: Tim Polk <tim.polk@nist.gov>, Sean Turner <turners@ieca.com>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 05:13:05 -0000

This is a multi-part message in MIME format.
--------------000601080203050901040802
Content-Type: multipart/alternative;
 boundary="------------020603040801080606000202"


--------------020603040801080606000202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


As discussed; attached is the proposed charter text for a new working 
group (MOGGIES) based on future direction in the GSS-API and SASL 
space.  Please provide any feed-back to the lists by the end of May.

Thank you,

Shawn Emery and Tom Yu (co-chairs)
--

--------------020603040801080606000202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<font size="+1"><tt><br>
As discussed; attached is the proposed charter text for a new working
group (MOGGIES) based on future direction in the GSS-API and SASL
space.&nbsp; Please provide any feed-back to the lists by the end of May.<br>
<br>
Thank you,<br>
<br>
Shawn Emery and Tom Yu (co-chairs)<br>
--<br>
</tt></font>
</body>
</html>

--------------020603040801080606000202--

--------------000601080203050901040802
Content-Type: text/plain;
 name="moggies-charter.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="moggies-charter.txt"

MOGGIES (Mechanisms Of Generating Generically Interoperable & Effective
Security)


Description of Working Group:

The Generic Security Services (GSS) API and Simple Authentication and Security
Layer (SASL) provide various applications with a security framework for secure
network communication.  The purpose of the Mechanisms Of Generating Generically
Interoperable & Effective Security (MOGGIES) working group (WG) is to develop
extensions/improvements to the GSS-API, shepherd specific GSS-API security
mechanisms, revise SASLprep with a stringprep profile from the NewPrep WG, and
provide guidance for any new SASL-related submissions.
 
This working is chartered to specify the following extensions and improvements
(draft-yu-kitten-api-wishlist-00) to the GSS-API:

* Provide new interfaces for credential management, which include the following:
	initializing credentials
	iterating credentials
	exporting/importing credentials

* Specify interface for asynchronous calls.

* Define interfaces for better error message reporting.

* Specify an interface for reporting the security strength of GSS-API mechanism.

* Provide a more programmer friendly interface for application developers.

This working group is also chartered to transition proposed SASL mechanisms as
GSS-API mechanisms:

* A SASL Mechanism for OpenID
	draft-lear-ietf-sasl-openid-00
* A SASL Mechanism for SAML
	draft-wierenga-ietf-sasl-saml-00

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 (RFC 5801).

The working group shall also revise SASLprep with a stringprep profile developed
by the NewPrep WG.

This working group will review SASL related submissions as well, including any
new SASL mechanisms proposed.


Deliverables:

* GSS-API: initializing credentials
[editor: TBD]

* GSS-API: iterating credentials
[editor: TBD]

* GSS-API: exporting/importing credentials
[editor: TBD]

* GSS-API: specification for asynchronous calls
[editor: TBD]

* GSS-API: interfaces/improvements for better error message reporting
[editor: TBD]

* GSS-API: reporting security strength
[editor: TBD]

* GSS-API: programmer friendly interfaces
[editor: TBD]

* GSS-API: transition SASL mechanism for OpenID
[editor: TBD]

* GSS-API: transition SASL mechanism for SAML
[editor: TBD]

* SASL: Revise SASLprep with stringprep from the NewPrep WG
[editor: TBD]


Goals and Milestones:

July 2010	First Meeting

TBD		Listed Work Items

--------------000601080203050901040802--

From simon@josefsson.org  Mon May 17 22:51:40 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860F83A6B66; Mon, 17 May 2010 22:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.39
X-Spam-Level: 
X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209,  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 QYmfJvi0FvMM; Mon, 17 May 2010 22:51:39 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id DC3EB3A6BD8; Mon, 17 May 2010 22:51:33 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4I5p41F031247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 May 2010 07:51:10 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Shawn Emery <shawn.emery@oracle.com>
Subject: Re: MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100518:kitten@ietf.org::xl9kTq9Obe2rLepy:Hce+
X-Hashcash: 1:22:100518:sasl@ietf.org::vqExf7YyssOAdaNy:J8hx
X-Hashcash: 1:22:100518:turners@ieca.com::TOanfYWwe9y70wIH:OQ+A
X-Hashcash: 1:22:100518:tim.polk@nist.gov::h4d+c5VQeK1kr3rA:X+f5
X-Hashcash: 1:22:100518:shawn.emery@oracle.com::GSOx6Clyi35F2dVo:O8rs
Date: Tue, 18 May 2010 07:51:04 +0200
In-Reply-To: <4BF221C1.2090005@oracle.com> (Shawn Emery's message of "Mon, 17 May 2010 23:12:33 -0600")
Message-ID: <87iq6lu59z.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, Sean Turner <turners@ieca.com>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 05:51:40 -0000

The charter looks fine to me.  Do we have energy to also look at moving
RFC 4422 from Proposed to Draft?  Unless I'm missing something, that
shouldn't be too complicated.  I recall some implementation evaluation
has already started.

/Simon

From leifj@sunet.se  Tue May 18 07:03:43 2010
Return-Path: <leifj@sunet.se>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3376C3A6943 for <kitten@core3.amsl.com>; Tue, 18 May 2010 07:03:43 -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 14BNB2mFulbf for <kitten@core3.amsl.com>; Tue, 18 May 2010 07:03:42 -0700 (PDT)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 8F3ED3A686E for <kitten@ietf.org>; Tue, 18 May 2010 07:03:36 -0700 (PDT)
Received: from [192.36.125.216] (dhcp-216.pilsnet.sunet.se [192.36.125.216] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o4IE3OCG004034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 16:03:26 +0200 (CEST)
Message-ID: <4BF29E2C.3070007@sunet.se>
Date: Tue, 18 May 2010 16:03:24 +0200
From: Leif Johansson <leifj@sunet.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: Shawn M Emery <Shawn.Emery@Sun.COM>
Subject: Feed draft-ietf-kitten-gssapi-naming-exts-07.txt to the IESG
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "kitten@ietf.org" <kitten@ietf.org>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 14:03:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Since we passwd WGLC I updated to 07 and bumped the expiration date.
Feel free to start the publication process using this version at any
time you like.

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvyniwACgkQ8Jx8FtbMZneJRgCfboYZUj8JacAAu56sNUX2KExG
s7MAnjJosuMMCXjEWmmgFierkR/I8gOd
=UzQ4
-----END PGP SIGNATURE-----

From root@core3.amsl.com  Tue May 18 07:15:05 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: kitten@ietf.org
Delivered-To: kitten@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id A89B43A6BDB; Tue, 18 May 2010 07:15:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-kitten-gssapi-naming-exts-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100518141504.A89B43A6BDB@core3.amsl.com>
Date: Tue, 18 May 2010 07:15:02 -0700 (PDT)
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 14:15:05 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF.


	Title           : GSS-API Naming Extensions
	Author(s)       : N. Williams, L. Johansson
	Filename        : draft-ietf-kitten-gssapi-naming-exts-07.txt
	Pages           : 14
	Date            : 2010-05-18

The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization.  This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-kitten-gssapi-naming-exts-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-05-18070153.I-D@ietf.org>


--NextPart--

From alexey.melnikov@isode.com  Tue May 18 09:28:11 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10763A69B2; Tue, 18 May 2010 09:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.217
X-Spam-Level: 
X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382,  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 dGnb34om+zIY; Tue, 18 May 2010 09:28:11 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8D67B28C1E4; Tue, 18 May 2010 09:20:43 -0700 (PDT)
Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S=K-UABeGSvl@rufus.isode.com>; Tue, 18 May 2010 17:20:35 +0100
Message-ID: <4BF2BE33.8010106@isode.com>
Date: Tue, 18 May 2010 17:20:03 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <simon@josefsson.org>
Subject: Re: MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <87iq6lu59z.fsf@mocca.josefsson.org>
In-Reply-To: <87iq6lu59z.fsf@mocca.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, Sean Turner <turners@ieca.com>, sasl@ietf.org, Tim Polk <tim.polk@nist.gov>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 16:28:11 -0000

Simon Josefsson wrote:

>The charter looks fine to me.  Do we have energy to also look at moving
>RFC 4422 from Proposed to Draft?  Unless I'm missing something, that
>shouldn't be too complicated.  I recall some implementation evaluation
>has already started.
>
I wouldn't object to this, as long as I don't need to write the implementation report. I can contribute necessary information for the Cyrus SASL though.
 


From alexey.melnikov@isode.com  Tue May 18 10:31:59 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0DB28C1F9; Tue, 18 May 2010 10:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.923
X-Spam-Level: 
X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_50=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 D1GR-24eZT1z; Tue, 18 May 2010 10:31:57 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 017F53A69AA; Tue, 18 May 2010 10:28:00 -0700 (PDT)
Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S=LOFQBeGZNG@rufus.isode.com>; Tue, 18 May 2010 18:27:51 +0100
Message-ID: <4BF2CDF2.2090600@isode.com>
Date: Tue, 18 May 2010 18:27:14 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <shawn.emery@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com>
In-Reply-To: <4BF221C1.2090005@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 17:31:59 -0000

Shawn Emery wrote:

> As discussed; attached is the proposed charter text for a new working 
> group (MOGGIES) based on future direction in the GSS-API and SASL 
> space.  Please provide any feed-back to the lists by the end of May.

Thanks for writing a proposal.
My comments below (without my AD hat):

> Thank you,
>
> Shawn Emery and Tom Yu (co-chairs)

-------------------------------------------------

>MOGGIES (Mechanisms Of Generating Generically Interoperable & Effective
>Security)
>
>
>Description of Working Group:
>
>The Generic Security Services (GSS) API and Simple Authentication and Security
>Layer (SASL) provide various applications with a security framework for secure
>network communication.  The purpose of the Mechanisms Of Generating Generically
>Interoperable & Effective Security (MOGGIES) working group (WG) is to develop
>extensions/improvements to the GSS-API, shepherd specific GSS-API security
>mechanisms, revise SASLprep with a stringprep profile from the NewPrep WG,
>
I think that SASLPrep should be done in the proposed newprep WG. There 
might be some bits that might be done in MOGGIES, but at this point I am 
not convinced there are any.

I am Ok with the rest of your list.

>and provide guidance for any new SASL-related submissions.
> 
>This working is chartered to specify the following extensions and improvements
>(draft-yu-kitten-api-wishlist-00) to the GSS-API:
>
>* Provide new interfaces for credential management, which include the following:
>	initializing credentials
>	iterating credentials
>	exporting/importing credentials
>
>* Specify interface for asynchronous calls.
>
>* Define interfaces for better error message reporting.
>
>* Specify an interface for reporting the security strength of GSS-API mechanism.
>
>* Provide a more programmer friendly interface for application developers.
>
>This working group is also chartered to transition proposed SASL mechanisms as
>GSS-API mechanisms:
>  
>
What does this mean? Do you mean that they become GS2 mechanisms?

>* A SASL Mechanism for OpenID
>	draft-lear-ietf-sasl-openid-00
>* A SASL Mechanism for SAML
>	draft-wierenga-ietf-sasl-saml-00
>
>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 (RFC 5801).
>
RFC 5801 hasn't been published yet. So I don't think we should reference it.

>The working group shall also revise SASLprep with a stringprep profile developed
>by the NewPrep WG.
>  
>
See above.

>This working group will review SASL related submissions as well, including any
>new SASL mechanisms proposed.
>
IMHO, this is a bit open ended for IESG.
Should we restrict this to SASL mechanisms, or are we saying that 
updates to SASL protocol profiles are also in scope? I think the answer 
is probably "no", although they should be reviewed here.

On a somewhat related note: is there still any interest in publish 
"DIGEST-MD5-to-historic" document, or should I request its publication 
outside of a Sec Area WG?

>Deliverables:
>
>* GSS-API: initializing credentials
>[editor: TBD]
>
>* GSS-API: iterating credentials
>[editor: TBD]
>
>* GSS-API: exporting/importing credentials
>[editor: TBD]
>
>* GSS-API: specification for asynchronous calls
>[editor: TBD]
>
>* GSS-API: interfaces/improvements for better error message reporting
>[editor: TBD]
>
>* GSS-API: reporting security strength
>[editor: TBD]
>
>* GSS-API: programmer friendly interfaces
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for OpenID
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for SAML
>[editor: TBD]
>
>* SASL: Revise SASLprep with stringprep from the NewPrep WG
>[editor: TBD]
>
>
>Goals and Milestones:
>
>July 2010	First Meeting
>
>TBD		Listed Work Items
>


From simon@josefsson.org  Tue May 18 10:48:59 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF113A6B8D; Tue, 18 May 2010 10:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.395
X-Spam-Level: 
X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204,  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 gZdpH1+W5FQy; Tue, 18 May 2010 10:48:58 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4C85C3A6CA5; Tue, 18 May 2010 10:47:31 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4IHlDg9019562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 May 2010 19:47:16 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <87iq6lu59z.fsf@mocca.josefsson.org> <4BF2BE33.8010106@isode.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100518:sasl@ietf.org::sZVw4Ecq2MXSMo8Y:4Zch
X-Hashcash: 1:22:100518:alexey.melnikov@isode.com::M136F5gIYyRPevPC:1/ir
X-Hashcash: 1:22:100518:kitten@ietf.org::An954q0RO6Zt0+eC:6A6W
X-Hashcash: 1:22:100518:tim.polk@nist.gov::VlNABa7nVpABAyOf:7Thj
Date: Tue, 18 May 2010 19:47:13 +0200
In-Reply-To: <4BF2BE33.8010106@isode.com> (Alexey Melnikov's message of "Tue,  18 May 2010 17:20:03 +0100")
Message-ID: <877hn19k66.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 17:48:59 -0000

Alexey Melnikov <alexey.melnikov@isode.com> writes:

> Simon Josefsson wrote:
>
>>The charter looks fine to me.  Do we have energy to also look at moving
>>RFC 4422 from Proposed to Draft?  Unless I'm missing something, that
>>shouldn't be too complicated.  I recall some implementation evaluation
>>has already started.
>>
> I wouldn't object to this, as long as I don't need to write the
> implementation report. I can contribute necessary information for the
> Cyrus SASL though.

I now recall one issue that was causing trouble earlier: SASLprep.  It
wasn't clear (at least not to me) whether it is a good idea to move RFC
4422 to Draft as long as it referenced SASLprep.  Now, the references to
SASLprep only affect other specifications, not implementations, thus we
might be able to dodge this issue completely by explaining that.

On the other hand, perhaps we should punt on moving SASL to Draft
Standard until we have some clear vision for the future of i18n in SASL.
The SASLprep replacement work the WG likely will be chartered to take on
may result in an update to RFC 4422, and we could move that replacement
document to Draft Standard instead of RFC 4422.

/Simon

From alexey.melnikov@isode.com  Tue May 18 10:50:28 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595CA3A6AA6; Tue, 18 May 2010 10:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOi12qTJ1nrj; Tue, 18 May 2010 10:50:27 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4D81A3A6AC6; Tue, 18 May 2010 10:49:23 -0700 (PDT)
Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S=LTGQBeGW6Y@rufus.isode.com>; Tue, 18 May 2010 18:49:14 +0100
Message-ID: <4BF2D2F9.20305@isode.com>
Date: Tue, 18 May 2010 18:48:41 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <simon@josefsson.org>
Subject: Re: MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <87iq6lu59z.fsf@mocca.josefsson.org> <4BF2BE33.8010106@isode.com> <877hn19k66.fsf@mocca.josefsson.org>
In-Reply-To: <877hn19k66.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, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 17:50:28 -0000

Simon Josefsson wrote:

>Alexey Melnikov <alexey.melnikov@isode.com> writes:
>
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>The charter looks fine to me.  Do we have energy to also look at moving
>>>RFC 4422 from Proposed to Draft?  Unless I'm missing something, that
>>>shouldn't be too complicated.  I recall some implementation evaluation
>>>has already started.
>>>      
>>>
>>I wouldn't object to this, as long as I don't need to write the
>>implementation report. I can contribute necessary information for the
>>Cyrus SASL though.
>>    
>>
>I now recall one issue that was causing trouble earlier: SASLprep.  It
>wasn't clear (at least not to me) whether it is a good idea to move RFC
>4422 to Draft as long as it referenced SASLprep.  Now, the references to
>SASLprep only affect other specifications, not implementations, thus we
>might be able to dodge this issue completely by explaining that.
>
>On the other hand, perhaps we should punt on moving SASL to Draft
>Standard until we have some clear vision for the future of i18n in SASL.
>The SASLprep replacement work the WG likely will be chartered to take on
>may result in an update to RFC 4422, and we could move that replacement
>document to Draft Standard instead of RFC 4422.
>  
>
Good point.


From simon@josefsson.org  Tue May 18 11:02:48 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA753A689D; Tue, 18 May 2010 11:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198,  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 kvpEyjXQo94Q; Tue, 18 May 2010 11:02:47 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D6EA73A6A76; Tue, 18 May 2010 11:02:39 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4II2QQr019993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 May 2010 20:02:28 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <4BF2CDF2.2090600@isode.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100518:shawn.emery@oracle.com::SQYsuTufsYD8wSYD:51H
X-Hashcash: 1:22:100518:sasl@ietf.org::s5kjjRDwjMOUX6yx:8K4Y
X-Hashcash: 1:22:100518:kitten@ietf.org::9QCormhZdolh+fG1:Eayn
X-Hashcash: 1:22:100518:tim.polk@nist.gov::CdOaJsibcOFkqGsn:Wi3W
X-Hashcash: 1:22:100518:alexey.melnikov@isode.com::L5tMYHfAyvZ7Es2R:aOOd
Date: Tue, 18 May 2010 20:02:26 +0200
In-Reply-To: <4BF2CDF2.2090600@isode.com> (Alexey Melnikov's message of "Tue,  18 May 2010 18:27:14 +0100")
Message-ID: <87ljbh84wd.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, sasl@ietf.org, Tim Polk <tim.polk@nist.gov>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 18:02:48 -0000

Alexey Melnikov <alexey.melnikov@isode.com> writes:

> On a somewhat related note: is there still any interest in publish
> "DIGEST-MD5-to-historic" document, or should I request its publication
> outside of a Sec Area WG?

I'd like to see publishing this in the charter.  We shouldn't let people
use DIGEST-MD5 without a big warning, and I believe we can establish WG
consensus around that.

/Simon

From Nicolas.Williams@oracle.com  Tue May 18 12:16:49 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF2028C181; Tue, 18 May 2010 12:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.173
X-Spam-Level: 
X-Spam-Status: No, score=-4.173 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUpMXR1PJxJh; Tue, 18 May 2010 12:16:47 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 898153A6AC0; Tue, 18 May 2010 12:16:47 -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.1) with ESMTP id o4IJGZCN004675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 19:16:37 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 o4IJGVVq022396; Tue, 18 May 2010 19:16:31 GMT
Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 277283101274210127; Tue, 18 May 2010 12:15:27 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 12:15:26 -0700
Date: Tue, 18 May 2010 14:15:22 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Shawn Emery <shawn.emery@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <20100518191521.GL9429@oracle.com>
References: <4BF221C1.2090005@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BF221C1.2090005@oracle.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090203.4BF2E796.0097:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 19:16:49 -0000

On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
> As discussed; attached is the proposed charter text for a new
> working group (MOGGIES) based on future direction in the GSS-API and
> SASL space.  Please provide any feed-back to the lists by the end of
> May.

I don't love the name (I keep thinking "MOOGIES", which sounds like
something gross :), but I'll live; I have no better suggestions.

> * Specify an interface for reporting the security strength of GSS-API mechanism.

I'd word that differently:

 * Specify an interface for enforcing security strength of GSS-API mechanisms.

The reason is that "reporting the security strength" of something
implies [to me] an absolute measure of security strength, and I don't
think it's possible to degisn a good, _stable_, absolute measure of
security strength.

> This working group will review SASL related submissions as well, including any
> new SASL mechanisms proposed.

New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close the
WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
with EMU?

Nico
-- 

From jaltman@secure-endpoints.com  Tue May 18 12:29:56 2010
Return-Path: <jaltman@secure-endpoints.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143EF3A699C for <kitten@core3.amsl.com>; Tue, 18 May 2010 12:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.304
X-Spam-Level: 
X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_05=-1.11, 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 AoezH72MhaqF for <kitten@core3.amsl.com>; Tue, 18 May 2010 12:29:55 -0700 (PDT)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 146FA3A69D8 for <kitten@ietf.org>; Tue, 18 May 2010 12:29:53 -0700 (PDT)
Received: from www.secure-endpoints.com (cpe-24-193-47-88.nyc.res.rr.com [24.193.47.88]) (user=jea31 mech=LOGIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4IJTiNN029854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <kitten@ietf.org>; Tue, 18 May 2010 15:29:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1274210938; x=1274815738; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=11AtvTbAEA1kGGg8FW S2SdkgER6o4xHg+hGdOP8dju4=; b=ICGqyP0XY/M1ZSxhhbsBe9VbMqXlg8n2f8 sctWWP1kg7Ax1heN8Y7jGrDx6YVlTxhZBOcxgX8CzvWYxKyexpXiQA3bhkmDigwp BBjO3u05m7gmEMwbV6TGDIOiP1e2HIHnMYwt2tBFN/UlJVyu0PY1hPPZ3SlYnHu1 z1eAfhS1s=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=OnRzITKA/bJvcTWrAi2aVtFarLXcwRPEuslnaadmNdcub4dLvPbvHwWiPB1/ 1jxMOOd4W/65zzahzL4jiSgLzaT8zSI8B1DnhvYoqpTzSsJ/5+qwpj+h1 hAlCHmcafsrxUvSXnKHc+rHuOn0TMuINMsA8crKSKVVQYeKxOLutk8=;
X-MDAV-Processed: www.secure-endpoints.com, Tue, 18 May 2010 15:28:58 -0400
Received: from [192.168.1.17] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v11.0.1) with ESMTP id md50000239362.msg for <kitten@ietf.org>; Tue, 18 May 2010 15:28:57 -0400
X-Spam-Processed: www.secure-endpoints.com, Tue, 18 May 2010 15:28:57 -0400 (not processed: message from trusted or authenticated source)
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kitten@ietf.org
Message-ID: <4BF2EAA2.2000600@secure-endpoints.com>
Date: Tue, 18 May 2010 15:29:38 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4
MIME-Version: 1.0
To: kitten@ietf.org
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com>
In-Reply-To: <20100518191521.GL9429@oracle.com>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://pgp.mit.edu
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030104060408020208060302"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: jaltman@secure-endpoints.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 19:29:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms030104060408020208060302
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/18/2010 3:15 PM, Nicolas Williams wrote:
> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
>> As discussed; attached is the proposed charter text for a new
>> working group (MOGGIES) based on future direction in the GSS-API and
>> SASL space.  Please provide any feed-back to the lists by the end of
>> May.
>=20
> I don't love the name (I keep thinking "MOOGIES", which sounds like
> something gross :), but I'll live; I have no better suggestions.

I think the charter is fine but I too object to the name.
Kitten was funny because the predecessor has the acronym of CAT.
I don't think MOGGIES is funny. Perhaps if you figured out how to
turn it into DOGGIES or PUPPIES.

I would much prefer a working group name that had an easy to understand
meaning at first glance.

Jeffrey Altman


--------------ms030104060408020208060302
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX
DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6
y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL
kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE
jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp
Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK
ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z
cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF
9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/
QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6
m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4
Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/
bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S
VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd
wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2
Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID
bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1MTgxOTI5MzhaMCMGCSqGSIb3DQEJBDEWBBQKapt+
aWzZQM5z9zZNsGuIXw65PTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs
9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBACCQaxZ9GuvMQ/+kzUZ57Sl0BoL+JnF1ic0k
xnu4rd1HXETAAeVW4WP9Ta2QqU7k9BcoZp+cGbqpiTJcLgbqodx+KgDSYx/YTPiWEMX7l3yC
FACQORdCpMO+M/s2u4Eqtk82WEgPaqm7jQXd+44u9ObuC2CQBOGNBRpftywsnn8fcD970Eg+
sXJIXkUhgwm11La83Vn/FaogndDiiH8y4UzqOXaTw6TUoZIWBLGcolzxjnwKTEXRz6FhxJ3/
TP3zf/H9WQyL5Jk43D4rGExrwvzD6Cx4ju4FcfXWl3ggQDDyKgCIL8KpiC8wy3/IplqXgI46
Z1WckzWgW6+IWLhA2qAAAAAAAAA=
--------------ms030104060408020208060302--


From Nicolas.Williams@oracle.com  Tue May 18 12:48:13 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4703A6ADE for <kitten@core3.amsl.com>; Tue, 18 May 2010 12:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.095
X-Spam-Level: 
X-Spam-Status: No, score=-4.095 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFdtpmyDE90O for <kitten@core3.amsl.com>; Tue, 18 May 2010 12:48:12 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 882053A6AB4 for <kitten@ietf.org>; Tue, 18 May 2010 12:48:12 -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.1) with ESMTP id o4IJm2cI028871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 19:48:04 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4IJjLrb014108; Tue, 18 May 2010 19:48:02 GMT
Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 277663751274212042; Tue, 18 May 2010 12:47:22 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 12:47:22 -0700
Date: Tue, 18 May 2010 14:47:17 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Jeffrey Altman <jaltman@secure-endpoints.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <20100518194717.GN9429@oracle.com>
References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com> <4BF2EAA2.2000600@secure-endpoints.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BF2EAA2.2000600@secure-endpoints.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090205.4BF2EEF4.014C:SCFMA922111,ss=1,fgs=0
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 19:48:13 -0000

On Tue, May 18, 2010 at 03:29:38PM -0400, Jeffrey Altman wrote:
> On 5/18/2010 3:15 PM, Nicolas Williams wrote:
> > On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
> >> As discussed; attached is the proposed charter text for a new
> >> working group (MOGGIES) based on future direction in the GSS-API and
> >> SASL space.  Please provide any feed-back to the lists by the end of
> >> May.
> > 
> > I don't love the name (I keep thinking "MOOGIES", which sounds like
> > something gross :), but I'll live; I have no better suggestions.
> 
> I think the charter is fine but I too object to the name.
> Kitten was funny because the predecessor has the acronym of CAT.
> I don't think MOGGIES is funny. Perhaps if you figured out how to
> turn it into DOGGIES or PUPPIES.

KITTEN wasn't an acronym...

A completely uncreative acronym:

 - SAGSS (Simple Authentication and GSS)

Slightly more creative acronym:

 - 2PALS (Two Peer Application Layer Security)

   (This one is kinda neat, if I do say so myself, though it could be
   seen to conflict with TLS.)

Funny WG names in the KITTEN tradition:

 - GASSS (Generic And Simple Security Services)

 - SASSY (not an acronym)

 - anything like TIGER, LION, ... (KITTEN, "growed up")

 - HELLO [KITTy]

I like a fair number (four) of the above, and not just 'cause I came up
with them :)

Nico
-- 

From jhutz@cmu.edu  Tue May 18 14:09:28 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063A13A6ACE; Tue, 18 May 2010 14:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.931
X-Spam-Level: 
X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_40=-0.185, 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 QUiSEebDfNKm; Tue, 18 May 2010 14:09:27 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 0E8363A6AD1; Tue, 18 May 2010 14:09:26 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IL9Hcc001108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 17:09:17 -0400 (EDT)
Date: Tue, 18 May 2010 17:09:17 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>, Shawn Emery <shawn.emery@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu>
In-Reply-To: <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com>
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.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.198
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 21:09:28 -0000

--On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams 
<Nicolas.Williams@oracle.com> wrote:

> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
>> As discussed; attached is the proposed charter text for a new
>> working group (MOGGIES) based on future direction in the GSS-API and
>> SASL space.  Please provide any feed-back to the lists by the end of
>> May.
>
> I don't love the name (I keep thinking "MOOGIES", which sounds like
> something gross :), but I'll live; I have no better suggestions.

I don't even _understand_ the name.  Or the expansion.
Can't we have something that doesn't make me (and anyone not already 
familiar with what we're working on) go "Huh?" ?



>> This working group will review SASL related submissions as well,
>> including any new SASL mechanisms proposed.
>
> New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close the
> WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
> with EMU?

This WG should review proposals for new SASL and GSS-API mechanisms, and 
such work should be considered to fall within its general scope, but it 
should be constrained to actually work only on mechanisms specifically 
listed in the charter.  If we want to work on a new mechanism, we can amend 
the charter.

It should also be willing to provide advice and review on non-mechanism 
proposals such as defining use of SASL or GSS-API in a new or existing 
protocol.  However, actual work on such proposals should be done in the 
relevant WG for the protocol in question, and _not_ in the new one.

-- Jeff

From Nicolas.Williams@oracle.com  Tue May 18 14:39:13 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65443A6A71; Tue, 18 May 2010 14:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.394
X-Spam-Level: 
X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=1.204,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irZWgmOjDU49; Tue, 18 May 2010 14:39:12 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CF03B3A68FC; Tue, 18 May 2010 14:39:12 -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.1) with ESMTP id o4ILd0nD011485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 21:39:01 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 o4IJStsQ032403; Tue, 18 May 2010 21:38:59 GMT
Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 278280271274218726; Tue, 18 May 2010 14:38:46 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 14:38:45 -0700
Date: Tue, 18 May 2010 16:38:40 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <20100518213840.GO9429@oracle.com>
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090203.4BF308F7.002B:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org, Tim Polk <tim.polk@nist.gov>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 21:39:13 -0000

On Tue, May 18, 2010 at 05:09:17PM -0400, Jeffrey Hutzelman wrote:
> >New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close the
> >WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
> >with EMU?
> 
> This WG should review proposals for new SASL and GSS-API mechanisms,
> and such work should be considered to fall within its general scope,
> but it should be constrained to actually work only on mechanisms
> specifically listed in the charter.  If we want to work on a new
> mechanism, we can amend the charter.

OK, which mechanisms, if any should the WG work on?

We have SCRAM, we have GS2, we have RFC4121, and KRB-WG will work on
IAKERB.  That leaves only PKU2U, and that'd be up to Larry.

> It should also be willing to provide advice and review on
> non-mechanism proposals such as defining use of SASL or GSS-API in a
> new or existing protocol.  However, actual work on such proposals
> should be done in the relevant WG for the protocol in question, and
> _not_ in the new one.

Indeed.

From jhutz@cmu.edu  Tue May 18 15:36:54 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B58D3A6877; Tue, 18 May 2010 15:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.112
X-Spam-Level: 
X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.487,  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 ZVFvkYetTtEm; Tue, 18 May 2010 15:36:53 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id ADD6C3A685F; Tue, 18 May 2010 15:36:53 -0700 (PDT)
Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IMag5p011570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 18:36:44 -0400 (EDT)
Date: Tue, 18 May 2010 18:36:42 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <184AE5042EA2EBECF7E0D5EE@atlantis.pc.cs.cmu.edu>
In-Reply-To: <20100518213840.GO9429@oracle.com>
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <20100518213840.GO9429@oracle.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.196
Cc: kitten@ietf.org, jhutz@cmu.edu, sasl@ietf.org, Tim Polk <tim.polk@nist.gov>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 22:36:54 -0000

--On Tuesday, May 18, 2010 04:38:40 PM -0500 Nicolas Williams 
<Nicolas.Williams@oracle.com> wrote:

> On Tue, May 18, 2010 at 05:09:17PM -0400, Jeffrey Hutzelman wrote:
>> > New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close
>> > the WG (and even SASL) to new non-GS2 mechanisms?  Might there be
>> > conflicts with EMU?
>>
>> This WG should review proposals for new SASL and GSS-API mechanisms,
>> and such work should be considered to fall within its general scope,
>> but it should be constrained to actually work only on mechanisms
>> specifically listed in the charter.  If we want to work on a new
>> mechanism, we can amend the charter.
>
> OK, which mechanisms, if any should the WG work on?

The ones already in the proposed charter.


From simon@josefsson.org  Tue May 18 23:32:04 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0B73A689E; Tue, 18 May 2010 23:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089,  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 W4CKyKgjLtqr; Tue, 18 May 2010 23:32:03 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4F8493A6964; Tue, 18 May 2010 23:32:01 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4J6VhOm004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 May 2010 08:31:45 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100519:shawn.emery@oracle.com::3xEXT8jMoqgLCumM:0h2T
X-Hashcash: 1:22:100519:jhutz@cmu.edu::gqW11CC0sR6l45q+:7DJ8
X-Hashcash: 1:22:100519:tim.polk@nist.gov::+QEdwUwVmg0Mmmlc:B41r
X-Hashcash: 1:22:100519:kitten@ietf.org::WQmcHT2vBuGQayYg:EE/9
X-Hashcash: 1:22:100519:sasl@ietf.org::gJs7aqmsn8rZ0LGa:Efmm
X-Hashcash: 1:22:100519:nicolas.williams@oracle.com::dwhTi0/5QfrMwQLQ:S9yO
Date: Wed, 19 May 2010 08:31:43 +0200
In-Reply-To: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 18 May 2010 17:09:17 -0400")
Message-ID: <878w7gv1v4.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 06:32:04 -0000

Jeffrey Hutzelman <jhutz@cmu.edu> writes:

> --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams
> <Nicolas.Williams@oracle.com> wrote:
>
>> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
>>> As discussed; attached is the proposed charter text for a new
>>> working group (MOGGIES) based on future direction in the GSS-API and
>>> SASL space.  Please provide any feed-back to the lists by the end of
>>> May.
>>
>> I don't love the name (I keep thinking "MOOGIES", which sounds like
>> something gross :), but I'll live; I have no better suggestions.
>
> I don't even _understand_ the name.  Or the expansion.
> Can't we have something that doesn't make me (and anyone not already
> familiar with what we're working on) go "Huh?" ?

+1

I would prefer something self-explanatory, like SASLGSS.

/Simon

From abartlet@samba.org  Wed May 19 01:26:20 2010
Return-Path: <abartlet@samba.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D9A3A6C69; Wed, 19 May 2010 01:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 Y5dqZm7BUdMk; Wed, 19 May 2010 01:26:19 -0700 (PDT)
Received: from lists.samba.org (fn.samba.org [216.83.154.106]) by core3.amsl.com (Postfix) with ESMTP id 78EC33A6BC8; Wed, 19 May 2010 01:21:13 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 6D035AD237; Wed, 19 May 2010 02:21:07 -0600 (MDT)
Subject: Re: MOGGIES Proposed Charter
From: Andrew Bartlett <abartlet@samba.org>
To: Simon Josefsson <simon@josefsson.org>
In-Reply-To: <878w7gv1v4.fsf@mocca.josefsson.org>
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <878w7gv1v4.fsf@mocca.josefsson.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3leGN7Mk8uM3f7tTUtn0"
Date: Wed, 19 May 2010 16:42:03 +1000
Message-ID: <1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.1.2 (2.30.1.2-2.fc13) 
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org, Jeffrey Hutzelman <jhutz@cmu.edu>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 08:26:20 -0000

--=-3leGN7Mk8uM3f7tTUtn0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2010-05-19 at 08:31 +0200, Simon Josefsson wrote:
> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
>=20
> > --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams
> > <Nicolas.Williams@oracle.com> wrote:
> >
> >> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
> >>> As discussed; attached is the proposed charter text for a new
> >>> working group (MOGGIES) based on future direction in the GSS-API and
> >>> SASL space.  Please provide any feed-back to the lists by the end of
> >>> May.
> >>
> >> I don't love the name (I keep thinking "MOOGIES", which sounds like
> >> something gross :), but I'll live; I have no better suggestions.
> >
> > I don't even _understand_ the name.  Or the expansion.
> > Can't we have something that doesn't make me (and anyone not already
> > familiar with what we're working on) go "Huh?" ?
>=20
> +1
>=20
> I would prefer something self-explanatory, like SASLGSS.

Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun. =20

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-3leGN7Mk8uM3f7tTUtn0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iD8DBQBL84g6z4A8Wyi0NrsRAkXuAKCf1zbWv6/ZXqIw6UhmXGjBRBNjwACfdBpg
sVXZ1l0iU4ys/Z9A5SEr3GU=
=LJhW
-----END PGP SIGNATURE-----

--=-3leGN7Mk8uM3f7tTUtn0--


From alexey.melnikov@isode.com  Wed May 19 02:01:24 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480EE3A687C; Wed, 19 May 2010 02:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.21
X-Spam-Level: 
X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389,  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 D8rWJ0CNvxo2; Wed, 19 May 2010 02:01:23 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BB1A53A6829; Wed, 19 May 2010 02:01:20 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S=Oo2ABeGUuh@rufus.isode.com>; Wed, 19 May 2010 10:01:12 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4BF3A8D5.8070905@isode.com>
Date: Wed, 19 May 2010 10:01:09 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <jhutz@cmu.edu>
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu>
In-Reply-To: <0653C22222CBEBDD0AD1CCFA@minbar.fac.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, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 09:01:24 -0000

Jeffrey Hutzelman wrote:

> --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams 
> <Nicolas.Williams@oracle.com> wrote:
>
>> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
>
 [...]

>>> This working group will review SASL related submissions as well,
>>> including any new SASL mechanisms proposed.
>>
>> New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close the
>> WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
>> with EMU?
>
> This WG should review proposals for new SASL and GSS-API mechanisms, 
> and such work should be considered to fall within its general scope, 
> but it should be constrained to actually work only on mechanisms 
> specifically listed in the charter.  If we want to work on a new 
> mechanism, we can amend the charter.

+1.

> It should also be willing to provide advice and review on 
> non-mechanism proposals such as defining use of SASL or GSS-API in a 
> new or existing protocol.  However, actual work on such proposals 
> should be done in the relevant WG for the protocol in question, and 
> _not_ in the new one.

I think I was quite clear on this in my reply, but in case I wasn't: +1.



From alexey.melnikov@isode.com  Wed May 19 02:37:12 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2476E3A6C1E; Wed, 19 May 2010 02:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Level: 
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386,  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 MIT1AU2bUKsT; Wed, 19 May 2010 02:37:11 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C646D28C13F; Wed, 19 May 2010 02:31:37 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S=Ov8QBeGUyC@rufus.isode.com>; Wed, 19 May 2010 10:31:29 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4BF3AFEC.3030206@isode.com>
Date: Wed, 19 May 2010 10:31:24 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com>
In-Reply-To: <20100518191521.GL9429@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, Tim Polk <tim.polk@nist.gov>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 09:37:12 -0000

Nicolas Williams wrote:

>On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
>  
>
 [...]

>>This working group will review SASL related submissions as well, including any
>>new SASL mechanisms proposed.
>>    
>>
>New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close the
>WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
>with EMU?
>  
>
I don't think there is immediate overlap with EMU, although I think this 
needs a bit more investigation.


From jhutz@cmu.edu  Wed May 19 10:49:18 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B053A6C32; Wed, 19 May 2010 10:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.128
X-Spam-Level: 
X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.471,  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 7HVeFGzU8Bge; Wed, 19 May 2010 10:49:17 -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 308DB3A6BDE; Wed, 19 May 2010 10:49:17 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4JHn6Ux004918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 13:49:07 -0400 (EDT)
Date: Wed, 19 May 2010 13:49:06 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Andrew Bartlett <abartlet@samba.org>, Simon Josefsson <simon@josefsson.org>
Subject: Re: MOGGIES Proposed Charter
Message-ID: <581E1885DAD3191FAA4B0B8C@minbar.fac.cs.cmu.edu>
In-Reply-To: <8205_1274257577_o4J8QGwT009700_1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net>
References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <878w7gv1v4.fsf@mocca.josefsson.org> <8205_1274257577_o4J8QGwT009700_1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net>
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, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 17:49:18 -0000

--On Wednesday, May 19, 2010 04:42:03 PM +1000 Andrew Bartlett 
<abartlet@samba.org> wrote:

>> I would prefer something self-explanatory, like SASLGSS.
>
> Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun.

Again, huh?

From alper.yegin@yegin.org  Thu May 20 07:21:02 2010
Return-Path: <alper.yegin@yegin.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCC13A6C1F; Thu, 20 May 2010 07:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.841
X-Spam-Level: **
X-Spam-Status: No, score=2.841 tagged_above=-999 required=5 tests=[AWL=1.391,  BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449]
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 4ERZqeqb0nKo; Thu, 20 May 2010 07:21:01 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 089CB3A6D1E; Thu, 20 May 2010 07:18:30 -0700 (PDT)
Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0McV0i-1NxRCR26oS-00ILjz; Thu, 20 May 2010 10:18:22 -0400
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>, <saag@mit.edu>
References: <tslbpciqojd.fsf@mit.edu>
In-Reply-To: <tslbpciqojd.fsf@mit.edu>
Subject: RE: [Emu] Summary of Federated Authentication BOF at IETF 77
Date: Thu, 20 May 2010 17:18:03 +0300
Message-ID: <005901caf827$47550e50$d5ff2af0$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-language: en-us
Thread-index: AcrzmpQtoe7feQCCSLaIZxkt3D10hAEieX7w
X-Provags-ID: V01U2FsdGVkX1/mPFLphe2SPqjXDe021MnJkKkCUHZ4nAOUMrP hcVHFt1DfioBapz3SkNWtYt3RKfmiyWn3ctaColu6AsYd3FSTY 6mwrQ9uPvVE9jy5zfh44BntHk+wCvXY
X-Mailman-Approved-At: Thu, 20 May 2010 09:15:19 -0700
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2010 14:21:03 -0000

Hello,

I have a comment about use of EAP in this context.

Folks might remember the ICOS BoF held during IETF 62. Discussions at that
meeting, around that era, and since then have been always pointing to the
applicability statement of EAP and more-or-less blocking the use of EAP for
anything other than network access.

EAP RFC 3748:

   EAP was designed for use in network access authentication, where IP
   layer connectivity may not be available.  Use of EAP for other
   purposes, such as bulk data transport, is NOT RECOMMENDED.

See the meeting notes at http://www.ietf.org/proceedings/62/icos.html,
especially Sam's (SEC AD at that time):

	Sam: Although having a lot of EAP methods is complicated, deploying
new credentials 
	is also hard. I think the uses of EAP that were discussed here are
close enough to 
	network access that I could see the connection. But when EAP was
expaned from PPP 
	to other uses, a lot of new work was required; if we expand EAP to
services in general, 
	we need at least the same amount of work. We might want to check
that there are 
	no better solutions. So if you're using EAP for something totally
else than 
	network access authentication, please talk to me earlier rather than
later.


I'm not against using EAP for arbitrary applications. If this is where we
are getting at in IETF, I'm hoping this gets proper consideration bridging
where we were 5 years ago and today. 

Was this discussed? Is there a proposal to expand the applicability
statement of EAP now? Where do we draw the new line now?

Thanks in advance.

Alper


 





> -----Original Message-----
> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of
> Sam Hartman
> Sent: Friday, May 14, 2010 10:20 PM
> To: saag@mit.edu
> Cc: kitten@ietf.org; moonshot-community@jiscmail.ac.uk; emu@ietf.org
> Subject: [Emu] Summary of Federated Authentication BOF at IETF 77
> 
> 
> 
> I'm told there were around 30 people in the room.  That seemed like a
> good turn out for Thursday at 9 PM.
> 
> Many of the participants had already read some or all of the proposed
> documents.
> I presented a problem statement based on providing federated
> authentication  for non-web applications.
> Two solutions were presented.  I presented work on Moonshot, a
> technology that combines EAP, GSS-API, RADIUS and SAML to solve the
> problem.  Eliot Lear and Klaas Wierenga presented a simpler solution
> that uses browser-based SAML and Open ID.
> 
> The sense of the room was that these solutions compliment each other.
> Moonshot requires more infrastructure and client configuration but
> provides several advantages.  The browser-based solutions are something
> that requires fewer client changes.
> 
> Volunteers were collected from the EAP, GSS and RADIUS communities who
> would be interested in working on these problems.  Some of the work
> discussed, possibly especially including the Open ID and SAML
> browser-based solutions may be able to progress in kitten.  I and I
> believe several of the other Moonshot proponents would prefer to focus
> the Moonshot work in one working group.  Other solutions could also be
> progressed in that group, although we should be careful not to slow
> down
> work that could progress quickly in kitten by moving it into an
> as-yet-unchartered group.
> 
> There seemed to be strong support for going forward.  However, several
> things to address in a BOF were raised with regard to the Moonshot
> work.
> 
> * Steve Bellovin pointed out that we need to be very aware of the
>   operational impact and how this fits with the operational model of
> the
>   technologies that are used/extended.
> 
> * Klaas pointed out that Moonshot involves changes to a lot of
> different
>   components.  We need to make sure that there are incremental
>   advantages to each of these changes so they will be deployed: a
> system
>   where there is no benefit until the end when all the peaces fall
>   together is much harder to deploy.
> 
> * Klaas pointed out that we need to consider  the operational security
>   around how RADIUS federations are deployed.  If network access is not
>   considered sensitive today, people may be more lax in the security
>   surrounding their RADIUS infrastructure.  If we use that
>   infrastructure to secure more sensitive resources we need to have
>   practices that tighten up the security of the infrastructure
>   sufficiently.
> 
> * Someone brought up that this is another one of those authentication
>   proposals where user-interface is critical.  While we should not lay
>   out dialogues in the IETF, we're going to need to describe the
>   usability aspects of this enough to increase the probability of a
> good
>   security solution.
> 
> People specifically asked to look at the following:
> * Complexity
> * What can't be handled with simpler solutions
> * Is Moonshot broad enough in scope?
> * The UI questions
> 
> Since the bar BOF, there has been a lot of traffic on the list and work
> continues.
> We're definitely going to put together a BOF request for IETF 78.
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



From mrex@sap.com  Thu May 20 15:39:05 2010
Return-Path: <mrex@sap.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE503A696C; Thu, 20 May 2010 15:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.75
X-Spam-Level: 
X-Spam-Status: No, score=-7.75 tagged_above=-999 required=5 tests=[AWL=-0.101,  BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l85ChN1nN8Zd; Thu, 20 May 2010 15:39:04 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 66BF83A6A20; Thu, 20 May 2010 15:38:31 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4KMcNZZ025561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 00:38:23 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp>
Subject: Re: [sasl] MOGGIES Proposed Charter
To: Nicolas.Williams@oracle.com (Nicolas Williams)
Date: Fri, 21 May 2010 00:38:22 +0200 (MEST)
In-Reply-To: <20100518191521.GL9429@oracle.com> from "Nicolas Williams" at May 18, 10 02:15:22 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: kitten@ietf.org, sasl@ietf.org, tim.polk@nist.gov
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2010 22:39:05 -0000

Nicolas Williams wrote:
> 
> 
> > * Specify an interface for reporting the security strength of
> >   GSS-API mechanism.
> 
> I'd word that differently:
> 
>  * Specify an interface for enforcing security strength of GSS-API mechanisms.
> 
> The reason is that "reporting the security strength" of something
> implies [to me] an absolute measure of security strength, and I don't
> think it's possible to design a good, _stable_, absolute measure of
> security strength.


I think that the comparable strength measured in "Bits of security"
as used by NIST SP800-57 section 5.6.1 should be sufficiently stable.

What changes over time is the amount of "strength" that one considers
secure.  

      fairly stable           gradually fading
        Bits of           characterisation of strength
        security                 
          <40                 ridiculously weak
          40                  extremely weak
          56                  very weak
          64                  weak
          80                  mediocre
          96                  fair
          112                 good
          128                 strong
         >128                 very strong


-Martin

From Nicolas.Williams@oracle.com  Thu May 20 15:57:37 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9D83A6885; Thu, 20 May 2010 15:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.134
X-Spam-Level: 
X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYnWYJUb18ZU; Thu, 20 May 2010 15:57:36 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 521253A6875; Thu, 20 May 2010 15:57:36 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KMvQL6018957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 May 2010 22:57:28 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KJg4Bv026693; Thu, 20 May 2010 22:57:26 GMT
Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 255656301274396214; Thu, 20 May 2010 15:56:54 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 15:56:54 -0700
Date: Thu, 20 May 2010 17:56:47 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Martin Rex <mrex@sap.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <20100520225647.GX9605@oracle.com>
References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet13.oracle.com [148.87.113.125]
X-CT-RefId: str=0001.0A090208.4BF5BE58.0224:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org, tim.polk@nist.gov
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2010 22:57:37 -0000

On Fri, May 21, 2010 at 12:38:22AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > I'd word that differently:
> > 
> >  * Specify an interface for enforcing security strength of GSS-API mechanisms.
> > 
> > The reason is that "reporting the security strength" of something
> > implies [to me] an absolute measure of security strength, and I don't
> > think it's possible to design a good, _stable_, absolute measure of
> > security strength.
> 
> I think that the comparable strength measured in "Bits of security"
> as used by NIST SP800-57 section 5.6.1 should be sufficiently stable.

I don't.  I'd much rather be able to ask for a credential or context
that meets a given security profile, or to check what profiles a given
credential or context meets.  The profiles should be named

Possible profile names and semantics:

 - FIPS-140-x        -> obvious semantics (FIPS-140-x compliant cipher suites)
 - <other standards> -> obvious semantics
 - Strong            -> obvious-but-local semantics
 - Fast              -> obvious-but-local semantics
 - Interoperable     -> standard, per-mechanism semantics
 - Weak              -> standard, per-mechanism semantics (basically:
                        interoperable cipher suites + obsolete suites)

 - Local-*           -> locally-defined profile names and semantics

> What changes over time is the amount of "strength" that one considers
> secure.  

Not only.  Cryptanalysis progresses and the relative strengths of
various algorithms can vary.

I abhor anything remotely like a quantification of cryptographic
strength, and will for the forseeable future.

Nico
-- 

From mrex@sap.com  Fri May 21 14:54:38 2010
Return-Path: <mrex@sap.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758E33A67F6; Fri, 21 May 2010 14:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.747
X-Spam-Level: 
X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHaHPqip-3Ib; Fri, 21 May 2010 14:54:37 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 656C73A659A; Fri, 21 May 2010 14:54:33 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o4LKBDNQ020669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 22:11:13 +0200 (MEST)
Received: from fs4113.wdf.sap.corp (fs4113.wdf.sap.corp [10.21.76.84]) by mail.sap.corp (mail03-25) with ESMTP id o4LKBCuA006580 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 21 May 2010 22:11:13 +0200 (MEST)
Received: (from d019080@localhost) by fs4113.wdf.sap.corp (8.13.4+Sun/8.13.4/Submit) id o4LKBBFk012803; Fri, 21 May 2010 22:11:11 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005212011.o4LKBBFk012803@fs4113.wdf.sap.corp>
Subject: Re: MOGGIES Proposed Charter<
To: simon@josefsson.org (Simon Josefsson)
Date: Fri, 21 May 2010 22:11:11 +0200 (MEST)
In-Reply-To: <878w7gv1v4.fsf@mocca.josefsson.org> from "Simon Josefsson" at May 19, 10 08:31:43 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2010 21:54:38 -0000

Simon Josefsson wrote:
> 
> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> >
> > <Nicolas.Williams@oracle.com> wrote:
> > >   [..."MOGGIES"...]
> > >
> > > I don't love the name (I keep thinking "MOOGIES", which sounds like
> > > something gross :), but I'll live; I have no better suggestions.
> >
> > I don't even _understand_ the name.  Or the expansion.
> > Can't we have something that doesn't make me (and anyone not already
> > familiar with what we're working on) go "Huh?" ?

I had to look up the term MOGGIES in a dictionary.

The meaning of the expansion appears a little weird/non-intuitive to me.

> 
> I would prefer something self-explanatory, like SASLGSS.

Do we need to rename Kitten at all?

How about "KittenS" ?

-Martin

From tlyu@mit.edu  Fri May 21 15:43:46 2010
Return-Path: <tlyu@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1F23A6A59; Fri, 21 May 2010 15:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.867
X-Spam-Level: 
X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_50=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 NpDtg10-ILUk; Fri, 21 May 2010 15:43:45 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 02C1E3A6942; Fri, 21 May 2010 15:43:44 -0700 (PDT)
X-AuditID: 12074424-b7b9dae000002832-1e-4bf70c9af6bc
Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 65.0A.10290.A9C07FB4; Fri, 21 May 2010 18:43:38 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o4LMhblE031336;  Fri, 21 May 2010 18:43:37 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4LMhZgV020165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 May 2010 18:43:36 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4LMhZ5Q004255; Fri, 21 May 2010 18:43:35 -0400 (EDT)
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 21 May 2010 18:43:35 -0400
In-Reply-To: <20100520225647.GX9605@oracle.com> (Nicolas Williams's message of "Thu, 20 May 2010 17:56:47 -0500")
Message-ID: <ldvy6fc3mg8.fsf@cathode-dark-space.mit.edu>
Lines: 31
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: AAAAAA==
Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2010 22:43:46 -0000

Nicolas Williams <Nicolas.Williams@oracle.com> writes:

> On Fri, May 21, 2010 at 12:38:22AM +0200, Martin Rex wrote:
>
>> What changes over time is the amount of "strength" that one considers
>> secure.  
>
> Not only.  Cryptanalysis progresses and the relative strengths of
> various algorithms can vary.
>
> I abhor anything remotely like a quantification of cryptographic
> strength, and will for the forseeable future.

The meaning of "security strength" can be made fairly precise by
definitions involving, for example, the base 2 logarithm of the time
or space complexity of attacking an algorithm, e.g., NIST SP 800-57,
Part 1, Section 5.6.1.  That text gives the example of three-key
triple DES, which has 168 bits of key material and has 112 bits of
effective security strength.

Yes, this means that you may have to revise the numeric "security
strength" that you report for a given cryptographic association as new
cryptanalytic attacks are discovered, but you would have to do that
anyway with a non-numeric method of reporting "security strength".

As I understand it, defeating an algorithm with a security strength of
128 bits approaches or exceeds reasonable information-theoretic bounds
on the computational capacity of the universe, unless you consider
quantum computing to be a credible threat.  I expect that the amount
of "strength" that we consider secure is unlikely to change unless
tremendous advances occur in the realm of quantum computing.

From Nicolas.Williams@oracle.com  Fri May 21 16:11:07 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0F13A6A99; Fri, 21 May 2010 16:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.133
X-Spam-Level: 
X-Spam-Status: No, score=-4.133 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZYosepT0Q2B; Fri, 21 May 2010 16:11:05 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 41D883A6A95; Fri, 21 May 2010 16:11:05 -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.1) with ESMTP id o4LNAtqU011778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 23:10:57 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LMbYaK022976; Fri, 21 May 2010 23:10:55 GMT
Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 289445551274483346; Fri, 21 May 2010 16:09:06 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 16:09:05 -0700
Date: Fri, 21 May 2010 18:09:00 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Tom Yu <tlyu@mit.edu>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <20100521230900.GF9605@oracle.com>
References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> <ldvy6fc3mg8.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ldvy6fc3mg8.fsf@cathode-dark-space.mit.edu>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090201.4BF71302.002B:SCFMA922111,ss=1,fgs=0
Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2010 23:11:07 -0000

On Fri, May 21, 2010 at 06:43:35PM -0400, Tom Yu wrote:
> Yes, this means that you may have to revise the numeric "security
> strength" that you report for a given cryptographic association as new
> cryptanalytic attacks are discovered, but you would have to do that
> anyway with a non-numeric method of reporting "security strength".

Yes, but that way we get to also have policy names, both, standard and
locally-defined, as the interface _for users_.

Let me refine my problem with numeric measures of cryptographic strength
in APIs.  There are two.  First, what's better in a UI (I'm betting API
particulars will leak into UIs)?  Second, do we want to encourage users
and/or developers to make relative cipher suite strength comparisons?

Looking at it from a UI perspective I'd rather have UI-friendly security
strength indications than numeric ones.  One might argue that numeric
measures of strength are what users are used to, and there's no sense in
trying to change that.  Is anyone up for that argument?

Nico
-- 

From arnt@gulbrandsen.priv.no  Sat May 22 02:22:37 2010
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADD23A6C4C; Sat, 22 May 2010 02:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.28
X-Spam-Level: 
X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=-0.281,  BAYES_50=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 ZS8G-MoFB+NK; Sat, 22 May 2010 02:22:35 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by core3.amsl.com (Postfix) with ESMTP id 028923A6C3B; Sat, 22 May 2010 02:22:24 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id E60C1FA0008; Sat, 22 May 2010 09:22:22 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.3) with esmtpa id 1274520135-37716-37715/8/50; Sat, 22 May 2010 11:22:15 +0200
Message-Id: <aTuL5hseOU458FLQG7pXdg.md5@lochnagar.gulbrandsen.priv.no>
Date: Sat, 22 May 2010 11:22:32 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
Organization: http://arnt.gulbrandsen.priv.no
References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> <ldvy6fc3mg8.fsf@cathode-dark-space.mit.edu> <20100521230900.GF9605@oracle.com>
In-Reply-To: <20100521230900.GF9605@oracle.com>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
X-Mailman-Approved-At: Sat, 22 May 2010 18:40:51 -0700
Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 May 2010 09:22:37 -0000

Nicolas Williams writes:
> Let me refine my problem with numeric measures of cryptographic 
> strength in APIs. There are two. First, what's better in a UI (I'm 
> betting API particulars will leak into UIs)?

As (mostly former) UI-head: Numbers are better than magic constants. 
Magic constants have a way of getting into a fight with UI translation.

There are good ways to handle magic constants, but errare humanum est, 
programmers are human, and my impression is that magic constants are 
associated with more UI snafus than numbers.

> Second, do we want to encourage users and/or developers to make 
> relative cipher suite strength comparisons?

Other than "Pick the best?"

Arnt

From Nicolas.Williams@oracle.com  Sun May 23 21:37:26 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C6C3A69A6; Sun, 23 May 2010 21:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.131
X-Spam-Level: 
X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eps+2cel88Ay; Sun, 23 May 2010 21:37:24 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C61BC3A69A3; Sun, 23 May 2010 21:37:24 -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.1) with ESMTP id o4O4bCo2032643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 May 2010 04:37:14 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4O2mtuA000354; Mon, 24 May 2010 04:37:11 GMT
Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 291863271274675820; Sun, 23 May 2010 21:37:00 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 May 2010 21:37:00 -0700
Date: Sun, 23 May 2010 23:36:55 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: Re: [sasl] MOGGIES Proposed Charter
Message-ID: <20100524043655.GI9605@oracle.com>
References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> <ldvy6fc3mg8.fsf@cathode-dark-space.mit.edu> <20100521230900.GF9605@oracle.com> <aTuL5hseOU458FLQG7pXdg.md5@lochnagar.gulbrandsen.priv.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aTuL5hseOU458FLQG7pXdg.md5@lochnagar.gulbrandsen.priv.no>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090201.4BFA027A.0158:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2010 04:37:26 -0000

On Sat, May 22, 2010 at 11:22:32AM +0200, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Let me refine my problem with numeric measures of cryptographic
> >strength in APIs. There are two. First, what's better in a UI (I'm
> >betting API particulars will leak into UIs)?
> 
> As (mostly former) UI-head: Numbers are better than magic constants.
> Magic constants have a way of getting into a fight with UI
> translation.
> 
> There are good ways to handle magic constants, but errare humanum
> est, programmers are human, and my impression is that magic
> constants are associated with more UI snafus than numbers.

These wouldn't be constants though -- that's part of the point.

> >Second, do we want to encourage users and/or developers to make
> >relative cipher suite strength comparisons?
> 
> Other than "Pick the best?"

One could certainly have locally defined preference orders for cipher
suites.  Numeric sorting by "strength number" needn't enter into it.

From Kurt.Zeilenga@Isode.com  Tue May 25 07:58:59 2010
Return-Path: <Kurt.Zeilenga@Isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C943A6B54; Tue, 25 May 2010 07:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.362
X-Spam-Level: 
X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_50=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 VYHC3JU9YU5z; Tue, 25 May 2010 07:58:58 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BA6653A679C; Tue, 25 May 2010 07:58:30 -0700 (PDT)
Received: from [192.168.1.101] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <S=vljABeGZxu@rufus.isode.com>; Tue, 25 May 2010 15:58:21 +0100
X-SMTP-Protocol-Errors: NORDNS
Subject: Re: [sasl] MOGGIES Proposed Charter
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
In-Reply-To: <4BF221C1.2090005@oracle.com>
Date: Tue, 25 May 2010 07:58:18 -0700
Message-Id: <A820F20B-A4C0-4973-8898-DA9004294872@Isode.com>
References: <4BF221C1.2090005@oracle.com>
To: Shawn Emery <shawn.emery@oracle.com>
X-Mailer: Apple Mail (2.1078)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 14:58:59 -0000

I am fine with the charter not specifically stating it will undertake =
revision of RFC 4422.  I see no burning need to undertake this work and =
personally rather wait for SASLprep to be sorted.

On the subject of SASLprep, I rather revision of RFC 4013 be worked in =
NewPrep.  The reason for this is two fold. 1) Expertise: I figure there =
is better chance of getting both SASL (and general security expertise) =
and Unicode/StringPrep expertise in the NewPrep forums than the MOGGIES =
forums.   2) SASLprep is used not only by SASL mechanisms but in various =
other systems, such as LDAP, I prefer a more neutral forum.

On the subject of "interface for reporting the security strength of =
GSS-API:  I note that I once wrote an I-D which kinds of relates to =
this.  =
<http://www.watersprings.org/pub/id/draft-zeilenga-auth-lvl-02.txt>.   =
Beyond that, I think this work item is a rat-hole and rather it not be =
on the charter.  Instead, I suggest folks pursue this on an =
individual/independent basis if they think they can come up with =
something useful here.

-- Kurt=

From hartmans@mit.edu  Tue May 25 13:37:12 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69353A6819 for <kitten@core3.amsl.com>; Tue, 25 May 2010 13:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.335
X-Spam-Level: 
X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgt4o1o8G32r for <kitten@core3.amsl.com>; Tue, 25 May 2010 13:37:12 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CBC433A680A for <kitten@ietf.org>; Tue, 25 May 2010 13:37:08 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F059C20239; Tue, 25 May 2010 16:36:55 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B31243EF; Tue, 25 May 2010 16:36:30 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: kitten@ietf.org,tim.polk@nist.gov
Subject: review of draft-wierenga-ietf-sasl-saml-00
Date: Tue, 25 May 2010 16:36:30 -0400
Message-ID: <tslzkzn67n5.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 20:37:13 -0000

[Tim copied because this document came up on a recent call]

Hi.  I've been promising the authors of the SASL SAML mechanism a review
for a while and I realized that the only way it would happen is if I sit
down and write it up.

For those who haven't read the document, the idea is to permit the use
of an existing SAML IDP for SASL authentication.  The flow is as
follows:

1) The server sends a URI to redirect to to the client.

2) The client pops up a browser and sends it to that URI

3) The client sends an empty response to the server

4) At some later point the server says authentication succeeded or
failed.

What's presumably happening behind the covers is that the client is
interacting with a browser and an identity provider.  Eventually if
authentication is successful the client will be directed back to a URI
on the server.  Once the authentication is received  over this URI  then
the server will respond that SASL has succeeded.

I think this mechanism may be the best approach possible given the
technical constraints, especially in the case where the IDP URI is
provided by the server or where an IDP discovery mechanism is used.

However the security properties of this mechanism are a lot closer to
SASL plain or anonymous than more modern SASL mechanisms such as SCRAM.
It's not as bad as plain: long-term secrets are not sent over the wire
in the clear.  However it seems vulnerable to the following attacks:

1) The client has no assurance provided by this mechanism that it is
talking to the intended server.  So, this mechanism provides no
protection against man-in-the-middle attacks.

2) There is no channel binding or security layer provided.  If this
mechanism is used with TLS, there is no assurance that  the endpoints of
TLS are related to the endpoints of SASL.

3) The client has no to weak assurance that authentication actually
happened.  The server  could return successful authentication at any
point after the client sends the empty response.  We've learned from
discussion of phishing attacks that often it's valuable to force someone
to believe they have authenticated to a site when they have not done
so.  They will be willing to enter confidential information--after all,
they did manage to log in.

4) The fact that the server provides the IDP or IDP discovery URI opens
the system to fairly classic phishing attacks.

Some of these attacks are addressed by using TLS between the client and
server.  That's only true if certificates are validated and if the user
does not accept invalid certificates.  It's also important that the name
in the certificate be properly checked.

A mechanism similar to this could provide significantly better security
guarantees if the client knew its own IDP URI.


1) Channel binding could be provided.  In some portion of the
authentication request covered by the signature, the SASL server
includes the channel binding data for the channel.  The client can
verify that the correct channel binding data is included.  The client
cannot yet tell that there is no man in the middle.

2) The return URI should provide some space for the client to include
some token.  The client includes this token in the return URI as it
passes the authentication request to the browser.  The server echoes
this returned token back to the client in the success message.  Because
the server has never seen this token before it provides some assurance
that the server interacted with the IDP.  Naturally this only provides
value if the IDP is selected by the client rather than the server.

I think that if these two additions can be fleshed out and if there are
significant use cases where clients could know their IDP, then the
mechanism should be modified to support these use cases.

However, as I mentioned, I don't know how to do better than the current
mechanism given the common requirement that the server provide an IDP
discovery URI.  I do understand that requirement is important.  Any
mechanism we publish in this space should have a clear applicability
statement and a good explanation of these attacks in the security
considerations section.

From cantor.2@osu.edu  Tue May 25 13:54:07 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336063A6BB1 for <kitten@core3.amsl.com>; Tue, 25 May 2010 13:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=1]
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 LQKbQggiWr8a for <kitten@core3.amsl.com>; Tue, 25 May 2010 13:54:06 -0700 (PDT)
Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id 6CE473A6D4F for <kitten@ietf.org>; Tue, 25 May 2010 13:46:47 -0700 (PDT)
Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4PKkcI2018996; Tue, 25 May 2010 16:46:38 -0400
Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4PKkbnB018810; Tue, 25 May 2010 16:46:38 -0400
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>, <kitten@ietf.org>
References: <tslzkzn67n5.fsf@mit.edu>
In-Reply-To: <tslzkzn67n5.fsf@mit.edu>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Tue, 25 May 2010 16:46:39 -0400
Organization: The Ohio State University
Message-ID: <077001cafc4b$603f0510$20bd0f30$@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: AQLRbl7pt5nj/GkkimyEmmW8RXcC05BVuIAA
Content-Language: en-us
X-CanIt-Geo: ip=128.146.216.86; 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.133
Cc: moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 20:54:07 -0000

> A mechanism similar to this could provide significantly better security
> guarantees if the client knew its own IDP URI.
...
> I think that if these two additions can be fleshed out and if there are
> significant use cases where clients could know their IDP, then the
> mechanism should be modified to support these use cases.

That is in essence the reason I am still planning to propose an alternative
design that makes direct use of the SAML profile that was designed for this
basic scenario of a client that's been modified. It does not impose
significant technical barriers to clients (they don't have to know much
about SAML or create XML Signatures or any of the other common complaints).

I believe the cost of deploying a client is such that it's absolutely
essential to use that change to move discovery to it.

I was hoping to have an I-D submitted by now, but I haven't found the time.
Hopefully fairly soon.

> However, as I mentioned, I don't know how to do better than the current
> mechanism given the common requirement that the server provide an IDP
> discovery URI.  I do understand that requirement is important. 

I haven't seen a compelling argument for why it's important. It's actually
been a problem for federation since its inception, and when you can avoid
it, you really have to.

It's something you can work around in cases in which the application relies
on identifiers that resemble email addresses and can be used to perform an
implicit kind of discovery, but that's not a generalized case, and it still
results in the additional security issues you mentioned.

-- Scott



From hartmans@mit.edu  Tue May 25 17:40:20 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30953A6B2F; Tue, 25 May 2010 17:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.335
X-Spam-Level: 
X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmo09Aw0LFfN; Tue, 25 May 2010 17:40:04 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C44AC3A6C64; Tue, 25 May 2010 16:08:18 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 06D5120239; Tue, 25 May 2010 19:08:06 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 30B9743EF; Tue, 25 May 2010 19:07:40 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: mrex@sap.com
Subject: Re: MOGGIES Proposed Charter<
References: <201005212011.o4LKBBFk012803@fs4113.wdf.sap.corp>
Date: Tue, 25 May 2010 19:07:40 -0400
In-Reply-To: <201005212011.o4LKBBFk012803@fs4113.wdf.sap.corp> (Martin Rex's message of "Fri, 21 May 2010 22:11:11 +0200 (MEST)")
Message-ID: <tslfx1f60n7.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>, jhutz@cmu.edu, sasl@ietf.org, tim.polk@nist.gov
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 00:40:20 -0000

>>>>> "Martin" == Martin Rex <mrex@sap.com> writes:


I join Martin.  I think that closing sasl and rechartering is disruptive
enough.  I don't think it makes sense to change the name of two WGs.  I
definitely don't think that it makes sense to change to a new mailing
list instead of one of the existing mailing lists.  I don't think the
new name or a desire to have a new name is sufficiently compelling to
change the mailing list.

so:

1) I strongly object to the new wg using a mailing list other than
kitten@ietf.org the old SASL list.
2) I don't think it wise for the new WG to have a name that disagrees
with its mailing list.

As a result I fairly strongly believe the WG should be called kitten or
SASL.

From jhutz@cmu.edu  Tue May 25 17:43:46 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD5F3A6AA6; Tue, 25 May 2010 17:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 WOUhH0xetEVn; Tue, 25 May 2010 17:43:45 -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 938B63A6F26; Tue, 25 May 2010 16:43:06 -0700 (PDT)
Received: from 174-146-39-7.pools.spcsdns.net (174-146-39-7.pools.spcsdns.net [174.146.39.7]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4PNgrw0020336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 19:42:55 -0400 (EDT)
X-User-Agent: K-9 Mail for Android
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: MOGGIES Proposed Charter<
From: Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Tue, 25 May 2010 19:42:51 -0400
To: Sam Hartman <hartmans-ietf@mit.edu>, mrex@sap.com
Message-ID: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com>
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: kitten@ietf.org, simon@josefsson.org, sasl@ietf.org, tim.polk@nist.gov
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 00:43:46 -0000

"Sam Hartman" <hartmans-ietf@mit.edu> wrote:

>>>>>> "Martin" == Martin Rex <mrex@sap.com> writes:
>
>
>I join Martin.  I think that closing sasl and rechartering is disruptive
>enough.  I don't think it makes sense to change the name of two WGs.  I
>definitely don't think that it makes sense to change to a new mailing
>list instead of one of the existing mailing lists.  I don't think the
>new name or a desire to have a new name is sufficiently compelling to
>change the mailing list.
>
>so:
>
>1) I strongly object to the new wg using a mailing list other than
>kitten@ietf.org the old SASL list.
>2) I don't think it wise for the new WG to have a name that disagrees
>with its mailing list.
>
>As a result I fairly strongly believe the WG should be called kitten or
>SASL.

I agree; I was wondering why we weren't just rechartering one group to absorb the other.  I suggest having kitten absorb sasl, so we don't end up with a wg acronym that's only one of our protocols.

From Nicolas.Williams@oracle.com  Wed May 26 07:17:18 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7076F3A694F; Wed, 26 May 2010 07:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.948
X-Spam-Level: 
X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64pHAZ4d6OWU; Wed, 26 May 2010 07:17:17 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 62B3F3A6930; Wed, 26 May 2010 07:17:17 -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.1) with ESMTP id o4QEH1xb005162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 May 2010 14:17:03 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4QCObhK024378; Wed, 26 May 2010 14:16:55 GMT
Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 299543411274883398; Wed, 26 May 2010 07:16:38 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 May 2010 07:16:37 -0700
Date: Wed, 26 May 2010 09:16:32 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [sasl] MOGGIES Proposed Charter<
Message-ID: <20100526141632.GW9605@oracle.com>
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090206.4BFD2D61.00FB:SCFMA922111,ss=1,fgs=0
Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 14:17:18 -0000

On Tue, May 25, 2010 at 07:42:51PM -0400, Jeffrey Hutzelman wrote:
> "Sam Hartman" <hartmans-ietf@mit.edu> wrote:
> >1) I strongly object to the new wg using a mailing list other than
> >kitten@ietf.org the old SASL list.
> >2) I don't think it wise for the new WG to have a name that disagrees
> >with its mailing list.
> >
> >As a result I fairly strongly believe the WG should be called kitten
> >or SASL.
> 
> I agree; I was wondering why we weren't just rechartering one group to
> absorb the other.  I suggest having kitten absorb sasl, so we don't
> end up with a wg acronym that's only one of our protocols.

+1

From klaas@cisco.com  Wed May 26 07:17:46 2010
Return-Path: <klaas@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB5C3A683F for <kitten@core3.amsl.com>; Wed, 26 May 2010 07:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 mv3kRYs1Bd3c for <kitten@core3.amsl.com>; Wed, 26 May 2010 07:17:45 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0CB483A6960 for <kitten@ietf.org>; Wed, 26 May 2010 07:17:44 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0BAHbK/EuQ/uCWe2dsb2JhbACeIBUBARYiBhynNpl9glqCOQSPUw
X-IronPort-AV: E=Sophos;i="4.53,304,1272844800";  d="scan'208";a="7829460"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 May 2010 13:38:32 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QEHYeO022725; Wed, 26 May 2010 14:17:35 GMT
Message-ID: <4BFD2D7E.4010204@cisco.com>
Date: Wed, 26 May 2010 16:17:34 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu>
In-Reply-To: <tslzkzn67n5.fsf@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 26 May 2010 07:40:31 -0700
Cc: kitten@ietf.org, tim.polk@nist.gov, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 14:17:46 -0000

Hi Sam,.

Thanks for your review! I agree with most of your observations. To 
address your mitigating measures:

- IdP discovery

I don't think that in the use cases I am thinking of currently (jabber, 
imap etc.) IdP discovery is that important. I can very well live with 
having the client specify the IdP instead of relying on a discovery url 
provided by the server. I wanted to be as flexible as possible, but 
given your and others feedback I can change that. I see 2 options: 
introduce an "IdP hint" provided by the client and fall back to one 
provided by the server and discuss this in the security considerations 
or have the client always provide the IdP. I guess you prefer the 
latter, what do others think?

- token provided by client

Interesting idea. I had been toying with the idea of having the server 
provide a nonce, but that would not have helped. I have to think if/how 
that could be done.

- channel binding

How useful is channel binding if there is still a MITM possible?

Thanks again,

Klaas

> [Tim copied because this document came up on a recent call]
>
> Hi.  I've been promising the authors of the SASL SAML mechanism a review
> for a while and I realized that the only way it would happen is if I sit
> down and write it up.
>
> For those who haven't read the document, the idea is to permit the use
> of an existing SAML IDP for SASL authentication.  The flow is as
> follows:
>
> 1) The server sends a URI to redirect to to the client.
>
> 2) The client pops up a browser and sends it to that URI
>
> 3) The client sends an empty response to the server
>
> 4) At some later point the server says authentication succeeded or
> failed.
>
> What's presumably happening behind the covers is that the client is
> interacting with a browser and an identity provider.  Eventually if
> authentication is successful the client will be directed back to a URI
> on the server.  Once the authentication is received  over this URI  then
> the server will respond that SASL has succeeded.
>
> I think this mechanism may be the best approach possible given the
> technical constraints, especially in the case where the IDP URI is
> provided by the server or where an IDP discovery mechanism is used.
>
> However the security properties of this mechanism are a lot closer to
> SASL plain or anonymous than more modern SASL mechanisms such as SCRAM.
> It's not as bad as plain: long-term secrets are not sent over the wire
> in the clear.  However it seems vulnerable to the following attacks:
>
> 1) The client has no assurance provided by this mechanism that it is
> talking to the intended server.  So, this mechanism provides no
> protection against man-in-the-middle attacks.
>
> 2) There is no channel binding or security layer provided.  If this
> mechanism is used with TLS, there is no assurance that  the endpoints of
> TLS are related to the endpoints of SASL.
>
> 3) The client has no to weak assurance that authentication actually
> happened.  The server  could return successful authentication at any
> point after the client sends the empty response.  We've learned from
> discussion of phishing attacks that often it's valuable to force someone
> to believe they have authenticated to a site when they have not done
> so.  They will be willing to enter confidential information--after all,
> they did manage to log in.
>
> 4) The fact that the server provides the IDP or IDP discovery URI opens
> the system to fairly classic phishing attacks.
>
> Some of these attacks are addressed by using TLS between the client and
> server.  That's only true if certificates are validated and if the user
> does not accept invalid certificates.  It's also important that the name
> in the certificate be properly checked.
>
> A mechanism similar to this could provide significantly better security
> guarantees if the client knew its own IDP URI.
>
>
> 1) Channel binding could be provided.  In some portion of the
> authentication request covered by the signature, the SASL server
> includes the channel binding data for the channel.  The client can
> verify that the correct channel binding data is included.  The client
> cannot yet tell that there is no man in the middle.
>
> 2) The return URI should provide some space for the client to include
> some token.  The client includes this token in the return URI as it
> passes the authentication request to the browser.  The server echoes
> this returned token back to the client in the success message.  Because
> the server has never seen this token before it provides some assurance
> that the server interacted with the IDP.  Naturally this only provides
> value if the IDP is selected by the client rather than the server.
>
> I think that if these two additions can be fleshed out and if there are
> significant use cases where clients could know their IDP, then the
> mechanism should be modified to support these use cases.
>
> However, as I mentioned, I don't know how to do better than the current
> mechanism given the common requirement that the server provide an IDP
> discovery URI.  I do understand that requirement is important.  Any
> mechanism we publish in this space should have a clear applicability
> statement and a good explanation of these attacks in the security
> considerations section.


From klaas@cisco.com  Wed May 26 07:23:35 2010
Return-Path: <klaas@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E70D3A6956 for <kitten@core3.amsl.com>; Wed, 26 May 2010 07:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level: 
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=4.093,  BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSXI66HJF3fm for <kitten@core3.amsl.com>; Wed, 26 May 2010 07:23:20 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5D9063A6930 for <kitten@ietf.org>; Wed, 26 May 2010 07:23:20 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0BADTL/EuQ/uCWe2dsb2JhbACeIBUBARYiBhynLpl/glqCOQSPUw
X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="61825940"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 May 2010 14:23:10 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QENAMj024607; Wed, 26 May 2010 14:23:10 GMT
Message-ID: <4BFD2ECE.5020600@cisco.com>
Date: Wed, 26 May 2010 16:23:10 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Scott Cantor <cantor.2@osu.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu>
In-Reply-To: <077001cafc4b$603f0510$20bd0f30$@osu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 26 May 2010 07:40:31 -0700
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 14:23:35 -0000

On 5/25/10 10:46 PM, Scott Cantor wrote:

Scott,

>> A mechanism similar to this could provide significantly better security
>> guarantees if the client knew its own IDP URI.
> ...
>> I think that if these two additions can be fleshed out and if there are
>> significant use cases where clients could know their IDP, then the
>> mechanism should be modified to support these use cases.
>
> That is in essence the reason I am still planning to propose an alternative
> design that makes direct use of the SAML profile that was designed for this
> basic scenario of a client that's been modified. It does not impose
> significant technical barriers to clients (they don't have to know much
> about SAML or create XML Signatures or any of the other common complaints).

I am assuming you refer to the ECP profile. How different would this be 
from the SASL point of view? I.e. what difference would it make on the 
"SASL wire"?

>
> I believe the cost of deploying a client is such that it's absolutely
> essential to use that change to move discovery to it.
>
> I was hoping to have an I-D submitted by now, but I haven't found the time.
> Hopefully fairly soon.
>
>> However, as I mentioned, I don't know how to do better than the current
>> mechanism given the common requirement that the server provide an IDP
>> discovery URI.  I do understand that requirement is important.
>
> I haven't seen a compelling argument for why it's important. It's actually
> been a problem for federation since its inception, and when you can avoid
> it, you really have to.

There is no compelling argument other than that this is the way it is 
done in most identity federations today and I wanted to stay as close as 
possible to today's implementations and not fall into the trap of trying 
to introduce something new and at the same time try to fix all other 
problems in the world.

> It's something you can work around in cases in which the application relies
> on identifiers that resemble email addresses and can be used to perform an
> implicit kind of discovery, but that's not a generalized case, and it still
> results in the additional security issues you mentioned.

Agreed.

Klaas

From cantor.2@osu.edu  Wed May 26 08:08:38 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2F73A683F for <kitten@core3.amsl.com>; Wed, 26 May 2010 08:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 RM9PpE0SufR3 for <kitten@core3.amsl.com>; Wed, 26 May 2010 08:08:37 -0700 (PDT)
Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by core3.amsl.com (Postfix) with ESMTP id 9901B3A6359 for <kitten@ietf.org>; Wed, 26 May 2010 08:08:37 -0700 (PDT)
X-Authority-Analysis: v=1.1 cv=Pm0qIGCwx3bIEOZlSg1a56K3RSwKBTW9sPEb+DFvEKk= c=1 sm=0 a=FNPjm8h7-gQA:10 a=0qYQvVkOOIcA:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=ZVL_7Xqr5YMxoD93R1wA:9 a=8kaPJNggRd5kbjln-7IA:7 a=x-tPcLOtnoXcFznNn-55bZjQSZoA:4 a=CjuIK1q_8ugA:10 a=rjC1WpulEXHb2dl-:21 a=GYJa4N8imfAWlNCz:21 a=/Wh0N9815gtYTLoiNwER9g==:117
X-Cloudmark-Score: 0
X-Originating-IP: 24.210.116.83
Received: from [24.210.116.83] ([24.210.116.83:21668] helo=SNOWDOG) by hrndva-oedge03.mail.rr.com (envelope-from <cantor.2@osu.edu>) (ecelerity 2.2.2.39 r()) with ESMTP id AC/CC-23859-B693DFB4; Wed, 26 May 2010 15:08:28 +0000
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Klaas Wierenga'" <klaas@cisco.com>
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com>
In-Reply-To: <4BFD2ECE.5020600@cisco.com>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Wed, 26 May 2010 11:08:29 -0400
Organization: The Ohio State University
Message-ID: <07e801cafce5$4cf7f7b0$e6e7e710$@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: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmaQPSUmgA==
Content-Language: en-us
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 15:08:38 -0000

> I am assuming you refer to the ECP profile. How different would this be
> from the SASL point of view? I.e. what difference would it make on the
> "SASL wire"?

Significantly different from yours, since there's no empty response and no
callback communication between the SP and the IdP, but I believe it can be
compatible with SAML ECP on the IdP side, and is essentially a direct
mapping from using HTTP as a "container" for the SP/client SOAP envelopes to
using the SASL messages.

It suffers the same MITM issues that Sam mentioned, since that's what
happens if you punt that to TLS without any channel bindings. I'm not in a
position to address that without help, I just believe there's a better
non-web flow here. It also creates a much more flexible field for phishing
to be addressed, since the client/IdP exchange is not a browser and a web
site.

The only issue to address in translating the profile over to SASL is the
fact that in a non-web case there's no real "responseURL" involved, which is
something that's baked into the standard ECP profile, but I think it can be
"emulated" with no particular effort in the interest of compatibility, or
removed at the cost of same.
 
> There is no compelling argument other than that this is the way it is
> done in most identity federations today and I wanted to stay as close as
> possible to today's implementations and not fall into the trap of trying
> to introduce something new and at the same time try to fix all other
> problems in the world.

This makes sense if you're remaining compatible with something people *want*
to deal with, but IdP discovery is the last thing anybody operating an SP
*wants* to deal with. It's a gigantic usability problem, and arguably the
biggest reason why federation has scaling issues.

Anyway, it's on me to produce the draft, which I've started on (using yours
as a starting point, which I hope is ok).

-- Scott



From klaas@cisco.com  Wed May 26 08:42:14 2010
Return-Path: <klaas@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45963A659A for <kitten@core3.amsl.com>; Wed, 26 May 2010 08:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.43
X-Spam-Level: 
X-Spam-Status: No, score=-4.43 tagged_above=-999 required=5 tests=[AWL=-1.831,  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 on-iNjGLyyIg for <kitten@core3.amsl.com>; Wed, 26 May 2010 08:42:13 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3C4093A66B4 for <kitten@ietf.org>; Wed, 26 May 2010 08:42:13 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0BAHXe/EuQ/uCWe2dsb2JhbACeHRUBARYiBhyoCZoAglqCOQSPUw
X-IronPort-AV: E=Sophos;i="4.53,304,1272844800";  d="scan'208";a="7835152"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 May 2010 15:03:00 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QFg3ps019581; Wed, 26 May 2010 15:42:03 GMT
Message-ID: <4BFD414A.7070002@cisco.com>
Date: Wed, 26 May 2010 17:42:02 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Scott Cantor <cantor.2@osu.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu>
In-Reply-To: <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 15:42:14 -0000

On 5/26/10 5:08 PM, Scott Cantor wrote:
>> I am assuming you refer to the ECP profile. How different would this be
>> from the SASL point of view? I.e. what difference would it make on the
>> "SASL wire"?
>
> Significantly different from yours, since there's no empty response and no
> callback communication between the SP and the IdP, but I believe it can be
> compatible with SAML ECP on the IdP side, and is essentially a direct
> mapping from using HTTP as a "container" for the SP/client SOAP envelopes to
> using the SASL messages.

right, but that than comes at the expense of more complex SASL 
interaction, i.e. you are going to send the AuthenticationStatement as a 
response to the AuthentionRequest challenge over SASL, right?

>
> It suffers the same MITM issues that Sam mentioned, since that's what
> happens if you punt that to TLS without any channel bindings. I'm not in a
> position to address that without help, I just believe there's a better
> non-web flow here. It also creates a much more flexible field for phishing
> to be addressed, since the client/IdP exchange is not a browser and a web
> site.
>
> The only issue to address in translating the profile over to SASL is the
> fact that in a non-web case there's no real "responseURL" involved, which is
> something that's baked into the standard ECP profile, but I think it can be
> "emulated" with no particular effort in the interest of compatibility, or
> removed at the cost of same.
>
>> There is no compelling argument other than that this is the way it is
>> done in most identity federations today and I wanted to stay as close as
>> possible to today's implementations and not fall into the trap of trying
>> to introduce something new and at the same time try to fix all other
>> problems in the world.
>
> This makes sense if you're remaining compatible with something people *want*
> to deal with, but IdP discovery is the last thing anybody operating an SP
> *wants* to deal with. It's a gigantic usability problem, and arguably the
> biggest reason why federation has scaling issues.

ok, fair point

>
> Anyway, it's on me to produce the draft, which I've started on (using yours
> as a starting point, which I hope is ok).

obviously! Looking forward to the draft.

Klaas

From cantor.2@osu.edu  Wed May 26 08:55:32 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CEC3A66B4 for <kitten@core3.amsl.com>; Wed, 26 May 2010 08:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_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 hQpz+ipuK9jD for <kitten@core3.amsl.com>; Wed, 26 May 2010 08:55:31 -0700 (PDT)
Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by core3.amsl.com (Postfix) with ESMTP id 8C7423A67DB for <kitten@ietf.org>; Wed, 26 May 2010 08:55:29 -0700 (PDT)
X-Authority-Analysis: v=1.1 cv=muTmBHIsIIrvj5np50lvqqEF3x9MmSj/zDSU9q1ni6E= c=1 sm=0 a=FNPjm8h7-gQA:10 a=0qYQvVkOOIcA:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=7xHUJE1NU49kgWwFEnEA:9 a=ej963Yy3zctA84nWFcwtFIR99AoA:4 a=CjuIK1q_8ugA:10 a=/Wh0N9815gtYTLoiNwER9g==:117
X-Cloudmark-Score: 0
X-Originating-IP: 24.210.116.83
Received: from [24.210.116.83] ([24.210.116.83:29913] helo=SNOWDOG) by hrndva-oedge04.mail.rr.com (envelope-from <cantor.2@osu.edu>) (ecelerity 2.2.2.39 r()) with ESMTP id AA/15-22658-8644DFB4; Wed, 26 May 2010 15:55:20 +0000
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Klaas Wierenga'" <klaas@cisco.com>
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <4BFD414A.7070002@cisco.com>
In-Reply-To: <4BFD414A.7070002@cisco.com>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Wed, 26 May 2010 11:55:21 -0400
Organization: The Ohio State University
Message-ID: <07f301cafceb$d9244f30$8b6ced90$@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: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCs1lfWwKr/Y2zkBI5PBA=
Content-Language: en-us
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 15:55:32 -0000

> right, but that than comes at the expense of more complex SASL
> interaction, i.e. you are going to send the AuthenticationStatement as a
> response to the AuthentionRequest challenge over SASL, right?

It's a SAML Response (the statement is well buried), but why is that more
complex than an empty response, running a web server to handle a SSO
response, and then making a callback?

I think it's a much simpler flow. Request, Response.

I'm coming at this with probably insufficient SASL knowledge, though I'm
trying to rectify that. Maybe I'm missing something.

-- Scott



From hartmans@mit.edu  Wed May 26 11:27:12 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772083A69B9 for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.965
X-Spam-Level: 
X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1QnBDLRX-CD for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:27:11 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B34D63A68AA for <kitten@ietf.org>; Wed, 26 May 2010 11:27:11 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 71511201F6; Wed, 26 May 2010 14:26:58 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F21EF43EF; Wed, 26 May 2010 14:26:30 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: "Scott Cantor" <cantor.2@osu.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu>
Date: Wed, 26 May 2010 14:26:30 -0400
In-Reply-To: <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> (Scott Cantor's message of "Wed, 26 May 2010 11:08:29 -0400")
Message-ID: <tslvdaa4izt.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 18:27:12 -0000

>>>>> "Scott" == Scott Cantor <cantor.2@osu.edu> writes:

    >> I am assuming you refer to the ECP profile. How different would
    >> this be from the SASL point of view? I.e. what difference would
    >> it make on the "SASL wire"?

    Scott> It suffers the same MITM issues that Sam mentioned, since
    Scott> that's what happens if you punt that to TLS without any
    Scott> channel bindings. I'm not in a position to address that
    Scott> without help, I just believe there's a better non-web flow
    Scott> here. It also creates a much more flexible field for phishing
    Scott> to be addressed, since the client/IdP exchange is not a
    Scott> browser and a web site.

Scott, I'm happy to work with you to figure out if channel binding
support is possible in your approach.

From hartmans@mit.edu  Wed May 26 11:29:19 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABDA3A69B1 for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level: 
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY-FmFXPhh6F for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:29:18 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9FCE23A68AA for <kitten@ietf.org>; Wed, 26 May 2010 11:29:18 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D2E88201CA; Wed, 26 May 2010 14:29:09 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7822343EF; Wed, 26 May 2010 14:28:42 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Klaas Wierenga <klaas@cisco.com>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com>
Date: Wed, 26 May 2010 14:28:42 -0400
In-Reply-To: <4BFD2ECE.5020600@cisco.com> (Klaas Wierenga's message of "Wed, 26 May 2010 16:23:10 +0200")
Message-ID: <tslr5ky4iw5.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@MIT.EDU>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 18:29:19 -0000

>>>>> "Klaas" == Klaas Wierenga <klaas@CISCO.COM> writes:

    Klaas> right, so the server would have a list of realm to idp-url
    Klaas> mappings?

In order for the proposal I made to work, the following must be true:

1) The IDP MUST verify that channel binding data is asserted by the
expected RP and has been modified by no other party

2) The client MUST verify that the channel binding data corresponds to
the channel that is in use.

Those two are enough that the user will learn through the web browser if
the connection is under attack.  However, the that's not enough to
defend against a server that fakes successful authentication or to learn
at the SASL protocol level about a channel binding failure.

3)  The client inserts a cookie into the return URL

4) The server or agents under the control of the server not see this
cookie before succesful authentication

5) The server returns the cookie to the client.

I'm not actually sure 3 is possible: I'm not sure whether the return URL
is covered by the signature.  Assuming it's possible, 4 means that the
client must be able to verify that the IDP URL it goes to is one that it
trusts.  So, ultimately, the server can pick however you like, but it
MUST pick from a list of *URLs* that the client trusts.  Anything like
the server mapping an IDP hint to a URL destroys the security property.

Note that it's possible to have multiple modes of operation with
different security properties.  That creates UI challenges, but that is
potentially doable.

From cantor.2@osu.edu  Wed May 26 11:41:44 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DCA3A692E for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level: 
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_50=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 QcDHNpvo4Tf2 for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:41:44 -0700 (PDT)
Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id EC7983A6915 for <kitten@ietf.org>; Wed, 26 May 2010 11:41:42 -0700 (PDT)
Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QIfVva030254; Wed, 26 May 2010 14:41:31 -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 o4QIfUTp004960; Wed, 26 May 2010 14:41:30 -0400
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu>
In-Reply-To: <tslvdaa4izt.fsf@mit.edu>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Wed, 26 May 2010 14:41:32 -0400
Organization: The Ohio State University
Message-ID: <082501cafd03$0fe0f250$2fa2d6f0$@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: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCs1lfWwFbRpYxkBzsvvA=
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.133
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 18:41:45 -0000

> Scott, I'm happy to work with you to figure out if channel binding
> support is possible in your approach.

I plan to take you up on it. To ease the process of comparing the
approaches, I think it's easiest to produce a simple draft initially, which
highlights some of the issues you mentioned, but leaves things as is for the
same compatibility reasons that Klaas had. The result may be a merging of
the proposals, or not.

Related to this, for example, I'm in favor of supporting a way to tie the
SAML assertion in the response to a key at the TLS layer (holder of key via
client TLS, in other words). That's an addition to the SAML profile I'm
basing this work on, which is why I'm not starting there, to simplify the
compatibility story. I probably will go back to OASIS to get a HoK version
of the ECP profile created, and then I can just reference it.

I'm fairly far along since starting on this last night so I should have
something soon.

-- Scott



From cantor.2@osu.edu  Wed May 26 11:43:41 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AE33A697A for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.049
X-Spam-Level: 
X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=1.550,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0KLgtO5v8vc for <kitten@core3.amsl.com>; Wed, 26 May 2010 11:43:39 -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 4FB293A6998 for <kitten@ietf.org>; Wed, 26 May 2010 11:43:39 -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 o4QIhSEE028312; Wed, 26 May 2010 14:43:28 -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 o4QIhSa7015293; Wed, 26 May 2010 14:43:28 -0400
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>, "'Klaas Wierenga'" <klaas@cisco.com>
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <tslr5ky4iw5.fsf@mit.edu>
In-Reply-To: <tslr5ky4iw5.fsf@mit.edu>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Wed, 26 May 2010 14:43:30 -0400
Organization: The Ohio State University
Message-ID: <082601cafd03$561cfcf0$0256f6d0$@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: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCW31CfpAqh8xw
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, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 18:43:41 -0000

> I'm not actually sure 3 is possible: I'm not sure whether the return URL
> is covered by the signature.

The signature in a SAML redirect binding URL is over a defined set of
parameters in a particular order, and is not perturbed by additional
parameters (though of course they are not protected by it).

-- Scott



From simon@josefsson.org  Wed May 26 12:59:11 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72DF3A693D for <kitten@core3.amsl.com>; Wed, 26 May 2010 12:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 QxqK+WZ3rF5u for <kitten@core3.amsl.com>; Wed, 26 May 2010 12:59:10 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 679E63A66B4 for <kitten@ietf.org>; Wed, 26 May 2010 12:59:08 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4QJwoBM011259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 May 2010 21:58:52 +0200
From: Simon Josefsson <simon@josefsson.org>
To: "Scott Cantor" <cantor.2@osu.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100526:cantor.2@osu.edu::4mUl+BzOxCUosyrh:0Wov
X-Hashcash: 1:22:100526:hartmans-ietf@mit.edu::OmIuQrExQxZoj74s:4f07
X-Hashcash: 1:22:100526:draft-wierenga-ietf-sasl-saml@tools.ietf.org::ewt5bE+/ouv1u4Qd:8D8m
X-Hashcash: 1:22:100526:kitten@ietf.org::N7SHP1pEIYT/OKiZ:UOsD
X-Hashcash: 1:22:100526:moonshot-community@jiscmail.ac.uk::91rBAwA1NaEJ4Nw1:j8N3
Date: Wed, 26 May 2010 21:58:50 +0200
In-Reply-To: <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> (Scott Cantor's message of "Wed, 26 May 2010 14:41:32 -0400")
Message-ID: <87fx1eo2o5.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 19:59:11 -0000

"Scott Cantor" <cantor.2@osu.edu> writes:

>> Scott, I'm happy to work with you to figure out if channel binding
>> support is possible in your approach.
>
> I plan to take you up on it. To ease the process of comparing the
> approaches, I think it's easiest to produce a simple draft initially, which
> highlights some of the issues you mentioned, but leaves things as is for the
> same compatibility reasons that Klaas had. The result may be a merging of
> the proposals, or not.
>
> Related to this, for example, I'm in favor of supporting a way to tie the
> SAML assertion in the response to a key at the TLS layer (holder of key via
> client TLS, in other words). That's an addition to the SAML profile I'm
> basing this work on, which is why I'm not starting there, to simplify the
> compatibility story. I probably will go back to OASIS to get a HoK version
> of the ECP profile created, and then I can just reference it.

I would prefer if channel bindings is done in a GS2 compatible way, to
allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
By using the GS2 prefix, you also get support for authorization
identities.

If authors are interested here, I could help with the GS2 prefix part so
that it causes minimal confusion for non-GSS-API people and still allows
that variant.  I made this suggestion for the OpenID SASL mechanism as
well.

/Simon

From cantor.2@osu.edu  Wed May 26 13:18:20 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0955C3A69CC for <kitten@core3.amsl.com>; Wed, 26 May 2010 13:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level: 
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=1.033,  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 oyFgy99XIR9a for <kitten@core3.amsl.com>; Wed, 26 May 2010 13:17:59 -0700 (PDT)
Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id 7009D3A69E5 for <kitten@ietf.org>; Wed, 26 May 2010 13:17:44 -0700 (PDT)
Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QKHYfJ013122; Wed, 26 May 2010 16:17:34 -0400
Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QKHW3P027717; Wed, 26 May 2010 16:17:33 -0400
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Simon Josefsson'" <simon@josefsson.org>
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org>
In-Reply-To: <87fx1eo2o5.fsf@mocca.josefsson.org>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Wed, 26 May 2010 16:17:34 -0400
Organization: The Ohio State University
Message-ID: <084601cafd10$7b6633c0$72329b40$@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: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCs1lfWwFbRpYxAjty4KIB2IJ2bY/8aGGQ
Content-Language: en-us
X-CanIt-Geo: ip=128.146.216.86; 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.133
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 20:18:20 -0000

> I would prefer if channel bindings is done in a GS2 compatible way, to
> allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
> By using the GS2 prefix, you also get support for authorization
> identities.
> 
> If authors are interested here, I could help with the GS2 prefix part so
> that it causes minimal confusion for non-GSS-API people and still allows
> that variant.  I made this suggestion for the OpenID SASL mechanism as
> well.

I'm completely open to any and all SASL/GSS-related suggestions and
improvements. This is sort of a 5 year old work item for me that dates back
to SAML 2's initial design work, which I intended to demonstrate as a fit
for SASL and never got the time or the perceived interest to get done.

I just want to get a proposal out that "fits" my original intention for how
this would look, and then let the experts on the non-SAML parts whack it
into shape once there's an understanding of the compatibility trade-offs.

-- Scott



From lear@cisco.com  Thu May 27 02:44:05 2010
Return-Path: <lear@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CD63A67E5; Thu, 27 May 2010 02:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaQ4qU1mGNVf; Thu, 27 May 2010 02:44:04 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 452C63A67AF; Thu, 27 May 2010 02:44:04 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjICAIPb/UuQ/uCWe2dsb2JhbACDF5sBFQEBFiIGHKYTiQ2RCYElgwRqBINA
X-IronPort-AV: E=Sophos;i="4.53,310,1272844800";  d="scan'208";a="7889328"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 May 2010 09:04:47 +0000
Received: from ams3-vpn-dhcp4135.cisco.com (ams3-vpn-dhcp4135.cisco.com [10.61.80.38]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4R9hoJq023824; Thu, 27 May 2010 09:43:51 GMT
Message-ID: <4BFE3EAC.1010403@cisco.com>
Date: Thu, 27 May 2010 15:13:08 +0530
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100524 Lanikai/3.1.1pre
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter<
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com>
In-Reply-To: <20100526141632.GW9605@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, sasl@ietf.org, Jeffrey Hutzelman <jhutz@cmu.edu>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 09:44:05 -0000

  I don't generally care about naming, and while I don't feel strongly 
about names, and was mostly joking with all of this when it began (and I 
apologize for that), there is a benefit about creating a new name, which 
is that kitten is known for GSS work and SASL is known for SASL work.  
Having a new name may actually lead to less confusion for those 
wondering what happens in the combined group.

From alexey.melnikov@isode.com  Thu May 27 02:48:28 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189733A684C; Thu, 27 May 2010 02:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 9nXzCOzMDn7v; Thu, 27 May 2010 02:48:27 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4BA3E3A67AF; Thu, 27 May 2010 02:48:27 -0700 (PDT)
Received: from [10.234.41.233] ((unknown) [217.41.234.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <S=4=4QBeGTOv@rufus.isode.com>; Thu, 27 May 2010 10:48:17 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4BFE3FE2.6060408@isode.com>
Date: Thu, 27 May 2010 10:48:18 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15
To: Eliot Lear <lear@cisco.com>
Subject: Re: [sasl] MOGGIES Proposed Charter<
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com>
In-Reply-To: <4BFE3EAC.1010403@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 09:48:28 -0000

Eliot Lear wrote:
>  I don't generally care about naming, and while I don't feel strongly 
> about names, and was mostly joking with all of this when it began (and 
> I apologize for that), there is a benefit about creating a new name, 
> which is that kitten is known for GSS work and SASL is known for SASL 
> work.  Having a new name may actually lead to less confusion for those 
> wondering what happens in the combined group.
+1.

(No opinion about use of MOGGIES or any other name.)

From klaas@cisco.com  Thu May 27 05:34:28 2010
Return-Path: <klaas@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A38E3A6AA3 for <kitten@core3.amsl.com>; Thu, 27 May 2010 05:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.972
X-Spam-Level: 
X-Spam-Status: No, score=-7.972 tagged_above=-999 required=5 tests=[AWL=2.627,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRW2cm8vW+ib for <kitten@core3.amsl.com>; Thu, 27 May 2010 05:34:26 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 44F723A68B3 for <kitten@ietf.org>; Thu, 27 May 2010 05:34:26 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYBAA8E/kuQ/uCWe2dsb2JhbACeGxUBARYiBhymSpoYhRMEj1g
X-IronPort-AV: E=Sophos;i="4.53,311,1272844800"; d="scan'208";a="61900128"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 May 2010 12:34:15 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4RCYEVw018481; Thu, 27 May 2010 12:34:14 GMT
Message-ID: <4BFE66C6.6060108@cisco.com>
Date: Thu, 27 May 2010 14:34:14 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Scott Cantor <cantor.2@osu.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <4BFD414A.7070002@cisco.com> <07f301cafceb$d9244f30$8b6ced90$@osu.edu>
In-Reply-To: <07f301cafceb$d9244f30$8b6ced90$@osu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 12:34:28 -0000

On 5/26/10 5:55 PM, Scott Cantor wrote:
>> right, but that than comes at the expense of more complex SASL
>> interaction, i.e. you are going to send the AuthenticationStatement as a
>> response to the AuthentionRequest challenge over SASL, right?
>
> It's a SAML Response (the statement is well buried), but why is that more
> complex than an empty response, running a web server to handle a SSO
> response, and then making a callback?
>
> I think it's a much simpler flow. Request, Response.
>
> I'm coming at this with probably insufficient SASL knowledge, though I'm
> trying to rectify that. Maybe I'm missing something.

No sorry, what I meant to say is that at the client it is easier to do 
"please open a browser with the following url" as opposed to "here is a 
saml assertion, deal with it and send me back your 
AuthenticationStatement", for the SASL interaction it is not more 
difficult indeed.

Klaas

From tlyu@mit.edu  Thu May 27 06:17:56 2010
Return-Path: <tlyu@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB71E3A6A36; Thu, 27 May 2010 06:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 W7EGESSS9BYs; Thu, 27 May 2010 06:17:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id BA5133A6AA3; Thu, 27 May 2010 06:17:55 -0700 (PDT)
X-AuditID: 12074423-b7c0bae0000030f0-7b-4bfe70f91637
Received: from mailhub-auth-3.mit.edu (MAILHUB-AUTH-3.MIT.EDU [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 93.D5.12528.9F07EFB4; Thu, 27 May 2010 09:17:45 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o4RDHi9h024792;  Thu, 27 May 2010 09:17:44 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4RDHfqj000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 May 2010 09:17:42 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4RDHfnq007524; Thu, 27 May 2010 09:17:41 -0400 (EDT)
To: Eliot Lear <lear@cisco.com>
Subject: Re: [sasl] MOGGIES Proposed Charter<
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 27 May 2010 09:17:41 -0400
In-Reply-To: <4BFE3EAC.1010403@cisco.com> (Eliot Lear's message of "Thu, 27 May 2010 15:13:08 +0530")
Message-ID: <ldvr5kxqya2.fsf@cathode-dark-space.mit.edu>
Lines: 20
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: AAAAAA==
Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 13:17:57 -0000

Eliot Lear <lear@cisco.com> writes:

>  I don't generally care about naming, and while I don't feel strongly
> about names, and was mostly joking with all of this when it began (and
> I apologize for that), there is a benefit about creating a new name,
> which is that kitten is known for GSS work and SASL is known for SASL
> work.  Having a new name may actually lead to less confusion for those
> wondering what happens in the combined group.

I notice that Secretariat's expansion for "KITTEN" is "GSS-API Next
Generation".  If we change it to "Common Authentication Technology
Next Generation", based on the old CAT WG name (and actually part of
the current charter text!), it would imply a broader scope than
GSS-API, encompassing SASL and more, so KITTEN could adopt the work of
SASL by a change of charter.  After all, Kerberos was a product of the
CAT working group.

Are there objections to adopting this approach?  Is there likely to be
confusion if we announce that the scope of KITTEN is expanding beyond
GSS-API?

From klaas@cisco.com  Thu May 27 08:19:28 2010
Return-Path: <klaas@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B643A6960 for <kitten@core3.amsl.com>; Thu, 27 May 2010 08:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.185
X-Spam-Level: 
X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id US3Asl+ZOx81 for <kitten@core3.amsl.com>; Thu, 27 May 2010 08:19:27 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0C1883A6950 for <kitten@ietf.org>; Thu, 27 May 2010 08:19:26 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAYq/ktAZnwN/2dsb2JhbACeH3GnL5opgwoCggcEj1g
X-IronPort-AV: E=Sophos;i="4.53,311,1272844800"; d="scan'208";a="115395057"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 May 2010 15:19:17 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4RFJGON017381; Thu, 27 May 2010 15:19:16 GMT
Message-ID: <4BFE8D74.3090102@cisco.com>
Date: Thu, 27 May 2010 17:19:16 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu>	<077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <tslr5ky4iw5.fsf@mit.edu>
In-Reply-To: <tslr5ky4iw5.fsf@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 15:19:28 -0000

On 5/26/10 8:28 PM, Sam Hartman wrote:

Sam,

Just to understand, what does channel binding buy you if you still can 
not prevent the MiTM? The SAML interactions can:

- give you a return url to the Relying Party and a 'transaction id'
- have you authenticate at your IdP
- have the IdP verify that the RP is a 'trusted' one
- have the (trusted) SP verify that it indeed issued that authentication 
request

Klaas

>>>>>> "Klaas" == Klaas Wierenga<klaas@CISCO.COM>  writes:
>
>      Klaas>  right, so the server would have a list of realm to idp-url
>      Klaas>  mappings?
>
> In order for the proposal I made to work, the following must be true:
>
> 1) The IDP MUST verify that channel binding data is asserted by the
> expected RP and has been modified by no other party
>
> 2) The client MUST verify that the channel binding data corresponds to
> the channel that is in use.
>
> Those two are enough that the user will learn through the web browser if
> the connection is under attack.  However, the that's not enough to
> defend against a server that fakes successful authentication or to learn
> at the SASL protocol level about a channel binding failure.
>
> 3)  The client inserts a cookie into the return URL
>
> 4) The server or agents under the control of the server not see this
> cookie before succesful authentication
>
> 5) The server returns the cookie to the client.
>
> I'm not actually sure 3 is possible: I'm not sure whether the return URL
> is covered by the signature.  Assuming it's possible, 4 means that the
> client must be able to verify that the IDP URL it goes to is one that it
> trusts.  So, ultimately, the server can pick however you like, but it
> MUST pick from a list of *URLs* that the client trusts.  Anything like
> the server mapping an IDP hint to a URL destroys the security property.
>
> Note that it's possible to have multiple modes of operation with
> different security properties.  That creates UI challenges, but that is
> potentially doable.


From klaas@cisco.com  Thu May 27 08:27:43 2010
Return-Path: <klaas@cisco.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CE83A6AA3 for <kitten@core3.amsl.com>; Thu, 27 May 2010 08:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Level: 
X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[AWL=2.101,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcBgYxpZnR2R for <kitten@core3.amsl.com>; Thu, 27 May 2010 08:27:42 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 722503A6950 for <kitten@ietf.org>; Thu, 27 May 2010 08:27:42 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYBAOcr/kuQ/uCWe2dsb2JhbACeHxUBARYiBhynOZonhRME
X-IronPort-AV: E=Sophos;i="4.53,312,1272844800"; d="scan'208";a="61911324"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 May 2010 15:27:32 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4RFRV5N010823; Thu, 27 May 2010 15:27:31 GMT
Message-ID: <4BFE8F63.5080802@cisco.com>
Date: Thu, 27 May 2010 17:27:31 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu>	<077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com>	<07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu>	<082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org>
In-Reply-To: <87fx1eo2o5.fsf@mocca.josefsson.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org, 'Sam Hartman' <hartmans-ietf@mit.edu>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 15:27:44 -0000

On 5/26/10 9:58 PM, Simon Josefsson wrote:

Hi Simon,

> "Scott Cantor"<cantor.2@osu.edu>  writes:
>
>>> Scott, I'm happy to work with you to figure out if channel binding
>>> support is possible in your approach.
>>
>> I plan to take you up on it. To ease the process of comparing the
>> approaches, I think it's easiest to produce a simple draft initially, which
>> highlights some of the issues you mentioned, but leaves things as is for the
>> same compatibility reasons that Klaas had. The result may be a merging of
>> the proposals, or not.
>>
>> Related to this, for example, I'm in favor of supporting a way to tie the
>> SAML assertion in the response to a key at the TLS layer (holder of key via
>> client TLS, in other words). That's an addition to the SAML profile I'm
>> basing this work on, which is why I'm not starting there, to simplify the
>> compatibility story. I probably will go back to OASIS to get a HoK version
>> of the ECP profile created, and then I can just reference it.
>
> I would prefer if channel bindings is done in a GS2 compatible way, to
> allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
> By using the GS2 prefix, you also get support for authorization
> identities.
>
> If authors are interested here, I could help with the GS2 prefix part so
> that it causes minimal confusion for non-GSS-API people and still allows
> that variant.  I made this suggestion for the OpenID SASL mechanism as
> well.

Thanks for the kind offer! My concern is that one of the design goals I 
started out with was not having to touch the existing IdP's. I lack here 
knowledge (have to read up on GSS-API), but would that be possible?

Klaas

From hartmans@mit.edu  Thu May 27 08:47:09 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF453A6359; Thu, 27 May 2010 08:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.01
X-Spam-Level: 
X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.325,  BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr4C7klzRv8M; Thu, 27 May 2010 08:47:05 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 36F5E3A6968; Thu, 27 May 2010 08:47:04 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 15C40203C9; Thu, 27 May 2010 11:46:53 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E95043EF; Thu, 27 May 2010 11:46:23 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Tom Yu <tlyu@MIT.EDU>
Subject: Re: [sasl] MOGGIES Proposed Charter<
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> <ldvr5kxqya2.fsf@cathode-dark-space.mit.edu>
Date: Thu, 27 May 2010 11:46:23 -0400
In-Reply-To: <ldvr5kxqya2.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of "Thu, 27 May 2010 09:17:41 -0400")
Message-ID: <tsleigx2vqo.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: simon@josefsson.org, Eliot Lear <lear@cisco.com>, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 15:47:09 -0000

>>>>> "Tom" == Tom Yu <tlyu@MIT.EDU> writes:

    Tom> Eliot Lear <lear@cisco.com> writes:
    >> I don't generally care about naming, and while I don't feel
    >> strongly about names, and was mostly joking with all of this when
    >> it began (and I apologize for that), there is a benefit about
    >> creating a new name, which is that kitten is known for GSS work
    >> and SASL is known for SASL work.  Having a new name may actually
    >> lead to less confusion for those wondering what happens in the
    >> combined group.

    Tom> I notice that Secretariat's expansion for "KITTEN" is "GSS-API
    Tom> Next Generation".  If we change it to "Common Authentication
    Tom> Technology Next Generation", based on the old CAT WG name (and
    Tom> actually part of the current charter text!), it would imply a
    Tom> broader scope than GSS-API, encompassing SASL and more, so
    Tom> KITTEN could adopt the work of SASL by a change of charter.
    Tom> After all, Kerberos was a product of the CAT working group.

I think this is especially true since RFC 2222 was discussed (although I
believe never adopted) by CAT.

From Nicolas.Williams@oracle.com  Thu May 27 08:54:55 2010
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758423A696F; Thu, 27 May 2010 08:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.573
X-Spam-Level: 
X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLXKNwVfLXfZ; Thu, 27 May 2010 08:54:54 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8DE363A6B18; Thu, 27 May 2010 08:54:54 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RFsZ2O029216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 15:54:37 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RE7Ah5012934; Thu, 27 May 2010 15:54:33 GMT
Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 274137461274975671; Thu, 27 May 2010 08:54:31 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 08:54:29 -0700
Date: Thu, 27 May 2010 10:54:21 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Tom Yu <tlyu@mit.edu>
Subject: Re: [sasl] MOGGIES Proposed Charter<
Message-ID: <20100527155421.GR9605@oracle.com>
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> <ldvr5kxqya2.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ldvr5kxqya2.fsf@cathode-dark-space.mit.edu>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet13.oracle.com [148.87.113.125]
X-CT-RefId: str=0001.0A090208.4BFE95C3.012B:SCFMA4539811,ss=1,fgs=0
Cc: simon@josefsson.org, Eliot Lear <lear@cisco.com>, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 15:54:55 -0000

On Thu, May 27, 2010 at 09:17:41AM -0400, Tom Yu wrote:
> Eliot Lear <lear@cisco.com> writes:
> 
> >  I don't generally care about naming, and while I don't feel strongly
> > about names, and was mostly joking with all of this when it began (and
> > I apologize for that), there is a benefit about creating a new name,
> > which is that kitten is known for GSS work and SASL is known for SASL
> > work.  Having a new name may actually lead to less confusion for those
> > wondering what happens in the combined group.
> 
> I notice that Secretariat's expansion for "KITTEN" is "GSS-API Next
> Generation".  If we change it to "Common Authentication Technology
> Next Generation", based on the old CAT WG name (and actually part of
> the current charter text!), it would imply a broader scope than
> GSS-API, encompassing SASL and more, so KITTEN could adopt the work of
> SASL by a change of charter.  After all, Kerberos was a product of the
> CAT working group.

I like this approach best.

> Are there objections to adopting this approach?  Is there likely to be

None here.

> confusion if we announce that the scope of KITTEN is expanding beyond
> GSS-API?

As Sam points out, although CAT's output was mostly related to the
GSS-API, it did work on Kerberos and authentication in general -- just
look at the CAT WG page:

http://www.ietf.org/wg/concluded/cat.html

Therefore it is logical that KITTEN, son-of-CAT, too should have as
broad a scope as CAT did.  Yeah, OK, few are likely to notice this, but
maybe we can get the KITTEN WG charter page to link prominently to the
CAT WG charter page.

Nico
-- 

From jhutz@cmu.edu  Thu May 27 10:08:58 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE96C3A6B57; Thu, 27 May 2010 10:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.493
X-Spam-Level: 
X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=0.247,  BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npppvk+XWgqK; Thu, 27 May 2010 10:08:58 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id C746E3A6ABA; Thu, 27 May 2010 10:08:57 -0700 (PDT)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4RH8kOd001330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 13:08:47 -0400 (EDT)
Date: Thu, 27 May 2010 13:08:46 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>, Tom Yu <tlyu@mit.edu>
Subject: Re: [sasl] MOGGIES Proposed Charter<
Message-ID: <064EB81E3BE0FBF68E7034F3@lysithea.fac.cs.cmu.edu>
In-Reply-To: <16096_1274975689_o4RFsmbb000306_20100527155421.GR9605@oracle.com>
References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com>	<ldvr5kxqya2.fsf@cathode-dark-space.mit.edu> <16096_1274975689_o4RFsmbb000306_20100527155421.GR9605@oracle.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.196
Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 17:08:58 -0000

--On Thursday, May 27, 2010 10:54:21 AM -0500 Nicolas Williams 
<Nicolas.Williams@oracle.com> wrote:

> On Thu, May 27, 2010 at 09:17:41AM -0400, Tom Yu wrote:
>> Eliot Lear <lear@cisco.com> writes:
>>
>> >  I don't generally care about naming, and while I don't feel strongly
>> > about names, and was mostly joking with all of this when it began (and
>> > I apologize for that), there is a benefit about creating a new name,
>> > which is that kitten is known for GSS work and SASL is known for SASL
>> > work.  Having a new name may actually lead to less confusion for those
>> > wondering what happens in the combined group.
>>
>> I notice that Secretariat's expansion for "KITTEN" is "GSS-API Next
>> Generation".  If we change it to "Common Authentication Technology
>> Next Generation", based on the old CAT WG name (and actually part of
>> the current charter text!), it would imply a broader scope than
>> GSS-API, encompassing SASL and more, so KITTEN could adopt the work of
>> SASL by a change of charter.  After all, Kerberos was a product of the
>> CAT working group.
>
> I like this approach best.

Me too.

From cantor.2@osu.edu  Thu May 27 10:16:38 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7423A3A6B7B; Thu, 27 May 2010 10:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.824
X-Spam-Level: 
X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.775,  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 yxHCh79YwE2R; Thu, 27 May 2010 10:16:37 -0700 (PDT)
Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id BA6B63A6B57; Thu, 27 May 2010 10:16:36 -0700 (PDT)
Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RHGPaL028357; Thu, 27 May 2010 13:16:25 -0400
Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RHGPS8001177; Thu, 27 May 2010 13:16:25 -0400
From: "Scott Cantor" <cantor.2@osu.edu>
To: <sasl@ietf.org>, <kitten@ietf.org>
Subject: SASL mech for SAML "Enhanced Clients" submitted
Date: Thu, 27 May 2010 13:16:27 -0400
Organization: The Ohio State University
Message-ID: <08e001cafdc0$577e8ce0$067ba6a0$@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: Acr9v8V2TYDFQ2jZTIC4rmGhnCMSRg==
Content-Language: en-us
X-CanIt-Geo: ip=128.146.216.86; 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.133
Cc: moonshot-community@jiscmail.ac.uk
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 17:16:38 -0000

Klaas, WGs,

My proposed SASL mechanism for SAML is here:
http://www.ietf.org/id/draft-cantor-ietf-sasl-saml-ec-00.txt

I used "EC" to differentiate it from Klaas' browser proposal.

I believe some obvious steps would be:

- address any questions about the differences between this and the browser
proposal
- consider whether to try to merge with Klaas' mechanism, proceed with both,
etc.
- obtain assistance from experts that have volunteered to incorporate
GSS-related changes or improvements
- consider how/whether to strengthen the security characteristics of the
mechanism(s)

-- Scott



From mrex@sap.com  Thu May 27 11:00:54 2010
Return-Path: <mrex@sap.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCE03A6B89 for <kitten@core3.amsl.com>; Thu, 27 May 2010 11:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.574
X-Spam-Level: 
X-Spam-Status: No, score=-7.574 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2NB0kmsQ-c6 for <kitten@core3.amsl.com>; Thu, 27 May 2010 11:00:53 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 87BF53A697B for <kitten@ietf.org>; Thu, 27 May 2010 11:00:53 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4RI0Bcm022005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 20:00:11 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
To: klaas@cisco.com (Klaas Wierenga)
Date: Thu, 27 May 2010 20:00:09 +0200 (MEST)
In-Reply-To: <4BFE8D74.3090102@cisco.com> from "Klaas Wierenga" at May 27, 10 05:19:16 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, hartmans-ietf@mit.edu, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 18:00:54 -0000

Klaas Wierenga wrote:
> 
> On 5/26/10 8:28 PM, Sam Hartman wrote:
> > 
> > 1) The IDP MUST verify that channel binding data is asserted by the
> > expected RP and has been modified by no other party
> >
> > 2) The client MUST verify that the channel binding data corresponds to
> > the channel that is in use.
> >
> > Those two are enough that the user will learn through the web browser if
> > the connection is under attack.  However, the that's not enough to
> > defend against a server that fakes successful authentication or to learn
> > at the SASL protocol level about a channel binding failure.
> 
> Just to understand, what does channel binding buy you if you still can 
> not prevent the MiTM?

That is a misunderstanding.  (Cryptographic) channel bindings reliably
protects you from MitM attacks.  But it can not protect you from
an attacker that can successfully impersonate a "trusted" server,
and neither from an inappropriately trusted "rogue" server.

Successfully impersonating a "trusted" server does not necessarily
require a full compromise of that server.  Being able to pass those
few superficial checks that the client performs in order to verify
the authentication of a server is perfectly sufficient -- and is
usually much easier than breaking into the real server in order to get
hold of its credentials.  Think of PKI, X.509 certs, server endpoint
identification similar to HTTP over TLS (rfc2818) and the problem
of lots of software dealing with embedded NUL chars in names,
or the problem of huge amounts of interchangeably-trusted root CAs.


-Martin

From hartmans@mit.edu  Thu May 27 11:11:58 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CAB3A6BB2 for <kitten@core3.amsl.com>; Thu, 27 May 2010 11:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.566,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XymOOXL9NhFT for <kitten@core3.amsl.com>; Thu, 27 May 2010 11:11:57 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2C6AB3A6BC4 for <kitten@ietf.org>; Thu, 27 May 2010 11:11:13 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id ADA77202FB; Thu, 27 May 2010 14:11:04 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BA79443EF; Thu, 27 May 2010 14:10:34 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: mrex@sap.com
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp>
Date: Thu, 27 May 2010 14:10:34 -0400
In-Reply-To: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu, 27 May 2010 20:00:09 +0200 (MEST)")
Message-ID: <tsliq691ahx.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, hartmans-ietf@mit.edu, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 18:11:58 -0000

>>>>> "Martin" == Martin Rex <mrex@sap.com> writes:

    Martin> Klaas Wierenga wrote:
    >> 
> On 5/26/10 8:28 PM, Sam Hartman wrote:
> > 
> > 1) The IDP MUST verify that channel binding data is asserted by the
    >> > expected RP and has been modified by no other party
    >> >
    >> > 2) The client MUST verify that the channel binding data
    >> corresponds to > the channel that is in use.
    >> >
    >> > Those two are enough that the user will learn through the web
    >> browser if > the connection is under attack.  However, the that's
    >> not enough to > defend against a server that fakes successful
    >> authentication or to learn > at the SASL protocol level about a
    >> channel binding failure.
    >> 
    >> Just to understand, what does channel binding buy you if you
    >> still can not prevent the MiTM?

Ah, I think I finally understand the question.

So, the channel binding does detect the MITM, but the question is how is
this communicated and to whom.

the two changes above are sufficient that the user would get an
authentication failure error in the browser.  However it's not
sufficient that the client application would be able to learn of this
failure without somehow parsing the web page.  The other changes I
proposed were sufficient for both the web browser and the client
application to learn of the attack.

From Josh.Howlett@ja.net  Thu May 27 12:39:56 2010
Return-Path: <Josh.Howlett@ja.net>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520F53A6BCF; Thu, 27 May 2010 12:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Skj1lHzMAgOI; Thu, 27 May 2010 12:39:55 -0700 (PDT)
Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 8B9AD3A698A; Thu, 27 May 2010 12:37:34 -0700 (PDT)
Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CBF184A6B64_BFEC9F3B; Thu, 27 May 2010 19:37:23 +0000 (GMT)
Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.atlas.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id A5F504A6B30_BFEC9EDF; Thu, 27 May 2010 19:37:17 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: SASL mech for SAML "Enhanced Clients" submitted
Date: Thu, 27 May 2010 20:37:24 +0100
Message-ID: <6ED388AA006C454BA35B0098396B9BFB073A49D1@uxsrvr20.atlas.ukerna.ac.uk>
In-Reply-To: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SASL mech for SAML "Enhanced Clients" submitted
Thread-Index: Acr9v8V2TYDFQ2jZTIC4rmGhnCMSRgAE6mRg
References: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu>
From: "Josh Howlett" <Josh.Howlett@ja.net>
To: "Scott Cantor" <cantor.2@osu.edu>, <sasl@ietf.org>, <kitten@ietf.org>
Cc: Josh Howlett <Josh.Howlett@ja.net>, moonshot-community@jiscmail.ac.uk
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 19:39:56 -0000

Scott,

> - address any questions about the differences between this=20
> and the browser proposal

There seem to be two principal differences between your proposal and
Klaas':

1. The use of the POAS binding within the SASL mechanism between the RP
and the client.

2. The use of SOAP binding between the client and the IdP.

Is that a reasonable summary?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG


From cantor.2@osu.edu  Thu May 27 12:58:20 2010
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2FC3A67E3; Thu, 27 May 2010 12:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level: 
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_50=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
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 lHcNkWbQDiQ5; Thu, 27 May 2010 12:58:19 -0700 (PDT)
Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by core3.amsl.com (Postfix) with ESMTP id 969443A68C2; Thu, 27 May 2010 12:58:18 -0700 (PDT)
Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RJw8vd024238; Thu, 27 May 2010 15:58:08 -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 o4RJw8GV006032; Thu, 27 May 2010 15:58:08 -0400
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Josh Howlett'" <Josh.Howlett@ja.net>, <sasl@ietf.org>, <kitten@ietf.org>
References: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu> <6ED388AA006C454BA35B0098396B9BFB073A49D1@uxsrvr20.atlas.ukerna.ac.uk>
In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB073A49D1@uxsrvr20.atlas.ukerna.ac.uk>
Subject: RE: SASL mech for SAML "Enhanced Clients" submitted
Date: Thu, 27 May 2010 15:58:10 -0400
Organization: The Ohio State University
Message-ID: <091c01cafdd6$eee0a990$cca1fcb0$@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: AQHSVbfbXE0qxJnSkEB8xu69ySzZJwHTUv3Gkkhj5iA=
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.134
Cc: moonshot-community@jiscmail.ac.uk
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 19:58:20 -0000

(Aside, I'm cc'ing both kitten and sasl, but if this is getting annoying,
feel free to let me know which to drop. Cost of transition I guess.)

> There seem to be two principal differences between your proposal and
> Klaas':
> 
> 1. The use of the POAS binding within the SASL mechanism between the RP
> and the client.

I wouldn't exactly call it PAOS (and I avoided referencing that binding),
since that's specifically bound to HTTP. I'm reusing some PAOS headers in
this draft to avoid making some changes to the original profile, but they
don't add much and I'm not sure they're needed. As long as the IdP can
operate in ignorance of the fact that it's not PAOS it shouldn't matter
whether it is or isn't.

What I wanted to do is make this a distinct profile that reused by inclusion
specific sections of the original one so that the actual normative message
definitions would come from the original one. For now at least (see below).

> 2. The use of SOAP binding between the client and the IdP.
> 
> Is that a reasonable summary?

Pretty much, but the use of the SOAP binding is also an arbitrary choice
designed for the purpose of reusing the ECP profile, and because it's the
only client/IdP SAML binding in existence today that isn't browser-centric.

The way to think about the difference from my point of view is like this:

Klaas' Mechanism:
- produce a URL equivalent to a Web SSO request from an SP
- send back empty response
- launch browser (explicitly or implicitly) and do Web SSO
- route result of Web SSO behind the scenes at server to trigger SASL result

Mine:
- challenge client with SAML AuthnRequest for delivery to IdP
- deliver AuthnRequest to IdP along with credentials to get Response for SP
- respond to SP with Response to complete SASL exchange

The messaging around those steps is essentially arbitrary to the conceptual
model and the ECP conventions were chosen as a starting point for reuse and
to save drafting time.
 
-- Scott



From simon@josefsson.org  Thu May 27 23:34:48 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BC23A67AD for <kitten@core3.amsl.com>; Thu, 27 May 2010 23:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Y1QVIw01e6yM for <kitten@core3.amsl.com>; Thu, 27 May 2010 23:34:47 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id AE0C93A6A1E for <kitten@ietf.org>; Thu, 27 May 2010 23:19:47 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4S6JFCu000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 May 2010 08:19:18 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Klaas Wierenga <klaas@cisco.com>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> <4BFE8F63.5080802@cisco.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100528:moonshot-community@jiscmail.ac.uk::W2s6GeWnB1HtutjY:3aSC
X-Hashcash: 1:22:100528:klaas@cisco.com::FJTIIyo+M08vctY7:FRwk
X-Hashcash: 1:22:100528:kitten@ietf.org::LtLE/kafvkmE+wOO:JhyD
X-Hashcash: 1:22:100528:hartmans-ietf@mit.edu::EI4k0a+5E5k5tvro:IZ5w
X-Hashcash: 1:22:100528:draft-wierenga-ietf-sasl-saml@tools.ietf.org::M8kk1iXUrCH3LTMd:m2cx
Date: Fri, 28 May 2010 08:19:16 +0200
In-Reply-To: <4BFE8F63.5080802@cisco.com> (Klaas Wierenga's message of "Thu, 27 May 2010 17:27:31 +0200")
Message-ID: <87pr0ga6qj.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, 'Sam Hartman' <hartmans-ietf@mit.edu>, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2010 06:34:48 -0000

Klaas Wierenga <klaas@cisco.com> writes:

> On 5/26/10 9:58 PM, Simon Josefsson wrote:
>
> Hi Simon,
>
>> "Scott Cantor"<cantor.2@osu.edu>  writes:
>>
>>>> Scott, I'm happy to work with you to figure out if channel binding
>>>> support is possible in your approach.
>>>
>>> I plan to take you up on it. To ease the process of comparing the
>>> approaches, I think it's easiest to produce a simple draft initially, which
>>> highlights some of the issues you mentioned, but leaves things as is for the
>>> same compatibility reasons that Klaas had. The result may be a merging of
>>> the proposals, or not.
>>>
>>> Related to this, for example, I'm in favor of supporting a way to tie the
>>> SAML assertion in the response to a key at the TLS layer (holder of key via
>>> client TLS, in other words). That's an addition to the SAML profile I'm
>>> basing this work on, which is why I'm not starting there, to simplify the
>>> compatibility story. I probably will go back to OASIS to get a HoK version
>>> of the ECP profile created, and then I can just reference it.
>>
>> I would prefer if channel bindings is done in a GS2 compatible way, to
>> allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
>> By using the GS2 prefix, you also get support for authorization
>> identities.
>>
>> If authors are interested here, I could help with the GS2 prefix part so
>> that it causes minimal confusion for non-GSS-API people and still allows
>> that variant.  I made this suggestion for the OpenID SASL mechanism as
>> well.
>
> Thanks for the kind offer! My concern is that one of the design goals
> I started out with was not having to touch the existing IdP's. I lack
> here knowledge (have to read up on GSS-API), but would that be
> possible?

I am not certain.  The important part is traditionally to make the
client and server agree on the channel binding, and refuse connections
when they don't match.  I don't see any value in having the IdP also
necessarily have to be involved in this negotiation.

The transfer of the channel binding needs to be integrity protected, and
it needs to be tied with the authentication.  Thus, a simple way to
achieve this would be for the client to include it in a attribute that
it signs and sends to the server.  I don't think the IdP would need to
do anything with a field like that, but it needs to be preserved and
presented to the server.  I'm not enough of a SAML expert to tell
whether this is easy to achieve or not?  I do operate a SAML server for
a company, and when we did the integration with some RPs, there were
many places were you could put extension fields, so I strongly suspect
the answer is "yes" but it needs to be confirmed.

/Simon

From hartmans@mit.edu  Fri May 28 05:41:36 2010
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7563A68A3 for <kitten@core3.amsl.com>; Fri, 28 May 2010 05:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.726
X-Spam-Level: 
X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.539,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfZ4oqy2Ma-j for <kitten@core3.amsl.com>; Fri, 28 May 2010 05:41:35 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9A6A23A6820 for <kitten@ietf.org>; Fri, 28 May 2010 05:41:34 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D0AFC202F3; Fri, 28 May 2010 08:41:20 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3AAA543EF; Fri, 28 May 2010 08:40:49 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Simon Josefsson <simon@josefsson.org>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> <4BFE8F63.5080802@cisco.com> <87pr0ga6qj.fsf@mocca.josefsson.org>
Date: Fri, 28 May 2010 08:40:49 -0400
In-Reply-To: <87pr0ga6qj.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 28 May 2010 08:19:16 +0200")
Message-ID: <tslhblsxkq6.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kitten@ietf.org, 'Sam Hartman' <hartmans-ietf@mit.edu>, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2010 12:41:36 -0000

Simon, I think the IDP may end up involved in the channel binding
discussion because the client and server may happen not to have another
mechanism for an integrity protected channel.  In cases where the client
and server directly share a key or a key falls out of the SAML exchange,
I agree with you, no IDP interaction is required.

From simon@josefsson.org  Sat May 29 02:35:22 2010
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705EC3A6893 for <kitten@core3.amsl.com>; Sat, 29 May 2010 02:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 YeViB8kpv79d for <kitten@core3.amsl.com>; Sat, 29 May 2010 02:35:21 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4A27D3A67F8 for <kitten@ietf.org>; Sat, 29 May 2010 02:35:20 -0700 (PDT)
Received: from mocca (m83-178-251-213.cust.tele2.se [83.178.251.213]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4T9YusE007424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 May 2010 11:35:02 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> <4BFE8F63.5080802@cisco.com> <87pr0ga6qj.fsf@mocca.josefsson.org> <tslhblsxkq6.fsf@mit.edu>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100529:hartmans-ietf@mit.edu::F+j98R89dn6nJfHo:Mz4
X-Hashcash: 1:22:100529:kitten@ietf.org::CJI+u10s6GusPlrC:2OXe
X-Hashcash: 1:22:100529:draft-wierenga-ietf-sasl-saml@tools.ietf.org::orf1k3cvzAFa7LqE:ASA0
X-Hashcash: 1:22:100529:moonshot-community@jiscmail.ac.uk::UyvNh3bc9Cecb50I:FPao
Date: Sat, 29 May 2010 11:34:49 +0200
In-Reply-To: <tslhblsxkq6.fsf@mit.edu> (Sam Hartman's message of "Fri, 28 May 2010 08:40:49 -0400")
Message-ID: <87k4qnxd8m.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 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 May 2010 09:35:22 -0000

Sam Hartman <hartmans-ietf@mit.edu> writes:

> Simon, I think the IDP may end up involved in the channel binding
> discussion because the client and server may happen not to have another
> mechanism for an integrity protected channel.  In cases where the client
> and server directly share a key or a key falls out of the SAML exchange,
> I agree with you, no IDP interaction is required.

Right.  I think there is some advantage in having a key fall out of a
SAML exchange, but it may also make a SAML SASL mechanism unnecessarily
complex.  I'm concerned that IDPs (and potentially other middle parties)
can see the TLS Finished messages for connections between clients and
servers though.

/Simon

From leifj@mnt.se  Mon May 31 00:30:29 2010
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7962D3A69D6 for <kitten@core3.amsl.com>; Mon, 31 May 2010 00:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Mw1gX21RuOBl for <kitten@core3.amsl.com>; Mon, 31 May 2010 00:30:17 -0700 (PDT)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id C77C43A68BD for <kitten@ietf.org>; Mon, 31 May 2010 00:30:14 -0700 (PDT)
Received: from [158.129.74.141] (wlan74-141.tnc2010.litnet.lt [158.129.74.141]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o4V7TuZH006389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Mon, 31 May 2010 09:29:59 +0200 (CEST)
Message-ID: <4C036574.8090201@mnt.se>
Date: Mon, 31 May 2010 09:29:56 +0200
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre
MIME-Version: 1.0
To: kitten@ietf.org
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com> <4BF2EAA2.2000600@secure-endpoints.com>
In-Reply-To: <4BF2EAA2.2000600@secure-endpoints.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2010 07:30:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I think the charter is fine but I too object to the name.
> Kitten was funny because the predecessor has the acronym of CAT.
> I don't think MOGGIES is funny. Perhaps if you figured out how to
> turn it into DOGGIES or PUPPIES.

Yeah MOGGIES sounds like a fetish of some kind...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwDZXMACgkQ8Jx8FtbMZncsTgCgqgclDZxuLFdjNm6qlSq4GWUm
XqYAn1jH1SpsKEJ3sFwJkeUWY8S+l1pn
=R39U
-----END PGP SIGNATURE-----

From leifj@mnt.se  Mon May 31 00:31:20 2010
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3045D3A6939 for <kitten@core3.amsl.com>; Mon, 31 May 2010 00:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_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 gZT59q+ZNEGD for <kitten@core3.amsl.com>; Mon, 31 May 2010 00:31:13 -0700 (PDT)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id E1CE63A69F3 for <kitten@ietf.org>; Mon, 31 May 2010 00:31:10 -0700 (PDT)
Received: from [158.129.74.141] (wlan74-141.tnc2010.litnet.lt [158.129.74.141]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o4V7UrcK018390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Mon, 31 May 2010 09:30:56 +0200 (CEST)
Message-ID: <4C0365AD.6070004@mnt.se>
Date: Mon, 31 May 2010 09:30:53 +0200
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre
MIME-Version: 1.0
To: kitten@ietf.org
Subject: Re: MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com>	<22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com>	<0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu>	<878w7gv1v4.fsf@mocca.josefsson.org> <1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net>
In-Reply-To: <1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2010 07:31:21 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> I would prefer something self-explanatory, like SASLGSS.
> 
> Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun.  

But what _is_ a moggy? Is it a feline?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwDZa0ACgkQ8Jx8FtbMZneFuACeKGksSTvG8fxMlPBD5wpWLiBF
3UAAn2bn0nlGH2upa1epZDZ+DcLjXlG/
=qxFJ
-----END PGP SIGNATURE-----
