From shawn.emery@oracle.com  Wed Nov  2 13:45:49 2011
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F0111E811F for <kitten@ietfa.amsl.com>; Wed,  2 Nov 2011 13:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK2zJ9KmTdRZ for <kitten@ietfa.amsl.com>; Wed,  2 Nov 2011 13:45:49 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4660B11E80BC for <kitten@ietf.org>; Wed,  2 Nov 2011 13:45:49 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA2KjlcM019921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Wed, 2 Nov 2011 20:45:48 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pA2KjlRi022240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Wed, 2 Nov 2011 20:45:47 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pA2KjgX9013519 for <kitten@ietf.org>; Wed, 2 Nov 2011 15:45:42 -0500
Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Nov 2011 13:45:42 -0700
Message-ID: <4EB1ABDA.2060602@oracle.com>
Date: Wed, 02 Nov 2011 14:45:14 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:7.0.1) Gecko/20111008 Thunderbird/7.0.1
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
Content-Type: multipart/alternative; boundary="------------010005040003080206080903"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EB1ABFC.00D0,ss=1,re=0.000,fgs=0
Subject: [kitten] IETF 82 Agenda
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 02 Nov 2011 20:45:49 -0000

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


Here is the draft agenda for the kitten session at IETF 82:

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

Please provide feed-back/additions no later than 11/717:00 PT.

Shawn.
--

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

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="+1"><tt><br>
        Here is the draft agenda for the kitten session at IETF 82:<br>
        <br>
        <a class="moz-txt-link-freetext" href="http://www.ietf.org/proceedings/82/agenda/kitten.txt">http://www.ietf.org/proceedings/82/agenda/kitten.txt</a><br>
        <br>
      </tt></font><small><font size="+1"><small><tt>Please provide
            feed-back/additions no later than 11/7</tt></small></font></small><tt>
      17:00 PT</tt><font size="+1"><tt>.</tt></font><font size="+1"><tt><br>
        <br>
        Shawn.<br>
        --<br>
      </tt></font>
  </body>
</html>

--------------010005040003080206080903--

From wmills@yahoo-inc.com  Wed Nov  2 16:13:17 2011
Return-Path: <wmills@yahoo-inc.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05EA1F0C36 for <kitten@ietfa.amsl.com>; Wed,  2 Nov 2011 16:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.154
X-Spam-Level: 
X-Spam-Status: No, score=-16.154 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OudG+kF4S15g for <kitten@ietfa.amsl.com>; Wed,  2 Nov 2011 16:13:17 -0700 (PDT)
Received: from nm38-vm5.bullet.mail.ne1.yahoo.com (nm38-vm5.bullet.mail.ne1.yahoo.com [98.138.229.149]) by ietfa.amsl.com (Postfix) with SMTP id 1BFBB21F9C20 for <kitten@ietf.org>; Wed,  2 Nov 2011 16:13:17 -0700 (PDT)
Received: from [98.138.90.55] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2011 23:13:11 -0000
Received: from [98.138.89.165] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2011 23:13:11 -0000
Received: from [127.0.0.1] by omp1021.mail.ne1.yahoo.com with NNFMP; 02 Nov 2011 23:13:11 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 650303.26294.bm@omp1021.mail.ne1.yahoo.com
Received: (qmail 62233 invoked by uid 60001); 2 Nov 2011 23:13:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1320275591; bh=nE9E0IcZxNqWXfSciD0FM13itIQb+PZ7xb8LF5T8MGk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WDazO3lQ2NROK7jZpWElW7bTlU0kw29x6SDp0euxZJO46zWXoSmknUDA7pJFKU2Y32drpZJXpyvJ1cCL+KDCtgoXbA6iy86zaWHEjKZ0jeIrDeJCEHmzPcm2Sohg0TRA8HyqFwYRQ5kYeY5C/Onw6N3V6JZs8OVwzbhaUabr9tU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=GY08tVebbpvLYVywOMW2Mud98R9rZK1dBKJhHyd9H1tSykJ1pdW91yr4c9bOJO5kkcH0XAalLI/S31YFwHHVvf0UFROh3MG/nbW8MkY/mSywEuF5d24qkkd1M7rt1DrIH0QPi+xYKrJ+GESawY03+zo6x0ZBbRqZ+FDwJA2WOKI=;
X-YMail-OSG: sEN.ulgVM1k68_yLl0.ilRQBCPIOzQ_aMW92c5bP0V.__vY WV4OcV6VFTw5YaU2o2IfmsLW_M_L6AoaSXXxcJu4Q1REsmq690oqAZ8YNdGa CbaUO_qv2.47MW_SOJ02wZ.PZzO3l02nMjlZwRRX4_mZ0lZcpLyd0mHVNDmv TSpYGhFAQ01JL6s8muUcK6152PwK2u.ZwoPt7YCgaIRU98IR3pd3UiFCnB5H CHfMUnJ0A4LmxH85p1KqUJxzvQYVlwr8shoamejEU8hsmbKVmrJJsQ9ho21H fIj_O4BAphuea5Qj94j7e5IdGnY59rMiMaQJJ07xDnH9vxXVmMy3E5e9wG9e zgT6PMW6Zxcj8rhpHcqCLaP1dOxCOIeqvsBdAcvDxijSR2eXTQumRUmc_V_e cei1CaZFzSwkR_jhekcLAx8Ighuv8_W6XhARQ
Received: from [209.131.62.113] by web31803.mail.mud.yahoo.com via HTTP; Wed, 02 Nov 2011 16:13:11 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.115.330114
References: <4EB1ABDA.2060602@oracle.com>
Message-ID: <1320275591.61647.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Wed, 2 Nov 2011 16:13:11 -0700 (PDT)
From: William Mills <wmills@yahoo-inc.com>
To: Shawn Emery <shawn.emery@oracle.com>, "kitten@ietf.org" <kitten@ietf.org>
In-Reply-To: <4EB1ABDA.2060602@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1536546416-1320275591=:61647"
Subject: Re: [kitten] IETF 82 Agenda
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills@yahoo-inc.com>
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 02 Nov 2011 23:13:17 -0000

--0-1536546416-1320275591=:61647
Content-Type: text/plain; charset=us-ascii

I won't be able to attend in person, will there be any kind of teleconference?



________________________________
From: Shawn Emery <shawn.emery@oracle.com>
To: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, November 2, 2011 1:45 PM
Subject: [kitten] IETF 82 Agenda



Here is the draft agenda for the kitten session at IETF 82:

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

Please provide feed-back/additions no later than 11/717:00 PT.

Shawn.
--
 
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
--0-1536546416-1320275591=:61647
Content-Type: text/html; charset=us-ascii

<html><body><div style="color:#000; background-color:#fff; font-family:Courier New, courier, monaco, monospace, sans-serif;font-size:12pt"><div><span>I won't be able to attend in person, will there be any kind of teleconference?<br></span></div><div><br></div><div style="font-family: Courier New, courier, monaco, monospace, sans-serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font face="Arial" size="2"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Shawn Emery &lt;shawn.emery@oracle.com&gt;<br><b><span style="font-weight: bold;">To:</span></b> "kitten@ietf.org" &lt;kitten@ietf.org&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Wednesday, November 2, 2011 1:45 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [kitten] IETF 82 Agenda<br></font><br>
<div id="yiv2055378850">
  

    
  
  <div>
    <font size="+1"><tt><br>
        Here is the draft agenda for the kitten session at IETF 82:<br>
        <br>
        http://www.ietf.org/proceedings/82/agenda/kitten.txt<br>
        <br>
      </tt></font><small><font size="+1"><small><tt>Please provide
            feed-back/additions no later than 11/7</tt></small></font></small><tt>
      17:00 PT</tt><font size="+1"><tt>.</tt></font><font size="+1"><tt><br>
        <br>
        Shawn.<br>
        --<br>
      </tt></font>
  </div>

</div><br>_______________________________________________<br>Kitten mailing list<br><a ymailto="mailto:Kitten@ietf.org" href="mailto:Kitten@ietf.org">Kitten@ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/kitten" target="_blank">https://www.ietf.org/mailman/listinfo/kitten</a><br><br><br></div></div></div></body></html>
--0-1536546416-1320275591=:61647--

From leifj@mnt.se  Sat Nov 12 18:12:31 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93B421F8483 for <kitten@ietfa.amsl.com>; Sat, 12 Nov 2011 18:12:31 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSOXYak7d1Iq for <kitten@ietfa.amsl.com>; Sat, 12 Nov 2011 18:12:31 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id BD84621F8482 for <kitten@ietf.org>; Sat, 12 Nov 2011 18:12:29 -0800 (PST)
Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAD2CJWM004042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 03:12:26 +0100 (CET)
Message-ID: <4EBF2782.9060906@mnt.se>
Date: Sun, 13 Nov 2011 03:12:18 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Cantor, Scott" <cantor.2@osu.edu>
References: <CACEE4A0.18488%cantor.2@osu.edu>
In-Reply-To: <CACEE4A0.18488%cantor.2@osu.edu>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Nov 2011 02:12:31 -0000

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

On 10/27/2011 04:38 PM, Cantor, Scott wrote:
> On 10/27/11 3:10 AM, "Leif Johansson" <leifj@mnt.se> wrote:
>> 
>> Why not simply say
>> 
>> "This is analogous to the SAML 
>> urn:oasis:names:tc:SAML:2.0:nameid-format:persistent NameID
>> format and has comparable security and privacy properties and
>> implications."
> 
> Obviously that's the "fix", but I think that's confusing in
> context because that format is about much more than uniqueness, and
> I think all you're trying to say in that sentence is that the
> naming attributes might themselves provide a unique (possibly
> omnidirectional) identifier. In other words, any SAML attribute of
> NameID might end up in there and be used for that purpose, not just
> (or even predominantly) that one.
> 
>> I give you that you could (and might want to) include much more
>> detail to make this a really understandable example wo prior SAML
>> knowledge but nevertheless I believe it would be good to have
>> something on this important topic.
> 
> I think I'd avoid the SAML reference, then, and just state
> something more general. Or I'd use more than one SAML example,
> because you don't just mean a directed ID here.

Could you give me a sample of text to use as a second example?

	Cheers Leif

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

iEYEARECAAYFAk6/J34ACgkQ8Jx8FtbMZnerzACgrjlE6+gpef7U0hMKcyVfbeL1
IxsAoKBzNvJoLt5dLCEJFGNQP99sIKyx
=vjIM
-----END PGP SIGNATURE-----

From leifj@mnt.se  Sat Nov 12 18:17:33 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81C21F84A6 for <kitten@ietfa.amsl.com>; Sat, 12 Nov 2011 18:17:33 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pavCpbyPtX6p for <kitten@ietfa.amsl.com>; Sat, 12 Nov 2011 18:17:32 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4655A21F84A2 for <kitten@ietf.org>; Sat, 12 Nov 2011 18:17:32 -0800 (PST)
Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAD2HKJg021415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 03:17:26 +0100 (CET)
Message-ID: <4EBF28AF.5020200@mnt.se>
Date: Sun, 13 Nov 2011 03:17:19 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com>
In-Reply-To: <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org
Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Nov 2011 02:17:33 -0000

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

On 10/27/2011 05:18 PM, Nico Williams wrote:
> On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson <leifj@mnt.se>
> wrote:
>>> GSS_Set_name_attribute() MAY succeed even though a credential
>>> acquired with the resulting NAME may not actually result in a
>>> peer seeing the given attribute.  If it is critical that the
>>> attribute be asserted in subsequent security context
>>> establishments, then the caller must inquire the NAME for any 
>>> CREDENTIAL HANDLE acquired with this NAME and then check that
>>> the requested attribute has indeed been set in the CREDENTIAL
>>> HANDLE's NAME.
>> 


So it sounds like there is consensus for Nicos proposal.

Do you want to call this now Shawn or should I bring it up at the
mic and re-confirm?

In either case I can have a version out as soon as Scotts issue
on persistent NameID has been resolved.

We should start a WGLC on that version asap.

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

iEYEARECAAYFAk6/KK8ACgkQ8Jx8FtbMZneMNgCgjjDDhXTALUXchi+BQM4enrf1
XRkAoKEs31mnOZ3ywL151rz3+g2DIwQB
=0Rdl
-----END PGP SIGNATURE-----

From stephen.farrell@cs.tcd.ie  Sat Nov 12 18:28:04 2011
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580D211E8091 for <kitten@ietfa.amsl.com>; Sat, 12 Nov 2011 18:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLWSk83A+hV7 for <kitten@ietfa.amsl.com>; Sat, 12 Nov 2011 18:28:03 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69911E8090 for <kitten@ietf.org>; Sat, 12 Nov 2011 18:28:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D0B31171C8B; Sun, 13 Nov 2011 02:28:01 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1321151281; bh=F59y4pjinaD8e7 nVKOqrTVayyz0GLugQiV7BJ0YjNzk=; b=4/4iLExWFkxNpXblCvDgELrRm0ZRJ2 p7gqwo/kaJEO/Ht3V0ey72sSD2+gNv5i/meR9S4YwOQS2SsS+w/mI9YZTjbroSBm KX0DX2WQ0r76k0l/0sLEcpR92S6vDuvDaYa0omFduafECirZnfrvZnN5uiQ7Wdyv 5z5C0GfJGybpfwqPVmRCalRKCI6M4MBAghCdZlCefaIGMAlF7BuXK9r3p8dlVeKO AukJpYbAAIMJsgu8PxUZgJUD6ZlYxrzFm9Zs1jNZiTdC1U2dGTTwyT54h6JaLnuU F23/bq994MMxxn9ESQsmhQmbh4UnJNQEtovxamfI1ZtYTbvG7zOjFQWQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id W8aebQFzEm6N; Sun, 13 Nov 2011 02:28:01 +0000 (GMT)
Received: from [130.129.103.171] (dhcp-67ab.meeting.ietf.org [130.129.103.171]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B875F171C51; Sun, 13 Nov 2011 02:27:58 +0000 (GMT)
Message-ID: <4EBF2B2A.8000602@cs.tcd.ie>
Date: Sun, 13 Nov 2011 02:27:54 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <4DEF26FE.5070904__4175.18786057389$1307518736$gmane$org@cs.tcd.ie> <87d3ioycn4.fsf@latte.josefsson.org> <4DEF48C0.3000508@cs.tcd.ie>
In-Reply-To: <4DEF48C0.3000508@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>
Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Nov 2011 02:28:04 -0000

Folks,

Not being on the top of anyone's list, this doesn't
seem to have progressed since June.

Can we resolve this on the list or at this week's
meeting?

Thanks,
S.

On 06/08/2011 11:02 AM, Stephen Farrell wrote:
>
>
> On 08/06/11 09:02, Simon Josefsson wrote:
>> Stephen Farrell<stephen.farrell@cs.tcd.ie>  writes:
>>
>>> Hi all,
>>>
>>> Can you confirm that this is correct, or not?
>>
>> I think we could use some more discussion before approving this -- for
>> example, what impact does this have on existing implementations?
>
> Good point. I'm fine with waiting for the WG to give me the
> answer that I'll cut'n'paste into the errata tool:-) Sooner
> is of course better for that.
>
> Thanks,
> S.
>
>>
>> I will try to change my implementation to use 255 instead of 0 and see
>> if it still works and inteoperates with my old version.  It would be
>> useful if others could do similar experiments.  I don't expect serious
>> problems, but I think we should consider the impact before approving
>> this.
>>
>> I do agree it is a bug in the specification though.
>>
>> /Simon
>>
>>> Thanks,
>>> S.
>>>
>>> -------- Original Message --------
>>> Subject: [Technical Errata Reported] RFC5801 (2825)
>>> Date: Tue,  7 Jun 2011 20:58:20 -0700 (PDT)
>>> From: RFC Errata System<rfc-editor@rfc-editor.org>
>>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,
>>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,
>>> kurt.zeilenga@isode.com
>>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org
>>>
>>>
>>> The following errata report has been submitted for RFC5801,
>>> "Using Generic Security Service Application Program Interface (GSS-API)
>>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
>>> Mechanism Family".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Thomas Maslen<thomas.maslen@quest.com>
>>>
>>> Section: 5.1
>>>
>>> Original Text
>>> -------------
>>> The initiator-address-type and acceptor-address-type fields of the
>>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.
>>>
>>>
>>> Corrected Text
>>> --------------
>>> The initiator-address-type and acceptor-address-type fields of the
>>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).
>>>
>>>
>>> Notes
>>> -----
>>> See RFC 2744, section 3.11, last paragraph:  "[...] or omit addressing
>>> information, specifying GSS_C_AF_NULLADDR as the address-types".
>>>
>>> Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255.
>>>
>>> Instructions:
>>> -------------
>>> This errata is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --------------------------------------
>>> RFC5801 (draft-ietf-sasl-gs2-20)
>>> --------------------------------------
>>> Title               : Using Generic Security Service Application Program
>>> Interface (GSS-API) Mechanisms in Simple Authentication and Security
>>> Layer (SASL): The GS2 Mechanism Family
>>> Publication Date    : July 2010
>>> Author(s)           : S. Josefsson, N. Williams
>>> Category            : PROPOSED STANDARD
>>> Source              : Simple Authentication and Security Layer
>>> Area                : Security
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>

From cantor.2@osu.edu  Sun Nov 13 12:22:16 2011
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3549921F8B72 for <kitten@ietfa.amsl.com>; Sun, 13 Nov 2011 12:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.642
X-Spam-Level: 
X-Spam-Status: No, score=-3.642 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRii69igupTT for <kitten@ietfa.amsl.com>; Sun, 13 Nov 2011 12:22:15 -0800 (PST)
Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by ietfa.amsl.com (Postfix) with ESMTP id 51FD921F84AF for <kitten@ietf.org>; Sun, 13 Nov 2011 12:22:13 -0800 (PST)
Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pADKMAGV013838; Sun, 13 Nov 2011 15:22:11 -0500
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Sun, 13 Nov 2011 15:22:10 -0500
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Leif Johansson <leifj@mnt.se>
Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt
Thread-Index: AQHMGk9ePlGRzA45C0OMSYHcBxvktpWP5aMAgAEXv4CAADo1gIAaOvIAgADcrwA=
Date: Sun, 13 Nov 2011 20:22:10 +0000
Message-ID: <CAE58F15.19642%cantor.2@osu.edu>
In-Reply-To: <4EBF2782.9060906@mnt.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31a9e779-d00e-428f-aa75-14ec107ae552>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.40; 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: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Nov 2011 20:22:16 -0000

On 11/12/11 9:12 PM, "Leif Johansson" <leifj@mnt.se> wrote:
>>I think I'd avoid the SAML reference, then, and just state
>> something more general. Or I'd use more than one SAML example,
>> because you don't just mean a directed ID here.
>
>Could you give me a sample of text to use as a second example?

"When the underlying security mechanism does not provide a permanent
unique identity (e.g., anonymous kerberos), GSS-API naming extensions may
be used to provide a permanent unique identity attribute. This may be a
globally unique identifier, a value unique within the namespace of the
attribute issuer, or a "directed" identifier that is unique per peer
acceptor identity.

SAML, to use one example technology, offers a number of built-in
constructs for this purpose, such as a <NameID> with a Format of
"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". SAML deployments
also typically make use of domain-specific attribute types that can serve
as identifiers."

I think the second paragraph is entirely optional, but if you want an
example, that's what I'd suggest.

-- Scott


