From timshow@yahoo-inc.com Wed Jan 4 15:44:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9111E80EA for ; Wed, 4 Jan 2012 15:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.74 X-Spam-Level: X-Spam-Status: No, score=-15.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0keJxJjTjYMB for ; Wed, 4 Jan 2012 15:44:08 -0800 (PST) Received: from smtp102.prem.mail.sp1.yahoo.com (smtp102.prem.mail.sp1.yahoo.com [98.136.44.57]) by ietfa.amsl.com (Postfix) with SMTP id B724711E80D8 for ; Wed, 4 Jan 2012 15:44:08 -0800 (PST) Received: (qmail 78167 invoked from network); 4 Jan 2012 23:44:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1325720642; bh=aahrXSw9ZjYP3c/a8Sa1iuyfxOhu1eIJk7OKIJWn5aI=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=3tSimM28ANa1kCR7BwnJsUMtaJhnEryGBRYN2LCWEqhAMZ1IrbgQZBwLyTlTUYyUCP2MgPE6yvFjNz2ZSDsXKsIDU+9XHYQRxvf+SS0suau9vt5m7hf7Zoy1e8O85tpODtj2H9lz3mFsoQPjyKnVNWrO2DJ+CsOmRUQ9hEKZfOA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JAhhr9XezZjdSwJUwsGIjKSBUs2DHsktcFLMtuOZn3IvcVTq8M3tyYak13wyivgz ; X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Unpq_wMVM1lhpFNcAf5UiQrxjUQ.AuyVJCLe3hgSi21K_Xy 8Y7mSGBSKJrb0CFdr2WYUtpC1ODTSTvTp3JAocpHlahtdn8b39T7jQ5sTkV_ PFAH1RhK1pQgA.DKw4vt9bBO6chl7Km3TryVp2F6Kapw0MT97IoIeKEQbA4q athpKeYo2jMQ7e9TP4OQZwJb2Z4wT1Zit5OOy1lfQ9PfrwjCNcK5r.qyShxC IZbB1iZGYpuUSorjj1ZAHBnXS7RSPXx8_RBXuNISvLN..t7fAYQg0dSgPg6L pGJYuOVJil.7Fn6EXvG5ymZ2YuZYhh0phljrnNNJLpFk2soOkQZ_M5YaQIH7 3iBdLN0J6zDpPyUivdjvko4GldX58YPBkdaYZ5GrpQEM0YbrxhMTgF8.cnmZ vI1f3qcYMCtIqqYGWYAJ7fr6Q.xBg_sNYhiRx6HhohvHBaghboPPjyzr77Oi NjqGQrbAI85nuG8CSRrAoMYR.MWxhETTnqPZE4f2QuHsdBGEO X-Yahoo-SMTP: jK5ghcGswBAlBjVhZO0ppd4- Received: from [10.72.120.248] (timshow@209.131.62.113 with plain) by smtp102.prem.mail.sp1.yahoo.com with SMTP; 04 Jan 2012 15:44:02 -0800 PST Message-ID: <4F04E442.4000702@yahoo-inc.com> Date: Wed, 04 Jan 2012 15:44:02 -0800 From: Tim Showalter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: kitten@ietf.org References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:44:09 -0000 On 12/20/11 1:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I would need your feedback on the following important design decision. > Currently, the OAuth messages are encoded as HTTP headers and Leif had > suggested to instead use a JSON encoding. > --------------- > GET / HTTP/1.1 > Host: imap.example.com > Authorization: BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==" > --------------- > > A possible JSON based representation would be: > --------------- > {"token-type":" BEARER", > "token":" vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="} > --------------- > In my made-up example I define two attributes: a token container and a > token type attribute. The accessed resource is most likely in the > protected token itself and is additionally carried in the underlying > transport mechanism and therefore not needed again. I much prefer to leverage the HTTP headers as the format is already defined and additional fields map naturally into the SASL profile. But if we're going down that route, I would suggest that the JSON fields be mapped identically to the header fields, like this: {"authorization":["BEARER" "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="]} The "user" and "host" arguments are omitted from your JSON examples, but are helpful for discovery cases, like the IMAP server that is speaking to unconfigured clients, where the authentication credentials can come from multiple "realms" depending on the user involved. In your JSON notation, the equivalent thing might be {"user":"user@example.com", "host":"imap.example.com", "authorization":{"token-type":"BEARER" "token":"........."}} Anyway, I still like just putting an HTTP thing in there. The parser isn't that hard to write, and it means one fewer mapping in the world. It's not as pretty, but I think it's much less work to specify it, and to maintain the links between the specs. I'm afraid that I have not followed discussions on discovery. I would prefer to not make SASL any more different from HTTP OAuth 2 than is required to get the job done. If we can steal others' discovery work, great! Tim From chris.newman@oracle.com Wed Jan 4 17:55:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DB01F0C49 for ; Wed, 4 Jan 2012 17:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qTEE2mjKm2V for ; Wed, 4 Jan 2012 17:55:31 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7848E1F0C41 for ; Wed, 4 Jan 2012 17:55:31 -0800 (PST) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id q051tSed023945; Thu, 5 Jan 2012 01:55:28 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id q051tRZr065179; Thu, 5 Jan 2012 01:55:28 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.03 64bit (built Oct 25 2011)) with ESMTPA id <0LXA0016VYOAX000@gotmail.us.oracle.com>; Wed, 04 Jan 2012 17:55:27 -0800 (PST) Date: Wed, 04 Jan 2012 17:55:22 -0800 From: Chris Newman To: Tim Showalter , kitten@ietf.org Message-id: In-reply-to: <4F04E442.4000702@yahoo-inc.com> References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:55:32 -0000 We attempted to use HTTP syntax for the DIGEST-MD5 SASL mechanism. I believe it was one of the reasons that mechanism was a failure. While there's nothing apparently wrong with HTTP headers as normally used, the legal syntactic variations for semantically identical headers are unbounded. Not only is white-space variable, but line folding can get complex, especially when combined with 2047 encoding. Also, charsets are a mess (iso8859-1 or UTF-8 or RFC 2047?). And then there's the hidden side-effects of the legacy ABNF "#" operator used by HTTP syntax. Having a SASL parser call out to a header parser would be poor security design, because every line of code is an additional potential security vulnerability (especially prior to authentication) and a lot of code is needed for a 100% correct header parser. So I think it's actually important for a SASL mechanism to not accept arbitrary header syntax. It's probably easier to specify a constrained JSON syntax than a constrained subset of header syntax (disallowing all the unnecessary syntax variations so a strict parser is very simple), but either of those options would address the syntax problems encountered by the DIGEST-MD5 SASL mechanism. I concur with Tim's point that if we do a JSON syntax it ought to be algorithmically mapped from HTTP header fields. - Chris --On January 4, 2012 15:44:02 -0800 Tim Showalter wrote: > On 12/20/11 1:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> I would need your feedback on the following important design decision. >> Currently, the OAuth messages are encoded as HTTP headers and Leif had >> suggested to instead use a JSON encoding. > >> --------------- >> GET / HTTP/1.1 >> Host: imap.example.com >> Authorization: BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==" >> --------------- >> >> A possible JSON based representation would be: >> --------------- >> {"token-type":" BEARER", >> "token":" vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="} >> --------------- >> In my made-up example I define two attributes: a token container and a >> token type attribute. The accessed resource is most likely in the >> protected token itself and is additionally carried in the underlying >> transport mechanism and therefore not needed again. > > I much prefer to leverage the HTTP headers as the format is already > defined and additional fields map naturally into the SASL profile. But > if we're going down that route, I would suggest that the JSON fields be > mapped identically to the header fields, like this: > > {"authorization":["BEARER" "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="]} > > The "user" and "host" arguments are omitted from your JSON examples, but > are helpful for discovery cases, like the IMAP server that is speaking to > unconfigured clients, where the authentication credentials can come from > multiple "realms" depending on the user involved. In your JSON notation, > the equivalent thing might be > > {"user":"user@example.com", > "host":"imap.example.com", > "authorization":{"token-type":"BEARER" > "token":"........."}} > > Anyway, I still like just putting an HTTP thing in there. The parser > isn't that hard to write, and it means one fewer mapping in the world. > It's not as pretty, but I think it's much less work to specify it, and to > maintain the links between the specs. > > I'm afraid that I have not followed discussions on discovery. I would > prefer to not make SASL any more different from HTTP OAuth 2 than is > required to get the job done. If we can steal others' discovery work, > great! > > Tim > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From rra@stanford.edu Wed Jan 4 18:34: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 358835E8001 for ; Wed, 4 Jan 2012 18:34:14 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jhYBeF4ps66 for ; Wed, 4 Jan 2012 18:34:13 -0800 (PST) Received: from smtp.stanford.edu (smtp4.Stanford.EDU [171.67.219.84]) by ietfa.amsl.com (Postfix) with ESMTP id 768A021F87EF for ; Wed, 4 Jan 2012 18:34:13 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2714E1A559C; Wed, 4 Jan 2012 18:34:12 -0800 (PST) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id A773A1A5336; Wed, 4 Jan 2012 18:34:11 -0800 (PST) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 80AB22F60B; Wed, 4 Jan 2012 18:34:11 -0800 (PST) From: Russ Allbery To: Chris Newman In-Reply-To: (Chris Newman's message of "Wed, 04 Jan 2012 17:55:22 -0800") Organization: The Eyrie References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Date: Wed, 04 Jan 2012 18:34:11 -0800 Message-ID: <8762gqev30.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 02:34:14 -0000 Chris Newman writes: > We attempted to use HTTP syntax for the DIGEST-MD5 SASL mechanism. I > believe it was one of the reasons that mechanism was a failure. While > there's nothing apparently wrong with HTTP headers as normally used, the > legal syntactic variations for semantically identical headers are > unbounded. Not only is white-space variable, but line folding can get > complex, especially when combined with 2047 encoding. Also, charsets are > a mess (iso8859-1 or UTF-8 or RFC 2047?). And then there's the hidden > side-effects of the legacy ABNF "#" operator used by HTTP syntax. > Having a SASL parser call out to a header parser would be poor security > design, because every line of code is an additional potential security > vulnerability (especially prior to authentication) and a lot of code is > needed for a 100% correct header parser. So I think it's actually > important for a SASL mechanism to not accept arbitrary header syntax. Based on my experience writing netnews implementations, which use RFC 5322 header field syntax very akin to the HTTP header field syntax, I completely concur with Chris's reaction. The header field syntax is surprisingly complex, particularly in the presence of encoding and character set issues, and most implementors do not implement it properly. -- Russ Allbery (rra@stanford.edu) From stephen.farrell@cs.tcd.ie Thu Jan 5 02:39:48 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 422B121F8799 for ; Thu, 5 Jan 2012 02:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC9pY07gL60D for ; Thu, 5 Jan 2012 02:39:47 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5704121F8788 for ; Thu, 5 Jan 2012 02:39:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6580015356C; Thu, 5 Jan 2012 10:39:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1325759985; bh=BlYNW0Uhc2fZJj 7FSOcMODnVAHSeuXh3Ipz/IDt+pLA=; b=n/Dl0DimrcSm12rTMVCp4XZMHCfFcA 4+WrYvbgUSDK6ebU/c+UK8JkY/raJZaKx8cjcxNG2Dzbd/r6vVgI452jCGl/Wy6K /A3hWrqbkZIMmsCq89GAMbxdFxRNz5KcXkfqWx4DVXnaLMG7+mIOv+vL6Uzk7tk2 VChq5cddE61QESHaToJaNqHnHGz/8etJ75XNaYS2l/nE17+x1Lj3uUxclQXJGUJF VrB6G5RFrTRzwhi6JNYIB2Z8NaWu8f0t3chTTbtt0UwNrMaNREWKZdTVm3zpXhIe FP69tjA2yVnBVvkNbXN+WlZWD54S0LSDS/Nl5ffXNQei94iYBCZtiJXQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id xkh2bo5Utg21; Thu, 5 Jan 2012 10:39:45 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4082B171CC5; Thu, 5 Jan 2012 10:39:38 +0000 (GMT) Message-ID: <4F057DE1.5030901@cs.tcd.ie> Date: Thu, 05 Jan 2012 10:39:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Klaas Wierenga References: <4ECC405A.1000605@cs.tcd.ie> <4EF34518.7010400@cs.tcd.ie> <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> <4EF72A20.8000700@isode.com> <4EF72CA5.2000002@isode.com> In-Reply-To: <4EF72CA5.2000002@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 05 Jan 2012 10:39:48 -0000 So last call on this has expired and I think Alexey's were the only comments. (Is that right?) Anyway, I'd say a quick re-spin to fix Alexey's issues is right so I'll mark this as revised-ID needed and then when we get that I'll put it on an IESG telechat. Cheers, S. On 12/25/2011 02:01 PM, Alexey Melnikov wrote: > On 25/12/2011 13:50, Alexey Melnikov wrote: >> Additional comments (mostly nits) on the latest version: > One more thing: > > [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. > > This is likely to be need to be a Normative Reference. It is Ok that it > is Informational, it is already in the Downref registry. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From klaas@cisco.com Thu Jan 5 03:15: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 C160121F8706 for ; Thu, 5 Jan 2012 03:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH3-VTklwxiQ for ; Thu, 5 Jan 2012 03:15:44 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 459A021F86BD for ; Thu, 5 Jan 2012 03:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=399; q=dns/txt; s=iport; t=1325762144; x=1326971744; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1su1BgvuSoc6qcFJwX0N3kdQg2aEqr8ihYye1iRh6VU=; b=fHrVgPcVvNe+kEIm2Vlgg7JaR94ddEzxemhuKJ2rz7g09uZLu3Oz1RHV LsWCb1j4R6ZeE9w/EAYyZ+j6ke0BIuvNua9yvShTQjhEaOTI5w6IuzvyI 1dyT18jCd7B7k0kcmzxCS5V6A5JcS8RAmGYEAxMYL/uQIZcCDhd4VHjWb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJeFBU+tJXG9/2dsb2JhbABDrHyBBYFyAQEBAwESAWYQC0ZXBjWHWJcvAZ4Fiy5jBJUGkjY X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; d="scan'208";a="48848674" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jan 2012 11:15:44 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q05BFgSB021474; Thu, 5 Jan 2012 11:15:43 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Klaas Wierenga In-Reply-To: <4F057DE1.5030901@cs.tcd.ie> Date: Thu, 5 Jan 2012 12:15:42 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4ECC405A.1000605@cs.tcd.ie> <4EF34518.7010400@cs.tcd.ie> <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> <4EF72A20.8000700@isode.com> <4EF72CA5.2000002@isode.com> <4F057DE1.5030901@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 05 Jan 2012 11:15:44 -0000 On Jan 5, 2012, at 11:39 AM, Stephen Farrell wrote: Hi Stephen, > > So last call on this has expired and I think Alexey's were > the only comments. (Is that right?) I think so > > Anyway, I'd say a quick re-spin to fix Alexey's issues is > right so I'll mark this as revised-ID needed and then when > we get that I'll put it on an IESG tele chat. OK, I'll do that. Klaas From internet-drafts@ietf.org Thu Jan 5 07:11:26 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 2AF3B21F87EA; Thu, 5 Jan 2012 07:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYOJ5ILUf2-v; Thu, 5 Jan 2012 07:11:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A269521F86F8; Thu, 5 Jan 2012 07:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120105151125.27953.13088.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2012 07:11:25 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:11:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL and GSS-API Mechanism for SAML Author(s) : Klaas Wierenga Eliot Lear Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-07.txt Pages : 28 Date : 2012-01-05 Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-07.txt From stephen.farrell@cs.tcd.ie Thu Jan 5 08:02: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 12B8821F8582 for ; Thu, 5 Jan 2012 08:02:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqHah3GPppPE for ; Thu, 5 Jan 2012 08:02:09 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEF721F857A for ; Thu, 5 Jan 2012 08:02:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 351CD171DC7 for ; Thu, 5 Jan 2012 16:02:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1325779327; bh=C/rcLYAiJTwkGt Y6OVSs2rS5DZ4DhoK8Isw56p+41F0=; b=ycvmc/oE7UjtYUfJzGaXqBaMez/bvs 1f2M5lcS/JNmnp1sAIGoPwV02QFFhMgtFSQulpVlXQFsHM6FE2uA/SjF2AuY32lF mDynrSedHFFD1v2yijM3HiT33SHtA1/UkLlmge9zDogXzoIGQTa7NZEZ8w2LhTCt vzxcWy6GnpEYPJW/BOBbxLo+kejbFf7+SKU3drQiA35JY9QDZx6bQX3nWWsqTsgD QZRjTgiv/Fx4PqcjQt90tEjQ4XNThc5G4OMipQNlnyoRwpvcOt84DhK6jL4Rrfge 58SEAuxZYlAk+EeT1TKgVX7bm3D+YbmLRFZkguJzRpRNQNsPky9N/SNQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ll4TlfKswsbA for ; Thu, 5 Jan 2012 16:02:07 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C8C87171C28 for ; Thu, 5 Jan 2012 16:02:07 +0000 (GMT) Message-ID: <4F05C975.8020703@cs.tcd.ie> Date: Thu, 05 Jan 2012 16:01:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kitten@ietf.org References: <20120105151125.27953.13088.idtracker@ietfa.amsl.com> In-Reply-To: <20120105151125.27953.13088.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:02:11 -0000 Thanks for the quick update. This is now on the Jan 19th telechat agenda. S On 01/05/2012 03:11 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : A SASL and GSS-API Mechanism for SAML > Author(s) : Klaas Wierenga > Eliot Lear > Simon Josefsson > Filename : draft-ietf-kitten-sasl-saml-07.txt > Pages : 28 > Date : 2012-01-05 > > Security Assertion Markup Language (SAML) has found its usage on the > Internet for Web Single Sign-On. Simple Authentication and Security > Layer (SASL) and the Generic Security Service Application Program > Interface (GSS-API) are application frameworks to generalize > authentication. This memo specifies a SASL mechanism and a GSS-API > mechanism for SAML 2.0 that allows the integration of existing SAML > Identity Providers with applications using SASL and GSS-API. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-07.txt > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From timshow@yahoo-inc.com Thu Jan 5 13:38: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 5F8CC21F88AE for ; Thu, 5 Jan 2012 13:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.669 X-Spam-Level: X-Spam-Status: No, score=-16.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S7ochdfXx9H for ; Thu, 5 Jan 2012 13:38:07 -0800 (PST) Received: from smtp105.prem.mail.sp1.yahoo.com (smtp105.prem.mail.sp1.yahoo.com [98.136.44.60]) by ietfa.amsl.com (Postfix) with SMTP id 73F8121F8838 for ; Thu, 5 Jan 2012 13:38:07 -0800 (PST) Received: (qmail 8296 invoked from network); 5 Jan 2012 21:38:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1325799484; bh=ybh/2lGLmigrOwKG2jS3BUBB1WWignLrmW6Q+z7FDWE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Tkdcl8TkVmArP4jfG6O2Quj1kCHGlQfciLng+/VFaywQfHq4stS4PcEFHs2oHPZg91kaoTn8+/wnePfXTNgaxQ2WunLRxxvAeFtqWP8JwPAvFo4lWgkt/YrjMkmSJ1kwXfMpBHo7lt3SxBSkAO9K5aR8jDrecba+Zo8hH+TwPfQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OEaewnwtneWXEiYo+RZGg+IvbDGwUjOoQt1JMSdueiNJpaGXPoQP9ZEmj0WAgKIt ; X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: J2Hl6QUVM1n2Eb0VGecx1d6aM7A7ySoAYL16IPFT1DVRj89 vA2a_NTN7ZfzSb_HZ13OuFArchLE.WDk5SNAwWzN8.uVLrSSa2V4NZmkf8wZ WRaIgI6RgWUX5flIW3BKt9N03sbn4rWKBKaLPHqvO5JPx8192Vfak1rr0F7S vKVkjt7BcYuSqGcR6RD4GUE6qUhz3xvIEk.4IP5mAV0bYDQb2ZnrJo8TiwI. eaS7AlOYMjZGmdWGUM_fXv._SXq5zhJTn_UWTQfjIn8PnETQs6EedjKIE9.N cNVL5viD7GXXtfTQLBMiSfNE2krwsaokGqUqUnA07Ef_qDxpmyXlYqcCOhR0 WCSaF0f7pelHY9KuekJB7BF6JO0cvwWLqBXbrohqMbejyS.vX6oJDUbMmsPi GuZorJYa3ED2gwqrXSjaVaKhxIedDms29NgPf8mBJeQx.COk- X-Yahoo-SMTP: jK5ghcGswBAlBjVhZO0ppd4- Received: from [10.72.120.248] (timshow@209.131.62.113 with plain) by smtp105.prem.mail.sp1.yahoo.com with SMTP; 05 Jan 2012 13:38:03 -0800 PST Message-ID: <4F06183B.4010401@yahoo-inc.com> Date: Thu, 05 Jan 2012 13:38:03 -0800 From: Tim Showalter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Russ Allbery References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> In-Reply-To: <8762gqev30.fsf@windlord.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:38:08 -0000 On 1/4/12 6:34 PM, Russ Allbery wrote: > Chris Newman writes: >> Having a SASL parser call out to a header parser would be poor security >> design, because every line of code is an additional potential security >> vulnerability (especially prior to authentication) and a lot of code is >> needed for a 100% correct header parser. So I think it's actually >> important for a SASL mechanism to not accept arbitrary header syntax. > > Based on my experience writing netnews implementations, which use RFC 5322 > header field syntax very akin to the HTTP header field syntax, I > completely concur with Chris's reaction. The header field syntax is > surprisingly complex, particularly in the presence of encoding and > character set issues, and most implementors do not implement it properly. I'm really sorry to hear that -- I suspect you're right, and I don't like it. I think trying to constrain JSON and define the mappings is going to be a lot of work. Is there a simple way to specify a general mapping? Or are we going to have to do this on a per-header basis? Tim From wmills@yahoo-inc.com Thu Jan 5 16:01:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7EE21F878A for ; Thu, 5 Jan 2012 16:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VNw9N9zanOT for ; Thu, 5 Jan 2012 16:01:30 -0800 (PST) Received: from nm28-vm0.bullet.mail.bf1.yahoo.com (nm28-vm0.bullet.mail.bf1.yahoo.com [98.139.213.149]) by ietfa.amsl.com (Postfix) with SMTP id C327221F8775 for ; Thu, 5 Jan 2012 16:01:29 -0800 (PST) Received: from [98.139.212.153] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jan 2012 00:01:25 -0000 Received: from [98.139.212.214] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jan 2012 00:01:25 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 06 Jan 2012 00:01:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 152155.53643.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 51097 invoked by uid 60001); 6 Jan 2012 00:01:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325808084; bh=R/K51I96CJri8fd8ApYLFWNWEDD4g8yBy14NDn7xzr8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HJ1WA+o4dIbnFu0pHWP5Q0anYruHrTB0uJbARgk0hxKNH1U0aUj624+j7f5OeyTMOjp7PxyG6t1DtoqEDIbiNZ8p7nS6LbAoz4WdOn5VzGIbPCiOAIaPltNnY0dJrXv4dcA7XX28RLnxs34g8GKMRvmRhWk4Ncz88PJO8wIJV68= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ixQckgOpw7+8z/pAa2oU3m40GjoW1j/TifIVddxxW+Jy5Fk2GakAUZC0712vmGe7seuGMXTLlet58IBPaMv/5eqB25lhxXC13OQ+PlYH0ItjwXfGITOMEmGiLuCW0UOmmXAjIOGdCPrWfJbXHGWy2aTzIDMGKcEsQSGIL3YoUgk=; X-YMail-OSG: GYaIL_YVM1lqenXUm9k7hgbEs1_uJklzpsmaQhw1iFvnuFa Ta73Lq_OQtqjd5IXjSC5prjZ8479fxPl_EfWII5WS55dwDtazZjAl4R7Djax zAxsU2tw44pyGi0ZfVZ.LCqJue5AGTPOk9cjRckBSUjl1KDfkX48pu99N6Sc 21Ir0AarsX8gi223F5N_s_fVksPNILIXfguoFap.gVX02xD4RhxpVuIFt01_ KiiIsgsg4wx_IsaoXMGKTthZ_aiWrdtAm81sKAFKu5FjyPkla7lHBGI8R7wJ Z6cyIPhYk_4ybcvYuwe5s1RT9.Qe9rgF08QD50FPYqdN7itGA91L8XsHybCT sK0SMt80cOtEqJpUPRdVqRrJwMagbaf.b1uetjy.3MDc1aagG0E1RsJ9EMf1 AgFkKZ4wR_zomeYR2oWX9gZ5SqC9wb7gwEA-- Received: from [67.72.118.219] by web31812.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2012 16:01:24 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> Message-ID: <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 5 Jan 2012 16:01:24 -0800 (PST) From: William Mills To: Tim Showalter , Russ Allbery In-Reply-To: <4F06183B.4010401@yahoo-inc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-2052146962-1325808084=:1216" Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:01:31 -0000 --1458549034-2052146962-1325808084=:1216 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, I really hate this.=0A=0AThere's stuff in the MAC token spec for exam= ple that requires knowing the URL path, fragments, hostname, etc., and so w= e have to include every element form HTTP that might be required for any OA= uth (HTTP based itself) authorization scheme.=A0 This means we have to writ= e an entire mapping grammar for an entire HTTP payload into JSON.=0A=0AWhil= e I agree that HTTP is non-trivial to parse, I don't think it's compelling = enough for me to like the change to JSON because there are enough HTTP pars= ing libraries out there that an implementer should not have to do their own= , they should pull one in.=0AAs I said before, designing this in a vacuum H= TTP is far down the list, but I think in light of the fact that we're bridg= ing from something that *is* HTTP it is less complex overall to stay consis= tent.=0A=0A=0A=0A-bill=0A=0A=0A=0A________________________________=0A From:= Tim Showalter =0ATo: Russ Allbery =0ACc: "kitten@ietf.org" =0ASent: Thursday, January 5, = 2012 1:38 PM=0ASubject: Re: [kitten] SASL OAuth: Next Steps=0A =0AOn 1/4/12= 6:34 PM, Russ Allbery wrote:=0A> Chris Newman=A0 = writes:=0A>> Having a SASL parser call out to a header parser would be poor= security=0A>> design, because every line of code is an additional potentia= l security=0A>> vulnerability (especially prior to authentication) and a lo= t of code is=0A>> needed for a 100% correct header parser. So I think it's = actually=0A>> important for a SASL mechanism to not accept arbitrary header= syntax.=0A> =0A> Based on my experience writing netnews implementations, w= hich use RFC 5322=0A> header field syntax very akin to the HTTP header fiel= d syntax, I=0A> completely concur with Chris's reaction.=A0 The header fiel= d syntax is=0A> surprisingly complex, particularly in the presence of encod= ing and=0A> character set issues, and most implementors do not implement it= properly.=0A=0AI'm really sorry to hear that -- I suspect you're right, an= d I don't like it.=A0 I think trying to constrain JSON and define the mappi= ngs is going to be a lot of work.=0A=0AIs there a simple way to specify a g= eneral mapping?=A0 Or are we going to have to do this on a per-header basis= ?=0A=0ATim=0A_______________________________________________=0AKitten maili= ng list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten --1458549034-2052146962-1325808084=:1216 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I really hate this.

