From stpeter@stpeter.im Thu Apr 4 21:05:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F421221F96A0 for ; Thu, 4 Apr 2013 21:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 1ccO-zYSOHgJ for ; Thu, 4 Apr 2013 21:05:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD6921F9699 for ; Thu, 4 Apr 2013 21:05:00 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B980D406D9 for ; Thu, 4 Apr 2013 22:14:49 -0600 (MDT) Message-ID: <515E4D5B.5050102@stpeter.im> Date: Thu, 04 Apr 2013 22:04:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> In-Reply-To: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 04:05:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I neglected to forward this last week. This version, and the updated PRECIS framework specification, address some of the feedback received from the KITTEN WG. https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Peter - -------- Original Message -------- Subject: I-D Action: draft-ietf-precis-saslprepbis-01.txt Date: Wed, 27 Mar 2013 20:39:51 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: precis@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-01.txt Pages : 13 Date : 2013-03-27 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXk1aAAoJEOoGpJErxa2pmooP/3AgLpW29CgC97E284t05dP5 FGQYFdLKNHXhXVfuBiyAERioAKtcS5hVuWUppv+7yIondZGkINgPO9SSM8PsZkn+ rZgQ1c13RgW3RMAOV0ZnhvXiZd85rk3V6IWWhhWr7Z+rM0kaG5JbqyHDN2+XwLvN jN9Ue4rrdSRc3Khx2ZqG4cN7LzSbWOs6LeID6+gJ3MA1HOaByE/CYu4DJ8HFIgxY tSFlEIPnpLxveBYpGtahbPMT+ft70bpVxjH/DqjbS4yxcpGqb3KAGd01E+DMDuio on0EvZOdSkU7Vu8EXfGNcSCQK5MpkpCkna6rOEUGNRYwW/h0o8Lx4BAwpzCH8viB 3mExMcJ6iGW3G82ZdueXmJqil+B/ueozXwogDQ/2KHa4DWwtDFzo1yM6TnZvOMgT Upp0UrcZecNycmUxPw9uPr4P+8XTur+8yHQdR1KjQ++yTY1AZNRm0E+GrxZRSEcs 5Bpnf4IPqEupCiSbqEdkLHFSdq8S+6OaCxLSzOsz7RKEy2yFzG3fF8IC5ZPHDXyG vWZe2zmzrcNnpk2zxzs7ZcERld1ABAyvr1Z9K1yWW2W72dmXjGCIE4YUD3KMBjQH AcYIs2PH1C2FbrrfeeZv0Tq3HXelqCd5lSgbT29kW5CtDKuKmmySYBWmyQSs8vax AOWt4IZoypsK4s8PkKPS =aOeS -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Apr 9 14:42:39 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF58A21F998B for ; Tue, 9 Apr 2013 14:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPWqmA-V-ydC for ; Tue, 9 Apr 2013 14:42:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3D11821F9986 for ; Tue, 9 Apr 2013 14:42:38 -0700 (PDT) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E7C2140D1E for ; Tue, 9 Apr 2013 15:52:42 -0600 (MDT) Message-ID: <51648B46.2020905@stpeter.im> Date: Tue, 09 Apr 2013 15:42:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: kitten@ietf.org References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> In-Reply-To: <515E4D5B.5050102@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:42:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris / Nico / others, please let us know if you do or do not find the revised text convincing with respect to simple user names. Thanks! Peter On 4/4/13 10:04 PM, Peter Saint-Andre wrote: > I neglected to forward this last week. This version, and the > updated PRECIS framework specification, address some of the > feedback received from the KITTEN WG. > > https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ > > https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ > > Peter > > -------- Original Message -------- Subject: I-D Action: > draft-ietf-precis-saslprepbis-01.txt Date: Wed, 27 Mar 2013 > 20:39:51 -0700 From: internet-drafts@ietf.org Reply-To: > internet-drafts@ietf.org To: i-d-announce@ietf.org CC: > precis@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Preparation and > Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation and Comparison of Internationalized > Strings Representing Simple User Names and Passwords Author(s) > : Peter Saint-Andre Alexey Melnikov Filename : > draft-ietf-precis-saslprepbis-01.txt Pages : 13 Date > : 2013-03-27 > > Abstract: This document describes how to handle Unicode strings > representing simple user names and passwords, primarily for > purposes of comparison. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN and SCRAM-SHA-1), as well as other protocols that exchange > simple user names or passwords. This document obsoletes RFC 4013. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ I-D-Announce > mailing list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZItFAAoJEOoGpJErxa2px9oP/itsu1Vwdp28JinzWktmwrwS 7cxQoboqsTQuDblkFEeQH67341bYlSgjSitiJe0wze1UpdW0+HZMrHD/FQIXv6V9 +AvUnpTS5jUFRxfZC5ZQyZ5H4MxzznbL+BDPGNCYZ8o7VfNMMP69uaIpmSKdBeAZ lDpd53HBpogSvLG2y6F9MoHGmQSoPYVDQOdk7kYlqLWFFT54O2UPLIg3zo9+kLBr 7jgwbPNThXclHcK0pjNSJ26h7qqLK6otkt82OV8LtCawjTEIH7Edc78Gy634qubc pCHU1HA3Aa2JhOrkDZEahr+p6IVIoc57mFWqcb4AQnp38PfiCzqgUkFSYdDPcwC7 K/nnTayq6GmECoFmpTlLdJ1Io6KsRVlm4QcylrRatHD/aobUbLGTYB0B6ilSFGl9 0p5SsvW1+FIN/XyCkpnRyupdnIg165mMZzv4uyTtGzIMst36RP3P777Exp7U3JfC xSShTPTkuXat6DpgjQPBS4XmApV2fSFJDQWu8rL/oEdwjznduqwXBmnuLExvwgUg zvkvYSGzUlQoGzoAmw4y7mSXgFSgmwgD+77krIC7gG+vjgvWFuP8dxAovHcdbZZ6 bohw0AW+sH0gWQUgXMFnm/IirYNHk1Qbnw/k2FEEJ0N8j+XBTGld8XkI/YS/a5QN XVBcoso/eomdv1ltQN+g =Os64 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Apr 10 23:41:11 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C0321F8E87; Wed, 10 Apr 2013 23:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 X-IfuXOViLEJ; Wed, 10 Apr 2013 23:41:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C16D21F8E8F; Wed, 10 Apr 2013 23:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130411064110.29519.86993.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 23:41:10 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 06:41:11 -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 Gen= eration Working Group of the IETF. Title : Initial and Pass Through Authentication Using Kerberos V= 5 and the GSS- API (IAKERB) Author(s) : Jim Schaad Larry Zhu Jeffery Altman Filename : draft-ietf-kitten-iakerb-00.txt Pages : 9 Date : 2013-04-10 Abstract: This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-iakerb-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Thu Apr 11 02:20:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0178921F8EB1 for ; Thu, 11 Apr 2013 02:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 Uyt7srtsAmue for ; Thu, 11 Apr 2013 02:20:56 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8C21F8ED5 for ; Thu, 11 Apr 2013 02:20:51 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 311442CA0C for ; Thu, 11 Apr 2013 02:20:45 -0700 (PDT) From: "Jim Schaad" To: References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> In-Reply-To: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2013 02:20:05 -0700 Message-ID: <001201ce3695$c13005e0$439011a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQInhc4BOAu809luPPTSMSXo7gVgypgeH7Zw Subject: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 09:20:57 -0000 This document is a match for the old krb-wg version of the document. A set of updates and questions will be forthcoming. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, April 10, 2013 11:41 PM > To: ietf@augustcellars.com > Cc: lzhu@microsoft.com; jaltman@secure-endpoints.com > Subject: New Version Notification for draft-ietf-kitten-iakerb-00.txt >=20 >=20 > A new version of I-D, draft-ietf-kitten-iakerb-00.txt has been = successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Filename: draft-ietf-kitten-iakerb > Revision: 00 > Title: Initial and Pass Through Authentication Using Kerberos V5 > and the GSS- API (IAKERB) > Creation date: 2013-04-10 > Group: kitten > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-kitten-iakerb-00.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb > Htmlized: = http://tools.ietf.org/html/draft-ietf-kitten-iakerb-00 >=20 >=20 > Abstract: > This document defines extensions to the Kerberos protocol and the > GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to > exchange messages with the KDC using the GSS-API acceptor as the > proxy, by encapsulating the Kerberos messages inside GSS-API = tokens. > With these extensions a client can obtain Kerberos tickets for > services where the KDC is not accessible to the client, but is > accessible to the application server. >=20 >=20 >=20 >=20 > The IETF Secretariat From ietf@augustcellars.com Thu Apr 11 11:56:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0021F8F6E for ; Thu, 11 Apr 2013 11:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.006 X-Spam-Level: X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[AWL=0.593, 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 n+5pcH1LEDOd for ; Thu, 11 Apr 2013 11:56:15 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8F221F8DFC for ; Thu, 11 Apr 2013 11:56:15 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 249772C9EE for ; Thu, 11 Apr 2013 11:56:15 -0700 (PDT) From: "Jim Schaad" To: References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> In-Reply-To: <001201ce3695$c13005e0$439011a0$@augustcellars.com> Date: Thu, 11 Apr 2013 11:55:34 -0700 Message-ID: <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQInhc4BOAu809luPPTSMSXo7gVgygHxuRa0mA8t9GA= Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 18:56:15 -0000 I have an updated version of this document that corrects the references to deal with published document. There is one blocking issue on this document that needs to be dealt with. In the next to last paragraph of section 3 there is a reference to [PKU2U] which, if you following the missing reference, is https://datatracker.ietf.org/doc/draft-zhu-pku2u/ This document is currently expired and, per Sam, was never intended to be a krb-wg document. We can either try and revive this document as well or just copy the sections dealing with GSS_EXTS_FINISHED. If we do the copy, then these sections appear to be: 1. The definition of it in section 6.3. I need to get a second set of eyes to determine which of the paragraphs need to be copied over. My current guess is: The last sentence of the paragraph that start "The 'cksum' fields of the" The ASN.1 blocks for GSS_EXTS_FINISHED and KRB-FINISHED The paragraph starting "The gss-mic field contains" I believe the last 3 paragraphs in the section are omitted. 2. The paragraph dealing with GSS_EXTS_FINISHED in section 10 (IANA) 3. Is an ASN.1 module needed or not? Once this is finished then a new WG Last call is going to need to be done. Jim > -----Original Message----- > From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Thursday, April 11, 2013 2:20 AM > To: kitten@ietf.org > Subject: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb- > 00.txt > > This document is a match for the old krb-wg version of the document. > > A set of updates and questions will be forthcoming. > > Jim > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, April 10, 2013 11:41 PM > > To: ietf@augustcellars.com > > Cc: lzhu@microsoft.com; jaltman@secure-endpoints.com > > Subject: New Version Notification for draft-ietf-kitten-iakerb-00.txt > > > > > > A new version of I-D, draft-ietf-kitten-iakerb-00.txt has been > > successfully submitted by Jim Schaad and posted to the IETF repository. > > > > Filename: draft-ietf-kitten-iakerb > > Revision: 00 > > Title: Initial and Pass Through Authentication Using Kerberos V5 > > and the GSS- API (IAKERB) > > Creation date: 2013-04-10 > > Group: kitten > > Number of pages: 9 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-kitten-iakerb- > 00.txt > > Status: http://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb > > Htmlized: http://tools.ietf.org/html/draft-ietf-kitten-iakerb-00 > > > > > > Abstract: > > This document defines extensions to the Kerberos protocol and the > > GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to > > exchange messages with the KDC using the GSS-API acceptor as the > > proxy, by encapsulating the Kerberos messages inside GSS-API tokens. > > With these extensions a client can obtain Kerberos tickets for > > services where the KDC is not accessible to the client, but is > > accessible to the application server. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From ghudson@mit.edu Thu Apr 11 13:39:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6F021E8041 for ; Thu, 11 Apr 2013 13:39:58 -0700 (PDT) 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=[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 NkY44050NI4W for ; Thu, 11 Apr 2013 13:39:58 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0E23821E803F for ; Thu, 11 Apr 2013 13:39:57 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-45-51671f9d4e08 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 72.92.21847.D9F17615; Thu, 11 Apr 2013 16:39:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r3BKduYL006322; Thu, 11 Apr 2013 16:39:56 -0400 Received: from [18.101.8.162] (VPN-18-101-8-162.MIT.EDU [18.101.8.162]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r3BKdgXK025059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Apr 2013 16:39:55 -0400 Message-ID: <51671F8E.3050701@mit.edu> Date: Thu, 11 Apr 2013 16:39:42 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jim Schaad References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> In-Reply-To: <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT150rnx5osPWfkMXq6d/ZLI5uXsXi wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGXcmdzEWrCTq+L+uT2sDYy7OLoYOTkkBEwk GpY+Z4KwxSQu3FvP1sXIxSEksI9R4sufk6wQzkZGiSVLbzBCOEeYJD4dm8oG0sIroCZxbOIO FhCbRUBV4v6lb+wgNpuAssTBs9/A4qICIRIXn25hhagXlDg58wlYXERAXWLr6ptgq5kFhCUu bN8LViMsECaxuHE+1BkrGSW+nTkJNJSDg1PAQWL+qkiIUyUlFk3rZIHo1ZF41/eAGcKWl9j+ dg7zBEahWUjWzUJSNgtJ2QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxhB oc0pybuD8d1BpUOMAhyMSjy8L4TTA4VYE8uKK3MPMUpyMCmJ8vrJAYX4kvJTKjMSizPii0pz UosPMUpwMCuJ8MbsTQsU4k1JrKxKLcqHSUlzsCiJ815JuekvJJCeWJKanZpakFoEk5Xh4FCS 4J0FMlSwKDU9tSItM6cEIc3EwQkynAdoeBxIDW9xQWJucWY6RP4Uo6KUOG8dSEIAJJFRmgfX C0s9rxjFgV4R5t0AUsUDTFtw3a+ABjMBDTbsTwEZXJKIkJJqYGxsiy8XkrVmXLROvX7HecbS wL1rbV9EnjcNX8QnO3NG6evLvjW7cmeELKwxuN0Z8vat8us7Ahnb5t/0FGvfbSo0b8valwx/ KwymXQhT23RK8Yyu7ezQFY1Z2vJXo1lv7vrxrup7lcwP/hlb5l3qvrrSz/0FCx9bk+j907fv n1ny+qxrLpeG2VclluKMREMt5qLiRADEmCIkGAMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:39:59 -0000 Unfortunately, I have another issue to raise. We implemented IAKERB for MIT krb5 1.9, but due to an oversight, we implemented draft-zhu-ws-kerb-03 instead of draft-ietf-krb-wg-iakerb-02. Looking at the two drafts briefly, it appears that: * Both use the same mech OID, the same IAKERB_PROXY token format, and the same error codes. Both require an authenticator subkey in the AP-REQ. * The two drafts define the "finished" extension slightly differently: - draft-zhu-ws-kerb-03 defines the data type as TBD and a key usage of 42. In MIT krb5 1.9, we used an extension type of 1. - draft-ietf-krb-wg-iakerb-02 refers to draft-zhu-pku2u-09, which uses an extension type of 2 and a key usage of 41. The two drafts use functionally identical ASN.1 sequences, checksum contents, and checksum keys. They use different names for the data type, ASN.1 type name, and ASN.1 sequence field name, but those have no impact on the wire encoding. Because of the differences in data type and key usage, the two drafts are not interoperable. Conceivably an acceptor could allow both versions of the finished extension, but an initiator would have to guess at what the other end can accept. The only other IAKERB implementation I'm aware of is in OSX, which appears to implement draft-ietf-krb-wg-iakerb-02. From ietf@augustcellars.com Thu Apr 11 14:26:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03721F8E5C for ; Thu, 11 Apr 2013 14:26:20 -0700 (PDT) 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=[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 h89ie1OLlZlJ for ; Thu, 11 Apr 2013 14:26:19 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6B021F8A0B for ; Thu, 11 Apr 2013 14:26:19 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 0E21438F1A; Thu, 11 Apr 2013 14:26:19 -0700 (PDT) From: "Jim Schaad" To: "'Greg Hudson'" References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> <51671F8E.3050701@mit.edu> In-Reply-To: <51671F8E.3050701@mit.edu> Date: Thu, 11 Apr 2013 14:25:39 -0700 Message-ID: <006301ce36fb$1dc3b760$594b2620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQInhc4BOAu809luPPTSMSXo7gVgygHxuRa0AVJmqS0Br5xmXJf3TIXQ Cc: kitten@ietf.org Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:26:20 -0000 We can easily define both numbers as extensions and say that servers must do both, so that does not seem to be a big deal. Is there any difference between the key usage of 41 and r2 that is significant? Jim > -----Original Message----- > From: Greg Hudson [mailto:ghudson@MIT.EDU] > Sent: Thursday, April 11, 2013 1:40 PM > To: Jim Schaad > Cc: kitten@ietf.org > Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb- > 00.txt > > Unfortunately, I have another issue to raise. > > We implemented IAKERB for MIT krb5 1.9, but due to an oversight, we > implemented draft-zhu-ws-kerb-03 instead of draft-ietf-krb-wg-iakerb-02. > Looking at the two drafts briefly, it appears that: > > * Both use the same mech OID, the same IAKERB_PROXY token format, and > the same error codes. Both require an authenticator subkey in the AP-REQ. > > * The two drafts define the "finished" extension slightly differently: > > - draft-zhu-ws-kerb-03 defines the data type as TBD and a key usage of 42. In > MIT krb5 1.9, we used an extension type of 1. > > - draft-ietf-krb-wg-iakerb-02 refers to draft-zhu-pku2u-09, which uses an > extension type of 2 and a key usage of 41. > > The two drafts use functionally identical ASN.1 sequences, checksum > contents, and checksum keys. They use different names for the data type, > ASN.1 type name, and ASN.1 sequence field name, but those have no impact > on the wire encoding. > > Because of the differences in data type and key usage, the two drafts are not > interoperable. Conceivably an acceptor could allow both versions of the > finished extension, but an initiator would have to guess at what the other end > can accept. > > The only other IAKERB implementation I'm aware of is in OSX, which appears > to implement draft-ietf-krb-wg-iakerb-02. From lukeh@padl.com Sat Apr 13 16:11:33 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E2921F8E87 for ; Sat, 13 Apr 2013 16:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iseqt1J+SR8Q for ; Sat, 13 Apr 2013 16:11:32 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5857A21F8E72 for ; Sat, 13 Apr 2013 16:11:29 -0700 (PDT) Received: by us.padl.com with ESMTP id r3DNBPqW003344; Sat, 13 Apr 2013 19:11:28 -0400 From: Luke Howard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> Date: Sat, 13 Apr 2013 19:11:24 -0400 To: "kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Subject: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 23:11:33 -0000 GSS BrowserID allows authentication of the acceptor using PKIX = certificates. This is an optional feature. (We use PKIX instead of = BrowserID certificates as they're more likely to be available for server = authentication; issuing BrowserID server certificates would likely = require each RP to run a custom IdP, or a standardized provisioning = protocol.) Depending on policy, the initiator may solely verify the acceptor = hostname (by looking at the dNSName SAN or least significant CN), or = verify the entire acceptor service name. In the current implementation and specification, the initiator may = verify the acceptor service name by validating the URI SAN. (GSS = BrowserID encodes the service name in a URN anyway, so this makes = sense.) Nico points out that it may be difficult to get CAs to issue = certificates with URIs in them. Instead, he proposes that we continue to = use the dNSName SAN, and encode the GSS-API service name (and the domain = presumably, for RFC5178 domain-based services) into an EKU OID. = (Absence of EKUs =3D=3D all services.) Thoughts? -- Luke (and Nico) From lukeh@padl.com Sun Apr 14 17:03:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D0821F8A18 for ; Sun, 14 Apr 2013 17:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRgFHZQ+JJZv for ; Sun, 14 Apr 2013 17:02:59 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9F14F21F869A for ; Sun, 14 Apr 2013 17:02:59 -0700 (PDT) Received: by us.padl.com with ESMTP id r3F02qar023559; Sun, 14 Apr 2013 20:02:56 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> Date: Sun, 14 Apr 2013 20:02:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 00:03:00 -0000 On 13/04/2013, at 7:11 PM, Luke Howard wrote: > Nico points out that it may be difficult to get CAs to issue = certificates with URIs in them. Instead, he proposes that we continue to = use the dNSName SAN, and encode the GSS-API service name (and the domain = presumably, for RFC5178 domain-based services) into an EKU OID. = (Absence of EKUs =3D=3D all services.) By encode, we mean either encode each ASCII character of the service = name into an OID element, or maintain a registry mapping GSS/SASL = service names to OIDs. Alternatively, we could use otherName with an OID representing a service = name (but that has similar issues to using a URI). Ultimately, if service-constrained certificates are to work, we need to = find a way that will work with deployed CA policies. -- Luke= From lukeh@padl.com Sun Apr 14 17:15:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D487A21F8E9A for ; Sun, 14 Apr 2013 17:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh725Mht7f3s for ; Sun, 14 Apr 2013 17:15:42 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4F321F8E51 for ; Sun, 14 Apr 2013 17:15:42 -0700 (PDT) Received: by us.padl.com with ESMTP id r3F0Fcit023824; Sun, 14 Apr 2013 20:15:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> Date: Sun, 14 Apr 2013 20:15:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: Michiko Short , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 00:15:42 -0000 Nico points out that PKU2U may have addressed this. Looking at = draft-zhu-pku2u: 3. If a X.509 certificate has a dNSName SAN that matches the hostname part of the host-based service principal name, and either the anyExtendedKeyUsage extended key usage (EKU), or no EKU is present, or an EKU is present which corresponds to the service part of the host-based service principal name, then the X.509 certificate matches. The id-kp-serverAuth EKU SHALL be considered to match the 'HTTP' service name. So, whereas currently the BrowserID draft specifies that = id-kp-serverAuth (or a BrowserID equivalent) is mandatory but not bound = to a particular service name, PKU2U binds it to HTTP and establishes a = registry for other services. There's certainly an argument for being consistent with PKU2U, but a = registry (as opposed to an algorithmic mapping) is a burden to = implementors and/or deployers. -- Luke= From nico@cryptonector.com Sun Apr 14 17:18:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3D21F8540 for ; Sun, 14 Apr 2013 17:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 IIYnvMHzav5L for ; Sun, 14 Apr 2013 17:18:00 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 57BDF21F8B2B for ; Sun, 14 Apr 2013 17:18:00 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id CD69758406A for ; Sun, 14 Apr 2013 17:17:59 -0700 (PDT) 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=0HDgIPYWDSAquGHgXGa5 qtfiKoA=; b=q960fCB0XllZ4GKdVuPV5NJahN/8JgNqr/n6IcoZ+BkJ7tW80yXH fitYPETwINxDQ8gfDEJIW2xqJf6gXPOUyFWlgkMsYKw2WkjEIOmxs98EjlY81DmC PUJWNKjOnFJWJWtAS0uds9K2YfX0C2rFHRz78gG0QblWij0QvDcIt/8= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (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 81DDA584065 for ; Sun, 14 Apr 2013 17:17:59 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so4042283wgh.15 for ; Sun, 14 Apr 2013 17:17:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr8387168wic.33.1365985078107; Sun, 14 Apr 2013 17:17:58 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Sun, 14 Apr 2013 17:17:57 -0700 (PDT) In-Reply-To: <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> Date: Sun, 14 Apr 2013 19:17:57 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=001a11c37cdc59667904da5b2ff8 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 00:18:01 -0000 --001a11c37cdc59667904da5b2ff8 Content-Type: text/plain; charset=UTF-8 Ah, I just remembered that the PKU2U I-D has all the required text regarding EKU. --001a11c37cdc59667904da5b2ff8 Content-Type: text/html; charset=UTF-8 Ah, I just remembered that the PKU2U I-D has all the required text regarding EKU. --001a11c37cdc59667904da5b2ff8-- From nico@cryptonector.com Sun Apr 14 17:52:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96E21F8511 for ; Sun, 14 Apr 2013 17:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 FlfaAMTBYVGs for ; Sun, 14 Apr 2013 17:52:30 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6821F8464 for ; Sun, 14 Apr 2013 17:52:30 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 733392F4059 for ; Sun, 14 Apr 2013 17:52:30 -0700 (PDT) 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=aLmGt/LTdb1ZGSDwvdBp oTeVaSo=; b=ZtJ4pM/dzvXqbzTS4zR3v6NlSgJemsw0g9Ze4NY5U5aj5igHXlpT dTe9exZ++EtqUTyzoxKqrQGkgHY+mr4XJTVbMtmKR35lxaC0RAfqlq0SEComUems 2LP4VQUxLaZhA6MTFsl+OM+EZrjt2BK4L8mCcZl+lFBTmZ2krJOHyT4= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 1C3352F4057 for ; Sun, 14 Apr 2013 17:52:29 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z2so3423360wey.1 for ; Sun, 14 Apr 2013 17:52:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr28795951wjc.50.1365987148915; Sun, 14 Apr 2013 17:52:28 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Sun, 14 Apr 2013 17:52:28 -0700 (PDT) In-Reply-To: References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> Date: Sun, 14 Apr 2013 19:52:28 -0500 Message-ID: From: Nico Williams To: Nico Williams Content-Type: multipart/alternative; boundary=089e010d8510c76b4904da5baaf1 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 00:52:31 -0000 --089e010d8510c76b4904da5baaf1 Content-Type: text/plain; charset=UTF-8 Luke would prefer an algorithmic service name to eku mapping. quite frankly, so would I. --089e010d8510c76b4904da5baaf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luke would prefer an algorithmic service name to eku mapping. =C2=A0quite f= rankly, so would I. --089e010d8510c76b4904da5baaf1-- From lukeh@padl.com Sun Apr 14 18:46:22 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786A221F90C1 for ; Sun, 14 Apr 2013 18:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 J1twuSRjjqfa for ; Sun, 14 Apr 2013 18:46:21 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3C821F8E96 for ; Sun, 14 Apr 2013 18:46:21 -0700 (PDT) Received: by us.padl.com with ESMTP id r3F1kF8U026378; Sun, 14 Apr 2013 21:46:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Sun, 14 Apr 2013 21:46:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 01:46:22 -0000 On 14/04/2013, at 8:52 PM, Nico Williams wrote: > Luke would prefer an algorithmic service name to eku mapping. quite = frankly, so would I. Hmm, I think I could go either way. Consistency with PKU2U wouldn't be a = bad thing. -- Luke= From lukeh@padl.com Sun Apr 14 18:57:48 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B700D21F884A for ; Sun, 14 Apr 2013 18:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHdS8bLjlVW for ; Sun, 14 Apr 2013 18:57:48 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2135021F875A for ; Sun, 14 Apr 2013 18:57:48 -0700 (PDT) Received: by us.padl.com with ESMTP id r3F1veC5026551; Sun, 14 Apr 2013 21:57:43 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Sun, 14 Apr 2013 21:57:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13701FCB-EBC7-414C-886B-D7FD5B6A72DF@padl.com> References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 01:57:48 -0000 Also see id-pkinit-san in RFC 4556 (also referenced from PKU2U). That = contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what CAs = support that, but perhaps it's a cleaner encoding of a service name than = a URI. So options are one or some combination of: * dNSName SAN, service name ignored (we probably want to support this = anyway) * dNSName SAN, service name mapped from EKU through a registry * dNSName SAN, service name mapped from EKU algorithmically * id-pkinit-san (RFC 4556), containing a Kerberos name * URI SAN containing BrowserID audience, service name encoded into URN -- Luke= From nico@cryptonector.com Sun Apr 14 19:03:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0994121F92E9 for ; Sun, 14 Apr 2013 19:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ul8kixH3C98W for ; Sun, 14 Apr 2013 19:03:28 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5618F21F85ED for ; Sun, 14 Apr 2013 19:03:28 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 1744276805C for ; Sun, 14 Apr 2013 19:03:28 -0700 (PDT) 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=GVtpq2JGy6HsQ5EcESWq gAD7LRQ=; b=yQWHZxju1Hm5VHwfed/ZaYZHmLsFLwGrPMb54Nkqg43I/CjKxIxI KEpFGnkYb3iiDVA3CWtQMMy8L7M+V0UzOvg7GR6OEAO1npY/IMWvO+WBX2h6hrde 9Y/aX07v7yB455O/3XDXFJvycQ1W0CRKJ+ZLXUMH2+RMfP5+FaAu1rk= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id B5ACC768057 for ; Sun, 14 Apr 2013 19:03:27 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so345622wgh.10 for ; Sun, 14 Apr 2013 19:03:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr8834894wik.16.1365991406459; Sun, 14 Apr 2013 19:03:26 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Sun, 14 Apr 2013 19:03:26 -0700 (PDT) In-Reply-To: <13701FCB-EBC7-414C-886B-D7FD5B6A72DF@padl.com> References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> <13701FCB-EBC7-414C-886B-D7FD5B6A72DF@padl.com> Date: Sun, 14 Apr 2013 21:03:26 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=001a11c23f308c628904da5ca8d2 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 02:03:29 -0000 --001a11c23f308c628904da5ca8d2 Content-Type: text/plain; charset=UTF-8 On Sunday, April 14, 2013, Luke Howard wrote: > Also see id-pkinit-san in RFC 4556 (also referenced from PKU2U). That > contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what CAs support > that, but perhaps it's a cleaner encoding of a service name than a URI. > > So options are one or some combination of: > > * dNSName SAN, service name ignored (we probably want to support this > anyway) > > * dNSName SAN, service name mapped from EKU through a registry > > * dNSName SAN, service name mapped from EKU algorithmically We should have just one EKU mapping, IMO. I can live with a registry, but note that nothing has stopped people from using whatever GSS service names they wished without registration, and this EKU thing would put an end to that -- annoying, no? > * id-pkinit-san (RFC 4556), containing a Kerberos name We may want this for domain-based names. > * URI SAN containing BrowserID audience, service name encoded into URN All of these are OK, but new PKIX name types depend on CA support (in software, procedures) for issuance, so to the extent that we can avoid that, all the better. Nico -- --001a11c23f308c628904da5ca8d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, April 14, 2013, Luke Howard wrote:
Also see id-pkinit-san in RFC 4556 (also referenced from PKU2= U). That contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what= CAs support that, but perhaps it's a cleaner encoding of a service nam= e than a URI.

