From iesg-secretary@ietf.org Mon Mar 5 13:53:59 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 8D92C21F87C5; Mon, 5 Mar 2012 13:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 XWvD2y8G-0xv; Mon, 5 Mar 2012 13:53:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2021F8827; Mon, 5 Mar 2012 13:53:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305215358.21831.93353.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 13:53:58 -0800 Cc: kitten mailing list , kitten chair , RFC Editor Subject: [kitten] Protocol Action: 'A SASL & GSS-API Mechanism for OpenID' to Proposed Standard (draft-ietf-kitten-sasl-openid-08.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, 05 Mar 2012 21:53:59 -0000 The IESG has approved the following document: - 'A SASL & GSS-API Mechanism for OpenID' (draft-ietf-kitten-sasl-openid-08.txt) as a Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ Technical Summary OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL, RFC 4422) and the Generic Security Service Application Program Interface (GSS-API, RFC 2743) are application frameworks to generalize authentication for connection based protocols. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. The OpenID foundation have assured the RFC editor that the [OpenID] and [SREG] references are stable. Working Group Summary Nothing worth noting, this document was relatively non controversial once the rough consensus was reached in the WG that using a browser for some part of SASL authentication is acceptable for some deployments. Document Quality At least one implementation is in progress and one is planned. Personnel Alexey Melnikov is the document shepherd. Stephen Farrell is the responsible AD. RFC Editor Note There are a bunch (7) of little changes. First, in the References section: 1. Please add the following URL to the [OpenID] reference: http://specs.openid.net/auth/2.0 OLD [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007. NEW [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007. http://specs.openid.net/auth/2.0 2. Please add the following URL to the [SREG1.0] reference: http://openid.net/sreg/1.0 OLD [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension version 1.0", June 2006. NEW [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension version 1.0", June 2006. http://openid.net/sreg/1.0 3. Please move the [XRI2.0] reference from the normative (9.1) to informative (9.2) references subsection. 4. In the security considerations text, section 6, please replace "[1]" with "[OpenID]", apparently that's a bug in xml2rfc somehow OLD specification and to other literature [1]. Similarly, for general NEW specification and to other literature [OpenID]. Similarly, for general 5. In section 2.2: OLD defined in the crudest sense. That is, when one is prompted to approve or disapprove an authentication, anything that one might find on a browser is allowed, including JavaScript, fancy style-sheets, etc. Because of this lack of structure, implementations will need to invoke a fairly rich browser in order to ensure that the authentication can be completed. NEW defined in the crudest sense. That is, when one is prompted to approve or disapprove an authentication, anything that one might find on a browser is allowed, including JavaScript, complex style-sheets, etc. Because of this lack of structure, implementations will need to invoke a rich browser in order to ensure that the authentication can be completed. 6. On page 5, section 2, item 6: OLD 6. The SASL client now sends an response consisting of "=", to indicate that authentication continues via the normal OpenID flow. NEW 6. The SASL client now sends an response consisting of "=" to the server, to indicate that authentication continues via the normal OpenID flow. 7. On page 6, section 2, item 8: OLD Next the client optionally authenticates to the OP and then approves or disapproves authentication to the Relying Party. NEW Next the end user optionally authenticates to the OP and then, depending on the OP, may approve or disapprove authentication to the Relying Party. From stephen.farrell@cs.tcd.ie Thu Mar 8 06:16:46 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 EA13B21F86B9 for ; Thu, 8 Mar 2012 06:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv9G4g50Ru1o for ; Thu, 8 Mar 2012 06:16:45 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EBACE21F858E for ; Thu, 8 Mar 2012 06:16:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 354321535F9 for ; Thu, 8 Mar 2012 14:16:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1331216203; bh=fkDWaCOVL0Qtg4iju5oS8Ppt bD83TMt3irQBjQ76I3E=; b=rvwx2G8OkJhn4JqR0dSqYU69jCk7IzoCpzSW0BHz JTmAiFnGk3ZKlRIfaWnOvyt7NYHLLdhgDqBI7Uurx1DtstAZzlQqrdEudJiq55yN EIeYHCAW7LSQD9d9DbWots9tfooE+TQaLdrXSTTC41xDdvVW0p1NpoKjAAwRJiNa PHZjjp02r74CH75hhQzGcPe1wmOyhc534f3Uvi3JZs0wcs2885a2p9jhllCVOT7Y LbZQpo6Fu3iNflg1Xl+PIwmz7B/fn8HBVQWGbz/yXRln6RjpL60ldPVg/XDJycVP tXDX6JsvrGscLXsTypeeHpJ8UtzZ14mktd5pna8oi6D7HA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id htlaHJ5JQSyI for ; Thu, 8 Mar 2012 14:16:43 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E185C1535F8 for ; Thu, 8 Mar 2012 14:16:43 +0000 (GMT) Message-ID: <4F58BF4B.7050009@cs.tcd.ie> Date: Thu, 08 Mar 2012 14:16:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 14:16:46 -0000 Hi, Shawn has requested publication of this draft. This is my AD review of that prior to starting IETF last call. I've 3 questions that I think need answering. I think a revised I-D is likely needed before IETF LC to handle those. (If not then you'll argue about that:-) I've also some other comments that can be handled before or during IETF LC along with whatever other comments crop up. Things that need handling: 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't care much really, but others do;-) 2. The IANA considerations section doesn't seem clear enough for IANA to action. What's the update rule, what's the name of the registry, ... 3. Nico's address bounces. Please fix unless there's some good reason - is there? Other comments/questions, (not blocking):- - Section 6 is a bit unclear. In particular the "otherwise" in the 2nd para on p8 - does that mean "if there's no colon" or "if there's no space and no colon"? The clarity of this section could be improved, maybe by laying it out as a bulleted list. - I don't really get the 2nd last paragraph of section 6, what's that saying? - The last para of section 6 is also a bit unclear, I think you mean where the administrator controls all aspects (e.g. both the KDC and the relying applications) but I'm not 100% sure. - 7.1, last sentence - would it be better to spell this out some more? E.g. maybe say that ordering of SET OF OCTET STRING MUST be preserved. - The danger in the 2nd last para of 7.6 is not crystal clear. Might be worth spelling that out some more. - An example or two would be nice, or a pointer to such if its easily referenced. Thanks, Stephen. From stephen.farrell@cs.tcd.ie Thu Mar 8 06:20:39 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 2231521F866C for ; Thu, 8 Mar 2012 06:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCOhL+B5GyGw for ; Thu, 8 Mar 2012 06:20:38 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D609521F8648 for ; Thu, 8 Mar 2012 06:20:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F3C031535FF for ; Thu, 8 Mar 2012 14:20:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331216435; bh=ghSf8WKaO9owTC +kwTY1Iwpl6v9chQBMfjq7Wqrb5cQ=; b=VwjBmgcNC/M15n9AkCoL48s08vYGR8 52vC1LGhSMcSs8tSJYL5yOCS+s03OgvkLfKdAYM76IfaqGhaRQAkURDyR0NgkJ/d j2tZ0onPVC5c9EV2v4SXvnIjhFCPmBJuQTJx73SS+6rQVZkrpMBugHINFDurwRtr PCxacT7k1Zv+nlno+qAQoesZUWgjCGJ7bAr3XMQ8BQPZYJ7H70P8ba0jRnGgL51z q9f8yHsjlVSkIf/FTF6N9GTetMWcM5F4BWjbATlGZmHq4N4RLpmkwfEDaKHwgrT5 wvvb5Elhi/KfkFesrwAoLheVzvfFd4ljesxVlSTXgmiw7duE9TjB8GBg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id P16XPclDypwZ; Thu, 8 Mar 2012 14:20:35 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5B3191535F8; Thu, 8 Mar 2012 14:20:35 +0000 (GMT) Message-ID: <4F58C033.80407@cs.tcd.ie> Date: Thu, 08 Mar 2012 14:20:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <4F58BF4B.7050009@cs.tcd.ie> In-Reply-To: <4F58BF4B.7050009@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 14:20:39 -0000 Sorry one more thing that can be handled along with IETF LC - I-D nits complains [1] about some of the references being unused. Seems worth fixing along with other stuff as well. S. [1] http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-12.txt On 03/08/2012 02:16 PM, Stephen Farrell wrote: > > Hi, > > Shawn has requested publication of this draft. This is my AD > review of that prior to starting IETF last call. > > I've 3 questions that I think need answering. I think a revised > I-D is likely needed before IETF LC to handle those. (If not then > you'll argue about that:-) I've also some other comments that > can be handled before or during IETF LC along with whatever > other comments crop up. > > Things that need handling: > > 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I > don't care much really, but others do;-) > > 2. The IANA considerations section doesn't seem clear enough > for IANA to action. What's the update rule, what's the name > of the registry, ... > > 3. Nico's address bounces. Please fix unless there's some > good reason - is there? > > Other comments/questions, (not blocking):- > > - Section 6 is a bit unclear. In particular the "otherwise" in the > 2nd para on p8 - does that mean "if there's no colon" or "if there's > no space and no colon"? The clarity of this section could be > improved, maybe by laying it out as a bulleted list. > > - I don't really get the 2nd last paragraph of section 6, what's > that saying? > > - The last para of section 6 is also a bit unclear, I think you > mean where the administrator controls all aspects (e.g. both the > KDC and the relying applications) but I'm not 100% sure. > > - 7.1, last sentence - would it be better to spell this out some > more? E.g. maybe say that ordering of SET OF OCTET STRING MUST > be preserved. > > - The danger in the 2nd last para of 7.6 is not crystal clear. > Might be worth spelling that out some more. > > - An example or two would be nice, or a pointer to such if its > easily referenced. > > Thanks, > Stephen. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From leifj@mnt.se Thu Mar 8 06:27:24 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 15BE321F8646 for ; Thu, 8 Mar 2012 06:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6deErxe+PMa for ; Thu, 8 Mar 2012 06:27:23 -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 D7F1521F8678 for ; Thu, 8 Mar 2012 06:27:22 -0800 (PST) Received: from [109.105.104.200] (dhcp66.se-tug.nordu.net [109.105.104.200] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q28ERGE2012330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 15:27:19 +0100 (CET) Message-ID: <4F58C1C4.6000105@mnt.se> Date: Thu, 08 Mar 2012 15:27:16 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <4F58BF4B.7050009@cs.tcd.ie> In-Reply-To: <4F58BF4B.7050009@cs.tcd.ie> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nicolas Williams Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 14:27:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/2012 03:16 PM, Stephen Farrell wrote: > > Hi, > > Shawn has requested publication of this draft. This is my AD review > of that prior to starting IETF last call. > > I've 3 questions that I think need answering. I think a revised I-D > is likely needed before IETF LC to handle those. (If not then > you'll argue about that:-) I've also some other comments that can > be handled before or during IETF LC along with whatever other > comments crop up. > > Things that need handling: > > 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't > care much really, but others do;-) > Not sure I agree. The API proposed in this draft are completely orthogonal to base GSS-API. Why is this an update? > 2. The IANA considerations section doesn't seem clear enough for > IANA to action. What's the update rule, what's the name of the > registry, ... I disagree. The section sais that we may want a registry sometime in the future not that we are creating one now. > > 3. Nico's address bounces. Please fix unless there's some good > reason - is there? Probably not. Nico - which address do you want me to use? > > Other comments/questions, (not blocking):- Haven't thought about those yet.... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9YwcAACgkQ8Jx8FtbMZneo9ACaAueVLwH8liRuiv95cg+NzYBH yUgAn0qZp3DsH0KvmPg4lRxzU12dl0YX =8xDs -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Thu Mar 8 06:31: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 E194021F86B5 for ; Thu, 8 Mar 2012 06:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcUmi7vhsX+c for ; Thu, 8 Mar 2012 06:31:38 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EB65C21F8656 for ; Thu, 8 Mar 2012 06:31:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 605961535F8; Thu, 8 Mar 2012 14:31:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331217096; bh=fY+43xLKKUYD2e tXt1PHZsgeHABjMy5DXhbC1oEv34o=; b=MnnzFI9pq0BzZ2kc7fYA6CN/ofNv2q pOeG5aKE0scL+O8RZQ1NTxNDajCKg6+dDnC7gjyXNQt/nb9J7uhPTNl+rrrJRPeH lLTcemv9bgpZCO/B+aYuCcNw5JFCMB8XzsgyfNXfROGVxyi23+a00+BEIScBfqdw xunmezW8qcwa+ViSTKgjeZa2zr4Q9wCYOyW90CJS9vPkXC8OMOO7KLsxsVGO+REY L9sq9IIcyyOJkxQ+CX5V3wK7Wif5R6xFPTgqDWy614sofrG36Z+tJeBkdIUqJlVt kS8fp+et11VCkXE22rvirRbmXyCbbLwWmWYHvBTsrNFDTxIoibMoODAQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id BL4zhOZ5cgxU; Thu, 8 Mar 2012 14:31:36 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 503231535F9; Thu, 8 Mar 2012 14:31:36 +0000 (GMT) Message-ID: <4F58C2C7.4090904@cs.tcd.ie> Date: Thu, 08 Mar 2012 14:31:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Leif Johansson References: <4F58BF4B.7050009@cs.tcd.ie> <4F58C1C4.6000105@mnt.se> In-Reply-To: <4F58C1C4.6000105@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Nicolas Williams Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 14:31:39 -0000 On 03/08/2012 02:27 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/08/2012 03:16 PM, Stephen Farrell wrote: >> >> Hi, >> >> Shawn has requested publication of this draft. This is my AD review >> of that prior to starting IETF last call. >> >> I've 3 questions that I think need answering. I think a revised I-D >> is likely needed before IETF LC to handle those. (If not then >> you'll argue about that:-) I've also some other comments that can >> be handled before or during IETF LC along with whatever other >> comments crop up. >> >> Things that need handling: >> >> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't >> care much really, but others do;-) >> > > Not sure I agree. The API proposed in this draft are completely > orthogonal to base GSS-API. Why is this an update? Personally, I don't care much. But it does extend the GSS-API. I'll go with what the WG want here but other ADs might want this. (Was that specifically considered by the WG?) > >> 2. The IANA considerations section doesn't seem clear enough for >> IANA to action. What's the update rule, what's the name of the >> registry, ... > > I disagree. The section sais that we may want a registry sometime > in the future not that we are creating one now. Ah, sorry, my fault. I read "This document creates a namespace of GSS-API name attributes." as creating a registry. Maybe say: "This document creates a namespace of GSS-API name attributes but no new IANA registry" so even dummies like me don't get confused:-) Consider this one non-blocking now. >> 3. Nico's address bounces. Please fix unless there's some good >> reason - is there? > > Probably not. Nico - which address do you want me to use? This I think should be done so the authors can see any IETF LC discussion. Thanks, S > >> >> Other comments/questions, (not blocking):- > > Haven't thought about those yet.... > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9YwcAACgkQ8Jx8FtbMZneo9ACaAueVLwH8liRuiv95cg+NzYBH > yUgAn0qZp3DsH0KvmPg4lRxzU12dl0YX > =8xDs > -----END PGP SIGNATURE----- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nico@cryptonector.com Thu Mar 8 08:05: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 B5F3321F85E7 for ; Thu, 8 Mar 2012 08:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+0m8InHMP2Y for ; Thu, 8 Mar 2012 08:05:07 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C473B21F870A for ; Thu, 8 Mar 2012 08:04:55 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 41DFA2AC083 for ; Thu, 8 Mar 2012 08:04:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=JIH+0smS5oE+MlBtXXZ33 NFOGFYl2fCYacsOlghhIwy4rpIPCERjc8OwtOEzXPvm4Iw000PZ7RquLh9svheBa fn/asw21L+Yl5mR4RlkGXP2UZPwIn4G6msnadYi1HlcS6YAUnVhULIyEo3gskb/Q eklfKm2YtiyZpJXgsPTuas= 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=zXoi6LUzP/3QYsNtzP2n GsAPqHo=; b=qVxVTD5d7f2N8hHxUjz8HNMbmmGwr6TGkSKu05oQriYR80hGsZkr vxIHyP+rWHwR04YG8u1GkkT9mYqjBGKJtMRXZyGtiSPtGcE7NK/I/khmw4PePqED uTgY32vjB5EMmRhE6pWicv07hSo3Iufxjp83V9PHNrj8QOugfKsiuJc= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 2A2ED2AC07A for ; Thu, 8 Mar 2012 08:04:55 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1816644pbb.31 for ; Thu, 08 Mar 2012 08:04:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.192.100 with SMTP id hf4mr9511755pbc.118.1331222694689; Thu, 08 Mar 2012 08:04:54 -0800 (PST) Received: by 10.68.28.6 with HTTP; Thu, 8 Mar 2012 08:04:54 -0800 (PST) In-Reply-To: <4F58C1C4.6000105@mnt.se> References: <4F58BF4B.7050009@cs.tcd.ie> <4F58C1C4.6000105@mnt.se> Date: Thu, 8 Mar 2012 10:04:54 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 16:05:07 -0000 On Thu, Mar 8, 2012 at 8:27 AM, Leif Johansson wrote: >> 3. Nico's address bounces. Please fix unless there's some good >> reason - is there? > > Probably not. Nico - which address do you want me to use? nico@cryptonector.com Also, please remove the mailing address. Nico -- From nico@cryptonector.com Thu Mar 8 08:08:50 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 D298021F8740 for ; Thu, 8 Mar 2012 08:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.277, 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 rAOCn61p-PuB for ; Thu, 8 Mar 2012 08:08:50 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9621F8768 for ; Thu, 8 Mar 2012 08:08:50 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 24420428076 for ; Thu, 8 Mar 2012 08:08:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=mRUD3z/f7NwPt0so6XgBo y91qLoacx9kSutUbc2j0diYY1AHRcCobfgr1f+birwRQxGE8l4DFzGYnTDTBK4tG nC9FOBJn5x7B8qaKQeb72DthWalqUv3n83YTRQtZvQjDyA9GndqzGZTSOOSUzNdB D20zieYL7Zymzkjylui3Xw= 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=fnAGZoIY0HBHAJZUl6h/ H9u7JSY=; b=Q1qTbWJGpUrdP+r5IiRo/k3rBTwsVElwfFGYPo6uoaoHKprLx+XS PmoRyyvh6uV0Mlot3zvQffbFk1kJWBwH73x2SNmfU4tsJ5JxomRss5yWLD1C0KTL ZOxG14iH+E+mBvUSLlo4MtZ+qfmnXOEOqnZfHVl9HOkZFkYfR2apVuU= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id F3F8442806E for ; Thu, 8 Mar 2012 08:08:49 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1820623pbb.31 for ; Thu, 08 Mar 2012 08:08:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.129.129 with SMTP id nw1mr10564138pbb.13.1331222929301; Thu, 08 Mar 2012 08:08:49 -0800 (PST) Received: by 10.68.28.6 with HTTP; Thu, 8 Mar 2012 08:08:49 -0800 (PST) In-Reply-To: <4F58C2C7.4090904@cs.tcd.ie> References: <4F58BF4B.7050009@cs.tcd.ie> <4F58C1C4.6000105@mnt.se> <4F58C2C7.4090904@cs.tcd.ie> Date: Thu, 8 Mar 2012 10:08:49 -0600 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 16:08:51 -0000 On Thu, Mar 8, 2012 at 8:31 AM, Stephen Farrell wrote: > On 03/08/2012 02:27 PM, Leif Johansson wrote: >> On 03/08/2012 03:16 PM, Stephen Farrell wrote: >>> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't >>> care much really, but others do;-) >> >> Not sure I agree. The API proposed in this draft are completely >> orthogonal to base GSS-API. Why is this an update? > > Personally, I don't care much. But it does extend the > GSS-API. I'll go with what the WG want here but other > ADs might want this. (Was that specifically considered by > the WG?) I've no problem with saying that all extensions to the GSS-API must update RFC2743 and, if they specify C bindings, also RFC244. I think an argument can be made this should be true w.r.t. all Standards-Track API-specifying RFCs. >>> 2. The IANA considerations section doesn't seem clear enough for >>> IANA to action. What's the update rule, what's the name of the >>> registry, ... >> >> I disagree. The section sais that we may want a registry sometime >> in the future not that we are creating one now. > > Ah, sorry, my fault. I read "This document creates a namespace > of GSS-API name attributes." as creating a registry. > > Maybe say: "This document creates a namespace of GSS-API name > attributes but no new IANA registry" so even dummies like me > don't get confused:-) Consider this one non-blocking now. Sure. >>> 3. Nico's address bounces. Please fix unless there's some good >>> reason - is there? >> >> >> Probably not. Nico - which address do you want me to use? > > > This I think should be done so the authors can see any IETF > LC discussion. Yes please (see separate e-mail). And thanks for noticing (and thanks to Leif for fixing it). Nico -- From hartmans@mit.edu Thu Mar 8 09:56: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 B87C021F86B2 for ; Thu, 8 Mar 2012 09:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM44bnQApDTh for ; Thu, 8 Mar 2012 09:56:34 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3021F86B1 for ; Thu, 8 Mar 2012 09:56:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8307E2023F; Thu, 8 Mar 2012 12:56:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E52A744E8; Thu, 8 Mar 2012 12:56:21 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4F58BF4B.7050009@cs.tcd.ie> <4F58C1C4.6000105@mnt.se> <4F58C2C7.4090904@cs.tcd.ie> Date: Thu, 08 Mar 2012 12:56:21 -0500 In-Reply-To: (Nico Williams's message of "Thu, 8 Mar 2012 10:08:49 -0600") 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, Nicolas Williams Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 08 Mar 2012 17:56:34 -0000 2) If you have no IANA actions, please state "This specification has no actions for IANA." You're much less likely to get questions if you use those exact words. IANA has complained in the past if an IANA Considerations section included anything besides current actions for IANA. My recommendation here would be to start the IANA considerations section with "This Specification has no actions for IANA," in its own paragraph. Then include whatever text the WG believes is necessary. However we should be prepared to move that text elsewhere if requested by IANA. From mrex@sap.com Thu Mar 8 18:56:44 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 1E77421F8532 for ; Thu, 8 Mar 2012 18:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[AWL=0.202, 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 u20p93WyfGGa for ; Thu, 8 Mar 2012 18:56:43 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 748C521F8533 for ; Thu, 8 Mar 2012 18:56:28 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q292uLb6016026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 03:56:21 +0100 (MET) From: Martin Rex Message-Id: <201203090256.q292uLh0007143@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Fri, 9 Mar 2012 03:56:21 +0100 (MET) In-Reply-To: from "Nico Williams" at Mar 8, 12 10:08:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, Nicolas.Williams@oracle.com Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 09 Mar 2012 02:56:44 -0000 Nico Williams wrote: > > On Thu, Mar 8, 2012 at 8:31 AM, Stephen Farrell > > On 03/08/2012 02:27 PM, Leif Johansson wrote: > >>Stephen Farrell wrote: > >>> > >>> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't > >>> care much really, but others do;-) > >> > >> Not sure I agree. The API proposed in this draft are completely > >> orthogonal to base GSS-API. Why is this an update? > > > > Personally, I don't care much. But it does extend the > > GSS-API. I'll go with what the WG want here but other > > ADs might want this. (Was that specifically considered by > > the WG?) > > I've no problem with saying that all extensions to the GSS-API must > update RFC2743 and, if they specify C bindings, also RFC244. Actually, I would prefer to not use an "Updates:" for 2743, 2744. Given the mess there is with updates to STD-13 (DNS 1034/1035), I'm wondering whether there should be a distinction of metadata into "Extends:" and "Changes:", rather than lumping that together under Updates:. > > I think an argument can be made this should be true w.r.t. all > Standards-Track API-specifying RFCs. I do not see a big difference between new optional API-calls being added to an API standard, and new optional protocol features being added to an existing protocol standard. -Martin From mrex@sap.com Thu Mar 8 19:21:22 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 E877321E801C for ; Thu, 8 Mar 2012 19:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[AWL=0.201, 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 1YUjkFz0nHab for ; Thu, 8 Mar 2012 19:21:22 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6C21E8010 for ; Thu, 8 Mar 2012 19:21:22 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q293LE2h018916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 04:21:19 +0100 (MET) From: Martin Rex Message-Id: <201203090321.q293LDK8008639@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 9 Mar 2012 04:21:13 +0100 (MET) In-Reply-To: <201203090256.q292uLh0007143@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 9, 12 03:56:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, Nicolas.Williams@oracle.com Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 09 Mar 2012 03:21:23 -0000 Martin Rex wrote: > > Nico Williams wrote: > > > > Stephen Farrell wrote: > > >>Stephen Farrell wrote: > > >>> > > >>> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't > > >>> care much really, but others do;-) > > > > > > Personally, I don't care much. But it does extend the > > > GSS-API. I'll go with what the WG want here but other > > > ADs might want this. (Was that specifically considered by > > > the WG?) btw. rfc4401 (GSS-PRF) and rfc5178 (I18N support for names) do not carry an "Updates: 2743, 2744" either, although both probably have a much broader applicability than this API extension (i.e. can be implemented with more gss-api mechanisms than this one). -Martin From hannes.tschofenig@gmx.net Sun Mar 11 03:13:36 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 7104421F86AA for ; Sun, 11 Mar 2012 03:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 5QwEU4Tk9sHs for ; Sun, 11 Mar 2012 03:13:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 10D3221F869E for ; Sun, 11 Mar 2012 03:13:34 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 10:13:33 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 11 Mar 2012 11:13:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+uj4l10IauI5lOWknGciBk7vnsJ0ZhfZ6+0kHxDV +uL323uV8NK9ld Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Sun, 11 Mar 2012 12:13:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] SASL OAuth: Next Steps 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, 11 Mar 2012 10:13:36 -0000 Hi Bill,=20 I agree with you. I would prefer to say with the currently described = approach in the document absent strong objections.=20 We may gain some more implementation experience in the next few months = and could also reach out to the XMPP guys who had expressed interest in = this work instead of changing the core design. =20 Ciao Hannes On Jan 24, 2012, at 9:10 AM, William Mills wrote: > I've been thinking about this quite a bit, and Tim's rebuke to me = privately that I really should think about JSON seriously before = dismissing the idea because HTTP really is harder to parse than I think = it is struck home. >=20 > I'm still stuck on the fact that I think the HTTP we have to parse in = the client for the mechanism to work is all OAuth 2 protocol or defined = in the mechanims (discovery) so it's more limited. On the server side = it's very limited, only enough to figure out the discovery. So I don't = think the HTTP here is that scary. The actual HTTP we have to parse for = the mechanism to work on the server side is mimimal, and well defined. = Am I wrong? >=20 > SO.... I'm trying to figure out how this would work and what we'd need = to do in order to make JSON work instead of HTTP as the authentication = message format. My assumptions are: > =20 > - We're passing the Auth header in to a library, the SASL mechanism = itself doesn't need to parse it. >=20 > We need to support right now for the profiles I know about: >=20 > - The user name and host name for discovery > - The port number for things like MAC authentication > - the Authorization header payload > - discovery information for return to the client >=20 > It's possible we'll also need to pass in: >=20 > - The HTTP POST payload for profiles that require it (though I was = assuming GET only initially) > - Something else I'm forgetting about... or for extension = flexibility? >=20 > In the end I'm presuming we're passing all the real HTTP into a = library that will understand it anyway (which is how my initial = implementation is working) so we don't need to dive down into the header = and POST body payload in the JSON. If this is right then the JSON = doesn't look that hard, but then again if what I have above is correct = then we're not talking about a general use HTTP parser either. >=20 > The OAuth 1.0a library I was playing with for this consumes and gives = back the entire Auth header, but I don't know if that design pattern is = common. >=20 > Where do we go from here? >=20 > -bill >=20 >=20 >=20 >=20 >=20 > From: William Mills > To: Tim Showalter ; Russ Allbery = =20 > Cc: "kitten@ietf.org" =20 > Sent: Thursday, January 5, 2012 4:01 PM > Subject: Re: [kitten] SASL OAuth: Next Steps >=20 > Yeah, I really hate this. >=20 > There's stuff in the MAC token spec for example that requires knowing = the URL path, fragments, hostname, etc., and so we have to include every = element form HTTP that might be required for any OAuth (HTTP based = itself) authorization scheme. This means we have to write an entire = mapping grammar for an entire HTTP payload into JSON. >=20 > While I agree that HTTP is non-trivial to parse, I don't think it's = compelling enough for me to like the change to JSON because there are = enough HTTP parsing libraries out there that an implementer should not = have to do their own, they should pull one in. >=20 > As I said before, designing this in a vacuum HTTP is far down the = list, but I think in light of the fact that we're bridging from = something that *is* HTTP it is less complex overall to stay consistent. >=20 >=20 > -bill >=20 > From: Tim Showalter > To: Russ Allbery =20 > Cc: "kitten@ietf.org" =20 > Sent: Thursday, January 5, 2012 1:38 PM > Subject: Re: [kitten] SASL OAuth: Next Steps >=20 > On 1/4/12 6:34 PM, Russ Allbery wrote: > > Chris Newman writes: > >> Having a SASL parser call out to a header parser would be poor = security > >> design, because every line of code is an additional potential = security > >> vulnerability (especially prior to authentication) and a lot of = code is > >> needed for a 100% correct header parser. So I think it's actually > >> important for a SASL mechanism to not accept arbitrary header = syntax. > >=20 > > Based on my experience writing netnews implementations, which use = RFC 5322 > > header field syntax very akin to the HTTP header field syntax, I > > completely concur with Chris's reaction. The header field syntax is > > surprisingly complex, particularly in the presence of encoding and > > character set issues, and most implementors do not implement it = properly. >=20 > I'm really sorry to hear that -- I suspect you're right, and I don't = like it. I think trying to constrain JSON and define the mappings is = going to be a lot of work. >=20 > Is there a simple way to specify a general mapping? Or are we going = to have to do this on a per-header basis? >=20 > Tim > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From leifj@mnt.se Sun Mar 11 14:05:36 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 3CA2F21F8601 for ; Sun, 11 Mar 2012 14:05:36 -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 5SfJ1ZrmfMi7 for ; Sun, 11 Mar 2012 14:05:35 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2B921F85DA for ; Sun, 11 Mar 2012 14:05:34 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2BL5TJ1008537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Mar 2012 22:05:33 +0100 (CET) Message-ID: <4F5D1399.80705@mnt.se> Date: Sun, 11 Mar 2012 22:05:29 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <201203090321.q293LDK8008639@fs4113.wdf.sap.corp> In-Reply-To: <201203090321.q293LDK8008639@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 11 Mar 2012 21:05:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/2012 04:21 AM, Martin Rex wrote: > Martin Rex wrote: >> >> Nico Williams wrote: >>> >>> Stephen Farrell wrote: >>>>> Stephen Farrell wrote: >>>>>> >>>>>> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? >>>>>> (I don't care much really, but others do;-) >>>> >>>> Personally, I don't care much. But it does extend the >>>> GSS-API. I'll go with what the WG want here but other ADs >>>> might want this. (Was that specifically considered by the >>>> WG?) > > btw. rfc4401 (GSS-PRF) and rfc5178 (I18N support for names) do not > carry an "Updates: 2743, 2744" either, although both probably have > a much broader applicability than this API extension (i.e. can be > implemented with more gss-api mechanisms than this one). For the record I agree with Martin but don't think it is worth holding up the draft over. Stephen do you think this is an actual issue with the IESG? If not I propose we change nothing. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dE5kACgkQ8Jx8FtbMZndhTwCfQWroRF8sNMl75SnvAMNbzPUi a7sAoLmmXoOStkSJhRqdJ2qk4cezj4dv =l07N -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Sun Mar 11 14:10:45 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 CB6D921F86CA for ; Sun, 11 Mar 2012 14:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 DvvhIZyMZ2wm for ; Sun, 11 Mar 2012 14:10:41 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7709321F8601 for ; Sun, 11 Mar 2012 14:10:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D276A153606; Sun, 11 Mar 2012 21:10:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331500239; bh=uZVWCZowOQbmTp HBpVOgzl2+yBPtQ3tTRkwm4Vk19jE=; b=vO5fsqYYB8npBldVCmIQXW728dA3fY /5SPairLHAzrWpqKdlyetd8KzL3aCd4D6Gd1IfTRLhHQ8xdVSFT3q7gDQyvF6ocM MC8TINvjKivLNA0zo8COUavilRJJXjtLEPeHM0p9u8dfDxrAUOv943Svmbu0v/fZ qvbgS0Eobafz27W+K+AmhJstduyyQln5czVnUkE8LJ8VN95bkjTah3G2UCM1+wx4 4PwgYbjK25WWMQwV0NvpENbDMvPrDjLaufKtrQBN7JiulxEnWtCgr+VspZpxFL8d L5IxsJM82zQqaTnE1S7QqVdoalvlcsOBehQjKD0MY0LZ0uwUGCWTv5HQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 2ASZTB1X5w+J; Sun, 11 Mar 2012 21:10:39 +0000 (GMT) Received: from [10.226.44.61] (unknown [194.230.159.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 485ED1535C5; Sun, 11 Mar 2012 21:10:37 +0000 (GMT) Message-ID: <4F5D14CA.7030805@cs.tcd.ie> Date: Sun, 11 Mar 2012 21:10:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Leif Johansson References: <201203090321.q293LDK8008639@fs4113.wdf.sap.corp> <4F5D1399.80705@mnt.se> In-Reply-To: <4F5D1399.80705@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 11 Mar 2012 21:10:45 -0000 Hi Leif, On 03/11/2012 09:05 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/09/2012 04:21 AM, Martin Rex wrote: >> Martin Rex wrote: >>> >>> Nico Williams wrote: >>>> >>>> Stephen Farrell wrote: >>>>>> Stephen Farrell wrote: >>>>>>> >>>>>>> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? >>>>>>> (I don't care much really, but others do;-) >>>>> >>>>> Personally, I don't care much. But it does extend the >>>>> GSS-API. I'll go with what the WG want here but other ADs >>>>> might want this. (Was that specifically considered by the >>>>> WG?) >> >> btw. rfc4401 (GSS-PRF) and rfc5178 (I18N support for names) do not >> carry an "Updates: 2743, 2744" either, although both probably have >> a much broader applicability than this API extension (i.e. can be >> implemented with more gss-api mechanisms than this one). > > For the record I agree with Martin but don't think it is worth holding > up the draft over. > > Stephen do you think this is an actual issue with the IESG? If not > I propose we change nothing. I'm ok with whatever the WG want as I said. Probability of a discuss is hard to tell but worst case is another IETF LC which'll generate zero comments, so +2 weeks. Soon's -13 appears with fixed email/affiliation for Nico I'll push it on. S > > Cheers Leif > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9dE5kACgkQ8Jx8FtbMZndhTwCfQWroRF8sNMl75SnvAMNbzPUi > a7sAoLmmXoOStkSJhRqdJ2qk4cezj4dv > =l07N > -----END PGP SIGNATURE----- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From leifj@mnt.se Sun Mar 11 14:16:29 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 964EE21F8608 for ; Sun, 11 Mar 2012 14:16:29 -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 5NxtK2nbD3HI for ; Sun, 11 Mar 2012 14:16:29 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7721F85A4 for ; Sun, 11 Mar 2012 14:16:28 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2BLGM0l011947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Mar 2012 22:16:27 +0100 (CET) Message-ID: <4F5D1626.7090307@mnt.se> Date: Sun, 11 Mar 2012 22:16:22 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <4F58BF4B.7050009@cs.tcd.ie> <4F58C1C4.6000105@mnt.se> <4F58C2C7.4090904@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 11 Mar 2012 21:16:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/2012 06:56 PM, Sam Hartman wrote: > 2) If you have no IANA actions, please state "This specification > has no actions for IANA." You're much less likely to get questions > if you use those exact words. > > IANA has complained in the past if an IANA Considerations section > included anything besides current actions for IANA. My > recommendation here would be to start the IANA considerations > section with "This Specification has no actions for IANA," in its > own paragraph. ok, doing that! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dFiYACgkQ8Jx8FtbMZnf82gCgszzYS69PO4B47enLiYDizs1K vq4An04uwPQTBl+qEWcgWE/6KKrXcddr =ijyf -----END PGP SIGNATURE----- From leifj@mnt.se Sun Mar 11 14:45:29 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 8CA1A21F84F5 for ; Sun, 11 Mar 2012 14:45:29 -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 ez4nk2mLVpUu for ; Sun, 11 Mar 2012 14:45:28 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9DC21F84E6 for ; Sun, 11 Mar 2012 14:45:28 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2BLj8lB005945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 22:45:12 +0100 (CET) Message-ID: <4F5D1CE3.7000301@mnt.se> Date: Sun, 11 Mar 2012 22:45:07 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org, Nico Williams References: <4F58BF4B.7050009@cs.tcd.ie> In-Reply-To: <4F58BF4B.7050009@cs.tcd.ie> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 11 Mar 2012 21:45:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/2012 03:16 PM, Stephen Farrell wrote: > > Hi, > > Shawn has requested publication of this draft. This is my AD > review of that prior to starting IETF last call. > > I've 3 questions that I think need answering. I think a revised > I-D is likely needed before IETF LC to handle those. (If not then > you'll argue about that:-) I've also some other comments that > can be handled before or during IETF LC along with whatever > other comments crop up. > > Things that need handling: > > 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I > don't care much really, but others do;-) > > 2. The IANA considerations section doesn't seem clear enough > for IANA to action. What's the update rule, what's the name > of the registry, ... > > 3. Nico's address bounces. Please fix unless there's some > good reason - is there? > > Other comments/questions, (not blocking):- > > - Section 6 is a bit unclear. In particular the "otherwise" in the > 2nd para on p8 - does that mean "if there's no colon" or "if there's > no space and no colon"? The clarity of this section could be > improved, maybe by laying it out as a bulleted list. Actually I think its not. You're supposed to read it as [ ] I.e you can have a nameform even if you have a local name so it is actually written correctly. Do we need ABNF (please say no)? > > - I don't really get the 2nd last paragraph of section 6, what's > that saying? Nico, I think you wrote that one... can you elaborate? > > - The last para of section 6 is also a bit unclear, I think you > mean where the administrator controls all aspects (e.g. both the > KDC and the relying applications) but I'm not 100% sure. > > - 7.1, last sentence - would it be better to spell this out some > more? E.g. maybe say that ordering of SET OF OCTET STRING MUST > be preserved. Sure, how about "Any implementation of SET OF OCTET STRING for use by this specification MUST preserve order." > > - The danger in the 2nd last para of 7.6 is not crystal clear. > Might be worth spelling that out some more. The WG argued over this one extensively. I need a specific suggestion if we are to argue some more :-) > > - An example or two would be nice, or a pointer to such if its > easily referenced. Example of API calls in C you mean? We could always point to project moonshot. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dHOMACgkQ8Jx8FtbMZneveQCgs/bqokVii0fLCoriu4m5fFpi XTsAn3iQioE3Zta/msTyCw3SajqfGHYE =S4x9 -----END PGP SIGNATURE----- From leifj@mnt.se Sun Mar 11 15:23: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 DDA5221F8601 for ; Sun, 11 Mar 2012 15:23: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=[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 myZvtcjISnYX for ; Sun, 11 Mar 2012 15:23:07 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A936121F8723 for ; Sun, 11 Mar 2012 15:23:05 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2BMMuWD017916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 23:23:00 +0100 (CET) Message-ID: <4F5D25BF.3010605@mnt.se> Date: Sun, 11 Mar 2012 23:22:55 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <201203090321.q293LDK8008639@fs4113.wdf.sap.corp> <4F5D1399.80705@mnt.se> <4F5D14CA.7030805@cs.tcd.ie> In-Reply-To: <4F5D14CA.7030805@cs.tcd.ie> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 11 Mar 2012 22:23:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/11/2012 10:10 PM, Stephen Farrell wrote: > > Hi Leif, > > On 03/11/2012 09:05 PM, Leif Johansson wrote: On 03/09/2012 04:21 > AM, Martin Rex wrote: >>>> Martin Rex wrote: >>>>> >>>>> Nico Williams wrote: >>>>>> >>>>>> Stephen Farrell wrote: >>>>>>>> Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> 1. Shouldn't this UPDATE something? Maybe 2743 and >>>>>>>>> 2744? (I don't care much really, but others do;-) >>>>>>> >>>>>>> Personally, I don't care much. But it does extend the >>>>>>> GSS-API. I'll go with what the WG want here but other >>>>>>> ADs might want this. (Was that specifically considered >>>>>>> by the WG?) >>>> >>>> btw. rfc4401 (GSS-PRF) and rfc5178 (I18N support for names) >>>> do not carry an "Updates: 2743, 2744" either, although both >>>> probably have a much broader applicability than this API >>>> extension (i.e. can be implemented with more gss-api >>>> mechanisms than this one). > > For the record I agree with Martin but don't think it is worth > holding up the draft over. > > Stephen do you think this is an actual issue with the IESG? If not > I propose we change nothing. > >> I'm ok with whatever the WG want as I said. > >> Probability of a discuss is hard to tell but worst case is >> another IETF LC which'll generate zero comments, so +2 weeks. > >> Soon's -13 appears with fixed email/affiliation for Nico I'll >> push it on. OK, I don't -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dJb8ACgkQ8Jx8FtbMZndAPgCghT8SAYx0Oee76/84WlJG390N 76UAoI68zleg7RkQkLdCc+4kIVooCHrT =Ztml -----END PGP SIGNATURE----- From internet-drafts@ietf.org Sun Mar 11 15:35: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 4A41121F8711; Sun, 11 Mar 2012 15:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 FreS1C9udF3j; Sun, 11 Mar 2012 15:35:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D683721F86F0; Sun, 11 Mar 2012 15:35:11 -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.00 Message-ID: <20120311223511.11139.43669.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 15:35:11 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-13.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: Sun, 11 Mar 2012 22:35: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= Generation Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : Nicolas Williams Leif Johansson Sam Hartman Simon Josefsson Filename : draft-ietf-kitten-gssapi-naming-exts-13.txt Pages : 18 Date : 2012-03-11 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-13= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-13.= txt From leifj@sunet.se Sun Mar 11 15:36:32 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 9B64F21F8764 for ; Sun, 11 Mar 2012 15:36:32 -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 IEaGbpCYQ6t9 for ; Sun, 11 Mar 2012 15:36:32 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id AACB721F8763 for ; Sun, 11 Mar 2012 15:36:31 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2BMaM3e016328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Mar 2012 23:36:26 +0100 (CET) Message-ID: <4F5D28E6.7000002@sunet.se> Date: Sun, 11 Mar 2012 23:36:22 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20120311223512.11139.75291.idtracker@ietfa.amsl.com> In-Reply-To: <20120311223512.11139.75291.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.5 X-Forwarded-Message-Id: <20120311223512.11139.75291.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-gssapi-naming-exts-13.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: Sun, 11 Mar 2012 22:36:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've tried to address the non-controversial stuff in this version. Cheers Leif - -------- Original Message -------- Subject: New Version Notification for draft-ietf-kitten-gssapi-naming-exts-13.txt Date: Sun, 11 Mar 2012 15:35:12 -0700 From: internet-drafts@ietf.org To: leifj@sunet.se CC: nico@cryptonector.com, hartmans-ietf@mit.edu, simon@josefsson.org A new version of I-D, draft-ietf-kitten-gssapi-naming-exts-13.txt has been successfully submitted by Leif Johansson and posted to the IETF repository. Filename: draft-ietf-kitten-gssapi-naming-exts Revision: 13 Title: GSS-API Naming Extensions Creation date: 2012-03-11 WG ID: kitten Number of pages: 18 Abstract: The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. The IETF Secretariat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dKOYACgkQ8Jx8FtbMZnfpvQCeNCY8VHxEnKFe9NTvw7LFoLvI zuEAn3cX6VwP/XCa7+j/1sy7aMTgRqzg =IW5o -----END PGP SIGNATURE----- From nico@cryptonector.com Sun Mar 11 16:30: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 2F39021F8732 for ; Sun, 11 Mar 2012 16:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 cvL4XmHxv2Zn for ; Sun, 11 Mar 2012 16:30:40 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id EE86C21F850C for ; Sun, 11 Mar 2012 16:30:38 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 8ADE42C2060 for ; Sun, 11 Mar 2012 16:30:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=wKo4Fn1Atke1oF3L3/YYG 1DUvT14CwLISX8qvxmG+QjFbs4wz66VVOtoQ8RUNY5sldfkc3cNzJIxOP+A7lKuN 96kaTD6CBoY6fS0tLWJPMezSaTBrtlsaKOTVNe2LMuhyt5Ysjmu42dU9668HFKTm F7eL1xpuBji6qNEk4hxrfw= 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=IaCCHbm9DosALceam1UX j66c+II=; b=vRbD8jptn1JQH88E0AIE39mDwgTbIVfjZuIv4p0wV4xhWhbMhcHu ZbNzG7lb4nONIIruqpt9ubSHUeN36owFNl9dxlhr5RHSmxb+2um9jKqa4tqKAe6s y3RTnulBGqMBnlI7KzRyGS5ol4moEC9aeaxwQjyZ47SReV4CqDibWl4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 662BB2C2059 for ; Sun, 11 Mar 2012 16:30:38 -0700 (PDT) Received: by dakl33 with SMTP id l33so4643661dak.31 for ; Sun, 11 Mar 2012 16:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.100 with SMTP id hf4mr16382372pbc.118.1331508638101; Sun, 11 Mar 2012 16:30:38 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Sun, 11 Mar 2012 16:30:37 -0700 (PDT) In-Reply-To: <4F5D1CE3.7000301@mnt.se> References: <4F58BF4B.7050009@cs.tcd.ie> <4F5D1CE3.7000301@mnt.se> Date: Sun, 11 Mar 2012 18:30:37 -0500 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 11 Mar 2012 23:30:41 -0000 On Sun, Mar 11, 2012 at 4:45 PM, Leif Johansson wrote: > On 03/08/2012 03:16 PM, Stephen Farrell wrote: >> 3. Nico's address bounces. Please fix unless there's some >> good reason - is there? Oh, FYI, please make my company name "Cryptonector, LLC". This can be done as a note tot he RFC-Editor. >> - Section 6 is a bit unclear. In particular the "otherwise" in the >> 2nd para on p8 - does that mean "if there's no colon" or "if there's >> no space and no colon"? The clarity of this section could be >> improved, maybe by laying it out as a bulleted list. > > Actually I think its not. You're supposed to read it as > > [ ] No, more like: [ ...] Where is | And is a sequence of printable ASCII characters not including space or colon, while is, well, a URI, and specifically has a colon and no spaces. > I.e you can have a nameform even if you have a local name so > it is actually written correctly. Do we need ABNF (please say no)? I think we need some examples, and possibly ABNF yes. Here are some examples: tag:foo.example,2012#attr1 local_foo local_foo tag:foo.example,2012#attr1 local_foo local_bar tag:bar.example,2012#attrX tag:foo.example,2012#attrY >> >> - I don't really get the 2nd last paragraph of section 6, what's >> that saying? > > Nico, I think you wrote that one... can you elaborate? Although I do not recall writing that I can explain the text, I think, though I'm not sure that I can write much better text. This paragraph needs to be read in conjunction with section 5, but it belongs in section 6. The idea is that an attribute name like "e-mail address" is or may not be enough and may need some additional contextual information. This contextual information is to be "prefixed", effectively, to the part of the attribute name that says "e-mail address". In particular, this paragraph warns not to use ASCII space as this is used to split up the complete attribute name into a list of attribute names. What this paragraph does not (and should not) do is say much more about how to construct attribute names. I think part of what causes confusion is the term "prefix"; I think "affix" would do. To give a more concrete example, suppose we have e-mail address as known to a KDC versus e-mail address as known to a CA issuer for a PKINIT client certificate that is fully trusted by the KDC versus an e-mail address from a PKINIT client certificate where the KDC does not trust anything more than the subject public key from the certificate. Using tag URIs we might then have: tag:ietf.org,2012#e-mail-address tag:ietf.org,2012#trusted-pki-e-mail-address tag:ietf.org,2012#untrusted-e-mail-address I do think that part of the problem with this is that if we were to elaborate on a concept of "issuer" then we wouldn't need this paragraph at all. I'd much rather do that!! Note that to elaborate on a concept of issuer is trivial: specify an attribute name for "issuer" and specify that its value is an exported name token for the name of the issuer of the GSS NAME or a given attribute of the GSS NAME. For example: - GSS_Get_name_attribute(some_name, "tag:ietf.org,2012#GSS-name-issuer") should produce an exported name token corresponding to aKerberos realm name or CA name. - GSS_Get_name_attribute(some_name, "tag:ietf.org,2012#e-mail-address") should produce an e-mail address. - GSS_Get_name_attribute(some_name, "tag:ietf.org,2012#GSS-name-issuer tag:ietf.org,2012#e-mail-address") should produce the name of the issuer of the e-mail address attribute's value. Note that in this example we compose attribute names with an ASCII space. We can even specify an attribute like the issuer attribute that indicates whether the given attribute is trusted per-local policy. Such an attribute must not be delivered with any name on the wire, but rather evaluated locally. Sam, do you have any ideas as to how to rewrite that paragraph to be clearer? And can you explain why elaborating on issuer wouldn't be better? >> - The danger in the 2nd last para of 7.6 is not crystal clear. >> Might be worth spelling that out some more. > > The WG argued over this one extensively. I need a specific suggestion > if we are to argue some more :-) But we can clarify. The problem is "deny" ACL entries where the subject of the entry is an attribute that a given principal might have but which is not disclosed to the relying party. The canonical example would be DENY ACL entries where the subject is a group. In a Windows Active Directory environment the PAC may not deliver the SIDs of certain groups that a user may in fact be a member of (e.g., local groups), thus DENY ACL entries with such groups as the subject will have no effect! Nico -- From florob@babelmonkeys.de Sun Mar 11 17:01:25 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 54CBB21F8701 for ; Sun, 11 Mar 2012 17:01:25 -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 9pObT3AYIGWF for ; Sun, 11 Mar 2012 17:01:24 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4421F86FA for ; Sun, 11 Mar 2012 17:01:24 -0700 (PDT) Received: from xdsl-81-173-168-189.netcologne.de ([81.173.168.189] helo=[192.168.0.50]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S6shV-0001Mm-Hs for kitten@ietf.org; Mon, 12 Mar 2012 01:01:21 +0100 Message-ID: <4F5D3CCB.3070102@babelmonkeys.de> Date: Mon, 12 Mar 2012 01:01:15 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> In-Reply-To: <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] SASL OAuth: Next Steps 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, 12 Mar 2012 00:01:25 -0000 On 11.03.2012 11:13, Hannes Tschofenig wrote: > Hi Bill, > > I agree with you. I would prefer to say with the currently described approach in the document absent strong objections. > We may gain some more implementation experience in the next few months and could also reach out to the XMPP guys who had expressed interest in this work instead of changing the core design. > > Ciao > Hannes > > On Jan 24, 2012, at 9:10 AM, William Mills wrote: > >> I've been thinking about this quite a bit, and Tim's rebuke to me privately that I really should think about JSON seriously before dismissing the idea because HTTP really is harder to parse than I think it is struck home. >> >> I'm still stuck on the fact that I think the HTTP we have to parse in the client for the mechanism to work is all OAuth 2 protocol or defined in the mechanims (discovery) so it's more limited. On the server side it's very limited, only enough to figure out the discovery. So I don't think the HTTP here is that scary. The actual HTTP we have to parse for the mechanism to work on the server side is mimimal, and well defined. Am I wrong? >> >> SO.... I'm trying to figure out how this would work and what we'd need to do in order to make JSON work instead of HTTP as the authentication message format. My assumptions are: >> >> - We're passing the Auth header in to a library, the SASL mechanism itself doesn't need to parse it. >> >> We need to support right now for the profiles I know about: >> >> - The user name and host name for discovery >> - The port number for things like MAC authentication >> - the Authorization header payload >> - discovery information for return to the client >> >> It's possible we'll also need to pass in: >> >> - The HTTP POST payload for profiles that require it (though I was assuming GET only initially) >> - Something else I'm forgetting about... or for extension flexibility? >> >> In the end I'm presuming we're passing all the real HTTP into a library that will understand it anyway (which is how my initial implementation is working) so we don't need to dive down into the header and POST body payload in the JSON. If this is right then the JSON doesn't look that hard, but then again if what I have above is correct then we're not talking about a general use HTTP parser either. >> >> The OAuth 1.0a library I was playing with for this consumes and gives back the entire Auth header, but I don't know if that design pattern is common. >> >> Where do we go from here? >> >> -bill Nom, tasty TOFU. Hi, I have a question/suggestion concerning this. I'm admittedly somewhat reluctant to ask at this point, because I have not found time to read enough of the OAuth RFCs to get the full picture, but please bear with me. It seems we have a relatively well defined list of necessary information. If this is put into JSON it appears to me that this JSON, except for ordering of entries will not be particularly flexible. Is there a compelling reason not to go back to a good old comma separated key value pair list at that point? The reason I ask is that having either a HTTP or a JSON parser (even a limited one) just for a SASL mechanism seems like enormous over engineering to me. This particularly struck me when people were discussing token based authentication at the last XMPP Summit. People were suggesting we might be able to reuse SASL OAuth for this under the assumption that it would just amount to sending a single token string over the wire. I find it somewhat irritating that at this point in time it is very significantly more complex than that. Regards, Florian Zeitz From wmills@yahoo-inc.com Sun Mar 11 17:36: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 3965B21F8623 for ; Sun, 11 Mar 2012 17:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.374 X-Spam-Level: X-Spam-Status: No, score=-17.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y0eK5YKGafv for ; Sun, 11 Mar 2012 17:36:05 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id A2ADB21F861E for ; Sun, 11 Mar 2012 17:36:05 -0700 (PDT) Received: from [98.139.91.68] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 00:36:03 -0000 Received: from [98.139.91.15] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 00:36:02 -0000 Received: from [127.0.0.1] by omp1015.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 00:36:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 969939.54737.bm@omp1015.mail.sp2.yahoo.com Received: (qmail 75349 invoked by uid 60001); 12 Mar 2012 00:36:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331512562; bh=qJjNs2G1n+IUS9HNPyYVggrepcr0u/IppaOyr0FwxSU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bBTSI1y21HCs6VMJ1zCF/lLgnpR9PpGJq3ek3VLVQet/ufA9YR8V0zY3LR+DPRAMT0Ht2urpE28d67mB5MGT0ik96bGrasSbYsSHRfFdwQbWCblaCPxRtlcolKr80rfe6XHvlu2klHggLea0NASZsKDMdMDqGcXvfMhXOO225Ls= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dJLTZL1QGpsCvVFnK+VyRMwBmWcaI522x2QX4mH3gYWlKRZV3onOv3CALFfpbXPLWf29uC7VIfLkEaOuHekj5R5kAyT3A603HnuU7sz7V5uYs5CfBNDDl+BGZV4xESqRTEwx57M1NWsbiovI3JlyDfgJ59+mD+ArjijqxMcp5m0=; X-YMail-OSG: 9o3CVkAVM1ks._X4Uesv13HsYXTt.mMvaqi3tLbPObTAgEU 8bDyK.7Ra8Oppoptbh319mjvxqCrjLSiOANfg02sZbIYo1LqXwkWBNmaSCDT 5hvCS_h6clbxYQoT8ku99mvIVC7e.l3QxLZw7QiYnxQrBrGV.yI9AzoEo9bZ mUvBNPJMkB8hBBiH27B5E7LxdC46Y8BclhkkpsSpMfTBJweWqDnKHM2BChpr nivYrAYPz83y3CSIMShSIIOSzAIBcO4.aulEDhZSMMgfeGO3DFPeNalsQz1I _2Zhx5iBNrmy90kOb1xqfQxZyW2aKpGhtQxq2mhhfy3_ilKMcSXIJrjtYz_M Q6n3dDV7TaI0Lc5s2fh55oiI7i3MjLrUW7DtSeUs1aqa9RkrvK.AjfMrnUd3 6Ynm3txZ8q8kWPpjE2pcbu20INaA49A-- Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Sun, 11 Mar 2012 17:36:01 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> Message-ID: <1331512561.69670.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sun, 11 Mar 2012 17:36:01 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-351979839-1331512561=:69670" Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 00:36:07 -0000 ---551393103-351979839-1331512561=:69670 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Something else that may play in to this is the fact that this basically isn= 't that far from what Google has had running for quite a while no on their = IMAP service.=A0 Updating those implementations to this would be a much sma= ller move than going to JSON.=A0 There's quite a bit of actually running co= de out there working against Google, so staying near that implementaiton pr= obably has value.=0A=0A-bill=0A=0A=0A=0A=0A________________________________= =0A From: Hannes Tschofenig =0ATo: William Mills= =0ACc: Hannes Tschofenig ; Tim Showalter ; Russ Allbery ; = "kitten@ietf.org" =0ASent: Sunday, March 11, 2012 3:13 AM= =0ASubject: Re: [kitten] SASL OAuth: Next Steps=0A =0AHi Bill, =0A=0AI agre= e with you. I would prefer to say with the currently described approach in = the document absent strong objections. =0AWe may gain some more implementat= ion experience in the next few months and could also reach out to the XMPP = guys who had expressed interest in this work instead of changing the core d= esign.=A0 =0A=0ACiao=0AHannes=0A=0AOn Jan 24, 2012, at 9:10 AM, William Mil= ls wrote:=0A=0A> I've been thinking about this quite a bit, and Tim's rebuk= e to me privately that I really should think about JSON seriously before di= smissing the idea because HTTP really is harder to parse than I think it is= struck home.=0A> =0A> I'm still stuck on the fact that I think the HTTP we= have to parse in the client for the mechanism to work is all OAuth 2 proto= col or defined in the mechanims (discovery) so it's more limited.=A0 On the= server side it's very limited, only enough to figure out the discovery.=A0= So I don't think the HTTP here is that scary. The actual HTTP we have to p= arse for the mechanism to work on the server side is mimimal, and well defi= ned.=A0 Am I wrong?=0A> =0A> SO.... I'm trying to figure out how this would= work and what we'd need to do in order to make JSON work instead of HTTP a= s the authentication message format.=A0 My assumptions are:=0A>=A0 =0A> -= =A0 =A0 We're passing the Auth header in to a library, the SASL mechanism i= tself doesn't need to parse it.=0A> =0A> We need to support right now for t= he profiles I know about:=0A> =0A> -=A0 =A0 The user name and host name for= discovery=0A> -=A0 =A0 The port number for things like MAC authentication= =0A> -=A0 =A0 the Authorization header payload=0A> -=A0 =A0 discovery infor= mation for return to the client=0A> =0A> It's possible we'll also need to p= ass in:=0A> =0A> -=A0 =A0 The HTTP POST payload for profiles that require i= t (though I was assuming GET only initially)=0A> -=A0 =A0 Something else I'= m forgetting about... or for extension flexibility?=0A> =0A> In the end I'm= presuming we're passing all the real HTTP into a library that will underst= and it anyway (which is how my initial implementation is working) so we don= 't need to dive down into the header and POST body payload in the JSON. If = this is right then the JSON doesn't look that hard, but then again if what = I have above is correct then we're not talking about a general use HTTP par= ser either.=0A> =0A> The OAuth 1.0a library I was playing with for this con= sumes and gives back the entire Auth header, but I don't know if that desig= n pattern is common.=0A> =0A> Where do we go from here?=0A> =0A> -bill=0A> = =0A> =0A> =0A> =0A> =0A> From: William Mills =0A> To:= Tim Showalter ; Russ Allbery =0A= > Cc: "kitten@ietf.org" =0A> Sent: Thursday, January 5, 2= 012 4:01 PM=0A> Subject: Re: [kitten] SASL OAuth: Next Steps=0A> =0A> Yeah,= I really hate this.=0A> =0A> There's stuff in the MAC token spec for examp= le that requires knowing the URL path, fragments, hostname, etc., and so we= have to include every element form HTTP that might be required for any OAu= th (HTTP based itself) authorization scheme.=A0 This means we have to write= an entire mapping grammar for an entire HTTP payload into JSON.=0A> =0A> W= hile I agree that HTTP is non-trivial to parse, I don't think it's compelli= ng enough for me to like the change to JSON because there are enough HTTP p= arsing libraries out there that an implementer should not have to do their = own, they should pull one in.=0A> =0A> As I said before, designing this in = a vacuum HTTP is far down the list, but I think in light of the fact that w= e're bridging from something that *is* HTTP it is less complex overall to s= tay consistent.=0A> =0A> =0A> -bill=0A> =0A> From: Tim Showalter =0A> To: Russ Allbery =0A> Cc: "kitten@ietf= .org" =0A> Sent: Thursday, January 5, 2012 1:38 PM=0A> Su= bject: Re: [kitten] SASL OAuth: Next Steps=0A> =0A> On 1/4/12 6:34 PM, Russ= Allbery wrote:=0A> > Chris Newman=A0 writes:=0A> = >> Having a SASL parser call out to a header parser would be poor security= =0A> >> design, because every line of code is an additional potential secur= ity=0A> >> vulnerability (especially prior to authentication) and a lot of = code is=0A> >> needed for a 100% correct header parser. So I think it's act= ually=0A> >> important for a SASL mechanism to not accept arbitrary header = syntax.=0A> > =0A> > Based on my experience writing netnews implementations= , which use RFC 5322=0A> > header field syntax very akin to the HTTP header= field syntax, I=0A> > completely concur with Chris's reaction.=A0 The head= er field syntax is=0A> > surprisingly complex, particularly in the presence= of encoding and=0A> > character set issues, and most implementors do not i= mplement it properly.=0A> =0A> I'm really sorry to hear that -- I suspect y= ou're right, and I don't like it.=A0 I think trying to constrain JSON and d= efine the mappings is going to be a lot of work.=0A> =0A> Is there a simple= way to specify a general mapping?=A0 Or are we going to have to do this on= a per-header basis?=0A> =0A> Tim=0A> _____________________________________= __________=0A> Kitten mailing list=0A> Kitten@ietf.org=0A> https://www.ietf= .org/mailman/listinfo/kitten=0A> =0A> =0A> =0A> ___________________________= ____________________=0A> Kitten mailing list=0A> Kitten@ietf.org=0A> https:= //www.ietf.org/mailman/listinfo/kitten=0A> =0A> =0A> ______________________= _________________________=0A> Kitten mailing list=0A> Kitten@ietf.org=0A> h= ttps://www.ietf.org/mailman/listinfo/kitten ---551393103-351979839-1331512561=:69670 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Something= else that may play in to this is the fact that this basically isn't that f= ar from what Google has had running for quite a while no on their IMAP serv= ice.  Updating those implementations to this would be a much smaller m= ove than going to JSON.  There's quite a bit of actually running code = out there working against Google, so staying near that implementaiton proba= bly has value.