There's stuff in the MAC token spec for example that requires knowing t= he URL path, fragments, hostname, etc., and so we have to include every ele= ment form HTTP that might be required for any OAuth (HTTP based itself) aut= horization scheme.  This means we have to write an entire mapping gram= mar for an entire HTTP payload into JSON.

While I agree that HTTP is non-trivial to parse, I don't = think it's compelling enough for me to like the change to JSON because ther= e are enough HTTP parsing libraries out there that an implementer should no= t have to do their own, they should pull one in.

As I said before, designing this in a vacuum HTTP is far down the list, but I think in light of the fact that we're bridging from something = that *is* HTTP it is less complex overall to stay consistent.


-bill

= From: Tim Showalter <timsho= w@yahoo-inc.com>
To: Russ Allbery <rra@stanford.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Thursday, January 5, 2012 = 1:38 PM
Subject: Re: [= kitten] SASL OAuth: Next Steps
=0AOn 1/4/12 6:34 PM, Russ A= llbery wrote:
> Chris Newman<chris.newman@oracle.com>  writes:
>> Having a SASL parser call out to a header p= arser would be poor security
>> design, because every line of code= is an additional potential security
>> vulnerability (especially = prior to authentication) and a lot of code is
>> needed for a 100%= correct header parser. So I think it's actually
>> important for = a SASL mechanism to not accept arbitrary header syntax.
>
> Ba= sed on my experience writing netnews implementations, which use RFC 5322> header field syntax very akin to the HTTP header field syntax, I
&= gt; completely concur with Chris's reaction.  The header field syntax = is
> surprisingly complex, particularly in the presence of encoding a= nd
> character set issues, and most implementors do not implement it properly.