So options are one or some combination of:

* dNSName SAN, service name ignored (we probably want to support this anywa= y)

* dNSName SAN, service name mapped from EKU through a registry

* dNSName SAN, service name mapped from EKU algorithmically

We should have just one EKU mapping, IMO. =C2=A0I can live= with a registry, but note that nothing has stopped people from using whate= ver GSS service names they wished without registration, and this EKU thing = would put an end to that -- annoying, no?

=C2=A0
* id-pkinit-san (RFC 4556), containing a Kerberos name
We may want this for domain-based names.
=C2=A0
=
* URI SAN containing BrowserID audience, service name encoded into URN
=C2=A0
A= ll of these are OK, but new PKIX name types depend on CA support (in softwa= re, procedures) for issuance, so to the extent that we can avoid that, all= =C2=A0the better.

Nico
--=C2=A0=C2=A0
--001a11c23f308c628904da5ca8d2-- From lukeh@padl.com Mon Apr 15 05:55:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E926A21F93A6 for ; Mon, 15 Apr 2013 05:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 69dsrB6zzEhw for ; Mon, 15 Apr 2013 05:55:54 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id DA61821F93A3 for ; Mon, 15 Apr 2013 05:55:53 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FCtoub019769; Mon, 15 Apr 2013 08:55:52 -0400 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_C1F8377E-1698-4EEA-BAB7-9B3F629D33CE" Date: Mon, 15 Apr 2013 08:55:50 -0400 References: <20130415125344.7161.67704.idtracker@ietfa.amsl.com> To: "dev-identity@lists.mozilla.org" , "kitten@ietf.org" Message-Id: <4BC0428B-D70F-4349-8A1A-A3A7DE01F460@padl.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: [kitten] draft-howard-gss-browserid-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:55:55 -0000 --Apple-Mail=_C1F8377E-1698-4EEA-BAB7-9B3F629D33CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nico and I met up the other day and cleaned up a bunch of things. It = probably still needs a glossary to bridge the gap between the GSS and = BrowserID/JOSE worlds. There are also a bunch of revision remarks now pertaining to outstanding = issues. -- Luke Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-howard-gss-browserid-02.txt > Date: 15 April 2013 8:53:44 AM EDT > To: lukeh@padl.com > Cc: nico@cryptonector.com >=20 >=20 > A new version of I-D, draft-howard-gss-browserid-02.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Filename: draft-howard-gss-browserid > Revision: 02 > Title: A SASL and GSS-API Mechanism for the BrowserID = Authentication Protocol > Creation date: 2013-04-15 > Group: Individual Submission > Number of pages: 45 > URL: = http://www.ietf.org/internet-drafts/draft-howard-gss-browserid-02.txt > Status: = http://datatracker.ietf.org/doc/draft-howard-gss-browserid > Htmlized: = http://tools.ietf.org/html/draft-howard-gss-browserid-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-browserid-02 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism based on the BrowserID authentication mechanism. > Through the GS2 family of mechanisms defined in RFC 5801, these > protocols also define how Simple Authentication and Security Layer > (SASL, RFC 4422) applications may use BrowserID. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_C1F8377E-1698-4EEA-BAB7-9B3F629D33CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Nico = and I met up the other day and cleaned up a bunch of things. It probably = still needs a glossary to bridge the gap between the GSS and = BrowserID/JOSE worlds.