-bill


= From: Hannes Tschofenig <= ;hannes.tschofenig@gmx.net>
To: William Mills <wmills@yahoo-inc.com>
Cc: Hannes Tschofenig <hanne= s.tschofenig@gmx.net>; Tim Showalter <timshow@yahoo-inc.com>; Russ= Allbery <rra@stanford.edu>; "kitten@ietf.org" <kitten@ietf.org>= ;
Sent: Sunday, March= 11, 2012 3:13 AM
Subject:= Re: [kitten] SASL OAuth: Next Steps

=0AHi Bill,=

I agree with you. I would prefer to say with the currently describ= ed approach in the document absent strong objections.
We may gain some = more implementation experience in the next few months and could also reach = out to the XMPP guys who had expressed interest in this work instead of cha= nging the core design. 

Ciao
Hannes

On Jan 24, 2012,= at 9:10 AM, William Mills wrote:

> I've been thinking about this= quite a bit, and Tim's rebuke to me privately that I really should think a= bout JSON seriously before dismissing the idea because HTTP really is harde= r to parse than I think it is struck home.
>
> I'm still stuck= on the fact that I think the HTTP we have to parse in the client for the m= echanism to work is all OAuth 2 protocol or defined in the mechanims (disco= very) so it's more limited.  On the server side it's very limited, onl= y enough to figure out the discovery.  So I don't think the HTTP here is that scary. The actual HTTP we have to parse for the mech= anism to work on the server side is mimimal, and well defined.  Am I w= rong?
>
> SO.... I'm trying to figure out how this would work = and what we'd need to do in order to make JSON work instead of HTTP as the = authentication message format.  My assumptions are:
>  > -    We're passing the Auth header in to a library, the SAS= L mechanism itself doesn't need to parse it.
>
> We need to su= pport right now for the profiles I know about:
>
> -  &nb= sp; The user name and host name for discovery
> -    The po= rt number for things like MAC authentication
> -    the Aut= horization header payload
> -    discovery information for = return to the client
>
> It's possible we'll also need to pass= in:
>
> -    The HTTP POST payload for profiles that require it (though I was assuming GET only initially)
>= ; -    Something else I'm forgetting about... or for extension fl= exibility?
>
> In the end I'm presuming we're passing all the = real HTTP into a library that will understand it anyway (which is how my in= itial implementation is working) so we don't need to dive down into the hea= der and POST body payload in the JSON. If this is right then the JSON doesn= 't look that hard, but then again if what I have above is correct then we'r= e not talking about a general use HTTP parser either.
>
> The = OAuth 1.0a library I was playing with for this consumes and gives back the = entire Auth header, but I don't know if that design pattern is common.
&= gt;
> Where do we go from here?
>
> -bill
>
&= gt;
>
>
>
> From: William Mills <wmills@yahoo-inc.com>
> = To: Tim Showalter <timshow@yahoo-inc.com>; Russ Allbery &l= t;r= ra@stanford.edu>
> Cc: "kitten@ietf.org" <kitten@ietf.org>= ;
> Sent: Thursday, January 5, 2012 4:01 PM
> Subject: Re: [ki= tten] SASL OAuth: Next Steps
>
> Yeah, I really hate this.
= >
> There's stuff in the MAC token spec for example that requires= knowing the URL path, fragments, hostname, etc., and so we have to include= every element form HTTP that might be required for any OAuth (HTTP based i= tself) authorization scheme.  This means we have to write an entire ma= pping grammar for an entire HTTP payload into JSON.
>
> While I agr= ee that HTTP is non-trivial to parse, I don't think it's compelling enough = for me to like the change to JSON because there are enough HTTP parsing lib= raries out there that an implementer should not have to do their own, they = should pull one in.
>
> As I said before, designing this in a = vacuum HTTP is far down the list, but I think in light of the fact that we'= re bridging from something that *is* HTTP it is less complex overall to sta= y consistent.
>
>
> -bill
>
> From: Tim Sh= owalter <timshow@yahoo-inc.com>
> To: Russ Allbery &= lt;= rra@stanford.edu>
> Cc: "kitten@ietf.org" <kitten@= ietf.org>
> Sent: Thursday, January 5, 2012 1:38 PM
> S= ubject: Re: [kitten] SASL OAuth: Next Steps
>
> On 1/4/12 6:34= PM, Russ Allbery wrote:
> > Chris Newman<chris.newm= an@oracle.com>  writes:
> >> Having a SASL parser c= all out to a header parser would be poor security
> >> design, = because every line of code is an additional potential security
> >= > vulnerability (especially prior to authentication) and a lot of code i= s
> >> needed for a 100% correct header parser. So I think it's= actually
> >> important for a SASL mechanism to not accept arb= itrary header syntax.
> >
> > Based on my experience wri= ting netnews implementations, which use RFC 5322
> > header field syntax very akin to the HTTP header field syntax, I
> > completel= y concur with Chris's reaction.  The header field syntax is
> &g= t; surprisingly complex, particularly in the presence of encoding and
&g= t; > character set issues, and most implementors do not implement it pro= perly.
>
> I'm really sorry to hear that -- I suspect you're r= ight, and I don't like it.  I think trying to constrain JSON and defin= e the mappings is going to be a lot of work.
>
> Is there a si= mple way to specify a general mapping?  Or are we going to have to do = this on a per-header basis?
>
> Tim
> __________________= _____________________________
> Kitten mailing list
> Kitten@ietf.or= g
> https://www.ietf.org/mailman/listinfo/kitten
>
>
>
> _______________________________________________=
> Kitten mailing list
> Kitten@ietf.org
> https://www.iet= f.org/mailman/listinfo/kitten
>
>
> _______________= ________________________________
> Kitten mailing list
> Kitten@ietf= .org
> https://www.ietf.org/mailman/listinfo/kitten