I'm really sorry to hear= that -- I suspect you're right, and I don't like it.  I think trying = to constrain JSON and define the mappings is going to be a lot of work.
=
Is there a simple way to specify a general mapping?  Or are we goi= ng to have to do this on a per-header basis?

Tim
________________= _______________________________
Kitten mailing list
Kitten@ietf.orghttps://www.ietf.org/mailman/listinfo/kitten


=
--1458549034-2052146962-1325808084=:1216-- From Thomas.Maslen@quest.com Fri Jan 6 16:23:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9378121F85C4 for ; Fri, 6 Jan 2012 16:23:13 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwE7oE1E7Ng6 for ; Fri, 6 Jan 2012 16:23:12 -0800 (PST) Received: from alvetxw02.quest.com (alvetxw02.quest.com [12.106.87.94]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4521F85BF for ; Fri, 6 Jan 2012 16:23:12 -0800 (PST) Received: from ALVHTXW02.prod.quest.corp (10.1.135.18) by alvetxw02.quest.com (10.1.100.94) with Microsoft SMTP Server (TLS) id 14.1.255.0; Fri, 6 Jan 2012 16:12:09 -0800 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW02.prod.quest.corp ([::1]) with mapi id 14.01.0255.000; Fri, 6 Jan 2012 16:23:11 -0800 From: Thomas Maslen To: "kitten@ietf.org" Thread-Topic: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825) Thread-Index: AQHMzM9MJo0UKCx6r0GJq3/Ymzn4cQ== Date: Sat, 7 Jan 2012 00:23:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 00:23:13 -0000 Dusting off this pesky little issue (AF_UNSPEC vs AF_NULLADDR in channel-bi= nding hash calculations)...=0A= =0A= I don't want to waylay "Kerberos Version 5 GSS-API Channel Binding Hash Agi= lity" on its way to PS (and of course I should have noticed this earlier), = but:=0A= =0A= Section 3.2 of draft-ietf-krb-wg-gss-cb-hash-agility-10.txt just says=0A= =0A= data-value=0A= =0A= The output obtained by applying the Kerberos V get_mic=0A= operation [RFC3961] with key usage number 43, to the channel=0A= binding data as described in [RFC4121], section 4.1.1.2=0A= =0A= and RFC 4121 refers to RFC 2744, which still specifies 255 (AF_NULLADDR) fo= r addressless channel bindings.=0A= =0A= Since "Kerberos Version 5 GSS-API Channel Binding Hash Agility" is all abo= ut generating (more secure) interoperable channel-binding hashes, and it is= expected that addressless channel bindings will be the norm, would it beho= ove us to say "disregard the bit where RFC 2744 says to use 255; real prog= rammers use zero (AF_UNSPEC)"?=0A= =0A= [draft-ietf-krb-wg-gss-cb-hash-agility is krb-wg, but rightly or wrongly I'= m posting this to kitten].=0A= =0A= =0A= =0A= =0A= ----------------------------------------------------------------------=0A= =0A= Message: 1=0A= Date: Mon, 14 Nov 2011 17:12:31 +0100 (MET)=0A= From: Martin Rex =0A= To: stephen.farrell@cs.tcd.ie (Stephen Farrell)=0A= Cc: kitten@ietf.org, simon@josefsson.org=0A= Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)=0A= Message-ID: <201111141612.pAEGCVL0007860@fs4113.wdf.sap.corp>=0A= Content-Type: text/plain; charset=3DISO-8859-1=0A= =0A= Stephen Farrell wrote:=0A= >=0A= > Not being on the top of anyone's list, this doesn't=0A= > seem to have progressed since June.=0A= >=0A= > Can we resolve this on the list or at this week's=0A= > meeting?=0A= =0A= I think we stopped here:=0A= http://www.ietf.org/mail-archive/web/kitten/current/msg02688.html=0A= =0A= While GSS_C_AF_NULLADDR(255) would be undoubtedly the correct tag with=0A= respect to the original GSS-API spec, we seem to have an installed=0A= base which didn't follow the spec.=0A= =0A= =0A= -Martin=0A= =0A= =0A= > On 06/08/2011 11:02 AM, Stephen Farrell wrote:=0A= > >=0A= > >=0A= > > On 08/06/11 09:02, Simon Josefsson wrote:=0A= > >> Stephen Farrell writes:=0A= > >>=0A= > >>> Hi all,=0A= > >>>=0A= > >>> Can you confirm that this is correct, or not?=0A= > >>=0A= > >> I think we could use some more discussion before approving this -- for= =0A= > >> example, what impact does this have on existing implementations?=0A= > >=0A= > > Good point. I'm fine with waiting for the WG to give me the=0A= > > answer that I'll cut'n'paste into the errata tool:-) Sooner=0A= > > is of course better for that.=0A= > >=0A= > > Thanks,=0A= > > S.=0A= > >=0A= > >>=0A= > >> I will try to change my implementation to use 255 instead of 0 and see= =0A= > >> if it still works and inteoperates with my old version. It would be= =0A= > >> useful if others could do similar experiments. I don't expect serious= =0A= > >> problems, but I think we should consider the impact before approving= =0A= > >> this.=0A= > >>=0A= > >> I do agree it is a bug in the specification though.=0A= > >>=0A= > >> /Simon=0A= > >>=0A= > >>> Thanks,=0A= > >>> S.=0A= > >>>=0A= > >>> -------- Original Message --------=0A= > >>> Subject: [Technical Errata Reported] RFC5801 (2825)=0A= > >>> Date: Tue, 7 Jun 2011 20:58:20 -0700 (PDT)=0A= > >>> From: RFC Errata System=0A= > >>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,=0A= > >>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,=0A= > >>> kurt.zeilenga@isode.com=0A= > >>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org=0A= > >>>=0A= > >>>=0A= > >>> The following errata report has been submitted for RFC5801,=0A= > >>> "Using Generic Security Service Application Program Interface (GSS-AP= I)=0A= > >>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS= 2=0A= > >>> Mechanism Family".=0A= > >>>=0A= > >>> --------------------------------------=0A= > >>> You may review the report below and at:=0A= > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D5801&eid=3D2825=0A= > >>>=0A= > >>> --------------------------------------=0A= > >>> Type: Technical=0A= > >>> Reported by: Thomas Maslen=0A= > >>>=0A= > >>> Section: 5.1=0A= > >>>=0A= > >>> Original Text=0A= > >>> -------------=0A= > >>> The initiator-address-type and acceptor-address-type fields of the=0A= > >>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.=0A= > >>>=0A= > >>>=0A= > >>> Corrected Text=0A= > >>> --------------=0A= > >>> The initiator-address-type and acceptor-address-type fields of the=0A= > >>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR)= .=0A= > >>>=0A= > >>>=0A= > >>> Notes=0A= > >>> -----=0A= > >>> See RFC 2744, section 3.11, last paragraph: "[...] or omit addressin= g=0A= > >>> information, specifying GSS_C_AF_NULLADDR as the address-types".=0A= > >>>=0A= > >>> Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR = is 255.=0A= > >>>=0A= > >>> Instructions:=0A= > >>> -------------=0A= > >>> This errata is currently posted as "Reported". If necessary, please= =0A= > >>> use "Reply All" to discuss whether it should be verified or=0A= > >>> rejected. When a decision is reached, the verifying party (IESG)=0A= > >>> can log in to change the status and edit the report, if necessary.=0A= > >>>=0A= > >>> --------------------------------------=0A= > >>> RFC5801 (draft-ietf-sasl-gs2-20)=0A= > >>> --------------------------------------=0A= > >>> Title : Using Generic Security Service Application Prog= ram=0A= > >>> Interface (GSS-API) Mechanisms in Simple Authentication and Security= =0A= > >>> Layer (SASL): The GS2 Mechanism Family=0A= > >>> Publication Date : July 2010=0A= > >>> Author(s) : S. Josefsson, N. Williams=0A= > >>> Category : PROPOSED STANDARD=0A= > >>> Source : Simple Authentication and Security Layer=0A= > >>> Area : Security=0A= > >>> Stream : IETF=0A= > >>> Verifying Party : IESG=0A= > >>=0A= > > _______________________________________________=0A= > > Kitten mailing list=0A= > > Kitten@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/kitten=0A= > >=0A= > _______________________________________________=0A= > Kitten mailing list=0A= > Kitten@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/kitten=0A= >=0A= =0A= From internet-drafts@ietf.org Thu Jan 12 00:09:43 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 90A3121F866E; Thu, 12 Jan 2012 00:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqoHVMkVWEwI; Thu, 12 Jan 2012 00:09:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC621F8667; Thu, 12 Jan 2012 00:09:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112080940.18723.1887.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 00:09:40 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-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: Thu, 12 Jan 2012 08:09:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL and GSS-API Mechanism for SAML Author(s) : Klaas Wierenga Eliot Lear Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-08.txt Pages : 30 Date : 2012-01-12 Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-08.txt From arnab.bakshi@gmail.com Tue Jan 17 00:54:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE1821F8692 for ; Tue, 17 Jan 2012 00:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKEsXDFQE4KL for ; Tue, 17 Jan 2012 00:54:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B816221F8634 for ; Tue, 17 Jan 2012 00:54:23 -0800 (PST) Received: by yenr11 with SMTP id r11so1777136yen.31 for ; Tue, 17 Jan 2012 00:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=NVUEaGPszHJw3NOxAa9TR55BIqd6ajwzyluqP60Q7os=; b=C36xpL4SLFuy3hm7+Djbch5hHsPUm5A0iJCdNpxGIyWln9Toy7nZzPKcAhY9T9BEX2 9nEWgW91zQuyQ6NK/dun7diDZUN923bx5bP1NIrSTu3RXqBXh4RpSmhw6UvgiJfHsROq hWf9bR7G2/M7IUtX9VosAjaEIOiB7IDoXg6RU= Received: by 10.236.78.6 with SMTP id f6mr22536763yhe.109.1326790463296; Tue, 17 Jan 2012 00:54:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.123.3 with HTTP; Tue, 17 Jan 2012 00:54:02 -0800 (PST) From: Arnab Bakshi Date: Tue, 17 Jan 2012 14:24:02 +0530 Message-ID: To: kitten@ietf.org Content-Type: multipart/mixed; boundary=20cf3005154041958204b6b57aff Subject: [kitten] Issue with MechListMIC 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, 17 Jan 2012 08:54:24 -0000 --20cf3005154041958204b6b57aff Content-Type: multipart/alternative; boundary=20cf3005154041957e04b6b57afd --20cf3005154041957e04b6b57afd Content-Type: text/plain; charset=ISO-8859-1 Hi,**** **** I am trying to develop a SMB2 implementation of my own and right now I would require some assistance on the authentication using SPNEGO and NTLMSSP. I am describing the issue I am getting as follows...**** **** I am using NTLM2 since extended security is ON, key exchange is ON. Please refer to the packet capture attached.**** Using the methodology defined in the specs I am able to get the signing and sealing keys perfectly. The MIC digest also looks fine. The problem I am getting is with the *mechListMIC* generation for the last negTokenTarg from the client. I am aware of the seqnum and version fields in the mechListMIC field but I am not getting through with the digest part(8 byte). The RFC4718 mentions about the DER encoding of mechTypeList received from initiator (server in this case) but by using that it is not matching with the generated digest in the packet.**** **** Can anybody kindly help with the algorithm in* generating the mechListMIC value*. I have mentioned the Sign Key, Seal Key, Mech Types List, Generated Random key on client, the mechListMIC and packet**** capture for your reference. It will be great if we can take these values as sample.**** **** Sign Key: ~~~~~~~~~~ ec-00-57-ad-88-de-cd-70-0-a7-bc-6f-b0-a8-21-d8**** **** Seal Key: ~~~~~~~~~~ 91-71-c7-7f-16-16-1-4-c2-62-cd-7f-68-1e-10-2f**** **** Mech Types List: ~~~~~~~~~~~~~~~~ 30-2e-06-09-2a-86-48-82-f7-12-01-02-02-06-09-2a-86-48-86-f7-12-01-02-02-06-0a-2a-86-48-86-f7-12-01-02-02-03-06-0a-2b-06-01-04-01-82-37-02-02-0a **** Full NegTokenInit: ~~~~~~~~~~~~~~~~~~ 0xa0,0x60,0x30,0x5e,0xa0,0x30,0x30,0x2e,0x06,0x09,0x2a,0x86,0x48,0x82,0xf7,0x12 ,0x01,0x02,0x02,0x06,0x09,0x2a,0x86,0x48,0x86,0xf7,0x12,0x01,0x02,0x02,0x06,0x0a ,0x2a,0x86,0x48,0x86,0xf7,0x12,0x01,0x02,0x02,0x03,0x06,0x0a,0x2b,0x06,0x01,0x04 ,0x01,0x82,0x37,0x02,0x02,0x0a,0xa3,0x2a,0x30,0x28,0xa0,0x26,0x1b,0x24,0x6e,0x6f ,0x74,0x5f,0x64,0x65,0x66,0x69,0x6e,0x65,0x64,0x5f,0x69,0x6e,0x5f,0x52,0x46,0x43 ,0x34,0x31,0x37,0x38,0x40,0x70,0x6c,0x65,0x61,0x73,0x65,0x5f,0x69,0x67,0x6e,0x6f ,0x72,0x65**** **** Encrypted Session Key: ~~~~~~~~~~~~~~~~~~~~~~ fd-ae-58-07-25-66-af-83-cf-08-f5-a8-ce-19-7e-79**** Generated Random Key: ~~~~~~~~~~~~~~~~~~~~~ 0x0d, 0xa8, 0xfe, 0xdc, 0x2a, 0x32, 0xc1, 0x9b, 0xdf, 0xd2, 0xd1, 0xad, 0x90, 0x3f, 0x39, 0x70**** MechListMIC@ negTokenTarg from client: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0x01,0x00,0x00,0x00,0x61,0x1d,0xd3,0x3d,0xc3,0x65,0xbc,0x9f,0x00,0x00,0x00,0x00 **** **** Warm Regards Arnab --20cf3005154041957e04b6b57afd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