There are also a bunch of = revision remarks now pertaining to outstanding = issues.

-- Luke

Begin forwarded = message:

Subject: New Version Notification for = draft-howard-gss-browserid-02.txt
Date: 15 April 2013 = 8:53:44 AM EDT


A new version of I-D, = draft-howard-gss-browserid-02.txt
has been successfully submitted by = Luke Howard and posted to the
IETF repository.

Filename: = draft-howard-gss-browserid
Revision: 02
Title: A SASL = and GSS-API Mechanism for the BrowserID Authentication = Protocol
Creation date: 2013-04-15
Group: = Individual Submission
Number of pages: 45
URL: =             http://www.ietf.org/internet-drafts/draft-howard-gss-browserid-02.txt=
Status:          http:/= /datatracker.ietf.org/doc/draft-howard-gss-browserid
Htmlized: =        http://t= ools.ietf.org/html/draft-howard-gss-browserid-02
Diff: =            = http://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-browserid-02
Abstract:
  This document defines protocols, procedures = and conventions for a
  Generic Security Service = Application Program Interface (GSS-API)
  security = mechanism based on the BrowserID authentication mechanism.
=   Through the GS2 family of mechanisms defined in RFC 5801, = these
  protocols also define how Simple Authentication = and Security Layer
  (SASL, RFC 4422) applications may use = BrowserID.




The IETF = Secretariat



= --Apple-Mail=_C1F8377E-1698-4EEA-BAB7-9B3F629D33CE-- From lukeh@padl.com Mon Apr 15 06:05:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF9921F8B2B for ; Mon, 15 Apr 2013 06:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bGEloLubrAjJ for ; Mon, 15 Apr 2013 06:05:37 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56E21F87B6 for ; Mon, 15 Apr 2013 06:05:37 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FD5S7p019957; Mon, 15 Apr 2013 09:05:32 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_B5359D60-AFC8-485C-8C0E-34B4698B03A6" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Mon, 15 Apr 2013 09:05:28 -0400 Message-Id: References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> <13701FCB-EBC7-414C-886B-D7FD5B6A72DF@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:05:38 -0000 --Apple-Mail=_B5359D60-AFC8-485C-8C0E-34B4698B03A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > We should have just one EKU mapping, IMO. I can live with a registry, = but note that nothing has stopped people from using whatever GSS service = names they wished without registration, and this EKU thing would put an = end to that -- annoying, no? True. I've put all on-the-table options in draft -02, but obviously we = need to trim them down before publication. While I do like the = consistency of id-pkinit-san, it also means implementations have to have = an (exposed) ASN.1 library. Ultimately broad CA support (as you said, in = software and procedures) should be the deciding factor. See below, anyway. If the initiator policy requires the acceptor service name to be validated in addition to the acceptor host name, the service name MUST be validated against one of the following: o A service-name EKU from the registry defined by [I-D.zhu-pku2u] o An algorithmically mapped service-name EKU (TBD) o A spn expressed as a realm-less KRB5PrincipalName in the id- pkinit-san otherName SAN (see [RFC4556] Section 3.2.2) o A BrowserID audience URN containing the spn, encoded in a URI SAN (see Section 3.2) o An out-of-band binding to the certificate If the initiator policy only requires the acceptor host name to be authenticated, or an EKU binding is used (rather than the id-pkinit- san or URI SAN, which contain a host name), then the host component of the service name (service-host) MUST be present as a value for the dNSName SAN or as the least significant Common Name RDN. If the acceptor name contains a service-specific component and the initiator policy requires this to be authenticated, note only the id- pkinit-san or URI SANs provide this binding. -- Luke= --Apple-Mail=_B5359D60-AFC8-485C-8C0E-34B4698B03A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
We should have just one EKU = mapping, IMO.  I can live with a registry, but note that nothing = has stopped people from using whatever GSS service names they wished = without registration, and this EKU thing would put an end to that -- = annoying, no?

True. I've put all = on-the-table options in draft -02, but obviously we need to trim them = down before publication. While I do like the consistency of = id-pkinit-san, it also means implementations have to have an (exposed) = ASN.1 library. Ultimately broad CA support (as you said, in software and = procedures) should be the deciding factor.

See = below, anyway.
   If the initiator =
policy requires the acceptor service name to be
   validated in addition to the acceptor host name, the service name
   MUST be validated against one of the following:

   o  A service-name EKU from the registry defined by [I-D.zhu-pku2u]

   o  An algorithmically mapped service-name EKU (TBD)

   o  A spn expressed as a realm-less KRB5PrincipalName in the id-
      pkinit-san otherName SAN (see [RFC4556] =
Section 3.2.2)

   o  A BrowserID audience URN containing =
the spn, encoded in a URI SAN
      (see Section 3.2)

   o  An out-of-band binding to the certificate

   If the initiator policy only requires the acceptor host name to be
   authenticated, or an EKU binding is used (rather than the id-pkinit-
   san or URI SAN, which contain a host name), then the host component
   of the service name (service-host) MUST be present as a value for the
   dNSName SAN or as the least significant Common Name RDN.

   If the acceptor name contains a service-specific component and the
   initiator policy requires this to be authenticated, note only the id-
   pkinit-san or URI SANs provide this binding.
-- = Luke
= --Apple-Mail=_B5359D60-AFC8-485C-8C0E-34B4698B03A6-- From mrex@sap.com Mon Apr 15 08:42:10 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B97A21F9408 for ; Mon, 15 Apr 2013 08:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 ith4p66dIXpd for ; Mon, 15 Apr 2013 08:42:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2275021F8585 for ; Mon, 15 Apr 2013 08:42:08 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r3FFg4ql010292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Apr 2013 17:42:04 +0200 (MEST) In-Reply-To: <13701FCB-EBC7-414C-886B-D7FD5B6A72DF@padl.com> To: Luke Howard Date: Mon, 15 Apr 2013 17:42:04 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:42:10 -0000 Luke Howard wrote: > Also see id-pkinit-san in RFC 4556 (also referenced from PKU2U). > That contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what > CAs support that, but perhaps it's a cleaner encoding of a service > name than a URI. The problem with KRB5PrincipalName as otherName SAN is that this structure is an ambiguous mess, and its definition and semantics smeared over several documents, rather than a simple, well-defined datatype that is easily parsable by non-Kerberos RPs. The MS-UPN otherName SAN is **MUCH** easier to deal with. > > So options are one or some combination of: > > * dNSName SAN, service name ignored (we probably want to support this anyway) > > * dNSName SAN, service name mapped from EKU through a registry > > * dNSName SAN, service name mapped from EKU algorithmically > > * id-pkinit-san (RFC 4556), containing a Kerberos name > > * URI SAN containing BrowserID audience, service name encoded into URN That list seems to be missing the "Service Name" otherName SAN http://tools.ietf.org/html/rfc4985 Btw. HTTP-over-TLS (rfc2818) does not recognize or require the id-kp-serverAuth nor the id-kp-clientAuth. Both EKUs (id-kp-serverAuth and id-kp-clientAuth) were defined exclusively by PKIX (rfc2459, rfc3280, rfc5280), and the PKIX definition is limited to "TLS WWW server/client authentication". There is no clear definition what "WWW" means. The conservative assumption would be, that it refers to "HTTP over TLS", which has been retroactively documented ("informative") in rfc2818. -Martin From nico@cryptonector.com Mon Apr 15 08:58:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1C21F8B27 for ; Mon, 15 Apr 2013 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 YE-Ymj5QBJCv for ; Mon, 15 Apr 2013 08:58:39 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80221F9415 for ; Mon, 15 Apr 2013 08:57:22 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 2FDD22F4060 for ; Mon, 15 Apr 2013 08:56:58 -0700 (PDT) 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=SjzQUm8bq1my7xGjOZ/y it/Y3AQ=; b=emMDXJLrMzFtbbgsOvFDyaWF1kz0AKM57MMpOxhFrZMWPQMZ0L6E b0OWbRcbFPcTwaNnaW2T28kbGYemNUvwWWRgF1WRGkRO/6uCra+daPcl4hpdTe5G uZoFhZMwk333azYao9uBheKNlD6GZS2gmI4P7HGjXYjQQhAwzWEXbvw= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id AA0632F4059 for ; Mon, 15 Apr 2013 08:56:57 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so3744526wey.11 for ; Mon, 15 Apr 2013 08:56:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr33398699wjb.29.1366041416217; Mon, 15 Apr 2013 08:56:56 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Mon, 15 Apr 2013 08:56:56 -0700 (PDT) In-Reply-To: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> References: <13701FCB-EBC7-414C-886B-D7FD5B6A72DF@padl.com> <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> Date: Mon, 15 Apr 2013 10:56:56 -0500 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=047d7b5d456c5cbe2f04da684d8b Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:58:41 -0000 --047d7b5d456c5cbe2f04da684d8b Content-Type: text/plain; charset=UTF-8 On Monday, April 15, 2013, Martin Rex wrote: > Luke Howard wrote: > > So options are one or some combination of: > > > > * dNSName SAN, service name ignored (we probably want to support this > anyway) > > > > * dNSName SAN, service name mapped from EKU through a registry > > > > * dNSName SAN, service name mapped from EKU algorithmically > > > > * id-pkinit-san (RFC 4556), containing a Kerberos name > > > > * URI SAN containing BrowserID audience, service name encoded into URN > > That list seems to be missing the "Service Name" otherName SAN > > http://tools.ietf.org/html/rfc4985 Oh, that's awesome! Much better than having an EKU OID column added to the GSS service name registry. Are there CAs that know how to handle this? Because that's key here, and I assume that getting CAs to understand EKUs is relatively easy, since EKUs are a constraint on certs the CAs already know how to and are willing to issue. > Btw. HTTP-over-TLS (rfc2818) does not recognize or require the > id-kp-serverAuth > nor the id-kp-clientAuth. > > Both EKUs (id-kp-serverAuth and id-kp-clientAuth) were defined exclusively > by PKIX (rfc2459, rfc3280, rfc5280), and the PKIX definition is limited > to "TLS WWW server/client authentication". There is no clear definition > what "WWW" means. The conservative assumption would be, that it refers > to "HTTP over TLS", which has been retroactively documented ("informative") > in rfc2818. > Thanks for the info Martin! Nico -- --047d7b5d456c5cbe2f04da684d8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, April 15, 2013, Martin Rex wrote:
Luke Howard wrote:
> So options are one or some combination of:
>
> * dNSName SAN, service name ignored (we probably want to support this = anyway)
>
> * dNSName SAN, service name mapped from EKU through a registry
>
> * dNSName SAN, service name mapped from EKU algorithmically
>
> * id-pkinit-san (RFC 4556), containing a Kerberos name
>
> * URI SAN containing BrowserID audience, service name encoded into URN=

That list seems to be missing the "Service Name" otherName SAN
=C2=A0 htt= p://tools.ietf.org/html/rfc4985

Oh, tha= t's awesome! =C2=A0Much better than having an EKU OID column added to t= he GSS service name registry.

Are there CAs that know how to handle this? =C2=A0Becau= se that's key here, and I assume that getting CAs to understand EKUs is= relatively easy, since EKUs are a constraint on certs the CAs already know= how to and are willing to issue.

=C2=A0
Btw. HTTP-over-TLS (rfc2818) does not recognize or require the id-kp-server= Auth
nor the id-kp-clientAuth.