From leifj@mnt.se  Sun Nov 13 17:30:07 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F8421F87D9 for <kitten@ietfa.amsl.com>; Sun, 13 Nov 2011 17:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.166
X-Spam-Level: 
X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ4Itfvr+Jgs for <kitten@ietfa.amsl.com>; Sun, 13 Nov 2011 17:30:06 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id F20CC21F87D3 for <kitten@ietf.org>; Sun, 13 Nov 2011 17:30:05 -0800 (PST)
Received: from [130.129.17.132] (dhcp-1184.meeting.ietf.org [130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAE1Tuco009889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 02:30:02 +0100 (CET)
Message-ID: <4EC06F13.90709@mnt.se>
Date: Mon, 14 Nov 2011 02:29:55 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Cantor, Scott" <cantor.2@osu.edu>
References: <CAE58F15.19642%cantor.2@osu.edu>
In-Reply-To: <CAE58F15.19642%cantor.2@osu.edu>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Nov 2011 01:30:07 -0000

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

On 11/13/2011 09:22 PM, Cantor, Scott wrote:
> On 11/12/11 9:12 PM, "Leif Johansson" <leifj@mnt.se> wrote:
>>> I think I'd avoid the SAML reference, then, and just state 
>>> something more general. Or I'd use more than one SAML example, 
>>> because you don't just mean a directed ID here.
>> 
>> Could you give me a sample of text to use as a second example?
> 
> "When the underlying security mechanism does not provide a
> permanent unique identity (e.g., anonymous kerberos), GSS-API
> naming extensions may be used to provide a permanent unique
> identity attribute. This may be a globally unique identifier, a
> value unique within the namespace of the attribute issuer, or a
> "directed" identifier that is unique per peer acceptor identity.
> 
> SAML, to use one example technology, offers a number of built-in 
> constructs for this purpose, such as a <NameID> with a Format of 
> "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". SAML
> deployments also typically make use of domain-specific attribute
> types that can serve as identifiers."
> 
> I think the second paragraph is entirely optional, but if you want
> an example, that's what I'd suggest.
> 
> -- Scott
> 

I assume you meant for this to replace the paragraph in question -
this sounds good to me.

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

iEYEARECAAYFAk7AbxMACgkQ8Jx8FtbMZneUJwCdFb/NN4pCStbE1SiNqC5e54wk
hI4AnA6o/psMRpVyOvZYotqa7yhXoYM7
=yDdS
-----END PGP SIGNATURE-----

From shawn.emery@oracle.com  Sun Nov 13 18:13:44 2011
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9F411E8087 for <kitten@ietfa.amsl.com>; Sun, 13 Nov 2011 18:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWbXiwzISmHf for <kitten@ietfa.amsl.com>; Sun, 13 Nov 2011 18:13:44 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id DC0E611E80AE for <kitten@ietf.org>; Sun, 13 Nov 2011 18:13:43 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAE2DgWH027664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Mon, 14 Nov 2011 02:13:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAE2DffB006051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Mon, 14 Nov 2011 02:13:42 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAE2DaEg009977 for <kitten@ietf.org>; Sun, 13 Nov 2011 20:13:36 -0600
Received: from dhcp-1599.meeting.ietf.org (/130.129.21.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Nov 2011 18:13:36 -0800
Message-ID: <4EC07933.70003@oracle.com>
Date: Sun, 13 Nov 2011 19:13:07 -0700
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: kitten@ietf.org
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se>
In-Reply-To: <4EBF28AF.5020200@mnt.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EC07957.0011,ss=1,re=0.000,fgs=0
Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Nov 2011 02:13:44 -0000

On 11/12/11 7:17 PM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2011 05:18 PM, Nico Williams wrote:
>> On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson<leifj@mnt.se>
>> wrote:
>>>> GSS_Set_name_attribute() MAY succeed even though a credential
>>>> acquired with the resulting NAME may not actually result in a
>>>> peer seeing the given attribute.  If it is critical that the
>>>> attribute be asserted in subsequent security context
>>>> establishments, then the caller must inquire the NAME for any
>>>> CREDENTIAL HANDLE acquired with this NAME and then check that
>>>> the requested attribute has indeed been set in the CREDENTIAL
>>>> HANDLE's NAME.
>
> So it sounds like there is consensus for Nicos proposal.
>
> Do you want to call this now Shawn or should I bring it up at the
> mic and re-confirm?

Let's discuss this during the session and then make a consensus call to 
the list in case there are any new revelations made.

> In either case I can have a version out as soon as Scotts issue
> on persistent NameID has been resolved.

Thanks.

> We should start a WGLC on that version asap.

Agreed.

Shawn.
--

From internet-drafts@ietf.org  Sun Nov 13 21:41:17 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C698611E81C9; Sun, 13 Nov 2011 21:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level: 
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXnEOyRbBPlK; Sun, 13 Nov 2011 21:41:17 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330C211E8184; Sun, 13 Nov 2011 21:41:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.63
Message-ID: <20111114054117.28158.21707.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2011 21:41:17 -0800
Cc: kitten@ietf.org
Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-00.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Nov 2011 05:41:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Authentication Technology Next=
 Generation Working Group of the IETF.

	Title           : A SASL and GSS-API Mechanism for OAuth
	Author(s)       : William Mills
                          Tim Showalter
                          Hannes Tschofenig
	Filename        : draft-ietf-kitten-sasl-oauth-00.txt
	Pages           : 25
	Date            : 2011-11-13

   OAuth enables a third-party application to obtain limited access to a
   protected resource, either on behalf of a resource owner by
   orchestrating an approval interaction, or by allowing the third-party
   application to obtain access on its own behalf.

   This document defines how an application client uses OAuth over the
   Simple Authentication and Security Layer (SASL) or the Generic
   Security Service Application Program Interface (GSS-API) to access a
   protected resource at a resource serve, and additionally defines
   authorization and token issuing endpoint discovery.  Thereby, it
   enables schemes defined within the OAuth framework for non-HTTP-based
   application protocols.

   Clients typically store the user&#39;s long term credential.  This does,
   however, lead to significant security vulnerabilities, for example,
   when such a credential leaks.  A significant benefit of OAuth for
   usage in those clients is that the password is replaced by a token.
   Tokens typically provided limited access rights and can be managed
   and revoked separately from the user&#39;s long-term credential
   (password).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-00.txt

From shawn.emery@oracle.com  Mon Nov 14 00:03:27 2011
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDEC11E824C for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 00:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gISreY18pazH for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 00:03:22 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4C89111E80B5 for <kitten@ietf.org>; Mon, 14 Nov 2011 00:03:22 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAE83KIu014632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Mon, 14 Nov 2011 08:03:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAE83J2O020786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Mon, 14 Nov 2011 08:03:20 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAE83EVB018355 for <kitten@ietf.org>; Mon, 14 Nov 2011 02:03:14 -0600
Received: from dhcp-1599.meeting.ietf.org (/10.159.223.32) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Nov 2011 00:03:14 -0800
Message-ID: <4EC0CB2F.10706@oracle.com>
Date: Mon, 14 Nov 2011 01:02:55 -0700
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: kitten@ietf.org
References: <4DEF26FE.5070904__4175.18786057389$1307518736$gmane$org@cs.tcd.ie> <87d3ioycn4.fsf@latte.josefsson.org> <4DEF48C0.3000508@cs.tcd.ie> <4EBF2B2A.8000602@cs.tcd.ie>
In-Reply-To: <4EBF2B2A.8000602@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4EC0CB49.00DE,ss=1,re=0.000,fgs=0
Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Nov 2011 08:03:27 -0000

On 11/12/11 7:27 PM, Stephen Farrell wrote:
> Folks,
>
> Not being on the top of anyone's list, this doesn't
> seem to have progressed since June.
>
> Can we resolve this on the list or at this week's
> meeting?

Let's discuss this during the session.

Simon,

What was the result of your tests running against the updated version of 
GNU SASL?

Shawn.
--
> On 06/08/2011 11:02 AM, Stephen Farrell wrote:
>>
>>
>> On 08/06/11 09:02, Simon Josefsson wrote:
>>> Stephen Farrell<stephen.farrell@cs.tcd.ie>  writes:
>>>
>>>> Hi all,
>>>>
>>>> Can you confirm that this is correct, or not?
>>>
>>> I think we could use some more discussion before approving this -- for
>>> example, what impact does this have on existing implementations?
>>
>> Good point. I'm fine with waiting for the WG to give me the
>> answer that I'll cut'n'paste into the errata tool:-) Sooner
>> is of course better for that.
>>
>> Thanks,
>> S.
>>
>>>
>>> I will try to change my implementation to use 255 instead of 0 and see
>>> if it still works and inteoperates with my old version.  It would be
>>> useful if others could do similar experiments.  I don't expect serious
>>> problems, but I think we should consider the impact before approving
>>> this.
>>>
>>> I do agree it is a bug in the specification though.
>>>
>>> /Simon
>>>
>>>> Thanks,
>>>> S.
>>>>
>>>> -------- Original Message --------
>>>> Subject: [Technical Errata Reported] RFC5801 (2825)
>>>> Date: Tue,  7 Jun 2011 20:58:20 -0700 (PDT)
>>>> From: RFC Errata System<rfc-editor@rfc-editor.org>
>>>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,
>>>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,
>>>> kurt.zeilenga@isode.com
>>>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org
>>>>
>>>>
>>>> The following errata report has been submitted for RFC5801,
>>>> "Using Generic Security Service Application Program Interface 
>>>> (GSS-API)
>>>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
>>>> Mechanism Family".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Thomas Maslen<thomas.maslen@quest.com>
>>>>
>>>> Section: 5.1
>>>>
>>>> Original Text
>>>> -------------
>>>> The initiator-address-type and acceptor-address-type fields of the
>>>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.
>>>>
>>>>
>>>> Corrected Text
>>>> --------------
>>>> The initiator-address-type and acceptor-address-type fields of the
>>>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).
>>>>
>>>>
>>>> Notes
>>>> -----
>>>> See RFC 2744, section 3.11, last paragraph:  "[...] or omit addressing
>>>> information, specifying GSS_C_AF_NULLADDR as the address-types".
>>>>
>>>> Appendix A of RFC 2744 specifies that the value of 
>>>> GSS_C_AF_NULLADDR is 255.
>>>>
>>>> Instructions:
>>>> -------------
>>>> This errata is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>> can log in to change the status and edit the report, if necessary.
>>>>
>>>> --------------------------------------
>>>> RFC5801 (draft-ietf-sasl-gs2-20)
>>>> --------------------------------------
>>>> Title               : Using Generic Security Service Application 
>>>> Program
>>>> Interface (GSS-API) Mechanisms in Simple Authentication and Security
>>>> Layer (SASL): The GS2 Mechanism Family
>>>> Publication Date    : July 2010
>>>> Author(s)           : S. Josefsson, N. Williams
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Simple Authentication and Security Layer
>>>> Area                : Security
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>
>> _______________________________________________
>> Kitten mailing list
>> Kitten@ietf.org
>> https://www.ietf.org/mailman/listinfo/kitten
>>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten


From simon@josefsson.org  Mon Nov 14 01:17:45 2011
Return-Path: <simon@josefsson.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0321F844E for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 01:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.754
X-Spam-Level: 
X-Spam-Status: No, score=-101.754 tagged_above=-999 required=5 tests=[AWL=-1.845, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3DYmh1iBBHc for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 01:17:43 -0800 (PST)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6E11E21F8F10 for <kitten@ietf.org>; Mon, 14 Nov 2011 01:17:00 -0800 (PST)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAE9GYtj023689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Nov 2011 10:16:36 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Shawn M Emery <shawn.emery@oracle.com>
References: <4DEF26FE.5070904__4175.18786057389$1307518736$gmane$org@cs.tcd.ie> <87d3ioycn4.fsf@latte.josefsson.org> <4DEF48C0.3000508@cs.tcd.ie> <4EBF2B2A.8000602@cs.tcd.ie> <4EC0CB2F.10706__31780.7765132331$1321257821$gmane$org@oracle.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:111114:kitten@ietf.org::jlpot5ryvGglzZTA:BBdO
X-Hashcash: 1:22:111114:shawn.emery@oracle.com::ZvsyXEARCEIIuJUA:BhZ2
Date: Mon, 14 Nov 2011 10:16:34 +0100
In-Reply-To: <4EC0CB2F.10706__31780.7765132331$1321257821$gmane$org@oracle.com> (Shawn M. Emery's message of "Mon, 14 Nov 2011 01:02:55 -0700")
Message-ID: <874ny783nx.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org
Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Nov 2011 09:17:46 -0000

Shawn M Emery <shawn.emery@oracle.com> writes:

> On 11/12/11 7:27 PM, Stephen Farrell wrote:
>> Folks,
>>
>> Not being on the top of anyone's list, this doesn't
>> seem to have progressed since June.
>>
>> Can we resolve this on the list or at this week's
>> meeting?
>
> Let's discuss this during the session.
>
> Simon,
>
> What was the result of your tests running against the updated version
> of GNU SASL?

I must admit that I forgot about this.  GNU SASL still populate the
initiator-address-type and acceptor-address-type fields to 0.

Did any other implementers experiment with changing this?

I'm a bit uncertain how to test this properly, just modifying GNU SASL
to use 0 instead of 255 will likely work running against itself, but the
bigger question is probably if any interoperability between the old
variant and the new variant is affect, and if the choice of GSS-API
library has any bearing of the outcome.  Or even GS2 implementation.

I still agree that it is a bug in the specification though.  If you want
to see a resolution to this errata report now, I suggest to approve it
and we'll figure out if there are any interop issues later on.  You can
always update the errata later on if that turns out to be the case.

/Simon

> Shawn.
> --
>> On 06/08/2011 11:02 AM, Stephen Farrell wrote:
>>>
>>>
>>> On 08/06/11 09:02, Simon Josefsson wrote:
>>>> Stephen Farrell<stephen.farrell@cs.tcd.ie>  writes:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Can you confirm that this is correct, or not?
>>>>
>>>> I think we could use some more discussion before approving this -- for
>>>> example, what impact does this have on existing implementations?
>>>
>>> Good point. I'm fine with waiting for the WG to give me the
>>> answer that I'll cut'n'paste into the errata tool:-) Sooner
>>> is of course better for that.
>>>
>>> Thanks,
>>> S.
>>>
>>>>
>>>> I will try to change my implementation to use 255 instead of 0 and see
>>>> if it still works and inteoperates with my old version.  It would be
>>>> useful if others could do similar experiments.  I don't expect serious
>>>> problems, but I think we should consider the impact before approving
>>>> this.
>>>>
>>>> I do agree it is a bug in the specification though.
>>>>
>>>> /Simon
>>>>
>>>>> Thanks,
>>>>> S.
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [Technical Errata Reported] RFC5801 (2825)
>>>>> Date: Tue,  7 Jun 2011 20:58:20 -0700 (PDT)
>>>>> From: RFC Errata System<rfc-editor@rfc-editor.org>
>>>>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,
>>>>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,
>>>>> kurt.zeilenga@isode.com
>>>>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org
>>>>>
>>>>>
>>>>> The following errata report has been submitted for RFC5801,
>>>>> "Using Generic Security Service Application Program Interface
>>>>> (GSS-API)
>>>>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
>>>>> Mechanism Family".
>>>>>
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825
>>>>>
>>>>> --------------------------------------
>>>>> Type: Technical
>>>>> Reported by: Thomas Maslen<thomas.maslen@quest.com>
>>>>>
>>>>> Section: 5.1
>>>>>
>>>>> Original Text
>>>>> -------------
>>>>> The initiator-address-type and acceptor-address-type fields of the
>>>>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.
>>>>>
>>>>>
>>>>> Corrected Text
>>>>> --------------
>>>>> The initiator-address-type and acceptor-address-type fields of the
>>>>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).
>>>>>
>>>>>
>>>>> Notes
>>>>> -----
>>>>> See RFC 2744, section 3.11, last paragraph:  "[...] or omit addressing
>>>>> information, specifying GSS_C_AF_NULLADDR as the address-types".
>>>>>
>>>>> Appendix A of RFC 2744 specifies that the value of
>>>>> GSS_C_AF_NULLADDR is 255.
>>>>>
>>>>> Instructions:
>>>>> -------------
>>>>> This errata is currently posted as "Reported". If necessary, please
>>>>> use "Reply All" to discuss whether it should be verified or
>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>> can log in to change the status and edit the report, if necessary.
>>>>>
>>>>> --------------------------------------
>>>>> RFC5801 (draft-ietf-sasl-gs2-20)
>>>>> --------------------------------------
>>>>> Title               : Using Generic Security Service Application
>>>>> Program
>>>>> Interface (GSS-API) Mechanisms in Simple Authentication and Security
>>>>> Layer (SASL): The GS2 Mechanism Family
>>>>> Publication Date    : July 2010
>>>>> Author(s)           : S. Josefsson, N. Williams
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Simple Authentication and Security Layer
>>>>> Area                : Security
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>>>
>>> _______________________________________________
>>> Kitten mailing list
>>> Kitten@ietf.org
>>> https://www.ietf.org/mailman/listinfo/kitten
>>>
>> _______________________________________________
>> Kitten mailing list
>> Kitten@ietf.org
>> https://www.ietf.org/mailman/listinfo/kitten

From mrex@sap.com  Mon Nov 14 08:12:39 2011
Return-Path: <mrex@sap.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140521F0C82 for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 08:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.116
X-Spam-Level: 
X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbUeHbmspLGe for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 08:12:38 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC01F0C55 for <kitten@ietf.org>; Mon, 14 Nov 2011 08:12:37 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAEGCWLd022366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2011 17:12:32 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201111141612.pAEGCVL0007860@fs4113.wdf.sap.corp>
To: stephen.farrell@cs.tcd.ie (Stephen Farrell)
Date: Mon, 14 Nov 2011 17:12:31 +0100 (MET)
In-Reply-To: <4EBF2B2A.8000602@cs.tcd.ie> from "Stephen Farrell" at Nov 13, 11 02:27:54 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: kitten@ietf.org, simon@josefsson.org
Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Nov 2011 16:12:39 -0000

Stephen Farrell wrote:
> 
> Not being on the top of anyone's list, this doesn't
> seem to have progressed since June.
> 
> Can we resolve this on the list or at this week's
> meeting?

I think we stopped here:
http://www.ietf.org/mail-archive/web/kitten/current/msg02688.html

While GSS_C_AF_NULLADDR(255) would be undoubtedly the correct tag with
respect to the original GSS-API spec, we seem to have an installed
base which didn't follow the spec.


-Martin


> On 06/08/2011 11:02 AM, Stephen Farrell wrote:
> >
> >
> > On 08/06/11 09:02, Simon Josefsson wrote:
> >> Stephen Farrell<stephen.farrell@cs.tcd.ie>  writes:
> >>
> >>> Hi all,
> >>>
> >>> Can you confirm that this is correct, or not?
> >>
> >> I think we could use some more discussion before approving this -- for
> >> example, what impact does this have on existing implementations?
> >
> > Good point. I'm fine with waiting for the WG to give me the
> > answer that I'll cut'n'paste into the errata tool:-) Sooner
> > is of course better for that.
> >
> > Thanks,
> > S.
> >
> >>
> >> I will try to change my implementation to use 255 instead of 0 and see
> >> if it still works and inteoperates with my old version.  It would be
> >> useful if others could do similar experiments.  I don't expect serious
> >> problems, but I think we should consider the impact before approving
> >> this.
> >>
> >> I do agree it is a bug in the specification though.
> >>
> >> /Simon
> >>
> >>> Thanks,
> >>> S.
> >>>
> >>> -------- Original Message --------
> >>> Subject: [Technical Errata Reported] RFC5801 (2825)
> >>> Date: Tue,  7 Jun 2011 20:58:20 -0700 (PDT)
> >>> From: RFC Errata System<rfc-editor@rfc-editor.org>
> >>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,
> >>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,
> >>> kurt.zeilenga@isode.com
> >>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org
> >>>
> >>>
> >>> The following errata report has been submitted for RFC5801,
> >>> "Using Generic Security Service Application Program Interface (GSS-API)
> >>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
> >>> Mechanism Family".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825
> >>>
> >>> --------------------------------------
> >>> Type: Technical
> >>> Reported by: Thomas Maslen<thomas.maslen@quest.com>
> >>>
> >>> Section: 5.1
> >>>
> >>> Original Text
> >>> -------------
> >>> The initiator-address-type and acceptor-address-type fields of the
> >>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.
> >>>
> >>>
> >>> Corrected Text
> >>> --------------
> >>> The initiator-address-type and acceptor-address-type fields of the
> >>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).
> >>>
> >>>
> >>> Notes
> >>> -----
> >>> See RFC 2744, section 3.11, last paragraph:  "[...] or omit addressing
> >>> information, specifying GSS_C_AF_NULLADDR as the address-types".
> >>>
> >>> Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255.
> >>>
> >>> Instructions:
> >>> -------------
> >>> This errata is currently posted as "Reported". If necessary, please
> >>> use "Reply All" to discuss whether it should be verified or
> >>> rejected. When a decision is reached, the verifying party (IESG)
> >>> can log in to change the status and edit the report, if necessary.
> >>>
> >>> --------------------------------------
> >>> RFC5801 (draft-ietf-sasl-gs2-20)
> >>> --------------------------------------
> >>> Title               : Using Generic Security Service Application Program
> >>> Interface (GSS-API) Mechanisms in Simple Authentication and Security
> >>> Layer (SASL): The GS2 Mechanism Family
> >>> Publication Date    : July 2010
> >>> Author(s)           : S. Josefsson, N. Williams
> >>> Category            : PROPOSED STANDARD
> >>> Source              : Simple Authentication and Security Layer
> >>> Area                : Security
> >>> Stream              : IETF
> >>> Verifying Party     : IESG
> >>
> > _______________________________________________
> > Kitten mailing list
> > Kitten@ietf.org
> > https://www.ietf.org/mailman/listinfo/kitten
> >
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
> 


From cantor.2@osu.edu  Mon Nov 14 19:02:39 2011
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922671F0D85 for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 19:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.639
X-Spam-Level: 
X-Spam-Status: No, score=-3.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYJVj+uhxdmI for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 19:02:36 -0800 (PST)
Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id A952F1F0D8B for <kitten@ietf.org>; Mon, 14 Nov 2011 19:02:09 -0800 (PST)
Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id pAF3262K001444; Mon, 14 Nov 2011 22:02:07 -0500
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Mon, 14 Nov 2011 22:02:49 -0500
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Shawn Emery <shawn.emery@oracle.com>, "kitten@ietf.org" <kitten@ietf.org>
Thread-Topic: [kitten] IETF 82 Agenda
Thread-Index: AQHMmaCbe938WS8zhUeFqPpqzGiSFpWtUtKA
Date: Tue, 15 Nov 2011 03:02:41 +0000
Message-ID: <CAE73DCA.1267F%cantor.2@osu.edu>
In-Reply-To: <4EB1ABDA.2060602@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5f231356-dfd4-426a-bf53-7761a1977636>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6
X-CanItPRO-Stream: outbound
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133
Subject: Re: [kitten] IETF 82 Agenda
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Nov 2011 03:02:40 -0000

I'm not going to make a 4:00am EST meeting, sorry. ;-)

I believe I've covered the SAML-EC status before, but for the record:

Draft, and the OASIS dependencies, are stable and need implementation
experience to polish and find problems. IETF draft depends on a couple of
OASIS docs, and OASIS process is now so backlogged that I'm not planning
to advance them there until the bugs are worked out.

I have a TODO to review Sam's latest GSS naming draft for SAML in ABFAB
(http://tools.ietf.org/wg/abfab/draft-ietf-abfab-gss-eap-naming/) and
hopefully use that for SAML-EC as well. Hoping to get to that this week.

I have a potential implementer to work with on a SAML-EC project, waiting
for that to get funded and move forward (or not). Timeframe is 2Q 2012 as
best I can tell.

Other outstanding TBD is to try and get support for per-message tokens
added to the draft. This is something I probably can't do securely without
some expert help; it means defining a key derivation process based on a
key passed to the client and acceptor by the IdP. I will try and sketch
something and send to list as a starting point.

-- Scott


From zhou.sujing@zte.com.cn  Mon Nov 14 22:27:23 2011
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBFF1F0CBB for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 22:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.349
X-Spam-Level: 
X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34gWCiDmaNf9 for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 22:27:23 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3F1F0C5B for <kitten@ietf.org>; Mon, 14 Nov 2011 22:27:22 -0800 (PST)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690817445859; Tue, 15 Nov 2011 14:15:56 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 18185.817445859; Tue, 15 Nov 2011 14:27:02 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAF6QwGU056052 for <kitten@ietf.org>; Tue, 15 Nov 2011 14:26:58 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
To: kitten@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF33B92730.1DC4643E-ON48257949.00234E4D-48257949.00236EFC@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Tue, 15 Nov 2011 14:26:55 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-15 14:27:00, Serialize complete at 2011-11-15 14:27:00
Content-Type: multipart/alternative; boundary="=_alternative 00236EFB48257949_="
X-MAIL: mse02.zte.com.cn pAF6QwGU056052
Subject: [kitten] Is Meetecho available for the meeting at today afternoon in this WG?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Nov 2011 06:29:46 -0000

This is a multipart message in MIME format.
--=_alternative 00236EFB48257949_=
Content-Type: text/plain; charset="US-ASCII"

Best regards!
Sujing Zhou
======================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--=_alternative 00236EFB48257949_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
Best regards!<br>
Sujing Zhou<br>
======================================</font><br><pre>
--------------------------------------------------------
ZTE&nbsp;Information&nbsp;Security&nbsp;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;organization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nbsp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&nbsp;to&nbsp;others.
This&nbsp;email&nbsp;and&nbsp;any&nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nbsp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;the&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;email&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp;sender.
This&nbsp;message&nbsp;has&nbsp;been&nbsp;scanned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Spam&nbsp;system.
</pre>
--=_alternative 00236EFB48257949_=--


From shawn.emery@oracle.com  Mon Nov 14 23:37:32 2011
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE511E8096 for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 23:37:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFzsy-fwerlw for <kitten@ietfa.amsl.com>; Mon, 14 Nov 2011 23:37:31 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id B61A611E8094 for <kitten@ietf.org>; Mon, 14 Nov 2011 23:37:31 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAF7bUQ4023133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2011 07:37:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAF7bTIK027421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2011 07:37:29 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAF7bO4C023934; Tue, 15 Nov 2011 01:37:24 -0600
Received: from dhcp-1599.meeting.ietf.org (/130.129.21.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Nov 2011 23:37:24 -0800
Message-ID: <4EC216B2.9030401@oracle.com>
Date: Tue, 15 Nov 2011 00:37:22 -0700
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: zhou.sujing@zte.com.cn
References: <OF33B92730.1DC4643E-ON48257949.00234E4D-48257949.00236EFC@zte.com.cn>
In-Reply-To: <OF33B92730.1DC4643E-ON48257949.00234E4D-48257949.00236EFC@zte.com.cn>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EC216BB.0011,ss=1,re=0.000,fgs=0
Cc: kitten@ietf.org
Subject: Re: [kitten] Is Meetecho available for the meeting at today afternoon in this WG?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Nov 2011 07:37:32 -0000

Meetecho will not be available for the Taipei session as it requires 
submitting a request not on the same day of the session.  If you would 
like to see this tested in a future meeting then I would not have any 
objections.

Shawn.
kitten co-chair
--
On 11/14/11 11:26 PM, zhou.sujing@zte.com.cn wrote:
>
>
> Best regards!
> Sujing Zhou
> ======================================
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten


From leifj@mnt.se  Tue Nov 15 01:29:36 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92921F8FC4 for <kitten@ietfa.amsl.com>; Tue, 15 Nov 2011 01:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level: 
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHR6Nl1teIWl for <kitten@ietfa.amsl.com>; Tue, 15 Nov 2011 01:29:35 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAC721F8FC6 for <kitten@ietf.org>; Tue, 15 Nov 2011 01:29:34 -0800 (PST)
Received: from [130.129.17.132] (dhcp-1184.meeting.ietf.org [130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAF9TOWO008788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Tue, 15 Nov 2011 10:29:33 +0100 (CET)
Message-ID: <4EC230F2.6000508@mnt.se>
Date: Tue, 15 Nov 2011 10:29:22 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: kitten@ietf.org
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com>
In-Reply-To: <4EC07933.70003@oracle.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Nov 2011 09:29:36 -0000

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



Sam and me talked this over yesterday and we realized that we've
been talking about two different things and that both proposals
that have been discussed make sense.

We've been talking about unknown attributes in the sense that
no mechanism has knowledge of or supports the attribute type.
We are also talking about criticality in the sense that you
need to know for sure that an attribute has been set.

We propose to keep the current text that sais that an error
must be returned for unknown attributes *and* add the text
that Nico proposed that sais that if you care you must verify.

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

iEYEARECAAYFAk7CMPEACgkQ8Jx8FtbMZncIygCfe9SSCtMKsZBSQ8wGY1cu4xa4
9LEAn2MUy7imj9cW6Rx504dehs91bAI1
=J2oW
-----END PGP SIGNATURE-----

From leifj@mnt.se  Tue Nov 15 18:52:17 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D6E11E81D4 for <kitten@ietfa.amsl.com>; Tue, 15 Nov 2011 18:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpUhOWdcjNzW for <kitten@ietfa.amsl.com>; Tue, 15 Nov 2011 18:52:11 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4811E81D0 for <kitten@ietf.org>; Tue, 15 Nov 2011 18:52:11 -0800 (PST)
Received: from [130.129.17.132] (dhcp-1184.meeting.ietf.org [130.129.17.132]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAG2q29n018369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Wed, 16 Nov 2011 03:52:08 +0100 (CET)
Message-ID: <4EC32551.20906@mnt.se>
Date: Wed, 16 Nov 2011 03:52:01 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: kitten@ietf.org
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com>
In-Reply-To: <4EC07933.70003@oracle.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Nov 2011 02:52:17 -0000

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

On 11/14/2011 03:13 AM, Shawn M Emery wrote:
> On 11/12/11 7:17 PM, Leif Johansson wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 10/27/2011 05:18 PM, Nico Williams wrote:
>>> On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson<leifj@mnt.se> 
>>> wrote:
>>>>> GSS_Set_name_attribute() MAY succeed even though a
>>>>> credential acquired with the resulting NAME may not
>>>>> actually result in a peer seeing the given attribute.  If
>>>>> it is critical that the attribute be asserted in subsequent
>>>>> security context establishments, then the caller must
>>>>> inquire the NAME for any CREDENTIAL HANDLE acquired with
>>>>> this NAME and then check that the requested attribute has
>>>>> indeed been set in the CREDENTIAL HANDLE's NAME.
>> 
>> So it sounds like there is consensus for Nicos proposal.
>> 
>> Do you want to call this now Shawn or should I bring it up at
>> the mic and re-confirm?
> 
> Let's discuss this during the session and then make a consensus
> call to the list in case there are any new revelations made.
> 


Expanding on my note from yesterday - here is suggested text for
section 7.6 (just after the list of error codes):

"If the attribute NAME is not know or could not be set an error of
GSS_S_UNAVAILABLE SHOULD be returned however GSS_Set_name_attribute()
MAY succeed even though a credential acquired with the resulting NAME
may not actually result in a peer seeing the given attribute. If it is
critical that the attribute be asserted in subsequent security context
establishments, then the caller must inquire the NAME for any
CREDENTIAL HANDLE acquired with this NAME and then check that the
requested attribute has indeed been set in the CREDENTIAL HANDLE's NAME."

If I can get a consensus for that I can issue 12 and Shawn can start
the (final?) WGLC.

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

iEYEARECAAYFAk7DJVEACgkQ8Jx8FtbMZnebZQCeKmpSyvgj/SbXD84Aedr7emBU
F4sAoKkfU2RHXP3VAppn+yOuAQJB0Dwd
=pp27
-----END PGP SIGNATURE-----

From leifj@mnt.se  Wed Nov 16 17:58:09 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728FA1F0C44 for <kitten@ietfa.amsl.com>; Wed, 16 Nov 2011 17:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liFRuMggghDL for <kitten@ietfa.amsl.com>; Wed, 16 Nov 2011 17:58:08 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 742731F0C64 for <kitten@ietf.org>; Wed, 16 Nov 2011 17:58:08 -0800 (PST)
Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAH1vvV1012727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 02:58:06 +0100 (CET)
Message-ID: <4EC46A24.1000702@mnt.se>
Date: Thu, 17 Nov 2011 02:57:56 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>, "kitten@ietf.org" <kitten@ietf.org>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EC3274D.2000103@isode.com>
In-Reply-To: <4EC3274D.2000103@isode.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 01:58:09 -0000

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

On 11/16/2011 04:00 AM, Alexey Melnikov wrote:
> On 16/11/2011 02:52, Leif Johansson wrote:
>> On 11/14/2011 03:13 AM, Shawn M Emery wrote:
>>> On 11/12/11 7:17 PM, Leif Johansson wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> On 10/27/2011 05:18 PM, Nico Williams wrote:
>>>>> On Thu, Oct 27, 2011 at 9:36 AM, Leif
>>>>> Johansson<leifj@mnt.se> wrote:
>>>>>>> GSS_Set_name_attribute() MAY succeed even though a 
>>>>>>> credential acquired with the resulting NAME may not 
>>>>>>> actually result in a peer seeing the given attribute.
>>>>>>> If it is critical that the attribute be asserted in
>>>>>>> subsequent security context establishments, then the
>>>>>>> caller must inquire the NAME for any CREDENTIAL HANDLE
>>>>>>> acquired with this NAME and then check that the
>>>>>>> requested attribute has indeed been set in the
>>>>>>> CREDENTIAL HANDLE's NAME.
>>>> So it sounds like there is consensus for Nicos proposal.
>>>> 
>>>> Do you want to call this now Shawn or should I bring it up
>>>> at the mic and re-confirm?
>>> Let's discuss this during the session and then make a
>>> consensus call to the list in case there are any new
>>> revelations made.
>> Expanding on my note from yesterday - here is suggested text for 
>> section 7.6 (just after the list of error codes):
>> 
>> "If the attribute NAME is not know
> s/know/known
>> or could not be set an error of GSS_S_UNAVAILABLE SHOULD be
>> returned however GSS_Set_name_attribute() MAY succeed even though
>> a credential acquired with the resulting NAME may not actually
>> result in a peer seeing the given attribute. If it is critical
>> that the attribute be asserted in subsequent security context 
>> establishments, then the caller must inquire the NAME for any 
>> CREDENTIAL HANDLE acquired with this NAME and then check that
>> the requested attribute has indeed been set in the CREDENTIAL
>> HANDLE's NAME."
>> 
>> If I can get a consensus for that I can issue 12 and Shawn can
>> start the (final?) WGLC.
> The new text looks good to me.
> 


I got this reply from Alexei. Anyone else...? Going.... going....

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

iEYEARECAAYFAk7EaiQACgkQ8Jx8FtbMZndlUACgofU3u2N+KrRgh87OPOWDr58U
D4QAoIWV3HTXPIHm6RoK9kn7BibbBFsh
=qDtb
-----END PGP SIGNATURE-----

From nico@cryptonector.com  Wed Nov 16 19:27:34 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54D31F0CC0 for <kitten@ietfa.amsl.com>; Wed, 16 Nov 2011 19:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zEuCCNCnMlF for <kitten@ietfa.amsl.com>; Wed, 16 Nov 2011 19:27:34 -0800 (PST)
Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id EE5621F0CA5 for <kitten@ietf.org>; Wed, 16 Nov 2011 19:27:33 -0800 (PST)
Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 9399D286062 for <kitten@ietf.org>; Wed, 16 Nov 2011 19:27:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=vUQqwvZI33ONmiFbez5yT P6uBflqU+jlZq/Hc32T2r4c1gQ9EHnXuNSZptX0w43f7My1/9odHOfGeM2QBg3c0 tOjElyhrMbM4YSBznUErZs1tZrKDOTuoynSvCocEmyoGVP/WaHHe+tUXPWph5tFy oIvqirZpv3kTXa3YgjatQI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fKTYHEFLvXnc2rZDgmVc qMtXpcI=; b=UQ/nGQNR6AiDha+PHOylYtka2P2FgTOnD/ShsfvPCuKpZFLi/3mi wX0CdHhsajZa8fub+cTj0Bk9fdER3RCl6unj+3KE7e4i4yKbWgA67mO3TvA3Yk8/ GK0R4/G2e0/pcnq9lhAxBA5h/5E4agWyssVUJNeY0TPzL0RPcf77xFA=
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 6DEBD286060 for <kitten@ietf.org>; Wed, 16 Nov 2011 19:27:33 -0800 (PST)
Received: by iaeo4 with SMTP id o4so1849535iae.31 for <kitten@ietf.org>; Wed, 16 Nov 2011 19:27:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.63.9 with SMTP id z9mr8624501ibh.17.1321500452857; Wed, 16 Nov 2011 19:27:32 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Wed, 16 Nov 2011 19:27:32 -0800 (PST)
In-Reply-To: <4EC32551.20906@mnt.se>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se>
Date: Wed, 16 Nov 2011 21:27:32 -0600
Message-ID: <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Leif Johansson <leifj@mnt.se>
Content-Type: text/plain; charset=UTF-8
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 03:27:34 -0000

On Tue, Nov 15, 2011 at 8:52 PM, Leif Johansson <leifj@mnt.se> wrote:
> Expanding on my note from yesterday - here is suggested text for
> section 7.6 (just after the list of error codes):
>
> "If the attribute NAME is not know or could not be set an error of

s/know/known/

> GSS_S_UNAVAILABLE SHOULD be returned however GSS_Set_name_attribute()

I think I want s/SHOULD/may/ here because the only way the mechglue
could know if an attribute is "known" is by inquiring all its
providers to see if it is.  Sure, the SPI could have a method to do
the inquiry, but I'd not want to assume that.  Besides, given that we
agree that the caller that cares must check the acquired credential's
name, I don't want to give developers a false sense that they don't
have to.

> MAY succeed even though a credential acquired with the resulting NAME

But this MAY is fine :)

> may not actually result in a peer seeing the given attribute. If it is
> critical that the attribute be asserted in subsequent security context
> establishments, then the caller must inquire the NAME for any
> CREDENTIAL HANDLE acquired with this NAME and then check that the
> requested attribute has indeed been set in the CREDENTIAL HANDLE's NAME."
>
> If I can get a consensus for that I can issue 12 and Shawn can start
> the (final?) WGLC.

With the above corrections I think this is fine.

Nico
--

From leifj@mnt.se  Wed Nov 16 21:38:05 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7322011E80B2 for <kitten@ietfa.amsl.com>; Wed, 16 Nov 2011 21:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN62Yp5toLO2 for <kitten@ietfa.amsl.com>; Wed, 16 Nov 2011 21:38:04 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 8384511E8083 for <kitten@ietf.org>; Wed, 16 Nov 2011 21:38:03 -0800 (PST)
Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAH5boMG010988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 06:37:57 +0100 (CET)
Message-ID: <4EC49DAD.2070908@mnt.se>
Date: Thu, 17 Nov 2011 06:37:49 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com>
In-Reply-To: <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 05:38:05 -0000

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

On 11/17/2011 04:27 AM, Nico Williams wrote:
> On Tue, Nov 15, 2011 at 8:52 PM, Leif Johansson <leifj@mnt.se>
> wrote:
>> Expanding on my note from yesterday - here is suggested text for 
>> section 7.6 (just after the list of error codes):
>> 
>> "If the attribute NAME is not know or could not be set an error
>> of
> 
> s/know/known/
> 
>> GSS_S_UNAVAILABLE SHOULD be returned however
>> GSS_Set_name_attribute()
> 
> I think I want s/SHOULD/may/ here because the only way the
> mechglue could know if an attribute is "known" is by inquiring all
> its providers to see if it is.  Sure, the SPI could have a method
> to do the inquiry, but I'd not want to assume that.  Besides, given
> that we agree that the caller that cares must check the acquired
> credential's name, I don't want to give developers a false sense
> that they don't have to.

The second MAY is pretty clear on that I think. A SHOULD says that
the mechglue is expected to do its best but that it MAY do something
else if it has good reason to. I suspect that most implementations
will have configuration to look at for determining that an attribute
is known or not. This imho makes a SHOULD a reasonable thing.


> 
>> MAY succeed even though a credential acquired with the resulting
>> NAME
> 
> But this MAY is fine :)
> 
>> may not actually result in a peer seeing the given attribute. If
>> it is critical that the attribute be asserted in subsequent
>> security context establishments, then the caller must inquire the
>> NAME for any CREDENTIAL HANDLE acquired with this NAME and then
>> check that the requested attribute has indeed been set in the
>> CREDENTIAL HANDLE's NAME."
>> 
>> If I can get a consensus for that I can issue 12 and Shawn can
>> start the (final?) WGLC.
> 
> With the above corrections I think this is fine.
> 
> Nico --

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

iEYEARECAAYFAk7Ena0ACgkQ8Jx8FtbMZneuCwCfZp8m1uPTQLrPlunU52f/o0Dt
lKIAoMeK3UzTQ7gJELqFvO+UrtHs1Iwg
=R3il
-----END PGP SIGNATURE-----

From nico@cryptonector.com  Thu Nov 17 08:15:57 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A47A21F99C0 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 08:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level: 
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1ljI5fp7o4c for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 08:15:56 -0800 (PST)
Received: from homiemail-a26.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 60AD721F99BC for <kitten@ietf.org>; Thu, 17 Nov 2011 08:15:56 -0800 (PST)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 4756DB8072 for <kitten@ietf.org>; Thu, 17 Nov 2011 08:15:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=EhZPZUJkpWjU9nuLUW0f7aRPL26sAzUnn2HX0exgpP19 aAIRY1kpsmpYXv6AeB+grsNkqsaxdm3V1HFf+B0KHpuxiAjPqz8t61b4GGgQzzgZ lWxp02i7KZWUA+enQN3J9N17elIABMfZOF3hjjNZ6GsKWWvd3VlG6aAsulFV+9Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=nG4e5KJegwjaPxAxIxhr7tCRBs0=; b=qG7eNpjk925 RZuq7j9oh40qtOQYvhaME9rDUzG6kyribwn/wOKSxh7KHs3r7UgncpJmgVdNEfvM EqRprC/mr65GVqXsflk9+9ITT15qCFNKl+JOAp0bk7zm35ZL5DX8YJA8jrLU5YwO 6N/jGmCT7OHdjrvKTffUZQU7vhYMHxJI=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 038CBB808A for <kitten@ietf.org>; Thu, 17 Nov 2011 08:15:23 -0800 (PST)
Received: by pzk5 with SMTP id 5so2581310pzk.9 for <kitten@ietf.org>; Thu, 17 Nov 2011 08:15:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.25.101 with SMTP id b5mr270049pbg.24.1321546522915; Thu, 17 Nov 2011 08:15:22 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 08:15:22 -0800 (PST)
In-Reply-To: <4EC49DAD.2070908@mnt.se>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <4EC49DAD.2070908@mnt.se>
Date: Thu, 17 Nov 2011 10:15:22 -0600
Message-ID: <CAK3OfOhkWp-xnqynnf9H6uHx=zWko4XvfSgKB8=BfssTpMWqOQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Leif Johansson <leifj@mnt.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 16:15:59 -0000

On Wed, Nov 16, 2011 at 11:37 PM, Leif Johansson <leifj@mnt.se> wrote:
> On 11/17/2011 04:27 AM, Nico Williams wrote:
>> On Tue, Nov 15, 2011 at 8:52 PM, Leif Johansson <leifj@mnt.se>
>> wrote:
>>> Expanding on my note from yesterday - here is suggested text for
>>> section 7.6 (just after the list of error codes):
>>>
>>> "If the attribute NAME is not know or could not be set an error
>>> of
>>
>> s/know/known/
>>
>>> GSS_S_UNAVAILABLE SHOULD be returned however
>>> GSS_Set_name_attribute()
>>
>> I think I want s/SHOULD/may/ here because the only way the
>> mechglue could know if an attribute is "known" is by inquiring all
>> its providers to see if it is. =C2=A0Sure, the SPI could have a method
>> to do the inquiry, but I'd not want to assume that. =C2=A0Besides, given
>> that we agree that the caller that cares must check the acquired
>> credential's name, I don't want to give developers a false sense
>> that they don't have to.
>
> The second MAY is pretty clear on that I think. A SHOULD says that
> the mechglue is expected to do its best but that it MAY do something
> else if it has good reason to. I suspect that most implementations
> will have configuration to look at for determining that an attribute
> is known or not. This imho makes a SHOULD a reasonable thing.

Why is local configuration an appropriate thing to resort to here?
(And what else could it be but local configuration?  Do we really want
the mechglue and/or its providers to do network I/O in this one
function?)

Suppose we add an interactive credential acquisition function...  It
should suffice that the application and credential infrastructure
(e.g., KDCs) support a given attribute.  If using a new attribute then
requires distributing local configuration changes then we've made a
big mistake.

The more I think about it the more I want this paragraph to say
nothing about "unknown" attributes, and I really don't want it to say
"SHOULD return an error" in the case of unknown attributes.

Nico
--

From nico@cryptonector.com  Thu Nov 17 09:12:55 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B8121F95DB for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 09:12:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PY3FzO08jjG for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 09:12:54 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5CF21F952E for <kitten@ietf.org>; Thu, 17 Nov 2011 09:12:54 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id E58F6264073 for <kitten@ietf.org>; Thu, 17 Nov 2011 09:12:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type: content-transfer-encoding; q=dns; s=cryptonector.com; b=CUUskakE 7Ez4n2+ymHuK4HsZQ+q6F4nKXEP5wFpBWRU+XPasWkq7baVroWD3LREf2kbqo+vx GY6JD0mNKixT+L6TPeSPYnORKJyO0JyLlTxJMhZ7RndVLoHs6InIYL/cyz6km9qm 2aODvYFsw0D2w6M/mQ5xTrHdAILOqpyFmjM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type: content-transfer-encoding; s=cryptonector.com; bh=nB1ZY2HmJA1lSu 0LQU5F050FgVc=; b=EmSLzR0Vt8So+gvxPjzIPjFCJQrK6FKY6JHzBUdj1cUQgy 46DmQuvAptiD3Q/DwVSHJHogVRF8Y7W67Aa78rKNDqxflzeChKzXaU/iTjeO/2Lx IpiO3OzXPmPj+yibppxwL+ve+MOzjXosenWJV1br/IIoanPs8xUikYbMbIJFs=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 93DE626406F for <kitten@ietf.org>; Thu, 17 Nov 2011 09:12:53 -0800 (PST)
Received: by pzk5 with SMTP id 5so2764288pzk.9 for <kitten@ietf.org>; Thu, 17 Nov 2011 09:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.30.68 with SMTP id q4mr645736pbh.75.1321549973276; Thu, 17 Nov 2011 09:12:53 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 09:12:53 -0800 (PST)
Date: Thu, 17 Nov 2011 11:12:53 -0600
Message-ID: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: kitten@ietf.org, ietf-krb-wg@anl.gov
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [kitten] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 17:12:55 -0000

[This post is intentionally terse.  I assume reader familiarity with
this subject.]

We have two kinds of GSS/Kerberos and raw Kerberos applications that
we need to worry about w.r.t. rcaches: those that need an rcache, and
those that don't. =C2=A0For the latter we need to make sure that their
AP-REQs can't be played to acceptors/servers for applications that do
need an rcache -a critical requirement-, which means that for all
designs I describe below I assume that all Kerberos implementations on
the server support rcache avoidance.  This critical requirement I will call=
 the
"non-mixing requirement".

Whether to use an rcache will often be context-specific. =C2=A0For example,
forGS2 the question will depend on whether the Kerberos mechanism is
beingused and whether channel binding to a secure channel that
providesconfidentiality protection is being used. =C2=A0The same thing goes
forHTTP/Negotiate.

Here I will assume throughout that all Kerberos acceptor/server mechanism
implementations on a given host will support rcache avoidance, at least on
a per-service name basis.  I.e., configuration will be required to enable
rcache avoidance, and for now it must be disabled by default.

I've come to conclude that we need the initiator's/client's help and
the acceptor's/server's help to decide when it's OK to avoid the
rcache.  For the GSS-API we could make a minimally invasive extension
based entirely on req_flags/ret_flags, but that would require that
rcache avoidance not be enabled until all GSS applications (not just
GSS implementations) on a host have been updated.  A GSS extension
based entirely on req_flags/ret_flags would be unacceptably insecure
by default, therefore I propose the use of a credential option
instead.

In the interest of generality I propose two cred options by which to
describe what's happening in the application protocol, as opposed to
one cred option by which to say "use an rcache" or "don't use an
rcache".  The two cred options would indicate whether the security
context is to be channel bound to a secure channel providing
confidentiality protection, and/or whether per-message tokens will be
used and if so that nothing of consequence will be done or sent by the
acceptor until after receiving a per-message token from the initiator.

For the GSS-API then the additions are just two cred option OIDs (TBD)
and symbols for them:

 - GSS_C_CO_BOUND_TO_CONF_SEC_CHANNEL
 - GSS_C_CO_IMPLIED_EXTRA_LEG

The initiator and acceptor applications would use the above cred
options to signal that the given security context is channel bound to
a secure channel and/or to indicate that pre-message tokens will be
used and that nothing of consequence will be sent by the acceptor
until at least one per-message token has been sent by the initiator.
Instead of GSS_C_NO_CREDENTIAL the application would acquire a
credential handle for GSS_C_NO_NAME then set the cred options.  The
two options would have boolean values, and could be turned on or off.

When the initiator and acceptor agree that an rcache is not needed (by
setting either of these options to true), then the mechanism should
not use an rcache.  Other GSS acceptors or Kerberos services running
on the same server MUST reject any AP-REQs with these options set when
the acceptor/server application fails to indicate that an rcache is
not needed (see assumptions above), thus meeting the critical
non-mixing requirement.

Raw Kerberos APIs would look similar to the credential option for GSS
and need not be discussed here in any detail.

In the GSS Kerberos mechanism and in raw Kerberos we would use
non-critical authorization-data (i.e., wrapped in AD-IF-RELEVANT) to
signal these two options.  The authorization-data elements would bear
no data, just the element type, and they would be named something
like:

 - AD-BOUND-TO-CONF-SEC-CHANNEL
 - AD-IMPLIED-EXTRA-LEG

Nico
--

From leifj@mnt.se  Thu Nov 17 09:30:04 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0EE1F0C84 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 09:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.206
X-Spam-Level: 
X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAgIJnLg9LSR for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 09:29:57 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3B1F0C7F for <kitten@ietf.org>; Thu, 17 Nov 2011 09:29:57 -0800 (PST)
Received: from [130.129.64.184] (dhcp-40b8.meeting.ietf.org [130.129.64.184]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAHHTh4t003141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 18:29:49 +0100 (CET)
Message-ID: <4EC54486.3070000@mnt.se>
Date: Thu, 17 Nov 2011 18:29:42 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <4EC49DAD.2070908@mnt.se> <CAK3OfOhkWp-xnqynnf9H6uHx=zWko4XvfSgKB8=BfssTpMWqOQ@mail.gmail.com>
In-Reply-To: <CAK3OfOhkWp-xnqynnf9H6uHx=zWko4XvfSgKB8=BfssTpMWqOQ@mail.gmail.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 17:30:04 -0000

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

On 11/17/2011 05:15 PM, Nico Williams wrote:
> On Wed, Nov 16, 2011 at 11:37 PM, Leif Johansson <leifj@mnt.se>
> wrote:
>> On 11/17/2011 04:27 AM, Nico Williams wrote:
>>> On Tue, Nov 15, 2011 at 8:52 PM, Leif Johansson <leifj@mnt.se> 
>>> wrote:
>>>> Expanding on my note from yesterday - here is suggested text
>>>> for section 7.6 (just after the list of error codes):
>>>> 
>>>> "If the attribute NAME is not know or could not be set an
>>>> error of
>>> 
>>> s/know/known/
>>> 
>>>> GSS_S_UNAVAILABLE SHOULD be returned however 
>>>> GSS_Set_name_attribute()
>>> 
>>> I think I want s/SHOULD/may/ here because the only way the 
>>> mechglue could know if an attribute is "known" is by inquiring
>>> all its providers to see if it is.  Sure, the SPI could have a
>>> method to do the inquiry, but I'd not want to assume that.
>>> Besides, given that we agree that the caller that cares must
>>> check the acquired credential's name, I don't want to give
>>> developers a false sense that they don't have to.
>> 
>> The second MAY is pretty clear on that I think. A SHOULD says
>> that the mechglue is expected to do its best but that it MAY do
>> something else if it has good reason to. I suspect that most
>> implementations will have configuration to look at for
>> determining that an attribute is known or not. This imho makes a
>> SHOULD a reasonable thing.
> 
> Why is local configuration an appropriate thing to resort to here? 
> (And what else could it be but local configuration?  Do we really
> want the mechglue and/or its providers to do network I/O in this
> one function?)
> 
> Suppose we add an interactive credential acquisition function...
> It should suffice that the application and credential
> infrastructure (e.g., KDCs) support a given attribute.  If using a
> new attribute then requires distributing local configuration
> changes then we've made a big mistake.
> 
> The more I think about it the more I want this paragraph to say 
> nothing about "unknown" attributes, and I really don't want it to
> say "SHOULD return an error" in the case of unknown attributes.

The way I see it is that (and I'm also trying to echo Sam who said
more or less the same thing) if you're trying to set a saml attribute
on a krb mechglue that doesn't do saml then it is a bit silly to get
a GSS_S_COMPLETE and have to go and read that attribute only then to
realize it wasn't set. That mech clearly "knows" that it can't set
a saml attribute, so why should it not return an error?

	Cheers Leif

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

iEYEARECAAYFAk7FRIYACgkQ8Jx8FtbMZnfGRwCbBADI6OJlojVEqHhR6aChCvx8
GZ4AoJB8ye3nvhbU/sxx0KKxmSROPNg1
=rKXi
-----END PGP SIGNATURE-----

From nico@cryptonector.com  Thu Nov 17 10:03:48 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463781F0C7F for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 10:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.938
X-Spam-Level: 
X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3gVCjkSANWv for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 10:03:41 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D44821F0C54 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:03:41 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 7159D3B806A for <kitten@ietf.org>; Thu, 17 Nov 2011 10:03:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=FJ0YAYtCXNLRwz6S9lx23 ET8spTeb3aTVcoEJfy9aCbSGSs9SWwe5s055h+qHCF9T3ZnDHJrdjMFVUyOy7HuG vXEl9j9F2YVlLpiaS+r9HzHNcDPyjpBnQhr9YHJG7h5zeA5r2ij2wC3aNRSA1N5v pR/HHRgGU8hrsOaZWhjR5k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9E4ypFeAO8L2LYUSuGXP 74ZHOpw=; b=G03limXOI4GEul7eyETGo0qdqLtXb9zSWAUV5XaVKcAMfYKlW5Xq FRs6yc6useTTRy7UnP8syaxN+p5z6wvJABkyEJArK0FOs20DpmuaWBnwYNn87p88 sDqr7reyS6q6KxVxaj+kSxtNZnFH2lOroW5ZVmZTyN0ZpTiBs0EwrMc=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 600653B8065 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:03:41 -0800 (PST)
Received: by pzk5 with SMTP id 5so2928903pzk.9 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:03:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.10.138 with SMTP id i10mr999384pbb.92.1321553020970; Thu, 17 Nov 2011 10:03:40 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 10:03:40 -0800 (PST)
In-Reply-To: <4EC54486.3070000@mnt.se>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <4EC49DAD.2070908@mnt.se> <CAK3OfOhkWp-xnqynnf9H6uHx=zWko4XvfSgKB8=BfssTpMWqOQ@mail.gmail.com> <4EC54486.3070000@mnt.se>
Date: Thu, 17 Nov 2011 12:03:40 -0600
Message-ID: <CAK3OfOh-u5DQqZxouSpaMAymN7p5O_sYnETqu1aY1cTyxRx6Qg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Leif Johansson <leifj@mnt.se>
Content-Type: text/plain; charset=UTF-8
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 18:03:48 -0000

On Thu, Nov 17, 2011 at 11:29 AM, Leif Johansson <leifj@mnt.se> wrote:
> The way I see it is that (and I'm also trying to echo Sam who said
> more or less the same thing) if you're trying to set a saml attribute
> on a krb mechglue that doesn't do saml then it is a bit silly to get
> a GSS_S_COMPLETE and have to go and read that attribute only then to
> realize it wasn't set. That mech clearly "knows" that it can't set
> a saml attribute, so why should it not return an error?

The only way the mechanism can do this for you is if a) the NAME
passed to this function is an MN, and b) the mechanism goes on to do
credential acquisition (talk to the KDC) under the covers if that's
the only way to find out whether the attribute is known.  If this is
what you and Sam have in mind then the I-D should say so (INTERNAL
NAME does not imply MN).

I agree that set-then-confirm is an obnoxious sequence of calls to
have to make, but I don't see why set-then-confirm should be OK for
handling criticality but not for handling known-ness if the latter
requires a round-trip trip to the KDC -- something that any potential
mechanism might, thus I don't see the distinction.

So, a few things:

 - If the name given to GSS_Set_name_attribute() is not an MN then I
think the function should not do anything with regards to whether the
attribute is known.  Yes, the mechglue could try to create an MN for
each {provider, mechanism}, and then get each provider to set the
given attribute on the resulting MNs.  But this seems like a lot of
work for a mechglue to do.

 - If the name is an MN, then there's still the question of whether
the mechanism will have to do network I/O in order to validate whether
the name attribute is known.  If so, then what credentials should the
mechanism use for such I/O?  In other words, I think we need a
credential argument here, much as we've discussed
GSS_Canonicalize_name_with_cred() in the past.

 - If the mechanism can validate name attributes, then it could handle
a critical flag.  Here, once again, we care about whether the
credential will include the attribute, so a credential input argument
seems in order.

Have we got this API all wrong?  I do think that we could use some
additional APIs for convenience, namely a function that takes care of
credential acquisition and name attribute setting (including
criticality) in one step.

Nico
--

From nico@cryptonector.com  Thu Nov 17 10:16:26 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252C11F0C8E for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 10:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Level: 
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EDl-qeMeDCN for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 10:16:19 -0800 (PST)
Received: from homiemail-a28.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id A119A1F0C64 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:16:19 -0800 (PST)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 39F621B4058 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:16:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=SkmStAOSlf5EatxyichI3eA7n4WdLsZkCFYxpK2Z66bL 8uZxLhDUVQbLFQAo1aCQdV8GkorhH+ehhym2qPkWxTmhGfotaSyado23BAOfcRbv rGfbN2pystcHhyY3B3ZPY3fyPWnXf+5gKHBe2mYga7OFhkxU3ASdQTL9GTdiouw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=P35h+5jX1zE/9IUpZ6b2rgoHPkg=; b=R1bIYyIoa7l 6PsQ0LPyTlfuCgOQbiNw13AwEvvbVnthP8eAEZXio4Uh7j38eINrEqp0qYTcE3fF yHJZUh0ShBl1sYGkWUxCjvq85CPP2gW3N+XXETCe1iIZ1trq/0XKb5oai4DA5jyo adi1qPYuIxSYcQKsv7AGel6mDhJXl5Ms=
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E0B101B4009 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:16:17 -0800 (PST)
Received: by eyg24 with SMTP id 24so2754825eyg.31 for <kitten@ietf.org>; Thu, 17 Nov 2011 10:16:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.25.101 with SMTP id b5mr1082249pbg.24.1321553775884; Thu, 17 Nov 2011 10:16:15 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 10:16:15 -0800 (PST)
In-Reply-To: <CAK3OfOh-u5DQqZxouSpaMAymN7p5O_sYnETqu1aY1cTyxRx6Qg@mail.gmail.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <4EC49DAD.2070908@mnt.se> <CAK3OfOhkWp-xnqynnf9H6uHx=zWko4XvfSgKB8=BfssTpMWqOQ@mail.gmail.com> <4EC54486.3070000@mnt.se> <CAK3OfOh-u5DQqZxouSpaMAymN7p5O_sYnETqu1aY1cTyxRx6Qg@mail.gmail.com>
Date: Thu, 17 Nov 2011 12:16:15 -0600
Message-ID: <CAK3OfOhRXKW9AY7rtwBv=fOX71TY5c4Zg5ax3ydTX9mRq5+YGA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Leif Johansson <leifj@mnt.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 18:16:26 -0000

On Thu, Nov 17, 2011 at 12:03 PM, Nico Williams <nico@cryptonector.com> wro=
te:
> =C2=A0- If the name given to GSS_Set_name_attribute() is not an MN then I
> think the function should not do anything with regards to whether the
> attribute is known. =C2=A0Yes, the mechglue could try to create an MN for
> each {provider, mechanism}, and then get each provider to set the
> given attribute on the resulting MNs. =C2=A0But this seems like a lot of
> work for a mechglue to do.

Also, the mechglue can't try all mechanisms when the given name is not
an MN. =C2=A0The reason is that if some mechanisms fail to set the given
name attribute and some succeed, then what should the mechglue
return?! =C2=A0We can't let any one mechanism that the application does not
need/care about prevent the app from using the given name attribute.
But we also don't know which mechanism the application cares about.

So if you want to avoid set-then-confirm for determining whether a
name attribute is known, then you must require that the input name be
an MN. =C2=A0That still leaves the remaining issues open.

Here's my proposal:

=C2=A0- either remove the text recommending failure for unknown name
attributes or require that the name be an MN in order for unknown
attributes to yield an error (but do allow the name to not be an MN --
I think that will be useful);

=C2=A0- add (in this document or in a new I-D, your choice) a function that
combines the setting of name attributes with credential acquisition
(GSS_Acquire_cred_with_name_attributes()?).

Nico
--

From jhutz@cmu.edu  Thu Nov 17 11:47:45 2011
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9486121F99A6 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 11:47:45 -0800 (PST)
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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWbPAHt3tf2r for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 11:47:45 -0800 (PST)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id F12AA21F99A5 for <kitten@ietf.org>; Thu, 17 Nov 2011 11:47:44 -0800 (PST)
Received: from [128.2.216.42] (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 pAHJleBH024138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 14:47:40 -0500 (EST)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 17 Nov 2011 14:47:40 -0500
Message-ID: <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, jhutz@cmu.edu
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 19:47:45 -0000

On Thu, 2011-11-17 at 11:12 -0600, Nico Williams wrote:
> I've come to conclude that we need the initiator's/client's help and
> the acceptor's/server's help to decide when it's OK to avoid the
> rcache.  For the GSS-API we could make a minimally invasive extension
> based entirely on req_flags/ret_flags, but that would require that
> rcache avoidance not be enabled until all GSS applications (not just
> GSS implementations) on a host have been updated.

Why?  Remember that while there currently is a one-to-one correspondence
between the bits representing these flags as they appear in the RFC2744
C language bindings and as they appear on the wire in the Kerberos
mechanism, there is no requirement that this continue to be the case.
We are free to allocate flag bits on the wire in the Kerberos mechanism
to support rcache avoidance negotiation without exposing those bits to
the GSS-API (in any language).  Of course, we might want to avoid also
using the same bits for future unrelated flags in the C bindings, in
order to make life a bit easier for implementators.


> When the initiator and acceptor agree that an rcache is not needed (by
> setting either of these options to true), then the mechanism should
> not use an rcache.  Other GSS acceptors or Kerberos services running
> on the same server MUST reject any AP-REQs with these options set when
> the acceptor/server application fails to indicate that an rcache is
> not needed (see assumptions above), thus meeting the critical
> non-mixing requirement.

Hrm.  I'd be happier if this didn't require a non-critical extension to
be treated as critical by other acceptors.  The "everything must be
upgraded" requirement is tricky because it's hard for administrators to
tell if they've met it, and it's impossible for an application itself to
know the answer.


> In the GSS Kerberos mechanism and in raw Kerberos we would use
> non-critical authorization-data (i.e., wrapped in AD-IF-RELEVANT) to
> signal these two options.  The authorization-data elements would bear
> no data, just the element type, and they would be named something
> like:
> 
>  - AD-BOUND-TO-CONF-SEC-CHANNEL
>  - AD-IMPLIED-EXTRA-LEG

So, why make these non-critical?  It sounds like they actually should be
critical, which guarantees that acceptors which have _not_ been upgraded
will always reject an AP-REQ which contains them, which is what we want.

-- Jeff


From ghudson@mit.edu  Thu Nov 17 12:16:54 2011
Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9911E80AB for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 12:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atFcMTulUInf for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 12:16:53 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDFF11E8081 for <kitten@ietf.org>; Thu, 17 Nov 2011 12:16:53 -0800 (PST)
X-AuditID: 12074423-b7f266d0000008b8-0b-4ec56bb4464f
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D7.A3.02232.4BB65CE4; Thu, 17 Nov 2011 15:16:52 -0500 (EST)
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 pAHKGq05003071;  Thu, 17 Nov 2011 15:16:52 -0500
Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAHKGnZg014893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 15:16:50 -0500 (EST)
Message-ID: <4EC56BB1.9050406@mit.edu>
Date: Thu, 17 Nov 2011 15:16:49 -0500
From: Greg Hudson <ghudson@MIT.EDU>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Jeffrey Hutzelman <jhutz@cmu.edu>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu>
In-Reply-To: <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu>
X-Enigmail-Version: 1.4a1pre
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrbsl+6ifwfyzRhaTT05gsrj+/hy7 xdHNq1gsTl07wubA4nFyzVs2j/2tx1g9Xp46x+ixZMlPpgCWKC6blNSczLLUIn27BK6Mrjut jAW3OSsmHO1laWD8zt7FyMkhIWAicf5JAyuELSZx4d56ti5GLg4hgX2MEpfe7WKBcDYwSuzb 2skO4dxjklhw9i4zSAuvgJrEsc5LjCA2i4CqxNYtR8FGsQkoSxw8+40FxBYVCJF4NuE5G0S9 oMTJmU/A4iJA9ffmzAKzmQUiJN7euAc2R1jAWKJt1UwmiGWNjBLff25gAklwCthKrOu8xAxx q4zE/uP7mSGadSTe9T2AsuUltr+dwzyBUWgWkn2zkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJu cXJiXl5qka6ZXm5miV5qSukmRlAUsLso72D8c1DpEKMAB6MSD+9k26N+QqyJZcWVuYcYJTmY lER5d6QDhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwvvIAyvGmJFZWpRblw6SkOViUxHlldjr4 CQmkJ5akZqemFqQWwWRlODiUJHj/ZwE1ChalpqdWpGXmlCCkmTg4QYbzAA03yAYZXlyQmFuc mQ6RP8WoKCXOyw+SEABJZJTmwfXCktQrRnGgV4R5GUGqeIAJDq77FdBgJqDBuXuOgAwuSURI STUwpr7ZZVXwdbfdpjMLV39XvaL2VSX5Z8qMu27B5nYLUua9uvI1IOiZcopTp//h0GTzsmCt ssmMijEME8VsDJoP7t3is+mcBsuSdv4rx6Of8JxQSd4RIHns7eTQzQ8q3F7K/NtYv/YfQ/sq 64d/td8xvJtosPMx74b/21f57853WvVl8tutN/20dimxFGckGmoxFxUnAgA32yoaLQMAAA==
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 20:16:54 -0000

On 11/17/2011 02:47 PM, Jeffrey Hutzelman wrote:
> So, why make these non-critical?  It sounds like they actually should be
> critical, which guarantees that acceptors which have _not_ been upgraded
> will always reject an AP-REQ which contains them, which is what we want.

"Guarantees" is overly strong here.  Implementations don't tend to
respect the RFC 4120 requirement of rejecting authenticators containing
unknown authorization data.  That said, I'm not sure what the point of
the AD-IF-RELEVANT wrapper is.

I think there's a more significant issue, though.  Once we've added
support to GSSAPI and krb5 implementations and client and server apps,
how do new clients interoperate with old servers?

The client doesn't have any meaningful input into whether an rcache is
required.  The server has all of the information to know that.  We would
like the client to produce an authenticator which won't be accepted by
an rcache-requiring server, but only if we know that the intended server
will accept it.  That's fodder for negotiation, not a client-side
application flag.  (Unfortunately, the only vehicles I can think of for
negotiation are a ticket flag or a new mech OID, neither of which are
very attractive.)

From nico@cryptonector.com  Thu Nov 17 12:20:24 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F8B11E80C0 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 12:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peQNLKAaroBd for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 12:20:23 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A09AF11E80AB for <kitten@ietf.org>; Thu, 17 Nov 2011 12:20:23 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 58F633B806A for <kitten@ietf.org>; Thu, 17 Nov 2011 12:20:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Ygo8K3qEPRlnf9hUJzuYgq5y+kY6Dro7nV31cvdtZgmC 0XWWyhw0fWT4fLnw0Zqs2Er8DZrjrdhJF/JggRQtK2F7zhwUv4ZeQyNsqzz0Gp9q yXoBDQ/FN0NdSC/Wy0UkT14vNh7DTuI6oqVEKScyzV/PnMT6unyqG9LQe/IX0FQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=09Bht9R81sqCutbNVbvXHsS6vX8=; b=EFWokw6WxTr kIq1GVBksKz08AQhr16h9mrJ54gotCPh0mOVuEzD30623XkIDzJtsRPpbK8m7EFE DbNUIVOC8x3di4Lw2M7c1zgkNtMDKs4gy3tFPSPBQICKFhTJoslKgNsY0VhnPlH4 swnTFnPADoVx2A0Z/uO0+OgipdOwWSkg=
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id F24703B8020 for <kitten@ietf.org>; Thu, 17 Nov 2011 12:20:21 -0800 (PST)
Received: by faap16 with SMTP id p16so5096915faa.31 for <kitten@ietf.org>; Thu, 17 Nov 2011 12:20:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.10.138 with SMTP id i10mr1965268pbb.92.1321561219296; Thu, 17 Nov 2011 12:20:19 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 12:20:19 -0800 (PST)
In-Reply-To: <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu>
Date: Thu, 17 Nov 2011 14:20:19 -0600
Message-ID: <CAK3OfOhm3gh9Fa0hf+wQMc_QQckbWpjnKDJt6gY0YisPzdWXbQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 20:20:24 -0000

On Thu, Nov 17, 2011 at 1:47 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> On Thu, 2011-11-17 at 11:12 -0600, Nico Williams wrote:
>> I've come to conclude that we need the initiator's/client's help and
>> the acceptor's/server's help to decide when it's OK to avoid the
>> rcache. =C2=A0For the GSS-API we could make a minimally invasive extensi=
on
>> based entirely on req_flags/ret_flags, but that would require that
>> rcache avoidance not be enabled until all GSS applications (not just
>> GSS implementations) on a host have been updated.
>
> Why? =C2=A0Remember that while there currently is a one-to-one correspond=
ence
> [...]

Say we use only req_flags for this.  So the initiator sets one of
these flags, and the mechanism on the acceptor side honors it and
doesn't use the rcache.  But the acceptor application has to check the
ret_flags and reject authentication if the flags are inappropriately
present -- if it doesn't then a replay attack is possible.  Assuming
the mechanism implementations on a server are updated is one thing;
assuming all the apps on it are too is a bit too much for me.

>> When the initiator and acceptor agree that an rcache is not needed (by
>> setting either of these options to true), then the mechanism should
>> not use an rcache. =C2=A0Other GSS acceptors or Kerberos services runnin=
g
>> on the same server MUST reject any AP-REQs with these options set when
>> the acceptor/server application fails to indicate that an rcache is
>> not needed (see assumptions above), thus meeting the critical
>> non-mixing requirement.
>
> Hrm. =C2=A0I'd be happier if this didn't require a non-critical extension=
 to
> be treated as critical by other acceptors. =C2=A0The "everything must be
> upgraded" requirement is tricky because it's hard for administrators to
> tell if they've met it, and it's impossible for an application itself to
> know the answer.

We can't use a critical extension.  First because we'd have to
negotiate its use out of band, and that's not really an option.
Second, do all major Kerberos implementations treat critical
authz-data as critical?  I doubt it.

I don't think it's always hard for admins to know whether it's safe to
enable this, but that's why this option must default to disabled.

If we had always had an option for multiple round-trips, if we'd
always had critical authz-data, then we could have used that here.  As
it is we can't.  An approximation is the best I can see us achieving,
though we can also give up on rcache avoidance.

>> In the GSS Kerberos mechanism and in raw Kerberos we would use
>> non-critical authorization-data (i.e., wrapped in AD-IF-RELEVANT) to
>> signal these two options. =C2=A0The authorization-data elements would be=
ar
>> no data, just the element type, and they would be named something
>> like:
>>
>> =C2=A0- AD-BOUND-TO-CONF-SEC-CHANNEL
>> =C2=A0- AD-IMPLIED-EXTRA-LEG
>
> So, why make these non-critical? =C2=A0It sounds like they actually shoul=
d be
> critical, which guarantees that acceptors which have _not_ been upgraded
> will always reject an AP-REQ which contains them, which is what we want.

Ignoring the question of whether all mechanism implementations are
upgraded on the server, making this a non-critical option is exactly
the right thing to do.  It's only the possibility of legacy mechanism
implementations that should make you want this to be a critical
extension, and I do believe the best thing to do about that is to
disable this feature by default.

Nico
--

From jhutz@cmu.edu  Thu Nov 17 13:49:15 2011
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1477511E809D for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 13:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.566
X-Spam-Level: 
X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RfgPG23RnSn for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 13:49:14 -0800 (PST)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4B48D11E8080 for <kitten@ietf.org>; Thu, 17 Nov 2011 13:49:14 -0800 (PST)
Received: from [128.2.216.42] (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 pAHLnA3k029213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 16:49:11 -0500 (EST)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOhm3gh9Fa0hf+wQMc_QQckbWpjnKDJt6gY0YisPzdWXbQ@mail.gmail.com>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu> <CAK3OfOhm3gh9Fa0hf+wQMc_QQckbWpjnKDJt6gY0YisPzdWXbQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 17 Nov 2011 16:49:05 -0500
Message-ID: <1321566545.5944.170.camel@minbar.fac.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, jhutz@cmu.edu
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 21:49:15 -0000

On Thu, 2011-11-17 at 14:20 -0600, Nico Williams wrote:
> On Thu, Nov 17, 2011 at 1:47 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> > On Thu, 2011-11-17 at 11:12 -0600, Nico Williams wrote:
> >> I've come to conclude that we need the initiator's/client's help and
> >> the acceptor's/server's help to decide when it's OK to avoid the
> >> rcache.  For the GSS-API we could make a minimally invasive extension
> >> based entirely on req_flags/ret_flags, but that would require that
> >> rcache avoidance not be enabled until all GSS applications (not just
> >> GSS implementations) on a host have been updated.
> >
> > Why?  Remember that while there currently is a one-to-one correspondence
> > [...]
> 
> Say we use only req_flags for this.  So the initiator sets one of
> these flags, and the mechanism on the acceptor side honors it and
> doesn't use the rcache.  But the acceptor application has to check the
> ret_flags and reject authentication if the flags are inappropriately
> present -- if it doesn't then a replay attack is possible.  Assuming
> the mechanism implementations on a server are updated is one thing;
> assuming all the apps on it are too is a bit too much for me.

OK, I can see how that applies to raw Kerberos, since only the app knows
enough to know whether it is safe to avoid the rcache.  But in the case
of the Kerberos GSS-API mechanism, this shouldn't actually be an
application-specific question, should it?  The application shouldn't
know anything about Kerberos, let alone whether it needs a replay cache.

> We can't use a critical extension.  First because we'd have to
> negotiate its use out of band, and that's not really an option.

Yeah, you're right.

> Second, do all major Kerberos implementations treat critical
> authz-data as critical?  I doubt it.

Greg pointed this out.  That's unfortunate, though, because it basically
means we can never have critical authz-data.

> I don't think it's always hard for admins to know whether it's safe to
> enable this, but that's why this option must default to disabled.

It's hard.  Most admins don't understand the workings of everything on
their system.  They won't understand how to tell whether a particular
application is safe, and for services like "host", they may not even
know what applications are installed that share that principal.  Even if
they do, they won't know whether all of the applications sharing a
service are using Kerberos and GSS libraries that are new enough.  Even
supposedly single-application service often have multiple components
that share a principal.

And, turning this on when you shouldn't doesn't make services break; it
makes services become less secure without breaking.  That's exactly the
sort of knob you don't want to require admins to twist.  If we do this,
in a couple of years you'll be able to find "advice" on a dozen mailing
lists to blindly flip this switch to make your {imap,http,whatever}
server "faster", with no discussion of the consequences, which won't
even be understood by the person giving the "advice".



> >> In the GSS Kerberos mechanism and in raw Kerberos we would use
> >> non-critical authorization-data (i.e., wrapped in AD-IF-RELEVANT) to
> >> signal these two options.  The authorization-data elements would bear
> >> no data, just the element type, and they would be named something
> >> like:
> >>
> >>  - AD-BOUND-TO-CONF-SEC-CHANNEL
> >>  - AD-IMPLIED-EXTRA-LEG
> >
> > So, why make these non-critical?  It sounds like they actually should be
> > critical, which guarantees that acceptors which have _not_ been upgraded
> > will always reject an AP-REQ which contains them, which is what we want.
> 
> Ignoring the question of whether all mechanism implementations are
> upgraded on the server, making this a non-critical option is exactly
> the right thing to do.

Yeah, you've convinced me it needs to be for negotiation to work.

Unfortunately, that means you haven't gained anything.

I don't see why the client needs to be involved here at all.  The app
server knows whether the protocol supports rcache avoidance or not.  The
only reason to involve the client is to meet the non-mixing requirement,
by insuring that an application which cannot support rcache avoidance
does not accept an AP-REQ intended for an application which may be doing
rcache avoidance.  But if you can't include non-upgraded applications in
that set, you lose anyway.

I'm beginning to think the right answer is to always use different
principal names for rcache-avoiding and rcache-requiring services.

-- Jeff


From nico@cryptonector.com  Thu Nov 17 13:52:47 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002DC1F0C7F for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 13:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVFy8gp4jl-L for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 13:52:46 -0800 (PST)
Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 908291F0C75 for <kitten@ietf.org>; Thu, 17 Nov 2011 13:52:46 -0800 (PST)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 75A92B806B for <kitten@ietf.org>; Thu, 17 Nov 2011 13:52:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=KV3vEtzTnGa51G6hmNIyJ tsOciExDEj0ePUdxXTjlefATYf3VkczE/4Rr/sNsdA7BtMAmt24PknkjXeCeCX+b oKoVELW709lsrP6wjNgWgD3TCXXgVw0efV2PyL7gZs1HZ3YWA/cJV1iT8sbrQYsv GtAThCQnj4Rg9l32lWag7k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=wdFc+CeuPxOS5UA2A9CKdTJ iiHU=; b=PVjWShhW2aEbWOMpQdFbzyBWrXhOrFsQ5YnaPAGmvbhZCKEk0nTcLvS uPG/4rJFQlciU64wKtiz6P4hAT85hnGR/StX9FDfFJ+vfU6fA6O2BwL/hAOqBAJs XmeIQ2xRaB8jJqJ/ZxIg1hx+FG/Hnz4VgY9ZFVe6pSvbvbU4XZdc=
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id B74BFB807F for <kitten@ietf.org>; Thu, 17 Nov 2011 13:52:38 -0800 (PST)
Received: by eyg24 with SMTP id 24so3046813eyg.31 for <kitten@ietf.org>; Thu, 17 Nov 2011 13:52:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.44.40 with SMTP id b8mr2593393pbm.41.1321566754342; Thu, 17 Nov 2011 13:52:34 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 13:52:34 -0800 (PST)
In-Reply-To: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
Date: Thu, 17 Nov 2011 15:52:34 -0600
Message-ID: <CAK3OfOg1U0DQA+0WE5eJuvF4UtWGjkxEbNOHMSP7_tqLufpKvQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: kitten@ietf.org, ietf-krb-wg@anl.gov
Content-Type: text/plain; charset=UTF-8
Subject: Re: [kitten] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 21:52:47 -0000

I would like to remind you all that we have:

 - sites that disable the rcache or use MEMORY rcache implementations
to the same effect

   If we do nothing to help them, they'll continue doing this.  Yes,
we can implement fast rcaches (I've done it, so I know it's possible,
but then there's:

 - sites that use clustering but without any sort of distributed rcache

   I don't know of any distributed rcache implementations, much less
*fast* distributed rcache implementations.  (I know of at least one
fast local rcache implementation.)  Barring a sudden rush of interest
in developing such a thing, only rcache avoidance would really work
for clusters.

Nico
--

From nico@cryptonector.com  Thu Nov 17 14:06:58 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A911F0C67 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 14:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apnsR+eikKkt for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 14:06:58 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5162E1F0C55 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:06:58 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id ED89B678091 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:06:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GYTHBBqD0uddTZXL+PN9fZJ23Eomkdz8oAsKc9ZHqMOh asNHv0DqHJl9cCRUIQT0jG0NglRBlzEsKkrYe5xVvDRUk5kadE4SgJGLK3hYmbBR qwTC3yZUXx/S3/5I5m0yRVKLi4LGuwtDkPMJHtYzaUhpHb05PbOls+L9BcXNSl8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=6aCQRL6oE4wsjSR/0uGErgA1jfY=; b=DH2TW8DsWCA WbELO0D2gaxy6v/JCM5bqcF4ZZHmNn9R9QMdXkj0uB0StnmP9ZqsGlJbndbTqkO6 E3kbWC4XQwk/UcLVcnzTzu7cuEe+NzJkUVOvz3jBTbf5+SMNTxtSlv5O0kvH86tI kdZ9b0xkVYTZO6NH0Z2VpeyGR9XOk5Wc=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 16959678089 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:05:59 -0800 (PST)
Received: by pzk5 with SMTP id 5so3616676pzk.9 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:05:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.30.68 with SMTP id q4mr2697260pbh.75.1321567559116; Thu, 17 Nov 2011 14:05:59 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 14:05:59 -0800 (PST)
In-Reply-To: <1321566545.5944.170.camel@minbar.fac.cs.cmu.edu>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu> <CAK3OfOhm3gh9Fa0hf+wQMc_QQckbWpjnKDJt6gY0YisPzdWXbQ@mail.gmail.com> <1321566545.5944.170.camel@minbar.fac.cs.cmu.edu>
Date: Thu, 17 Nov 2011 16:05:59 -0600
Message-ID: <CAK3OfOj_3ap-TUgemj5hbr=qZHPQm-Oyieossi=ogKreCr-Xwg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 22:06:58 -0000

On Thu, Nov 17, 2011 at 3:49 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> On Thu, 2011-11-17 at 14:20 -0600, Nico Williams wrote:
>> Say we use only req_flags for this. =C2=A0So the initiator sets one of
>> these flags, and the mechanism on the acceptor side honors it and
>> doesn't use the rcache. =C2=A0But the acceptor application has to check =
the
>> ret_flags and reject authentication if the flags are inappropriately
>> present -- if it doesn't then a replay attack is possible. =C2=A0Assumin=
g
>> the mechanism implementations on a server are updated is one thing;
>> assuming all the apps on it are too is a bit too much for me.
>
> OK, I can see how that applies to raw Kerberos, since only the app knows
> enough to know whether it is safe to avoid the rcache. =C2=A0But in the c=
ase
> of the Kerberos GSS-API mechanism, this shouldn't actually be an
> application-specific question, should it? =C2=A0The application shouldn't
> know anything about Kerberos, let alone whether it needs a replay cache.

Consider SASL/GS2 with the Kerberos mechanism.  The only way it's safe
to not rcache in that case is if the application is doing channel
binding to a secure channel that provides confidentiality protection.

There's nothing about GSS that makes it fundamentally not need an
rcache.  The situation is the same as for raw Kerberos.

>> I don't think it's always hard for admins to know whether it's safe to
>> enable this, but that's why this option must default to disabled.
>
> It's hard. =C2=A0Most admins don't understand the workings of everything =
on
> ...

Admins often already have options for disabling the rcache.  And they
have no secure rcache for clusters option.

You effectively assert that this proposed option makes things worse,
but have you considered the options that users have now (or don't have
now, as in the case of clusters)?  If so, please explain how this
option is worse than those.

> Yeah, you've convinced me it needs to be for negotiation to work.
>
> Unfortunately, that means you haven't gained anything.

I don't agree.  We gain a solution that works for clusters.

> I don't see why the client needs to be involved here at all. =C2=A0The ap=
p
> server knows whether the protocol supports rcache avoidance or not. =C2=
=A0The
> only reason to involve the client is to meet the non-mixing requirement,

So you do see why the client needs to be involved.

But I also think that adding context-descriptive elements is a good
thing -- I can't see how they cause harm, even if you think their
benefit in this case is marginal.

> by insuring that an application which cannot support rcache avoidance
> does not accept an AP-REQ intended for an application which may be doing
> rcache avoidance. =C2=A0But if you can't include non-upgraded application=
s in
> that set, you lose anyway.

Given the situation in the field, I disagree.

> I'm beginning to think the right answer is to always use different
> principal names for rcache-avoiding and rcache-requiring services.

That would be too disruptive.  You're letting perfection be the enemy
of good enough, thus risking a result that is worse than good enough
would be.  Moreover, over time my "good enough" becomes perfect.

Nico
--

From nico@cryptonector.com  Thu Nov 17 14:54:45 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8507021F94DF for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 14:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.034
X-Spam-Level: 
X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frZUmk2tAGuN for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 14:54:45 -0800 (PST)
Received: from homiemail-a32.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id A33BD21F94DC for <kitten@ietf.org>; Thu, 17 Nov 2011 14:54:43 -0800 (PST)
Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id F36D8584056 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:54:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AQJZn/e/EUTFqRPnO+xcGPHNIPuKRDj6GDgYWtzX1ENP IVtw+cTty0Hz8DGaAlFSbkzdOy57VMfF0u1MuzEwPhGxJa2l4/cWdPPeklj+H3US 6PHoppMDRzMs92HbJwBxLUOOoMUdaSiBVuO85p1el0FpKrypjmERDAeIAoqMLAs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Na4KVqunQARct45v72pfBwbNnTU=; b=azria9/GL0C VbX8TnOIe7/jRlMZ7N+1huqI+AeKU1ASm31+yYZ1u40W2fVNw/+X/TEinU38IJpv 77a754Puwx6TvNFQ6vM3FYKk9BKVHvUSAvodWqB6lQhKEFC3qWJ9p2n7J2teM52Q Fb9tQ8dNvP0f1UY09jW7f4K6Ab/79oOY=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id D0979584070 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:54:31 -0800 (PST)
Received: by pzk5 with SMTP id 5so3726794pzk.9 for <kitten@ietf.org>; Thu, 17 Nov 2011 14:54:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.30.68 with SMTP id q4mr3033114pbh.75.1321570467368; Thu, 17 Nov 2011 14:54:27 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 14:54:27 -0800 (PST)
In-Reply-To: <4EC56BB1.9050406@mit.edu>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu> <4EC56BB1.9050406@mit.edu>
Date: Thu, 17 Nov 2011 16:54:27 -0600
Message-ID: <CAK3OfOgFAa1SNQfJffELKYj=qa4eCpf2vz8ckZzunDg9XoEX9Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 22:54:45 -0000

[resend]

On Thu, Nov 17, 2011 at 2:16 PM, Greg Hudson <ghudson@mit.edu> wrote:
> On 11/17/2011 02:47 PM, Jeffrey Hutzelman wrote:
>> So, why make these non-critical? =C2=A0It sounds like they actually shou=
ld be
>> critical, which guarantees that acceptors which have _not_ been upgraded
>> will always reject an AP-REQ which contains them, which is what we want.
>
> "Guarantees" is overly strong here. =C2=A0Implementations don't tend to
> respect the RFC 4120 requirement of rejecting authenticators containing
> unknown authorization data. =C2=A0That said, I'm not sure what the point =
of
> the AD-IF-RELEVANT wrapper is.

See below:

> I think there's a more significant issue, though. =C2=A0Once we've added
> support to GSSAPI and krb5 implementations and client and server apps,
> how do new clients interoperate with old servers?

New clients/initiators set the authz-data (in AD-IF-RELEVANT); old
servers ignore it (and use the rcache). =C2=A0New servers shazring the same
credentials as still-in-use old servers disable this feature and
therefore ignore the authz-data and use the rcache. =C2=A0Nothing changes.

> The client doesn't have any meaningful input into whether an rcache is
> required. =C2=A0The server has all of the information to know that. =C2=
=A0We would

The initiator/client knows some contextual information and asserts it
(non-critically). =C2=A0The acceptor/server application does the same. =C2=
=A0The
acceptor mechanism decides if that means that the rcache is to not be
used.

This is why I propose *descriptive* options, not prescriptive ones.

> like the client to produce an authenticator which won't be accepted by
> an rcache-requiring server, but only if we know that the intended server
> will accept it. =C2=A0That's fodder for negotiation, not a client-side
> application flag. =C2=A0(Unfortunately, the only vehicles I can think of =
for
> negotiation are a ticket flag or a new mech OID, neither of which are
> very attractive.)

The only reason to negotiate anything here is old Kerberos
implementations mixed with new ones and wanting to still avoid the
rcache. =C2=A0We don't have negotiation in the Kerberos AP exchange, nor in
the Kerberos GSS mechanism. =C2=A0Therefore we can only say "don't do
that".

Nico
--

From ghudson@mit.edu  Thu Nov 17 14:55:21 2011
Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B414521F94E1 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 14:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level: 
X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsE5g4zcwiWh for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 14:55:15 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0903B21F94DF for <kitten@ietf.org>; Thu, 17 Nov 2011 14:55:14 -0800 (PST)
X-AuditID: 12074425-b7f116d0000008fe-61-4ec590d27179
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D2.6D.02302.2D095CE4; Thu, 17 Nov 2011 17:55:14 -0500 (EST)
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 pAHMtECM023211;  Thu, 17 Nov 2011 17:55:14 -0500
Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAHMt9Au017474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 17:55:10 -0500 (EST)
Message-ID: <4EC590CD.2010103@mit.edu>
Date: Thu, 17 Nov 2011 17:55:09 -0500
From: Greg Hudson <ghudson@MIT.EDU>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu> <4EC56BB1.9050406@mit.edu> <CAK3OfOgFAa1SNQfJffELKYj=qa4eCpf2vz8ckZzunDg9XoEX9Q@mail.gmail.com>
In-Reply-To: <CAK3OfOgFAa1SNQfJffELKYj=qa4eCpf2vz8ckZzunDg9XoEX9Q@mail.gmail.com>
X-Enigmail-Version: 1.4a1pre
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrXtpwlE/g5lnpS0mn5zAZHH9/Tl2 i6ObV7FYnLp2hM2BxePkmrdsHvtbj7F6vDx1jtFjyZKfTAEsUVw2Kak5mWWpRfp2CVwZf/be Yy44LlZxc31RA+M6oS5GTg4JAROJU5//MEPYYhIX7q1n62Lk4hAS2McosfHWaWYIZwOjxJG+ xUwgVUIC95gklm03AbF5BdQkZu+dwQhiswioSjw+sApsEpuAssTBs99YQGxRgRCJZxOes0HU C0qcnPkELC4ioClxfd5SsDizgLfE1hWbWEFsYQFjibZVM5kgFj9klHj5+yPYYk6BQIkdDYcZ IU6Vkdh/fD/QMg6gZnWJ9fOEIObIS2x/O4d5AqPQLCTrZiFUzUJStYCReRWjbEpulW5uYmZO cWqybnFyYl5eapGuhV5uZoleakrpJkZQ8LO7qO5gnHBI6RCjAAejEg+vlfVRPyHWxLLiytxD jJIcTEqivFzA2BHiS8pPqcxILM6ILyrNSS0+xCjBwawkwvvKAyjHm5JYWZValA+TkuZgURLn fb3DwU9IID2xJDU7NbUgtQgmK8PBoSTB6w0yVLAoNT21Ii0zpwQhzcTBCTKcB2i4B0gNb3FB Ym5xZjpE/hSjopQ4bwhIQgAkkVGaB9cLS06vGMWBXhHm9QKp4gEmNrjuV0CDmYAG5+45AjK4 JBEhJdXAuO10IGfE6cA14X69nnyH9TiK2sImMW0N3THVb0F/4/aw43cXBHBwGNaGh/GWrFjX MucLw8JkM9bOSdMev3LKd3wcI5LjrP1Qh6vg3Lqm3ncGmRLBtRXbX2tXPK1SFVnOtrlW7fXd pUssAnaqbjPU9ufh0ma8XjRPfs/+2QWPd130nTLzgfVzJZbijERDLeai4kQAPG1zFSkDAAA=
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Nov 2011 22:55:21 -0000

On 11/17/2011 03:28 PM, Nico Williams wrote:
>> I think there's a more significant issue, though.  Once we've added
>> support to GSSAPI and krb5 implementations and client and server apps,
>> how do new clients interoperate with old servers?
> New clients/initiators set the authz-data (in AD-IF-RELEVANT); old
> servers ignore it (and use the rcache).  New servers shazring the same
> credentials as still-in-use old servers disable this feature and
> therefore ignore the authz-data and use the rcache.  Nothing changes.
Let me see if I understand the proposal correctly.  For the sake of
argument, assume that the Kerberized telnet protocol needs a replay
cache but the gssapi-with-mic ssh protocol does not.  Then:

(1) New ssh + new client lib + new server lib + new sshd + configured-on
--> success without rcache

(1a) #1 except old ssh and/or old client lib --> success with rcache
(authz data isn't sent, authenticator might be used against telnet)
(1b) #1 except old server lib --> success with rcache (authz data isn't
recognized)
(1c) #1 except configured-off --> success with rcache (authz data isn't
honored)
(1d) #1 except old sshd and configured-off --> success with rcache
(authz data isn't honored)
(1e) #1 except old sshd --> failure (admin wasn't supposed to configure
this on until sshd is updated)

(2) New or old telnet + new or old client lib + new server lib + new
telnetd + configured-on --> success with rcache (authz data isn't sent)

(2a) #2 except buggy/rogue telnet client setting flags --> failure
(authz data sent, appears as if a replayed ssh authenticator)

The requirements of this proposal are:

* GSS implementors must implement it (obviously)

* Developers must identify when the protocol variation doesn't require
an rcache and set flags on the client and server as appropriate.
  - Clients inappropriately setting the flags will get #2a auth failures
against updated and servers on configured-on hosts.
  - Clients inappropriately failing to set the flags will get #1a
successes with rcache use (possible DOS issue, but no worse than today).
  - Servers inappropriately setting the flags will mostly behave as in
#2, but become vulnerable to replays in combination with buggy clients
used by legitimate users, on configured-on hosts (however, buggy clients
should be rare since they won't work against correct servers on
configured-on hosts).
  - Servers inappropriately failing to set the flags will get #1e auth
failures against updated clients on configured-on hosts.

* Server admins must only enable the feature after all servers
implementing rcache-avoidable protocols have been updated to set the flags.
  - Configuring the feature prematurely will result in #1e auth failures
from updated clients.

Is that all correct?  (All of this is intended as description, not
judgement.)


From nico@cryptonector.com  Thu Nov 17 16:09:14 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531F411E809B for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 16:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.033
X-Spam-Level: 
X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqbmHlf4YkU2 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 16:09:08 -0800 (PST)
Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 000CA11E8099 for <kitten@ietf.org>; Thu, 17 Nov 2011 16:09:07 -0800 (PST)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id A076A2AC072 for <kitten@ietf.org>; Thu, 17 Nov 2011 16:09:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=UKP28MlQ3Z+HwgKcRFNoG5MIpdHP/IOIoyZVi7jvjHwi MnFxH73Epad0U0Pzz+oHal3Pxs/DBoJo1BpCS58y0VJ5olDZFbdfOfp+UbNQzN1M 9FwSygqh0okzaq7yTRLkz9jA241WQHB7vcTvJup4JW2RHy6kJKdhL8lG8CBDzYg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=7nRX9hS0B/SFAyMf2J12ftFw2aE=; b=kE8AoQxG5V0 0UDiL5crRKdudRqThQpBsWVjnLi+NLe9oPhLkOunFdXSJdX9H6S1+oJObZuZ0rPL 2zE4CnI5IwOsWtaygdKsIDLhNX2WvKkFnFI4JQqBdgRLQdLmOVUWIPotr9GlijNg vSnf4trFuJonOpJwjlg+WytuHu/SDpNM=
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 75F382AC070 for <kitten@ietf.org>; Thu, 17 Nov 2011 16:09:07 -0800 (PST)
Received: by ywt34 with SMTP id 34so2168739ywt.31 for <kitten@ietf.org>; Thu, 17 Nov 2011 16:09:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.44.40 with SMTP id b8mr3539577pbm.41.1321574946555; Thu, 17 Nov 2011 16:09:06 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Thu, 17 Nov 2011 16:09:06 -0800 (PST)
In-Reply-To: <4EC590CD.2010103@mit.edu>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com> <1321559260.5944.57.camel@minbar.fac.cs.cmu.edu> <4EC56BB1.9050406@mit.edu> <CAK3OfOgFAa1SNQfJffELKYj=qa4eCpf2vz8ckZzunDg9XoEX9Q@mail.gmail.com> <4EC590CD.2010103@mit.edu>
Date: Thu, 17 Nov 2011 18:09:06 -0600
Message-ID: <CAK3OfOiQaVPWx9Cgg8WngpuRhfJLfA5vZ5mKQwbX_ndcvgvM9g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Nov 2011 00:09:14 -0000

On Thu, Nov 17, 2011 at 4:53 PM, Greg Hudson <ghudson@mit.edu> wrote:
> Let me see if I understand the proposal correctly. =C2=A0For the sake of
> argument, assume that the Kerberized telnet protocol needs a replay
> cache but the gssapi-with-mic ssh protocol does not. =C2=A0Then:

Sure.  This is not the most interesting case though because ssh will
send its security context tokens over a confidentiality-protecting
channel.  A better example would be to posit SASL/GS2 service that
accepts non-channel-bound contexts, and to make it interesting make it
two SASL/GS2 services using the same credentials.  But let's use the
example you give for now.

(Of course, your example is close to good enough because you could
configure telnetd to not require encryption and some clients might not
request it.  It's only the fact that ssh has a secure channel that
makes the example not so interesting.  Note too that an active
attacker impersonating the ssh server could play the client's AP-REQ
to telnetd, and if telnetd does not require encryption then they're
in, but they have to slam the door on the ssh client since the
attacker will be detected as a MITM otherwise.)

> (1) New ssh + new client lib + new server lib + new sshd + configured-on
> --> success without rcache

Yes.

> (1a) #1 except old ssh and/or old client lib --> success with rcache
> (authz data isn't sent, authenticator might be used against telnet)
> (1b) #1 except old server lib --> success with rcache (authz data isn't
> recognized)
> (1c) #1 except configured-off --> success with rcache (authz data isn't
> honored)
> (1d) #1 except old sshd and configured-off --> success with rcache
> (authz data isn't honored)

Also, even if configured on, if sshd is old then the rcache will be
used (because sshd won't set the new cred options).

> (1e) #1 except old sshd --> failure (admin wasn't supposed to configure
> this on until sshd is updated)

Yes.

There's also (1f), the case where telnetd is linked with an old
library but sshd is new and linked with a new library.  In that case
the failure is that sshd will not use an rcache, allowing a replay to
telnetd.

> (2) New or old telnet + new or old client lib + new server lib + new
> telnetd + configured-on --> success with rcache (authz data isn't sent)

Yes.

> (2a) #2 except buggy/rogue telnet client setting flags --> failure
> (authz data sent, appears as if a replayed ssh authenticator)

Yes.

> The requirements of this proposal are:
>
> * GSS implementors must implement it (obviously)

Yes :)

> * Developers must identify when the protocol variation doesn't require
> an rcache and set flags on the client and server as appropriate.

No.  Developers must describe the context.  If the app is using
channel binding to TLS with encryption then the app should set
GSS_C_CO_BOUND_TO_CONF_SEC_CHANNEL.  If the app protocol is such that
the client will send the first consequential per-message token, and
all consequential data will be protected, then the app should set
GSS_C_CO_IMPLIED_EXTRA_LEG.

I specifically want descriptive, not prescriptive options because I
don't think application developers should be deciding when an rcache
is needed or not.  They should describe what is or will happen and let
the mechanism decide when that means that the rcache is not needed.

> =C2=A0- Clients inappropriately setting the flags will get #2a auth failu=
res
> against updated and servers on configured-on hosts.

Yes, but such clients should not get deployed -- interop testing will find =
them.

(1e) is a very interesting case, but sysadmins will react to it by
disabling rcache avoidance, or not enabling it too soon in the first
place.

> =C2=A0- Clients inappropriately failing to set the flags will get #1a
> successes with rcache use (possible DOS issue, but no worse than today).

Right.

> =C2=A0- Servers inappropriately setting the flags will mostly behave as i=
n
> #2, but become vulnerable to replays in combination with buggy clients
> used by legitimate users, on configured-on hosts (however, buggy clients
> should be rare since they won't work against correct servers on
> configured-on hosts).

Yes.  But again, this is why the flags have to be descriptive, not prescrip=
tive.

There's other mistakes that a developer could make that destroy
security -and that we could not stop them from making- that bother me
as much as or more than this one.

> =C2=A0- Servers inappropriately failing to set the flags will get #1e aut=
h
> failures against updated clients on configured-on hosts.

Yes.  Servers and libraries have be upgraded both before enabling the featu=
re.

> * Server admins must only enable the feature after all servers
> implementing rcache-avoidable protocols have been updated to set the flag=
s.

It's a bit more subtle: all raw Kerberos and Kerberos GSS mech
libraries/providers must be upgraded, and all server applications that
should be setting these options (either always or sometimes) must be
upgraded, before enabling the feature.  And this is a host-wide
requirement, not a realm-wide requirement.

> =C2=A0- Configuring the feature prematurely will result in #1e auth failu=
res
> from updated clients.

Yes.

> Is that all correct? =C2=A0(All of this is intended as description, not
> judgement.)

With the above minor corrections/nits, yes.  Thank you for listing all
those cases!

Nico
--

From nico@cryptonector.com  Thu Nov 17 18:20:56 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A9A11E80A5 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 18:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level: 
X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5AWdJNw20A0 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 18:20:55 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC411E8097 for <kitten@ietf.org>; Thu, 17 Nov 2011 18:20:55 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 8823621DE56 for <kitten@ietf.org>; Thu, 17 Nov 2011 18:20:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=lVh8ATK+YUXyKwJtEMegW 6QOdQgs5eLaivgElatMauAqtu0JhIdkk8LupONcERhE+zLFV8KPfbdG/YPe+JKgr Ehw/PAmzcCKoQD5i6iPh9knnZESdHcx84XmsU0ukLQMjmtgCXvQKrPvi+OAqS5om SfcSxkwCdiS+7gtBLblRJE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=NWu90DeBHfFwATlCo0w5sFu 7IxU=; b=gRBCikfBi3n36DR+kuvFEc6L0/9BAGj6r3xodT+MA9vwtjZ3oiK8i50 KUK7sY+3gpOKnBvMvjemuMUIPoriSy61oxEr7r1KRClJCe7Nm9ItWQP31qMs7bah ZcKP9XAK8w0PbKeily9Eum9+V9yhCN8EYy+OoK4R3lVj08EiYYhA=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 52BC021DE55 for <kitten@ietf.org>; Thu, 17 Nov 2011 18:20:55 -0800 (PST)
Received: by vcbfl15 with SMTP id fl15so3148474vcb.31 for <kitten@ietf.org>; Thu, 17 Nov 2011 18:20:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.65.176 with SMTP id y16mr1340228vds.53.1321582507700; Thu, 17 Nov 2011 18:15:07 -0800 (PST)
Received: by 10.220.98.6 with HTTP; Thu, 17 Nov 2011 18:15:07 -0800 (PST)
In-Reply-To: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
References: <CAK3OfOho8ZjLFbuwNzdz+ff4LxuLzqQGmAFyT+v1HnFXMbiZ-A@mail.gmail.com>
Date: Thu, 17 Nov 2011 20:15:07 -0600
Message-ID: <CAK3OfOgOuk=bZ_AdrqkAMZZYkhBVC28P05ZcBRX+DN-6L6+ndw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: kitten@ietf.org, ietf-krb-wg@anl.gov
Content-Type: text/plain; charset=UTF-8
Subject: Re: [kitten] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Nov 2011 02:20:56 -0000

Something else that bears repeating is that practically all uses of
Kerberos AP exchanges or the Kerberos GSS mechanism don't need an
rcache or can be configured to never need an rcache:

 - No Internet protocol that uses the GSS-API other than SASL/GS2 and
HTTP/Negotiate needs an rcache except to protect other protocols that
do need an rcache;

 - No Internet protocol that uses raw Kerberos other than TELNET needs
an rcache except to protect other protocols that do need an rcache;

 - Most if not all proprietary protocols that use GSS that I've seen
so far don't need an rcache except to protect other protocols that do
need an rcache;

 - Protocols like rsh and TELNET don't need an rcache if configured
correctly (i.e., to always require encryption);

 - SASL/GS2 can be configured to not need an rcache (i.e., always
require channel binding to a channel that provides confidentiality
protection or unique CB);

 - HTTP/Negotiate can be used with channel binding, so it too can be
configured to not need an rcache;

To the extent that we need an rcache, we need it only during
migrations, until we can configure all services to not need an rcache
(or decommission services that can't be so configured).

In light of this, and of the fact that people regularly disable the
use of rcaches altogether (explicitly and implicitly), I don't think
the risk of admins accidentially enabling rcache avoidance too soon is
a big deal.

Independently of rcache avoidance (thoug perhaps accidentally because
of it), we should also explore the potential benefits of having
applications describe application protocol context to GSS mechanisms.

Nico
--

From mrex@sap.com  Thu Nov 17 20:02:50 2011
Return-Path: <mrex@sap.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B2811E80E1 for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 20:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.126
X-Spam-Level: 
X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuFg+0GQEASo for <kitten@ietfa.amsl.com>; Thu, 17 Nov 2011 20:02:49 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3108311E80D1 for <kitten@ietf.org>; Thu, 17 Nov 2011 20:02:49 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAI42eGH010945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2011 05:02:40 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201111180402.pAI42eqg024835@fs4113.wdf.sap.corp>
To: nico@cryptonector.com (Nico Williams)
Date: Fri, 18 Nov 2011 05:02:40 +0100 (MET)
In-Reply-To: <CAK3OfOgOuk=bZ_AdrqkAMZZYkhBVC28P05ZcBRX+DN-6L6+ndw@mail.gmail.com> from "Nico Williams" at Nov 17, 11 08:15:07 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Nov 2011 04:02:50 -0000

Nico Williams wrote:
> 
> Something else that bears repeating is that practically all uses of
> Kerberos AP exchanges or the Kerberos GSS mechanism don't need an
> rcache or can be configured to never need an rcache:
> 
>  - No Internet protocol that uses the GSS-API other than SASL/GS2 and
> HTTP/Negotiate needs an rcache except to protect other protocols that
> do need an rcache;

HTTP/Negotiate channel binding is optional, probably because
roughly half of the installed base (everything prior to Windows 7)
will _not_ send tls-unique channel bindings according to how
I understand Microsoft's Online documentation:

http://msdn.microsoft.com/en-us/library/dd919960%28v=vs.85%29.aspx

Btw. MIT Kerberos does not seem to support a smooth migration
for channel bindings.  If the server asserts channel bindings,
and the client didn't have channel bindings, security context
establishment will fail.  So you can not use MIT Kerberos in a
heterogeneous environment (=where only a fraction of the clients
is able to send channel bindings) unless no-one uses channel-bindings.

If you do not use a replay cache on the HTTP/Negotiate server at all,
then a passive observer could easily pick a non-channelbindings
plain Kerberos AP_REQ (like from an CIFS authentication) with that
server, insert it into an HTTP/Negotiate request and get served.

So all Authenticators from gssapi context establishments without
channel bindings need to be replay cached.

Even with replay cache in place, an attack might still be able
to observe a non-channel-bound Kerberos authentication on a shared
communication media (like ethernet) he could kill/corrupt the ethernet
frame before it has been completely sent and then insert the observed
AP_REQ into a HTTP-Negotiate request (while hogging the ethernet by
not leaving enough silence between his own ethernet frames for the
original sender to successfully resent the corrupted frame that
contained the orignal AP_REQ.


Does Microsoft really use at least SMB signing for CIFS and RPCs
by default?  I don't know the SMB/CIFS protocol details, how do both
ensure that signing is used (or code an MITM simply strip that)?
And what about the performance impact, is it really so insignificant
that nobody minds?


-Martin

From lukeh@padl.com  Fri Nov 18 06:01:34 2011
Return-Path: <lukeh@padl.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622A721F8B00 for <kitten@ietfa.amsl.com>; Fri, 18 Nov 2011 06:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level: 
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ofxp18XQztd for <kitten@ietfa.amsl.com>; Fri, 18 Nov 2011 06:01:34 -0800 (PST)
Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id D873121F8ABB for <kitten@ietf.org>; Fri, 18 Nov 2011 06:01:33 -0800 (PST)
Received: by us.padl.com  with ESMTP id pAIE1LBN024425; Fri, 18 Nov 2011 09:01:24 -0500
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <201111180402.pAI42eqg024835@fs4113.wdf.sap.corp>
Date: Sat, 19 Nov 2011 01:01:21 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B37222F-A518-40D8-84B0-139F50D7531C@padl.com>
References: <201111180402.pAI42eqg024835@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1251.1)
X-SMTP-Vilter-Version: 1.3.6
X-Spamd-Symbols: BAYES_00,USER_IN_WHITELIST
X-SMTP-Vilter-Spam-Backend: spamd
X-Spam-Threshold: 5.0
X-Spam-Probability: -20.5
Cc: kitten@ietf.org, ietf-krb-wg@anl.gov
Subject: Re: [kitten] [Ietf-krb-wg] rcache avoidance, take 3
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Nov 2011 14:01:34 -0000

> Btw. MIT Kerberos does not seem to support a smooth migration
> for channel bindings.  If the server asserts channel bindings,
> and the client didn't have channel bindings, security context
> establishment will fail.  So you can not use MIT Kerberos in a
> heterogeneous environment (=3Dwhere only a fraction of the clients
> is able to send channel bindings) unless no-one uses channel-bindings.

In SSPI this is just a flag to allow missing bindings, but GSS doesn't =
let the acceptor pass in a flag. But it could be done with a context or =
credential option.

> Does Microsoft really use at least SMB signing for CIFS and RPCs
> by default?  I don't know the SMB/CIFS protocol details, how do both
> ensure that signing is used (or code an MITM simply strip that)?
> And what about the performance impact, is it really so insignificant
> that nobody minds?


MS RPC avoids a replay cache (GSS_C_DCE_STYLE). Not for SMB AFAIK.

-- Luke=

From shawn.emery@oracle.com  Mon Nov 21 13:41:52 2011
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04011E8115 for <kitten@ietfa.amsl.com>; Mon, 21 Nov 2011 13:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzfV0BTa6VCj for <kitten@ietfa.amsl.com>; Mon, 21 Nov 2011 13:41:48 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9083C11E80FE for <kitten@ietf.org>; Mon, 21 Nov 2011 13:41:48 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pALLflBP016898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Mon, 21 Nov 2011 21:41:48 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pALLfktP020189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Mon, 21 Nov 2011 21:41:47 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pALLffbc011631 for <kitten@ietf.org>; Mon, 21 Nov 2011 15:41:41 -0600
Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Nov 2011 13:41:41 -0800
Message-ID: <4ECAC57E.9020506@oracle.com>
Date: Mon, 21 Nov 2011 14:41:18 -0700
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:7.0.1) Gecko/20111008 Thunderbird/7.0.1
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
Content-Type: multipart/alternative; boundary="------------030406090908060306010600"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4ECAC59C.0016,ss=1,re=0.000,fgs=0
Subject: [kitten] IETF 82 - session notes
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Nov 2011 21:41:52 -0000

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


The kitten-wg session notes have been uploaded here:

http://tools.ietf.org/wg/kitten/minutes

Please provide any feedback by 12/16/11.

Shawn.
--

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

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="+1"><tt><br>
        The kitten-wg session notes have been uploaded here:<br>
        <br>
        <a class="moz-txt-link-freetext" href="http://tools.ietf.org/wg/kitten/minutes">http://tools.ietf.org/wg/kitten/minutes</a><br>
        <br>
        Please provide any feedback by 12/16/11.<br>
        <br>
        Shawn.<br>
        --<br>
      </tt></font>
  </body>
</html>

--------------030406090908060306010600--

From hartmans@mit.edu  Tue Nov 22 09:53:16 2011
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7B21F8A69 for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 09:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.323
X-Spam-Level: 
X-Spam-Status: No, score=-103.323 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao55kHUYoOmk for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 09:53:16 -0800 (PST)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04821F88A0 for <kitten@ietf.org>; Tue, 22 Nov 2011 09:53:15 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (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 C27D520CF9; Tue, 22 Nov 2011 12:53:34 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F011A435A; Tue, 22 Nov 2011 12:52:58 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Nico Williams <nico@cryptonector.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com>
Date: Tue, 22 Nov 2011 12:52:58 -0500
In-Reply-To: <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> (Nico Williams's message of "Wed, 16 Nov 2011 21:27:32 -0600")
Message-ID: <tsl8vn8f3id.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
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Nov 2011 17:53:16 -0000

>>>>> "Nico" == Nico Williams <nico@cryptonector.com> writes:


    Nico> I think I want s/SHOULD/may/ here because the only way the
    Nico> mechglue could know if an attribute is "known" is by inquiring
    Nico> all its providers to see if it is.  

Unfortunately, I think I feel fairly strongly that this needs to be a
MUST not a SHOULD.
I agree that there are situations where you need to see if some external
system has permitted the attribute to be set.
In those situations you need to check the attribute is set.
However, there are a lot of cases--for example setting one of the
GSS-EAP attributes on a Kerberos MN, where you can determine it's not
going to work.
I think that it is important in the cases where the caller can catch the
error that we mandate it do so.
I feel quite strongly about this.

From nico@cryptonector.com  Tue Nov 22 10:18:09 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50721F877F for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 10:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.181
X-Spam-Level: 
X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EwFTuFc7eDt for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 10:18:08 -0800 (PST)
Received: from homiemail-a98.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C437321F8726 for <kitten@ietf.org>; Tue, 22 Nov 2011 10:18:08 -0800 (PST)
Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 81B1B2C2063 for <kitten@ietf.org>; Tue, 22 Nov 2011 10:18:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=om/yLwftyoLeuo+Wa6jLyYJceKIWzUQz4vKRh+f07UrO 8zCZS1hPdrk34qngYapNK1C0J9HiLnsy45h708nsUCyNxfjxPlQsdvEatnr8ktWQ sgSBMue+bUDMyKhly8yfgIn0Mu8mGVKcWCKC7VJfpmk+p8N/mSQ7w/z3m9ELc9Y=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=BVvRyd58sp9JIy1sdE2OKMrMyzU=; b=gTFD4x1Xt+E JT8V15aAA+vDJpv82AxWjlwrSD2IT7HiglvGi/hUX44cV7txcs7dxm4hioJOrQ4q 0hHMZUsUTA9K2R7Aq1S8rvHPeHz/b4WnUhCiU3D0OmrX032gArTgI01QTgKCG7O0 5DCt3sm9vTmkvZsezpd7B/KxUgjDHn4E=
Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 578B72C2062 for <kitten@ietf.org>; Tue, 22 Nov 2011 10:18:08 -0800 (PST)
Received: by qadb40 with SMTP id b40so604959qad.10 for <kitten@ietf.org>; Tue, 22 Nov 2011 10:18:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.25.170 with SMTP id d10mr272719pbg.7.1321985887142; Tue, 22 Nov 2011 10:18:07 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Tue, 22 Nov 2011 10:18:07 -0800 (PST)
In-Reply-To: <tsl8vn8f3id.fsf@mit.edu>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <tsl8vn8f3id.fsf@mit.edu>
Date: Tue, 22 Nov 2011 12:18:07 -0600
Message-ID: <CAK3OfOiMcfwkCMsMoqi4kFUTrSELti+nZDXj7XQPuF3SYq5V4g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Nov 2011 18:18:09 -0000

On Tue, Nov 22, 2011 at 11:52 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote=
:
> I agree that there are situations where you need to see if some external
system has permitted the attribute to be set.

Why is this not an application-specific problem? =C2=A0I.e., why should GSS
be solving this?

> I feel quite strongly about this.

But how would this be implemented if not with either local policy or
some protocol? =C2=A0If local policy then that means local configuration
needs updating when you want to add new attributes. =C2=A0Is that really
what you want? =C2=A0I feel quite strongly that I don't want that. =C2=A0If=
 some
protocol, well, what's it look like?

You've also not answered my question: why is "known" different from
"critical"? =C2=A0 Why is one solution (check after cred acquisition) OK
for one (criticality) but not the other?

Nico
--

From leifj@mnt.se  Tue Nov 22 14:21:34 2011
Return-Path: <leifj@mnt.se>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D786911E80B9 for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 14:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0sz0YU5h2v6 for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 14:21:32 -0800 (PST)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A002711E80E9 for <kitten@ietf.org>; Tue, 22 Nov 2011 14:21:30 -0800 (PST)
Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pAMMLHAT017232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Nov 2011 23:21:21 +0100 (CET)
Message-ID: <4ECC205D.4030609@mnt.se>
Date: Tue, 22 Nov 2011 23:21:17 +0100
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <tsl8vn8f3id.fsf@mit.edu> <CAK3OfOiMcfwkCMsMoqi4kFUTrSELti+nZDXj7XQPuF3SYq5V4g@mail.gmail.com>
In-Reply-To: <CAK3OfOiMcfwkCMsMoqi4kFUTrSELti+nZDXj7XQPuF3SYq5V4g@mail.gmail.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Nov 2011 22:21:34 -0000

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

On 11/22/2011 07:18 PM, Nico Williams wrote:
> On Tue, Nov 22, 2011 at 11:52 AM, Sam Hartman
> <hartmans-ietf@mit.edu> wrote:
>> I agree that there are situations where you need to see if some
>> external
> system has permitted the attribute to be set.
> 
> Why is this not an application-specific problem?  I.e., why should
> GSS be solving this?
> 
>> I feel quite strongly about this.
> 
> But how would this be implemented if not with either local policy
> or some protocol?  If local policy then that means local
> configuration needs updating when you want to add new attributes.
> Is that really what you want?  I feel quite strongly that I don't
> want that.  If some protocol, well, what's it look like?

Local config is *exactly* how this is handled in RP software today. For
instance Shibboleth require you to define your attributes in a config-
file.

	Cheers Leif

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

iEYEARECAAYFAk7MIF0ACgkQ8Jx8FtbMZneb1ACeJuFwGQ1F6f0BsM6MPP7pxK4c
AQgAnRN+Lv4XPo5xNS/VxVPEvXWGziL0
=fwS7
-----END PGP SIGNATURE-----

From nico@cryptonector.com  Tue Nov 22 14:23:29 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EB111E80EE for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 14:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.179
X-Spam-Level: 
X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBneXqYfw3G9 for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 14:23:28 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id ED87811E80B9 for <kitten@ietf.org>; Tue, 22 Nov 2011 14:23:28 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 9B47B674059 for <kitten@ietf.org>; Tue, 22 Nov 2011 14:23:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xWEz5MkoikBhGkJ6Ux76CeLZN5V8kFJ0d245YR+ZZcyq nk2JGU0gsTbEvwRNXbRnt/eA1TGLOHu1fd+JiMAuiZ1TMY7GB7dWpTSSWhDpm6pm wWgUTxTWewdqDZ/loMeiS0wNe5/iOwRuIq2MefLOWnvIPYs0meO03OuygApF+Vg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=+7W7vHwScoJ0eXcnJQ6P47S4i2U=; b=uoTkoqcn9vh ODDVmNZCKFdfgc/+8xPl1Mt5wnRRHdvHTaA4XCqzkaxz1zcnrI1d/TBrESFrdYe2 3JnaGxGXbCDGOG+WlOFOwU2kE0VpYyRfBH2CXAHQi/ag7wTOu77eDFgB0Hrxs+SJ i6bIjsiovnOZIssFc7wVLpvobPa8x3Iw=
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 7182F674058 for <kitten@ietf.org>; Tue, 22 Nov 2011 14:23:28 -0800 (PST)
Received: by qyk32 with SMTP id 32so716315qyk.31 for <kitten@ietf.org>; Tue, 22 Nov 2011 14:23:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.30.68 with SMTP id q4mr1986629pbh.75.1322000607139; Tue, 22 Nov 2011 14:23:27 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Tue, 22 Nov 2011 14:23:27 -0800 (PST)
In-Reply-To: <4ECC205D.4030609@mnt.se>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <tsl8vn8f3id.fsf@mit.edu> <CAK3OfOiMcfwkCMsMoqi4kFUTrSELti+nZDXj7XQPuF3SYq5V4g@mail.gmail.com> <4ECC205D.4030609@mnt.se>
Date: Tue, 22 Nov 2011 16:23:27 -0600
Message-ID: <CAK3OfOifFh7tVKEJKhY42r=dE0Rkck4+G3-0xikG--6NQEjZfA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Leif Johansson <leifj@mnt.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kitten@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Nov 2011 22:23:29 -0000

On Tue, Nov 22, 2011 at 4:21 PM, Leif Johansson <leifj@mnt.se> wrote:
> On 11/22/2011 07:18 PM, Nico Williams wrote:
>> But how would this be implemented if not with either local policy
>> or some protocol? =C2=A0If local policy then that means local
>> configuration needs updating when you want to add new attributes.
>> Is that really what you want? =C2=A0I feel quite strongly that I don't
>> want that. =C2=A0If some protocol, well, what's it look like?
>
> Local config is *exactly* how this is handled in RP software today. For
> instance Shibboleth require you to define your attributes in a config-
> file.

But why must this be something the mechglue (or mechanism provider)
provides?  This seems very much application-specific, not generic.

Nico
--

From stephen.farrell@cs.tcd.ie  Tue Nov 22 16:37:50 2011
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FE221F8AA8 for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 16:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.782
X-Spam-Level: 
X-Spam-Status: No, score=-101.782 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, MANGLED_SEX=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gY2Ta673Y3R for <kitten@ietfa.amsl.com>; Tue, 22 Nov 2011 16:37:50 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C2DB621F8A97 for <kitten@ietf.org>; Tue, 22 Nov 2011 16:37:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3714E171CBC for <kitten@ietf.org>; Wed, 23 Nov 2011 00:37:49 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:subject:mime-version:user-agent:from:date :message-id:received:received:x-virus-scanned; s=cs; t= 1322008668; bh=GPFjkz+6jarXHFlhOdtfL+wXdTouyf1je6fkt1yVymU=; b=C yGApZKx4ZdutrEuouQgRaUyDUqXrSTJiv9EiZGyYX8y+qFUSdc5tua3i8om1YuZS HCfaeS809LqGr6U8XA+/7P5mwan7OyzeV33iWso7SDhxgObhbzOO+hfXpSFR76f2 V96Hadd+rqvLwm7tOw0DAtBtpeVtwW0fnkYOaDdjpemfE7CU5BPceRsQNzMg1wBT wa7uvep7UAt0t4X5JpCFHRTXPntuWezsHwr3u701JR7EQsCJO4ofqk+aARhZ8dyJ i+eN/Z6gdfapSat6onLAK+y29HmOkZYx57mzMBYdo/ErHgbGvg7XWPUOzh9mR0L7 j984IHvGP7up3kczHI4ng==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id b3rNqBfXjUYq for <kitten@ietf.org>; Wed, 23 Nov 2011 00:37:48 +0000 (GMT)
Received: from [10.87.48.3] (unknown [86.42.182.28]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B5229171BFA for <kitten@ietf.org>; Wed, 23 Nov 2011 00:37:47 +0000 (GMT)
Message-ID: <4ECC405A.1000605@cs.tcd.ie>
Date: Wed, 23 Nov 2011 00:37:46 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: kitten@ietf.org
Content-Type: multipart/mixed; boundary="------------090304080907000702090808"
Subject: [kitten] AD review of draft-ietf-kitten-sasl-saml
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 00:37:50 -0000

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


Hi,

I've reviewed this and its ready or nearly ready for
IETF LC - I've a few questions though so I'm not sure.
(That's the first, numbered group in the attached.)

Let's see if there's changes needed or not and then
proceed. (IESG comments on the openid spec might also
be worth a look with respect to this when we get them
next week.)

Cheers,
S.

--------------090304080907000702090808
Content-Type: text/plain;
 name="kitten-sasl-saml.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="kitten-sasl-saml.txt"


questions:
----------

#1, 1.2 - what does "or similar integrity protected and
authenticated channels" mean? If you mean IPsec, then saying that
seems right.  The problem though is that people do say things like
this when they mean "use it in clear on the intranet" which is not
desirable here presumably. (I realise now I let this pass for the
openid spec but we could still fix that too;-) I'm sure we can come
up with a better wording that captures the WG's desired meaning but
doesn't leave open the option to just run this in clear.

#2, s2, what does "sends a domain" mean near the end of p5?

#3, s3.2 says that the SASL server "transmits" stuff to the IdP,
but there's no line for that in figure 2 - what's up there? Is it
sent via the client really? Be less confusing to say so, if so.  If
not, then I think something needs to change.

#4, s.3, says the client uses a "HTTP GET" - shouldn't that be
HTTPS?

#5, s3.2, the client "MUST handle" auth with the IdP - that seems
ambiguous - how's I test for it? Maybe s/MUST handle/handles/ since
that's really SAML, right?

#6, s3.2, what does it mean to say the client "relays the response
to the RP via HTTP(S)"? That makes the client sound like an HTTP
proxy which, I think, misleading.

#7 s4, the first para needs changes as were done with openid, e.g.
NORMATIVE isn't 2119 language etc.

minor, can be handled alongside IETF LC, or earlier, or not at all:
-------------------------------------------------------------------

general: you sometimes talk about the "SASL server" and other times
use "Relying Party" or RP, I think it'd be good to say those are
basically the same (or whatever is the case). That's nearly all
there, at the end of 3.2, but I think it might be better to just
say that those are the same thing near the front and then just use
one of the terms all the time after that. Should be clearer for
coders I'd hope.

s2, How is this about "non-HTTP Use Cases"? It seems much broader.
Suggest renaming the section, maybe to "Authentication Flow." 

s2, "some sort of cookie" is a bit vague - can't you do better?

s2, Why "must" the RP "remain untouched"? That may be resonable but
it doesn't seem like its a must - you could have chosen to modify
the IdP if you'd liked. Maybe s/must remain/is better/?

s2, is 3986 really a useful reference for the URI sent at step 3 on
p5? Isn't there some saml reference that'd be better?

s3.1, it might be useful to label the abnf as such (xml2rfc can
help with that a bit if you make it a figure with artwork of type
abnf).

s3.x, it'd be good to tie the sections here back to figure 2, e.g.
put stuff like "(message 2 in Figure 2)" in as parenthethic notes.

s6.1, is the encoding shown for steps 4, 5 and others obvious for
implementers? Maybe it is, but I was surprised.

nits:
-----

p3, s/We want to point out that the/The/
p3, s/is optional/is OPTIONAL/
p3, s/that uses/that use/
p3, s/to a maximum extent/to the maximum extent/
p3, s/The mechamsisms assumes/The mechanism assumes/
p3, s/will continued to/will continue to/
p4, s/Applicability Because/Because/
p5, s/RP now has/The RP now has/


--------------090304080907000702090808--

From internet-drafts@ietf.org  Wed Nov 23 06:12:51 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D318A21F8CA6; Wed, 23 Nov 2011 06:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsulfO33CC75; Wed, 23 Nov 2011 06:12:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC86521F8ACA; Wed, 23 Nov 2011 06:12:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111123141250.14132.8999.idtracker@ietfa.amsl.com>
Date: Wed, 23 Nov 2011 06:12:50 -0800
Cc: kitten@ietf.org
Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-07.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 14:12:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Authentication Technology Next=
 Generation Working Group of the IETF.

	Title           : A SASL & GSS-API Mechanism for OpenID
	Author(s)       : Eliot Lear
                          Hannes Tschofenig
                          Henry Mauldin
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-openid-07.txt
	Pages           : 23
	Date            : 2011-11-23

   OpenID has found its usage on the Internet for Web Single Sign-On.
   Simple Authentication and Security Layer (SASL) and the Generic
   Security Service Application Program Interface (GSS-API) are
   application frameworks to generalize authentication.  This memo
   specifies a SASL and GSS-API mechanism for OpenID that allows the
   integration of existing OpenID Identity Providers with applications
   using SASL and GSS-API.


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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt


From lear@cisco.com  Wed Nov 23 06:18:37 2011
Return-Path: <lear@cisco.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3F521F8B5E for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 06:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.066
X-Spam-Level: 
X-Spam-Status: No, score=-109.066 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCLhWrTbXHaA for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 06:18:37 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83221F8B6E for <kitten@ietf.org>; Wed, 23 Nov 2011 06:18:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=5212; q=dns/txt; s=iport; t=1322057916; x=1323267516; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to; bh=tLHj+g9faB7rBje80QM58Jgxynn+YSBByaYvyWV5h4k=; b=CEA5rekIG2ueG4y7141qNJZgyuF5KsnZeFgmeKAPr6XnfHTwHBtpBgKo IK/XbQZeMBBThcRteal1MOcE+bKg5YIl4MKGsG2417kax9WV7qraIlPGO /s+qRNpZD1K2wTV9HrsU9qCYU4l+cDJuN7+pMo7lK9wqWUVZs/gXl6L0N E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsMAI4AzU6Q/khM/2dsb2JhbAA7CYUBpGmBAYEFgXIBAQEEAQEBDwEQBEcLEAsEFAkhAgIPAhYwEwEFAgEBBRmHa5VqAYxZkWiHL4IdgRYElEiSCw
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800";  d="scan'208,217";a="122458802"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2011 14:18:24 +0000
Received: from dhcp-10-61-105-144.cisco.com (dhcp-10-61-105-144.cisco.com [10.61.105.144]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pANEIOYd005200 for <kitten@ietf.org>; Wed, 23 Nov 2011 14:18:24 GMT
Message-ID: <4ECD00AF.80409@cisco.com>
Date: Wed, 23 Nov 2011 15:18:23 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
CC: kitten@ietf.org
References: <20111123141250.14132.8999.idtracker@ietfa.amsl.com>
In-Reply-To: <20111123141250.14132.8999.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.3.3
Content-Type: multipart/alternative; boundary="------------000003050806000906000608"
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-07.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 14:18:37 -0000

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

Hi,

This version addresses the following issues that were raised in various
reviews, as discussed in Taipei:

  * Reference instead of copy OpenID specification;
  * Replace URIs for OpenID spec, as requested by OpenID foundation
  * Add explanation for transaction ID
  * Use HTTPS
  * Update references (3920->6120)
  * XRIs MUST NOT be used
  * Tighten security considerations.


Eliot

On 11/23/11 3:12 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.
>
> 	Title           : A SASL & GSS-API Mechanism for OpenID
> 	Author(s)       : Eliot Lear
>                           Hannes Tschofenig
>                           Henry Mauldin
>                           Simon Josefsson
> 	Filename        : draft-ietf-kitten-sasl-openid-07.txt
> 	Pages           : 23
> 	Date            : 2011-11-23
>
>    OpenID has found its usage on the Internet for Web Single Sign-On.
>    Simple Authentication and Security Layer (SASL) and the Generic
>    Security Service Application Program Interface (GSS-API) are
>    application frameworks to generalize authentication.  This memo
>    specifies a SASL and GSS-API mechanism for OpenID that allows the
>    integration of existing OpenID Identity Providers with applications
>    using SASL and GSS-API.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>

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

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    This version addresses the following issues that were raised in
    various reviews, as discussed in Taipei:<br>
    <br>
    <ul>
      <li>Reference instead of copy OpenID specification;</li>
      <li>Replace URIs for OpenID spec, as requested by OpenID
        foundation</li>
      <li>Add explanation for transaction ID</li>
      <li>Use HTTPS</li>
      <li>Update references (3920-&gt;6120)</li>
      <li>XRIs MUST NOT be used</li>
      <li>Tighten security considerations.</li>
    </ul>
    <p><br>
      Eliot<br>
    </p>
    On 11/23/11 3:12 PM, <a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> wrote:
    <blockquote
      cite="mid:20111123141250.14132.8999.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : A SASL &amp; GSS-API Mechanism for OpenID
	Author(s)       : Eliot Lear
                          Hannes Tschofenig
                          Henry Mauldin
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-openid-07.txt
	Pages           : 23
	Date            : 2011-11-23

   OpenID has found its usage on the Internet for Web Single Sign-On.
   Simple Authentication and Security Layer (SASL) and the Generic
   Security Service Application Program Interface (GSS-API) are
   application frameworks to generalize authentication.  This memo
   specifies a SASL and GSS-API mechanism for OpenID that allows the
   integration of existing OpenID Identity Providers with applications
   using SASL and GSS-API.


A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt">http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt</a>

Internet-Drafts are also available by anonymous FTP at:
<a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a>

This Internet-Draft can be retrieved at:
<a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt">ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt</a>

_______________________________________________
Kitten mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kitten@ietf.org">Kitten@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/kitten">https://www.ietf.org/mailman/listinfo/kitten</a>

</pre>
    </blockquote>
  </body>
</html>

--------------000003050806000906000608--

From cantor.2@osu.edu  Wed Nov 23 07:43:40 2011
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDAF21F8B42 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 07:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.138
X-Spam-Level: 
X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdWBBX-lgL2J for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 07:43:40 -0800 (PST)
Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id EB78D21F8B20 for <kitten@ietf.org>; Wed, 23 Nov 2011 07:43:38 -0800 (PST)
Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pANFhVHO023225 for <kitten@ietf.org>; Wed, 23 Nov 2011 10:43:37 -0500
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Wed, 23 Nov 2011 10:43:04 -0500
From: "Cantor, Scott" <cantor.2@osu.edu>
To: "kitten@ietf.org" <kitten@ietf.org>
Thread-Topic: Clarification on use of per-message tokens
Thread-Index: AQHMqfaVVyQr5i3To0u3R5dYbybUEw==
Date: Wed, 23 Nov 2011 15:42:56 +0000
Message-ID: <CAF27EB0.1A0C5%cantor.2@osu.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <880661c8-12d7-44b0-b6a3-f8dfbe095081>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.168; 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.226
Subject: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 15:43:40 -0000

Sam's helping me with some pointers on getting key derivation added to the
SAML-EC draft, but I had a general question. Am I correct in assuming that
one of the purposes of channel binding is to obviate the need for doing
sign/seal at the message layer?

Just trying to think about the use cases a bit.

-- Scott


From nico@cryptonector.com  Wed Nov 23 08:48:36 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68D81F0C36 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 08:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.177
X-Spam-Level: 
X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS0FIC4XsPx2 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 08:48:36 -0800 (PST)
Received: from homiemail-a97.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3D211E8099 for <kitten@ietf.org>; Wed, 23 Nov 2011 08:48:28 -0800 (PST)
Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 095BC28606D for <kitten@ietf.org>; Wed, 23 Nov 2011 08:48:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=L8SRWGR2V0ijQoXD5IoOK 8Y3LC/RVBKXLMZcpbl6D54yp/sv3y/Es9tZwDkdWNnperqFjnw3IIqonblL6VaRE gL/d79DvgLJAdQcCf/uxl6wmxjcjqXrWUdioD0lnXeqxXcxDL/6XZWKq/lJK23Ld ufKPCGgGnwahA+2OPNHnno=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=TReMB4MHFn6KTv+VK5ZP ZKMiU1s=; b=ujzc/0Y7uDGtAr7AfT4NpsI4sk7asWFxpLPvNGsSm5E11T5m4f6T BaS3DvN4i/3zKgPhLhSnrghHikn7D5x41NcgM/FHIVwQGdG7cqtbyuSnSPSmHDva 4fODJNiIXi7V5bqVA5qKdBULqbkcRIwqjZNt6Lvv0hdsB1v+cj5gts4=
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id D32F2286064 for <kitten@ietf.org>; Wed, 23 Nov 2011 08:48:27 -0800 (PST)
Received: by qadb14 with SMTP id b14so2748946qad.10 for <kitten@ietf.org>; Wed, 23 Nov 2011 08:48:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.55.103 with SMTP id r7mr9396407pbp.41.1322066543918; Wed, 23 Nov 2011 08:42:23 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Wed, 23 Nov 2011 08:42:23 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Wed, 23 Nov 2011 08:42:23 -0800 (PST)
In-Reply-To: <CAF27EB0.1A0C5%cantor.2@osu.edu>
References: <CAF27EB0.1A0C5%cantor.2@osu.edu>
Date: Wed, 23 Nov 2011 10:42:23 -0600
Message-ID: <CAK3OfOj1irDB5HR3KHQafXW-a8wm16w70OfVypPf79MPn4+sqg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Cantor, Scott" <cantor.2@osu.edu>
Content-Type: multipart/alternative; boundary=bcaec53aeec4b83fd104b2699a59
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 16:48:36 -0000

--bcaec53aeec4b83fd104b2699a59
Content-Type: text/plain; charset=UTF-8

On Nov 23, 2011 9:43 AM, "Cantor, Scott" <cantor.2@osu.edu> wrote:
>
> Sam's helping me with some pointers on getting key derivation added to the
> SAML-EC draft, but I had a general question. Am I correct in assuming that
> one of the purposes of channel binding is to obviate the need for doing
> sign/seal at the message layer?

Yes, but there are a number of standards-track Internet protocols that use
the GSS-API and its per-message tokens (DNS GSS-TSIG, SSHv2, RPCSEC_GSSv1,
SASL/GS1, ...).

Nico
--

--bcaec53aeec4b83fd104b2699a59
Content-Type: text/html; charset=UTF-8

<p>On Nov 23, 2011 9:43 AM, &quot;Cantor, Scott&quot; &lt;<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>&gt; wrote:<br>
&gt;<br>
&gt; Sam&#39;s helping me with some pointers on getting key derivation added to the<br>
&gt; SAML-EC draft, but I had a general question. Am I correct in assuming that<br>
&gt; one of the purposes of channel binding is to obviate the need for doing<br>
&gt; sign/seal at the message layer?</p>
<p>Yes, but there are a number of standards-track Internet protocols that use the GSS-API and its per-message tokens (DNS GSS-TSIG, SSHv2, RPCSEC_GSSv1, SASL/GS1, ...).</p>
<p>Nico<br>
-- </p>

--bcaec53aeec4b83fd104b2699a59--

From cantor.2@osu.edu  Wed Nov 23 09:21:29 2011
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48A921F8B4C for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 09:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.114
X-Spam-Level: 
X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuPd3CDaimCb for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 09:21:27 -0800 (PST)
Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF211E808B for <kitten@ietf.org>; Wed, 23 Nov 2011 09:21:26 -0800 (PST)
Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pANHL8TG019547; Wed, 23 Nov 2011 12:21:21 -0500
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Wed, 23 Nov 2011 12:20:28 -0500
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Nico Williams <nico103@gmail.com>
Thread-Topic: [kitten] Clarification on use of per-message tokens
Thread-Index: AQHMqf6XuXWmHmBPNEKcPukWASgqapW6tGWA
Date: Wed, 23 Nov 2011 17:20:27 +0000
Message-ID: <CAF29496.1A0E8%cantor.2@osu.edu>
In-Reply-To: <CAK3OfOj968rCt=LJTL1TPX2UbQEiM=xvifSSkmUkvSn3p2naFQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6ae6fdb8-9f61-4636-925e-5a6fc70db4b6>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.168; 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.225
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 17:21:29 -0000

On 11/23/11 11:39 AM, "Nico Williams" <nico103@gmail.com> wrote:

>Yes, but there are a number of standards-track Internet protocols that
>use the GSS-API and its per-message tokens (DNS GSS-TSIG, SSHv2,
>RPCSEC_GSSv1, SASL/GS1, ...).

One of the reasons I was asking is to figure out if it's worth thinking
about ways to establish the master key that would only be good ideas in
the presence of channel binding.

-- Scott


From nico@cryptonector.com  Wed Nov 23 10:23:41 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEC311E80A3 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 10:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level: 
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM-iLmQQpwyG for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 10:23:41 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8111E807F for <kitten@ietf.org>; Wed, 23 Nov 2011 10:23:23 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 6DF7759401E for <kitten@ietf.org>; Wed, 23 Nov 2011 10:23:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=GB7sAgDkCLv+psueQmmKB 92lZmliXcWyWYTcA2fwbOgVUDWXBjj/kKRmj+8bUNPbm1E/ltk/Q1mAk01Zh6oMU 2nbQcHqtMwANGWHVAn/VTTcw8+d+pfZ+J/1N3261C8+WGDsa5dBimLQ8SCKH8gDv 3BMws4vfTNBP1wCRtQC34w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rdYnHzNsyrfU/hasGuPf 0DWnOXY=; b=YA3piZ0FeKtMikx7oSHRk4GHTkb4Zz8yX2TLzG7n4IqDZgb6hXO+ 4iUnOrKtXtdABx34+DlkcUetf9xxXP7OJ/TF/l2ZjYXxU675s7dqsjDqQt5ONDAy SpQpuybE/KkCaGFm5W7mhpGhfxGNwzLJLpHHw7JWz/nuhzRbTvpfHbU=
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 43962594074 for <kitten@ietf.org>; Wed, 23 Nov 2011 10:23:08 -0800 (PST)
Received: by qadb14 with SMTP id b14so2864047qad.10 for <kitten@ietf.org>; Wed, 23 Nov 2011 10:23:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.10.138 with SMTP id i10mr10184009pbb.92.1322072587348; Wed, 23 Nov 2011 10:23:07 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Wed, 23 Nov 2011 10:23:07 -0800 (PST)
In-Reply-To: <CAF29496.1A0E8%cantor.2@osu.edu>
References: <CAK3OfOj968rCt=LJTL1TPX2UbQEiM=xvifSSkmUkvSn3p2naFQ@mail.gmail.com> <CAF29496.1A0E8%cantor.2@osu.edu>
Date: Wed, 23 Nov 2011 12:23:07 -0600
Message-ID: <CAK3OfOiGUuxbxqgywwdLUAeq7U0OH8m5BaZWmK3AYU3KKybWtQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Cantor, Scott" <cantor.2@osu.edu>
Content-Type: text/plain; charset=UTF-8
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 18:23:41 -0000

On Wed, Nov 23, 2011 at 11:20 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
> One of the reasons I was asking is to figure out if it's worth thinking
> about ways to establish the master key that would only be good ideas in
> the presence of channel binding.

I think it would only be a good idea to do that with unique and
private channel binding types anyways.

From cantor.2@osu.edu  Wed Nov 23 11:08:37 2011
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC411E809F for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 11:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.093
X-Spam-Level: 
X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFRMjumLSK63 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 11:08:37 -0800 (PST)
Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF511E8099 for <kitten@ietf.org>; Wed, 23 Nov 2011 11:08:37 -0800 (PST)
Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pANJ8RuM028618; Wed, 23 Nov 2011 14:08:31 -0500
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Wed, 23 Nov 2011 14:08:25 -0500
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Nico Williams <nico@cryptonector.com>
Thread-Topic: [kitten] Clarification on use of per-message tokens
Thread-Index: AQHMqf6XuXWmHmBPNEKcPukWASgqapW6tGWAgABlVID//7jUgA==
Date: Wed, 23 Nov 2011 19:08:23 +0000
Message-ID: <CAF2AE8E.1A107%cantor.2@osu.edu>
In-Reply-To: <CAK3OfOiGUuxbxqgywwdLUAeq7U0OH8m5BaZWmK3AYU3KKybWtQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0797c1f7-c735-4603-ba7e-09177b3aa330>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.40; 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.226
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 19:08:37 -0000

On 11/23/11 1:23 PM, "Nico Williams" <nico@cryptonector.com> wrote:

>On Wed, Nov 23, 2011 at 11:20 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
>> One of the reasons I was asking is to figure out if it's worth thinking
>> about ways to establish the master key that would only be good ideas in
>> the presence of channel binding.
>
>I think it would only be a good idea to do that with unique and
>private channel binding types anyways.

Ok, thanks. Trying to do this with bearer token clients is really an
exercise in "better than nothing" at the end of the day.

-- Scott


From nico@cryptonector.com  Wed Nov 23 12:16:28 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79511E80C7 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 12:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+WraKy4wRRL for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 12:16:28 -0800 (PST)
Received: from homiemail-a73.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4C11E80BB for <kitten@ietf.org>; Wed, 23 Nov 2011 12:16:28 -0800 (PST)
Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 6FE461F0084 for <kitten@ietf.org>; Wed, 23 Nov 2011 12:16:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=bL4lGG9uPOugYHfn88YiR 5AkoVh4oaZYOqP+HgIYUdqXAENN2kzLBosgpTa+HYTwbOn/Y6qyatCV4oRS7sSTl 1HEMYBY+bQys4kfGSbAhtOHspk77tlIxAwbf5t/UXwShRuz3wJe9FD06aeX7n7C6 3oeQJsOdy9tVYF9VTz/ebE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/EB2hn3AMVh9UR9BxQhd CjAJunY=; b=QLmz3G6D7OSv4huvKYMdJLhdGQhXmDargS+5ZI40K7Vr1/Ie4geS Y8pMpBpP6BInxz9yfL+3jv8IHVw7BFavyK5P+2FrMXLcER+k4jwUUAdfyWW/Pb+g qE0cFNJgOY4FpZQ2kvv52+UcJV0Hgw6qCDxOHhBPOYu/YLUw4w8uAVc=
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 3B0931F007C for <kitten@ietf.org>; Wed, 23 Nov 2011 12:16:27 -0800 (PST)
Received: by qadb14 with SMTP id b14so2986256qad.10 for <kitten@ietf.org>; Wed, 23 Nov 2011 12:16:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.55.103 with SMTP id r7mr10743806pbp.41.1322079386235; Wed, 23 Nov 2011 12:16:26 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Wed, 23 Nov 2011 12:16:26 -0800 (PST)
In-Reply-To: <CAF2AE8E.1A107%cantor.2@osu.edu>
References: <CAK3OfOiGUuxbxqgywwdLUAeq7U0OH8m5BaZWmK3AYU3KKybWtQ@mail.gmail.com> <CAF2AE8E.1A107%cantor.2@osu.edu>
Date: Wed, 23 Nov 2011 14:16:26 -0600
Message-ID: <CAK3OfOhfxLvT9nmUmN6H39NOx35CkT-bQzTLM_RHc3cHQov9gQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Cantor, Scott" <cantor.2@osu.edu>
Content-Type: text/plain; charset=UTF-8
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 20:16:28 -0000

On Wed, Nov 23, 2011 at 1:08 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> Ok, thanks. Trying to do this with bearer token clients is really an
> exercise in "better than nothing" at the end of the day.

Pretty much :)

You might as well send a nonce and declare it the session key.  No
real security is possible for per-message tokens, nor for CB, and you
depend entirely on the secure channel for authentication of the RP to
the initiator, but to the extent that applications depend on
per-message tokens, you can make them work (or, rather, not fail).

From cantor.2@osu.edu  Wed Nov 23 12:36:16 2011
Return-Path: <cantor.2@osu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5ED21F8558 for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 12:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.073
X-Spam-Level: 
X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NErRGQ+FH92q for <kitten@ietfa.amsl.com>; Wed, 23 Nov 2011 12:36:15 -0800 (PST)
Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 985C521F8557 for <kitten@ietf.org>; Wed, 23 Nov 2011 12:36:15 -0800 (PST)
Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pANKaDCE019600; Wed, 23 Nov 2011 15:36:13 -0500
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi; Wed, 23 Nov 2011 15:36:13 -0500
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Nico Williams <nico@cryptonector.com>
Thread-Topic: [kitten] Clarification on use of per-message tokens
Thread-Index: AQHMqf6XuXWmHmBPNEKcPukWASgqapW6tGWAgABlVID//7jUgIAAZtUA//+xs4A=
Date: Wed, 23 Nov 2011 20:36:11 +0000
Message-ID: <CAF2C0E1.1A12A%cantor.2@osu.edu>
In-Reply-To: <CAK3OfOhfxLvT9nmUmN6H39NOx35CkT-bQzTLM_RHc3cHQov9gQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <528a2e42-a13b-43fa-ad8d-7184ff1ce4db>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.171; 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.225
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on use of per-message tokens
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Nov 2011 20:36:16 -0000

On 11/23/11 3:16 PM, "Nico Williams" <nico@cryptonector.com> wrote:
>
>You might as well send a nonce and declare it the session key.

Well, my proposal was to have the IdP supply the key to both of them.
Mainly because the attacker would have to get access to the actual message
received by the client, not just the bearer assertion in the message.

-- Scott


From hartmans@mit.edu  Mon Nov 28 07:08:49 2011
Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0940321F8CE4 for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 07:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.851
X-Spam-Level: 
X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVr2ynkT7uli for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 07:08:48 -0800 (PST)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 85CFE21F8CE1 for <kitten@ietf.org>; Mon, 28 Nov 2011 07:08:45 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (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 1204B20188; Mon, 28 Nov 2011 10:09:10 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0BD664239; Mon, 28 Nov 2011 10:08:39 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Nico Williams <nico@cryptonector.com>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <tsl8vn8f3id.fsf@mit.edu> <CAK3OfOiMcfwkCMsMoqi4kFUTrSELti+nZDXj7XQPuF3SYq5V4g@mail.gmail.com> <4ECC205D.4030609@mnt.se> <CAK3OfOifFh7tVKEJKhY42r=dE0Rkck4+G3-0xikG--6NQEjZfA@mail.gmail.com>
Date: Mon, 28 Nov 2011 10:08:39 -0500
In-Reply-To: <CAK3OfOifFh7tVKEJKhY42r=dE0Rkck4+G3-0xikG--6NQEjZfA@mail.gmail.com> (Nico Williams's message of "Tue, 22 Nov 2011 16:23:27 -0600")
Message-ID: <tsllir09te0.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>
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Nov 2011 15:08:49 -0000

Is there any chance we could discuss this late this week (Thursday or
Friday)?

From wmills@yahoo-inc.com  Mon Nov 28 17:49:47 2011
Return-Path: <wmills@yahoo-inc.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB921F853E for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 17:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.184
X-Spam-Level: 
X-Spam-Status: No, score=-15.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82tPVK4RpsUQ for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 17:49:47 -0800 (PST)
Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by ietfa.amsl.com (Postfix) with SMTP id 9CE9021F84BB for <kitten@ietf.org>; Mon, 28 Nov 2011 17:49:44 -0800 (PST)
Received: from [98.139.52.195] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 29 Nov 2011 01:49:41 -0000
Received: from [98.139.52.169] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 29 Nov 2011 01:49:41 -0000
Received: from [127.0.0.1] by omp1052.mail.ac4.yahoo.com with NNFMP; 29 Nov 2011 01:49:41 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 330796.80351.bm@omp1052.mail.ac4.yahoo.com
Received: (qmail 73320 invoked by uid 60001); 29 Nov 2011 01:49:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322531380; bh=wuBVAD/H7mo8rUdt/ejzffe40f0CFHvI5XU05Rw2P8A=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Z7ABFJFOr0TDNQiRbOXs1HFaeDlg245GHTQbl8F7LS9Z9OGStBk2PFIlzuYV7JClykxjleP/4oS6FRw8o7pJR9j7uHzxsHJlcArZrppSUJy9ASWr2NpS2gu0wWXpcZjRZc3N1IP1rcNXeawnbt0/6njsLhqZ56iVawSVXTzWNoQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=XjHywPglEY4BAM5DLqQ50E3NFGbjy6CXX0neRSnzgg05eu3CdxOq37rJLqg0C9B79CsBrCQUZ9q9Bgy4aDCUEtzKJ5sHu6vFIzdqB1CLeLGrbnzPBOp/f0L9CFtYpWPqDluO57Kp8DhA1CblwU91V9wZredhSRXxc1ZKyymlWZ4=;
X-YMail-OSG: xNIQ_mgVM1msakpKxXxFAmE5HpEKmD1qT9uTbkdZ7ago0pX kzi2vbuLeLlsA0WE46w4iqyNZqvQlnRbLHkR8.3L_C8bByPxfgzne4t_iD7h zvR5V5u2lznDLh.Av5qdBDYoyMzvlWI4DqRn9BJ_exz_Sxj2wS8kHnrDk4ql qOaMjo1cuSkVajNTCn3HDmQhohq193Au4KzaCT7DamrOj3W1AcrnV_TG1xll .8crcC4z4ozV40KMKufC.faJqvzaQEtC3OFUpPq7l4iFbsbPks4buTjO2zSa if.KFpnfPTR3awy7f_VKNmh0yEx.kXGhrki6JfY7FLAHopXjhTfp8.qGfU2b aS4GP7ZnkN9ttPEIDAOqq914WZ6TtzL8jk4ckFus6QFM5grXhIGrYUiob16U MwH3Vwx2qbM4JcPd_XW.fsK2usJQrNxxygKGcMGC2MdY-
Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Mon, 28 Nov 2011 17:49:40 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
References: <20111123141250.14132.8999.idtracker@ietfa.amsl.com> <4ECD00AF.80409@cisco.com>
Message-ID: <1322531380.67305.YahooMailNeo@web31813.mail.mud.yahoo.com>
Date: Mon, 28 Nov 2011 17:49:40 -0800 (PST)
From: William Mills <wmills@yahoo-inc.com>
To: Eliot Lear <lear@cisco.com>, "kitten@ietf.org" <kitten@ietf.org>
In-Reply-To: <4ECD00AF.80409@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="767760015-1124355805-1322531380=:67305"
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-07.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills@yahoo-inc.com>
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Nov 2011 01:49:48 -0000

--767760015-1124355805-1322531380=:67305
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I've been asked to be a reviewer for this.=A0 My most profound question her=
e is around the choice to make the identity assertion by the OP to the RP o=
ut of band.=A0 This is a really significant choice as it puts a huge design=
 issue in the hands of the implementer, that the RP has to provide an HTTP =
entrypoint which implicitly has some form of RPC with the SASL enabled serv=
er to communicate the identity authenticated for a session.=A0 Why was this=
 choice made in favor of having the return form the OP presented in-band as=
 a SASL client message?=A0 =0A=0AIt seems like the choice is to minimize th=
e impact on the client so that a browser user agent can be used for the cli=
ent interaction with the OP.=0A=0AThanks,=0A=0A-bill
--767760015-1124355805-1322531380=:67305
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:Co=
urier New, courier, monaco, monospace, sans-serif;font-size:12pt">I've been=
 asked to be a reviewer for this.&nbsp; My most profound question here is a=
round the choice to make the identity assertion by the OP to the RP out of =
band.&nbsp; This is a really significant choice as it puts a huge design is=
sue in the hands of the implementer, that the RP has to provide an HTTP ent=
rypoint which implicitly has some form of RPC with the SASL enabled server =
to communicate the identity authenticated for a session.&nbsp; Why was this=
 choice made in favor of having the return form the OP presented in-band as=
 a SASL client message?&nbsp; <br><br>It seems like the choice is to minimi=
ze the impact on the client so that a browser user agent can be used for th=
e client interaction with the OP.<br><br>Thanks,<br><br>-bill<br><br><br></=
div></body></html>
--767760015-1124355805-1322531380=:67305--

From nico@cryptonector.com  Mon Nov 28 20:05:15 2011
Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C55611E809B for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 20:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.327
X-Spam-Level: 
X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FontmN7W5O75 for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 20:05:14 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id E108F11E8090 for <kitten@ietf.org>; Mon, 28 Nov 2011 20:05:07 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 7A0AC26C064 for <kitten@ietf.org>; Mon, 28 Nov 2011 20:05:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=kkw/8HsH+ILkFvDtRKJEP pLEJgDqLPuVjeeEda/mvRGz5k0/2hz5pu2GsesVMkY7OOD18bACu9NWI6SCywA9E J9qYXnDZVaP2067Z03CbWX34iMyZRwJAPDHFZ1yJ/bTRGkavepPeBz023xNkmaZc LCr5z+GHTphwPP5tYwL3lE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2sgop9eIip2pCSY4ulDk JFc9Dkg=; b=nC6lXa4IsmBaJ/Y6631X6VfJyIhn4HHGIOme1S2VdATOfUn6G7cf aTnPWMvgfGHPZ99ZJxUB3zU57fwqt1N5fPH3k4TT8XcSKHGUl7sCJBlF7NmZpJPs E9Z9gggRKQaZ3Dy2470Q1L4E+PmlNr2SjYiyVLP5umSR2r4bnqK1LII=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 6079D26C063 for <kitten@ietf.org>; Mon, 28 Nov 2011 20:05:07 -0800 (PST)
Received: by pzk5 with SMTP id 5so7300019pzk.9 for <kitten@ietf.org>; Mon, 28 Nov 2011 20:05:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.55.103 with SMTP id r7mr59251825pbp.41.1322539506817; Mon, 28 Nov 2011 20:05:06 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Mon, 28 Nov 2011 20:05:06 -0800 (PST)
In-Reply-To: <tsllir09te0.fsf@mit.edu>
References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <CAK3OfOgPYOe3CcrZ3AbC=CxdWVvG9sMPO1_Wqv=XyoSgfdy27Q@mail.gmail.com> <A62BD631-1E14-4E4E-9139-9F16D5CA08CA@padl.com> <CAK3OfOg7-CgKW_7tv4U6tkYXt973UoqNrEBG2qN+NWhmLRUECQ@mail.gmail.com> <4EA907E7.3080501@mnt.se> <CAK3OfOi_VStZAmbAJZ7P2AiPHDgyejVO6mnZhk-LDYCv4uB4Vw@mail.gmail.com> <4EA96C78.5010603@mnt.se> <CAK3OfOg+TA53SfLbbWknt0U_h-eb4OM+sTJpxhq_1=3gc5oH5Q@mail.gmail.com> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <CAK3OfOh+N393woPP6u+ui4CQb-UXd8WkR3yKpFJYiXGNOFqyjw@mail.gmail.com> <tsl8vn8f3id.fsf@mit.edu> <CAK3OfOiMcfwkCMsMoqi4kFUTrSELti+nZDXj7XQPuF3SYq5V4g@mail.gmail.com> <4ECC205D.4030609@mnt.se> <CAK3OfOifFh7tVKEJKhY42r=dE0Rkck4+G3-0xikG--6NQEjZfA@mail.gmail.com> <tsllir09te0.fsf@mit.edu>
Date: Mon, 28 Nov 2011 22:05:06 -0600
Message-ID: <CAK3OfOiOhihaoqfK0ei0GLZdZEdHBFOhCZbLJ7ua-2NdHNQe-Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Content-Type: text/plain; charset=UTF-8
Cc: kitten@ietf.org
Subject: Re: [kitten] new text for section 7.6
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Nov 2011 04:05:15 -0000

On Mon, Nov 28, 2011 at 9:08 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
> Is there any chance we could discuss this late this week (Thursday or
> Friday)?

Yes.  Ping me on either of those days.

From wmills@yahoo-inc.com  Mon Nov 28 22:24:57 2011
Return-Path: <wmills@yahoo-inc.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266C011E80AB for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 22:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.392
X-Spam-Level: 
X-Spam-Status: No, score=-16.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5sNO8igvG0h for <kitten@ietfa.amsl.com>; Mon, 28 Nov 2011 22:24:57 -0800 (PST)
Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with SMTP id 04FA311E80A5 for <kitten@ietf.org>; Mon, 28 Nov 2011 22:24:57 -0800 (PST)
Received: from [98.139.91.61] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
Received: from [98.139.91.28] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
Received: from [127.0.0.1] by omp1028.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 860187.37629.bm@omp1028.mail.sp2.yahoo.com
Received: (qmail 26413 invoked by uid 60001); 29 Nov 2011 06:24:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322547891; bh=NNkHqIZGSr14NpbQ7g1UMCG/5GgGEXftkQraqomPZ+0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BGzQR4JEoRclMU34nBM8NRSeIcf/1ziI3m1t4NKyORqFQ/2Q6yDNgpLb1gZzf/GLk4DrS6+/BqWY/bonVpV6FJJISDHUKdDiRFPesk/qt6rpMEGwVe+3FXm8zXCSUCNi0TaDxFM2s0JBqdIRkILTsoddHfHDiKgYPgwyiS3DaMo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nx/Kffth5avxdJsmMyr+VKofeEBmvSnvj66TCah7scFGKHbQ9b7lCYT8PBUioLNi0eYHfjiS8sK5NKsSQlVzTLx1waSq3uWfekgo4TiFoHTZI9ZXNVIZd6zF43+C+7XPPOZar0Hmqp3mij7MgBKhCK9HxLqof0FNFfWxWIqd9sM=;
X-YMail-OSG: oAfbI.EVM1l9LOQRTNENR97qWFXKO58mX2NX43bpfbivd_J 1r5IgT5zyRYVkOLD20qB9UMSKGGJCeDfSRV4U8jO73gdEtUXPCI1m3PhNj0c FgAjntANwKJ8uQLG8MWMbNnhdO0JWMbPvaFwKKuMJiPGPHoKJlEgVK4PjRTv MSfdISIKV9rzn04yjYzBH7dEdrPN35KIfnXpBXMBAIvU9QrMpfq6ziK5dhts SZNVyuEBoevz6tntPqB5VhEHzKGUpYd6Y6L3RVMH_HYcdK.WojE3ropQ0e2j o1AhsjVRXFI_ztYHIAfZZt5hYxmlehIHlI3ESt_PPsZ9vj6ZEknZIwko2CJh gAJpEqvUoGd6bCxkhgoGw2WZKcNmpQNajI8YLRDplQNNAbaWnrnjEIr7kMcz s.akoGvGyYSxN3b5W9BdiVwIjbtoAcT9KM0yTVlXzSSMD_VJY4Jje.kFhXBK AI5BieRavDY4Y0CK2XiXzz7ar1Spo2zJAY5DWFGBmN3BPtqb.lZPVZF8TiQS yDfv_A6A-
Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Mon, 28 Nov 2011 22:24:51 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
Message-ID: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Mon, 28 Nov 2011 22:24:51 -0800 (PST)
From: William Mills <wmills@yahoo-inc.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-kitten-sasl-openid.all@tools.ietf.org" <draft-ietf-kitten-sasl-openid.all@tools.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" <kitten@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills@yahoo-inc.com>
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Nov 2011 06:24:57 -0000

I have been selected as the Applications Area Review Team reviewer for this=
 draft (for background on apps-review, please see http://www.apps.ietf.org/=
content/applications-area-review-team). =0A=0APlease resolve these comments=
 along with any other Last Call comments you may receive. Please wait for d=
irection from your document shepherd or AD before posting a new version of =
the draft.=0A=0ADocument: draft-ietf-kitten-sasl-openid-07=0AReviewer: Will=
iam J. Mills=0AReview Date: November 28, 2011=0AIETF Last Call Date:=A0 Oct=
ober 25, 2011=0A=0AReview Summary:=0A=0AThis draft is almost ready for publ=
ication as a Proposed Standard, but should address the three major issues b=
elow before proceeding.=A0 Some minor issues and nits are also noted.=0A=0A=
Document Summary:=0A=0AThis document defines a pure SASL mechanism for Open=
ID, but it conforms to the new bridge between SASL and the GSS-API called G=
S2 [RFC5801], so it defines both a SASL and a GSS-API mechanism.=0A.=0A=0AM=
ajor Issues:=0A=0ASection=A0 1.2.=A0=A0Applicability:=A0 This section requi=
res TLS but channel binding is not supported by the mechanism.=A0 OpenID it=
self does not require TLS for client to relying party interactions, as inte=
grity can be assured with a MAC signature and replayability is dealt with i=
n the OpenID nonce.=A0 Requiring TLS does not appear to be based on the und=
erlying security profile of OpenID.=A0 If TLS is ot be required channel bin=
ding should be supported.=A0 If TLS is not required then there is the possi=
bility of a DOS against the return_to entrypoint returned to the user, send=
ing a false failure message.=0A=0A=0ASection 3.2 Authentication Request:=A0=
 In the second full paragraph defining transaction id, the language here pr=
obably isn't strong enough.=A0=A0=A0 What it says now is =0A=0A=A0=A0 The f=
orm of this transaction is left to the RP to decide, but =0A=A0=A0 SHOULD b=
e large enough to be resistant to being guessed or attacked.=0A=0A(Nit: At =
the very least "transaction" needs to be "transaction id") I think it would=
 be better if the current text is replaced with=0A=0A=A0=A0 The form of thi=
s transaction id is left to the implementer, but it=0A=A0=A0 MUST be resist=
ant to being guessed or attacked.=0A=0AI think MUST is justified here becau=
se the RP is possibly open to a DOS if the value is guessable.=A0 A paragra=
ph in the security considerations section might be warranted to talk about =
how to pick good unguessable values, although this has been done many times=
 in many different specs.=A0 Side comment: maybe we need an RFC just for th=
is and then everyone can cite it.=0A=0A3.3.=A0=A0Server Response=0A=0AThe p=
roblem I see here is that the result sent to the server that is "used to se=
t state in the server accordingly" is not guaranteed to provide a username=
=A0 that will be useful to the SASL endpoint.=A0 The RP might get a full em=
ail address, or might get a bare username.=A0 In the case of an IMAP server=
 supporting multiple domains this may be significant.=A0 The spec really sh=
ould define how the SASL identities are determined from the response from t=
he OP.=0A=0AIt's possible that this could be solved by moving 6.1 and makin=
g it 3.3.1.=A0 Identity mapping seems to fit better here than in security c=
onsiderations.=0A=0A=0AMinor issues:=0A=0AUser confusion on names: The prob=
lem I see is one of confusion for the user of an OpenID enabled SASL client=
 for Mail.=A0 Some endpoint will need to be given usrename, some will be gi=
ven an dOpenID endpoint.=A0 Clarifying language might be useful to guide th=
e client implementer.=A0 Is there a disocvery method that the client can us=
e ot go from a username/domain to the OpenID endpoint ot send to the RP?=0A=
=0AMore examples:=A0 I'd prefer to see an example of a failure flow include=
d.=A0 I tend to like examples though, and find them helpful in parsing the =
normative text.=0A=0A3.3.=A0=A0Server Response & 3.4.=A0=A0Error Handling &=
 5. Example=0A=0AThere's an inconsistency here I think could be better.=A0=
=A0In the Exmaple we have a success case where the client returns and empty=
 client message in order to prompt the server to finalize the SASL negotiat=
ion.=A0 In the error handling case we have an explicit continuation from th=
e client sending "=3D".=A0=A0 Is the "=3D" sign after the error return actu=
ally required or can this simply be an empty client message.=A0 This means =
if the client knows the negotiation is complete and has not gotten a result=
 it just always sends the empty message.=0A=0A=0ANits:=0A=0ASection 1, 4th =
para, first sentence:=A0 I would change "As currently envisioned, this mech=
anism is to allow" to "This mechanism allows".=0A=0ASection 1, 5th para, 2n=
d sentence: "will continued to be" change continued to continue.