=A0=A0 I am trying to develop a SM= B2 implementation of my own and right now I would require some assistance o= n the authentication using SPNEGO and NTLMSSP.=A0
I am describing the issue I am getting as follows...

=A0=

I am using NTLM2 since extended security is ON, key exc= hange is ON. Please refer to the packet capture attached.

Using= the methodology defined in=A0the specs I am able to get the signing and se= aling keys perfectly. The MIC digest also looks fine.=A0
The problem I a= m getting is with the=A0mechListMIC=A0generation for the l= ast negTokenTarg from the client. I am aware of the seqnum and version fiel= ds in the mechListMIC field but I am not
getting through with the digest part(8 byte). The RFC4718 mentions about th= e DER encoding of mechTypeList received from initiator (server in this case= ) but by using that it is not matching with the=A0
generated digest in t= he packet.

=A0

Can anybody kindly help with the algorithm in generati= ng the mechListMIC value. I have mentioned the Sign Key, Seal Key, Mech= Types List, Generated Random key on client, the mechListMIC and packet<= /u>

captu= re for your reference. It will be great if we can take these values as samp= le.

=A0

Sign = Key:=A0
~~~~~~~~~~
ec-00-57-ad-88-de-cd-70-0-a7-bc-6f-b0-a8-21-d8<= /u>