Both EKUs (id-kp-serverAuth and id-kp-clientAuth) were defined exclusively<= br> by PKIX (rfc2459, rfc3280, rfc5280), and the PKIX definition is limited
to "TLS WWW server/client authentication". =C2=A0There is no clea= r definition
what "WWW" means. =C2=A0The conservative assumption would be, tha= t it refers
to "HTTP over TLS", which has been retroactively documented (&quo= t;informative")
in rfc2818.

Thanks for the info Martin!

=
Nico
--=C2=A0=C2=A0
--047d7b5d456c5cbe2f04da684d8b-- From mrex@sap.com Mon Apr 15 10:32:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A3321F9600 for ; Mon, 15 Apr 2013 10:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 r-gSKjToKpGr for ; Mon, 15 Apr 2013 10:32:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BBEED21F95EC for ; Mon, 15 Apr 2013 10:32:28 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r3FHWOWE018350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Apr 2013 19:32:24 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Mon, 15 Apr 2013 19:32:24 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130415173224.6BD491A6AF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:32:29 -0000 Nico Williams wrote: > > Martin Rex wrote: > > > > That list seems to be missing the "Service Name" otherName SAN > > > > http://tools.ietf.org/html/rfc4985 > > > Oh, that's awesome! Much better than having an EKU OID column added to the > GSS service name registry. > > Are there CAs that know how to handle this? Because that's key here, and I > assume that getting CAs to understand EKUs is relatively easy, since EKUs > are a constraint on certs the CAs already know how to and are willing to > issue. Myself, I don't know about CAs and what they offer. Btw. here is the guidance from rfc6125: http://tools.ietf.org/html/rfc6125#section-3 Although I personally do not believe in certificate name constraints, existing specs (PKIX for DNSName, PKIX for URI and rfc4985 for otherName SRVName) at least contain name constraints processing rules for them. AFAIK, there are no name constraints processing rules defined for the KerberosPrincipalName otherName SAN. (And Microsoft's MS-UPN does not have a public spec, nor published name constraints processing rules). -Martin From lukeh@padl.com Mon Apr 15 10:57:19 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0721F94A6 for ; Mon, 15 Apr 2013 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 Qb6s5fatOB2T for ; Mon, 15 Apr 2013 10:57:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C173221F90B9 for ; Mon, 15 Apr 2013 10:57:18 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FHvCps001256; Mon, 15 Apr 2013 13:57:15 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> Date: Mon, 15 Apr 2013 13:57:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:57:19 -0000 > The MS-UPN otherName SAN is **MUCH** easier to deal with. That's not applicable to our use case because it is for client principal = names only. (The protocol uses BrowserID rather than PKIX certificates = for client authentication.) > http://tools.ietf.org/html/rfc4985 Ah, thanks for this! Are GSS and DNS service names always aligned? -- Luke= From lukeh@padl.com Mon Apr 15 10:59:08 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1647521F848D for ; Mon, 15 Apr 2013 10:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 bPW07gQST1mf for ; Mon, 15 Apr 2013 10:59:07 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4421F8425 for ; Mon, 15 Apr 2013 10:59:07 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FHx2Tv001284; Mon, 15 Apr 2013 13:59:05 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <20130415173224.6BD491A6AF@ld9781.wdf.sap.corp> Date: Mon, 15 Apr 2013 13:59:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130415173224.6BD491A6AF@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:59:08 -0000 On 15/04/2013, at 1:32 PM, Martin Rex wrote: > AFAIK, there are no name constraints processing rules defined for the > KerberosPrincipalName otherName SAN. (And Microsoft's MS-UPN does not > have a public spec, nor published name constraints processing rules). Well, the UPN suffix namespace in Active Directory is distinct from the = domain namespace (although they may have common members). Each forest = has a set of valid UPN suffixes, and trusts between forests also specify = which suffixes they will accept. Anyway, this has nothing to do with BrowserID mutual auth. :-) -- Luke= From lukeh@padl.com Mon Apr 15 11:17:11 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8621F9659 for ; Mon, 15 Apr 2013 11:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 xpBGOx9aFmW5 for ; Mon, 15 Apr 2013 11:17:11 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1B21F9654 for ; Mon, 15 Apr 2013 11:17:10 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FIH7x4001816; Mon, 15 Apr 2013 14:17:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> Date: Mon, 15 Apr 2013 14:17:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:17:11 -0000 On 15/04/2013, at 1:57 PM, Luke Howard wrote: > Ah, thanks for this! Are GSS and DNS service names always aligned? For example, RFC 6120 registers "xmpp" as a GSS-API service name, but = "xmpp-client" and "xmpp-server" as IANA service names. So there's no = straightforward mapping. I'm also curious why PKU2U did not use RFC 4985. Larry? -- Luke= From lukeh@padl.com Mon Apr 15 11:23:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BAB21F9685 for ; Mon, 15 Apr 2013 11:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 TGfrAtIbgYKh for ; Mon, 15 Apr 2013 11:23:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9833221F9607 for ; Mon, 15 Apr 2013 11:23:38 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FINXY5001943; Mon, 15 Apr 2013 14:23:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <20130415173224.6BD491A6AF@ld9781.wdf.sap.corp> Date: Mon, 15 Apr 2013 14:23:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <022F9B15-9641-4FB4-BFBC-670BDDA6EB7B@padl.com> References: <20130415173224.6BD491A6AF@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:23:55 -0000 On 15/04/2013, at 1:32 PM, Martin Rex wrote: > Btw. here is the guidance from rfc6125: >=20 > http://tools.ietf.org/html/rfc6125#section-3 Interesting. Following the RFC6125 logic, we should use the URI SAN, = which is what I originally proposed! (We still have the issue of whether = CAs will actually issue certificates with URIs in them.) Another thing: in our current draft, I suggested it's a matter of = initiator policy whether they wish to require a complete service name = match (using a URI or PKINIT SAN, or EKU) or just verify the dNSName/CN. = Would it better to say that all services are allowed by a certificate = lacking a service name binding? -- Luke= From lzhu@microsoft.com Mon Apr 15 12:09:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9E21F9452 for ; Mon, 15 Apr 2013 12:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nepjaOtRY9D0 for ; Mon, 15 Apr 2013 12:09:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 31CF721F9436 for ; Mon, 15 Apr 2013 12:09:06 -0700 (PDT) Received: from BY2FFO11FD024.protection.gbl (10.1.15.200) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 18:55:18 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 18:54:47 +0000 Received: from TK5EX14MBXC301.redmond.corp.microsoft.com ([169.254.1.230]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 18:54:41 +0000 From: Larry Zhu To: Luke Howard , "kitten@ietf.org" Thread-Topic: [kitten] BrowserID mutual auth Thread-Index: AQHOOJxBRT8T1tB7rU6suXbZsjII8JjWZ+uAgAAEOICAAAmlAIAADwYAgAADMQCAAOZWAIAAJcIAgAAFkICAAAojEA== Date: Mon, 15 Apr 2013 18:54:41 +0000 Message-ID: <362291B4CD0FE44E86CEEC506BCFF2840FA5B6A8@TK5EX14MBXC301.redmond.corp.microsoft.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> In-Reply-To: <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(189002)(199002)(479174001)(24454001)(377454001)(47776003)(5343655001)(55846006)(47976001)(69226001)(49866001)(54316002)(53806001)(47736001)(51856001)(74662001)(50986001)(23726002)(81542001)(5343635001)(4396001)(81342001)(76482001)(79102001)(74502001)(56776001)(16406001)(46102001)(20776003)(54356001)(59766001)(33656001)(47446002)(31966008)(80022001)(46406003)(63696002)(66066001)(65816001)(50466001)(44976003)(56816002)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:09:09 -0000 Hi Luke, I am catching up the context. Can you expand on the question? I do not thin= k PKU2U has any restrictions on the use of RFC4985, right? Thanks. -----Original Message----- From: Luke Howard [mailto:lukeh@padl.com]=20 Sent: Monday, April 15, 2013 11:17 AM To: kitten@ietf.org Cc: Larry Zhu Subject: Re: [kitten] BrowserID mutual auth On 15/04/2013, at 1:57 PM, Luke Howard wrote: > Ah, thanks for this! Are GSS and DNS service names always aligned? For example, RFC 6120 registers "xmpp" as a GSS-API service name, but "xmpp= -client" and "xmpp-server" as IANA service names. So there's no straightfor= ward mapping. I'm also curious why PKU2U did not use RFC 4985. Larry? -- Luke From lukeh@padl.com Mon Apr 15 12:12:48 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CAA21F85D4 for ; Mon, 15 Apr 2013 12:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 RX+ew8PjNezE for ; Mon, 15 Apr 2013 12:12:48 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 31AAE21F8928 for ; Mon, 15 Apr 2013 12:12:48 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FJCg9C004036; Mon, 15 Apr 2013 15:12:45 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <362291B4CD0FE44E86CEEC506BCFF2840FA5B6A8@TK5EX14MBXC301.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 15:12:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <362291B4CD0FE44E86CEEC506BCFF2840FA5B6A8@TK5EX14MBXC301.redmond.corp.microsoft.com> To: Larry Zhu X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org, Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:12:48 -0000 Hi Larry, > I am catching up the context. Can you expand on the question? I do not = think PKU2U has any restrictions on the use of RFC4985, right? Thanks. The context is, for a new GSS-API mechanism that supports authentication = of the acceptor using PKIX certificates: =93How should such certificates be bound to GSS-API service principal = names (SPNs) where it is desired to authenticate the service name as = well as the acceptor host name?=94 [1] There seem to be a bunch of options: * the PKU2U EKU registry * a putative encoding of the service name contents into an EKU OID * a URI SAN containing a URN (the mechanism in question uses URIs = natively, so this makes sense) * RFC4556 KRB5PrincipalName (the mechanism in question uses = Kerberos-like names, so this also makes sense) * RFC4985 (simple, but assumes GSS and IANA service names are = equivalent) Nico's biggest concern is: given this mechanism is designed to be used = over the Internet, what will be most interoperable with existing CA = policies? This is the advantage of an EKU, because CAs can continue to = use their existing validation policies to certify the SAN, and consider = the EKU as an additional restriction. The disadvantage of the PKU2U EKU = registry is that implementations would have to be updated to support new = or arbitrary service names. -- Luke [1] Note here I am using "service name" to mean "http" or "host" and = "service principal name" to mean that bound to a host, e.g. = "host/example.com" in our native representation, or "host@example.com" = as a GSS_C_NT_HOSTBASED_SERVICE. Let's avoid RFC5178 names for now.= From ietf@augustcellars.com Mon Apr 15 12:28:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3421F944A for ; Mon, 15 Apr 2013 12:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wXfSANfAsTXH for ; Mon, 15 Apr 2013 12:28:54 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89BD821F940C for ; Mon, 15 Apr 2013 12:28:54 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2FBA42CA47; Mon, 15 Apr 2013 12:28:54 -0700 (PDT) From: "Jim Schaad" To: "'Nico Williams'" , "'Luke Howard'" References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> In-Reply-To: Date: Mon, 15 Apr 2013 12:28:10 -0700 Message-ID: <029701ce3a0f$5e01f4b0$1a05de10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0298_01CE39D4.B1A45530" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGja9r4Q8TIWR4ftsTS2+hVrhj6UgKbI9YWAayczPWZCwjUsA== Cc: kitten@ietf.org, 'Ryan Hurst' Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:28:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0298_01CE39D4.B1A45530 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Are you thinking this means that the PKU2U draft should be revived and = published? Or just that the text on EKU should be pulled into the = BrowserID draft if applicable =20 Jim =20 =20 From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf = Of Nico Williams Sent: Sunday, April 14, 2013 5:18 PM To: Luke Howard Cc: kitten@ietf.org; Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth =20 Ah, I just remembered that the PKU2U I-D has all the required text = regarding EKU.=20 ------=_NextPart_000_0298_01CE39D4.B1A45530 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Are you thinking this means that the PKU2U draft should be revived = and published?=C2=A0 Or just that the text on EKU should be pulled into = the BrowserID draft if applicable

 

Jim

 

 

From:= = kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of = Nico Williams
Sent: Sunday, April 14, 2013 5:18 = PM
To: Luke Howard
Cc: kitten@ietf.org; Ryan = Hurst
Subject: Re: [kitten] BrowserID mutual = auth

 

Ah, I just = remembered that the PKU2U I-D has all the required text regarding EKU. =

------=_NextPart_000_0298_01CE39D4.B1A45530-- From lukeh@padl.com Mon Apr 15 12:34:30 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62B921F9361 for ; Mon, 15 Apr 2013 12:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 SuyUZpLdcoYY for ; Mon, 15 Apr 2013 12:34:30 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC3121F9350 for ; Mon, 15 Apr 2013 12:34:30 -0700 (PDT) Received: by us.padl.com with ESMTP id r3FJY6Vi005608; Mon, 15 Apr 2013 15:34:09 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_F2A55519-8F67-4C63-9CF2-CE726DBFDA6D" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <029701ce3a0f$5e01f4b0$1a05de10$@augustcellars.com> Date: Mon, 15 Apr 2013 15:34:06 -0400 Message-Id: <6733494D-BFA8-4365-8565-3FC645BBD655@padl.com> References: <19CCE59B-42FD-4DEE-A935-1F4EADF0314C@padl.com> <99894E60-0113-497F-A88B-FE91001FAFBE@padl.com> <029701ce3a0f$5e01f4b0$1a05de10$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org, Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:34:30 -0000 --Apple-Mail=_F2A55519-8F67-4C63-9CF2-CE726DBFDA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15/04/2013, at 3:28 PM, "Jim Schaad" wrote: > Are you thinking this means that the PKU2U draft should be revived and = published? Or just that the text on EKU should be pulled into the = BrowserID draft if applicable Good point; the BrowserID draft already references a bunch of abandoned = Internet Drafts, such as NegoEx. (We are planning to pull the NegoEx = text out though.) So, we could just import the text from the PKU2U draft, but both drafts = can't each update the IANA GSS-API service name registry to include an = EKU. How we proceed depends on (a) whether we choose the PKU2U approach = and (b) whether the PKU2U draft is to be revived. -- Luke= --Apple-Mail=_F2A55519-8F67-4C63-9CF2-CE726DBFDA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 15/04/2013, at = 3:28 PM, "Jim Schaad" <ietf@augustcellars.com> = wrote:

Are you thinking this = means that the PKU2U draft should be revived and published?  Or = just that the text on EKU should be pulled into the BrowserID draft if = applicable

Good = point; the BrowserID draft already references a bunch of abandoned = Internet Drafts, such as NegoEx. (We are planning to pull the NegoEx = text out though.)

So, we could just import the = text from the PKU2U draft, but both drafts can't each update the IANA = GSS-API service name registry to include an EKU. How we proceed depends = on (a) whether we choose the PKU2U approach and (b) whether the PKU2U = draft is to be revived.

-- = Luke
= --Apple-Mail=_F2A55519-8F67-4C63-9CF2-CE726DBFDA6D-- From nico@cryptonector.com Mon Apr 15 12:54:52 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F621F93B7 for ; Mon, 15 Apr 2013 12:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 i-ApnuTA-B+U for ; Mon, 15 Apr 2013 12:54:51 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4488721F93A9 for ; Mon, 15 Apr 2013 12:54:51 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 07F98594062 for ; Mon, 15 Apr 2013 12:54:51 -0700 (PDT) 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=xALNWajQWVCZ30J0UCgM b9hvwwM=; b=v4HVHmugwRs6d4JsfcfasUncQkPOank1TDL9CAfkB79yYTMUaLwD ij0fvhiFy16FItjXdkOnqaqpwUuw/4sWwbv7zXPikhDyzkiYUMeTauBzv8hpkMEn 74a+2h6S/4RsVjAAX5Mau9aL14RKvoIKxgGpZvno4V5P1QAk7ID4AcU= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 83E5B594061 for ; Mon, 15 Apr 2013 12:54:50 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2001856wiw.0 for ; Mon, 15 Apr 2013 12:54:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr14553287wik.16.1366055688686; Mon, 15 Apr 2013 12:54:48 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Mon, 15 Apr 2013 12:54:48 -0700 (PDT) In-Reply-To: <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> Date: Mon, 15 Apr 2013 14:54:48 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=001a11c23f3011557304da6ba0e7 Cc: "kitten@ietf.org" , Ryan Hurst Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:54:52 -0000 --001a11c23f3011557304da6ba0e7 Content-Type: text/plain; charset=UTF-8 On Monday, April 15, 2013, Luke Howard wrote: > > The MS-UPN otherName SAN is **MUCH** easier to deal with. > > That's not applicable to our use case because it is for client principal > names only. (The protocol uses BrowserID rather than PKIX certificates for > client authentication.) > > > http://tools.ietf.org/html/rfc4985 > > Ah, thanks for this! Are GSS and DNS service names always aligned? > They are! --001a11c23f3011557304da6ba0e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, April 15, 2013, Luke Howard wrote:
> The MS-UPN otherName SAN is **MUCH** easier to deal with.

That's not applicable to our use case because it is for client principa= l names only. (The protocol uses BrowserID rather than PKIX certificates fo= r client authentication.)

> =C2=A0http://tools.ietf.org/html/rfc4985

Ah, thanks for this! Are GSS and DNS service names always aligned?

They are!=C2=A0
--001a11c23f3011557304da6ba0e7-- From nico@cryptonector.com Mon Apr 15 13:59:05 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3022121F9602 for ; Mon, 15 Apr 2013 13:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 Uwd+YOnkhGb8 for ; Mon, 15 Apr 2013 13:59:04 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 42A7421F95FC for ; Mon, 15 Apr 2013 13:59:04 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 090F8598058 for ; Mon, 15 Apr 2013 13:59:04 -0700 (PDT) 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=Is0tVbYT4av7LRJ/70Z0 zxtxKg4=; b=KTnpgyByZXVdkHNzCuSVav9XZ/EZPeVWjA28lk/qte2olcqCUPdX nZyXtmj+38uxIlYsOYAOJe2E+w0BMdhsVDrIa947UhFO4TnH/eyef4wtZ/fm5+Ks 6fpK7NUVAugkQ5CQaFINhc0lWMXmr9sP6DEs1Yz+b41p6hMQb7n2oCg= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id A45F359805F for ; Mon, 15 Apr 2013 13:59:03 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so560792wgh.1 for ; Mon, 15 Apr 2013 13:59:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr35068864wjb.29.1366059542004; Mon, 15 Apr 2013 13:59:02 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Mon, 15 Apr 2013 13:59:01 -0700 (PDT) In-Reply-To: <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> Date: Mon, 15 Apr 2013 15:59:01 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=047d7b5d456cbe4dfa04da6c85a1 Cc: "kitten@ietf.org" Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:59:05 -0000 --047d7b5d456cbe4dfa04da6c85a1 Content-Type: text/plain; charset=UTF-8 On Monday, April 15, 2013, Luke Howard wrote: > > On 15/04/2013, at 1:57 PM, Luke Howard wrote: > > > Ah, thanks for this! Are GSS and DNS service names always aligned? > > For example, RFC 6120 registers "xmpp" as a GSS-API service name, but > "xmpp-client" and "xmpp-server" as IANA service names. So there's no > straightforward mapping. That's a spec bug, IMO. We could bake that in code. we could update IANA instructions to avoid this in the future. --047d7b5d456cbe4dfa04da6c85a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, April 15, 2013, Luke Howard wrote:
On 15/04/2013, at 1:57 PM, Luke Howard <lukeh@padl.com>= wrote:

> Ah, thanks for this! Are GSS and DNS service names alwa= ys aligned?

For example, RFC 6120 registers "xmpp" as a GSS-API service n= ame, but "xmpp-client" and "xmpp-server" as IANA servic= e names. So there's no straightforward mapping.

That's a spec bug, IMO. =C2=A0W= e could bake that in code. =C2=A0we could update IANA instructions to avoid= this in the future.

--047d7b5d456cbe4dfa04da6c85a1-- From nico@cryptonector.com Mon Apr 15 14:06:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5921F9617 for ; Mon, 15 Apr 2013 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 RJnSDQT3+5HS for ; Mon, 15 Apr 2013 14:06:56 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id AF63C21F9602 for ; Mon, 15 Apr 2013 14:06:56 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 7D5F12F4060 for ; Mon, 15 Apr 2013 14:06:56 -0700 (PDT) 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=A3DKuKCgkdOEKrLb/M9u SfpMULQ=; b=XRIMRVGyuTbKwN1ZUYUWtOtoVQTAVVF7kvnGtHkVinxzLZL1gTNF UrFC27eqD4Q1BgqAy+nxgWItS64wP+Sg8WofvN6vcaqDX962sl2/zOmNMqjd+NG8 W+VwJRNsbivV80bbiZzZsoGWAVAtaCQc223/OVhMdR9EnF3M7rZYyY8= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 1941F2F4059 for ; Mon, 15 Apr 2013 14:06:55 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq17so1263606wib.17 for ; Mon, 15 Apr 2013 14:06:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr14856847wik.16.1366060014577; Mon, 15 Apr 2013 14:06:54 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Mon, 15 Apr 2013 14:06:54 -0700 (PDT) In-Reply-To: References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> Date: Mon, 15 Apr 2013 16:06:54 -0500 Message-ID: From: Nico Williams To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c23f30e92f6304da6ca113 Cc: "kitten@ietf.org" Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:06:57 -0000 --001a11c23f30e92f6304da6ca113 Content-Type: text/plain; charset=UTF-8 On Monday, April 15, 2013, Nico Williams wrote: > On Monday, April 15, 2013, Luke Howard wrote: > >> >> On 15/04/2013, at 1:57 PM, Luke Howard wrote: >> >> > Ah, thanks for this! Are GSS and DNS service names always aligned? >> >> For example, RFC 6120 registers "xmpp" as a GSS-API service name, but >> "xmpp-client" and "xmpp-server" as IANA service names. So there's no >> straightforward mapping. > > > That's a spec bug, IMO. We could bake that in code. we could update IANA > instructions to avoid this in the future. > We should probably update RFC2743 to indicate that (with exceptions) the service name component of host-based service name should match service names from the IANA ports registry. Nico -- --001a11c23f30e92f6304da6ca113 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, April 15, 2013, Nico Williams wrote:
On Monday, April 15, 2013, Luke Howard wrote:

On 15/04/2013, at 1:57 PM, Luke Howard <lukeh@padl.com>= wrote:

> Ah, thanks for this! Are GSS and DNS service names alwa= ys aligned?

For example, RFC 6120 registers "xmpp" as a GSS-API service n= ame, but "xmpp-client" and "xmpp-server" as IANA servic= e names. So there's no straightforward mapping.

That's a spec bug, IMO. =C2=A0W= e could bake that in code. =C2=A0we could update IANA instructions to avoid= this in the future.

=C2=A0We shoul= d probably update RFC2743 to indicate that (with exceptions) the service na= me component of=C2=A0host-based service name should match service names fro= m the IANA ports registry.

Nico
--=C2=A0
--001a11c23f30e92f6304da6ca113-- From stpeter@stpeter.im Mon Apr 15 14:13:13 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6721F91BB for ; Mon, 15 Apr 2013 14:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmKSQ+u4505Z for ; Mon, 15 Apr 2013 14:13:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A880021F91A5 for ; Mon, 15 Apr 2013 14:13:12 -0700 (PDT) Received: from squire.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B56D440FAD; Mon, 15 Apr 2013 15:23:36 -0600 (MDT) Message-ID: <516C6D5D.30708@stpeter.im> Date: Mon, 15 Apr 2013 15:13:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Nico Williams References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:13:13 -0000 On 4/15/13 2:59 PM, Nico Williams wrote: > On Monday, April 15, 2013, Luke Howard wrote: > > > On 15/04/2013, at 1:57 PM, Luke Howard wrote: > > > Ah, thanks for this! Are GSS and DNS service names always aligned? > > For example, RFC 6120 registers "xmpp" as a GSS-API service name, > but "xmpp-client" and "xmpp-server" as IANA service names. So > there's no straightforward mapping. > > > That's a spec bug, IMO. We could bake that in code. we could update > IANA instructions to avoid this in the future. > A bug in RFC 6120 or in RFC 2743? Peter From ietf@augustcellars.com Mon Apr 15 15:57:52 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8EB21F8E2C for ; Mon, 15 Apr 2013 15:57:52 -0700 (PDT) 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=0.001, 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 ZcnLBe06fhQk for ; Mon, 15 Apr 2013 15:57:52 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id ED43921F8DB6 for ; Mon, 15 Apr 2013 15:57:51 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A210538EEF; Mon, 15 Apr 2013 15:57:51 -0700 (PDT) From: "Jim Schaad" To: "'Greg Hudson'" , "Larry Zhu" References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> <51671F8E.3050701@mit.edu> In-Reply-To: <51671F8E.3050701@mit.edu> Date: Mon, 15 Apr 2013 15:57:10 -0700 Message-ID: <02cf01ce3a2c$902997a0$b07cc6e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQInhc4BOAu809luPPTSMSXo7gVgygHxuRa0AVJmqS0Br5xmXJf9r4UQ Cc: kitten@ietf.org Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 22:57:52 -0000 Larry Do we know if Msft has also implemented this and if so which did they use? Jim > -----Original Message----- > From: Greg Hudson [mailto:ghudson@MIT.EDU] > Sent: Thursday, April 11, 2013 1:40 PM > To: Jim Schaad > Cc: kitten@ietf.org > Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb- > 00.txt > > Unfortunately, I have another issue to raise. > > We implemented IAKERB for MIT krb5 1.9, but due to an oversight, we > implemented draft-zhu-ws-kerb-03 instead of draft-ietf-krb-wg-iakerb-02. > Looking at the two drafts briefly, it appears that: > > * Both use the same mech OID, the same IAKERB_PROXY token format, and > the same error codes. Both require an authenticator subkey in the AP-REQ. > > * The two drafts define the "finished" extension slightly differently: > > - draft-zhu-ws-kerb-03 defines the data type as TBD and a key usage of 42. In > MIT krb5 1.9, we used an extension type of 1. > > - draft-ietf-krb-wg-iakerb-02 refers to draft-zhu-pku2u-09, which uses an > extension type of 2 and a key usage of 41. > > The two drafts use functionally identical ASN.1 sequences, checksum > contents, and checksum keys. They use different names for the data type, > ASN.1 type name, and ASN.1 sequence field name, but those have no impact > on the wire encoding. > > Because of the differences in data type and key usage, the two drafts are not > interoperable. Conceivably an acceptor could allow both versions of the > finished extension, but an initiator would have to guess at what the other end > can accept. > > The only other IAKERB implementation I'm aware of is in OSX, which appears > to implement draft-ietf-krb-wg-iakerb-02. From lukeh@padl.com Tue Apr 16 06:29:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4390721F969F for ; Tue, 16 Apr 2013 06:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 ggLuIPm4dd07 for ; Tue, 16 Apr 2013 06:29:41 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id B6C4521F969B for ; Tue, 16 Apr 2013 06:29:41 -0700 (PDT) Received: by us.padl.com with ESMTP id r3GDTQep019516; Tue, 16 Apr 2013 09:29:29 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <02cf01ce3a2c$902997a0$b07cc6e0$@augustcellars.com> Date: Tue, 16 Apr 2013 09:29:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3151B618-970E-4F21-9C8C-E21984F9024D@padl.com> References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> <51671F8E.3050701@mit.edu> <02cf01ce3a2c$902997a0$b07cc6e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 13:29:42 -0000 I don't think MS implemented it, last time I checked. Greg -- I know you don't want to break stuff, but do you know if anyone = has deployed MIT's IAKERB? Could we make the old initiator behaviour a = config time option? -- Luke= From lukeh@padl.com Tue Apr 16 08:28:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D82621F9711 for ; Tue, 16 Apr 2013 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 qXgLL0GZ0jkM for ; Tue, 16 Apr 2013 08:28:31 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0067721F9710 for ; Tue, 16 Apr 2013 08:28:30 -0700 (PDT) Received: by us.padl.com with ESMTP id r3GFSDaX025955; Tue, 16 Apr 2013 11:28:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Tue, 16 Apr 2013 11:28:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 15:28:31 -0000 FWIW, my gut feeling is that we should do what PKU2U does, including = assigning EKUs to currently registered GSS service names. For = unregistered service names, or domain-based service names, the URI SAN = should be used. (Not sure whether we should ignore the EKUs in that = case?) Of course, my gut is directly indexed to ease of implementation and what = my current implementation does. I am usually happy to change my mind ;-) -- Luke= From ghudson@mit.edu Tue Apr 16 08:39:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C896821F974E for ; Tue, 16 Apr 2013 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 M9-1O9+yecFS for ; Tue, 16 Apr 2013 08:39:38 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3243B21F9748 for ; Tue, 16 Apr 2013 08:39:38 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-94-516d70b9ffe9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 24.F7.21847.9B07D615; Tue, 16 Apr 2013 11:39:37 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r3GFdaQZ009453; Tue, 16 Apr 2013 11:39:36 -0400 Received: from [18.189.109.93] ([18.189.109.93]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r3GFdW0j019827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 11:39:36 -0400 Message-ID: <516D70B4.1060803@mit.edu> Date: Tue, 16 Apr 2013 11:39:32 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jim Schaad References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> <51671F8E.3050701@mit.edu> <006301ce36fb$1dc3b760$594b2620$@augustcellars.com> In-Reply-To: <006301ce36fb$1dc3b760$594b2620$@augustcellars.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hRV1t1ZkBtoMPu1uMXq6d/ZLI5uXsXi wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGVM2hBbcICt4s3ySawNjFNYuxg5OSQETCR6 Zz5kgrDFJC7cW88GYgsJ7GOUOD8nrYuRC8jeyCix6uIMJghnLZPE12U9zCBVvAJqEu0f7oPZ LAKqEv+X7GQBsdkElCUOnv0GZosKhEhcfLqFFaJeUOLkzCdgcREBdYmtq2+CbWYWEJa4sH0v WI2wQJjE4sb5bBDLfjBKTFu+CKyBU8BBYvqie+wQp0pKLJrWyQLRrCPxru8BM4QtL7H97Rzm CYxCs5Dsm4WkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCA1uS dwfju4NKhxgFOBiVeHgD5HMChVgTy4orcw8xSnIwKYnyRuXnBgrxJeWnVGYkFmfEF5XmpBYf YpTgYFYS4T3rCJTjTUmsrEotyodJSXOwKInzXkm56S8kkJ5YkpqdmlqQWgSTleHgUJLgzQIZ KliUmp5akZaZU4KQZuLgBBnOAzQ8E6SGt7ggMbc4Mx0if4pRUUqcdytIQgAkkVGaB9cLSzyv GMWBXhHmnQFSxQNMWnDdr4AGMwENPrAqG2RwSSJCSqqBcWbTp1LPCatYdjMarjWLm7OO9cJi rXNB+61t2Sfs8z2Tn7q246Jx63/eaflZjLs0L331L3mz4vwNoSb5o7vna0n9DhVQMulvYPRt VZ3eV6x8fB/fk86EH/5OyxW5pmnF8oSqsmpJix1zZiiPKdeUPpTw+OeRb0d7bprkvkzXOmry SPKw8NNmJZbijERDLeai4kQANuJ//BcDAAA= Cc: kitten@ietf.org Subject: Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 15:39:38 -0000 On 04/11/2013 05:25 PM, Jim Schaad wrote: > We can easily define both numbers as extensions and say that servers must do > both, so that does not seem to be a big deal. That's enough in the long term, and I can't think of anything which would be helpful to initiators in the short term. (Even if we could find a way for acceptors to indicate whether they support draft-zhu-ws-kerb or draft-ietf-krb-wg-iakerb or both, the only acceptors who would implement it would be the ones are are agnostic anyway.) > Is there any difference between the key usage of 41 and r2 that is > significant? The key usage is just a number, used as input for RFC 3961 key derivation. I didn't find any other differences between the checksums in my reading of the two drafts; they both appeared to use the same keys and contents. From simon@josefsson.org Tue Apr 16 15:19:36 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDF121F97A7 for ; Tue, 16 Apr 2013 15:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[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 znYD3jATMrC9 for ; Tue, 16 Apr 2013 15:19:36 -0700 (PDT) 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 053C221F97A2 for ; Tue, 16 Apr 2013 15:19:34 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-56-49.mobileonline.telia.com [95.192.56.49]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r3GMJUm2018654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 17 Apr 2013 00:19:32 +0200 X-Hashcash: 1:22:130416:kitten@ietf.org::huEsPAuhZSNup5Xz:A1HU From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 17 Apr 2013 00:19:25 +0200 Message-ID: <878v4iw236.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [kitten] Kitten WG Interim meeting May 6th 8am PDT X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 22:19:37 -0000 The Kitten WG is planning to hold a virtual interim meeting on May 6th 8am PDT. We will use Jabber, WebEx and/or conference dial-in. The agenda would include: 1. Resolve the GSS-API mutual authentication requirements for the three SASL mechanisms; OpenID, SAML, and OAuth. We can loosen the restrictions of GS2 mechanisms to require mutual authentication or if this proves unsuccessful then remove the GS2 feature of the aforementioned SASL mechanisms. 2. Find/pick a solution to indicate successful a channel binding, ala draft-williams-kitten-channel-bound-flag. There are a couple of options proposed; create a NULL context in which all mechanisms need to be aware of or create new set cred options that applications would need to be changed. The list discussion on this topic had not reached consensus. The Jabber service is available from http://www.ietf.org/jabber/ and our group name is "kitten". Let us know ASAP if you have comments on the agenda or date. /Simon From ietf@augustcellars.com Thu Apr 18 10:24:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFE621F936E for ; Thu, 18 Apr 2013 10:24:16 -0700 (PDT) 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=0.000, 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 i1ILgUPdUukG for ; Thu, 18 Apr 2013 10:24:10 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 68B6F21F923C for ; Thu, 18 Apr 2013 10:24:08 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id DE69138F1A; Thu, 18 Apr 2013 10:24:07 -0700 (PDT) From: "Jim Schaad" To: "'Simon Josefsson'" , References: <878v4iw236.fsf@latte.josefsson.org> In-Reply-To: <878v4iw236.fsf@latte.josefsson.org> Date: Thu, 18 Apr 2013 10:23:22 -0700 Message-ID: <049301ce3c59$6e726630$4b573290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGvnpC+X7kWq84BnW0APRwPEm9bo5kZdV2g Subject: Re: [kitten] Kitten WG Interim meeting May 6th 8am PDT X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 17:24:16 -0000 Simply because I want to get it done. Can we discuss the set off issues related to the IAKERB draft? This should be relatively short. I will vote for Jabber/WebEx rather than dial-in. Jim > -----Original Message----- > From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of > Simon Josefsson > Sent: Tuesday, April 16, 2013 3:19 PM > To: kitten@ietf.org > Subject: [kitten] Kitten WG Interim meeting May 6th 8am PDT > > The Kitten WG is planning to hold a virtual interim meeting on May 6th 8am > PDT. We will use Jabber, WebEx and/or conference dial-in. > > The agenda would include: > > 1. Resolve the GSS-API mutual authentication requirements for the three > SASL mechanisms; OpenID, SAML, and OAuth. We can loosen the > restrictions of GS2 mechanisms to require mutual authentication or if > this proves unsuccessful then remove the GS2 feature of the > aforementioned SASL mechanisms. > > 2. Find/pick a solution to indicate successful a channel binding, ala > draft-williams-kitten-channel-bound-flag. There are a couple of > options proposed; create a NULL context in which all mechanisms need > to be aware of or create new set cred options that applications would > need to be changed. The list discussion on this topic had not > reached consensus. > > The Jabber service is available from http://www.ietf.org/jabber/ and our > group name is "kitten". > > Let us know ASAP if you have comments on the agenda or date. > > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From kwburgi@tycho.ncsc.mil Fri Apr 19 04:55:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF08421F8F0E for ; Fri, 19 Apr 2013 04:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 C6kU0ev4QU2b for ; Fri, 19 Apr 2013 04:55:49 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEF321F8EB3 for ; Fri, 19 Apr 2013 04:55:45 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id a55eac6c000adeaf ; Fri, 19 Apr 2013 07:54:15 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r3JBtiCW003840 for ; Fri, 19 Apr 2013 07:55:44 -0400 Message-Id: <14C027B5-733D-441F-81EF-6856B4BA2E3F@tycho.ncsc.mil> From: Kelley Burgin To: kitten@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-64--629047827 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Apr 2013 07:58:12 -0400 References: <20130419114305.13660.72069.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [kitten] Fwd: New Version Notification for draft-kitten-aes-cts-hmac-sha2-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 11:55:53 -0000 --Apple-Mail-64--629047827 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This document is the updated version of draft-burgin-kerberos-aes-cbc- hmac-sha2-02. It has the requested changes referring to CTS and adds test vectors. We also made a few text changes to be NIST compliant. Kelley Begin forwarded message: > From: internet-drafts@ietf.org > Date: April 19, 2013 7:43:05 AM EDT > To: "Michael A. Peck" , "Kelley W. Burgin" >, Kelley Burgin , Michael Peck > > Subject: New Version Notification for draft-kitten-aes-cts-hmac- > sha2-00.txt > > > A new version of I-D, draft-kitten-aes-cts-hmac-sha2-00.txt > has been successfully submitted by Kelley W. Burgin and posted to the > IETF repository. > > Filename: draft-kitten-aes-cts-hmac-sha2 > Revision: 00 > Title: AES Encryption with HMAC-SHA2 for Kerberos 5 > Creation date: 2013-04-19 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-kitten-aes-cts-hmac-sha2-00.txt > Status: http://datatracker.ietf.org/doc/draft-kitten-aes-cts-hmac-sha2 > Htmlized: http://tools.ietf.org/html/draft-kitten-aes-cts-hmac-sha2-00 > > > Abstract: > This document specifies two encryption types and two corresponding > checksum types for Kerberos 5. The new types use AES in CTS mode > (CBC mode with ciphertext stealing) for confidentiality and HMAC > with > a SHA-2 hash for integrity. > > > > > The IETF Secretariat > --Apple-Mail-64--629047827 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable This document is the updated = version of draft-burgin-kerberos-aes-cbc-hmac-sha2-02. It has the = requested changes referring to CTS and adds test vectors. We also made a = few text changes to be NIST = compliant.

Kelley

Begin forwarded = message:

Date: April 19, 2013 7:43:05 AM = EDT
To: "Michael A. Peck" <mpeck@mitre.org>, "Kelley W. = Burgin" <kwburgi@tycho.ncsc.mil>, = Kelley Burgin <kwburgi@tycho.ncsc.mil>, = Michael Peck <mpeck@mitre.org>
Subject: = New Version Notification for = draft-kitten-aes-cts-hmac-sha2-00.txt


A new = version of I-D, draft-kitten-aes-cts-hmac-sha2-00.txt
has been = successfully submitted by Kelley W. Burgin and posted to the
IETF = repository.

Filename: = draft-kitten-aes-cts-hmac-sha2
Revision: 00
Title: AES = Encryption with HMAC-SHA2 for Kerberos 5
Creation date: = 2013-04-19
Group: Individual Submission
Number = of pages: 12
URL: =             http://www.ietf.org/internet-drafts/draft-kitten-aes-cts-hmac-sha= 2-00.txt
Status: =          ht= tp://datatracker.ietf.org/doc/draft-kitten-aes-cts-hmac-sha2
Htmliz= ed:        http= ://tools.ietf.org/html/draft-kitten-aes-cts-hmac-sha2-00


Ab= stract:
  This document specifies two encryption types and = two corresponding
  checksum types for Kerberos 5. =  The new types use AES in CTS mode
  (CBC mode with = ciphertext stealing) for confidentiality and HMAC with
  a = SHA-2 hash for integrity.




The IETF = Secretariat


= --Apple-Mail-64--629047827-- From internet-drafts@ietf.org Fri Apr 19 06:58:02 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2204B21F960E; Fri, 19 Apr 2013 06:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 nSEOfTl9ul5q; Fri, 19 Apr 2013 06:58:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD721F960A; Fri, 19 Apr 2013 06:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130419135801.6388.52841.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2013 06:58:01 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 13:58:02 -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 Gen= eration Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Author(s) : Kelley W. Burgin Michael A. Peck Filename : draft-ietf-kitten-aes-cts-hmac-sha2-00.txt Pages : 12 Date : 2013-04-19 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Fri Apr 19 07:25:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1F221F944A for ; Fri, 19 Apr 2013 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB+9HzMGp1j9 for ; Fri, 19 Apr 2013 07:25:49 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59621F9427 for ; Fri, 19 Apr 2013 07:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BEE7420248 for ; Fri, 19 Apr 2013 10:25:43 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guV_GDIdUplO for ; Fri, 19 Apr 2013 10:25:43 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Fri, 19 Apr 2013 10:25:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 858CE4499; Fri, 19 Apr 2013 10:25:44 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org References: <20130419135801.6388.52841.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2013 10:25:44 -0400 In-Reply-To: <20130419135801.6388.52841.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 19 Apr 2013 06:58:01 -0700") Message-ID: 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 Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:25:50 -0000 HI, folks. After doing a complete read-through of this draft I expect to be starting a working group last call. Please feel free to start sending comments now although the timer will start after I've had a read-through. From hartmans@mit.edu Fri Apr 19 07:27:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6F21F944A for ; Fri, 19 Apr 2013 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXsjYQshTXwt for ; Fri, 19 Apr 2013 07:27:40 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 664A621F926E for ; Fri, 19 Apr 2013 07:27:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A537A20248; Fri, 19 Apr 2013 10:27:34 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSTDhQkHhVC4; Fri, 19 Apr 2013 10:27:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 19 Apr 2013 10:27:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 753D94499; Fri, 19 Apr 2013 10:27:34 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <878v4iw236.fsf@latte.josefsson.org> <049301ce3c59$6e726630$4b573290$@augustcellars.com> Date: Fri, 19 Apr 2013 10:27:34 -0400 In-Reply-To: <049301ce3c59$6e726630$4b573290$@augustcellars.com> (Jim Schaad's message of "Thu, 18 Apr 2013 10:23:22 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, 'Simon Josefsson' Subject: Re: [kitten] Kitten WG Interim meeting May 6th 8am PDT X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:27:40 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Simply because I want to get it done. Can we discuss the set Jim> off issues related to the IAKERB draft? This should be Jim> relatively short. Jim> I will vote for Jabber/WebEx rather than dial-in. I assume if we do webex we'll have dialin support for the voice portion. Although I believe ietf webex only has local numbers. For one I cannot use the webex client (or at least don't want to reinstall either my laptop or desktop so I can), so if there is not a way to call in via PSTN, you won't have me on voice. From shawn.emery@oracle.com Fri Apr 19 12:37:06 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76821F91CA for ; Fri, 19 Apr 2013 12:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5CZd5SZ7nyFW for ; Fri, 19 Apr 2013 12:37:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7C19621F8614 for ; Fri, 19 Apr 2013 12:37:05 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3JJb4O3024833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 19 Apr 2013 19:37:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3JJb30K011070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 19 Apr 2013 19:37:03 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3JJb3Mf011060 for ; Fri, 19 Apr 2013 19:37:03 GMT Received: from [10.159.66.19] (/10.159.66.19) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Apr 2013 12:37:02 -0700 Message-ID: <51719CBA.4050208@oracle.com> Date: Fri, 19 Apr 2013 13:36:26 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: kitten@ietf.org References: <878v4iw236.fsf@latte.josefsson.org> <049301ce3c59$6e726630$4b573290$@augustcellars.com> In-Reply-To: <049301ce3c59$6e726630$4b573290$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [kitten] Kitten WG Interim meeting May 6th 8am PDT X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:37:06 -0000 On 04/18/13 11:23 AM, Jim Schaad wrote: > Simply because I want to get it done. Can we discuss the set off issues > related to the IAKERB draft? This should be relatively short. Sounds reasonable. I've placed this at the end of the agenda: http://www.ietf.org/proceedings/interim/2013/05/06/kitten/agenda/agenda-interim-2013-kitten-1 > I will vote for Jabber/WebEx rather than dial-in. Yes, last I checked, WebEx and audio conference is provided with toll-free (US/Canada) and global call-in numbers. Shawn. -- >> -----Original Message----- >> From:kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf > Of >> Simon Josefsson >> Sent: Tuesday, April 16, 2013 3:19 PM >> To:kitten@ietf.org >> Subject: [kitten] Kitten WG Interim meeting May 6th 8am PDT >> >> The Kitten WG is planning to hold a virtual interim meeting on May 6th 8am >> PDT. We will use Jabber, WebEx and/or conference dial-in. >> >> The agenda would include: >> >> 1. Resolve the GSS-API mutual authentication requirements for the three >> SASL mechanisms; OpenID, SAML, and OAuth. We can loosen the >> restrictions of GS2 mechanisms to require mutual authentication or if >> this proves unsuccessful then remove the GS2 feature of the >> aforementioned SASL mechanisms. >> >> 2. Find/pick a solution to indicate successful a channel binding, ala >> draft-williams-kitten-channel-bound-flag. There are a couple of >> options proposed; create a NULL context in which all mechanisms need >> to be aware of or create new set cred options that applications would >> need to be changed. The list discussion on this topic had not >> reached consensus. >> >> The Jabber service is available fromhttp://www.ietf.org/jabber/ and our >> group name is "kitten". >> >> Let us know ASAP if you have comments on the agenda or date. >> >> /Simon >> _______________________________________________ >> 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 iesg-secretary@ietf.org Fri Apr 19 14:19:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAC721F8F05; Fri, 19 Apr 2013 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UnTMx9q6K-UP; Fri, 19 Apr 2013 14:19:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 203D721F8C10; Fri, 19 Apr 2013 14:19:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130419211915.4261.25601.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2013 14:19:15 -0700 Cc: kitten@ietf.org Subject: [kitten] KITTEN WG Virtual Interim Meeting: May 6, 2013 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 21:19:15 -0000 The Kitten WG is planning to hold a virtual interim meeting on May 6th, = 2013 at 8am PDT, using Jabber, WebEx and/or conference dial-in. The latest agenda is/will be at: http://www.ietf.org/proceedings/interim/2013/05/06/kitten/agenda/agenda-int= erim-2013-kitten-1 Additional information will be announced on the KITTEN WG mailing list: http://www.ietf.org/mail-archive/web/kitten/current/maillist.html From jhutz@cmu.edu Wed Apr 24 15:06:49 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECA621F9120 for ; Wed, 24 Apr 2013 15:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03IFEh14IW2t for ; Wed, 24 Apr 2013 15:06:48 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0321F8E2C for ; Wed, 24 Apr 2013 15:06:48 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r3OM6hdw017990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 18:06:44 -0400 (EDT) Message-ID: <1366841203.2711.428.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Wed, 24 Apr 2013 18:06:43 -0400 In-Reply-To: <31638_1366059552_r3FKxBF6018289_CAK3OfOjwXvpFr2uBCcRifs+8JDUba1_-_O9YpCYf6wR1Qv4__w@mail.gmail.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <31638_1366059552_r3FKxBF6018289_CAK3OfOjwXvpFr2uBCcRifs+8JDUba1_-_O9YpCYf6wR1Qv4__w@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: "kitten@ietf.org" , jhutz@cmu.edu Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:06:49 -0000 On Mon, 2013-04-15 at 15:59 -0500, Nico Williams wrote: > On Monday, April 15, 2013, Luke Howard wrote: > > > > > On 15/04/2013, at 1:57 PM, Luke Howard wrote: > > > > > Ah, thanks for this! Are GSS and DNS service names always aligned? > > > > For example, RFC 6120 registers "xmpp" as a GSS-API service name, but > > "xmpp-client" and "xmpp-server" as IANA service names. So there's no > > straightforward mapping. > > > That's a spec bug, IMO. We could bake that in code. we could update IANA > instructions to avoid this in the future. Um. ssh/telnet/whatever vs host ? From lukeh@padl.com Wed Apr 24 15:43:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAC821F8D61 for ; Wed, 24 Apr 2013 15:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydjSUgulDVCx for ; Wed, 24 Apr 2013 15:43:14 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8121F8D29 for ; Wed, 24 Apr 2013 15:43:03 -0700 (PDT) Received: by us.padl.com with ESMTP id r3OMgtkH028195; Wed, 24 Apr 2013 18:42:59 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <1366841203.2711.428.camel@minbar.fac.cs.cmu.edu> Date: Wed, 24 Apr 2013 23:42:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85C9C791-8920-4301-BDD4-F20098FFE2FC@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <31638_1366059552_r3FKxBF6018289_CAK3OfOjwXvpFr2uBCcRifs+8JDUba1_-_O9YpCYf6wR1Qv4__w@mail.gmail.com> <1366841203.2711.428.camel@minbar.fac.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:43:15 -0000 >>> On 15/04/2013, at 1:57 PM, Luke Howard wrote: >>>=20 >>>> Ah, thanks for this! Are GSS and DNS service names always aligned? >>>=20 >>> For example, RFC 6120 registers "xmpp" as a GSS-API service name, = but >>> "xmpp-client" and "xmpp-server" as IANA service names. So there's no >>> straightforward mapping. >>=20 >>=20 >> That's a spec bug, IMO. We could bake that in code. we could update = IANA >> instructions to avoid this in the future. >=20 > Um. ssh/telnet/whatever vs host ? And www/http vs http. My thoughts were described in my message of 16 = April, anyway (which was: do what PKU2U does, but also allow URI SANs = containing BrowserID URNs, in which case SANs/EKUs are ignored). -- Luke= From nico@cryptonector.com Wed Apr 24 16:08:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710F821F920B for ; Wed, 24 Apr 2013 16:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 ECD0GKq1YYCq for ; Wed, 24 Apr 2013 16:08:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D7CD621F869A for ; Wed, 24 Apr 2013 16:08:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 33F8E26C063 for ; Wed, 24 Apr 2013 16:08:07 -0700 (PDT) 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=lccYRDAPcBUsvtGKkloM zhmKHSY=; b=aOfsA958bYGSFyS2qrbdHQ4Cw32nnoV+1J/Gxe01DYx7Ey24vHc3 07WxM/qIekXSQc4yHrW2FicN/rM//pU4gbJvDIJb2nzthnqVfvggO8ifAi94LUe4 NE7SU++04rcq3q6TZL5iafdm24mCe2VOQOMyXWmmrnAzwCUFc30qpE0= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 D07CA26C05E for ; Wed, 24 Apr 2013 16:08:06 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id h11so7951080wiv.8 for ; Wed, 24 Apr 2013 16:08:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y7escXPvOJQitEJsls34IXJ9wMo5ova+bYd7hVCNKP4=; b=MUyfcpYf1nTX8XNw3Mw/R3WyXJ6KXGrKTOab31LqMO97idc2ij9yG8aR2dfDbezOjz 5tM3iiBMGN2L9Pe2eFoQnQnjrWnrACm78o7uR+O3ESt8VCizKVsDz/7sI5c2KIZIPoof W+oz3R7NSDrM5fRU8acwMECxznKFJPPlZiW5V08hVPOgBshniNLHtUSBVt1S7QG4Td+q bEn0viMGx/SJeBkOlvKxcXXeNDP3OLDIVgwAlOyaRHmRbtssVopht+7nDYYUK7eIS62P OZcwJ93tOxv7JrwopVMAUzdIwxEDqNUszzMxI1uYQAFVGAVw/4sDYackOUwhEIjrKYHp EOWQ== MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr39918825wic.33.1366844885646; Wed, 24 Apr 2013 16:08:05 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Wed, 24 Apr 2013 16:08:05 -0700 (PDT) In-Reply-To: <1366841203.2711.428.camel@minbar.fac.cs.cmu.edu> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <31638_1366059552_r3FKxBF6018289_CAK3OfOjwXvpFr2uBCcRifs+8JDUba1_-_O9YpCYf6wR1Qv4__w@mail.gmail.com> <1366841203.2711.428.camel@minbar.fac.cs.cmu.edu> Date: Wed, 24 Apr 2013 18:08:05 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 23:08:09 -0000 On Wed, Apr 24, 2013 at 5:06 PM, Jeffrey Hutzelman wrote: > On Mon, 2013-04-15 at 15:59 -0500, Nico Williams wrote: >> On Monday, April 15, 2013, Luke Howard wrote: >> >> > >> > On 15/04/2013, at 1:57 PM, Luke Howard wrote: >> > >> > > Ah, thanks for this! Are GSS and DNS service names always aligned? >> > >> > For example, RFC 6120 registers "xmpp" as a GSS-API service name, but >> > "xmpp-client" and "xmpp-server" as IANA service names. So there's no >> > straightforward mapping. >> >> >> That's a spec bug, IMO. We could bake that in code. we could update IANA >> instructions to avoid this in the future. > > Um. ssh/telnet/whatever vs host ? Right, we'll have exceptions. But why add more such things? From lukeh@padl.com Thu Apr 25 09:57:10 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44E821F9669 for ; Thu, 25 Apr 2013 09:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 SqlRvXKDHScc for ; Thu, 25 Apr 2013 09:57:09 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0E21F9662 for ; Thu, 25 Apr 2013 09:57:09 -0700 (PDT) Received: by us.padl.com with ESMTP id r3PGv4Gq027884; Thu, 25 Apr 2013 12:57:07 -0400 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_410340D5-E510-4672-86BF-F17D81C0A5B0" Date: Thu, 25 Apr 2013 17:57:03 +0100 References: <20130425163203.26591.89211.idtracker@ietfa.amsl.com> To: "dev-identity@lists.mozilla.org" , "kitten@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, HTML_MESSAGE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Subject: [kitten] draft-howard-gss-browserid-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 16:57:10 -0000 --Apple-Mail=_410340D5-E510-4672-86BF-F17D81C0A5B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A new version of I-D, draft-howard-gss-browserid-04.txt has been successfully submitted by Luke Howard and posted to the IETF repository. Filename: draft-howard-gss-browserid Revision: 04 Title: A SASL and GSS-API Mechanism for the BrowserID = Authentication Protocol Creation date: 2013-04-25 Group: Individual Submission Number of pages: 46 URL: = http://www.ietf.org/internet-drafts/draft-howard-gss-browserid-04.txt Status: = http://datatracker.ietf.org/doc/draft-howard-gss-browserid Htmlized: = http://tools.ietf.org/html/draft-howard-gss-browserid-04 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-browserid-04 Abstract: This document defines protocols, procedures and conventions for a Generic Security Service Application Program Interface (GSS-API) security mechanism based on the BrowserID authentication mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications may use BrowserID. The IETF Secretariat -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_410340D5-E510-4672-86BF-F17D81C0A5B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = draft-howard-gss-browserid
Revision: 04
Title: A SASL = and GSS-API Mechanism for the BrowserID Authentication = Protocol
Creation date: 2013-04-25
Group: = Individual Submission
Number of pages: 46
URL: =             http://www.ietf.org/internet-drafts/draft-howard-gss-browserid-04.txt=
Status:          http:/= /datatracker.ietf.org/doc/draft-howard-gss-browserid
Htmlized: =        http://t= ools.ietf.org/html/draft-howard-gss-browserid-04
Diff: =            = http://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-browserid-04
Abstract:
  This document defines protocols, procedures = and conventions for a
  Generic Security Service = Application Program Interface (GSS-API)
  security = mechanism based on the BrowserID authentication mechanism.
