From shawn.emery@oracle.com Thu Nov 1 10:01:11 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 8D70D21F90BF for ; Thu, 1 Nov 2012 10:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G8A88lzmew4 for ; Thu, 1 Nov 2012 10:01:11 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1192721F90C4 for ; Thu, 1 Nov 2012 10:01:11 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA1H1901006430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Nov 2012 17:01:10 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA1H19an002185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Nov 2012 17:01:09 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA1H19gm016082 for ; Thu, 1 Nov 2012 12:01:09 -0500 Received: from [10.159.108.135] (/10.159.108.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Nov 2012 10:01:09 -0700 Message-ID: <5092AA68.7070704@oracle.com> Date: Thu, 01 Nov 2012 10:59:20 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.7) Gecko/20120926 Thunderbird/10.0.7 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [kitten] Fwd: Help the NomCom 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, 01 Nov 2012 17:01:11 -0000 On 11/ 1/12 06:17 AM, NomCom Chair wrote: > ... > > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. The NomCom would greatly appreciate any help you > could provide in making members of your working group aware of ways in > which they can provide valuable feedback to the NomCom. > > In order to ensure that your input is received in time to be useful, the > NomCom needs to receive community feedback on or before Sunday, November 11. > > The final list of candidates (as per RFC 5680) that the NomCom is > considering for open positions can be found at: > https://www.ietf.org/group/nomcom/2012/input/ > > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes > comments on specific individuals, as well as general feedback related to > any of the positions that NomCom is considering. > > Note: A list of leadership positions that the NomCom is considering can be > found at: https://www.ietf.org/group/nomcom/2012/ > > If the NomCom office hours are inconvenient for you or if you cannot > attend IETF 85, the NomCom is happy to take community input via email > to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a > meeting outside of office hours, just send us email and we can set > something up. > > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool: > https://www.ietf.org/group/nomcom/2012/input/ > > Thank you for your help, > - Matt Lepinski > nomcom-chair at ietf.org From shawn.emery@oracle.com Sun Nov 4 19:34: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 1722221F87B8 for ; Sun, 4 Nov 2012 19:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.001, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wWCWbramDlF for ; Sun, 4 Nov 2012 19:34:49 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 788BA21F886E for ; Sun, 4 Nov 2012 19:34:49 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA53Ymx1027238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Nov 2012 03:34:48 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA53YlOX010555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Nov 2012 03:34:47 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA53YlAh017429 for ; Sun, 4 Nov 2012 21:34:47 -0600 Received: from shawn-emerys-computer.local (/74.176.163.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Nov 2012 19:34:46 -0800 Message-ID: <509733D9.7090700@oracle.com> Date: Sun, 04 Nov 2012 20:34:49 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [kitten] Kitten and Krb-wg Merger 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 Nov 2012 03:34:50 -0000 In light of the pending merger between the kitten and Kerberos WGs we have compiled a list of possible work items to start the merger/recharter discussions during the combined session on Tuesday. We are looking for feedback on this and other items that should be considered for the new charter. GSS-API related ------------- * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Negotiable replay cache avoidance * Define interfaces for better error message reporting. * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, for example, by eliminating parameters which are commonly used with the default values. * Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. Kerberos related -------------- * Prepare and advance one or more standards-track specifications which update the Kerberos version 5 protocol to support non-ASCII principal and realm names, salt strings, and passwords, and localized error reporting. Maximizing backward compatibility is strongly desired. * Prepare and advance one or more standards-track specifications which update the Kerberos version 5 protocol in a backward-compatible way to support extending the unencrypted portion of a Kerberos ticket. * Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-sorce-krbwg-general-pac-01 may be standardized. * Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. * Prepare and advance one or more standards-track specifications which define mechanisms for establishing keys and configuration information used during authentication between Kerberos realms. * Prepare and advance a standards-track specification defining a format for the transport of Kerberos credentials within other protocols. * Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. * Produce an LDAP schema for management of the KDC's database. Shawn. kitten and krb-wg co-chair -- From alexey.melnikov@isode.com Mon Nov 5 07:16:27 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 3649D21F8922 for ; Mon, 5 Nov 2012 07:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgqd3sw2vSK9 for ; Mon, 5 Nov 2012 07:16:26 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5E721F881F for ; Mon, 5 Nov 2012 07:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1352128583; d=isode.com; s=selector; i=@isode.com; bh=hjBq6n4KmazSNNIR9M4P0RVXNUeoj2TWUyBMLs0ZrmE=; 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=QvyuEL3pdHilCGRsg8zC9wWRq9tnzonRMrToZpK6VoTWSGh8XSoQEOib0NaN9fV27jPXPy iZWYf2EeDVd3hzJ/ZcTFGbNjvVcP7Px4z4TiU93xduywvtKh8MW8TWFUs/ThlYbdbZUeDT LkOskzgVxKAwihklvnAyzUdl0qHQ4fw=; Received: from [130.129.18.182] (dhcp-12b6.meeting.ietf.org [130.129.18.182]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 5 Nov 2012 15:16:22 +0000 Message-ID: <5097D840.4080000@isode.com> Date: Mon, 05 Nov 2012 15:16:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] Belated WGLC comments on draft-ietf-kitten-sasl-oauth-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 Nov 2012 15:16:27 -0000 I think the document is in a good shape, but number of errors in IMAP/SMTP examples bugs me ;-). In Section 1: Steps (E) and (F) are not defined in [I-D.ietf-oauth-v2] and are the main functionality specified within this document. Consequently, the message exchange shown in Figure 2 is the result of this specification. The client will genrally need to determine the Typo: generally 2. Terminology Note that the IMAP SASL specification requires base64 encoding message, not this memo. Missing an Informative reference for base64. Please use "RFC 4648, Section 4". In 3.1: Use / in the ABNF (| is used by HTTP ABNF only). RFC 2616 has to be a Normative reference (e.g. because you reference HTTP methods) 3.2.2. Canonicalization The identity asserted by the OAuth authorization server is canonical for display. The server MAY provide a different canonical form based on local data. I don't understand the second sentence. SASL server? How can it do that? In 3.3 you use "user" in your example, but it is not defined in 3.1. In 4: "must use RFC 6125" is not detailed enough to be useful. Maybe point people to reuse the application protocol profile of RFC 6125 (i.e. in SASL OAUTH running over IMAP the IMAP profile of RFC 6125 should be used.) In 5.1: the first IMAP response must start with "* OK ...". In 5.1 SASL-IR capability is missing in the IMAP CAPABILITY response or the example is not valid (SASL initial response is not allowed by unextended IMAP). So taking both into account: OLD: S: * IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER NEW: S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR In the SMTP example: the last line of EHLO response should use space instead of dash. The same issue in other SMTP examples. OLD: S: 250-PIPELINING NEW: S: 250 PIPELINING (Also update other sections in the similar manner). In 5.2, the first 2 lines are incorrect: no tagged response must be sent, you should be using OK response with CAPABILITY response code enclosed in []. The same issue in 5.3 and 5.4. OLD: S: * CAPABILITY IMAP4rev1 AUTH=OAUTH10A-PLUS SASL-IR IMAP4rev1 Server Ready S: t0 OK Completed NEW: S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTH10A-PLUS SASL-IR] IMAP4rev1 Server Ready From hartmans@mit.edu Tue Nov 6 03:55:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A8021F88B9 for ; Tue, 6 Nov 2012 03:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W9enNjH0cvf for ; Tue, 6 Nov 2012 03:55:06 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BC81021F8481 for ; Tue, 6 Nov 2012 03:55:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-459e.meeting.ietf.org [130.129.69.158]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id CAD0320355; Tue, 6 Nov 2012 06:54:11 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8B3DC412A; Tue, 6 Nov 2012 06:55:03 -0500 (EST) From: Sam Hartman To: kitten@ietf.org,ietf-krb-wg@anl.gov Date: Tue, 06 Nov 2012 06:55:03 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [kitten] Remote Participation at IETF 85 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, 06 Nov 2012 11:55:06 -0000 --=-=-= Folks, we will be using the kitten@jabber.ietf.org jabber room today for the entire session. We'll put a note in the Kerberos room that you're in the wrong place. You will have two options for audio: 1) meetecho (recommended); see below 2) The IETF MP3 stream (see http://tools.ietf.org/wg/kitten/agenda) For slides see meetecho or http://tools.ietf.org/wg/kitten/agenda --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Fri, 02 Nov 2012 10:44:39 -0400 X-Sieve: CMU Sieve 2.2 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mail.painless-security.com (Postfix) with ESMTP id 4E9562014B for ; Fri, 2 Nov 2012 10:44:39 -0400 (EDT) Received: from mailhub-dmz-2.mit.edu ( [18.7.62.37]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 5D.E7.03811.28CD3905; Fri, 2 Nov 2012 10:45:23 -0400 (EDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id qA2EivGT031483 for ; Fri, 2 Nov 2012 10:45:22 -0400 Resent-Date: Fri, 2 Nov 2012 10:45:22 -0400 Resent-From: info@meetecho.com Resent-Message-Id: <201211021445.qA2EivGT031483@mailhub-dmz-2.mit.edu> X-AuditID: 1209190c-b7f286d000000ee3-b9-5093dc8223f0 Authentication-Results: symauth.service.identifier Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B4.66.02341.18CD3905; Fri, 2 Nov 2012 10:45:22 -0400 (EDT) Received: from smtplqs-out47.aruba.it ([62.149.158.87]:34539 helo=smtplqs02.aruba.it) by grenache.tools.ietf.org with smtp (Exim 4.77) (envelope-from ) id 1TUIUn-0002U8-RW for kitten-chairs@tools.ietf.org; Fri, 02 Nov 2012 15:45:18 +0100 Received: (qmail 26403 invoked by uid 89); 2 Nov 2012 14:18:32 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplqs02.aruba.it with SMTP; 2 Nov 2012 14:18:32 -0000 Received: (qmail 17631 invoked by uid 89); 2 Nov 2012 14:18:32 -0000 Received: from unknown (HELO ?143.225.229.198?) (alex@meetecho.com@143.225.229.198) by smtp2.ad.aruba.it with ESMTPA; 2 Nov 2012 14:18:32 -0000 Message-ID: <5093D615.6000207@meetecho.com> Date: Fri, 02 Nov 2012 15:17:57 +0100 From: "info\@meetecho.com" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 To: kitten-chairs@tools.ietf.org, krb-wg-chairs@tools.ietf.org X-Helo-Check-Failed: Verification failed for HELO smtplqs02.aruba.it X-SA-Exim-Connect-IP: 62.149.158.87 X-SA-Exim-Rcpt-To: kitten-chairs@tools.ietf.org X-SA-Exim-Mail-From: info@meetecho.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on grenache.tools.ietf.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=3.0 tests=BAYES_50,GREYLIST_ISWHITE, RCVD_IN_DNSWL_NONE,X_HELO_CHECK_FAILED autolearn=no version=3.3.2 Subject: Meetecho support at IETF85 X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Resent-To: hartmans-ietf@mit.edu, shawn.emery@oracle.com, josh.howlett@ja.net List-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjm29nlOHbsODU/xTKWGl3mLSN/yDZETepHo6RIojy5kxttU3bU 1IQETaWF5NawjQKxLBUh1DRLy1xB3qbTIi3LXEXhtBKtiLLLOTvO/Pd833N5nxdeFBHX8kNQ jT6PNOgJrYQv5IoFsghp2SuzMmbhXGLCt4oZvgKkNVmGBEqQIUxUkVpNAWmIlmUK1e3Wal7u dW5hU8U4UgpuI+eBDwrxePhidozP4vXQOX2LxkJUjN8HsG12ksM+pgGsHB8XMCoxvh3aWzsA izfCmtcuDotTYe8li8CbetXa6kkFeBzsHnHz2KBJAJe63/FZQxUHti+lsDgZ/jC+XQk9A+8O 30S8/33DJoQ1mwAc/drGZQiMbjFqnvZM5uIRcNFm4zGYj0uhyzHkCQrEM+imfQJW7wcHrO89 3gBcBgfKnni8CJ4If/fXc1kcBu98ukIPQ+kNkuHcDV92mc1w8fN3Louj4bUFJ4eVRMIxYyj7 nQ57LLUru6+Dg08/AqYyxKsBbHaPeXbxp3PMzfYVkQLaBr/wL4Jw25p2tjWNbGsa1QGkGWxQ 6YqlOkKjpcgsKZVF6PWkQRobpdPkRZGq/DbA3IJPsKgLzPdJ7ABHgUSEzTSYlGIeUUAV6ewg GOVIArHDE2al2PdEjqpITVDq44Z8LUnZAUQRSQAmc9AcpiKKiklDjpcKRVEJxOKnaMrPQGaT hSc1Wvr8vDQH9WHsItqewGgwKpfQUZpslh8EO1FTY50LoO7yehcQc/U5ejIkCMtkpDgjVefr V9O89+wGQXR9f6yEUYnoa1/Nc9OjOPSo8IQaZlQe8Z8KKQX1o48i/3by9lww7C2P2bR1QpwW sCN77p6v/JTzckdPY0fK7v2qCMvP5eKkIbJB6LQWHpuZT9LZH7a8ked3t8Q+OGQ926/ed6Cq sjGibrlEbnlOORB7b1euYpHTefrIs1T5FK+36+jjwOBfB8OoXUZnnEyBpjq3/HGkvxxxGBc+ SLiUmojdhhgo4h9HLfw/qgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA1VSfUgTYRz23d3mOXZ2nl9vfmQtU8imlVISolILJLMWCJF/lJe7ttE25W6K 2geiVpIhuqHiMhAtSw3EjyixBBdimqZTSEsT7cNgpoWaSmB0t0uzf14efs/z+z3P731fDCE7 JH4YnW2iGSOll0ukaFLC7A5F/qRFtX+qA4mu/tkkiQcJ+QM9iAqkSGPUtF6XRTMRsalSbVtV iTjjPprdcHMEyQPtyG3ghkEiCt6rapHwGBAHYecbh1io+8DhqWauLsVIYhzApc5PThFJFIlg 29JxASvhWvFHIOArsGPgIbJR7x4wI0KzGcCh5VaUJ3AiDA5ZpkQ8Rok9cNFqdbpJCAWcGXzt HORNpEBbS7eroPeAfVWfnb1eRCzsK+h19iJEDFx/VYsKOAg+na/mzDAutRLO1bsLC+yGiwsr qIAjYN2PYZEgCYH24gChnAyfl1e6Cngb7B/9CvjIkCgBsNFhd+7iyc2xNNr+iuKhtf+7RMCR 0FG+Lhb2PQXNK+NOjYwIhQ77XUkpCLRu2cC6JbV1S+oagDSCQLUhV2GgdHqWTlOwaZTRSDOK w+EGnSmcVme2Au6VSVdl8DNQYJPbAIEBuQyffmBWkWIqi80x2MB2TCT3xs+OWVSk+8V0dY6W YrUXmEw9zdoAxBC5Fx47yHG4msrJpZn0DcofQ+W++Jj63WmS0FAm+jJNZ9DMBivCXG0gAMPk EG+a4Lo9GFpDZ1/S6U1bNW78IeVtZJxNNC/E2QzKwOo0gqgfRGLmRzUzAHMU1s4AEjWmG2k/ XzyVlxK8VJtp3By58aNHQKCfJw5cXFxIGZeJu4r/eQfw5a7BE7/KT5HpjKZNPwcXRcRFCY4u 46OYqH+UXx44dCIxqVE5XTQ+ZS4JujGfsVLh7vXh/HtRe1dXj2r5SXCk7HHIatyvwqC+2Fu/ j0ZKj3hcq6xNHF4on6vGusS9DZOaCn9tKaGcsHt9iW6NGz42UhbV3Cc+t+v6rGi0aOBlqKYl TJq8bydTf6drbTX+Rd1Ju+OtNrPe1xLiY5F+OyNHWS11YC/CsNQfrribOcwDAAA= X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Nov 2 10:44:39 2012 X-DSPAM-Confidence: 0.7009 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,5093dc57222705497126628 X-DSPAM-Factors: 27, Received*mit.edu>, 0.00960, Received*mail.painless, 0.99000, Received*security.com, 0.99000, Received*[18.7.62.37]), 0.01117, Received*Messaging, 0.01274, Received*Messaging, 0.01274, Received*(8.13.8/8.9.2), 0.01350, Received*mailhub, 0.01374, Received*mailhub, 0.01374, Received*1.MIT.EDU, 0.01437, Authentication-Results*symauth.service.identifier, 0.01506, Received*2.mit.edu, 0.01839, Received*2.mit.edu, 0.01839, Received*(, 0.02402, Received*1.mit.edu, 0.02457, Received*1.mit.edu, 0.02457, www, 0.02485, Date*0100, 0.97437, Date*Nov, 0.03067, Received*Nov, 0.03232, Received*Nov, 0.03232, Received*7.MIT.EDU, 0.03318, Received*7.mit.edu, 0.03318, Received*7.mit.edu, 0.03318, Received*[18.7.68.36]), 0.03318, Received*[18.9.25.12]), 0.03529, User-Agent*(Windows, 0.96242 MIME-Version: 1.0 Dear chair(s), we confirm Meetecho remote participation support for your WG meeting session @ IETF85. If you plan to have remote presenters, please let us know in proper advance so we can configure the audio feed accordingly. Further information and instructions on how to join can be found at http://ietf85.conf.meetecho.com. We kindly ask you to upload all slide decks on the meeting materials page ASAP, since we need to upload them on Meetecho as well. Thanks, the Meetecho team -- Meetecho s.r.l. www.meetecho.com --=-=-=-- From simon@josefsson.org Tue Nov 6 06:31: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 0F1FC21F893F for ; Tue, 6 Nov 2012 06:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt35q0+9JTyA for ; Tue, 6 Nov 2012 06:31:38 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC821F8922 for ; Tue, 6 Nov 2012 06:31:38 -0800 (PST) Received: from latte (host-95-193-24-90.mobileonline.telia.com [95.193.24.90]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA6EVPLv006084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Nov 2012 15:31:28 +0100 From: Simon Josefsson To: Shawn M Emery References: <509733D9.7090700__11791.6759838865$1352086504$gmane$org@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:121106:kitten@ietf.org::UMFKwaUccj/HrMIj:9Bsb X-Hashcash: 1:22:121106:shawn.emery@oracle.com::qJTrGLYFvO9VfsIF:8SCJ Date: Tue, 06 Nov 2012 15:31:20 +0100 In-Reply-To: <509733D9.7090700__11791.6759838865$1352086504$gmane$org@oracle.com> (Shawn M. Emery's message of "Sun, 04 Nov 2012 20:34:49 -0700") Message-ID: <87pq3q6bwn.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Kitten and Krb-wg Merger 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, 06 Nov 2012 14:31:39 -0000 Shawn M Emery writes: > In light of the pending merger between the kitten and Kerberos WGs we > have compiled a list of possible work items to start the > merger/recharter discussions during the combined session on Tuesday. > We are looking for feedback on this and other items that should be > considered for the new charter. I'd like to see support for one-time password / two-factor authentication needs for SASL applications. It could be achieved through an explicit new GSS-API/SASL mechanism (e.g., [1]) or if the consensus is that due to usability reasons, it is preferrable to do OTP/2FA through an higher level protocol (Kerberos/OpenID/SAML/SAML20EC/EAP?) prepare a document explaining the usability problem and provide pointers for implementers. /Simon [1] http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00 From leifj@sunet.se Tue Nov 6 06:40: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 E1D4321F8606 for ; Tue, 6 Nov 2012 06:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knt1NWwYoEkM for ; Tue, 6 Nov 2012 06:40:01 -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 27E8D21F84D3 for ; Tue, 6 Nov 2012 06:40:00 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org [130.129.9.70]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qA6Edr7f001324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Nov 2012 15:39:58 +0100 (CET) Message-ID: <50992138.9030200@sunet.se> Date: Tue, 06 Nov 2012 15:39:52 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07 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, 06 Nov 2012 14:40:02 -0000 Folks, I've reviewed version -07. I general I think the document is in good shape. Reading through it I've found a small set of relatively minor nits. - Object Type: A long list of things like "Function" and "Integer" is given but the description text basically sais these are just examples. I suggest replacing the list with the following text defined by the binding language - Registration Rules: Suggest change to say: " to Policy defined by [RFC5226] or an RFC that updates [RFC5226], for instance ..." Finally, I find the guidelines to Expert reviewers to be somewhat hard to follow. The final paragraph in section 8.2.2 to me basically reads as "use your good judgement". Personally I would find it difficult to draw any guidance from that text but I fully understand if this horse has been flogged enough. Cheers Leif From wmills@yahoo-inc.com Tue Nov 6 07:24:14 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 B87FE21F891C for ; Tue, 6 Nov 2012 07:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.788 X-Spam-Level: X-Spam-Status: No, score=-15.788 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWKh+eDBHFSl for ; Tue, 6 Nov 2012 07:24:14 -0800 (PST) Received: from nm20-vm0.bullet.mail.ac4.yahoo.com (nm20-vm0.bullet.mail.ac4.yahoo.com [98.139.53.214]) by ietfa.amsl.com (Postfix) with ESMTP id AD12A21F8914 for ; Tue, 6 Nov 2012 07:24:13 -0800 (PST) Received: from [98.139.52.188] by nm20.bullet.mail.ac4.yahoo.com with NNFMP; 06 Nov 2012 15:24:09 -0000 Received: from [98.139.52.186] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 06 Nov 2012 15:24:09 -0000 Received: from [127.0.0.1] by omp1069.mail.ac4.yahoo.com with NNFMP; 06 Nov 2012 15:24:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 564845.56786.bm@omp1069.mail.ac4.yahoo.com Received: (qmail 18558 invoked by uid 60001); 6 Nov 2012 15:24:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1352215448; bh=csQFGKwV+DJAic9at063zJW/PhT8XmETTvsCqIdaarg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FBQAyjW8SY3J0gep7JyWoe5ccyBDHv2gSvwAwBAnBvSdYNx+HMbm6+kMhKYBQeVoms8cFNLenR8kZra4uaMyLqGv781f2XhZpJ3BP9zkjjKSNLAvZb5tCQuVqGeuLqlRpS+wiC7RLdsExSgkrQ3FAbgGySK99W3ZFEekwg9bpww= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=btsoBOl/0qdwcMtkU9agAYYQFYn/T4yNHXO/O6FIdOi3+5U15tkyQ3NKcPI+Qiz9KgYx6+lBIkurJb2cOQHP1oVmLXPW//gorgeLMgUss1YY/r7j0FMXPy6AalqRBqkW6QswuVzDuPgU4YLjgRmxY4eW3zgwaVszXls0X3Ljnq4=; X-YMail-OSG: B7EIwFAVM1liolPr8vg9ffDOPXbPE28b2_c231QTZd1ncdd wf.tuLjunG8UlIJNo5sEhbWpKYPJ50VG1828x9KgSvScsi7RFmjp11PCM25n lys01WmMwJJva2YtoC7PRdxw_lJDxOOaUxBernmXdv3LbbDtVHRMqicjFyc6 _lB8XpjeAbDNP6TPW7P8fCdvhb6jDxVgqz9TBS0FwMjDCBtaUo3IW7VqXZeB 3YparDPy8ffW0RaUtB7Vo_eTdVvU.oGLx_7NckUxacWCpdlYGXQ4pnoB81E0 5h3Tdi9kUQ7h4RIHluwlaLaZpRFD94Vw6sOZDkk296L34mh2ipKj6JG0E2g_ JGgKdxFefDxyGk1jvdG37sugQsHTtYui2KZzV8bfL2kvMYtjRzGh9alhCDCl .2pCyHUVo4x0vo6AV1klNkYUpRkPHajl5ZaG5m54wlCLgkwVsNbidSZp0_wB jfAZq6qkO8avSAv93OQrGxk47 Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2012 07:24:08 PST X-Rocket-MIMEInfo: 001.001, V2h5IHdvdWxkbid0IHRoYXQganVzdCBiZSBhIFBMQUlOIHZhcmlhbnQ_wqAgUExBSU4tUlNBIGJlaW5nIGRlZmluZWQgYXMgU0FTTCBQTEFJTiB3aGVyZSB0aGUgcGFzc3dvcmQgaXMgdGhlIHBpbiBhbmQgUlNBIHRva2VuIHZhbHVlIGNvbmNhdGVuYXRlZC4KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBTaW1vbiBKb3NlZnNzb24gPHNpbW9uQGpvc2Vmc3Nvbi5vcmc.Cj5UbzogU2hhd24gTSBFbWVyeSA8c2hhd24uZW1lcnlAb3JhY2xlLmNvbT4gCj5DYzoga2l0dGVuQGkBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.460 References: <509733D9.7090700__11791.6759838865$1352086504$gmane$org@oracle.com> <87pq3q6bwn.fsf@latte.josefsson.org> Message-ID: <1352215448.18521.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Tue, 6 Nov 2012 07:24:08 -0800 (PST) From: William Mills To: Simon Josefsson , Shawn M Emery In-Reply-To: <87pq3q6bwn.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1509752018-1352215448=:18521" Cc: "kitten@ietf.org" Subject: Re: [kitten] Kitten and Krb-wg Merger 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: Tue, 06 Nov 2012 15:24:14 -0000 ---368338466-1509752018-1352215448=:18521 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Why wouldn't that just be a PLAIN variant?=A0 PLAIN-RSA being defined as SA= SL PLAIN where the password is the pin and RSA token value concatenated.=0A= =0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefsson = =0A>To: Shawn M Emery =0A>Cc:= kitten@ietf.org =0A>Sent: Tuesday, November 6, 2012 6:31 AM=0A>Subject: Re= : [kitten] Kitten and Krb-wg Merger=0A> =0A>Shawn M Emery writes:=0A>=0A>> In light of the pending merger between the kitten = and Kerberos WGs we=0A>> have compiled a list of possible work items to sta= rt the=0A>> merger/recharter discussions during the combined session on Tue= sday.=0A>> We are looking for feedback on this and other items that should = be=0A>> considered for the new charter.=0A>=0A>I'd like to see support for = one-time password / two-factor=0A>authentication needs for SASL application= s.=0A>=0A>It could be achieved through an explicit new GSS-API/SASL mechani= sm=0A>(e.g., [1]) or if the consensus is that due to usability reasons, it = is=0A>preferrable to do OTP/2FA through an higher level protocol=0A>(Kerber= os/OpenID/SAML/SAML20EC/EAP?) prepare a document explaining the=0A>usabilit= y problem and provide pointers for implementers.=0A>=0A>/Simon=0A>=0A>[1] h= ttp://tools.ietf.org/html/draft-josefsson-kitten-crotp-00=0A>______________= _________________________________=0A>Kitten mailing list=0A>Kitten@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---368338466-1509752018-1352215448=:18521 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Why would= n't that just be a PLAIN variant?  PLAIN-RSA being defined as SASL PLA= IN where the password is the pin and RSA token value concatenated.
=