---551393103-351979839-1331512561=:69670-- From wmills@yahoo-inc.com Sun Mar 11 18:02:13 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 ADC8D21F8619 for ; Sun, 11 Mar 2012 18:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.387 X-Spam-Level: X-Spam-Status: No, score=-17.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX0SRo33EyuO for ; Sun, 11 Mar 2012 18:02:12 -0700 (PDT) Received: from nm25-vm3.bullet.mail.ne1.yahoo.com (nm25-vm3.bullet.mail.ne1.yahoo.com [98.138.91.155]) by ietfa.amsl.com (Postfix) with SMTP id A60E421F8609 for ; Sun, 11 Mar 2012 18:02:06 -0700 (PDT) Received: from [98.138.90.54] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 12 Mar 2012 01:02:02 -0000 Received: from [98.138.87.11] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 12 Mar 2012 01:02:02 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 12 Mar 2012 01:02:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 711790.89379.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 53562 invoked by uid 60001); 12 Mar 2012 01:02:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331514122; bh=xj+ElpBna1jAOrgvzSLxgI6AjiyXbjhw9EcETKLtyI4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NsATHaFDy4XPKTeGZECEIgBJDZmY0D3vgWn4YJRVuWFRIKMGIrbRB5CwGscSD2BC0adSpB+3+uB48R0wHLXh7X4v5gkCEwIM4WPzGGCVYUvKSQbedVAS9gNcdPmP9Q0O+IXyQhMSHhur8a2kCFckKylpWcx0r6O77JMEMNymXsA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XkSxxi6VII146a84zcwrRZAnw2ajnZJ4TWXSO/2ufdLYbgdkiQq8Ke1MoFODBvXwHX+BCs30LAab0fwcFw9yXzHpyMyJ5ZoNhvA9zqb5qIGvnY8rZgB439POQLGraRsHhNfH4SzuNkMS77rfAwi9O1TnTwv2u2PTTrcS4dJzuiU=; X-YMail-OSG: bXQS1CQVM1l0gMwgEo7nCTBhriFSfgo3P0fGY4CIIYmKGJg HPEB6s98urrnmew6Ry_BOz9LbpcbuUHhE_S8VJr88599Dwa.xlQAdEmGVRUM 11jB1Ocf7vFzt537aJf.CPShdTDcbdjmc_lijI9r8NZQ3cPxedH04trekHXP WU_0Y1OYZqlLywMCguPwurn35IsAE4jLjZDVJVjeQDsbiY6rQBMopPxBXrQX 0aYkxB5oNLtG.._S0PAi5atJEuesbs1ZFTJm9To9t5i3gGtK96bssMXuusjr YPp8dqgXaGBLXwf85e1EAU.Cd9toyCmWpzTbzM2iLuqtD8R46Z7npdT6UC5b VcFX8Dj0bUihjUIR8JFXZgr89egAhIkpUJ1N4dMgdBXf1P6waa4UoBiKFT0I mDSzZ7FLYF2c0618yB0z35dN33wts Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Sun, 11 Mar 2012 18:02:02 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> <4F5D3CCB.3070102@babelmonkeys.de> Message-ID: <1331514122.47869.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Sun, 11 Mar 2012 18:02:02 -0700 (PDT) From: William Mills To: Florian Zeitz , "kitten@ietf.org" In-Reply-To: <4F5D3CCB.3070102@babelmonkeys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 01:02:13 -0000 First, lemme say I'm happy to have active discussion on this!=A0 More inlin= e...=0A=0A=0A>________________________________=0A> From: Florian Zeitz =0A>To: kitten@ietf.org =0A>Sent: Sunday, March 11, 201= 2 5:01 PM=0A>Subject: Re: [kitten] SASL OAuth: Next Steps=0A=0A=0A= =0A=0A>Nom, tasty TOFU.=0A>=0A>Hi,=0A>=0A>I have a question/suggestion conc= erning this.=0A>I'm admittedly somewhat reluctant to ask at this point, bec= ause I have=0A>not found time to read enough of the OAuth RFCs to get the f= ull picture,=0A>but please bear with me.=0A>=0A>It seems we have a relative= ly well defined list of necessary=0A>information. If this is put into JSON = it appears to me that this JSON,=0A>except for ordering of entries will not= be particularly flexible.=0A>Is there a compelling reason not to go back t= o a good old comma=0A>separated key value pair list at that point?=0A=0AIt'= s well defined for the current token profiles, yes, but what about for=0Aex= tensions and new auth profiles?=A0 I wanted to avoid having to write in a= =0Amapping per OAuth auth profile from the data in band to how it's used in= =0Aauthentication.=0A=0A=0A=0A>=0A>The reason I ask is that having either a= HTTP or a JSON parser (even a=0A>limited one) just for a SASL mechanism se= ems like enormous over=0A>engineering to me.=0A=0A=0AOn the server side it'= s probably more work, but on the client you have to do =0A=0AHTTP and JSON = anyway.=0A=0A=0A>This particularly struck me when people were discussing to= ken based=0A>authentication at the last XMPP Summit. People were suggesting= we might=0A>be able to reuse SASL OAuth for this under the assumption that= it would=0A>just amount to sending a single token string over the wire.=0A= >I find it somewhat irritating that at this point in time it is very=0A>sig= nificantly more complex than that.=0A=0A=0AThe simplest token case, Bearer,= could work this way.=A0 I don't think anything =0A=0Aelse does.=0A=0A=0AWe= might be able to do it differently, but I was using this also as proposal = =0A=0Afor how to do OAuth 2 discovery.=A0 Will XMPP want auth endpoint disc= overy?=0A=0A=0A-bill=0A=0A=0A=0A>=0A>Regards,=0A>Florian Zeitz=0A>_________= ______________________________________=0A>Kitten mailing list=0A>Kitten@iet= f.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> From Hannes.Tschofenig@gmx.net Mon Mar 12 00:46:44 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 1FD3721F85F0 for ; Mon, 12 Mar 2012 00:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 Wcw9ElmhgiWO for ; Mon, 12 Mar 2012 00:46:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3F8BE21F85EA for ; Mon, 12 Mar 2012 00:46:41 -0700 (PDT) Received: (qmail 24071 invoked by uid 0); 12 Mar 2012 07:46:40 -0000 Received: from 194.251.119.196 by rms-de008.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary199671331538398853996" Date: Mon, 12 Mar 2012 08:46:38 +0100 From: "Hannes Tschofenig" Message-ID: <20120312074638.199670@gmx.net> MIME-Version: 1.0 To: "William Mills" X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: icwvb5sseSEqSJIAqXUhwh1+IGRvb0BJ Cc: kitten@ietf.org, Tim Showalter Subject: Re: [kitten] SASL OAuth: Next Steps 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, 12 Mar 2012 07:46:44 -0000 --========GMXBoundary199671331538398853996 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Bill, that's certainly a good reason for staying with the current design. Do you by chance know the person(s) at Google who did their implementation. It might be useful to reach out to them and to get them involved in the work. ----- Ursprüngliche Nachricht ----- Von: William Mills Gesendet: 12.03.12 02:36 Uhr An: Hannes Tschofenig Betreff: Re: [kitten] SASL OAuth: Next Steps Something else that may play in to this is the fact that this basically isn't that far from what Google has had running for quite a while no on their IMAP service. Updating those implementations to this would be a much smaller move than going to JSON. There's quite a bit of actually running code out there working against Google, so staying near that implementaiton probably has value. -bill ----------------------------------------------------------------- From: Hannes Tschofenig To: William Mills Cc: Hannes Tschofenig ; Tim Showalter ; Russ Allbery ; "kitten@ietf.org" Sent: Sunday, March 11, 2012 3:13 AM Subject: Re: [kitten] SASL OAuth: Next Steps Hi Bill, I agree with you. I would prefer to say with the currently described approach in the document absent strong objections. We may gain some more implementation experience in the next few months and could also reach out to the XMPP guys who had expressed interest in this work instead of changing the core design. Ciao Hannes On Jan 24, 2012, at 9:10 AM, William Mills wrote: > I've been thinking about this quite a bit, and Tim's rebuke to me privately that I really should think about JSON seriously before dismissing the idea because HTTP really is harder to parse than I think it is struck home. > > I'm still stuck on the fact that I think the HTTP we have to parse in the client for the mechanism to work is all OAuth 2 protocol or defined in the mechanims (discovery) so it's more limited. On the server side it's very limited, only enough to figure out the discovery. So I don't think the HTTP here is that scary. The actual HTTP we have to parse for the mechanism to work on the server side is mimimal, and well defined. Am I wrong? > > SO.... I'm trying to figure out how this would work and what we'd need to do in order to make JSON work instead of HTTP as the authentication message format. My assumptions are: > > - We're passing the Auth header in to a library, the SASL mechanism itself doesn't need to parse it. > > We need to support right now for the profiles I know about: > > - The user name and host name for discovery > - The port number for things like MAC authentication > - the Authorization header payload > - discovery information for return to the client > > It's possible we'll also need to pass in: > > - The HTTP POST payload for profiles that require it (though I was assuming GET only initially) > - Something else I'm forgetting about... or for extension flexibility? > > In the end I'm presuming we're passing all the real HTTP into a library that will understand it anyway (which is how my initial implementation is working) so we don't need to dive down into the header and POST body payload in the JSON. If this is right then the JSON doesn't look that hard, but then again if what I have above is correct then we're not talking about a general use HTTP parser either. > > The OAuth 1.0a library I was playing with for this consumes and gives back the entire Auth header, but I don't know if that design pattern is common. > > Where do we go from here? > > -bill > > > > > > From: William Mills < wmills@yahoo-inc.com > > To: Tim Showalter < timshow@yahoo-inc.com >; Russ Allbery < rra@stanford.edu > > Cc: " kitten@ietf.org " < kitten@ietf.org > > Sent: Thursday, January 5, 2012 4:01 PM > Subject: Re: [kitten] SASL OAuth: Next Steps > > Yeah, I really hate this. > > There's stuff in the MAC token spec for example that requires knowing the URL path, fragments, hostname, etc., and so we have to include every element form HTTP that might be required for any OAuth (HTTP based itself) authorization scheme. This means we have to write an entire mapping grammar for an entire HTTP payload into JSON. > > While I agree that HTTP is non-trivial to parse, I don't think it's compelling enough for me to like the change to JSON because there are enough HTTP parsing libraries out there that an implementer should not have to do their own, they should pull one in. > > As I said before, designing this in a vacuum HTTP is far down the list, but I think in light of the fact that we're bridging from something that *is* HTTP it is less complex overall to stay consistent. > > > -bill > > From: Tim Showalter < timshow@yahoo-inc.com > > To: Russ Allbery < rra@stanford.edu > > Cc: " kitten@ietf.org " < kitten@ietf.org > > Sent: Thursday, January 5, 2012 1:38 PM > Subject: Re: [kitten] SASL OAuth: Next Steps > > On 1/4/12 6:34 PM, Russ Allbery wrote: > > Chris Newman< chris.newman@oracle.com > writes: > >> Having a SASL parser call out to a header parser would be poor security > >> design, because every line of code is an additional potential security > >> vulnerability (especially prior to authentication) and a lot of code is > >> needed for a 100% correct header parser. So I think it's actually > >> important for a SASL mechanism to not accept arbitrary header syntax. > > > > Based on my experience writing netnews implementations, which use RFC 5322 > > header field syntax very akin to the HTTP header field syntax, I > > completely concur with Chris's reaction. The header field syntax is > > surprisingly complex, particularly in the presence of encoding and > > character set issues, and most implementors do not implement it properly. > > I'm really sorry to hear that -- I suspect you're right, and I don't like it. I think trying to constrain JSON and define the mappings is going to be a lot of work. > > Is there a simple way to specify a general mapping? Or are we going to have to do this on a per-header basis? > > Tim > _______________________________________________ > 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 > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --========GMXBoundary199671331538398853996 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill, th= at's certainly a good reason for staying with the current design. Do you by= chance know the person(s) at Google who did their implementation.
=20 It might be useful to reach out to them and to get them involved in the wor= k.
=20
=20