=   Through the GS2 family of mechanisms defined in RFC 5801, = these
  protocols also define how Simple Authentication = and Security Layer
  (SASL, RFC 4422) applications may use = BrowserID.




The IETF = Secretariat



= --Apple-Mail=_410340D5-E510-4672-86BF-F17D81C0A5B0-- From hartmans@mit.edu Thu Apr 25 13:40:56 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2FC21F96B3 for ; Thu, 25 Apr 2013 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 CwitJe32FSGw for ; Thu, 25 Apr 2013 13:40:54 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5F521F91A3 for ; Thu, 25 Apr 2013 13:40:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 10E1B20248; Thu, 25 Apr 2013 16:38:51 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA7_XeM8hOuq; Thu, 25 Apr 2013 16:38:49 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 25 Apr 2013 16:38:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ED2FC4499; Thu, 25 Apr 2013 16:40:46 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> Date: Thu, 25 Apr 2013 16:40:46 -0400 In-Reply-To: <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> (Luke Howard's message of "Tue, 16 Apr 2013 11:28:13 -0400") Message-ID: 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" , Nico Williams Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 20:40:56 -0000 >>>>> "Luke" == Luke Howard writes: Luke> FWIW, my gut feeling is that we should do what PKU2U does, Luke> including assigning EKUs to currently registered GSS service Luke> names. For unregistered service names, or domain-based service Luke> names, the URI SAN should be used. (Not sure whether we should Luke> ignore the EKUs in that case?) Of course, my gut is directly I tend to agree. I tend to agree with the possible exception of URI SAN. I wonder if the SRV SAN would not be more appropriate both here and for pku2u. In the case where you have a service-specific SAN I think ignoring EUK is fine. From lukeh@padl.com Thu Apr 25 14:25:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C121F96CD for ; Thu, 25 Apr 2013 14:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 VQNwDuPyFWJJ for ; Thu, 25 Apr 2013 14:25:47 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4726B21F962E for ; Thu, 25 Apr 2013 14:25:45 -0700 (PDT) Received: by us.padl.com with ESMTP id r3PLPdcb011476; Thu, 25 Apr 2013 17:25:42 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Thu, 25 Apr 2013 22:25:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Nico Williams Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:25:56 -0000 > I tend to agree. > I tend to agree with the possible exception of URI SAN. > I wonder if the SRV SAN would not be more appropriate both here and = for > pku2u. I'm on the fence. The SRV SAN has the problem of differing IANA vs GSS = service names. The URI SAN has the problem of, well, there isn't a = standardised URN form for GSS service names beyond what we define in the = BrowserID draft. Either I suspect is going to be problematic for CAs to issue. Name = constraints should be imposable on both, but the relying party is going = to need to know how to apply them. -- Luke= From hartmans@mit.edu Thu Apr 25 14:55:39 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D321F9457 for ; Thu, 25 Apr 2013 14:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 WJchWnZVgwKf for ; Thu, 25 Apr 2013 14:55:38 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4619F21F92C0 for ; Thu, 25 Apr 2013 14:55:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B254D2021D; Thu, 25 Apr 2013 17:53:38 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lHGejVEAg8n; Thu, 25 Apr 2013 17:53:38 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 25 Apr 2013 17:53:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2FEFE4499; Thu, 25 Apr 2013 17:55:35 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> Date: Thu, 25 Apr 2013 17:55:35 -0400 In-Reply-To: (Luke Howard's message of "Thu, 25 Apr 2013 22:25:38 +0100") Message-ID: 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" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:55:39 -0000 Yes. I'm fairly sure CAs will issue neither. I'm definitely in favor of SRV SAN over a URN for GSS service names. I thought you were talking about URI sans like xmpp://painless-security.com From lukeh@padl.com Thu Apr 25 15:02:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BA021F971B for ; Thu, 25 Apr 2013 15:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 jFUVkU6P5ZVN for ; Thu, 25 Apr 2013 15:02:23 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC2D21F9715 for ; Thu, 25 Apr 2013 15:02:23 -0700 (PDT) Received: by us.padl.com with ESMTP id r3PM2HLK013446; Thu, 25 Apr 2013 18:02:21 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Thu, 25 Apr 2013 23:02:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Nico Williams Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:02:24 -0000 On 25/04/2013, at 10:55 PM, Sam Hartman wrote: > Yes. I'm fairly sure CAs will issue neither. >=20 > I'm definitely in favor of SRV SAN over a URN for GSS service names. > I thought you were talking about URI sans like > xmpp://painless-security.com No, that would introduce another set of mapping problems. URIs in GSS = BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service = name. For example, urn:x-gss:xmpp/painless-security.com. Hopefully we can get a non-experimental URN assigned when we progress = the draft (tips, anyone?) (Technically, we could probably just put the service name in the = assertion directly, given that we specify the protocol behaviour for = both endpoints. But it would be valid for a BrowserID implementation to = reject an audience that is not a valid URI.) -- Luke= From hartmans@painless-security.com Thu Apr 25 16:21:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3115B21F972E for ; Thu, 25 Apr 2013 16:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 i53menFFUzgN for ; Thu, 25 Apr 2013 16:21:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB2E21F972B for ; Thu, 25 Apr 2013 16:21:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5EB812021D; Thu, 25 Apr 2013 19:19:51 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3E3WJ_K6weN; Thu, 25 Apr 2013 19:19:50 -0400 (EDT) Received: from [100.250.29.189] (m842436d0.tmodns.net [208.54.36.132]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: hartmans-smtp@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA; Thu, 25 Apr 2013 19:19:18 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----QW59A5TLBLAOPTENLMJUFSOZAYV4L2" From: Sam Hartman Date: Thu, 25 Apr 2013 19:20:35 -0400 To: Luke Howard ,Sam Hartman Message-ID: <99e467bc-610f-4f61-bc3c-5f3094e4430f@email.android.com> Cc: "kitten@ietf.org" , Nico Williams Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:21:54 -0000 ------QW59A5TLBLAOPTENLMJUFSOZAYV4L2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I think srv san sounds better than that Luke Howard wrote: > >On 25/04/2013, at 10:55 PM, Sam Hartman wrote: > >> Yes. I'm fairly sure CAs will issue neither. >> >> I'm definitely in favor of SRV SAN over a URN for GSS service names. >> I thought you were talking about URI sans like >> xmpp://painless-security.com > >No, that would introduce another set of mapping problems. URIs in GSS >BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service >name. For example, urn:x-gss:xmpp/painless-security.com. > >Hopefully we can get a non-experimental URN assigned when we progress >the draft (tips, anyone?) > >(Technically, we could probably just put the service name in the >assertion directly, given that we specify the protocol behaviour for >both endpoints. But it would be valid for a BrowserID implementation to >reject an audience that is not a valid URI.) > >-- Luke -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------QW59A5TLBLAOPTENLMJUFSOZAYV4L2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think srv san sounds better than that

