From simon@josefsson.org Fri Oct 15 05:12:36 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00CD3A6AC1 for ; Fri, 15 Oct 2010 05:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqKMJOo1odwL for ; Fri, 15 Oct 2010 05:12:35 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 44C943A6C75 for ; Fri, 15 Oct 2010 05:11:49 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9FCCgPD008104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 15 Oct 2010 14:12:45 +0200 X-Hashcash: 1:22:101015:kitten@ietf.org::W9ybZfhqvm3ar6Lr:5cDR From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Fri, 15 Oct 2010 14:12:43 +0200 Message-ID: <87iq13k62s.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Subject: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 12:12:37 -0000 I'm implementing an API for RFC 5929 in GnuTLS and I'm having some troubles with the specification. Section 3.1 says: Description: The first TLS Finished message sent (note: the Finished struct, not the TLS record layer message containing it) in the most recent TLS handshake of the TLS connection being bound to (note: TLS connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). I don't follow the need for a distinction between connection and session here -- a TLS session resumption consists of a new TLS handshake and it exchanges new Finished messages. To be precise, is it the case that, for a resumed TLS session, the tls-unique CB is 1) the first TLS Finished message sent in the initial full TLS handshake? or 2) the first TLS Finished message sent in the abbreviated TLS handshake? In the former case, the text appears to be wrong because it refers to the most recent TLS handshake and not the initial full TLS handshake, and in the second case the distinction between session and connection does not seem to matter because the tls-unique CB data is always using the first Finished message exchanged in the latest TLS handshake? /Simon From mrex@sap.com Fri Oct 15 10:44:36 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07FF3A6B6A for ; Fri, 15 Oct 2010 10:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BFSKHgdZeJH for ; Fri, 15 Oct 2010 10:44:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 89E553A6984 for ; Fri, 15 Oct 2010 10:44:35 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o9FHjtGD021068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 19:45:55 +0200 (MEST) From: Martin Rex Message-Id: <201010151745.o9FHjs1q021417@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Fri, 15 Oct 2010 19:45:54 +0200 (MEST) In-Reply-To: <87iq13k62s.fsf@mocca.josefsson.org> from "Simon Josefsson" at Oct 15, 10 02:12:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal04 X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 17:44:36 -0000 Simon Josefsson wrote: > > I'm implementing an API for RFC 5929 in GnuTLS and I'm having some > troubles with the specification. Section 3.1 says: > > To be precise, is it the case that, for a resumed TLS session, the > tls-unique CB is > > 2) the first TLS Finished message sent in the abbreviated TLS handshake? Without having checked implementations, only 2) makes sense. Binding to the first Finished message that is exchanged helps in piggy-backing data onto that Finished message (e.g. TLS false start). But instead of channel bindings, the published TLS CB is about "connection state binding", because the binding changes with every renegotiation on existing channel. -Martin From Nicolas.Williams@oracle.com Fri Oct 15 11:40:21 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214583A6B07 for ; Fri, 15 Oct 2010 11:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBCqBmvpfFOY for ; Fri, 15 Oct 2010 11:40:17 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7583D3A684F for ; Fri, 15 Oct 2010 11:40:17 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FIfbk8004649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 18:41:39 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9F8Nm6t027646; Fri, 15 Oct 2010 18:41:36 GMT Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 688763621287167996; Fri, 15 Oct 2010 11:39:56 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 11:39:56 -0700 Date: Fri, 15 Oct 2010 13:39:51 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20101015183951.GA1635@oracle.com> References: <87iq13k62s.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87iq13k62s.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 18:40:21 -0000 On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote: > I'm implementing an API for RFC 5929 in GnuTLS and I'm having some > troubles with the specification. Section 3.1 says: > > Description: The first TLS Finished message sent (note: the Finished > struct, not the TLS record layer message containing it) in the most > recent TLS handshake of the TLS connection being bound to (note: TLS > connection, not session, so that the channel binding is specific to > each connection regardless of whether session resumption is used). > > I don't follow the need for a distinction between connection and session > here -- a TLS session resumption consists of a new TLS handshake and it > exchanges new Finished messages. Some people thought that we needed to be clear about this in case someone thought that the CB for a TLS connection were those of the handshake that created the session. You can see that that would be bad. > To be precise, is it the case that, for a resumed TLS session, the > tls-unique CB is > > 1) the first TLS Finished message sent in the initial full TLS > handshake? > > or > > 2) the first TLS Finished message sent in the abbreviated TLS handshake? (2). > In the former case, the text appears to be wrong because it refers to > the most recent TLS handshake and not the initial full TLS handshake, > and in the second case the distinction between session and connection > does not seem to matter because the tls-unique CB data is always using > the first Finished message exchanged in the latest TLS handshake? See above. From simon@josefsson.org Fri Oct 15 13:24:22 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FE33A6A73 for ; Fri, 15 Oct 2010 13:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkR6rDPSJLBI for ; Fri, 15 Oct 2010 13:24:21 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id E95133A63D2 for ; Fri, 15 Oct 2010 13:24:17 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9FKPXW7007037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Oct 2010 22:25:35 +0200 From: Simon Josefsson To: Nicolas Williams References: <87iq13k62s.fsf@mocca.josefsson.org> <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101015:kitten@ietf.org::dCRX3sd0xoO5c5Dh:6uOE X-Hashcash: 1:22:101015:nicolas.williams@oracle.com::1t79VqXEbUCVCoaA:XmSd Date: Fri, 15 Oct 2010 22:25:33 +0200 In-Reply-To: <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> (Nicolas Williams's message of "Fri, 15 Oct 2010 13:39:51 -0500") Message-ID: <87iq13dwzm.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:24:22 -0000 Nicolas Williams writes: > On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote: >> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some >> troubles with the specification. Section 3.1 says: >> >> Description: The first TLS Finished message sent (note: the Finished >> struct, not the TLS record layer message containing it) in the most >> recent TLS handshake of the TLS connection being bound to (note: TLS >> connection, not session, so that the channel binding is specific to >> each connection regardless of whether session resumption is used). >> >> I don't follow the need for a distinction between connection and session >> here -- a TLS session resumption consists of a new TLS handshake and it >> exchanges new Finished messages. > > Some people thought that we needed to be clear about this in case > someone thought that the CB for a TLS connection were those of the > handshake that created the session. You can see that that would be bad. Yes, but even after multiple re-readings I was still confused what the text really said. >> To be precise, is it the case that, for a resumed TLS session, the >> tls-unique CB is >> >> 1) the first TLS Finished message sent in the initial full TLS >> handshake? >> >> or >> >> 2) the first TLS Finished message sent in the abbreviated TLS handshake? > > (2). Good. That's what I implemented. For reference, the API we decided on is this one: http://www.gnu.org/software/gnutls/devel/manual/html_node/Channel-Bindings.html http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding /Simon From Nicolas.Williams@oracle.com Fri Oct 15 14:05:53 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6AB3A6B9D for ; Fri, 15 Oct 2010 14:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVotWF1DPPKw for ; Fri, 15 Oct 2010 14:05:52 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 954123A6A0F for ; Fri, 15 Oct 2010 14:05:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FL7CZo025363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 21:07:14 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9FL7CwV029201; Fri, 15 Oct 2010 21:07:12 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 689161841287176742; Fri, 15 Oct 2010 14:05:42 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 14:05:41 -0700 Date: Fri, 15 Oct 2010 16:05:37 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20101015210537.GC1635@oracle.com> References: <87iq13k62s.fsf@mocca.josefsson.org> <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> <87iq13dwzm.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87iq13dwzm.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:05:54 -0000 On Fri, Oct 15, 2010 at 10:25:33PM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > > On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote: > >> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some > >> troubles with the specification. Section 3.1 says: > >> > >> Description: The first TLS Finished message sent (note: the Finished > >> struct, not the TLS record layer message containing it) in the most > >> recent TLS handshake of the TLS connection being bound to (note: TLS > >> connection, not session, so that the channel binding is specific to > >> each connection regardless of whether session resumption is used). > >> > >> I don't follow the need for a distinction between connection and session > >> here -- a TLS session resumption consists of a new TLS handshake and it > >> exchanges new Finished messages. > > > > Some people thought that we needed to be clear about this in case > > someone thought that the CB for a TLS connection were those of the > > handshake that created the session. You can see that that would be bad. > > Yes, but even after multiple re-readings I was still confused what the > text really said. Sigh. It took a lot of negotiation to get text that made everyone happy. And it's still not good enough? But I think it's clear... Maybe it's just me. > >> 2) the first TLS Finished message sent in the abbreviated TLS handshake? > > > > (2). > > Good. That's what I implemented. For reference, the API we decided on > is this one: Good. (1) would be really difficult to implement, and for what benefit? (none, really). > http://www.gnu.org/software/gnutls/devel/manual/html_node/Channel-Bindings.html > http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding Awesome! Do you also support tls-server-end-point? Nico -- From simon@josefsson.org Fri Oct 15 14:20:52 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EE73A6D1B for ; Fri, 15 Oct 2010 14:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.658 X-Spam-Level: X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7+PZ30rgsW6 for ; Fri, 15 Oct 2010 14:20:50 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 885DB3A6A0F for ; Fri, 15 Oct 2010 14:20:49 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9FLM6WS010367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Oct 2010 23:22:08 +0200 From: Simon Josefsson To: Nicolas Williams References: <87iq13k62s.fsf@mocca.josefsson.org> <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> <87iq13dwzm.fsf@mocca.josefsson.org> <20101015210537.GC1635__2980.14151999286$1287176847$gmane$org@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101015:nicolas.williams@oracle.com::dJnLQs3Enlbuu+JO:28dQ X-Hashcash: 1:22:101015:kitten@ietf.org::PrsovqyHv+bducpw:6HpH Date: Fri, 15 Oct 2010 23:22:06 +0200 In-Reply-To: <20101015210537.GC1635__2980.14151999286$1287176847$gmane$org@oracle.com> (Nicolas Williams's message of "Fri, 15 Oct 2010 16:05:37 -0500") Message-ID: <87eibrrw1t.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:20:52 -0000 Nicolas Williams writes: > On Fri, Oct 15, 2010 at 10:25:33PM +0200, Simon Josefsson wrote: >> Nicolas Williams writes: >> >> > On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote: >> >> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some >> >> troubles with the specification. Section 3.1 says: >> >> >> >> Description: The first TLS Finished message sent (note: the Finished >> >> struct, not the TLS record layer message containing it) in the most >> >> recent TLS handshake of the TLS connection being bound to (note: TLS >> >> connection, not session, so that the channel binding is specific to >> >> each connection regardless of whether session resumption is used). >> >> >> >> I don't follow the need for a distinction between connection and session >> >> here -- a TLS session resumption consists of a new TLS handshake and it >> >> exchanges new Finished messages. >> > >> > Some people thought that we needed to be clear about this in case >> > someone thought that the CB for a TLS connection were those of the >> > handshake that created the session. You can see that that would be bad. >> >> Yes, but even after multiple re-readings I was still confused what the >> text really said. > > Sigh. It took a lot of negotiation to get text that made everyone > happy. And it's still not good enough? But I think it's clear... > Maybe it's just me. Describing a couple of different TLS flows (e.g., one normal, one resumed, one renegotiated) and what the binding should be in each case would have helped me. But the RFC is already published so there is no point now. >> >> 2) the first TLS Finished message sent in the abbreviated TLS handshake? >> > >> > (2). >> >> Good. That's what I implemented. For reference, the API we decided on >> is this one: > > Good. (1) would be really difficult to implement, and for what > benefit? (none, really). It wouldn't be that difficult to implement (1), just store the old finished messages together with the session data. One benefit would be that there is no renegotiation synchronization problem. I dislike it from a security perspective though, since I really want user authentication to be bound to the latest TLS handshake and not an earlier one. >> http://www.gnu.org/software/gnutls/devel/manual/html_node/Channel-Bindings.html >> http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding > > Awesome! > > Do you also support tls-server-end-point? Nope, but it should be possibly to implement using already existing APIs anyway. Still, it is on my todo list. One concern with the tls-server-end-point definition is that I'm not sure what to do if the local code don't implement the hash function used by the server certificate. Hopefully this won't be common in practice though. /Simon From Nicolas.Williams@oracle.com Fri Oct 15 15:03:37 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBDF3A6AC4 for ; Fri, 15 Oct 2010 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3WZYKP5h4Ce for ; Fri, 15 Oct 2010 15:03:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B92B13A68E0 for ; Fri, 15 Oct 2010 15:03:35 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FM4ur0015746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 22:04:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9FKoeAv012606; Fri, 15 Oct 2010 22:04:55 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 689302351287180188; Fri, 15 Oct 2010 15:03:08 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 15:03:08 -0700 Date: Fri, 15 Oct 2010 17:03:03 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20101015220303.GD1635@oracle.com> References: <87iq13k62s.fsf@mocca.josefsson.org> <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> <87iq13dwzm.fsf@mocca.josefsson.org> <20101015210537.GC1635__2980.14151999286$1287176847$gmane$org@oracle.com> <87eibrrw1t.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eibrrw1t.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 22:03:37 -0000 On Fri, Oct 15, 2010 at 11:22:06PM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > Sigh. It took a lot of negotiation to get text that made everyone > > happy. And it's still not good enough? But I think it's clear... > > Maybe it's just me. > > Describing a couple of different TLS flows (e.g., one normal, one > resumed, one renegotiated) and what the binding should be in each case > would have helped me. But the RFC is already published so there is no > point now. That would have made it quite lengthy, but, yes, that might have helped. Brevity, when concise, helps though, and we thought we had both attributes for the text. > >> http://www.gnu.org/software/gnutls/devel/manual/html_node/Channel-Bindings.html > >> http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding > > > > Awesome! > > > > Do you also support tls-server-end-point? > > Nope, but it should be possibly to implement using already existing APIs > anyway. Still, it is on my todo list. > > One concern with the tls-server-end-point definition is that I'm not > sure what to do if the local code don't implement the hash function used > by the server certificate. Hopefully this won't be common in practice > though. How can you verify the server cert if you don't have an implementation of the server cert's signature algorithm's hash algorithm?? (Answer: PKIX and TLS are different layers, and you might not have an implementation of that hash alg available to the TLS stack). Anyways, that brings up another issue: the application may negotiate CB types, for all we know, so it's important to know what CB types will be available. You might want to add a function that tells you what CB types are available for a given session. (Well, OK, the app could just ask for all CB types and then determine which are available that way.) Also, you might want an API by which to tell TLS which CB type the app will need, that way the TLS library can throw away CB data that won't be needed. Nico -- From simon@josefsson.org Sat Oct 16 00:06:26 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0652A3A6BD9 for ; Sat, 16 Oct 2010 00:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nlI7uVdkOXE for ; Sat, 16 Oct 2010 00:06:24 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 6D2FC3A6BDB for ; Sat, 16 Oct 2010 00:06:24 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9G77deg011114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 Oct 2010 09:07:41 +0200 From: Simon Josefsson To: Nicolas Williams References: <87iq13k62s.fsf@mocca.josefsson.org> <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> <87iq13dwzm.fsf@mocca.josefsson.org> <20101015210537.GC1635__2980.14151999286$1287176847$gmane$org@oracle.com> <87eibrrw1t.fsf@mocca.josefsson.org> <20101015220303.GD1635__47715.3865308084$1287180305$gmane$org@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101016:nicolas.williams@oracle.com::iBNLziKOcrkpVPyi:1AiK X-Hashcash: 1:22:101016:kitten@ietf.org::jx7iNagTdf4YRoKE:62JL Date: Sat, 16 Oct 2010 09:07:39 +0200 In-Reply-To: <20101015220303.GD1635__47715.3865308084$1287180305$gmane$org@oracle.com> (Nicolas Williams's message of "Fri, 15 Oct 2010 17:03:03 -0500") Message-ID: <87sk06r4xw.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 07:06:26 -0000 Nicolas Williams writes: >> Nope, but it should be possibly to implement using already existing APIs >> anyway. Still, it is on my todo list. >> >> One concern with the tls-server-end-point definition is that I'm not >> sure what to do if the local code don't implement the hash function used >> by the server certificate. Hopefully this won't be common in practice >> though. > > How can you verify the server cert if you don't have an implementation > of the server cert's signature algorithm's hash algorithm?? > (Answer: PKIX and TLS are different layers, and you might not have an > implementation of that hash alg available to the TLS stack). Yes, and there are other potential answers too -- e.g., no PKIX validation at all but instead trust SCRAM with channel binding to protect against MITM, or validation of PKIX material by a hard coded fingerprint or through a Keyassure approach. > Anyways, that brings up another issue: the application may negotiate CB > types, for all we know, so it's important to know what CB types will be > available. You might want to add a function that tells you what CB > types are available for a given session. (Well, OK, the app could just > ask for all CB types and then determine which are available that way.) > > Also, you might want an API by which to tell TLS which CB type the app > will need, that way the TLS library can throw away CB data that won't be > needed. Right it now it is inexpensive to store the tls-unique data, and the tls-server-end-point CB is possible to compute without storing anything more than what is already stored by the library. So I'll considering adding those APIs when I see a real practical need. Adding and maintaining new APIs has a high cost, so I don't want to add anything that isn't needed today. /Simon From alexey.melnikov@isode.com Sun Oct 17 23:51:26 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C743A6814 for ; Sun, 17 Oct 2010 23:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.842 X-Spam-Level: X-Spam-Status: No, score=-104.842 tagged_above=-999 required=5 tests=[AWL=-3.462, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95jxhBpQgQDE for ; Sun, 17 Oct 2010 23:51:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D69943A683F for ; Sun, 17 Oct 2010 23:51:25 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.33]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 18 Oct 2010 07:52:48 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CBA906B.2090704@isode.com> Date: Sun, 17 Oct 2010 06:58:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <87iq13k62s.fsf@mocca.josefsson.org> <20101015183951.GA1635__47201.7671251253$1287168112$gmane$org@oracle.com> <87iq13dwzm.fsf@mocca.josefsson.org> <20101015210537.GC1635__2980.14151999286$1287176847$gmane$org@oracle.com> <87eibrrw1t.fsf@mocca.josefsson.org> In-Reply-To: <87eibrrw1t.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] RFC 5929 tls-unique clarification? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 06:51:27 -0000 Simon Josefsson wrote: >Nicolas Williams writes: > > > >>On Fri, Oct 15, 2010 at 10:25:33PM +0200, Simon Josefsson wrote: >> >> >>>Nicolas Williams writes: >>> >>> >>> >>>>On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote: >>>> >>>> >>>>>I'm implementing an API for RFC 5929 in GnuTLS and I'm having some >>>>>troubles with the specification. Section 3.1 says: >>>>> >>>>> Description: The first TLS Finished message sent (note: the Finished >>>>> struct, not the TLS record layer message containing it) in the most >>>>> recent TLS handshake of the TLS connection being bound to (note: TLS >>>>> connection, not session, so that the channel binding is specific to >>>>> each connection regardless of whether session resumption is used). >>>>> >>>>>I don't follow the need for a distinction between connection and session >>>>>here -- a TLS session resumption consists of a new TLS handshake and it >>>>>exchanges new Finished messages. >>>>> >>>>> >>>>Some people thought that we needed to be clear about this in case >>>>someone thought that the CB for a TLS connection were those of the >>>>handshake that created the session. You can see that that would be bad. >>>> >>>> >>>Yes, but even after multiple re-readings I was still confused what the >>>text really said. >>> >>> >>Sigh. It took a lot of negotiation to get text that made everyone >>happy. And it's still not good enough? But I think it's clear... >>Maybe it's just me. >> >> >Describing a couple of different TLS flows (e.g., one normal, one >resumed, one renegotiated) and what the binding should be in each case >would have helped me. But the RFC is already published so there is no >point now. > > Sigh. You are right about that. We can submit an erratum. While it is not a substitute for an updated document, it can help implementors. From alexey.melnikov@isode.com Mon Oct 18 00:17:36 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AFF3A6CAE for ; Mon, 18 Oct 2010 00:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDMkkOzmCzNm for ; Mon, 18 Oct 2010 00:17:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F27FE3A6C86 for ; Mon, 18 Oct 2010 00:17:35 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.33]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 18 Oct 2010 08:19:02 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CBBF4DF.7010801@isode.com> Date: Mon, 18 Oct 2010 08:18:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: kitten@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] SCRAM (RF 5802) implementation in Java? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 07:17:37 -0000 Does anybody know of a Java SCRAM-SHA-1 implementation? Please reply privately. Thanks, Alexey From root@core3.amsl.com Thu Oct 21 16:00:02 2010 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 211553A6767; Thu, 21 Oct 2010 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021230002.211553A6767@core3.amsl.com> Date: Thu, 21 Oct 2010 16:00:02 -0700 (PDT) Cc: kitten@ietf.org Subject: [kitten] I-D Action:draft-ietf-kitten-sasl-saml-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 23:00:02 -0000 --NextPart 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 and GSS-API Mechanism for SAML Author(s) : K. Wierenga, et al. Filename : draft-ietf-kitten-sasl-saml-01.txt Pages : 26 Date : 2010-10-21 Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-sasl-saml-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21155751.I-D@ietf.org> --NextPart-- From simon@josefsson.org Thu Oct 21 17:06:33 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765AC3A65A5 for ; Thu, 21 Oct 2010 17:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxsB2fG1oqUi for ; Thu, 21 Oct 2010 17:06:32 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A30643A659C for ; Thu, 21 Oct 2010 17:06:31 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9M082fp014225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 22 Oct 2010 02:08:04 +0200 From: Simon Josefsson To: kitten@ietf.org References: <20101021230002.211553A6767@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101021:i-d-announce@ietf.org::yZly+1SttYESU8FU:1JWX X-Hashcash: 1:22:101021:kitten@ietf.org::oqHpJVxUpHuRT9ym:VZZf X-Hashcash: 1:22:101021:internet-drafts@ietf.org::gIOyalSV4aiCeAlZ:JE8P Date: Fri, 22 Oct 2010 02:08:02 +0200 In-Reply-To: <20101021230002.211553A6767@core3.amsl.com> (Internet-Drafts@ietf.org's message of "Thu, 21 Oct 2010 16:00:02 -0700 (PDT)") Message-ID: <87aam75btp.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Subject: Re: [kitten] I-D Action:draft-ietf-kitten-sasl-saml-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 00:06:33 -0000 Folks, We updated the draft below, and there is now at least one implementation of it -- see http://article.gmane.org/gmane.comp.gnu.gsasl.general/330 Protocol-wise, the main change between -00 and -01 is that server redirect is now actually and URI rather than a HTTP redirect response, which makes implementation and the protocol ABNF definition simpler. Another change is the addition of a security consideration section that explains why the mechanism needs to be used under a secure channel. It is not yet clear to me how this will interact with the GSS-API mechanism definition of SAML20 -- it seems the GSS-API mechanism would only be secure when used over a secure channel with server authentication. /Simon Internet-Drafts@ietf.org writes: > 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 and GSS-API Mechanism for SAML > Author(s) : K. Wierenga, et al. > Filename : draft-ietf-kitten-sasl-saml-01.txt > Pages : 26 > Date : 2010-10-21 > > Security Assertion Markup Language (SAML) has found its usage on the > Internet for Web Single Sign-On. Simple Authentication and Security > Layer (SASL) and the Generic Security Service Application Program > Interface (GSS-API) are application frameworks to generalize > authentication. This memo specifies a SASL mechanism and a GSS-API > mechanism for SAML 2.0 that allows the integration of existing SAML > Identity Providers with applications using SASL and GSS-API. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From shawn.emery@oracle.com Wed Oct 27 21:59:19 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1438A3A67ED for ; Wed, 27 Oct 2010 21:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWucG3t5IoNt for ; Wed, 27 Oct 2010 21:59:18 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0A8F63A67DF for ; Wed, 27 Oct 2010 21:59:17 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9S517P6002352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Oct 2010 05:01:08 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9S0eph9018722 for ; Thu, 28 Oct 2010 05:01:06 GMT Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 729614001288242038; Wed, 27 Oct 2010 22:00:38 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 22:00:37 -0700 Message-ID: <4CC90374.1090108@oracle.com> Date: Wed, 27 Oct 2010 23:00:36 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20100928 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------000306040803070909000106" Subject: [kitten] IETF 79 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 04:59:19 -0000 This is a multi-part message in MIME format. --------------000306040803070909000106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is the draft agenda for the upcoming session in Beijing: http://www.ietf.org/proceedings/79/agenda/kitten.txt Please let us know if you would like to add items to the session by November 1st. Shawn. kitten co-chair -- --------------000306040803070909000106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Here is the draft agenda for the upcoming session in Beijing:

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