=20 =C2=A0

=20
=20

=20 ----- = Urspr=C3=BCngliche Nachricht -----

=20

=20 Von: W= illiam Mills

=20

=20 Gesend= et: 12.03.12 02:36 Uhr

=20

=20 An: Ha= nnes Tschofenig

=20

=20 Betref= f: Re: [kitten] SASL OAuth: Next Steps

=20
=20
=20
=20 Something else that may play in to this is the fact that this basically = isn't that far from what Google has had running for quite a while no on the= ir IMAP service.  Updating those implementations to this would be a mu= ch smaller move than going to JSON.  There's quite a bit of actually r= unning code out there working against Google, so staying near that implemen= taiton probably has value.
=20
=20 -bill
=20
=20
=20
=20
=20
=20
=20
=20 From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
= =20 To: William Mills <wmills@yahoo-inc.com>
=20 Cc: Hannes Tschofen= ig <hannes.tschofenig@gmx.net>; Tim Showalter <timshow@yahoo-inc.c= om>; Russ Allbery <rra@stanford.edu>; "kitten@ietf.org" <kitten= @ietf.org>
=20 Sent: Sunday, March= 11, 2012 3:13 AM
=20 Subject: Re: [kitte= n] SASL OAuth: Next Steps
=20
=20 Hi Bill,
=20
=20 I agree with you. I would prefer to say with the currently described = approach in the document absent strong objections.
=20 We may gain some more implementation experience in the next few month= s and could also reach out to the XMPP guys who had expressed interest in t= his work instead of changing the core design. 
=20
=20 Ciao
=20 Hannes
=20
=20 On Jan 24, 2012, at 9:10 AM, William Mills wrote:
=20
=20 > I've been thinking about this quite a bit, and Tim's rebuke to m= e privately that I really should think about JSON seriously before dismissi= ng the idea because HTTP really is harder to parse than I think it is struc= k home.
=20 >
=20 > I'm still stuck on the fact that I think the HTTP we have to par= se in the client for the mechanism to work is all OAuth 2 protocol or defin= ed in the mechanims (discovery) so it's more limited.  On the server s= ide it's very limited, only enough to figure out the discovery.  So I = don't think the HTTP here is that scary. The actual HTTP we have to parse f= or the mechanism to work on the server side is mimimal, and well defined.&n= bsp; Am I wrong?
=20 >
=20 > SO.... I'm trying to figure out how this would work and what we'= d need to do in order to make JSON work instead of HTTP as the authenticati= on message format.  My assumptions are:
=20 > 
=20 > -    We're passing the Auth header in to a library, th= e SASL mechanism itself doesn't need to parse it.
=20 >
=20 > We need to support right now for the profiles I know about:
=20 >
=20 > -    The user name and host name for discovery
= =20 > -    The port number for things like MAC authenticatio= n
=20 > -    the Authorization header payload
=20 > -    discovery information for return to the client=20 >
=20 > It's possible we'll also need to pass in:
=20 >
=20 > -    The HTTP POST payload for profiles that require i= t (though I was assuming GET only initially)
=20 > -    Something else I'm forgetting about... or for ext= ension flexibility?
=20 >
=20 > In the end I'm presuming we're passing all the real HTTP into a = library that will understand it anyway (which is how my initial implementat= ion is working) so we don't need to dive down into the header and POST body= payload in the JSON. If this is right then the JSON doesn't look that hard= , but then again if what I have above is correct then we're not talking abo= ut a general use HTTP parser either.
=20 >
=20 > The OAuth 1.0a library I was playing with for this consumes and = gives back the entire Auth header, but I don't know if that design pattern = is common.
=20 >
=20 > Where do we go from here?
=20 >
=20 > -bill
=20 >
=20 >
=20 >
=20 >
=20 >
=20 > From: William Mills <= wmills@yahoo-inc.com>
=20 > To: Tim Showalter <t= imshow@yahoo-inc.com>; Russ Allbery <rra@stanford.edu>
=20 > Cc: "kitten@ietf.org" <= ;kitten@ietf.org>
=20 > Sent: Thursday, January 5, 2012 4:01 PM
=20 > Subject: Re: [kitten] SASL OAuth: Next Steps
=20 >
=20 > Yeah, I really hate this.
=20 >
=20 > There's stuff in the MAC token spec for example that requires kn= owing the URL path, fragments, hostname, etc., and so we have to include ev= ery element form HTTP that might be required for any OAuth (HTTP based itse= lf) authorization scheme.  This means we have to write an entire mappi= ng grammar for an entire HTTP payload into JSON.
=20 >
=20 > While I agree that HTTP is non-trivial to parse, I don't think i= t's compelling enough for me to like the change to JSON because there are e= nough HTTP parsing libraries out there that an implementer should not have = to do their own, they should pull one in.
=20 >
=20 > As I said before, designing this in a vacuum HTTP is far down th= e list, but I think in light of the fact that we're bridging from something= that *is* HTTP it is less complex overall to stay consistent.
=20 >
=20 >
=20 > -bill
=20 >
=20 > From: Tim Showalter <timshow@yahoo-inc.com>
=20 > To: Russ Allbery <rra@sta= nford.edu>
=20 > Cc: "kitten@ietf.org" <= ;kitten@ietf.org>
=20 > Sent: Thursday, January 5, 2012 1:38 PM
=20 > Subject: Re: [kitten] SASL OAuth: Next Steps
=20 >
=20 > On 1/4/12 6:34 PM, Russ Allbery wrote:
=20 > > Chris Newman<= chris.newman@oracle.com>  writes:
=20 > >> Having a SASL parser call out to a header parser would = be poor security
=20 > >> design, because every line of code is an additional pot= ential security
=20 > >> vulnerability (especially prior to authentication) and = a lot of code is
=20 > >> needed for a 100% correct header parser. So I think it'= s actually
=20 > >> important for a SASL mechanism to not accept arbitrary = header syntax.
=20 > >
=20 > > Based on my experience writing netnews implementations, whi= ch use RFC 5322
=20 > > header field syntax very akin to the HTTP header field synt= ax, I
=20 > > completely concur with Chris's reaction.  The header f= ield syntax is
=20 > > surprisingly complex, particularly in the presence of encod= ing and
=20 > > character set issues, and most implementors do not implemen= t it properly.
=20 >
=20 > I'm really sorry to hear that -- I suspect you're right, and I d= on't like it.  I think trying to constrain JSON and define the mapping= s is going to be a lot of work.
=20 >
=20 > Is there a simple way to specify a general mapping?  Or are= we going to have to do this on a per-header basis?
=20 >
=20 > Tim
=20 > _______________________________________________
=20 > Kitten mailing list
=20 > Kitten@ietf.org
=20 > https://www.ietf.org/mailman/listinfo/kitten
=20 >
=20 >
=20 >
=20 > _______________________________________________
=20 > Kitten mailing list
=20 > Kitten@ietf.org
=20 > https://www.ietf.org/mailman/listinfo/kitten
=20 >
=20 >
=20 > _______________________________________________
=20 > Kitten mailing list
=20 > Kitten@ietf.org
=20 > https://www.ietf.org/mailman/listinfo/kitten
=20
=20
=20 =C2=A0
=20
=20
=20
=20
=20
=20