Luke Howard <lukeh@padl.com> wrote:

On 25/04/2013, at 10:55 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:

Yes. I'm fairly sure CAs will issue neither.

I'm definitely in favor of  SRV SAN over a URN for GSS service names.
I thought you were talking about URI sans like
xmpp://painless-security.com

No, that would introduce another set of mapping problems. URIs in GSS BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service name. For example, urn:x-gss:xmpp/painless-security.com.

Hopefully we can get a non-experimental URN assigned when we progress the draft (tips, anyone?)

(Technically, we could probably just put the se
 rvice
name in the assertion directly, given that we specify the protocol behaviour for both endpoints. But it would be valid for a BrowserID implementation to reject an audience that is not a valid URI.)

-- Luke

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------QW59A5TLBLAOPTENLMJUFSOZAYV4L2-- From lukeh@padl.com Thu Apr 25 17:13:08 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A472A21F973A for ; Thu, 25 Apr 2013 17:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 jsjPQa0eG4il for ; Thu, 25 Apr 2013 17:13:05 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id EB71621F9730 for ; Thu, 25 Apr 2013 17:13:04 -0700 (PDT) Received: by us.padl.com with ESMTP id r3Q0Cwsm020012; Thu, 25 Apr 2013 20:13:02 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Fri, 26 Apr 2013 01:12:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE389F1-0895-4E4A-A21B-15D2027F5D47@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 00:13:08 -0000 >>> I'm definitely in favor of SRV SAN over a URN for GSS service = names. >=20 > Me too. I disagree but I am happy to change my mind if you can convincingly work = around the IANA port / GSS service name conflicts. >> No, that would introduce another set of mapping problems. URIs in GSS = BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service = name. For example, urn:x-gss:xmpp/painless-security.com. >=20 > The "gss" bit seems superfluous (we don't have that in, say, > Kerberos), and at the same time insufficient (there's no GSS name-type > indication; but then, though Kerberos has a name-type, it's > effectively optional anyways). This is not a representation of a generic GSS name. The "gss" refers to = the fact that this usage of the BrowserID protocol is for a GSS-API = mechanism. Please see: = http://tools.ietf.org/html/draft-howard-gss-browserid-04#section-3.2 This contains a "spn" which is defined here: = http://tools.ietf.org/html/draft-howard-gss-browserid-04#section-3.1.1 If you don't like "x-gss" please feel free to suggest something else, = e.g. "x-spn". :-) >> (Technically, we could probably just put the service name in the = assertion directly, given that we specify the protocol behaviour for = both endpoints. But it would be valid for a BrowserID implementation to = reject an audience that is not a valid URI.) >=20 > In the acceptor's response token? In that case it fails to work as a > constraint on the certificate (since the acceptor can sign whatever it > wants then). No, the audience claim is only in the request assertion. See: = http://tools.ietf.org/html/draft-howard-gss-browserid-04#section-6 and the BrowserID spec here: https://github.com/mozilla/id-specs/blob/prod/browserid/index.md > We might be able to do something else: use BrowserID for the acceptor > credential with the BrowserID certificate signed with the key for a > TLS server PKI EE cert with an EKU denoting the ability to do this. > (Yeah, this just after deciding to use PKIX for the acceptor > credential; sucks, I know. But this should be easier to manage w.r.t. > CAs.) Maybe. I'm loath to make things more complicated, but I guess it depends = how much we want to embrace the existing X.509 CA model. (I was going to = write "subvert".) -- Luke= From nico@cryptonector.com Thu Apr 25 17:34:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B00A21F95F9 for ; Thu, 25 Apr 2013 17:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 fg1GJL61QaDW for ; Thu, 25 Apr 2013 17:34:08 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8B21F955A for ; Thu, 25 Apr 2013 17:34:08 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id E70827E406F for ; Thu, 25 Apr 2013 17:34:07 -0700 (PDT) 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=xZcVBSkhabkq+Ci7YDCe PdCspbs=; b=Qusi2C0p+QSbGjv92ew5Fjo42gcyXf9cCPrDd+ERcqDQKtt4d1h+ tVx1gkfMuylLlI6Pq0AI/O7bkipIMLNPzCPRZ2WE0rqenartx2SY8DRrsxLBShrf W9hhem8BA+ZTmAhxXV+7d+dVNwCnHrORIyLMUf0jrD1YcUQaBjP58XI= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 9B4AD7E4065 for ; Thu, 25 Apr 2013 17:34:07 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hj19so58706wib.15 for ; Thu, 25 Apr 2013 17:34:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oSVAUVy2N7mPdT8jh51FVJQ1wRziTvFSihDkaPBwGp0=; b=VsfaEbc42F1Qmp3tF9VfNdOE7gM9LdMnndNk7gDpEwJxzwm8XYeenetDczbMTWKloo AUqVdh1kxzr7MQPKdmDrmIDYYIWUoImpqoSXEJ9gRvZtpMBw7qKuXWRcF9Dvsb+iJav3 YLUEGgouVrAoUOmxi8EIa4qfoRY0T2itkKxUTxWkmUJ2ouYPjQf33KMvFn99ideQaPDs uaa0gh59F82gRlL56eyBKGs7MMRCYGY/6ihJdjYSFVmHT1iOBcalW8Jpk3595NJOQN+L nd4/E63RktTDnt6m7PAcquDB1Bivw1oWsvI7whZ48wXP6DzSB0FDLK798yZ5IFz8mz71 a68w== MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr820546wik.16.1366936446439; Thu, 25 Apr 2013 17:34:06 -0700 (PDT) Received: by 10.216.66.71 with HTTP; Thu, 25 Apr 2013 17:34:06 -0700 (PDT) In-Reply-To: <2BE389F1-0895-4E4A-A21B-15D2027F5D47@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <2BE389F1-0895-4E4A-A21B-15D2027F5D47@padl.com> Date: Thu, 25 Apr 2013 19:34:06 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 00:34:09 -0000 On Thu, Apr 25, 2013 at 5:02 PM, Luke Howard wrote: > On 25/04/2013, at 10:55 PM, Sam Hartman wrote: >> Yes. I'm fairly sure CAs will issue neither. >> I'm definitely in favor of SRV SAN over a URN for GSS service names. Me too. >> I thought you were talking about URI sans like >> xmpp://painless-security.com > > No, that would introduce another set of mapping problems. URIs in GSS BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service name. For example, urn:x-gss:xmpp/painless-security.com. The "gss" bit seems superfluous (we don't have that in, say, Kerberos), and at the same time insufficient (there's no GSS name-type indication; but then, though Kerberos has a name-type, it's effectively optional anyways). > (Technically, we could probably just put the service name in the assertion directly, given that we specify the protocol behaviour for both endpoints. But it would be valid for a BrowserID implementation to reject an audience that is not a valid URI.) In the acceptor's response token? In that case it fails to work as a constraint on the certificate (since the acceptor can sign whatever it wants then). We might be able to do something else: use BrowserID for the acceptor credential with the BrowserID certificate signed with the key for a TLS server PKI EE cert with an EKU denoting the ability to do this. (Yeah, this just after deciding to use PKIX for the acceptor credential; sucks, I know. But this should be easier to manage w.r.t. CAs.) Nico -- From stpeter@stpeter.im Thu Apr 25 18:23:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB49521F92C0 for ; Thu, 25 Apr 2013 18:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb-0ybsSnNik for ; Thu, 25 Apr 2013 18:23:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44D21F8FEB for ; Thu, 25 Apr 2013 18:23:57 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0DC514004E; Thu, 25 Apr 2013 19:34:54 -0600 (MDT) Message-ID: <5179D72F.1070209@stpeter.im> Date: Thu, 25 Apr 2013 19:23:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luke Howard References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> In-Reply-To: <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 01:23:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/25/13 4:02 PM, Luke Howard wrote: > > On 25/04/2013, at 10:55 PM, Sam Hartman > wrote: > >> Yes. I'm fairly sure CAs will issue neither. >> >> I'm definitely in favor of SRV SAN over a URN for GSS service >> names. I thought you were talking about URI sans like >> xmpp://painless-security.com > > No, that would introduce another set of mapping problems. URIs in > GSS BrowserID look like urn:x-gss:spn where spn is a Kerberos-like > service name. For example, urn:x-gss:xmpp/painless-security.com. > > Hopefully we can get a non-experimental URN assigned when we > progress the draft (tips, anyone?) Hi Luke, I'm happy to help with that. It's really quite straightforward. See RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05. Peter P.S. Oh, and if I have my way, experimental URN namespaces will be going away... :-) http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05#section-5 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRedcvAAoJEOoGpJErxa2p7EQQAKUMfLHVd9YOjO6HEPijUkeR Bz+Kx5aMk2+wJLaf/kBP99olKshLUllXijRbFL8YRfkzdBpXie6eK49RB4Nw1zHe 9Ttz/ISbEaekzWwL9bO21RUhDwHVS7aEV0PqtUL8zAOzYaNyvOlwv0kBVlZ8iMBD 7t1txgnavZl5wcHUV0j/9oP+0dL0NcM4UYXk6rM5ipMIbTJD9g3y75VpLagm2iyq 1PsAZrmRmNJvI68CddHzEJvV9nBUskYPQJB4FHVFz439qExUrtC30Ax4++PPaIK9 gb2V3DEEh1ucrL9SFT7YlnBYYoy2H+dcCGyssLTTAiyrUxQoMR5/C977STRMEwU2 VWSas3imEFcLezWy1NQ7gC7ZsW98sRu4VnLYMaxgMABNb+iagBYOghYKL4MCC1Vz 51qQxYLztMu8vu1OgVNdpERGRjUbyBnP3Lwu0R85dnV9aEOBXhEzpVJ0GFEIwBW3 tjxVbE+B8gW7rCzg6lgzu6GwtrUTuFp5WsIlBoejJ/oF4zC/t2SXDh0g7iuLhGbh n59NGQND4suqBgFylgic1NPJ/GCaD+XkNZ+IN20EP3p8UXCiG4ZfmS5C4M3tdOYX hG13DKY3D2AbylBfeinRtIk/tJxaWYzb3kKPVio/IdefiafrR51PMTNAWCVZLLtC EK78+YtcPocYeD6jdbKu =St9Q -----END PGP SIGNATURE----- From lukeh@padl.com Fri Apr 26 00:42:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1C621F981C for ; Fri, 26 Apr 2013 00:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, 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 hVXi3lE+GRZ3 for ; Fri, 26 Apr 2013 00:42:57 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id DAFFD21F981A for ; Fri, 26 Apr 2013 00:42:56 -0700 (PDT) Received: by us.padl.com with ESMTP id r3Q7gps4005822; Fri, 26 Apr 2013 03:42:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Fri, 26 Apr 2013 08:42:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EF002F2-FA43-4BD5-9A4B-25BB1E51B85D@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <2BE389F1-0895-4E4A-A21B-15D2027F5D47@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:42:57 -0000 >> I disagree but I am happy to change my mind if you can convincingly = work around the IANA port / GSS service name conflicts. >=20 > Maybe we can sidestep that by switching to using BrowserID credentials > for the acceptor. Indeed. We could allow either/or. Of course, then we need to define how = service names are encoded in BrowserID certificates, but it's a lot = simpler when everything is JSON. :-) >> If you don't like "x-gss" please feel free to suggest something else, = e.g. "x-spn". :-) >=20 > Sure, x-spn. OK, I will update the draft. But obviously, this will have to be changed = to something like urn:ietf:params:gss:spn anyway (the gss registry is = created by the EAP naming draft, hopefully that'll be done before us). > Right, if we can't change the CAs, sidestep them. But I'm afraid that > there may be nothing we can to get CAs to issue suitable certs. Do > CAs issue certs with EKUs? We have one CA telling us "no". Let's step back a little. Maybe most deployments will be happy with = host-based certificates? (No service name.) -- Luke= From lukeh@padl.com Fri Apr 26 00:43:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9721F8518 for ; Fri, 26 Apr 2013 00:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 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 c-1FJpAV6vGd for ; Fri, 26 Apr 2013 00:43:42 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 01FBA21F849C for ; Fri, 26 Apr 2013 00:43:41 -0700 (PDT) Received: by us.padl.com with ESMTP id r3Q7gps5005822; Fri, 26 Apr 2013 03:43:40 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <5179D72F.1070209@stpeter.im> Date: Fri, 26 Apr 2013 08:43:40 +0100 Content-Transfer-Encoding: 7bit Message-Id: <748C745D-B654-4741-A54B-CE1881A5B095@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <5179D72F.1070209@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:43:42 -0000 On 26/04/2013, at 2:23 AM, Peter Saint-Andre wrote: > I'm happy to help with that. It's really quite straightforward. See > RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05. Actually maybe we want RFC 3553 and something like urn:ietf:params:gss:spn? -- Luke From lukeh@padl.com Fri Apr 26 09:00:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6946321F9A49 for ; Fri, 26 Apr 2013 09:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 AK0sCaOizTvK for ; Fri, 26 Apr 2013 09:00:55 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3454C21F9A57 for ; Fri, 26 Apr 2013 09:00:53 -0700 (PDT) Received: by us.padl.com with ESMTP id r3QG0k2u024458; Fri, 26 Apr 2013 12:00:50 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: Date: Fri, 26 Apr 2013 17:00:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <646B72A1-5EC9-4D83-9CC5-726447FE2541@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <2BE389F1-0895-4E4A-A21B-15D2027F5D47@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:00:57 -0000 On 26/04/2013, at 1:34 AM, Nico Williams wrote: > We might be able to do something else: use BrowserID for the acceptor > credential with the BrowserID certificate signed with the key for a > TLS server PKI EE cert with an EKU denoting the ability to do this. > (Yeah, this just after deciding to use PKIX for the acceptor > credential; sucks, I know. But this should be easier to manage w.r.t. > CAs.) Ironically this might force CAs to be more flexible about issuing = certificates with the necessary EKUs or SAN extensions, if they have = competition. :-) -- Luke= From stpeter@stpeter.im Fri Apr 26 09:03:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8A421F9894 for ; Fri, 26 Apr 2013 09:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHkmEkio-DYo for ; Fri, 26 Apr 2013 09:03:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2921F983B for ; Fri, 26 Apr 2013 09:03:18 -0700 (PDT) Received: from ergon.local (unknown [24.9.168.255]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7E3954004E; Fri, 26 Apr 2013 10:14:18 -0600 (MDT) Message-ID: <517AA54A.8000300@stpeter.im> Date: Fri, 26 Apr 2013 10:03:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luke Howard References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <5179D72F.1070209@stpeter.im> <748C745D-B654-4741-A54B-CE1881A5B095@padl.com> In-Reply-To: <748C745D-B654-4741-A54B-CE1881A5B095@padl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:03:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/26/13 1:43 AM, Luke Howard wrote: > > On 26/04/2013, at 2:23 AM, Peter Saint-Andre > wrote: > >> I'm happy to help with that. It's really quite straightforward. >> See RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05. > > Actually maybe we want RFC 3553 and something like > urn:ietf:params:gss:spn? Sure, that's even simpler. I don't think we need a namespace ID here, since we need only a single namespace, not a whole series of them. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJReqVJAAoJEOoGpJErxa2pm3cQAKHkUm/BRVTim3nw+Nhxm0DZ MTKlU/LXaJkaX/NgrBBkcvxAByKs75tCpu9qUkiyQGW7OkShMZPZWKHxuYbJ1e1f Ki8PHKkF+9fboUzpqJRPWFa/Q1y92FSJJbCl8CPpIhRJPPIJk2cVwMpezxpu4iA2 vdjgUwTsm1rNs9Qewf7NCr9/TZHtf4dAChMkfAdQKLZWjyTOBhGtwjxMyVRokKDg PewXPuK51JGN/zbY39gMaR4bxfP0LG0yxtYYM66J/4RGIg6oBF17TKqxe/hzTCny OfOjQhMaphIqI9HRtAGYtYjLWIDCqh5kBcKzitsCyBuSeJ6KMH4I7AD3HS4xFmvE BsXpeR4RPW8FbOcX74XH3P3yfIx3TnQJndeVjloVZ6hiBXwTOYcR+83r461qMTXr cTjQTMli5LfPtZsyOgkAKhxcjp/FWcBdGBmD8D8/IHFQE4ASPlmIpqub1McHP68R dHpGBqwHL6MVrPOypLvo7G8jH3M3andnP0nwPAa2VM7kiCtlxeSsKwX5GvqgjbdA KU4fWQGR5WC82WW5ZmPfnemp2eCjSnB6JAweHOYr1CqnW3aaRVHqCB08I5hK2tIP ciZeNbfjaglDOdutWr2joJ3+hA+PPWpX1dmFekqk0OaXLLQYFgLegrROkswEiJW/ 17rKDOQoAdHN5P7UUxiB =zmo0 -----END PGP SIGNATURE----- From mrex@sap.com Fri Apr 26 09:59:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACFE21F9A6C for ; Fri, 26 Apr 2013 09:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 YO1Bf2YPPtvr for ; Fri, 26 Apr 2013 09:59:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 005C621F99D1 for ; Fri, 26 Apr 2013 09:59:36 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r3QGxZdT007494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Apr 2013 18:59:35 +0200 (MEST) In-Reply-To: <5179D72F.1070209@stpeter.im> To: Peter Saint-Andre Date: Fri, 26 Apr 2013 18:59:34 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130426165934.DFF0B1A6D6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Sam Hartman , Nico Williams Subject: Re: [kitten] BrowserID mutual auth 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:59:38 -0000 A simple comment on use of "urn" in cert SANs. It seems to be currently impossible to constrain "urn" SAN by name contraints in X.509v3 certs. >From a recent PKIX discussion: http://www.ietf.org/mail-archive/web/pkix/current/msg32574.html -Martin Peter Saint-Andre wrote: > > Luke Howard wrote: > > > > On 25/04/2013, at 10:55 PM, Sam Hartman > > wrote: > > > >> Yes. I'm fairly sure CAs will issue neither. > >> > >> I'm definitely in favor of SRV SAN over a URN for GSS service > >> names. I thought you were talking about URI sans like > >> xmpp://painless-security.com > > > > No, that would introduce another set of mapping problems. URIs in > > GSS BrowserID look like urn:x-gss:spn where spn is a Kerberos-like > > service name. For example, urn:x-gss:xmpp/painless-security.com. > > > > Hopefully we can get a non-experimental URN assigned when we > > progress the draft (tips, anyone?) > > Hi Luke, > > I'm happy to help with that. It's really quite straightforward. See > RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05. > > Peter > > P.S. Oh, and if I have my way, experimental URN namespaces will be > going away... :-) > > http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05#section-5 From lukeh@padl.com Fri Apr 26 10:09:04 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE9921F99FD for ; Fri, 26 Apr 2013 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Yup8oNbPYclu for ; Fri, 26 Apr 2013 10:09:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3788A21F99F3 for ; Fri, 26 Apr 2013 10:08:57 -0700 (PDT) Received: by us.padl.com with ESMTP id r3QH8p8d029901; Fri, 26 Apr 2013 13:08:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Luke Howard In-Reply-To: <20130426165934.DFF0B1A6D6@ld9781.wdf.sap.corp> Date: Fri, 26 Apr 2013 18:08:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <692A010F-CC13-41D4-A007-F66EF95DFA9D@padl.com> References: <20130426165934.DFF0B1A6D6@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1503) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: "kitten@ietf.org" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 17:09:05 -0000 On 26/04/2013, at 5:59 PM, Martin Rex wrote: > A simple comment on use of "urn" in cert SANs. It seems to be = currently > impossible to constrain "urn" SAN by name contraints in X.509v3 certs. >=20 > =46rom a recent PKIX discussion: > http://www.ietf.org/mail-archive/web/pkix/current/msg32574.html Thanks for this Martin. I guess this is probably another nail in the = coffin of using URNs in SANs. It's a pity because they're text, easier = to encode than the Kerberos SAN, don't have the IANA/GSS service name = ambiguity, etc. But I am fine with that :-) -- Luke= From johnsonhammond1@hushmail.com Sat Apr 27 14:57:05 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCF521F9908 for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 2aDaO5Bn5jzh for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 17D9221F98DA for ; Sat, 27 Apr 2013 14:57:05 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id ECFEE580B3 for ; Sat, 27 Apr 2013 17:45:04 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:45:04 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B56E6E6736; Sat, 27 Apr 2013 17:45:04 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:45:04 -0400 To: kitten@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174504.B56E6E6736@smtp.hushmail.com> Subject: [kitten] Biggest Fake Conference in Computer Science X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:05 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From internet-drafts@ietf.org Mon Apr 29 19:30:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D182121F9BE8; Mon, 29 Apr 2013 19:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZrVbOsy20Ba8; Mon, 29 Apr 2013 19:30:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 738A321F9BB3; Mon, 29 Apr 2013 19:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130430023041.16275.15830.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 19:30:41 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 02:30:41 -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 Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-07.txt Pages : 37 Date : 2013-04-29 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/