From leifj@mnt.se Sun Dec 2 04:11:12 2012 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 0067521F8C6A for ; Sun, 2 Dec 2012 04:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVC3nNVKbs86 for ; Sun, 2 Dec 2012 04:11:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7CE21F879D for ; Sun, 2 Dec 2012 04:11:11 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1558118lah.31 for ; Sun, 02 Dec 2012 04:11:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Vj42NaP5ZKjClcpdHUlCQgOi7UHPMkKqZpcHbzYMajY=; b=Mg2N6qfLlFSBuDDX1Ssmdo2nZiyWtd6fVriQo/CWwXpwYh+d5xycdSqUHo4fyLgGN1 SsEx1aAn7cpQIxgv35t6dEd+i1kqW3A5qjNrj7HvspwqountI9BmVp7CrEgeG6shuQTz fCoGyUqlEuAxQjcBxue702h0mdycK0pVlxDPyTsMuysB+qidmLwaowhI3JQ0ZB6MTKzJ CVzpJmvTW7qi9eRq9c6FUF5B5I/eb9yHOc6JCcijMVWMrrHQrqgQU75lzhc7WNVJ+UR6 Q+G9b+o9PllJRblY0GIr9Je7xsC8M1hiFib6nN12DKOttg9MTDb+FD1tW8GvxnTSt3Vy Nfhw== Received: by 10.152.108.37 with SMTP id hh5mr6313897lab.52.1354444396149; Sun, 02 Dec 2012 02:33:16 -0800 (PST) Received: from [10.33.3.161] ([212.247.15.226]) by mx.google.com with ESMTPS id oz12sm3898837lab.17.2012.12.02.02.33.13 (version=SSLv3 cipher=OTHER); Sun, 02 Dec 2012 02:33:14 -0800 (PST) Message-ID: <50BB2E68.5090009@mnt.se> Date: Sun, 02 Dec 2012 11:33:12 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: kitten@ietf.org References: <1354293818.7684.319.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1354293818.7684.319.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkTVgPWHWJr7fXj04JxS5/OURzOZV0AC3yYKl4pQpTxX9+jEseDQRYBGi5QDLFwrO6wMs3u Subject: Re: [kitten] [Ietf-krb-wg] iakerb 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: Sun, 02 Dec 2012 12:11:12 -0000 On 11/30/2012 05:43 PM, Jeffrey Hutzelman wrote: > On Fri, 2012-11-30 at 09:19 -0500, Sam Hartman wrote: >> Is there anyone whose arm could be twisted to helping complete the >> iakerb specification? >> I know of one implementation and believe there are two. >> It seems kind of unfortunate to have a shipping protocol that gets >> dropped. > I did some checking, and I think that's mostly my fault. > > This document finished WGLC in 2009, with only a few comments including > some proposed changes from the author. Larry submitted a new version > (-02) which dealt with all of the comments and proposed changes. And > then I promptly dropped the ball. > > Near the end of 2011, I proposed picking up the ball, doing a review, > and sending the document along. I also asked if anyone had comments > based on implementation experience. I got exactly one reply. > > > So, this document still needs chair review and a writeup, but otherwise > should be basically ready to go. I expect the effort required of anyone > who volunteers to step in as editor would be minimal. > > You want to do another WGLC? From internet-drafts@ietf.org Mon Dec 3 17:51:07 2012 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 BA9FA21F892C; Mon, 3 Dec 2012 17:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoQ5-g4LF+-o; Mon, 3 Dec 2012 17:50:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCA521F8879; Mon, 3 Dec 2012 17:50:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204015058.32029.9437.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 17:50:58 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-05.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, 04 Dec 2012 01:51:12 -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-05.txt Pages : 36 Date : 2012-12-03 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leifj@sunet.se Wed Dec 5 00:07:34 2012 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 875C121F85C8 for ; Wed, 5 Dec 2012 00:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGmYp-PVjMlW for ; Wed, 5 Dec 2012 00:07:34 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0A321F8C99 for ; Wed, 5 Dec 2012 00:07:33 -0800 (PST) Received: from [192.36.125.240] (dhcp.pilsnet.sunet.se [192.36.125.240] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qB5863kn017493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 09:06:07 +0100 (CET) Message-ID: <50BF006B.8000306@sunet.se> Date: Wed, 05 Dec 2012 09:06:03 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete Resnick Subject: [kitten] forward the information model 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, 05 Dec 2012 08:07:34 -0000 At ATL I had a conversation with Pete about our use of RFC2119 language in the information model draft. We agreed that one way forward is for us to drop the _reference_ to RFC2119 and replace the standard 2119 boilerplate with language of our own that explain the terms MUST, SHOULD, etc. We both agree that dropping the use of all-caps words of this type is probably not a viable option. I'd like the WGs comment on the plan before proposing language text. Best R Leif From stephen.farrell@cs.tcd.ie Wed Dec 5 15:26:20 2012 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 4986521F8BC6 for ; Wed, 5 Dec 2012 15:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4hn1ZqcEZ4U for ; Wed, 5 Dec 2012 15:26:19 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BE78421F8BBE for ; Wed, 5 Dec 2012 15:26:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EA9D1BE58; Wed, 5 Dec 2012 23:25:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA2xrmW66iiZ; Wed, 5 Dec 2012 23:25:57 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.46.17.194]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6132FBE55; Wed, 5 Dec 2012 23:25:57 +0000 (GMT) Message-ID: <50BFD804.1090203@cs.tcd.ie> Date: Wed, 05 Dec 2012 23:25:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Leif Johansson References: <50BF006B.8000306@sunet.se> In-Reply-To: <50BF006B.8000306@sunet.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Pete Resnick , "krb-wg mailing list \(ietf-krb-wg@lists.anl.gov\)" Subject: Re: [kitten] forward the information model 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, 05 Dec 2012 23:26:20 -0000 Hi Leif, (Adding krb-wg list since we're not quite done merging yet.) On 12/05/2012 08:06 AM, Leif Johansson wrote: > > At ATL I had a conversation with Pete about our use of RFC2119 language > in the information model draft. > > We agreed that one way forward is for us to drop the _reference_ to RFC2119 > and replace the standard 2119 boilerplate with language of our own that > explain the terms MUST, SHOULD, etc. > > We both agree that dropping the use of all-caps words of this type is > probably > not a viable option. > > I'd like the WGs comment on the plan before proposing language text. I think you ought take silence as "yes" here since this has been a known trickiness for this draft and the plan seems like it ought make no difference to the WG (the text you add might, but the plan ought not). So I'd say firing ahead and sending your proposed wording change to the list for review ought be fine here. Cheers, S. > > Best R > Leif > > From jhutz@cmu.edu Thu Dec 6 00:03:41 2012 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 808A421F8D80 for ; Thu, 6 Dec 2012 00:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoLRatD2kn2c for ; Thu, 6 Dec 2012 00:03:41 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id DE7CB21F8D7E for ; Thu, 6 Dec 2012 00:03:40 -0800 (PST) Received: from [128.2.193.47] (destiny.pc.cs.cmu.edu [128.2.193.47]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id qB683WD9017528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2012 03:03:33 -0500 (EST) From: Jeffrey Hutzelman To: Stephen Farrell In-Reply-To: <50BFD804.1090203@cs.tcd.ie> References: <50BF006B.8000306@sunet.se> <50BFD804.1090203@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Dec 2012 03:03:32 -0500 Message-ID: <1354781012.578.117.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , "krb-wg mailing list \(ietf-krb-wg@lists.anl.gov\)" , Pete Resnick , Leif Johansson , jhutz@cmu.edu Subject: Re: [kitten] [Ietf-krb-wg] forward the information model 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, 06 Dec 2012 08:03:41 -0000 On Wed, 2012-12-05 at 23:25 +0000, Stephen Farrell wrote: > Hi Leif, > > (Adding krb-wg list since we're not quite done merging yet.) > > On 12/05/2012 08:06 AM, Leif Johansson wrote: > > > > At ATL I had a conversation with Pete about our use of RFC2119 language > > in the information model draft. > > > > We agreed that one way forward is for us to drop the _reference_ to RFC2119 > > and replace the standard 2119 boilerplate with language of our own that > > explain the terms MUST, SHOULD, etc. > > > > We both agree that dropping the use of all-caps words of this type is > > probably > > not a viable option. > > > > I'd like the WGs comment on the plan before proposing language text. > > I think you ought take silence as "yes" here since this has been > a known trickiness for this draft and the plan seems like it > ought make no difference to the WG (the text you add might, but > the plan ought not). So I'd say firing ahead and sending your > proposed wording change to the list for review ought be fine here. I think going ahead and sending proposed wording is fine. However, given the amount of time and effort we've spent on trying to get this aspect of the document right, I also think it's something the WG ought to sign off on. My preference would be to see a positive response from someone who has read the proposed new text. I don't think you can draw any meaning from lack of response to a message the WG hasn't seen. -- Jeff From hartmans@mit.edu Fri Dec 7 10:55:03 2012 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 CA88F21F8878 for ; Fri, 7 Dec 2012 10:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62xcwD3BNCXP for ; Fri, 7 Dec 2012 10:55:03 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 240F321F85DD for ; Fri, 7 Dec 2012 10:55:03 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 476972014B; Fri, 7 Dec 2012 13:53:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AB0F443F0; Fri, 7 Dec 2012 13:55:00 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Fri, 07 Dec 2012 13:55:00 -0500 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: michikos@microsoft.com Subject: [kitten] Kerberos IANA: Assigning pa-type 167 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, 07 Dec 2012 18:55:03 -0000 A while ago, I received the following registration request for the PA-types registry: Registry: http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#pre-authentication Description: We need padata type number 167 assigned for PA-PAC-OPTIONS for Windows 8 Kerberos extension specified in MS-KILE (http://msdn.microsoft.com/en-us/library/hh553950(v=prot.13).aspx). I sent mail to krb-wg about this. My reaction was the registration looked fine, but the procedures we adopted in RFc 6113 didn't actually give me enough flexibility to approve it. That needed to go through IETF review. Now, I think we're relaxing the registration procedures so if draft-ietf-kitten-kerberos-iana were approved, then I could just approve it as an expert. However, to get this taken care of, I'm wondering if the WG would permit us to simply include that registration in draft-ietf-kitten-kerberos-iana. We'll need supportive comments to do this; silence is insufficient. From alexey.melnikov@isode.com Mon Dec 10 03:24:06 2012 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 28A8921F8E75 for ; Mon, 10 Dec 2012 03:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPL2gKnhYTNq for ; Mon, 10 Dec 2012 03:24:05 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90E1F21F8E6C for ; Mon, 10 Dec 2012 03:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355138644; d=isode.com; s=selector; i=@isode.com; bh=CNGGXoqP7+5LJF7WXn/zoyk1qgw32YnffEwlmoajhQU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vU1wOF9W1XqQNwxJv++rp/H2O3V7CjVkGbVldpIkxowSaw5q3W0BcH7W/E00Io2tw/nZic 7WvE34jFjuvTQM67M9vIossDFQyFzpe7BSC86JSMDh913OQoCjqFMUp0TPvDwqK/IIASAN O3pMXguAd+0/pM5W4vKKfNrVROy0iSo=; Received: from [192.168.1.146] ((unknown) [62.3.217.253]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 10 Dec 2012 11:24:04 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <50C4B8B1.5030807@isode.com> Date: Sun, 09 Dec 2012 16:13:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Sam Hartman References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, michikos@microsoft.com Subject: Re: [kitten] Kerberos IANA: Assigning pa-type 167 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, 10 Dec 2012 11:24:06 -0000 On 07/12/2012 18:55, Sam Hartman wrote: > > > A while ago, I received the following registration request for the > PA-types registry: > Registry: > http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#pre-authentication > > Description: > We need padata type number 167 assigned for PA-PAC-OPTIONS for Windows 8 > Kerberos extension specified in MS-KILE > (http://msdn.microsoft.com/en-us/library/hh553950(v=prot.13).aspx). > > > I sent mail to krb-wg about this. My reaction was the registration > looked fine, but the procedures we adopted in RFc 6113 didn't actually > give me enough flexibility to approve it. That needed to go through > IETF review. > > Now, I think we're relaxing the registration procedures so if > draft-ietf-kitten-kerberos-iana were approved, then I could just approve > it as an expert. > However, to get this taken care of, I'm wondering if the WG would permit > us to simply include that registration in > draft-ietf-kitten-kerberos-iana. I generally support encouraging registrations and doing whatever is sensible. So +1 to registering this. On specific, I have a very minor point. I am not convinced that including a registration in draft-ietf-kitten-kerberos-iana is the best way forward. Assuming registration templates are already archived somewhere (are they?), I suggest you ask IESG to approve 1 exception to the procedure based on your recommendation as the Expert Reviewer. > We'll need supportive comments to do this; silence is insufficient. From jhutz@cmu.edu Mon Dec 10 13:09:12 2012 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 E94F621F8696 for ; Mon, 10 Dec 2012 13:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4NFZxlZMLda for ; Mon, 10 Dec 2012 13:09:12 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id D5EC921F8691 for ; Mon, 10 Dec 2012 13:09:11 -0800 (PST) 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 qBAL98mG011453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 16:09:09 -0500 (EST) Message-ID: <1355173748.2312.24.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Alexey Melnikov Date: Mon, 10 Dec 2012 16:09:08 -0500 In-Reply-To: <6225_1355138650_qBABO9C4032403_50C4B8B1.5030807@isode.com> References: <6225_1355138650_qBABO9C4032403_50C4B8B1.5030807@isode.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, michikos@microsoft.com, Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] Kerberos IANA: Assigning pa-type 167 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, 10 Dec 2012 21:09:13 -0000 On Sun, 2012-12-09 at 16:13 +0000, Alexey Melnikov wrote: > On 07/12/2012 18:55, Sam Hartman wrote: > > > > > > A while ago, I received the following registration request for the > > PA-types registry: > > Registry: > > http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#pre-authentication > > > > Description: > > We need padata type number 167 assigned for PA-PAC-OPTIONS for Windows 8 > > Kerberos extension specified in MS-KILE > > (http://msdn.microsoft.com/en-us/library/hh553950(v=prot.13).aspx). > > > > > > I sent mail to krb-wg about this. My reaction was the registration > > looked fine, but the procedures we adopted in RFc 6113 didn't actually > > give me enough flexibility to approve it. That needed to go through > > IETF review. > > > > Now, I think we're relaxing the registration procedures so if > > draft-ietf-kitten-kerberos-iana were approved, then I could just approve > > it as an expert. > > However, to get this taken care of, I'm wondering if the WG would permit > > us to simply include that registration in > > draft-ietf-kitten-kerberos-iana. > I generally support encouraging registrations and doing whatever is > sensible. So +1 to registering this. > > On specific, I have a very minor point. I am not convinced that > including a registration in draft-ietf-kitten-kerberos-iana is the best > way forward. > Assuming registration templates are already archived somewhere (are > they?), I'm not sure what you mean. The current registration procedures are documented in RFC6113, and the new procedures are in the draft. > I suggest you ask IESG to approve 1 exception to the procedure > based on your recommendation as the Expert Reviewer. > > We'll need supportive comments to do this; silence is insufficient. I'm not sure what to make of this. The registration procedures for the registry in question do not include IESG Approval as an option, so for the IESG to approve an exception, the conditions discussed in RFC5226 section 5.3 would need to apply. And, I'm not convinced they do: we don't yet have a "strong IETF consensus" to make the assignment, and getting one does not seem to be likely to be faster than waiting for the document to progress. And, since the document in question updates the registration procedures in ways that would permit the assignment, one can hardly claim that the burden of doing so is too heavy. I'm also not sure what the point is of including the registration in the document explicitly. That would have effect only once the document is approved, at which point the expert could simply approve the registration. That said, I have no objection to adding the registration to the document. If people feel that using the override procedure is the way to go, I'll be happy to lend my voice to an IETF consensus in support of making the allocation. -- Jeff From hartmans@mit.edu Mon Dec 10 14:40:38 2012 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 C679821F8203 for ; Mon, 10 Dec 2012 14:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkwpl+5iFIyl for ; Mon, 10 Dec 2012 14:40:37 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D675D21F8233 for ; Mon, 10 Dec 2012 14:40:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2FED520146; Mon, 10 Dec 2012 17:38:20 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 772D143F0; Mon, 10 Dec 2012 17:40:18 -0500 (EST) From: Sam Hartman To: Jeffrey Hutzelman References: <6225_1355138650_qBABO9C4032403_50C4B8B1.5030807@isode.com> <1355173748.2312.24.camel@minbar.fac.cs.cmu.edu> Date: Mon, 10 Dec 2012 17:40:18 -0500 In-Reply-To: <1355173748.2312.24.camel@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 10 Dec 2012 16:09:08 -0500") 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, michikos@microsoft.com, Sam Hartman Subject: Re: [kitten] Kerberos IANA: Assigning pa-type 167 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, 10 Dec 2012 22:40:38 -0000 I agree with Jeff's rationale for why I don't think an IESG override is appropriate here. Including the registration in this document avoids a round trip once this is approved, but if people object I can obviously deal once approved. My preference is 1) register here 2) approve after this doc is approved From tlyu@mit.edu Tue Dec 11 20:30:30 2012 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 7224121E80BA for ; Tue, 11 Dec 2012 20:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr7yIGD5QL-u for ; Tue, 11 Dec 2012 20:30:27 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 52EFD21F86FD for ; Tue, 11 Dec 2012 20:30:26 -0800 (PST) X-AuditID: 1209190c-b7f886d000000936-b5-50c8086180c6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 09.A8.02358.16808C05; Tue, 11 Dec 2012 23:30:25 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id qBC4UOQv000794; Tue, 11 Dec 2012 23:30:25 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qBC4UMuA023385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Dec 2012 23:30:24 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id qBC4UMlW009780; Tue, 11 Dec 2012 23:30:22 -0500 (EST) To: Sam Hartman References: From: Tom Yu Date: Tue, 11 Dec 2012 23:30:22 -0500 In-Reply-To: (Sam Hartman's message of "Fri, 07 Dec 2012 13:55:00 -0500") Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixCmqrZvIcSLA4M5NeYuvbQ/YLI5uXsVi 8a+bz4HZY8mSn0werTv+snusnHqaPYA5issmJTUnsyy1SN8ugSvj1t5prAVbuCrOH7nL0sB4 nqOLkZNDQsBE4t+0FUwQtpjEhXvr2UBsIYF9jBIzmtS6GLmA7A2MEr/ebGWGcK4wSWy5tY8R wulilJja95MFpEVEQF1i9aVJ7CA2s4C2xNeNx5lBbGEBK4mFLX+BVnAANahKzH5lCWKyCUhL HF1cBlLBAhS9sOch2BROgWSJeas/gVXzClhITJ8vCRLmEeCUOD3rM1gJr4CgxMmZT1ggFmlJ 3Pj3kmkCo+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBIet JM8OxjcHlQ4xCnAwKvHwXnh5PECINbGsuDL3EKMkB5OSKG8q24kAIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK8K7cClfOmJFZWpRblw6SkOViUxHkvp9z0FxJITyxJzU5NLUgtgsnKcHAoSfBq sAMNFSxKTU+tSMvMKUFIM3FwggznARruAVLDW1yQmFucmQ6RP8WoKCXOWwaSEABJZJTmwfXC 0sorRnGgV4Qh2nmAKQmu+xXQYCagwXGXQK4uLklESEk1MMZfWfh0ldrumfYZP04zSC+9Y1sl 0KQmtn+5smdb6cXAryc1za8UpvP/UPupqZXG8O7UstVzpP/uNDm47kiHRJ3b14pqrVW5vT3K zIkLWGTSp4Use3xySvinxbNYnxQ/OfJ46voZD54Lq4iuKcr6vOOQ7KFnj5SOve4oPxXQsSY5 eooB84n7a7iUWIozEg21mIuKEwHnBVyDBgMAAA== Cc: kitten@ietf.org, michikos@microsoft.com Subject: Re: [kitten] Kerberos IANA: Assigning pa-type 167 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, 12 Dec 2012 04:30:30 -0000 Sam Hartman writes: > > > A while ago, I received the following registration request for the > PA-types registry: > Registry: > http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#pre-authentication > > Description: > We need padata type number 167 assigned for PA-PAC-OPTIONS for Windows 8 > Kerberos extension specified in MS-KILE > (http://msdn.microsoft.com/en-us/library/hh553950(v=prot.13).aspx). > > > I sent mail to krb-wg about this. My reaction was the registration > looked fine, but the procedures we adopted in RFc 6113 didn't actually > give me enough flexibility to approve it. That needed to go through > IETF review. > > Now, I think we're relaxing the registration procedures so if > draft-ietf-kitten-kerberos-iana were approved, then I could just approve > it as an expert. > However, to get this taken care of, I'm wondering if the WG would permit > us to simply include that registration in > draft-ietf-kitten-kerberos-iana. > > We'll need supportive comments to do this; silence is insufficient. I think it's fine to put the new registration in our IANA registries document, assuming there is WG consensus that it should be registered. I personally have no problem with the proposed assignment. From alexey.melnikov@isode.com Wed Dec 12 11:25:02 2012 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 2371C21E804E for ; Wed, 12 Dec 2012 11:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFQiAnaF7MJq for ; Wed, 12 Dec 2012 11:25:01 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86A21E80C0 for ; Wed, 12 Dec 2012 11:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355340293; d=isode.com; s=selector; i=@isode.com; bh=hhnkVEsBV6PoEk2G1osTKOjBcYEI/KxVgEigL5e69e8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=CNs/CJJ8TIMLX9/yAqt9PTPR1RTbTxZNU47b/c/DPLfx49kHd2qcvM6hfReois8cCAwADV 8KwE6eYTY/vHeFsZSHiXX96OQwXF6f9Ny3kUepZGRv3dKYljzD6upQXaFQ0DX88Io+XQqF o1IzM2tU64TOysJAeVxQrserD9jtTuc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Dec 2012 19:24:53 +0000 Message-ID: <50C8DA13.8060703@isode.com> Date: Wed, 12 Dec 2012 19:25:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Jeffrey Hutzelman References: <6225_1355138650_qBABO9C4032403_50C4B8B1.5030807@isode.com> <1355173748.2312.24.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1355173748.2312.24.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, michikos@microsoft.com, Sam Hartman Subject: Re: [kitten] Kerberos IANA: Assigning pa-type 167 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, 12 Dec 2012 19:25:02 -0000 On 10/12/2012 21:09, Jeffrey Hutzelman wrote: > On Sun, 2012-12-09 at 16:13 +0000, Alexey Melnikov wrote: >> On 07/12/2012 18:55, Sam Hartman wrote: >>> >>> >>> A while ago, I received the following registration request for the >>> PA-types registry: >>> Registry: >>> http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#pre-authentication >>> >>> Description: >>> We need padata type number 167 assigned for PA-PAC-OPTIONS for Windows 8 >>> Kerberos extension specified in MS-KILE >>> (http://msdn.microsoft.com/en-us/library/hh553950(v=prot.13).aspx). >>> >>> >>> I sent mail to krb-wg about this. My reaction was the registration >>> looked fine, but the procedures we adopted in RFc 6113 didn't actually >>> give me enough flexibility to approve it. That needed to go through >>> IETF review. >>> >>> Now, I think we're relaxing the registration procedures so if >>> draft-ietf-kitten-kerberos-iana were approved, then I could just approve >>> it as an expert. >>> However, to get this taken care of, I'm wondering if the WG would permit >>> us to simply include that registration in >>> draft-ietf-kitten-kerberos-iana. >> I generally support encouraging registrations and doing whatever is >> sensible. So +1 to registering this. >> >> On specific, I have a very minor point. I am not convinced that >> including a registration in draft-ietf-kitten-kerberos-iana is the best >> way forward. >> >> Assuming registration templates are already archived somewhere (are >> they?), > I'm not sure what you mean. The current registration procedures are > documented in RFC6113, and the new procedures are in the draft. Is IANA archiving approved registration templates on iana.org? >> I suggest you ask IESG to approve 1 exception to the procedure >> based on your recommendation as the Expert Reviewer. >>> We'll need supportive comments to do this; silence is insufficient. > I'm not sure what to make of this. The registration procedures for the > registry in question do not include IESG Approval as an option, so for > the IESG to approve an exception, the conditions discussed in RFC5226 > section 5.3 would need to apply. And, I'm not convinced they do: we > don't yet have a "strong IETF consensus" to make the assignment, and > getting one does not seem to be likely to be faster than waiting for the > document to progress. And, since the document in question updates the > registration procedures in ways that would permit the assignment, one > can hardly claim that the burden of doing so is too heavy. Ok, fair enough. > I'm also not sure what the point is of including the registration in the > document explicitly. That would have effect only once the document is > approved, at which point the expert could simply approve the > registration. That was sort of my point. > That said, I have no objection to adding the registration to the > document. Same here. > If people feel that using the override procedure is the way > to go, I'll be happy to lend my voice to an IETF consensus in support of > making the allocation. From internet-drafts@ietf.org Mon Dec 17 09:43:31 2012 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 9C6BB21F8645; Mon, 17 Dec 2012 09:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyEtu5gNfSDy; Mon, 17 Dec 2012 09:43:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF55721F87DD; Mon, 17 Dec 2012 09:43:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217174329.30290.19312.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 09:43:29 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-09.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, 17 Dec 2012 17:43:31 -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 : A set of SASL and GSS-API Mechanisms for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-09.txt Pages : 31 Date : 2012-12-17 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Mon Dec 17 09:51:53 2012 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 82CCF21F8BD0 for ; Mon, 17 Dec 2012 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VMblaUCZXZU for ; Mon, 17 Dec 2012 09:51:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8542821F8BCC for ; Mon, 17 Dec 2012 09:51:51 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MZzaz-1TOrHO1SvP-00Lmym for ; Mon, 17 Dec 2012 18:51:49 +0100 Received: (qmail invoked by alias); 17 Dec 2012 17:51:49 -0000 Received: from a88-115-211-228.elisa-laajakaista.fi (EHLO [192.168.100.111]) [88.115.211.228] by mail.gmx.net (mp016) with SMTP; 17 Dec 2012 18:51:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ZdJIT2OpZWOV4Wmu9RCeKhdMQvqKy+a75ukAEbP E7RKi9AQVKH9Ih From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Dec 2012 19:51:47 +0200 Message-Id: <23F98B0F-9BC1-4717-9CB0-889676C898BE@gmx.net> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [kitten] OAuth SASL Draft Update 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, 17 Dec 2012 17:51:53 -0000 Hi all,=20 I thought I should submit the current draft snapshot. Here is the = current version:=20 http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09 Version -09 of the draft contains:=20 o Incorporated review comments from Alexey and myself.=09 o Clarified the three OAuth SASL mechanisms.=09 o Updated references.=09 o Extended acknowledgements. A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-09 I am not sure it completely addresses the remarks from Alexey regarding = 'Canonicalization', see =20 http://www.ietf.org/mail-archive/web/kitten/current/msg03670.html I have replaced the sub-section about Canonicalization with a separate = internationalization section.=20 Ciao Hannes From jhutz@cmu.edu Mon Dec 17 13:55:54 2012 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 D241421F8973 for ; Mon, 17 Dec 2012 13:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyaHsB1n6KIb for ; Mon, 17 Dec 2012 13:55:51 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id A63DA21F89BB for ; Mon, 17 Dec 2012 13:55:51 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id qBHLtm7V023410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 16:55:48 -0500 (EST) Message-ID: <1355781348.2312.94.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Hannes Tschofenig Date: Mon, 17 Dec 2012 16:55:48 -0500 In-Reply-To: <26027_1355766716_qBHHptmU008972_23F98B0F-9BC1-4717-9CB0-889676C898BE@gmx.net> References: <26027_1355766716_qBHHptmU008972_23F98B0F-9BC1-4717-9CB0-889676C898BE@gmx.net> 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.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] OAuth SASL Draft Update 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, 17 Dec 2012 21:55:54 -0000 On Mon, 2012-12-17 at 19:51 +0200, Hannes Tschofenig wrote: > Hi all, > > I thought I should submit the current draft snapshot. Here is the current version: > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09 > OAuth mechanims security contexts always have the mutual_state flag > (GSS_C_MUTUAL_FLAG) set to TRUE. OAuth supports credential > delegation, therefore security contexts may have the deleg_state flag > (GSS_C_DELEG_FLAG) set to either TRUE or FALSE. > > The mutual authentication property of this mechanism relies on > successfully comparing the TLS server identity with the negotiated > target name. Since the TLS channel is managed by the application > outside of the GSS-API mechanism, the mechanism itself is unable to > confirm the name while the application is able to perform this > comparison for the mechanism. For this reason, applications MUST > match the TLS server identity with the target name using the > appropriate application profile, as discussed in [RFC6125]. For > example, when SASL OAuth is run over IMAP then the IMAP profile of > RFC 6125 is used. So in other words, this mechanism does _not_ provide mutual auth. The mutual_state flag indicates that the _mechanism_ has authenticated the server. Here, you are saying that the mechanism cannot do so, and so it is up to the application to do so. That's fine, but then you cannot set mutual_auth, because that amounts to lying to the GSS-API application. This is important, because GSS applications depend on this flag to know whether they can depend on GSS-API channel bindings to bind the enclosing channel to the server's identity. That is, they use it to know whether it is OK that they are _not_ checking the TLS server cert (or whatever other channel is in use). You're basically saying that when using this mechanism, the application has to ignore mutual_state and assume the server is not authenticated (and so, neither is the enclosing channel). But you don't get to do that; it violates the API abstraction. Separately, I find the security considerations section in this document to be wholly inadequate. It basically says "there might be issues", but with a couple of specific exceptions does not explore what they are, whether or how the mechanism addresses them, or what steps should be taken to mitigate them. Please see RFC3552 for more information on what should be in the Security Considerations section of an RFC. Please pay particular attention to the discussion in section 5, and especially to the comments on what must be covered in the specific case of authentication mechanisms. IMHO the current document falls short in this regard. -- Jeff