Please let us know if you would like to add items to the session by November 1st.

Shawn.
kitten co-chair
--
 --------------000306040803070909000106-- From lear@cisco.com Wed Oct 27 22:53:42 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3DF3A67E3 for ; Wed, 27 Oct 2010 22:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.698 X-Spam-Level: X-Spam-Status: No, score=-104.698 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hkaYqwG1iAW for ; Wed, 27 Oct 2010 22:53:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 322023A67F3 for ; Wed, 27 Oct 2010 22:53:30 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkEABKtyEyQ/khLgWdsb2JhbACDDJ45FQEBFiIioxqKKpF3hFR0BIpT X-IronPort-AV: E=Sophos;i="4.58,249,1286150400"; d="scan'208,217";a="12161077" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Oct 2010 05:55:10 +0000 Received: from ams3-vpn-dhcp6061.cisco.com (ams3-vpn-dhcp6061.cisco.com [10.61.87.172]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9S5tA8t023087; Thu, 28 Oct 2010 05:55:10 GMT Message-ID: <4CC9105B.5000305@cisco.com> Date: Thu, 28 Oct 2010 07:55:39 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Shawn Emery References: <4CC90374.1090108@oracle.com> In-Reply-To: <4CC90374.1090108@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------010903060705060800000505" Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 79 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 05:53:42 -0000 This is a multi-part message in MIME format. --------------010903060705060800000505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Shawn, I will not be present in Beijing. I ask please that people send their comments to the list on draft-ietf-kitten-sasl-openid. Thanks, Eliot On 10/28/10 7:00 AM, Shawn Emery wrote: > > Here is the draft agenda for the upcoming session in Beijing: > > http://www.ietf.org/proceedings/79/agenda/kitten.txt > > Please let us know if you would like to add items to the session by > November 1st. > > Shawn. > kitten co-chair > -- > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------010903060705060800000505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Shawn,

I will not be present in Beijing.  I ask please that people send their comments to the list on draft-ietf-kitten-sasl-openid.

Thanks,

Eliot

On 10/28/10 7:00 AM, Shawn Emery wrote:

Here is the draft agenda for the upcoming session in Beijing:

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

Please let us know if you would like to add items to the session by November 1st.

Shawn.
kitten co-chair
--
 

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
--------------010903060705060800000505-- From hannes.tschofenig@gmx.net Wed Oct 27 23:22:42 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6EF3A682C for ; Wed, 27 Oct 2010 23:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.724 X-Spam-Level: X-Spam-Status: No, score=-100.724 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjTR-+8j9-hL for ; Wed, 27 Oct 2010 23:22:41 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 151043A6856 for ; Wed, 27 Oct 2010 23:22:27 -0700 (PDT) Received: (qmail invoked by alias); 28 Oct 2010 06:24:18 -0000 Received: from unknown (EHLO [10.254.0.90]) [192.100.123.77] by mail.gmx.net (mp007) with SMTP; 28 Oct 2010 08:24:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/sbS4Jma/s4VuB8kCXsb6LDoLfEl6A1Pqp/z8FEa oq50vFpli/bHGb Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4CC90374.1090108@oracle.com> Date: Thu, 28 Oct 2010 09:24:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CC90374.1090108@oracle.com> To: Shawn Emery X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 79 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 06:22:42 -0000 Hey Shawn,=20 could you put me on the agenda for the OAuth SASL draft?=20 Here is the pointer to the doc:=20 https://datatracker.ietf.org/doc/draft-mills-kitten-sasl-oauth/ Ciao Hannes On Oct 28, 2010, at 8:00 AM, Shawn Emery wrote: >=20 > Here is the draft agenda for the upcoming session in Beijing: >=20 > http://www.ietf.org/proceedings/79/agenda/kitten.txt >=20 > Please let us know if you would like to add items to the session by = November 1st. >=20 > Shawn. > kitten co-chair > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From alexey.melnikov@isode.com Thu Oct 28 03:57:08 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386473A683C for ; Thu, 28 Oct 2010 03:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vrwZsdQRidR for ; Thu, 28 Oct 2010 03:57:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 041FA3A67E1 for ; Thu, 28 Oct 2010 03:57:07 -0700 (PDT) Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 28 Oct 2010 11:58:57 +0100 Message-ID: <4CC95767.3060000@isode.com> Date: Thu, 28 Oct 2010 11:58:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shawn Emery References: <4CC90374.1090108@oracle.com> In-Reply-To: <4CC90374.1090108@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 79 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:57:08 -0000 Shawn Emery wrote: > > Here is the draft agenda for the upcoming session in Beijing: > > http://www.ietf.org/proceedings/79/agenda/kitten.txt > > Please let us know if you would like to add items to the session by > November 1st. I thought "Digest to Historic" is done and we are waiting for the WG chairs to do IESG write-up and request publication ;-). From cantor.2@osu.edu Thu Oct 28 07:00:08 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8693A6839 for ; Thu, 28 Oct 2010 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnF7Y9rM2vNX for ; Thu, 28 Oct 2010 07:00:07 -0700 (PDT) Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by core3.amsl.com (Postfix) with ESMTP id 11B3F3A67DA for ; Thu, 28 Oct 2010 07:00:05 -0700 (PDT) Received: from defang9.it.ohio-state.edu (defang9.it.ohio-state.edu [128.146.216.78]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9SE1vtm021906; Thu, 28 Oct 2010 10:01:57 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.160.224]) by defang9.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9SE1uPW023657; Thu, 28 Oct 2010 10:01:57 -0400 From: "Scott Cantor" To: "'Shawn Emery'" , References: <4CC90374.1090108@oracle.com> In-Reply-To: <4CC90374.1090108@oracle.com> Date: Thu, 28 Oct 2010 10:02:09 -0400 Organization: The Ohio State University Message-ID: <004b01cb76a8$b683b7e0$238b27a0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQH6bJqDmG4BQeXntdbhOeQLenlDoJL4d1Fw Content-language: en-us X-CanIt-Geo: ip=128.146.216.78; 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 Subject: Re: [kitten] IETF 79 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 14:00:08 -0000 > Please let us know if you would like to add items to the session by November > 1st. I won't be in Beijing but should be able to participate to some extent remotely and would like to ask for consideration of the SAML-EC mechanism as a WG draft. Current individual draft: https://datatracker.ietf.org/doc/draft-cantor-ietf-kitten-saml-ec/ Related work on Channel Bindings that will/would be incorporated into it: http://wiki.oasis-open.org/security/SAML2ChannelBindingExt http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile -- Scott From shawn.emery@oracle.com Fri Oct 29 11:40:16 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636023A695B for ; Fri, 29 Oct 2010 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skpAVZk1j21D for ; Fri, 29 Oct 2010 11:40:15 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1EEB13A683A for ; Fri, 29 Oct 2010 11:40:15 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9TIg5fF020584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 29 Oct 2010 18:42:08 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9TIg55a030621 for ; Fri, 29 Oct 2010 18:42:05 GMT Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 735079731288377614; Fri, 29 Oct 2010 11:40:14 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Oct 2010 11:40:14 -0700 Message-ID: <4CCB150D.6080800@oracle.com> Date: Fri, 29 Oct 2010 12:40:13 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20100928 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: kitten@ietf.org References: <4CC90374.1090108@oracle.com> In-Reply-To: <4CC90374.1090108@oracle.com> Content-Type: multipart/alternative; boundary="------------090302090605010200030901" Subject: Re: [kitten] IETF 79 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:40:16 -0000 This is a multi-part message in MIME format. --------------090302090605010200030901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've updated the agenda based on feed-back from the list, please review: http://www.ietf.org/proceedings/79/agenda/kitten.txt Shawn. kitten co-chair -- On 10/27/10 11:00 PM, Shawn Emery wrote: > > Here is the draft agenda for the upcoming session in Beijing: > > http://www.ietf.org/proceedings/79/agenda/kitten.txt > > Please let us know if you would like to add items to the session by > November 1st. > > Shawn. > kitten co-chair > -- > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------090302090605010200030901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I've updated the agenda based on feed-back from the list, please review:

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

Shawn.
kitten co-chair
--
On 10/27/10 11:00 PM, Shawn Emery wrote:

Here is the draft agenda for the upcoming session in Beijing:

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

Please let us know if you would like to add items to the session by November 1st.

Shawn.
kitten co-chair
--
 

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

--------------090302090605010200030901--