=20
=20 =C2=A0

=20 --========GMXBoundary199671331538398853996-- From wmills@yahoo-inc.com Mon Mar 12 08:45:05 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 64A1021E802A for ; Mon, 12 Mar 2012 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHlevBYx8GTs for ; Mon, 12 Mar 2012 08:45:03 -0700 (PDT) Received: from nm7.bullet.mail.sp2.yahoo.com (nm7.bullet.mail.sp2.yahoo.com [98.139.91.77]) by ietfa.amsl.com (Postfix) with SMTP id E348421E801E for ; Mon, 12 Mar 2012 08:45:03 -0700 (PDT) Received: from [98.139.91.64] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 15:45:03 -0000 Received: from [98.139.91.12] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 15:45:03 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 12 Mar 2012 15:45:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 827535.41242.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 18796 invoked by uid 60001); 12 Mar 2012 15:45:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331567103; bh=xPrcZ8tyxtDoix06CWtvkMadbxlJkEo5pAHIDId5tp8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M1UWYv1cobEB4UISBmYuUeV7fHsJUfYdTYpLVZSNwJSVv0fzXo7E6BdVghwVdk0QEHCEiQAADr6EW8KrnCRz99uoFyqc8X+Cr3tP7LzmC8qCo+TqjTg1L10otRwdM1w/nJdgxGMVKmqjI/NxjAFZinCCRTHtUeMK57YOf85gQpE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iiRFQPDhIXSd6e8uHLvzCyTyrQTc0q/TZisCh55y4dzhJyrS5ffOdH410B/d3WkUBdz2H3emrNEt8ARvs6GLYiqD6l228bHq1avQia+Ehunz0SCZ3ItFQRMXRTmiwKRj4o9yRztNStSvW4XVj4HoUEPFt6JTjnmWbKMHAEsGaEM=; X-YMail-OSG: iE4GPGUVM1lnHzXXuzbfUoFOhzhAIOcSXVa6tfIQpxPW8HG b5CnCidOF7GK87SCpu7iVjRoZGSyeX0NI9XMZVt0ndCTMlhiz8syAk6C_5hh EwqMrCiv_8oFpWkvbJ41t3.hd2CHiTvUU8OwucOvrk3lOfNk2X3opNjZbLba ye782KAJS3E2hQo_egTZ1mXxCN5TkGZLYRlYilIjUGt7R6v6tHqmvmiVrucD WNruzrbUjhGE_9SW9DH1bgONupYwgSN_2jOCRPaLqt6eMEQJqhs0Wi3mr7Gy nrjzrvMDan6scBVeR0grJJ.Djga9.o7JXRNINqrIPNLOZtub3_zSr55tsDdj QdGl0P_dpQMQ_fvPAEH.X9Kird8NC_fdOtNqzA30.pDID4HcKyUPo.RH0BZT zBLdfnbV_NCt_4EBcx1KRNPieBU31hXD2gS8gMCCuzP2RlzwhkvVO_uU8j3v gsKeVG5WRQ2CGew.x546691zoboAztgiB2dYFjmE1slidwgoj6pc53kiVdZh r2LoK15GFg.8Vqq8D4p0k_eE94mHw Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Mon, 12 Mar 2012 08:45:02 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <20120312074638.199670@gmx.net> Message-ID: <1331567102.82103.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 12 Mar 2012 08:45:02 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <20120312074638.199670@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-1913506449-1331567102=:82103" Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:45:05 -0000 ---551393103-1913506449-1331567102=:82103 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I exchanged e-mail with them at the beginning of this process, but they wer= e happy enough with what they had.=A0 http://sites.google.com/site/oauthgoo= g/Home/oauthimap is the link to the definition.=A0 We can see if they want = in again, but I think we're close to what they originally had with much mor= e capability/flexibility.=0A=0A-bill=0A=0A=0A=0A=0A>_______________________= _________=0A> From: Hannes Tschofenig =0A>To: Wi= lliam Mills =0A>Cc: Tim Showalter ; Russ Allbery ; kitten@ietf.org =0A>Sent: Monday, M= arch 12, 2012 12:46 AM=0A>Subject: Re: [kitten] SASL OAuth: Next Steps=0A> = =0A>=0A>Bill, that's certainly a good reason for staying with the current d= esign. Do you by chance know the person(s) at Google who did their implemen= tation.=0A>It might be useful to reach out to them and to get them involved= in the work.=0A>=0A>=0A>=A0=0A>----- Urspr=FCngliche Nachricht -----=0A>>V= on: William Mills=0A>>Gesendet: 12.03.12 02:36 Uhr=0A>>An: Hannes Tschofeni= g=0A>>Betreff: Re: [kitten] SASL OAuth: Next Steps=0A>>=0A>>Something else = that may play in to this is the fact that this basically isn't that far fro= m what Google has had running for quite a while no on their IMAP service.= =A0 Updating those implementations to this would be a much smaller move tha= n going to JSON.=A0 There's quite a bit of actually running code out there = working against Google, so staying near that implementaiton probably has va= lue.=0A>>=0A>>-bill=0A>>=0A>>=0A>>=0A>>=0A>>_______________________________= _=0A>> From: Hannes Tschofenig =0A>>To: William = Mills =0A>>Cc: Hannes Tschofenig ; Tim Showalter ; Russ Allbery ; "kitten@ietf.org" =0A>>Sent: Sunday, March 11, 2012 = 3:13 AM=0A>>Subject: Re: [kitten] SASL OAuth: Next Steps=0A>>Hi Bill,=0A>>= =0A>>I agree with you. I would prefer to say with the currently described a= pproach in the document absent strong objections.=0A>>We may gain some more= implementation experience in the next few months and could also reach out = to the XMPP guys who had expressed interest in this work instead of changin= g the core design.=A0=0A>>=0A>>Ciao=0A>>Hannes=0A>>=0A>>On Jan 24, 2012, at= 9:10 AM, William Mills wrote:=0A>>=0A>>> I've been thinking about this qui= te a bit, and Tim's rebuke to me privately that I really should think about= JSON seriously before dismissing the idea because HTTP really is harder to= parse than I think it is struck home.=0A>>>=0A>>> I'm still stuck on the f= act that I think the HTTP we have to parse in the client for the mechanism = to work is all OAuth 2 protocol or defined in the mechanims (discovery) so = it's more limited.=A0 On the server side it's very limited, only enough to = figure out the discovery.=A0 So I don't think the HTTP here is that scary. = The actual HTTP we have to parse for the mechanism to work on the server si= de is mimimal, and well defined.=A0 Am I wrong?=0A>>>=0A>>> SO.... I'm tryi= ng to figure out how this would work and what we'd need to do in order to m= ake JSON work instead of HTTP as the authentication message format.=A0 My a= ssumptions are:=0A>>>=A0=0A>>> -=A0 =A0 We're passing the Auth header in to= a library, the SASL mechanism itself doesn't need to parse it.=0A>>>=0A>>>= We need to support right now for the profiles I know about:=0A>>>=0A>>> -= =A0 =A0 The user name and host name for discovery=0A>>> -=A0 =A0 The port n= umber for things like MAC authentication=0A>>> -=A0 =A0 the Authorization h= eader payload=0A>>> -=A0 =A0 discovery information for return to the client= =0A>>>=0A>>> It's possible we'll also need to pass in:=0A>>>=0A>>> -=A0 =A0= The HTTP POST payload for profiles that require it (though I was assuming = GET only initially)=0A>>> -=A0 =A0 Something else I'm forgetting about... o= r for extension flexibility?=0A>>>=0A>>> In the end I'm presuming we're pas= sing all the real HTTP into a library that will understand it anyway (which= is how my initial implementation is working) so we don't need to dive down= into the header and POST body payload in the JSON. If this is right then t= he JSON doesn't look that hard, but then again if what I have above is corr= ect then we're not talking about a general use HTTP parser either.=0A>>>=0A= >>> The OAuth 1.0a library I was playing with for this consumes and gives b= ack the entire Auth header, but I don't know if that design pattern is comm= on.=0A>>>=0A>>> Where do we go from here?=0A>>>=0A>>> -bill=0A>>>=0A>>>=0A>= >>=0A>>>=0A>>>=0A>>> From: William Mills =0A>>> To: T= im Showalter ; Russ Allbery =0A>>>= Cc: "kitten@ietf.org" =0A>>> Sent: Thursday, January 5, 2= 012 4:01 PM=0A>>> Subject: Re: [kitten] SASL OAuth: Next Steps=0A>>>=0A>>> = Yeah, I really hate this.=0A>>>=0A>>> There's stuff in the MAC token spec f= or example that requires knowing the URL path, fragments, hostname, etc., a= nd so we have to include every element form HTTP that might be required for= any OAuth (HTTP based itself) authorization scheme.=A0 This means we have = to write an entire mapping grammar for an entire HTTP payload into JSON.=0A= >>>=0A>>> While I agree that HTTP is non-trivial to parse, I don't think it= 's compelling enough for me to like the change to JSON because there are en= ough HTTP parsing libraries out there that an implementer should not have t= o do their own, they should pull one in.=0A>>>=0A>>> As I said before, desi= gning this in a vacuum HTTP is far down the list, but I think in light of t= he fact that we're bridging from something that *is* HTTP it is less comple= x overall to stay consistent.=0A>>>=0A>>>=0A>>> -bill=0A>>>=0A>>> From: Tim= Showalter =0A>>> To: Russ Allbery =0A>>> Cc: "kitten@ietf.org" =0A>>> Sent: Thursday, Janua= ry 5, 2012 1:38 PM=0A>>> Subject: Re: [kitten] SASL OAuth: Next Steps=0A>>>= =0A>>> On 1/4/12 6:34 PM, Russ Allbery wrote:=0A>>> > Chris Newman=A0 writes:=0A>>> >> Having a SASL parser call out to a hea= der parser would be poor security=0A>>> >> design, because every line of co= de is an additional potential security=0A>>> >> vulnerability (especially p= rior to authentication) and a lot of code is=0A>>> >> needed for a 100% cor= rect header parser. So I think it's actually=0A>>> >> important for a SASL = mechanism to not accept arbitrary header syntax.=0A>>> >=0A>>> > Based on m= y experience writing netnews implementations, which use RFC 5322=0A>>> > he= ader field syntax very akin to the HTTP header field syntax, I=0A>>> > comp= letely concur with Chris's reaction.=A0 The header field syntax is=0A>>> > = surprisingly complex, particularly in the presence of encoding and=0A>>> > = character set issues, and most implementors do not implement it properly.= =0A>>>=0A>>> I'm really sorry to hear that -- I suspect you're right, and I= don't like it.=A0 I think trying to constrain JSON and define the mappings= is going to be a lot of work.=0A>>>=0A>>> Is there a simple way to specify= a general mapping?=A0 Or are we going to have to do this on a per-header b= asis?=0A>>>=0A>>> Tim=0A>>> _______________________________________________= =0A>>> Kitten mailing list=0A>>> Kitten@ietf.org=0A>>> https://www.ietf.org= /mailman/listinfo/kitten=0A>>>=0A>>>=0A>>>=0A>>> __________________________= _____________________=0A>>> Kitten mailing list=0A>>> Kitten@ietf.org=0A>>>= https://www.ietf.org/mailman/listinfo/kitten=0A>>>=0A>>>=0A>>> ___________= ____________________________________=0A>>> Kitten mailing list=0A>>> Kitten= @ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/kitten=0A>>=0A>>=0A>>= =A0=0A>=0A>=A0 =0A>=0A> ---551393103-1913506449-1331567102=:82103 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I exchanged e-mail with them at the beginning of this process, but they w= ere happy enough with what they had.  http://sites.google.com/site/oau= thgoog/Home/oauthimap is the link to the definition.  We can see if th= ey want in again, but I think we're close to what they originally had with = much more capability/flexibility.

<= div>-bill

=
From: Hannes Tschofenig <Hannes.= Tschofenig@gmx.net>
To:= William Mills <wmills@yahoo-inc.com>
Cc: Tim Showalter <timshow@yahoo-inc.com>; = Russ Allbery <rra@stanford.edu>; kitten@ietf.org
Sent: Monday, March 12, 2012 12:46 AM Subject: Re: [kitten] SA= SL OAuth: Next Steps