=A0

Seal = Key:=A0
~~~~~~~~~~
91-71-c7-7f-16-16-1-4-c2-62-cd-7f-68-1e-10-2f

=A0

Mech = Types List:=A0
~~~~~~~~~~~~~~~~
30-2e-06-09-2a-86-48-82-f7-12-01-02-0= 2-06-09-2a-86-48-86-f7-12-01-02-02-06-0a-2a-86-48-86-f7-12-01-02-02-03-06-0= a-2b-06-01-04-01-82-37-02-02-0a


F= ull NegTokenInit:=A0=A0=A0
~~~~~~~~~~~~~~~~~~
0xa0,0x60,0x30,0x5e,0xa= 0,0x30,0x30,0x2e,0x06,0x09,0x2a,0x86,0x48,0x82,0xf7,0x12
,0x01,0x02,0x02= ,0x06,0x09,0x2a,0x86,0x48,0x86,0xf7,0x12,0x01,0x02,0x02,0x06,0x0a
,0x2a,0x86,0x48,0x86,0xf7,0x12,0x01,0x02,0x02,0x03,0x06,0x0a,0x2b,0x06,0x01= ,0x04
,0x01,0x82,0x37,0x02,0x02,0x0a,0xa3,0x2a,0x30,0x28,0xa0,0x26,0x1b,= 0x24,0x6e,0x6f
,0x74,0x5f,0x64,0x65,0x66,0x69,0x6e,0x65,0x64,0x5f,0x69,0= x6e,0x5f,0x52,0x46,0x43
,0x34,0x31,0x37,0x38,0x40,0x70,0x6c,0x65,0x61,0x73,0x65,0x5f,0x69,0x67,0x6e= ,0x6f
,0x72,0x65