=
From: Simon Josefsson <simon@josefsson.org>
To: Shawn M Emery <shawn.emery@oracle.com= >
Cc: kitten@ietf.o= rg
Sent: Tuesday, November 6= , 2012 6:31 AM
Subject: Re: [kitten] Kitten and Krb-wg Merger

Shawn M Emer= y <shawn.emery@oracle.com> writes:

> In light = of the pending merger between the kitten and Kerberos WGs we
> have c= ompiled a list of possible work items to start the
> merger/recharter= discussions during the combined session on Tuesday.
> We are looking= for feedback on this and other items that should be
> considered for= the new charter.

I'd like to see support for one-time password / tw= o-factor
authentication needs for SASL applications.

It could be = achieved through an explicit new GSS-API/SASL mechanism
(e.g., [1]) or i= f the consensus is that due to usability reasons, it is
preferrable to d= o OTP/2FA through an higher level protocol
(Kerberos/OpenID/SAML/SAML20EC= /EAP?) prepare a document explaining the
usability problem and provide p= ointers for implementers.

/Simon

[1] http://too= ls.ietf.org/html/draft-josefsson-kitten-crotp-00
___________________= ____________________________
Kitten mailing list
Kitten@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/kitten


---368338466-1509752018-1352215448=:18521-- From simon@josefsson.org Tue Nov 6 07:27:28 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 52AC721F898D for ; Tue, 6 Nov 2012 07:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6XOmOPc6UUC for ; Tue, 6 Nov 2012 07:27:27 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8530921F8924 for ; Tue, 6 Nov 2012 07:27:26 -0800 (PST) Received: from latte (host-95-193-24-90.mobileonline.telia.com [95.193.24.90]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA6FRBwt008671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Nov 2012 16:27:14 +0100 From: Simon Josefsson To: William Mills References: <509733D9.7090700__11791.6759838865$1352086504$gmane$org@oracle.com> <87pq3q6bwn.fsf@latte.josefsson.org> <1352215448.18521.YahooMailNeo__36567.958087153$1352215467$gmane$org@web31801.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:121106:wmills@yahoo-inc.com::jWLRxl0y00qd4Q9Y:1Nhi X-Hashcash: 1:22:121106:kitten@ietf.org::UbkSsEimqNOgjY/J:eF20 X-Hashcash: 1:22:121106:shawn.emery@oracle.com::Nfopq744fdUQpYzp:jwV7 Date: Tue, 06 Nov 2012 16:27:05 +0100 In-Reply-To: <1352215448.18521.YahooMailNeo__36567.958087153$1352215467$gmane$org@web31801.mail.mud.yahoo.com> (William Mills's message of "Tue, 6 Nov 2012 07:24:08 -0800 (PST)") Message-ID: <87bofa69bq.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Kitten and Krb-wg Merger 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, 06 Nov 2012 15:27:28 -0000 Right, that's one option, and I'd be interested in exploring it. CROTP is an improvement since it doesn't send clear-text passwords in the clear, but a PLAIN-OTP or similar could be easier to use in some places. /Simon William Mills writes: > Why wouldn't that just be a PLAIN variant?  PLAIN-RSA being defined as > SASL PLAIN where the password is the pin and RSA token value > concatenated. > > > > > >>________________________________ >> From: Simon Josefsson >>To: Shawn M Emery >>Cc: kitten@ietf.org >>Sent: Tuesday, November 6, 2012 6:31 AM >>Subject: Re: [kitten] Kitten and Krb-wg Merger >> >>Shawn M Emery writes: >> >>> In light of the pending merger between the kitten and Kerberos WGs we >>> have compiled a list of possible work items to start the >>> merger/recharter discussions during the combined session on Tuesday. >>> We are looking for feedback on this and other items that should be >>> considered for the new charter. >> >>I'd like to see support for one-time password / two-factor >>authentication needs for SASL applications. >> >>It could be achieved through an explicit new GSS-API/SASL mechanism >>(e.g., [1]) or if the consensus is that due to usability reasons, it is >>preferrable to do OTP/2FA through an higher level protocol >>(Kerberos/OpenID/SAML/SAML20EC/EAP?) prepare a document explaining the >>usability problem and provide pointers for implementers. >> >>/Simon >> >>[1] http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00 >>_______________________________________________ >>Kitten mailing list >>Kitten@ietf.org >>https://www.ietf.org/mailman/listinfo/kitten >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From jhutz@cmu.edu Tue Nov 6 20:11: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 338DA21F8B9F for ; Tue, 6 Nov 2012 20:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.175 X-Spam-Level: X-Spam-Status: No, score=-105.175 tagged_above=-999 required=5 tests=[AWL=1.424, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkx15vOwuAEk for ; Tue, 6 Nov 2012 20:11:58 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 370CC21F8670 for ; Tue, 6 Nov 2012 20:11:57 -0800 (PST) Received: from [192.168.202.99] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id qA74Bqf0007685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Nov 2012 23:11:53 -0500 (EST) From: Jeffrey Hutzelman To: Shawn M Emery In-Reply-To: <27373_1352086492_qA53Ypm5027830_509733D9.7090700@oracle.com> References: <27373_1352086492_qA53Ypm5027830_509733D9.7090700@oracle.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 06 Nov 2012 23:11:52 -0500 Message-ID: <1352261512.2182.15.camel@tuzanor.jhutz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Kitten and Krb-wg Merger 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, 07 Nov 2012 04:11:59 -0000 On Sun, 2012-11-04 at 20:34 -0700, Shawn M Emery wrote: > In light of the pending merger between the kitten and Kerberos WGs we > have compiled a list of possible work items to start the > merger/recharter discussions during the combined session on Tuesday. We > are looking for feedback on this and other items that should be > considered for the new charter. > * Prepare and advance a standards-track specification defining a > format for the transport of Kerberos credentials within other > protocols. This is an item taken from krb-wg's current charter. However, we actually completed that item with the publication of RFC6448 last fall. Your list omits four items which appear on the current krb-wg charter: * Set/Change Password -- I believe this was very nearly done the last time we looked at it, but that was some time ago and there's been no movement since. So, while I'm disappointed to see it go, it probably does not belong in the new charter. * IAKERB - This is in a similar situation, though I don't think it's been inactive quite as long. * IANA - This is fairly important work and is actually active right now. Of course, I'd be happy to see this left out of the charter due to having been completed before the merge is finished. * Enctype work -- The current Kerberos WG is chartered to "prepare, review, and advance" RFC3961 enctypes on an ongoing basis(*). This empowers us to do new enctype work ourselves and to review and discuss enctype work being done by individuals. While krb-wg has completed a document under this item, it was intended to be an ongoing item, such that enctype work always remains in scope. I believe this remains important for the combined WG, particularly since RFC3961 enctypes are used not only in Kerberos itself but also in an increasing number of GSS-API mechanisms which use RFC4121 per-message tokens. -- Jeff (*) Actually, it contains two items with this language. As far as I can recall, this is the result of an editing error, and only the second, more verbose paragraph should be retained. From alexey.melnikov@isode.com Thu Nov 8 06:56: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 3645621F8590 for ; Thu, 8 Nov 2012 06:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEsONzC1EYCz for ; Thu, 8 Nov 2012 06:56:16 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8916821F8419 for ; Thu, 8 Nov 2012 06:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1352386564; d=isode.com; s=selector; i=@isode.com; bh=wqv/oS/ZS67oW5rGrKyzBItNesiZdo4ncZNGq3yp2bE=; 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=C1Fyi4K7ptOWXW99TphvvkC1FY/9EmhJHbIIBbsNdOFDDqDBh+aX+WDFWz4Tgmy5+kpnWH g7Sa34sr7+7wu3S00UHIB6Fiz9yu7tN7CwDpqD6afDOZqdwDNlVM5dj8+uG8u3RGTgK+HR 8TcVlOg1Bv7j8fIst8P2lX3619JltCs=; Received: from [130.129.18.182] (dhcp-12b6.meeting.ietf.org [130.129.18.182]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Nov 2012 14:56:04 +0000 Message-ID: <509BC801.8060506@isode.com> Date: Thu, 08 Nov 2012 14:56:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Leif Johansson References: <50992138.9030200@sunet.se> In-Reply-To: <50992138.9030200@sunet.se> 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] review of draft-ietf-kitten-gssapi-extensions-iana-07 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 Nov 2012 14:56:17 -0000 On 06/11/2012 14:39, Leif Johansson wrote: > Folks, Hi Leif, Thank you for the review. > I've reviewed version -07. I general I think the document is in good shape. > Reading through it I've found a small set of relatively minor nits. > > - Object Type: A long list of things like "Function" and "Integer" is given > but the description text basically sais these are just examples. I suggest > replacing the list with the following text > > defined by the binding language > > - Registration Rules: Suggest change to say: > > " to Policy defined by [RFC5226] or an RFC that > updates [RFC5226], for instance ..." Ok, these can be done. > Finally, I find the guidelines to Expert reviewers to be somewhat hard to > follow. The final paragraph in section 8.2.2 to me basically reads as "use > your good judgement". > > Personally I would find it difficult to draw any guidance from that text > but I fully understand if this horse has been flogged enough. The short answer to this is: if we know what the exact guidance is, we wouldn't need to use the Expert Review. So this is by design. From leifj@mnt.se Thu Nov 8 07:36: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 94CE321F8699 for ; Thu, 8 Nov 2012 07:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9aSDvQsip4o for ; Thu, 8 Nov 2012 07:36:21 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04AF421F8A78 for ; Thu, 8 Nov 2012 07:36:20 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2253741pbb.31 for ; Thu, 08 Nov 2012 07:36:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=tJW9LAiM/snTESklBlzGTt+UTQV9Q5EtF7/nz5YhCZU=; b=DDeKPVVMk/G8KqYUT9Ke4XzKAUvOAfNHtqA7Jv/9IJMBuTUzK+xtSiYygUeCe1Xl/S 1wZYO/dpAcN3yM4g/ODO3RbIjjFpObAoiyV8sdCwzOFfPAv8/bPQfhH+YfZG13ZSJwon cimgKU8H92eaeaNg+nX7/Map47F5hPjKEJkuevtIIgnvJvZ9h3PjRQWoAO9GybxC5W7L +5iz1P0pZKNBz1tw5cOeCzLjCVou8bnKPaIGSKwyr6pO2TSiQODOItx35CnpJRGWR/ks V5oJC7QHj75t9nBqJdnBuiUV/TYl18MSh+c39aP7479R6PiZq/pZrOTHwph0T2CGvQuh IXNg== Received: by 10.66.85.138 with SMTP id h10mr23312510paz.40.1352388980774; Thu, 08 Nov 2012 07:36:20 -0800 (PST) Received: from ?IPv6:2001:df8:0:8:e98e:2773:e7a0:457f? ([2001:df8:0:8:e98e:2773:e7a0:457f]) by mx.google.com with ESMTPS id ju7sm16097009pbb.60.2012.11.08.07.36.19 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 07:36:20 -0800 (PST) Message-ID: <509BD173.9000606@mnt.se> Date: Thu, 08 Nov 2012 16:36:19 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alexey Melnikov , "kitten@ietf.org" References: <50992138.9030200@sunet.se> <509BC801.8060506@isode.com> In-Reply-To: <509BC801.8060506@isode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm5hbnUkBW7RZ6f2Z/1qTx0Orb7/D2JaWVuaXMcOYC6vaoUad6vuAycylDGCxZmLht8MmPd Subject: Re: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07 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 Nov 2012 15:36:21 -0000 >> >> Personally I would find it difficult to draw any guidance from that text >> but I fully understand if this horse has been flogged enough. > The short answer to this is: if we know what the exact guidance is, we > wouldn't need to use the Expert Review. So this is by design. > > I object to that answer. Expert review should absolutely have guidance. I'm fine saying "use your good judgement" or not even having a guidance section and relying on implicit good sense. However, the current text claims to provide guidance to reviewers but probably won't help anyone who doesn't already understand what to do. I say skip it, but if ppl are really married to it I'm fine with that too :-) Cheers Leif From shawn.emery@oracle.com Fri Nov 9 08:35:11 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 DE1D121F86FB for ; Fri, 9 Nov 2012 08:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7POK3PFNyL8 for ; Fri, 9 Nov 2012 08:35:08 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 05C2521F874D for ; Fri, 9 Nov 2012 08:35:07 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA9GZ6MH002314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Nov 2012 16:35:07 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA9GZ6n5007741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Nov 2012 16:35:06 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA9GZ6vk014623 for ; Fri, 9 Nov 2012 10:35:06 -0600 Received: from dhcp-14cb.meeting.ietf.org (/130.129.20.203) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Nov 2012 08:35:06 -0800 Message-ID: <509D30B9.7020209@oracle.com> Date: Fri, 09 Nov 2012 09:35:05 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [kitten] Minutes Draft - IETF 85 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, 09 Nov 2012 16:35:12 -0000 I've uploaded draft minutes of the Kitten WG session to the proceedings site: http://www.ietf.org/proceedings/85/minutes/minutes-85-kitten I would like to thank Ben Kaduk, Simon Josefsson, and Tom Yu for taking excellent notes. Please let me know if there are corrections or comments by 11/16/12. Shawn. -- kitten co-chair From ietf@meetecho.com Fri Nov 9 09:06: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 16CCF21F879F for ; Fri, 9 Nov 2012 09:06:44 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTXc0e4IiRtU for ; Fri, 9 Nov 2012 09:06:43 -0800 (PST) Received: from smtpdg9.aruba.it (smtpdg9.aruba.it [62.149.158.239]) by ietfa.amsl.com (Postfix) with ESMTP id 86F8F21F8781 for ; Fri, 9 Nov 2012 09:06:43 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV6g1k00T0ELJoa01V6hmT; Fri, 09 Nov 2012 18:06:42 +0100 Message-ID: <509D381E.5070906@meetecho.com> Date: Fri, 09 Nov 2012 18:06:38 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-krb-wg@anl.gov Subject: [kitten] Meetecho session recording 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, 09 Nov 2012 17:06:44 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings 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-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From hannes.tschofenig@gmx.net Sun Nov 18 23:46: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 5D7AB21F8616 for ; Sun, 18 Nov 2012 23:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf9m4V4dRMPV for ; Sun, 18 Nov 2012 23:46:57 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5AA7F21F862B for ; Sun, 18 Nov 2012 23:46:56 -0800 (PST) Received: (qmail invoked by alias); 19 Nov 2012 07:43:34 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 19 Nov 2012 08:43:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/7/gOval/Wwu4/8SGMKTxxxjvHvB8gzuXcDCELW xD2oe2CoUbJpaT From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2012 09:43:32 +0200 Message-Id: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [kitten] Updating OAuth SASL 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, 19 Nov 2012 07:46:58 -0000 Hi all,=20 I have incorporated Alexey's comments into the draft and also my own = earlier review comments.=20 Here is the current snapshot: = https://github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/= draft-ietf-kitten-sasl-oauth-09.txt There is one issue that Alexey raised, which I still have to understand = better myself, namely: ----- 3.2.2. Canonicalization The identity asserted by the OAuth authorization server is canonical for display. The server MAY provide a different canonical form based on local data. I don't understand the second sentence. SASL server? How can it do that? ------ Ciao Hannes From shawn.emery@oracle.com Mon Nov 19 00:49: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 3186221F8458 for ; Mon, 19 Nov 2012 00:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQRh3GkP4f9e for ; Mon, 19 Nov 2012 00:49:02 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8776921F849F for ; Mon, 19 Nov 2012 00:49:02 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAJ8mxvT024428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Nov 2012 08:49:00 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAJ8mwYp000748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 08:48:59 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAJ8mwvw028811; Mon, 19 Nov 2012 02:48:58 -0600 Received: from [10.159.110.232] (/10.159.110.232) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Nov 2012 00:48:58 -0800 Message-ID: <50A9F225.8050103@oracle.com> Date: Mon, 19 Nov 2012 01:47:33 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.7) Gecko/20121011 Thunderbird/10.0.7 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <27373_1352086492_qA53Ypm5027830_509733D9.7090700@oracle.com> <1352261512.2182.15.camel@tuzanor.jhutz.local> In-Reply-To: <1352261512.2182.15.camel@tuzanor.jhutz.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: kitten@ietf.org Subject: Re: [kitten] Kitten and Krb-wg Merger 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, 19 Nov 2012 08:49:03 -0000 On 11/6/12 9:11 PM, Jeffrey Hutzelman wrote: > On Sun, 2012-11-04 at 20:34 -0700, Shawn M Emery wrote: >> In light of the pending merger between the kitten and Kerberos WGs we >> have compiled a list of possible work items to start the >> merger/recharter discussions during the combined session on Tuesday. We >> are looking for feedback on this and other items that should be >> considered for the new charter. >> * Prepare and advance a standards-track specification defining a >> format for the transport of Kerberos credentials within other >> protocols. > This is an item taken from krb-wg's current charter. However, we > actually completed that item with the publication of RFC6448 last fall. Sorry, this was elided from the list that was presented during the working group session. I will send out an updated list along with interest from the session's participants for each of the items discussed. > > Your list omits four items which appear on the current krb-wg charter: > > * Set/Change Password -- I believe this was very nearly done the last > time we looked at it, but that was some time ago and there's been no > movement since. So, while I'm disappointed to see it go, it probably > does not belong in the new charter. Someone can correct me if I'm wrong, but there were no current volunteers for progressing this work item. > * IAKERB - This is in a similar situation, though I don't think it's > been inactive quite as long. Same as above. > * IANA - This is fairly important work and is actually active right now. > Of course, I'd be happy to see this left out of the charter due to > having been completed before the merge is finished. Yes, this was also on the list discussed during the session and probably won't be completed before the recharter. > * Enctype work -- The current Kerberos WG is chartered to "prepare, > review, and advance" RFC3961 enctypes on an ongoing basis(*). This > empowers us to do new enctype work ourselves and to review and discuss > enctype work being done by individuals. While krb-wg has completed a > document under this item, it was intended to be an ongoing item, such > that enctype work always remains in scope. I believe this remains > important for the combined WG, particularly since RFC3961 enctypes are > used not only in Kerberos itself but also in an increasing number of > GSS-API mechanisms which use RFC4121 per-message tokens. During the session, this was discussed and was merged into one work item. > > (*) Actually, it contains two items with this language. As far as I can > recall, this is the result of an editing error, and only the second, > more verbose paragraph should be retained. Thanks for your review Jeff. I should have the updated list (with interest polled during the session) on the alias in about a week. Shawn. -- kitten co-chair From alexey.melnikov@isode.com Mon Nov 19 03:39:27 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 6025721F85C2 for ; Mon, 19 Nov 2012 03:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i42vQnAssDQ6 for ; Mon, 19 Nov 2012 03:39:26 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id CD79221F8564 for ; Mon, 19 Nov 2012 03:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1353325158; d=isode.com; s=selector; i=@isode.com; bh=5ddRsH5KnjE/06qHFsVwWRT3T2hRmodwTf6tn6CuetQ=; 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=RzWQl1rxPvSpgJIIhMS9Y843ewqE3JaZK8reNSwvGs4tyxswGvQYVBK1mmqDRiOdB0UviD BlzZliz7z70PimxjQNGVTh/64X5qBifKxlFIlzgp77CQZeKbIzilW2+kcI1kJ2KhZZyKwA fKBb5K42fS4tpg8tF+scNT5c95jwOa0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 19 Nov 2012 11:39:18 +0000 Message-ID: <50AA1A89.70206@isode.com> Date: Mon, 19 Nov 2012 11:39:53 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Hannes Tschofenig References: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> In-Reply-To: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> 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] Updating OAuth SASL 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, 19 Nov 2012 11:39:27 -0000 On 19/11/2012 07:43, Hannes Tschofenig wrote: > Hi all, Hi Hannes, > I have incorporated Alexey's comments into the draft and also my own earlier review comments. > Here is the current snapshot: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/draft-ietf-kitten-sasl-oauth-09.txt > > There is one issue that Alexey raised, which I still have to understand better myself, namely: Are you agreeing with me that the last sentence is not clear? I suspect it is wrong and should be deleted, but whoever wrote it should comment on that. > ----- > > 3.2.2. Canonicalization > > The identity asserted by the OAuth authorization server is canonical > for display. The server MAY provide a different canonical form based > on local data. > > I don't understand the second sentence. SASL server? How can it do that? > > ------ From william_john_mills@yahoo.com Mon Nov 19 16:51:52 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 CD67821F8460 for ; Mon, 19 Nov 2012 16:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.934 X-Spam-Level: X-Spam-Status: No, score=-16.934 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSOO8PhFFl-E for ; Mon, 19 Nov 2012 16:51:52 -0800 (PST) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by ietfa.amsl.com (Postfix) with ESMTP id CC71D21F847D for ; Mon, 19 Nov 2012 16:51:51 -0800 (PST) Received: from [98.139.212.145] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2012 00:51:51 -0000 Received: from [98.139.212.228] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2012 00:51:51 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 20 Nov 2012 00:51:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 175658.9851.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 18990 invoked by uid 60001); 20 Nov 2012 00:51:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353372710; bh=9CgtvGGYt6yxz0ST2Oa40VI70Ecb11xP2j3qryioRbs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sniGyM04lsLc63EFVpG2DdO+Ho0F+B21jUEtlf6hg0C5m1Ib1rzmvVN1bL/xRPpMgQWiHucZhWTW+WmVBzOAXP7EllS/Lb2rUqVCK1bHGO6A4aLGjaHXlyiTWdiiU6eSvzgTSJ/l/ejmsrgbXTzoidf0xQDryMtEuehTOnR0I4k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QoJ6wLGtF3m984d620M/5kAZWi6kdi4QTTvvkxxFl5xM6cr/Kw5aAZd89Jo8hh6V5T/29G6K+NxvLsFpVsHSkVuqqgYjezqsuR6+0HFko7mtOhaPdCtIgehLZ3QQ0D/PsrpMGeY5Ond+gTHhbcKEhYCz/7T/QMcczogqTJMvQLY=; X-YMail-OSG: PmLYLJkVM1nFn9EGHRr49ZcjxPFbEJSHUlHpTiNnY9lJKNx AgvZ5jcs38Mmu4o0vlkxtKB4K14NhBZ05DEdhyjOWbVWcfcAPtgU6zlz7Ybv 39YvKw1JhSItGWHMVdSvANo1weftk2IYeI5EWTYZ4uDkgJxuSwBWxyA0.IEK VJNikB1i8GnK7QqLOcHh04_Q5B8elCLGH.Nb7QyiWIDDeMEanPQ4kj_rrJGm v_J01vjnOA6N6HgUUqTAzCc67jidBZwBuSDQL6gmCaFgUyRDqaESestED6.J pS314tpL8lmletLDiPhugvQfog925hTetyPDSOgjNwe0BVb1Yvs4Bf9Uly6H LW7n8nyqtIsUQaE0AKMcDSaR7ofuWOAUdQESNUZh_mkZdDdoMqN3o9nLXOaE b.YE0gnmOVEfxzbtRcBl8MtpTTPywDJzvofwUwIyzDGzvnE8uA6xR76gldDw RaZREhQSS59N7MbI7kp2rWmT_UN_OLVg0Ycd7iIQ6JkKK7yKrRbqGKrmq8JH 1d3pem0KB0sD4DXrpIB_qlXTCAfKjJJR0bYueQje4NOm_kCDrkoCzborC._3 wnYma455reumJexVoNvF6uvQqAvP2abZGbeFnA1UJbUzFsCKaW7VIo0RHMUK V8SuimtDFo1nIYZRLD_0D Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Mon, 19 Nov 2012 16:51:49 PST X-Rocket-MIMEInfo: 001.001, VGhlIFNBU0wgc2VydmVyIG1pZ2h0IGhhdmUgYSBkaXNwbGF5IG5hbWUgZm9yIGEgbG9jYWwgbWFpbGJveCBmb3IgZXhhbXBsZSwgc28gaXQgbWlnaHQgZGlzcGxheSBhIGRpZmZlcmVudCBkaXNwbGF5IG5hbWUgdGhhbiB0aGUgb25lIHByb3ZpZGVkLgoKCgoKCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IEFsZXhleSBNZWxuaWtvdiA8YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbT4KPlRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gCj5DYzoBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.126.469 References: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> <50AA1A89.70206@isode.com> Message-ID: <1353372709.15179.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 19 Nov 2012 16:51:49 -0800 (PST) From: William Mills To: Alexey Melnikov , Hannes Tschofenig In-Reply-To: <50AA1A89.70206@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-1844479746-1353372709=:15179" Cc: "kitten@ietf.org" Subject: Re: [kitten] Updating OAuth SASL 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: Tue, 20 Nov 2012 00:51:52 -0000 ---551393103-1844479746-1353372709=:15179 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The SASL server might have a display name for a local mailbox for example, = so it might display a different display name than the one provided.=0A=0A= =0A=0A=0A=0A>________________________________=0A> From: Alexey Melnikov =0A>To: Hannes Tschofenig =0A>Cc: kitten@ietf.org =0A>Sent: Monday, November 19, 2012 3:39 AM=0A>S= ubject: Re: [kitten] Updating OAuth SASL=0A> =0A>On 19/11/2012 07:43, Hanne= s Tschofenig wrote:=0A>> Hi all,=0A>Hi Hannes,=0A>> I have incorporated Ale= xey's comments into the draft and also my own earlier review comments.=0A>>= Here is the current snapshot:=0A>> https://github.com/hannestschofenig/tsc= hofenig-ids/blob/master/sasl-oauth/draft-ietf-kitten-sasl-oauth-09.txt=0A>>= =0A>> There is one issue that Alexey raised, which I still have to understa= nd better myself, namely:=0A>Are you agreeing with me that the last sentenc= e is not clear?=0A>=0A>I suspect it is wrong and should be deleted, but who= ever wrote it should =0A>comment on that.=0A>> -----=0A>>=0A>> 3.2.2.=A0 Ca= nonicalization=0A>>=0A>>=A0 =A0 The identity asserted by the OAuth authoriz= ation server is canonical=0A>>=A0 =A0 for display.=A0 The server MAY provid= e a different canonical form based=0A>>=A0 =A0 on local data.=0A>>=0A>> I d= on't understand the second sentence. SASL server? How can it do that?=0A>>= =0A>> ------=0A>=0A>_______________________________________________=0A>Kitt= en mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo= /kitten=0A>=0A>=0A> ---551393103-1844479746-1353372709=:15179 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The SASL = server might have a display name for a local mailbox for example, so it mig= ht display a different display name than the one provided.

From:= Alexey Melnikov <alexey.melnikov@isode.com>
To: Hannes Tschofenig <hannes.tschofenig@gm= x.net>
Cc: kitten@i= etf.org
Sent: Monday, November 19= , 2012 3:39 AM
Subject: Re: [kitten] Updating OAuth SASL

On 19/11/2012 07:= 43, Hannes Tschofenig wrote:
> Hi all,
Hi Hannes,
> I have i= ncorporated Alexey's comments into the draft and also my own earlier review= comments.
> Here is the current snapshot:
> https://github.com/hannestsc= hofenig/tschofenig-ids/blob/master/sasl-oauth/draft-ietf-kitten-sasl-oauth-= 09.txt
>
> There is one issue that Alexey raised, which I s= till have to understand better myself, namely:
Are you agreeing with me = that the last sentence is not clear?

I suspect it is wrong and shoul= d be deleted, but whoever wrote it should
comment on that.
> -----
>
> 3.2.2.  Canonicalization
>
>  =   The identity asserted by the OAuth authorization server is canonical=
>    for display.  The server MAY provide a different= canonical form based
>    on local data.
>
> I= don't understand the second sentence. SASL server? How can it do that?
= >
> ------

_______________________________________________<= br>Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/li= stinfo/kitten


---551393103-1844479746-1353372709=:15179-- From william_john_mills@yahoo.com Mon Nov 19 16:53: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 B896821F884E for ; Mon, 19 Nov 2012 16:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.995 X-Spam-Level: X-Spam-Status: No, score=-16.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU4lBW-tc8aH for ; Mon, 19 Nov 2012 16:53:08 -0800 (PST) Received: from nm4-vm4.bullet.mail.ne1.yahoo.com (nm4-vm4.bullet.mail.ne1.yahoo.com [98.138.91.164]) by ietfa.amsl.com (Postfix) with ESMTP id DFD0021F847D for ; Mon, 19 Nov 2012 16:53:07 -0800 (PST) Received: from [98.138.90.51] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 20 Nov 2012 00:53:03 -0000 Received: from [98.138.89.245] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 20 Nov 2012 00:53:03 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 20 Nov 2012 00:53:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 919233.61517.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 48572 invoked by uid 60001); 20 Nov 2012 00:53:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353372783; bh=gpEHQrg1B/lfF0UHYhz2B/rigQsL6YqRK8uHPRyOWHE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=duBxdRQ2uSUlflVedxEFRfUmOncoqFafqCV7kzjBdjXz7WwDqjNOohBpCXb6Iz6t7ogTP/Qkq4JH9ozrAymhLjRjBCq+HE5lWS1ox18EMXO8eUnY25wSJlShAEsAVzjDkRgP2X5erqUzbXSUDb3eQQFIyW0MmdbOz5WR41FZ7dA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=A63lZSWP9PVue6nZBB5ohdAg5M5ETAxTZH/QPckb67xJ+M6OOg+EXMrsE41DQFdR+Gi+8hqOEKB8qzCMRDfy3Mt9FlfKiuxn3T1PM3NMpKn12SgNBCajd6p+GKfZOIqgd7cMFDKESYueP9fWExBMedSQTlGysfJl6F6SCcHLlmc=; X-YMail-OSG: Gf1TMrsVM1nlBh2mqY_CGEsKCpMpiEeqbAm7PiPu4hXOXNr WbBIQmEuGtOaUScB3LSAXBM5XpmtiBW5QBriouYGGAWiY9HYYrHxyOamb4My OdD.nRUYylTqsT4xkzLLo3JzQbv6dvWVozY9S8.Cxwo.AngFElmtF.z1dfb9 .WHGCRr7dYTNDEPC2uVZ.1csmnI_IlLPjuqCpCS_TfzP_rHPB4uf3a52Q5la dB20F2pGDTiVDEc8WvigvEHtbt20z6f7DwcM8x3H94c7yFZrYs6e5emQnEDa IpLwigOxD1.Ur1roM7MFBFS5Wl1KNhsh1togfbY_xrCAmD3SJQ4SWHUQ3nz4 PU1.t2ZVJ3nAS2t.dH4tSmpgYptU2MItajFrf92ZFiwpgZp0hFrmkO3owcRq LTf8uY.w609fi_Ajls0KmCHDqHJuJXhi8o_QsKeJ2wvM_kiy4bGpYZ_xpOio p_tuSYf94Hwf.U.z2mertem_3RSjs4vOmJgBKG48SZ5wfHGsuFcaw3GpC1Sz gxJN7kK1FOfaSk5n18N8pn2wtNA_z5nrSocuqIOOaBoBTGAst8j2SEiR9MLy XdqVvUmNyyCjtGNMwrSUzJlpXdSVOCt7co4Q0kz90JNLL3qCobdyGFLQRfa2 jTSGmZHR7x.n5A6b.VAv4 Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Mon, 19 Nov 2012 16:53:02 PST X-Rocket-MIMEInfo: 001.001, V2UgY2FuIHN0cmlrZSB0aGF0IHNlY29uZCBzZW50ZW5jZSBpZiB5b3Ugd2FudCwgaXQgd2FzIHRoZXJlIHRvIHRyeSB0byBjbGFyaWZ5LCBhbmQgaWYgaXQncyBub3QgZG9pbmcgdGhhdCBraWxsIGl0LiAKCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4KPlRvOiBraXR0ZW5AaWV0Zi5vcmcgCj5TZW50OiBTdW5kYXksIE5vdmVtYmVyIDE4LCAyMDEyIDExOjQzIFBNCj5TdWJqZWN0OiBba2l0dGUBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.126.469 References: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> Message-ID: <1353372782.48256.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 19 Nov 2012 16:53:02 -0800 (PST) From: William Mills To: Hannes Tschofenig , "kitten@ietf.org" In-Reply-To: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-318394802-1353372782=:48256" Subject: Re: [kitten] Updating OAuth SASL 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: Tue, 20 Nov 2012 00:53:08 -0000 --835683298-318394802-1353372782=:48256 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We can strike that second sentence if you want, it was there to try to clar= ify, and if it's not doing that kill it. =0A=0A=0A=0A=0A=0A>_______________= _________________=0A> From: Hannes Tschofenig = =0A>To: kitten@ietf.org =0A>Sent: Sunday, November 18, 2012 11:43 PM=0A>Sub= ject: [kitten] Updating OAuth SASL=0A> =0A>Hi all, =0A>=0A>I have incorpora= ted Alexey's comments into the draft and also my own earlier review comment= s. =0A>Here is the current snapshot:=0A>https://github.com/hannestschofenig= /tschofenig-ids/blob/master/sasl-oauth/draft-ietf-kitten-sasl-oauth-09.txt= =0A>=0A>There is one issue that Alexey raised, which I still have to unders= tand better myself, namely:=0A>=0A>-----=0A>=0A>3.2.2.=A0 Canonicalization= =0A>=0A>=A0 The identity asserted by the OAuth authorization server is cano= nical=0A>=A0 for display.=A0 The server MAY provide a different canonical f= orm based=0A>=A0 on local data.=0A>=0A>I don't understand the second senten= ce. SASL server? How can it do that?=0A>=0A>------=0A>=0A>Ciao=0A>Hannes=0A= >=0A>_______________________________________________=0A>Kitten mailing list= =0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>= =0A> --835683298-318394802-1353372782=:48256 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
We can st= rike that second sentence if you want, it was there to try to clarify, and = if it's not doing that kill it.


<= span style=3D"font-weight:bold;">From: Hannes Tschofenig <han= nes.tschofenig@gmx.net>
To: kitten@ietf.org
Sent: Sunday, November 18, 2012 11:43 PM
Subject: [kitten] Updating OAuth SASL
=
Hi all,

I have incorporated Alexey's comments into the draft a= nd also my own earlier review comments.
Here is the current snapshot:https://= github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/draft-iet= f-kitten-sasl-oauth-09.txt

There is one issue that Alexey raised= , which I still have to understand better myself, namely:

-----
<= br>3.2.2.  Canonicalization

  The identity asserted by the= OAuth authorization server is canonical
  for display.  The s= erver MAY provide a different canonical form based
  on local data.=

I don't understand the second sentence. SASL server? How can it do that?

------

Ciao
Hannes

_________________________= ______________________
Kitten mailing list
Kitten@ietf.org
https:/= /www.ietf.org/mailman/listinfo/kitten


--835683298-318394802-1353372782=:48256-- From hannes.tschofenig@gmx.net Thu Nov 22 06:38: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 0FCEE21F8596 for ; Thu, 22 Nov 2012 06:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDpPR8VSoIV9 for ; Thu, 22 Nov 2012 06:38:53 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5E07E21F8B1F for ; Thu, 22 Nov 2012 06:38:53 -0800 (PST) Received: (qmail invoked by alias); 22 Nov 2012 14:38:51 -0000 Received: from unknown (EHLO [10.255.131.102]) [194.251.119.201] by mail.gmx.net (mp030) with SMTP; 22 Nov 2012 15:38:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZuslKVsWZ9i2dtIkzsn/GbsX0CprhgCrlfalVd3 aLX04GJD35p2jJ Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1353372782.48256.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 22 Nov 2012 16:38:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> <1353372782.48256.YahooMailNeo@web31804.mail.mud.yahoo.com> To: William Mills , Alexey Melnikov X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org Subject: Re: [kitten] Updating OAuth SASL 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, 22 Nov 2012 14:38:55 -0000 Hi Bill, Hi Alexey,=20 I am wondering whether we couldn't just re-use the text we have in the = SASL OpenID specification.=20 Here is the relevant text from Section 4.1 of RFC 6616: ---- 4.1. GSS-API Principal Name Types for OpenID OpenID supports standard generic name syntaxes for acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see Section 4.1 of [RFC2743]). OpenID supports only a single name type for initiators: GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for OpenID. OpenID name normalization is covered by the OpenID specification; see Section 7.2 of [OpenID]. The query, display, and exported name syntaxes for OpenID principal names are all the same. There are no OpenID-specific name syntaxes -- applications should use generic GSS-API name types such as GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see=20 Section 4 of [RFC2743]). The exported name token does, of course, = conform to Section 3.2 of [RFC2743], but the "NAME" part of the token should be treated as a potential input string to the OpenID name normalization rules. For example, the OpenID Identifier "https://openid.example/" will have a GSS_C_NT_USER_NAME value of "https://openid.example/". GSS-API name attributes may be defined in the future to hold the normalized OpenID Identifier. ------- Of course instead of talking about OpenID identifiers (as URIs) we would = be talking about resource owner identifiers, for example, the = "Principal" defined in Section 4.1.6 of JWT (in case a JSON-based = structure is used to encode information, as it was done with OpenID = Connect). Note that the JWT spec does not define the syntax of the = principal identifier.=20 Section 3.2.1 and Section 3.2.2 of the current OAuth SASL draft would be = impacted.=20 Does this sound reasonable?=20 Ciao Hannes On Nov 20, 2012, at 2:53 AM, William Mills wrote: > We can strike that second sentence if you want, it was there to try to = clarify, and if it's not doing that kill it.=20 >=20 >=20 > From: Hannes Tschofenig > To: kitten@ietf.org=20 > Sent: Sunday, November 18, 2012 11:43 PM > Subject: [kitten] Updating OAuth SASL >=20 > Hi all,=20 >=20 > I have incorporated Alexey's comments into the draft and also my own = earlier review comments.=20 > Here is the current snapshot: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/= draft-ietf-kitten-sasl-oauth-09.txt >=20 > There is one issue that Alexey raised, which I still have to = understand better myself, namely: >=20 > ----- >=20 > 3.2.2. Canonicalization >=20 > The identity asserted by the OAuth authorization server is canonical > for display. The server MAY provide a different canonical form = based > on local data. >=20 > I don't understand the second sentence. SASL server? How can it do = that? >=20 > ------ >=20 > Ciao > Hannes >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 From william_john_mills@yahoo.com Thu Nov 22 16:17: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 CD8D421F850A for ; Thu, 22 Nov 2012 16:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.045 X-Spam-Level: X-Spam-Status: No, score=-17.045 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+yuVpHrs8IU for ; Thu, 22 Nov 2012 16:17:18 -0800 (PST) Received: from nm23-vm2.bullet.mail.ne1.yahoo.com (nm23-vm2.bullet.mail.ne1.yahoo.com [98.138.91.211]) by ietfa.amsl.com (Postfix) with ESMTP id D950A21F8466 for ; Thu, 22 Nov 2012 16:17:17 -0800 (PST) Received: from [98.138.90.54] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 00:17:12 -0000 Received: from [98.138.226.162] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 00:17:11 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 00:17:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 909144.40034.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 1097 invoked by uid 60001); 23 Nov 2012 00:17:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353629831; bh=6doFpyAC6ppZ1MMcRrCtbDdu9SsbFPSghbfGs6Dq8fQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5jJ3PXxIqTiSwGgT9OBqzlHtGsWdFWuL7ij2F9R54J8IPoPLOTAbD0htDsSlq4U45Wp3pUUxu02mTxw15OxRMfQ4Xtkjz41ptj6fXOuM4/e3qmwoyijaFjmKelz5Cs5i+dEFXlY83/jg8rRR06/k5jFFop9uKWHYL10DZD/JUOs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=owv/+ru815BXI9H9uH/TvYataUkHCwVeCGMneO/M1VNoVqRqyJJp/uIH63fy1ew5UTzKHfAMyTKwSYH6d5ubUqYGSgIjrGVS9gZPhlUXmPTvq1qbhSyEuCL6HuYOB6HM8iWfMPinXqyaotTsqBy2jCKGQBQbeMPR1sVe6SiNayk=; X-YMail-OSG: p6TrsnEVM1nJqYQnanvQkRCeE2_r_Q9P0R._B1TEIiV5GB. TIjOb7zqr_sGvgMSuVWXt8KxcDVHRKAFD0wLn3.kBDVFzzBAwOQQyVsxsPRX 2i_QRZirGWe6WCaNjRsYNXo_0LlkwpUpQuOq.QaYZRhEzkMjQ7IJsJ4idA8Z SDa0mWh96nnj6p5FnrHhInV2hxRq_gs_KnOWpxCChQL6259aZyZB5Em0iBa3 vMMyY8QQlkqEsCPecY8IKxO15_qPjVyeB4fwzPZqSa4z4caGQB5Q_XUgpOhY 4kfnEVMk5WVOUxwE0A4JwlmTvUh7SAAYjl13q8uXCxNEUlssTUVx4kT4WAeU cSOITVG8MRKcNcQJ3UO5jlOI0Sz_60w6r5m0.l5QlmvClyd4H3V39n2SaJ9Q Fy0i1m0hYDOg7HNRiWK..W7nAlH2IjO35LAhr8zyin7p09aq4zm9_ECImNjq wXDLbWqpNeTzqXEii4vpulyqi5kNRXa.gomJ9XzMGXzeLPiv63igUQ7KvmQm M6IJpNAZ37SV1twotDgwkJxHunNLKvmrD8JgnNUm3WE8v61arb4IYmzsO2kH T4PNQgFDNEzVMJ.03gVzJKXswZgL_8Lu5xVIFxybK9aUPmURKf3QVljPk_Ij .4esqbo23b1pKq.23cPoHfA-- Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Thu, 22 Nov 2012 16:17:11 PST X-Rocket-MIMEInfo: 001.001, Tm93aGVyZSBpbiBPQXV0aCBkbyB3ZSB0YWxrIGFib3V0IG5vcm1hbGl6aW5nIG9yIGNhbm9uaWNhbGl6aW5nIG5hbWVzIElJUkMsIHNvIHRoZXJlJ3MgYXQgbGVhc3Qgb25lIHdheSB0aGlzIHdvbid0IHdvcmsuwqDCoCBJIGtub3cgd2hhdCBwcm9ibGVtIEkgd2FzIHRyeWluZyB0byBzb2x2ZSB3aXRoIHRoYXQgbGFuZ3VhZ2UsIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGxhbmd1YWdlIHNvbHZlcyB0aGUgcHJvYmxlbS7CoCBQZXJoYXBzIGl0IGRvZXNuJ3QgbmVlZCBzb2x2aW5nLCBJIGNvdWxkIGJlbGlldmUgdGgBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.127.475 References: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> <1353372782.48256.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1353629831.97525.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 22 Nov 2012 16:17:11 -0800 (PST) From: William Mills To: Hannes Tschofenig , Alexey Melnikov In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1335605788-1353629831=:97525" Cc: "kitten@ietf.org" Subject: Re: [kitten] Updating OAuth SASL 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: Fri, 23 Nov 2012 00:17:21 -0000 ---368338466-1335605788-1353629831=:97525 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Nowhere in OAuth do we talk about normalizing or canonicalizing names IIRC,= so there's at least one way this won't work.=A0=A0 I know what problem I w= as trying to solve with that language, I don't see how this language solves= the problem.=A0 Perhaps it doesn't need solving, I could believe that.=A0 = I think we need to define a way for the server to get (or derive by DB look= up for example) the identity out of the token, and we should also define ho= w a server might get the client identity.=A0 Since nothing in the token is = defined as usable for display the current text also addresses that by addin= g it as a requirement.=0A=0AHow does the proposed language solve these thin= gs?=0A=0A-bill=0A=0A=0A=0A=0A=0A>________________________________=0A> From:= Hannes Tschofenig =0A>To: William Mills ; Alexey Melnikov =0A>Cc: Hannes= Tschofenig ; kitten@ietf.org =0A>Sent: Thursday= , November 22, 2012 6:38 AM=0A>Subject: Re: [kitten] Updating OAuth SASL=0A= > =0A>Hi Bill, Hi Alexey, =0A>=0A>I am wondering whether we couldn't just r= e-use the text we have in the SASL OpenID specification. =0A>Here is the re= levant text from Section 4.1 of RFC 6616:=0A>=0A>----=0A>=0A>4.1.=A0 GSS-AP= I Principal Name Types for OpenID=0A>=0A>=A0 OpenID supports standard gene= ric name syntaxes for acceptors such as=0A>=A0 GSS_C_NT_HOSTBASED_SERVICE = (see Section 4.1 of [RFC2743]).=0A>=0A>=A0 OpenID supports only a single n= ame type for initiators:=0A>=A0 GSS_C_NT_USER_NAME.=A0 GSS_C_NT_USER_NAME = is the default name type for=0A>=A0 OpenID.=0A>=0A>=A0 OpenID name normal= ization is covered by the OpenID specification; see=0A>=A0 Section 7.2 of = [OpenID].=0A>=0A>=A0 The query, display, and exported name syntaxes for Op= enID principal=0A>=A0 names are all the same.=A0 There are no OpenID-speci= fic name syntaxes=0A>=A0 -- applications should use generic GSS-API name t= ypes such as=0A>=A0 GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see= =0A>=A0 Section 4 of [RFC2743]).=A0 The exported name token does, of cour= se, conform to=0A>=A0 Section 3.2 of [RFC2743], but the "NAME" part of the = token should be=0A>=A0 treated as a potential input string to the OpenID n= ame normalization=0A>=A0 rules.=A0 For example, the OpenID Identifier "htt= ps://openid.example/"=0A>=A0 will have a GSS_C_NT_USER_NAME value of "http= s://openid.example/".=0A>=0A>=A0 GSS-API name attributes may be defined in= the future to hold the=0A>=A0 normalized OpenID Identifier.=0A>=0A>------= -=0A>Of course instead of talking about OpenID identifiers (as URIs) we wou= ld be talking about resource owner identifiers, for example, the "Principal= " defined in Section 4.1.6 of JWT (in case a JSON-based structure is used t= o encode information, as it was done with OpenID Connect). Note that the JW= T spec does not define the syntax of the principal identifier. =0A>=0A>Sect= ion 3.2.1 and Section 3.2.2 of the current OAuth SASL draft would be impact= ed. =0A>=0A>Does this sound reasonable? =0A>=0A>Ciao=0A>Hannes=0A>=0A>On No= v 20, 2012, at 2:53 AM, William Mills wrote:=0A>=0A>> We can strike that se= cond sentence if you want, it was there to try to clarify, and if it's not = doing that kill it. =0A>> =0A>> =0A>> From: Hannes Tschofenig =0A>> To: kitten@ietf.org =0A>> Sent: Sunday, November 18, 20= 12 11:43 PM=0A>> Subject: [kitten] Updating OAuth SASL=0A>> =0A>> Hi all, = =0A>> =0A>> I have incorporated Alexey's comments into the draft and also m= y own earlier review comments. =0A>> Here is the current snapshot:=0A>> htt= ps://github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/draf= t-ietf-kitten-sasl-oauth-09.txt=0A>> =0A>> There is one issue that Alexey r= aised, which I still have to understand better myself, namely:=0A>> =0A>> -= ----=0A>> =0A>> 3.2.2.=A0 Canonicalization=0A>> =0A>>=A0 The identity asse= rted by the OAuth authorization server is canonical=0A>>=A0 for display.= =A0 The server MAY provide a different canonical form based=0A>>=A0 on loc= al data.=0A>> =0A>> I don't understand the second sentence. SASL server? Ho= w can it do that?=0A>> =0A>> ------=0A>> =0A>> Ciao=0A>> Hannes=0A>> =0A>> = _______________________________________________=0A>> Kitten mailing list=0A= >> Kitten@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/kitten=0A>> = =0A>> =0A>=0A>=0A>=0A> ---368338466-1335605788-1353629831=:97525 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Nowhere i= n OAuth do we talk about normalizing or canonicalizing names IIRC, so there= 's at least one way this won't work.   I know what problem I was = trying to solve with that language, I don't see how this language solves th= e problem.  Perhaps it doesn't need solving, I could believe that.&nbs= p; I think we need to define a way for the server to get (or derive by DB l= ookup for example) the identity out of the token, and we should also define= how a server might get the client identity.  Since nothing in the tok= en is defined as usable for display the current text also addresses that by= adding it as a requirement.