=0A
Bill, tha= t's certainly a good reason for staying with the current design. Do you by = chance know the person(s) at Google who did their implementation.
=0AIt= might be useful to reach out to them and to get them involved in the work.=
=0A
=0A
=0A=09 
= =0A
= =0A=09
=0A=09=09----- Urspr=FCngliche Nac= hricht -----
=0A=09
=0A=09=09Von: William Mills
=0A=09
=0A=09=09Gesendet: 12.03.12 02:36 Uhr
=0A= =09
=0A=09=09An: Hannes Tschofenig<= /span>
=0A=09
=0A=09=09Betreff: Re: = [kitten] SASL OAuth: Next Steps
=0A=09
=0A=09
= =0A=09=09
=0A=09=09=09= Something else that may play in to this is the fact that this basically isn= 't that far from what Google has had running for quite a while no on their = IMAP service.  Updating those implementations to this would be a much = smaller move than going to JSON.  There's quite a bit of actually runn= ing code out there working against Google, so staying near that implementai= ton probably has value.
=0A=09=09=09
=0A=09=09=09-bill
=0A=09= =09=09
=0A=09=09=09
=0A=09=09=09
=0A=09=09=09=09
=0A=09=09=09=09=09
=0A=09=09=09=09=09=09
=0A=09=09=09= =09=09=09=09
=0A=09=09=09=09=09=09=09From: Hannes Tscho= fenig <hannes.tschofenig@gmx.net>
=0A=09=09=09=09=09=09=09To: William Mills <wmills@ya= hoo-inc.com>
=0A=09=09=09=09=09=09=09Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; T= im Showalter <timshow@yahoo-inc.com>; Russ Allbery <rra@stanford.e= du>; "kitten@ietf.org" <kitten@ietf.org>
=0A=09=09=09=09=09=09= =09Sent: Sunday, March 11, = 2012 3:13 AM
=0A=09=09=09=09=09=09=09Subject: Re: [kitten] SASL OAuth: Next Steps
=0A= =09=09=09=09=09=09
=0A=09=09=09=09=09=09Hi Bill,
=0A=09=09=09=09=09= =09
=0A=09=09=09=09=09=09I agree with you. I would prefer to say with t= he currently described approach in the document absent strong objections. =0A=09=09=09=09=09=09We may gain some more implementation experience in = the next few months and could also reach out to the XMPP guys who had expre= ssed interest in this work instead of changing the core design. 
= =0A=09=09=09=09=09=09
=0A=09=09=09=09=09=09Ciao
=0A=09=09=09=09=09= =09Hannes
=0A=09=09=09=09=09=09
=0A=09=09=09=09=09=09On Jan 24, 201= 2, at 9:10 AM, William Mills wrote:
=0A=09=09=09=09=09=09
=0A=09=09= =09=09=09=09> I've been thinking about this quite a bit, and Tim's rebuk= e to me privately that I really should think about JSON seriously before di= smissing the idea because HTTP really is harder to parse than I think it is= struck home.
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09> I= 'm still stuck on the fact that I think the HTTP we have to parse in the cl= ient for the mechanism to work is all OAuth 2 protocol or defined in the me= chanims (discovery) so it's more limited.  On the server side it's ver= y limited, only enough to figure out the discovery.  So I don't think = the HTTP here is that scary. The actual HTTP we have to parse for the mecha= nism to work on the server side is mimimal, and well defined.  Am I wr= ong?
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09> SO.... I'm= trying to figure out how this would work and what we'd need to do in order= to make JSON work instead of HTTP as the authentication message format.&nb= sp; My assumptions are:
=0A=09=09=09=09=09=09> 
=0A=09=09= =09=09=09=09> -    We're passing the Auth header in to a libra= ry, the SASL mechanism itself doesn't need to parse it.
=0A=09=09=09=09= =09=09>
=0A=09=09=09=09=09=09> We need to support right now for t= he profiles I know about:
=0A=09=09=09=09=09=09>
=0A=09=09=09=09= =09=09> -    The user name and host name for discovery
=0A= =09=09=09=09=09=09> -    The port number for things like MAC a= uthentication
=0A=09=09=09=09=09=09> -    the Authorizatio= n header payload
=0A=09=09=09=09=09=09> -    discovery inf= ormation for return to the client
=0A=09=09=09=09=09=09>
=0A=09= =09=09=09=09=09> It's possible we'll also need to pass in:
=0A=09=09= =09=09=09=09>
=0A=09=09=09=09=09=09> -    The HTTP POST= payload for profiles that require it (though I was assuming GET only initi= ally)
=0A=09=09=09=09=09=09> -    Something else I'm forge= tting about... or for extension flexibility?
=0A=09=09=09=09=09=09><= br> =0A=09=09=09=09=09=09> In the end I'm presuming we're passing all th= e real HTTP into a library that will understand it anyway (which is how my = initial implementation is working) so we don't need to dive down into the h= eader and POST body payload in the JSON. If this is right then the JSON doe= sn't look that hard, but then again if what I have above is correct then we= 're not talking about a general use HTTP parser either.
=0A=09=09=09=09= =09=09>
=0A=09=09=09=09=09=09> The OAuth 1.0a library I was playi= ng with for this consumes and gives back the entire Auth header, but I don'= t know if that design pattern is common.
=0A=09=09=09=09=09=09>
= =0A=09=09=09=09=09=09> Where do we go from here?
=0A=09=09=09=09=09= =09>
=0A=09=09=09=09=09=09> -bill
=0A=09=09=09=09=09=09> =0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09>
=0A=09=09=09= =09=09=09>
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09> F= rom: William Mills <wmills@yahoo= -inc.com>
=0A=09=09=09=09=09=09> To: Tim Showalter <timshow@yahoo-inc.com>; Russ All= bery <rra@stanford.edu>
=0A= =09=09=09=09=09=09> Cc: "kitten@ietf.org" <kitten@ietf.org>
=0A=09=09= =09=09=09=09> Sent: Thursday, January 5, 2012 4:01 PM
=0A=09=09=09= =09=09=09> Subject: Re: [kitten] SASL OAuth: Next Steps
=0A=09=09=09= =09=09=09>
=0A=09=09=09=09=09=09> Yeah, I really hate this.
= =0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09> There's stuff in th= e MAC token spec for example that requires knowing the URL path, fragments,= hostname, etc., and so we have to include every element form HTTP that mig= ht be required for any OAuth (HTTP based itself) authorization scheme. = ; This means we have to write an entire mapping grammar for an entire HTTP = payload into JSON.
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09&= gt; While I agree that HTTP is non-trivial to parse, I don't think it's com= pelling enough for me to like the change to JSON because there are enough H= TTP parsing libraries out there that an implementer should not have to do t= heir own, they should pull one in.
=0A=09=09=09=09=09=09>
=0A=09= =09=09=09=09=09> As I said before, designing this in a vacuum HTTP is fa= r down the list, but I think in light of the fact that we're bridging from = something that *is* HTTP it is less complex overall to stay consistent.
= =0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09>
=0A=09=09=09= =09=09=09> -bill
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09= > From: Tim Showalter <tims= how@yahoo-inc.com>
=0A=09=09=09=09=09=09> To: Russ Allbery &l= t;rra@stanford.edu>
=0A=09=09=09= =09=09=09> Cc: "kitten@ietf.org" <<= a rel=3D"nofollow" ymailto=3D"mailto:kitten@ietf.org" target=3D"_blank" hre= f=3D"mailto:kitten@ietf.org">kitten@ietf.org>
=0A=09=09=09=09=09= =09> Sent: Thursday, January 5, 2012 1:38 PM
=0A=09=09=09=09=09=09&g= t; Subject: Re: [kitten] SASL OAuth: Next Steps
=0A=09=09=09=09=09=09&g= t;
=0A=09=09=09=09=09=09> On 1/4/12 6:34 PM, Russ Allbery wrote:
= =0A=09=09=09=09=09=09> > Chris Newman<chris.newman@oracle.com>  writes:
=0A=09= =09=09=09=09=09> >> Having a SASL parser call out to a header pars= er would be poor security
=0A=09=09=09=09=09=09> >> design, be= cause every line of code is an additional potential security
=0A=09=09= =09=09=09=09> >> vulnerability (especially prior to authentication= ) and a lot of code is
=0A=09=09=09=09=09=09> >> needed for a = 100% correct header parser. So I think it's actually
=0A=09=09=09=09=09= =09> >> important for a SASL mechanism to not accept arbitrary hea= der syntax.
=0A=09=09=09=09=09=09> >
=0A=09=09=09=09=09=09>= ; > Based on my experience writing netnews implementations, which use RF= C 5322
=0A=09=09=09=09=09=09> > header field syntax very akin to = the HTTP header field syntax, I
=0A=09=09=09=09=09=09> > complete= ly concur with Chris's reaction.  The header field syntax is
=0A= =09=09=09=09=09=09> > surprisingly complex, particularly in the prese= nce of encoding and
=0A=09=09=09=09=09=09> > character set issues= , and most implementors do not implement it properly.
=0A=09=09=09=09= =09=09>
=0A=09=09=09=09=09=09> I'm really sorry to hear that -- I= suspect you're right, and I don't like it.  I think trying to constra= in JSON and define the mappings is going to be a lot of work.
=0A=09=09= =09=09=09=09>
=0A=09=09=09=09=09=09> Is there a simple way to spe= cify a general mapping?  Or are we going to have to do this on a per-h= eader basis?
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09> Ti= m
=0A=09=09=09=09=09=09> ___________________________________________= ____
=0A=09=09=09=09=09=09> Kitten mailing list
=0A=09=09=09=09= =09=09> Kitten@ietf.org
=0A=09=09= =09=09=09=09> https://www.ietf.org/mailman/listinfo/kit= ten
=0A=09=09=09=09=09=09>
=0A=09=09=09=09=09=09>
=0A= =09=09=09=09=09=09>
=0A=09=09=09=09=09=09> ______________________= _________________________
=0A=09=09=09=09=09=09> Kitten mailing list=
=0A=09=09=09=09=09=09> Kitten@ietf.or= g
=0A=09=09=09=09=09=09> https://www.ietf.org/m= ailman/listinfo/kitten
=0A=09=09=09=09=09=09>
=0A=09=09=09= =09=09=09>
=0A=09=09=09=09=09=09> _______________________________= ________________
=0A=09=09=09=09=09=09> Kitten mailing list
=0A= =09=09=09=09=09=09> Kitten@ietf.org =0A=09=09=09=09=09=09> https://www.ietf.org/mailman/l= istinfo/kitten
=0A=09=09=09=09=09=09
=0A=09=09=09=09=09=09
= =0A=09=09=09=09=09=09 
=0A=09=09=09=09
=0A=09=09=09
= =0A=09=09
=0A=09
=0A
=0A
=0A=09
=0A=09 
=0A=0A