=A0

Encrypted Sess= ion Key:
~~~~~~~~~~~~~~~~~~~~~~
fd-ae-58-07-25-66-af-83-cf-08-f5-a8-c= e-19-7e-79


Generated Random Key:=A0=A0
~~~~~~~~~~~~~~~~~~~~~
0x0d, 0xa8, 0xfe, 0= xdc, 0x2a, 0x32, 0xc1, 0x9b, 0xdf, 0xd2, 0xd1, 0xad, 0x90, 0x3f, 0x39, 0x70=


MechListMIC@ negTokenTarg from client:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~
0x01,0x00,0x00,0x00,0x61,0x1d,0xd3,0x3d,0xc3,0x65,0xbc,0x9f,0x00,0= x00,0x00,0x00

=A0


W= arm Regards
Arnab

--20cf3005154041957e04b6b57afd-- --20cf3005154041958204b6b57aff Content-Type: application/octet-stream; name="smb2_sess_setup_cap.pcap" Content-Disposition: attachment; filename="smb2_sess_setup_cap.pcap" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gxioqbtt0 1MOyoQIABAAAAAAAAAAAAP//AAABAAAA+ywNT2vtAAAmAQAAJgEAAAATwzxDxAAmWnaWxQgARQAB GA//QACABprGCs0bLQrNHlQBvfzLdvPugXmwiuRQGAEAVKIAAAAAAOz+U01CQAAAAAAAAAAAAAEA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQABAAICAACk K7M0qE47SYnxB3g4O4PAAQAAAAAAAQAAAAEAAAABAIewQskq0MwBzJSKPAfGzAGAAGwAIExNIGBq BgYrBgEFBQKgYDBeoDAwLgYJKoZIgvcSAQICBgkqhkiG9xIBAgIGCiqGSIb3EgECAgMGCisGAQQB gjcCAgqjKjAooCYbJG5vdF9kZWZpbmVkX2luX1JGQzQxNzhAcGxlYXNlX2lnbm9yZfssDU+m8AAA 3AAAANwAAAAAJlp2lsUAE8M8Q8QIAEUAAM5YG0AAfwZT9ArNHlQKzRst/MsBvXmwiuR28+9xUBg/ 7Wv0AAAAAACi/lNNQkAAAQAAAAAAAQAfAAAAAAAAAAAAAQAAAAAAAAD//gAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABkAAAEBAAAAAAAAAFgASgAAAAAAAAAAAGBIBgYrBgEFBQKgPjA8oA4w DAYKKwYBBAGCNwICCqIqBChOVExNU1NQAAEAAACXggjiAAAAAAAAAAAAAAAAAAAAAAYBsB0AAAAP +ywNT5nxAACXAQAAlwEAAAATwzxDxAAmWnaWxQgARQABiRAAQACABppUCs0bLQrNHlQBvfzLdvPv cXmwi4pQGAD/AlsAAAAAAV3+U01CQAABABYAAMABAAkAAQAAAAAAAAABAAAAAAAAAP/+AAAAAAAA fQAADAAEAAAAAAAAAAAAAAAAAAAAAAAACQAAAEgAFQGhggERMIIBDaADCgEBoQwGCisGAQQBgjcC AgqigfcEgfROVExNU1NQAAIAAAAOAA4AOAAAABWCieJsATVAlr2mpgAAAAAAAAAArgCuAEYAAAAG AHEXAAAAD0kAWABJAEEAQwBPAE0AAgAOAEkAWABJAEEAQwBPAE0AAQAcAEkAWABJAE4ALQBXADIA SwA4AC0AUwBSAFYAMQAEABYAaQB4AGkAYQBjAG8AbQAuAGMAbwBtAAMANABpAHgAaQBuAC0AdwAy AGsAOAAtAHMAcgB2ADEALgBpAHgAaQBhAGMAbwBtAC4AYwBvAG0ABQAWAGkAeABpAGEAYwBvAG0A LgBjAG8AbQAHAAgAsNZCySrQzAEAAAAA+ywNTw30AAB/AQAAfwEAAAAmWnaWxQATwzxDxAgARQAB cVgcQAB/BlNQCs0eVArNGy38ywG9ebCLinbz8NJQGD+UaR8AAAAAAUX+U01CQAABAAAAAAABABcA AAAAAAAAAAACAAAAAAAAAP/+AAAAAAAAfQAADAAEAAAAAAAAAAAAAAAAAAAAAAAAGQAAAQEAAAAA AAAAWADtAAAAAAAAAAAAoYHqMIHnoAMKAQGigcsEgchOVExNU1NQAAMAAAAYABgAiAAAABgAGACg AAAADgAOAFgAAAAOAA4AZgAAABQAFAB0AAAAEAAQALgAAAAVgojiBgGwHQAAAA/nD3U4yUgyrqcJ eBbrqALgSQBYAEkAQQBDAE8ATQBzAHUAcABhAG4AZABhAEkAWABJAE4ALQBTAFUATQBJAFQASlu0 nF6l0Y4AAAAAAAAAAAAAAAAAAAAATMiRUzXIOEkH3Q3BiC2gCaA3hBLgbn7z/a5YByVmr4PPCPWo zhl+eaMSBBABAAAAYR3TPcNlvJ8AAAAA+ywNT8QVAQCfAAAAnwAAAAATwzxDxAAmWnaWxQgARQAA kRAGQACABptGCs0bLQrNHlQBvfzLdvPw0nmwjNNQGAD+kbAAAAAAAGX+U01CQAABAAAAAAABAAkA CQAAAAAAAAACAAAAAAAAAP/+AAAAAAAAfQAADAAEAADu2OwlO7SaG1NXzirz7d+xCQAAAEgAHQCh GzAZoAMKAQCjEgQQAQAAAK7PhsmZIhrUAAAAAA== --20cf3005154041958204b6b57aff-- From shawn.emery@oracle.com Mon Jan 23 21:18:43 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 27B5421F8566 for ; Mon, 23 Jan 2012 21:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HiuZ4bxGzye for ; Mon, 23 Jan 2012 21:18:41 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3D21F8565 for ; Mon, 23 Jan 2012 21:18:41 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0O5IccN030396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jan 2012 05:18:38 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 q0O5IbOw016400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jan 2012 05:18:38 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q0O5IbTS026329 for ; Mon, 23 Jan 2012 23:18:37 -0600 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jan 2012 21:18:36 -0800 Message-ID: <4F1E3F14.1010307@oracle.com> Date: Mon, 23 Jan 2012 22:18:12 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:8.0) Gecko/20111202 Thunderbird/8.0 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------020209080604090406040106" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090204.4F1E3F31.0029,ss=1,re=0.000,fgs=0 Subject: [kitten] IETF 83: Requesting Agenda Items 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, 24 Jan 2012 05:18:43 -0000 This is a multi-part message in MIME format. --------------020209080604090406040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We are currently requesting kitten agenda items to be discussed for IETF 83. Please send any requests to the list or to me. Shawn. kitten co-chair -- --------------020209080604090406040106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We are currently requesting kitten agenda items to be discussed for IETF 83.  Please send any requests to the list or to me.