How does the proposed language solve th= ese things?

-bill


From: = Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: William Mills <wmills@yahoo-inc.com>= ;; Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Hannes Tschofenig <hannes.tschofenig@= gmx.net>; kitten@ietf.org
Sen= t: Thursday, November 22, 2012 6:38 AM
Subject: Re: [kitten] Updating OAuth SASL
Hi Bill, Hi Alexey,

I am wondering whether we couldn't jus= t re-use the text we have in the SASL OpenID specification.
Here is the= relevant text from Section 4.1 of RFC 6616:

----

4.1.  = GSS-API Principal Name Types for OpenID

  OpenID supports stan= dard generic name syntaxes for acceptors such as
  GSS_C_NT_HOSTBA= SED_SERVICE (see Section 4.1 of [RFC2743]).

  OpenID supports = only a single name type for initiators:
  GSS_C_NT_USER_NAME. = ; GSS_C_NT_USER_NAME is the default name type for
  OpenID.
  OpenID name normalization is covered by the OpenID specification; = see
  Section 7.2 of [OpenID].

  The query, display, = and exported name syntaxes for OpenID principal
  names are all th= e same.  There are no OpenID-specific name syntaxes
 =20 -- applications should use generic GSS-API name types such as
  G= SS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see
  Section 4= of [RFC2743]).  The exported name token does, of course, conform to  Section 3.2 of [RFC2743], but the "NAME" part of the token should = be
  treated as a potential input string to the OpenID name normal= ization
  rules.  For example, the OpenID Identifier "https://openid.example/"=
  will have a GSS_C_NT_USER_NAME value of "https://openid.example/".

 = GSS-API name attributes may be defined in the future to hold the
 = ; normalized OpenID Identifier.