<= br>
---551393103-1913506449-1331567102=:82103-- From hartmans@painless-security.com Mon Mar 12 16:38:16 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 BE55321E8224; Mon, 12 Mar 2012 16:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.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 1IyPKOXqqhYg; Mon, 12 Mar 2012 16:38:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D244021E8222; Mon, 12 Mar 2012 16:38:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3162C2024B; Mon, 12 Mar 2012 19:37:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C6FF4767; Mon, 12 Mar 2012 19:38:05 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org,abfab@ietf.org Date: Mon, 12 Mar 2012 19:38:05 -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 Subject: [kitten] URN prefixes for draft-ietf-abfab-gss-eap-naming 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, 12 Mar 2012 23:38:16 -0000 So last time around I said I'd put together a straw man for the name attribute prefixes for the GSS EAP mechanism in ABFAB and things like SAML EC in KITTEN. I asked for input and got suggestions like "use OIDs instead," after we spent months deciding to use URIs. I'm proposing things like urn:ietf:params:gss:fed-saml-assertion (for a saml assertion in the federated context) Please see section 5 and 6 of the most recent draft-ietf-abfab-gss-eap-naming. Comments welcome. From shawn.emery@oracle.com Mon Mar 12 23:12:33 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 52A3D21F88D3 for ; Mon, 12 Mar 2012 23:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[AWL=0.800, 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 OJAtW10fmpzz for ; Mon, 12 Mar 2012 23:12:31 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8A21F88D4 for ; Mon, 12 Mar 2012 23:12:31 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2D6CUuL029082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Mar 2012 06:12:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2D6CUQ7014778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 06:12:30 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2D6CTlm021572 for ; Tue, 13 Mar 2012 01:12:29 -0500 Received: from [10.159.3.253] (/10.159.3.253) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Mar 2012 23:12:29 -0700 Message-ID: <4F5EE527.3080803@oracle.com> Date: Tue, 13 Mar 2012 00:11:51 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" References: <4EB1ABDA.2060602@oracle.com> In-Reply-To: <4EB1ABDA.2060602@oracle.com> X-Forwarded-Message-Id: <4EB1ABDA.2060602@oracle.com> Content-Type: multipart/alternative; boundary="------------060204050905010305010504" X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020204.4F5EE54F.0030,ss=1,re=0.000,fgs=0 Subject: [kitten] IETF 83 Agenda 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, 13 Mar 2012 06:12:33 -0000 This is a multi-part message in MIME format. --------------060204050905010305010504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is the draft agenda for the kitten session at IETF 83: http://www.ietf.org/proceedings/83/agenda/agenda-83-kitten.txt Please provide feed-back/additions no later than 3/19/12 16:00 PDT. Shawn - kitten co-chair -- --------------060204050905010305010504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Here is the draft agenda for the kitten session at IETF 83:

http://www.ietf.org/proceedings/83/agenda/agenda-83-kitten.txt

Please provide feed-back/additions no later than 3/19/12 16:00 PDT.

Shawn - kitten co-chair
--
--------------060204050905010305010504-- From nico@cryptonector.com Mon Mar 12 23:53:00 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 6E39521F88BF for ; Mon, 12 Mar 2012 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 53Juf8pReHY7 for ; Mon, 12 Mar 2012 23:52:56 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 841DB21F88BB for ; Mon, 12 Mar 2012 23:52:56 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 55738B8058 for ; Mon, 12 Mar 2012 23:52:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=j3DyOzJieyH0yjGXMel6UwVi0bS/G/wzYOonxSYJxPft Q5/o0lhSm3i5fDpZ+C2NXzW3RAAKvJxH/suuCsSmVatsKiocNCsJSJRdB6VoWy7w IeBMkYW8TerJu8Z2qeUtvivtlSKv8T0eqnF2DJDSoyUIj/2RFENcB3sDSLQKU8g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=YOFJxovuP+fDFpo5QiVx+7HbXNY=; b=wk34br4YghF OL3+RsaKye93xnAnbDkl032FQGRzmw+DyHC8Dc/l9UvVMwIZ9xsumKEags9/YdyC NA0t+3XfLl3NiRAFGCfdLujxxfE61rboySf4quSwjchItgvYvnuPuhhArrr+Ae97 WCRJZKt40GI+KLH7uzIjIPl+RVr1F+XI= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 43D3AB8057 for ; Mon, 12 Mar 2012 23:52:56 -0700 (PDT) Received: by dakl33 with SMTP id l33so397729dak.31 for ; Mon, 12 Mar 2012 23:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.102 with SMTP id ot6mr5062047pbb.76.1331621575899; Mon, 12 Mar 2012 23:52:55 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Mon, 12 Mar 2012 23:52:55 -0700 (PDT) In-Reply-To: References: <4F58BF4B.7050009@cs.tcd.ie> <4F5D1CE3.7000301@mnt.se> Date: Tue, 13 Mar 2012 01:52:55 -0500 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 13 Mar 2012 06:53:00 -0000 I spoke to Sam today about this. On Sun, Mar 11, 2012 at 6:30 PM, Nico Williams wrot= e: >> Actually I think its not. You're supposed to read it as >> >> [ ] > > No, more like: I was wrong, it's really: There is one prefix. The prefix dictates how to interpret the rest of the attribute name (e.g., whether it too consists of a prefix and an attribute name). This is simple enough to not warrant an ABNF. In theory we could have chains of prefixes, and probably will. >>> - I don't really get the 2nd last paragraph of section 6, what's >>> that saying? >> >> Nico, I think you wrote that one... can you elaborate? > > Although I do not recall writing that I can explain the text, I think, > though I'm not sure that I can write much better text. =C2=A0This paragra= ph > needs to be read in conjunction with section 5, but it belongs in > section 6. There are two particularly confusing aspects of this paragraph: the fact that the word "prefix" is not used anywhere else in the entire document, and the phrase "sufficient prefix" -- sufficient for what? It's clear that prefix refers to the left half of the first space character, if any. I believe the "sufficient" modifier here means "sufficient to identify the context", where "context" is described earlier. Sam and I talked about this and we agree on one possible substantive change to the I-D: to reserve "local" attribute names (those with neither spaces nor colons). Specifically we'd reserve attribute names with '@' in them. The reason for this change would be that simple, non-URN attribute names would greatly help write protable and generic GSS applications, but we don't want to preclude local attributes either. I also very much wish that the I-D had some concrete examples of what these attributes might look like and what their semantics might be. We do have a list of such possible attributes. Sam, however, does not want to spend time adding any such to this draft, preferring that we add them to a new I-D. For your benefit, here are some possible attributes and prefixes: - a prefix denoting "validated by some locally-desired policy as suitable for authorization decisions" (though the policy may not be local, and the entity doing the validation may not be either) - a prefix denoting "the name of the issuer of the attribute" (This is useful for applications that implement policies of their own.) - a prefix denoting "the name of the entity that enforced policy for this attribute" - attributes for a variety of things (e.g., e-mail address, but also probably many of the items delivered in the PAC/PAD as discrete attributes) - attributes for things like "trust transit path" - others that I forget right now :) Nico -- From leifj@mnt.se Tue Mar 13 11:40:33 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 F0CF921E8060 for ; Tue, 13 Mar 2012 11:40:32 -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 lk5xG0cQ3y3S for ; Tue, 13 Mar 2012 11:40:31 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7378521E8040 for ; Tue, 13 Mar 2012 11:40:31 -0700 (PDT) Received: from [129.6.252.156] ([129.6.252.156]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2DIeJFd026617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 19:40:24 +0100 (CET) Message-ID: <4F5F9493.60807@mnt.se> Date: Tue, 13 Mar 2012 19:40:19 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nico Williams References: <4F58BF4B.7050009@cs.tcd.ie> <4F5D1CE3.7000301@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12 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, 13 Mar 2012 18:40:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 07:52 AM, Nico Williams wrote: > I spoke to Sam today about this. > > On Sun, Mar 11, 2012 at 6:30 PM, Nico Williams > wrote: >>> Actually I think its not. You're supposed to read it as >>> >>> [ ] >> >> No, more like: > > I was wrong, it's really: > > > > There is one prefix. The prefix dictates how to interpret the rest > of the attribute name (e.g., whether it too consists of a prefix > and an attribute name). This is simple enough to not warrant an > ABNF. Thank you. I was seriously scratching my head there... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9flJMACgkQ8Jx8FtbMZndoqwCdGF2ub6Jp5wmjhYnvyhzJw1b2 v5YAniUc5brJRtoIaep/prvArAOC2rEB =QuHr -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Wed Mar 14 04:02:58 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 6E7A721F873B for ; Wed, 14 Mar 2012 04:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=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 IENu4TTxr+mX for ; Wed, 14 Mar 2012 04:02:57 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F69021F8729 for ; Wed, 14 Mar 2012 04:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1331722975; d=isode.com; s=selector; i=@isode.com; bh=Qf32mzFdgZD0s8ryZVThp1xWLnMFHiUc+F/9W4I2QrI=; 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=gMthAiSuHNQDBiqBwFrk7Ib132dh1oTKrYK2GC//s4/2H0ziIj7BZbgbqx4gVNLBzrZr8C ugpUhwlwREGpfew+DeSmleygeHkgkXtg57vFuTjvpAyGu/KI/6q/uT//AWDmzpYVNdWVwW CLh+R7MC7Wxxik61NFFu47N0YzYXSbM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 14 Mar 2012 11:02:55 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F607AEF.3040209@isode.com> Date: Wed, 14 Mar 2012 11:03:11 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Shawn Emery References: <4EB1ABDA.2060602@oracle.com> <4F5EE527.3080803@oracle.com> In-Reply-To: <4F5EE527.3080803@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060805080409060004080100" Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 83 Agenda 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, 14 Mar 2012 11:02:58 -0000 This is a multi-part message in MIME format. --------------060805080409060004080100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13/03/2012 06:11, Shawn Emery wrote: > > Here is the draft agenda for the kitten session at IETF 83: > > http://www.ietf.org/proceedings/83/agenda/agenda-83-kitten.txt Looks Ok to me. Add SAML-EC? --------------060805080409060004080100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 13/03/2012 06:11, Shawn Emery wrote:

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

http://www.ietf.org/proceedings/83/agenda/agenda-83-kitten.txt
Looks Ok to me. Add SAML-EC?


--------------060805080409060004080100-- From cantor.2@osu.edu Wed Mar 14 06:45:49 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 95D7B21F87D7 for ; Wed, 14 Mar 2012 06:45:49 -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 wodZbkDv+jv7 for ; Wed, 14 Mar 2012 06:45:49 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id E555F21F87C6 for ; Wed, 14 Mar 2012 06:45:46 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2EDjfBR007204; Wed, 14 Mar 2012 09:45:43 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 09:45:35 -0400 From: "Cantor, Scott" To: Alexey Melnikov , Shawn Emery Thread-Topic: [kitten] IETF 83 Agenda Thread-Index: AQHNAOBKXGP+8dj1Y0ekPVaT5C1YY5Zp5WSA///qSIA= Date: Wed, 14 Mar 2012 13:45:33 +0000 Message-ID: In-Reply-To: <4F607AEF.3040209@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-ID: <62DE50FDFD6C7E49A9A9C5262D111A91@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 83 Agenda 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, 14 Mar 2012 13:45:49 -0000 On 3/14/12 7:03 AM, "Alexey Melnikov" wrote: > > Looks Ok to me. Add SAML-EC? I'll send an update noting open issues prior to the session. I may or may not be online for it. -- Scott From leifj@mnt.se Wed Mar 14 08:40:08 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 6C23121F8657 for ; Wed, 14 Mar 2012 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.694, 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 pUwYCTHW-ZaT for ; Wed, 14 Mar 2012 08:40:07 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 3F58C21F8647 for ; Wed, 14 Mar 2012 08:40:07 -0700 (PDT) Received: from [129.6.252.156] ([129.6.252.156]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2EFdv5n006327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 16:40:04 +0100 (CET) Message-ID: <4F60BBCC.2040101@mnt.se> Date: Wed, 14 Mar 2012 16:39:56 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <4EB1ABDA.2060602@oracle.com> <4F5EE527.3080803@oracle.com> In-Reply-To: <4F5EE527.3080803@oracle.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] IETF 83 Agenda 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, 14 Mar 2012 15:40:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 07:11 AM, Shawn Emery wrote: > > Here is the draft agenda for the kitten session at IETF 83: > > http://www.ietf.org/proceedings/83/agenda/agenda-83-kitten.txt > > Please provide feed-back/additions no later than 3/19/12 16:00 > PDT. > > Shawn - kitten co-chair looks ok -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9gu8wACgkQ8Jx8FtbMZnecHQCfcu75OykX6sLZXKpO9n+CGIAR S9IAniBD1zhthQe6FgPqLxh8hF1DSedv =kmOP -----END PGP SIGNATURE----- From nico@cryptonector.com Fri Mar 16 15:04:29 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 6B1E421F85AC for ; Fri, 16 Mar 2012 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 WKms7b+NivxE for ; Fri, 16 Mar 2012 15:04:28 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5221F856D for ; Fri, 16 Mar 2012 15:04:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id A37CE674060 for ; Fri, 16 Mar 2012 15:04:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=H2dP0X3fhpLSRmVq7PC+50/ys5e05sAslELLbdjZDA4b 4oq8Zsgf6y4bAqwUeQAX35Yb7fbZSAsJR3yxwkHpJwM7KIxHfLkBnE1487FHZeXT MubgUVfoXIP0wbZdur+U3nYnRAhecfmvc9216O9Fq/BAEq5UJjg8m/s9coe6s4c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=gf2/ACfBb1a5qiSyOKk9YdgeYDI=; b=y+OPVABxe5q sCweSWYR+lOHBhrfgbk+ykBCyQLM/ktU3ZHXlVpv6+imIFXz87t40H3G5iIv4Xp2 EzWUnymO3+/Dj/I/hHdxqljm9hDDx8cSkeyJ8J+64dTkEcxdiJ5ysgh2jfVzgmSl ieoGqVO9FTT0+cTKTRxsWDWb6J5itqhU= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 920FC674059 for ; Fri, 16 Mar 2012 15:04:16 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so304365pbb.31 for ; Fri, 16 Mar 2012 15:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr17894645pbb.13.1331935456285; Fri, 16 Mar 2012 15:04:16 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 15:04:16 -0700 (PDT) Date: Fri, 16 Mar 2012 17:04:16 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Proposed changes to http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-13 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, 16 Mar 2012 22:04:29 -0000 Sorry for proposing last minute changes. I have three changes to propose, of which only one is substantive: - clarify section 6 to indicate that "primary attribute component" and "prefix" are the same thing - re-write the second to last paragraph of section 6 - reserve a subset of the "local" attribute namespace ("local" attributes are ones with neither colons nor spaces) This is the substantive change. Sam and I believe that it will eventually be desirable to have simple attribute names that are not URNs -- developers and users/sysadmins (to the extent that attribute names leak into user/admin interfaces) will want non-URN, user-friendly, portable and generic attribute names. Sam proposes to reserve local attribute names that have an at-sign. This change requires confirmation on the list, thus this post. The proposed changes are as follows. 1) Clarification of "prefix": If an attribute name contains a space (ASCII 0x20), the first space separates the most significant or primary component of the name from - the remainder. If there is no space, the primary component is the - entire name, otherwise it defines the interpretation of the remainder - of the name.s + the remainder. We may refer to the primary component of the + attribute name as the attribute name's "prefix". If there is no + space, the primary component is the entire name, otherwise it defines + the interpretation of the remainder of the name.s 2) Re-write of second to last paragraph of section 6: - A sufficient prefix of attribute names needs to be dictated by a - mechanism in order to describe the context. For example it would be - problematic to represent SAML attribute names as the name format URI, - a space, and the remainder of the name. A carefully crafted SAML - assertion could appear to be a name from another mechanism or - context. Typically a SAML attribute name would include a prefix - describing the trust model and other context of the attribute name. + Since attribute names are split at the first space into prefix and + suffix, there is a potential for ambiguity if a mechanism blindly + passes through a name attribute whose name it does not understand. + In order to prevent such ambiguities the mechanism MUST always prefix + raw name attributes with a prefix that reflects the context of the + attribute. 3) Reserving local attribute names with at-signs in them: If the primary component contains an ASCII : (0x3a), then the primary component is a URI. Otherwise, the attribute is a local attribute and the primary component has meaning to the implementation of GSS- - API or to the specific configuration of the application. At this - time, local attribute names are not standardized; there is debate - about whether such standardization will be useful. Any future - standardizations will need to balance potential problems resulting - from attribute names used before standardization. + API or to the specific configuration of the application. Local + attribute names with an at-sign ('@') in them are reserved for future + allocation by the IETF. Comments? Nico -- From florob@babelmonkeys.de Fri Mar 16 16:55:09 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 91C5821F856D for ; Fri, 16 Mar 2012 16:55:09 -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 tGBR1Ure3SvO for ; Fri, 16 Mar 2012 16:55:09 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id D97A321F853D for ; Fri, 16 Mar 2012 16:55:08 -0700 (PDT) Received: from xdsl-213-196-243-40.netcologne.de ([213.196.243.40] helo=[192.168.0.50]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S8gzA-0004Do-Ci; Sat, 17 Mar 2012 00:55:04 +0100 Message-ID: <4F63D2D2.7050105@babelmonkeys.de> Date: Sat, 17 Mar 2012 00:54:58 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: William Mills References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> <4F5D3CCB.3070102@babelmonkeys.de> <1331514122.47869.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1331514122.47869.YahooMailNeo@web31806.mail.mud.yahoo.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth: Next Steps 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, 16 Mar 2012 23:55:09 -0000 On 12.03.2012 02:02, William Mills wrote: >> From: Florian Zeitz >> To: kitten@ietf.org >> Sent: Sunday, March 11, 2012 5:01 PM >> Subject: Re: [kitten] SASL OAuth: Next Steps >> Hi, >> >> I have a question/suggestion concerning this. >> I'm admittedly somewhat reluctant to ask at this point, because I have >> not found time to read enough of the OAuth RFCs to get the full picture, >> but please bear with me. >> >> It seems we have a relatively well defined list of necessary >> information. If this is put into JSON it appears to me that this JSON, >> except for ordering of entries will not be particularly flexible. >> Is there a compelling reason not to go back to a good old comma >> separated key value pair list at that point? > It's well defined for the current token profiles, yes, but what about for > extensions and new auth profiles? I wanted to avoid having to write in a > mapping per OAuth auth profile from the data in band to how it's used in > authentication. > Agreed, I was hoping OAuth mechanisms would have enough in common to map to a single representation. E.g. always provide data in the Authorization header field. From a quick examination it seems to me that this is currently at least one of the options for all mechanisms, however is not guaranteed to remain that way. >> The reason I ask is that having either a HTTP or a JSON parser (even a >> limited one) just for a SASL mechanism seems like enormous over >> engineering to me. > On the server side it's probably more work, but on the client you have to do > HTTP and JSON anyway. > I might just be overlooking something, but in particular the need to do JSON in a client is not apparent to me... >> This particularly struck me when people were discussing token based >> authentication at the last XMPP Summit. People were suggesting we might >> be able to reuse SASL OAuth for this under the assumption that it would >> just amount to sending a single token string over the wire. >> I find it somewhat irritating that at this point in time it is very >> significantly more complex than that. > The simplest token case, Bearer, could work this way. I don't think anything > else does. > > We might be able to do it differently, but I was using this also as proposal > for how to do OAuth 2 discovery. Will XMPP want auth endpoint discovery? > This was generally just an example of why the current approach strikes me as quite complex. In this particular discussion using SASL OAuth was sort of an afterthought. The idea was that (the equivalent to) the authorization endpoint would always be the resource/login server and tokens would be obtained via some XMPP based protocol. By now it seems to me that this might just be too different from OAuth to be reusing anything from it. I would however imagine that in general auth endpoint discovery would be very useful for some XMPP deployments that want to utilize "normal" OAuth. From wmills@yahoo-inc.com Fri Mar 16 18:14: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 40BD821E8026 for ; Fri, 16 Mar 2012 18:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.251 X-Spam-Level: X-Spam-Status: No, score=-17.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHwsLeWWRrlg for ; Fri, 16 Mar 2012 18:14:40 -0700 (PDT) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by ietfa.amsl.com (Postfix) with SMTP id 7338221E8014 for ; Fri, 16 Mar 2012 18:14:40 -0700 (PDT) Received: from [98.138.90.49] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 17 Mar 2012 01:14:37 -0000 Received: from [98.138.226.168] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 17 Mar 2012 01:14:37 -0000 Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 17 Mar 2012 01:14:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 198274.39913.bm@omp1069.mail.ne1.yahoo.com Received: (qmail 66489 invoked by uid 60001); 17 Mar 2012 01:14:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331946876; bh=zJSSI9CU1kWI5R4xRVqi8cn6a/ArMDgaDAkwGzQnxCw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nhdYeIjmSbBraEE0MwIjAqWf8tHYEXjserOPib/sIrCWbx3axeC1pdSO6fQHsruqDPvBHdQzdOCdyrr4F9W3DXLcdl/SJ9uUJzl64XvyC+reIbJlNNCUVlYuSlqyaJLSAdzU796YCO+nEA2I+jmX3T04aE8joEFetxk9wp4AJcs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=st1hQBN0A/+3AUbehKqJGpDHCpx1O0QkWTSj6e1lHQCzKCp6ZGqqjALXqbN7X5++Zh/pDGisK3tGI6tIOE+PHJLLcRDzWuT9Iy/lHUYfpPwOLBhH1GYbfcqE/ZaLoAA9Gi3HbuiXj/r5h8+XGUME4Q5w1X981TP4hGWV+aYd1Q0=; X-YMail-OSG: unKQ3DsVM1m_vR9wrTfWKdd0o1zLAlmIG70Y8r3cggf1HQD HYbMVZzpWI75NQkkYLLwPRFmiBNJZoFDzfNwiH2oe91A3NcIersS0gmgy6Gf HygzLpFly_GGY3amXoxIkYOaFzFgyXq1T_bEKnZCo7Ac0YPot1G_NF.6dDZI WqJf4Xuqd2Yofn3ocmNd.icA0QxkKaZ.z.KFsAbBAk4.p1V1ReXB.knr50O2 7Kw2BpjUtsdmFfS2alfV2rxTbcZf2wXxRFm3FScKmfipJAI23wbviAP5yrnq crYJuR65pW5BlyM6OF43fR2VsEMtfDMX0bAqnF7EqnzOnTCaRTb4DRgwoXfB GlOUS_GdPKnQPrISas3FqZC4WIfTVX0IyGZVXKuYkLuwN2zV4VUnUjoxBobO JpSGDe0Tvo4iBoKfUoqAgdFboXRmgtplW7mj8oED5dT7dLqdAh058E4kr Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Fri, 16 Mar 2012 18:14:36 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> <4F5D3CCB.3070102@babelmonkeys.de> <1331514122.47869.YahooMailNeo@web31806.mail.mud.yahoo.com> <4F63D2D2.7050105@babelmonkeys.de> Message-ID: <1331946876.63669.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Fri, 16 Mar 2012 18:14:36 -0700 (PDT) From: William Mills To: Florian Zeitz In-Reply-To: <4F63D2D2.7050105@babelmonkeys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 01:14:41 -0000 > =0A=0A>I might just be overlooking something, but in particular the need = to do=0A>JSON in a client is not apparent to me...=0A>=0A=0A=0ABecause the = OAuth 2.0 core protocol returns JSON formatted results.=0A=0A>This was gene= rally just an example of why the current approach strikes=0A>me as quite co= mplex. In this particular discussion using SASL OAuth was=0A>sort of an aft= erthought. The idea was that (the equivalent to) the=0A>authorization endpo= int would always be the resource/login server and=0A>tokens would be obtain= ed via some XMPP based protocol.=0A>By now it seems to me that this might j= ust be too different from OAuth=0A>to be reusing anything from it.=0A>=0A>I= would however imagine that in general auth endpoint discovery would be=0A>= very useful for some XMPP deployments that want to utilize "normal" OAuth.= =0A>=0A=0A=0ASomething that came up in a different conversation is that the= Google IMAP=0AOAuth solution is using HTTP already.=A0 =0A=0A=0AThat said,= discovery doesn't require the server to parse HTTP really, just =0A=0Aretu= rn it.=A0 The current proposal re-uses existing HTTP style LINK header=0Adi= scovery, in the hope that this will become more generally useful.=0A From leifj@mnt.se Fri Mar 16 23:46: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 2501621F865C for ; Fri, 16 Mar 2012 23:46:03 -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 3C5+X8tE0c5Z for ; Fri, 16 Mar 2012 23:46:02 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id DEBFC21F865B for ; Fri, 16 Mar 2012 23:46:01 -0700 (PDT) Received: from [10.130.3.194] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2H6jupe012906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Mar 2012 07:45:59 +0100 (CET) Message-ID: <4F643324.7080805@mnt.se> Date: Sat, 17 Mar 2012 07:45:56 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Proposed changes to http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-13 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, 17 Mar 2012 06:46:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Comments? FTR I'm fine with this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9kMyMACgkQ8Jx8FtbMZnfnzACgvd4zBPwETa69oLxjQJe0iOJ/ dTUAoMKqlp6a2RqG0Pb4SHYztOyVSuev =Dc/c -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Sat Mar 17 15:51:10 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 DC58821F868C for ; Sat, 17 Mar 2012 15:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.953 X-Spam-Level: X-Spam-Status: No, score=-103.953 tagged_above=-999 required=5 tests=[AWL=-2.346, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 HMTYNcMDoX+g for ; Sat, 17 Mar 2012 15:51:10 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB06621F8687 for ; Sat, 17 Mar 2012 15:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332024668; d=isode.com; s=selector; i=@isode.com; bh=hbpshC67y7ze17Mw6WOsVv3MrygRArJypZ5wNuJxgCo=; 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=FJV4Pm/yM3MTy8JbT5Ek0NrjXSxeKXlWGDcKNqVe3XF8f6GMRocMk1Fxas7pUo0Chckg6r 4eTw65zN5SgAt3YCtz8bz2yyuJKYaL8Zelbr8wes9KSWJM3b+V17KnoLKo6EgD1cv3FjHx zzXGu9eb3ng3is5bztRq17rAKcopg2Y=; Received: from [172.20.10.2] ((unknown) [212.183.140.31]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 17 Mar 2012 22:51:05 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4F646900.60408@isode.com> Date: Sat, 17 Mar 2012 10:35:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Nico Williams 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 Subject: Re: [kitten] Proposed changes to http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-13 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, 17 Mar 2012 22:51:11 -0000 On 16/03/2012 22:04, Nico Williams wrote: > Sorry for proposing last minute changes. > > I have three changes to propose, of which only one is substantive: > > - clarify section 6 to indicate that "primary attribute component" and > "prefix" are the same thing > > - re-write the second to last paragraph of section 6 > > - reserve a subset of the "local" attribute namespace > > ("local" attributes are ones with neither colons nor spaces) > > This is the substantive change. Sam and I believe that it will > eventually be desirable to have simple attribute names that > are not URNs -- developers and users/sysadmins (to the > extent that attribute names leak into user/admin interfaces) > will want non-URN, user-friendly, portable and generic > attribute names. > > Sam proposes to reserve local attribute names that have an > at-sign. > > This change requires confirmation on the list, thus this post. > > The proposed changes are as follows. > > 1) Clarification of "prefix": > > If an attribute name contains a space (ASCII 0x20), the first space > separates the most significant or primary component of the name from > - the remainder. If there is no space, the primary component is the > - entire name, otherwise it defines the interpretation of the remainder > - of the name.s > + the remainder. We may refer to the primary component of the > + attribute name as the attribute name's "prefix". If there is no > + space, the primary component is the entire name, otherwise it defines > + the interpretation of the remainder of the name.s > > 2) Re-write of second to last paragraph of section 6: > > - A sufficient prefix of attribute names needs to be dictated by a > - mechanism in order to describe the context. For example it would be > - problematic to represent SAML attribute names as the name format URI, > - a space, and the remainder of the name. A carefully crafted SAML > - assertion could appear to be a name from another mechanism or > - context. Typically a SAML attribute name would include a prefix > - describing the trust model and other context of the attribute name. > + Since attribute names are split at the first space into prefix and > + suffix, there is a potential for ambiguity if a mechanism blindly > + passes through a name attribute whose name it does not understand. > + In order to prevent such ambiguities the mechanism MUST always prefix > + raw name attributes with a prefix that reflects the context of the > + attribute. > > > 3) Reserving local attribute names with at-signs in them: > > If the primary component contains an ASCII : (0x3a), then the primary > component is a URI. Otherwise, the attribute is a local attribute > and the primary component has meaning to the implementation of GSS- > - API or to the specific configuration of the application. At this > - time, local attribute names are not standardized; there is debate > - about whether such standardization will be useful. Any future > - standardizations will need to balance potential problems resulting > - from attribute names used before standardization. > + API or to the specific configuration of the application. Local > + attribute names with an at-sign ('@') in them are reserved for future > + allocation by the IETF. > > Comments? I like these changes. From leifj@mnt.se Mon Mar 26 00:41: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 3E2CB21F8528 for ; Mon, 26 Mar 2012 00:41:34 -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=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eytpwVFrSKRs for ; Mon, 26 Mar 2012 00:41:33 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id DA1A221F8535 for ; Mon, 26 Mar 2012 00:41:28 -0700 (PDT) Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2Q7fNvM027691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 09:41:27 +0200 (CEST) Message-ID: <4F701DA3.1040305@mnt.se> Date: Mon, 26 Mar 2012 09:41:23 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: kitten@ietf.org References: <4F646900.60408@isode.com> In-Reply-To: <4F646900.60408@isode.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Proposed changes to http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-13 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, 26 Mar 2012 07:41:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2012 11:35 AM, Alexey Melnikov wrote: > On 16/03/2012 22:04, Nico Williams wrote: >> Sorry for proposing last minute changes. >> >> I have three changes to propose, of which only one is >> substantive: >> >> - clarify section 6 to indicate that "primary attribute >> component" and "prefix" are the same thing >> >> - re-write the second to last paragraph of section 6 >> >> - reserve a subset of the "local" attribute namespace >> >> ("local" attributes are ones with neither colons nor spaces) >> >> This is the substantive change. Sam and I believe that it will >> eventually be desirable to have simple attribute names that are >> not URNs -- developers and users/sysadmins (to the extent that >> attribute names leak into user/admin interfaces) will want >> non-URN, user-friendly, portable and generic attribute names. >> >> Sam proposes to reserve local attribute names that have an >> at-sign. >> >> This change requires confirmation on the list, thus this post. >> >> The proposed changes are as follows. >> >> 1) Clarification of "prefix": >> >> If an attribute name contains a space (ASCII 0x20), the first >> space separates the most significant or primary component of the >> name from - the remainder. If there is no space, the primary >> component is the - entire name, otherwise it defines the >> interpretation of the remainder - of the name.s + the >> remainder. We may refer to the primary component of the + >> attribute name as the attribute name's "prefix". If there is no >> + space, the primary component is the entire name, otherwise it >> defines + the interpretation of the remainder of the name.s >> >> 2) Re-write of second to last paragraph of section 6: >> >> - A sufficient prefix of attribute names needs to be dictated >> by a - mechanism in order to describe the context. For example >> it would be - problematic to represent SAML attribute names as >> the name format URI, - a space, and the remainder of the name. >> A carefully crafted SAML - assertion could appear to be a name >> from another mechanism or - context. Typically a SAML >> attribute name would include a prefix - describing the trust >> model and other context of the attribute name. + Since >> attribute names are split at the first space into prefix and + >> suffix, there is a potential for ambiguity if a mechanism >> blindly + passes through a name attribute whose name it does >> not understand. + In order to prevent such ambiguities the >> mechanism MUST always prefix + raw name attributes with a >> prefix that reflects the context of the + attribute. >> >> >> 3) Reserving local attribute names with at-signs in them: >> >> If the primary component contains an ASCII : (0x3a), then the >> primary component is a URI. Otherwise, the attribute is a local >> attribute and the primary component has meaning to the >> implementation of GSS- - API or to the specific configuration >> of the application. At this - time, local attribute names are >> not standardized; there is debate - about whether such >> standardization will be useful. Any future - standardizations >> will need to balance potential problems resulting - from >> attribute names used before standardization. + API or to the >> specific configuration of the application. Local + attribute >> names with an at-sign ('@') in them are reserved for future + >> allocation by the IETF. >> >> Comments? > I like these changes. > Anyone else have an opinion. This is the only thing holding this document up and I'd like to push a final version for IETF LC this week. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9wHaMACgkQ8Jx8FtbMZndLKwCfRl2NWcP+Gkih5sIx1+8OykqI +ZgAnip2ksJjeGNNlyXS7DyRDn2dPBzA =Hx5m -----END PGP SIGNATURE----- From cantor.2@osu.edu Mon Mar 26 08:40: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 DCDBD21E80C2 for ; Mon, 26 Mar 2012 08:40:02 -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 zVr3INkUm5DQ for ; Mon, 26 Mar 2012 08:40:02 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id EE28C21E80BD for ; Mon, 26 Mar 2012 08:39:59 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2QFdsH0010857 for ; Mon, 26 Mar 2012 11:39:58 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 11:39:40 -0400 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: Status of SAML-EC draft and open issues Thread-Index: AQHNC2aoGUqyRae8B0CDpfuP8hiFiQ== Date: Mon, 26 Mar 2012 15:39:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-ID: <441862CEA4B4F949993F2C5A0C4E2515@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Subject: [kitten] Status of SAML-EC draft and open issues 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, 26 Mar 2012 15:40:03 -0000 I hope to be in the chatroom tomorrow morning (my time), but regardless, here's a current summary: NCSA has implementation work proceeding as part of a funded project to prototype the draft mechanism initially with SSH as the test protocol. The initial feedback from that work was incorporated into a new draft last month, mostly to relax some assumptions about TLS being the only secure transport layer involved, which is not true with SSH of course. An additional item identified by the work was the absence of proper guidance on mechanism name handling, which I had identified a while ago as something that needed attention. The acceptor side will be based on GSS_C_NT_HOSTBASED_SERVICE, but there needs to be language added on mapping that to and from SAML entityID format. The initiator name needs to be expressed in terms of the SAML NameID element, or in its absence, some convention for representing an anonymous initiator (which could be carrying GSS naming attributes to actually identify the subject of course). So I need to define a mechanism name type and import/export guidance. I'm curious how that can be left out of the non-EC SAML mechanism, which has the same problem, seems to me. (Same goes for OAuth and OpenID, IMHO, though not in terms of SAML obviously.) Anyway, I'm going to be doing some work to draft something on that shortly. If I'm right that this problem applies to the non-EC mechanism, I'm of course willing to discuss something in common with those authors. The other major open item involves per-message token support. I exchanged some mail a while ago on that with Sam and I have at least a general idea on what to try adding, but the name issue above is higher priority at the moment. Finally, I'm tracking http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-02 and I would guess that I'll want to reference that from the EC draft as a convention for putting the SAML information into naming attributes. Those are the issues I'm aware of at this point. The two OASIS dependencies are so far holding stable, but I'm not advancing them there until I know for sure they don't need changes. -- Scott From prvs=143245be1e=jaltman@secure-endpoints.com Mon Mar 26 09:24: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 9409F21E80C4 for ; Mon, 26 Mar 2012 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=-3.362, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 8kf63cELPmp9 for ; Mon, 26 Mar 2012 09:24:30 -0700 (PDT) Received: from mail.secure-endpoints.com (rrcs-208-125-0-235.nyc.biz.rr.com [208.125.0.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8983F21E80C0 for ; Mon, 26 Mar 2012 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1332779069; x=1333383869; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=SbqY2cmKsBaSnlCkSa 5NwHJ21CT9iPRCyqrNznGM70s=; b=Y6E7gC/iyFiVkGf6jJiaezAcLBEuE8PWxO qRupvFgYZrLpUyBejJqRHJmy4P0boTwSxYEu0dtlOpLRWzlcw2TN6XuaJG2/LV5R 2q3IpRZb76mFQPVjI0yzqZJjEKYDS+AgDKfUAA6FO0WauZetFkT+5Q787d0/Amtv 7t8YBlBJQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=Svv+iqwM0ihX97RdNH18TbZ4WKlRS8XJrdg4fSr0xLbU8a5kOwQbqzhUpvkQ ZIUyCKVhbU0BhiIcYDXvTjG9W/sKm8/DlXLpXUGHo0VeSVYYQODQimwlF L6yESm4XQ1xOLeAM8ChHM4Op43j0JTsRi98Tt4S+HYgQOq+NXWTNp4=; X-MDAV-Processed: mail.secure-endpoints.com, Mon, 26 Mar 2012 12:24:29 -0400 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v12.5.4) with ESMTP id md50000249076.msg for ; Mon, 26 Mar 2012 12:24:28 -0400 X-Spam-Processed: mail.secure-endpoints.com, Mon, 26 Mar 2012 12:24:28 -0400 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:120326:md50000249076::cts8gbcJ1BXlqvZi:00000Y4D X-Return-Path: prvs=143245be1e=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <4F70983A.9070705@secure-endpoints.com> Date: Mon, 26 Mar 2012 12:24:26 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: kitten@ietf.org References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> <84A8F86B-0866-4C7D-91C3-CE0671CBA24E@gmx.net> <4F5D3CCB.3070102@babelmonkeys.de> <1331514122.47869.YahooMailNeo@web31806.mail.mud.yahoo.com> <4F63D2D2.7050105@babelmonkeys.de> <1331946876.63669.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1331946876.63669.YahooMailNeo@web31802.mail.mud.yahoo.com> X-Enigmail-Version: 1.4 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1A6E09A8EA74D5EB6E458F6E" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:24:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1A6E09A8EA74D5EB6E458F6E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just as a point of reference, OpenAFS's rxgk security class is designed to support any GSS mechanism that supports the GSS PRF. I would like to see the ability to use OAuth as an authentication mechanism for OpenAFS. As a result, I would prefer a SASL implementation that relies on the construction of a GSS mechanism instead of a direct SASL mechanism. I would also prefer to avoid parsing HTTP header syntax. Jeffrey Altman --------------enig1A6E09A8EA74D5EB6E458F6E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJPcJg8AAoJENxm1CNJffh44awIAKIWfH4JZvRLVkkzAjkokhls dBuQBSLpgxn75e0w9ErWWJSVsh837OhZUItm01xUAoRT66jlzEK0YkU3RKeQye7L 8bFgvSUmgBqjoQ2jIuKwGr5ONX1RhvmxbkBNFKu1FSEownF+KChZdBX/P0Pg96Nz w2HwbcJ2QhmpcBjlUef/qlfibk3hy2h/XzrrQ1IP3neOWr6WeGsSNvymkNH6sx4S TpP2MVFFZjapSv7akTPPes0otJqnrFcGUL9SqlOpfKYVaPq9+mjkkoSjxgGaRZqb JNS6/xg5ecjWRKnKRlEhVeVPmxacqFBmJHzr8E/7Yv/7kGI6gXMs7crrUmSYu2s= =4jI5 -----END PGP SIGNATURE----- --------------enig1A6E09A8EA74D5EB6E458F6E-- From ietf@meetecho.com Mon Mar 26 09:33: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 B2C2621E80C8 for ; Mon, 26 Mar 2012 09:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 K6ITw+iTVxZT for ; Mon, 26 Mar 2012 09:33:38 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out21.aruba.it [62.149.158.61]) by ietfa.amsl.com (Postfix) with SMTP id 9AD8E21E80BC for ; Mon, 26 Mar 2012 09:33:37 -0700 (PDT) Received: (qmail 11898 invoked by uid 89); 26 Mar 2012 16:33:34 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq04.aruba.it with SMTP; 26 Mar 2012 16:33:34 -0000 Received: (qmail 24982 invoked by uid 89); 26 Mar 2012 16:33:34 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with SMTP; 26 Mar 2012 16:33:34 -0000 Message-ID: <4F709A5D.60901@meetecho.com> Date: Mon, 26 Mar 2012 18:33:33 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: kitten@ietf.org, ietf-krb-wg@lists.anl.gov Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [kitten] Meetecho support for KITTEN/KRB session 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, 26 Mar 2012 16:33:38 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Tuesday's KITTEN/KRB WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/kitten The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From simon@josefsson.org Mon Mar 26 10:07:51 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 3CFD021E8107 for ; Mon, 26 Mar 2012 10:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=-1.808, 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 sH6ReOa35ugN for ; Mon, 26 Mar 2012 10:07:50 -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 29D0321E8106 for ; Mon, 26 Mar 2012 10:07:49 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2QH7fnR028244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Mar 2012 19:07:43 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120326:kitten@ietf.org::pbm8KXV95KpRrYKo:Kxxv X-Hashcash: 1:22:120326:cantor.2@osu.edu::lLkcntPetUH+/3MH:03MM7 Date: Mon, 26 Mar 2012 19:07:41 +0200 In-Reply-To: (Scott Cantor's message of "Mon, 26 Mar 2012 15:39:39 +0000") Message-ID: <87k427xpcy.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of SAML-EC draft and open issues 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, 26 Mar 2012 17:07:51 -0000 --=-=-= Content-Type: text/plain "Cantor, Scott" writes: > An additional item identified by the work was the absence of proper > guidance on mechanism name handling, which I had identified a while ago as > something that needed attention. The acceptor side will be based on > GSS_C_NT_HOSTBASED_SERVICE, but there needs to be language added on > mapping that to and from SAML entityID format. > > The initiator name needs to be expressed in terms of the SAML NameID > element, or in its absence, some convention for representing an anonymous > initiator (which could be carrying GSS naming attributes to actually > identify the subject of course). So I need to define a mechanism name type > and import/export guidance. > > I'm curious how that can be left out of the non-EC SAML mechanism, which > has the same problem, seems to me. (Same goes for OAuth and OpenID, IMHO, > though not in terms of SAML obviously.) > > Anyway, I'm going to be doing some work to draft something on that > shortly. If I'm right that this problem applies to the non-EC mechanism, > I'm of course willing to discuss something in common with those authors. I recall we drafted something related to this earlier, see draft below, but maybe it was never posted or pursued. Does it address the issue? I'm not sure I see how this is essential for implementations though? Does it have to be any normative part of the SASL-SAML specification? /Simon --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=draft-josefsson-gssapi-saml-nametype.txt Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Informational August 14, 2010 Expires: February 15, 2011 SAML Entity Identifier GSS-API Name Type draft-josefsson-gssapi-saml-nametype-00 Abstract This document specify a new GSS-API name type and associated syntax to represent SAML Entity Identifiers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 15, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Josefsson Expires February 15, 2011 [Page 1] Internet-Draft SAML Entity Identifier GSS-API Name Type August 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SAML Entity Identifier Name Form . . . . . . . . . . . . . . . 3 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 4. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Josefsson Expires February 15, 2011 [Page 2] Internet-Draft SAML Entity Identifier GSS-API Name Type August 2010 1. Introduction The Generic Security Service Application Program Interface (GSS-API) [RFC2743] specify name types for use in various situations, but none is applicable to Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os] that uses Uniform Resource Identifier (URI) [RFC3986] syntax for Entity Identifier. This document specify a new GSS-API name type and form to represent SAML Entity Identifier. 2. SAML Entity Identifier Name Form This name form shall be represented by the Object Identifier 1.3.6.1.4.1.11591.4.7. The recommended symbolic name for this type is "GSS_C_NT_SAML_ENTITYID". This name type is used to represent services associated with a SAML Entity Identifier. The name form syntax is a URI. For example: https://idp.example.org/SAML2 There is no canonicalization process, every valid URI input is a valid mechanism name form. 3. Acknowledgements The document was created as a result of discussions with Scott Cantor and Nicolas Williams. TBA. 4. Copying conditions This document should be considered a Code Component, and is thus effectively available under the BSD license. 5. Security Considerations TBW. 6. IANA Considerations None. Josefsson Expires February 15, 2011 [Page 3] Internet-Draft SAML Entity Identifier GSS-API Name Type August 2010 7. Normative References [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. Author's Address Simon Josefsson SJD AB Hagagatan 24 Stockholm 113 47 SE Email: simon@josefsson.org URI: http://josefsson.org/ Josefsson Expires February 15, 2011 [Page 4] --=-=-=-- From cantor.2@osu.edu Mon Mar 26 10:15: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 EA20121E80DA for ; Mon, 26 Mar 2012 10:15:02 -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 3Q+PTJFRbe+7 for ; Mon, 26 Mar 2012 10:15:02 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5F96321E80E0 for ; Mon, 26 Mar 2012 10:14:59 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2QHEak1004743; Mon, 26 Mar 2012 13:14:58 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 13:14:39 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: Status of SAML-EC draft and open issues Thread-Index: AQHNC3LzGUqyRae8B0CDpfuP8hiFiZZ80PMA Date: Mon, 26 Mar 2012 17:14:38 +0000 Message-ID: In-Reply-To: <87k427xpcy.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-ID: <830F861AB5E5184CA121F7802626E5BF@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of SAML-EC draft and open issues 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, 26 Mar 2012 17:15:03 -0000 On 3/26/12 1:07 PM, "Simon Josefsson" wrote: > >I recall we drafted something related to this earlier, see draft below, >but maybe it was never posted or pursued. Does it address the issue? I don't think so. That might be something to incorporate/reuse for a small bit of the territory, but it leaves out: - converting between host type names and entity names, since everybody expects to do host type names - the initiator half The latter is the larger concern at the moment. If nothing else, a host type name for an acceptor can be finessed into an entityID by just relying on the fact that pretty much all SAML implementations treat entityIDs as strings anyway. >I'm not sure I see how this is essential for implementations though? Treatment of initiator names isn't essential? >Does it have to be any normative part of the SASL-SAML specification? I'm not presuming to speak for others on it yet, I'm not familiar enough with GSS apps. If it is, I'm fine with doing a separate draft for reuse of the language. -- Scott From cantor.2@osu.edu Mon Mar 26 14:46:01 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 4992921F8623 for ; Mon, 26 Mar 2012 14:46:01 -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 C2CljzHUq1YI for ; Mon, 26 Mar 2012 14:46:00 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id C00C321F854F for ; Mon, 26 Mar 2012 14:45:51 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2QLjXNa017140; Mon, 26 Mar 2012 17:45:40 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 17:44:32 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: Status of SAML-EC draft and open issues Thread-Index: AQHNC3LzGUqyRae8B0CDpfuP8hiFiZZ9HHgA Date: Mon, 26 Mar 2012 21:44:31 +0000 Message-ID: In-Reply-To: <87k427xpcy.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <41FC7A2E161E474AA21CA7852823B8CF@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of SAML-EC draft and open issues 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, 26 Mar 2012 21:46:01 -0000 I'd still welcome comment, but after a little more thinking about it, I think I can convince myself that the other SAML mechanism avoids the concern over initiator name handling because it's not part of the GSS mechanism itself. Rather it's part of the interplay between the SAML SP implementation doing browser SSO and the server's mechanism, which AFAIK was left unspecified. Something in that interconnection of state has to indicate an initiator identity to apply to the GSS context it's accepting into the server, and while it's undoubtedly based on something in the SAML assertion, it's really implementation specific. That's not the case with EC. There is no unspecified component because the SP *is* the server mechanism, so there has to be a fully spec'd mapping from the SAML token to the initiator name. I think that also means that this is probably not an issue for the OpenID mech, it being similarly browser based, and is probably a matter for specific OAuth token types in the OAuth case, but I won't presume to speak for those. -- Scott From internet-drafts@ietf.org Tue Mar 27 05:19:17 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 D816C21F8855; Tue, 27 Mar 2012 05:19:17 -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 ZgY+Eq4-sR13; Tue, 27 Mar 2012 05:19:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B9021F87D0; Tue, 27 Mar 2012 05:19:17 -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.00 Message-ID: <20120327121917.2800.5352.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 05:19:17 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-14.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, 27 Mar 2012 12:19:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : Nicolas Williams Leif Johansson Sam Hartman Simon Josefsson Filename : draft-ietf-kitten-gssapi-naming-exts-14.txt Pages : 18 Date : 2012-03-27 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-14= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-14.= txt From iesg-secretary@ietf.org Tue Mar 27 05:48:21 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 78CC821E81CD; Tue, 27 Mar 2012 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 9I7hUYpsQi31; Tue, 27 Mar 2012 05:48:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0985B21F87CA; Tue, 27 Mar 2012 05:48:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327124818.13407.14666.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 05:48:18 -0700 Cc: kitten@ietf.org Subject: [kitten] Last Call: (GSS-API Naming Extensions) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:48:22 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'GSS-API Naming Extensions' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ballot/ No IPR declarations have been submitted directly on this I-D. From ietf@meetecho.com Tue Mar 27 12:24: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 6CC0A21E8094 for ; Tue, 27 Mar 2012 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Posr87tdWU8u for ; Tue, 27 Mar 2012 12:24:54 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out29.aruba.it [62.149.158.69]) by ietfa.amsl.com (Postfix) with SMTP id 094DE21E804B for ; Tue, 27 Mar 2012 12:24:52 -0700 (PDT) Received: (qmail 5170 invoked by uid 89); 27 Mar 2012 19:24:50 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq03.aruba.it with SMTP; 27 Mar 2012 19:24:50 -0000 Received: (qmail 26298 invoked by uid 89); 27 Mar 2012 19:24:50 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with SMTP; 27 Mar 2012 19:24:50 -0000 Message-ID: <4F7213FD.2030900@meetecho.com> Date: Tue, 27 Mar 2012 21:24:45 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [kitten] Meetecho session recording available 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, 27 Mar 2012 19:24:54 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of KITTEN session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf83/recordings#KITTEN_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From simon@josefsson.org Wed Mar 28 12:10:55 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 C951621E80E5 for ; Wed, 28 Mar 2012 12:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.642 X-Spam-Level: X-Spam-Status: No, score=-101.642 tagged_above=-999 required=5 tests=[AWL=-1.733, 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 Ab-nprt9OVew for ; Wed, 28 Mar 2012 12:10:48 -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 EFAEE21F86A3 for ; Wed, 28 Mar 2012 12:10:47 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2SJAesG002539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 28 Mar 2012 21:10:42 +0200 X-Hashcash: 1:22:120328:kitten@ietf.org::BSj36fLYvbHVxoUm:BJoS From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 28 Mar 2012 21:10:40 +0200 Message-ID: <87pqbw7d8v.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [kitten] OpenID SASL interop server available 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, 28 Mar 2012 19:10:55 -0000 Hello, Version 1.7.2 of GNU SASL (announcement in [1]) supports the OPENID20 mechanism and contains a example server which is running on "interop.josefsson.org" port 2000 using the SMTP protocol. The server accepts any OpenID URLs and will happily redirect you to its IdP and accept its authentication decision. Real servers would probably have some pre-filtering of acceptable OpenID URLs before proceeding with the redirect (i.e., the URL must match some identity in the database of authorized users). There are hints on how to test the server here: https://lists.gnu.org/archive/html/help-gsasl/2012-03/msg00004.html In the post you can see a step-by-step example of a succesful OpenID authenticated login to interop.josefsson.org. What is unusual about this mechanism compared to all other SASL mechanisms I have implemented is that it is variable-roundtrip. It can complete successfully after the second roundtrip (i.e., openid url, redirect url, dummy '=' response) or after the third roundtrip (i.e., openid url, redirect url, dummy '=' response, sreg, empty response). This caused some complexity in my implementation, but not significant. The document is a bit terse with examples, and there may be room for different interpretation of the SREG vs non-SREG cases, and also when the authentication fails. To get other people's feedback with the hope of improving interoperability, I wanted to give examples of the variants I could think of. (The output below is actually from my self-tests.) Running successful authentication without SREG: S: `' (0) GSASL_NEEDS_MORE C: `biwsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (36) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `' (0) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running successful authentication with SREG: S: `' (0) GSASL_NEEDS_MORE C: `biwsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (36) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `bmlja25hbWU9amFz' (16) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running successful authentication without SREG with authzid: S: `' (0) GSASL_NEEDS_MORE C: `bixhPXVzZXIsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (44) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `bmlja25hbWU9amFz' (16) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running successful authentication with SREG with authzid: S: `' (0) GSASL_NEEDS_MORE C: `bixhPXVzZXIsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (44) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `bmlja25hbWU9amFz' (16) GSASL_OK C: `' (0) GSASL_OK S: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Running failed authentication: S: `' (0) GSASL_NEEDS_MORE C: `bixhPXVzZXIsaHR0cDovL3VzZXIuZXhhbXBsZS5vcmcv' (44) GSASL_NEEDS_MORE S: `aHR0cDovL2lkcC5leGFtcGxlL05PTkNFLz9vcGVuaWQuZm9vPWJhcg==' (56) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_OK S: `b3BlbmlkLmVycm9yPWZhaWw=' (24) GSASL_NEEDS_MORE C: `PQ==' (4) GSASL_NEEDS_MORE S: GSASL_AUTHENTICATION_ERROR C: GSASL_MECHANISM_CALLED_TOO_MANY_TIMES Does anyone have different interpretation of how the round-trips should look like? Finally, I I noticed a nit in section 2.1: The nonce value MUST be at least 2^32 large and large enough to handle well in excess of the number of concurrent transactions a SASL server shall see. Presumably the intention is not to use 2^32 = 4GB large nonces. I used a 32 byte nonce, but possibly the intention was that the minimum required length should be 4 bytes? That is reinforced by the examples using 4 bytes. /Simon [1] https://lists.gnu.org/archive/html/help-gsasl/2012-03/msg00003.html