Shawn.
kitten co-chair
--
 --------------020209080604090406040106-- From wmills@yahoo-inc.com Mon Jan 23 23:10:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9021F85FD for ; Mon, 23 Jan 2012 23:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.397 X-Spam-Level: X-Spam-Status: No, score=-16.397 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Oyu-exCMfE3 for ; Mon, 23 Jan 2012 23:10:31 -0800 (PST) Received: from nm10.bullet.mail.bf1.yahoo.com (nm10.bullet.mail.bf1.yahoo.com [98.139.212.169]) by ietfa.amsl.com (Postfix) with SMTP id BB1C121F85F7 for ; Mon, 23 Jan 2012 23:10:30 -0800 (PST) Received: from [98.139.212.146] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2012 07:10:01 -0000 Received: from [98.139.212.237] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2012 07:10:01 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 24 Jan 2012 07:10:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 357856.72253.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 82872 invoked by uid 60001); 24 Jan 2012 07:10:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1327389000; bh=s3t8q61UbalFX34TXMAbLm3iXkFdxpVJqW0IAKzmtNg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nMTyb31M6CBaYK1VJzdoKZDwsDvJiRGOA564fO8w6mTse7KZEAV1nOTMCkz+ZO8vBebmfxy0tcDcvrPlJsDS5shpJG901h6g5qaJ4c/njyuMH/l27aHSOrESM0tpGYodCNcMn2avi4/9YAI87/RGw+z4sA9sBhfZ5HtHCTkmueo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=B7RQNtQIjMX72ypigjn6FkSteMgDYTWTHV8S6Unw9wpOn57smGqQUHnMpp5w2xsSZA3Yn5MVbeBlVltr6LNLRbSc3lyJ1+/JQ+4EvFkvVZWo3QldobGpKgESaB8NuCe602Tv5FsDAOi2Az4yslBb0q0fgkKIUnAfLW+Ah06SPXc=; X-YMail-OSG: eb5sbyoVM1lCe9xml65rnvJjzPI52b.BjhFdBo9Hb6aOzge LpYv9nvO20Ju1MhZh38Fa1O.6aAW_H8BQYfTyivXWAE7byh_8AMsKr_1rKP4 D4b_5tq0AD8CDhOPS9pdRzoeDOiKpiDVeD3k4MbG7Kl1q2b7OSAaFJ3hZmWx djUS0iwBF4qDnWeXThbpthaHZD95kWykQNqMCuwG8LyFVVh4jvoEhMtFmsC9 K.G4ewLyxgZNmccMiaO4_lo4orxOUDbk8TpijJRWx4hp7lanjC2i8fG0BVnU K4If6EQu0f9hLqFyXzftqD7KPXtq8a5UJ5GdteCyJ6RnQkMJL6BJDhCvu9cM .3srgtpujQE0TQ3ijc18wC2A1MCRpJybB58on2GxfBlUgo96ADvz837Aghdm IL9gAD2GR8yKo2TLI.UfEWWyWAh4kQUuS_5jH6K59OrSpq_6ftIY- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Mon, 23 Jan 2012 23:10:00 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.338427 References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> <4F04E442.4000702@yahoo-inc.com> <8762gqev30.fsf@windlord.stanford.edu> <4F06183B.4010401@yahoo-inc.com> <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1327389000.74641.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Mon, 23 Jan 2012 23:10:00 -0800 (PST) From: William Mills To: William Mills , Tim Showalter , Russ Allbery In-Reply-To: <1325808084.1216.YahooMailNeo@web31812.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1741771676-1327389000=:74641" Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:10:32 -0000 ---125733401-1741771676-1327389000=:74641 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've been thinking about this quite a bit, and Tim's rebuke to me privately= that I really should think about JSON seriously before dismissing the idea= because HTTP really is harder to parse than I think it is struck home.=0A= =0AI'm still stuck on the fact that I think the HTTP we have to parse in th= e client for the mechanism to work is all OAuth 2 protocol =0Aor defined in= the mechanims (discovery) so it's more limited.=A0 On the server side it's= very limited, only enough to figure out the discovery.=A0 So I don't think= the HTTP here is that scary. The actual HTTP we have to parse for the mech= anism to work on the server side is mimimal, and well defined.=A0 Am I wron= g?=0A=0A=0ASO.... I'm trying to figure out how this would work and what we'= d need to do in order to make JSON work instead of HTTP as the authenticati= on message format.=A0 My assumptions are:=0A=A0 =0A=0A-=A0=A0=A0 We're pass= ing the Auth header in to a library, the SASL mechanism itself doesn't need= to parse it.=0A=0A=0AWe need to support right now for the profiles I know = about:=0A=0A-=A0=A0=A0 The user name and host name for discovery=0A-=A0=A0= =A0 The port number for things like MAC authentication=0A-=A0=A0=A0 the Aut= horization header payload=0A-=A0=A0=A0 discovery information for return to = the client=0A=0A=0AIt's possible we'll also need to pass in:=0A=0A-=A0=A0= =A0 The HTTP POST payload for profiles that require it (though I was assumi= ng GET only initially)=0A-=A0=A0=A0 Something else I'm forgetting about... = or for extension flexibility?=0A=0A=0AIn the end I'm presuming we're passin= g all the real HTTP into a library that will understand it anyway (which is= how my initial implementation is working) so we don't need to dive down in= to the header and POST body payload in the JSON. If this is right then the = JSON doesn't look that hard, but then again if what I have above is correct= then we're not talking about a general use HTTP parser either.=0A=0A=0AThe= OAuth 1.0a library I was playing with for this consumes and gives back the= entire Auth header, but I don't know if that design pattern is common.=0A= =0AWhere do we go from here?=0A=0A-bill=0A=0A=0A=0A=0A=0A=0A=0A____________= ____________________=0A From: William Mills =0ATo: Ti= m Showalter ; Russ Allbery =0ACc:= "kitten@ietf.org" =0ASent: Thursday, January 5, 2012 4:0= 1 PM=0ASubject: Re: [kitten] SASL OAuth: Next Steps=0A =0A=0AYeah, I really= hate this.=0A=0AThere's stuff in the MAC token spec for example that requi= res knowing the URL path, fragments, hostname, etc., and so we have to incl= ude every element form HTTP that might be required for any OAuth (HTTP base= d itself) authorization scheme.=A0 This means we have to write an entire ma= pping grammar for an entire HTTP payload into JSON.=0A=0AWhile I agree that= HTTP is non-trivial to parse, I don't think it's compelling enough for me = to like the change to JSON because there are enough HTTP parsing libraries = out there that an implementer should not have to do their own, they should = pull one in.=0AAs I said before, designing this in a vacuum HTTP is far dow= n the list, but I think in light of the fact that we're bridging from somet= hing that *is* HTTP it is less complex overall to stay consistent.=0A=0A=0A= =0A-bill=0A=0A=0A=0A________________________________=0A From: Tim Showalter= =0ATo: Russ Allbery =0ACc: "kitt= en@ietf.org" =0ASent: Thursday, January 5, 2012 1:38 PM= =0ASubject: Re: [kitten] SASL OAuth: Next Steps=0A =0AOn 1/4/12 6:34 PM, Ru= ss Allbery wrote:=0A> Chris Newman=A0 writes:=0A>>= Having a SASL parser call out to a header parser would be poor security=0A= >> design, because every line of code is an additional potential security= =0A>> vulnerability (especially prior to authentication) and a lot of code = is=0A>> needed for a 100% correct header parser. So I think it's actually= =0A>> important for a SASL mechanism to not accept arbitrary header syntax.= =0A> =0A> Based on my experience writing netnews implementations, which use= RFC 5322=0A> header field syntax very akin to the HTTP header field syntax= , I=0A> completely concur with Chris's reaction.=A0 The header field syntax= is=0A> surprisingly complex, particularly in the presence of encoding and= =0A> character set issues, and most=0A implementors do not implement it pro= perly.=0A=0AI'm really sorry to hear that -- I suspect you're right, and I = don't like it.=A0 I think trying to constrain JSON and define the mappings = is going to be a lot of work.=0A=0AIs there a simple way to specify a gener= al mapping?=A0 Or are we going to have to do this on a per-header basis?=0A= =0ATim=0A_______________________________________________=0AKitten mailing l= ist=0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten=0A=0A= =0A=0A_______________________________________________=0AKitten mailing list= =0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten ---125733401-1741771676-1327389000=:74641 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've been thinking about this quite a bit, and Tim's rebuke to me private= ly that I really should think about JSON seriously before dismissing the id= ea because HTTP really is harder to parse than I think it is struck home.