-------
Of course instead of tal= king about OpenID identifiers (as URIs) we would be talking about resource = owner identifiers, for example, the "Principal" defined in Section 4.1.6 of JWT (in case a JSON-based structure is used to encode information, as it w= as done with OpenID Connect). Note that the JWT spec does not define the sy= ntax of the principal identifier.

Section 3.2.1 and Section 3.2.2 o= f the current OAuth SASL draft would be impacted.

Does this sound r= easonable?

Ciao
Hannes

On Nov 20, 2012, at 2:53 AM, Willi= am Mills wrote:

> We can strike that second sentence if you want,= it was there to try to clarify, and if it's not doing that kill it.
&g= t;
>
> From: Hannes Tschofenig <hannes.tsch= ofenig@gmx.net>
> To: kitten@ietf.org
> Sent: Sunday, No= vember 18, 2012 11:43 PM
> Subject: [kitten] Updating OAuth SASL
&= gt;
> Hi all,
>
> I have incorporated Alexey's comment= s into the draft and also my own earlier review comments.
> Here is t= he current snapshot:
> https://github.com/hannestschofenig/tschofenig-ids/blob/= master/sasl-oauth/draft-ietf-kitten-sasl-oauth-09.txt
>
> = There is one issue that Alexey raised, which I still have to understand bet= ter myself, namely:
>
> -----
>
> 3.2.2.  Ca= nonicalization
>
>  The identity asserted by the OAuth a= uthorization server is canonical
>  for display.  The serv= er MAY provide a different canonical form based
>  on local dat= a.
>
> I don't understand the second sentence. SASL server? Ho= w can it do that?
>
> ------
>
> Ciao
> Han= nes
>
> _______________________________________________
> Kitten mailing lis= t
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitt= en
>
>



=
---368338466-1335605788-1353629831=:97525-- From hannes.tschofenig@gmx.net Thu Nov 22 23:52: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 B9AC821F8201 for ; Thu, 22 Nov 2012 23:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E41KF+412j5Z for ; Thu, 22 Nov 2012 23:52:37 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D68EA21F8232 for ; Thu, 22 Nov 2012 23:52:31 -0800 (PST) Received: (qmail invoked by alias); 23 Nov 2012 07:52:29 -0000 Received: from unknown (EHLO [10.255.134.168]) [194.251.119.201] by mail.gmx.net (mp004) with SMTP; 23 Nov 2012 08:52:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nRwl/AIZn8+kRyt5zMYc9ba/O2sH1JCL1z0qR9p AfcGeYOhkxVnuH Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1353629831.97525.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Fri, 23 Nov 2012 09:52:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6197D3BF-AA50-4383-AE77-7EC523AAC848@gmx.net> References: <841A324B-C22C-4FB6-9D62-9CF0430BD940@gmx.net> <1353372782.48256.YahooMailNeo@web31804.mail.mud.yahoo.com> <1353629831.97525.YahooMailNeo@web31801.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Updating OAuth SASL 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, 23 Nov 2012 07:52:41 -0000 Hi Bill,=20 you are right that there are various aspects to consider.=20 The first one is that there is a need to map the resource owner = identifier from the OAuth exchange to the SASL/GSS-API used concepts. = The need to describe such a mapping is created by the layering = introduced. The text I distributed below tries to address that part = (since it is not described elsewhere in the document).=20 Then, there is a question of how the resource owner identifier is = actually presented to the user (as part of the user interface). The = problem is that there is no description in any of the OAuth documents = about the syntax of the resource owner identifer. The only (not yet = finished document) is the JWT that describes in which JSON field to put = the string. It does, however, leave the syntax of the string undefined = (intentionally).=20 This obviously makes it a bit difficult to describe in the SASL OAuth = document how such identifier canonicalization would look like.=20 Ciao Hannes On Nov 23, 2012, at 2:17 AM, William Mills wrote: > Nowhere in OAuth do we talk about normalizing or canonicalizing names = IIRC, so there's at least one way this won't work. I know what problem = I was trying to solve with that language, I don't see how this language = solves the problem. Perhaps it doesn't need solving, I could believe = that. I think we need to define a way for the server to get (or derive = by DB lookup for example) the identity out of the token, and we should = also define how a server might get the client identity. Since nothing = in the token is defined as usable for display the current text also = addresses that by adding it as a requirement. >=20 > How does the proposed language solve these things? >=20 > -bill >=20 >=20 > From: Hannes Tschofenig > To: William Mills ; Alexey Melnikov = =20 > Cc: Hannes Tschofenig ; kitten@ietf.org=20 > Sent: Thursday, November 22, 2012 6:38 AM > Subject: Re: [kitten] Updating OAuth SASL >=20 > Hi Bill, Hi Alexey,=20 >=20 > I am wondering whether we couldn't just re-use the text we have in the = SASL OpenID specification.=20 > Here is the relevant text from Section 4.1 of RFC 6616: >=20 > ---- >=20 > 4.1. GSS-API Principal Name Types for OpenID >=20 > OpenID supports standard generic name syntaxes for acceptors such as > GSS_C_NT_HOSTBASED_SERVICE (see Section 4.1 of [RFC2743]). >=20 > OpenID supports only a single name type for initiators: > GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for > OpenID. >=20 > OpenID name normalization is covered by the OpenID specification; = see > Section 7.2 of [OpenID]. >=20 > The query, display, and exported name syntaxes for OpenID principal > names are all the same. There are no OpenID-specific name syntaxes > -- applications should use generic GSS-API name types such as > GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see=20 > Section 4 of [RFC2743]). The exported name token does, of course, = conform to > Section 3.2 of [RFC2743], but the "NAME" part of the token should be > treated as a potential input string to the OpenID name normalization > rules. For example, the OpenID Identifier "https://openid.example/" > will have a GSS_C_NT_USER_NAME value of "https://openid.example/". >=20 > GSS-API name attributes may be defined in the future to hold the > normalized OpenID Identifier. >=20 > ------- > Of course instead of talking about OpenID identifiers (as URIs) we = would be talking about resource owner identifiers, for example, the = "Principal" defined in Section 4.1.6 of JWT (in case a JSON-based = structure is used to encode information, as it was done with OpenID = Connect). Note that the JWT spec does not define the syntax of the = principal identifier.=20 >=20 > Section 3.2.1 and Section 3.2.2 of the current OAuth SASL draft would = be impacted.=20 >=20 > Does this sound reasonable?=20 >=20 > Ciao > Hannes >=20 > On Nov 20, 2012, at 2:53 AM, William Mills wrote: >=20 > > We can strike that second sentence if you want, it was there to try = to clarify, and if it's not doing that kill it.=20 > >=20 > >=20 > > From: Hannes Tschofenig > > To: kitten@ietf.org=20 > > Sent: Sunday, November 18, 2012 11:43 PM > > Subject: [kitten] Updating OAuth SASL > >=20 > > Hi all,=20 > >=20 > > I have incorporated Alexey's comments into the draft and also my own = earlier review comments.=20 > > Here is the current snapshot: > > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/= draft-ietf-kitten-sasl-oauth-09.txt > >=20 > > There is one issue that Alexey raised, which I still have to = understand better myself, namely: > >=20 > > ----- > >=20 > > 3.2.2. Canonicalization > >=20 > > The identity asserted by the OAuth authorization server is = canonical > > for display. The server MAY provide a different canonical form = based > > on local data. > >=20 > > I don't understand the second sentence. SASL server? How can it do = that? > >=20 > > ------ > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > >=20 > >=20 >=20 >=20 >=20 From hartmans@mit.edu Fri Nov 30 06:19: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 A0A1721F8AE3 for ; Fri, 30 Nov 2012 06:19:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ2JELPkMgrP for ; Fri, 30 Nov 2012 06:19:33 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8F821F8AE2 for ; Fri, 30 Nov 2012 06:19:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id B018F20180; Fri, 30 Nov 2012 09:17:48 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73CD3420E; Fri, 30 Nov 2012 09:19:30 -0500 (EST) From: Sam Hartman To: kitten@ietf.org,ietf-krb-wg@anl.gov Date: Fri, 30 Nov 2012 09:19:30 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] iakerb X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:19:33 -0000 Is there anyone whose arm could be twisted to helping complete the iakerb specification? I know of one implementation and believe there are two. It seems kind of unfortunate to have a shipping protocol that gets dropped. From jhutz@cmu.edu Fri Nov 30 08:43: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 C878F21F8B64 for ; Fri, 30 Nov 2012 08:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxKvuEpAQG0u for ; Fri, 30 Nov 2012 08:43:46 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 926AB21F87FF for ; Fri, 30 Nov 2012 08:43:41 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id qAUGhc2s020358 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2012 11:43:39 -0500 (EST) Message-ID: <1354293818.7684.319.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Sam Hartman Date: Fri, 30 Nov 2012 11:43:38 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, jhutz@cmu.edu Subject: Re: [kitten] [Ietf-krb-wg] iakerb X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 16:43:46 -0000 On Fri, 2012-11-30 at 09:19 -0500, Sam Hartman wrote: > > Is there anyone whose arm could be twisted to helping complete the > iakerb specification? > I know of one implementation and believe there are two. > It seems kind of unfortunate to have a shipping protocol that gets > dropped. I did some checking, and I think that's mostly my fault. This document finished WGLC in 2009, with only a few comments including some proposed changes from the author. Larry submitted a new version (-02) which dealt with all of the comments and proposed changes. And then I promptly dropped the ball. Near the end of 2011, I proposed picking up the ball, doing a review, and sending the document along. I also asked if anyone had comments based on implementation experience. I got exactly one reply. So, this document still needs chair review and a writeup, but otherwise should be basically ready to go. I expect the effort required of anyone who volunteers to step in as editor would be minimal. -- Jeff