I'm still stuck on the fact that I think the HTTP we have to=0A parse in the client for the mechani= sm to work is all OAuth 2 protocol =0Aor defined in the mechanims (discover= y) so it's more limited.  On the server side it's very limited, only e= nough to figure out the discovery.  So I don't think the HTTP here is = that scary. The actual HTTP we have to parse for= the mechanism to work on the server side is mimimal, and well defined.&nbs= p; Am I wrong?

SO...= . I'm trying to figure out how this would work and what we'd need to do in = order to make JSON work instead of HTTP as the authentication message forma= t.  My assumptions are:
 
-    We're pass= ing the Auth header in to a library, the SASL mechanism itself doesn't need= to parse it.

We need to support right = now for the profiles I know about:

-    Th= e user name and host name for discovery
-    The port number for things= like MAC authentication
-    the Authorization header payload
-   = discovery information for return to the client

It's possible we'll= also need to pass in:

-    T= he HTTP POST payload for profiles that require it (though I was assuming GE= T only initially)
-    Something else I'm forgetting about... or for e= xtension flexibility?

In the end I'm presuming we're passing all the real H= TTP into a library that will understand it anyway (which is how my initial = implementation is working) so we don't need to dive down into the header an= d POST body payload in the JSON. If this is right then the JSON doesn't loo= k that hard, but then again if what I have above is correct then we're not = talking about a general use HTTP parser either.

The OAuth 1.0a libr= ary I was playing with for this consumes and gives back the entire Auth hea= der, but I don't know if that design pattern is common.
Where do we go = from here?

-bill




<= div>
From: William Mills <wmills@yahoo-inc.com>
<= span style=3D"font-weight: bold;">To: Tim Showalter <timshow@= yahoo-inc.com>; Russ Allbery <rra@stanford.edu>
Cc: "kitten@ietf.org" <kitten@ietf.or= g>
Sent: Thursday,= January 5, 2012 4:01 PM
Subject:= Re: [kitten] SASL OAuth: Next Steps

=0A<= div id=3D"yiv1805603019">
Yeah, I really hate this.

There's stuff in the MAC token spec for example that r= equires knowing the URL path, fragments, hostname, etc., and so we have to = include every element form HTTP that might be required for any OAuth (HTTP = based itself) authorization scheme.  This means we have to write an en= tire mapping grammar for an entire HTTP payload into JSON.

While I agree that HTTP is non-trivial t= o parse, I don't think it's compelling enough for me to like the change to = JSON because there are enough HTTP parsing libraries out there that an impl= ementer should not have to do their own, they should pull one in.

As I said before, designing this in a vacuum HTTP is far down the=0A list, but I think in light of the fact that we're bridging= from something that *is* HTTP it is less complex overall to stay consisten= t.


-bill

=
From: Tim Showalte= r <timshow@yahoo-inc.com>
To= : Russ Allbery <rra@stanford.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org> <= br> Sent: Thursday, January= 5, 2012 1:38 PM
Subject: Re: [kitten] SASL OAuth: Next Steps
=0AOn 1/4/12 6:34 PM= , Russ Allbery wrote:
> Chris Newman<chris.newman@oracle.com>  writes:
>>= ; Having a SASL parser call out to a header parser would be poor security>> design, because every line of code is an additional potential se= curity
>> vulnerability (especially prior to authentication) and a= lot of code is
>> needed for a 100% correct header parser. So I t= hink it's actually
>> important for a SASL mechanism to not accept= arbitrary header syntax.
>
> Based on my experience writing n= etnews implementations, which use RFC 5322
> header field syntax very= akin to the HTTP header field syntax, I
> completely concur with Chr= is's reaction.  The header field syntax is
> surprisingly comple= x, particularly in the presence of encoding and
> character set issues, and most=0A implementors do not implement it properl= y.

I'm really sorry to hear that -- I suspect you're right, and I do= n't like it.  I think trying to constrain JSON and define the mappings= is going to be a lot of work.

Is there a simple way to specify a ge= neral mapping?  Or are we going to have to do this on a per-header bas= is?

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



________________________________________= _______
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

=
---125733401-1741771676-1327389000=:74641--