From nico@cryptonector.com Mon Dec 2 13:04:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999D71ADF73 for ; Mon, 2 Dec 2013 13:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FROM_12LTRDOM=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE2iNiX2G_JS for ; Mon, 2 Dec 2013 13:04:53 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D86791ADF5C for ; Mon, 2 Dec 2013 13:04:53 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 9BE0E2F4071 for ; Mon, 2 Dec 2013 13:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=UBe9bqLdLWCKJ7y+IG5iNj42sbI=; b=qqSXdqBftSk xl49hGAPYLrgASW/3WanDigOU8TvRt30YkCpMZUlyO1l47CT4BJ7hzp/3UNBTHwT W6d4acfxD5P5G9540dXyOlgTUJrg+pYZYyhihdr9jexyUtoO5EQXKARqtoxvqflV AA+KNLLBh1XlYEIaOF8SPSg+F4boADxM= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 49D6C2F4057 for ; Mon, 2 Dec 2013 13:04:51 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hn6so1070763wib.4 for ; Mon, 02 Dec 2013 13:04:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=74A1OFeeGl/mtFAWkImIl8p7SK0YaNpw9e2W+aBhxXI=; b=Ih6Qr+i2rNInKwIldYMIZIJ4d/4yU6emT9rqIR/Qt5SGiZNfpNPd8Ae4wLvhWmZwbg basndwtBtvMowle2Xa3v6qyAwkeYaRw+QEDa5yiZI2bexkPgHpuf8Op7C6gnc10OR1Pn oNKOxuAboqRzb/AiXbPMozBtEl0CKlDHi0e+q+NREcostE1JJz7nn7WP9xRLhKqri8yZ 3uems0Vk3Qu/g40r/67LHFfMRzKuSNbbel3f5S3BP77Ldr6MXoDf6+Cjz9nj+fFNkPlD LoZeKRvcOB3mvrPOBQYIKoKCt8e65hokW5DPgZ0ypx6rrBon8pUg0OMvGd1s2oWkAjI6 c+3Q== MIME-Version: 1.0 X-Received: by 10.194.171.34 with SMTP id ar2mr13407wjc.81.1386018289478; Mon, 02 Dec 2013 13:04:49 -0800 (PST) Received: by 10.216.151.136 with HTTP; Mon, 2 Dec 2013 13:04:49 -0800 (PST) Date: Mon, 2 Dec 2013 15:04:49 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [kitten] New s2k and exposing the strength (iteration count) part of s2kparams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 21:04:54 -0000 ISTM that we should: 1) Expose the iteration count of the otherwise-opaque s2k params, and standardize it, renaming it a strength indication and leaving its interpretation as mechanism-specific. I.e., from now on all new enctypes with s2kparams will have theirs start with a four-octet, network byte order unsigned measure of strength. The rationale for this is based on: a) that utilities like ktutil need access to this in some cases (e.g., when KDCs are not reachable) b) KDC-side admin utilities (e.g., kadmin, LDAP clients of an LDAP-based KDB) need to know how to set s2k strenght, otherwise there's no way to ever change the default! c) we need it to be easy to add at least a synthetic strength parameter option in administrative tools d) all new enctypes with s2k functions can be expected to have a reasonable synthetic strength measure e) admins can be expected to understand strength measures for specific enctypes (particularly given how few enctypes/enctype families we'll have that have opaque s2kparams). Enctypes can't be expected to have normalized strength measures though. I.e., a strength of 4096 may mean one thing to one enctype and another to a different enctype. 2) It'd be nice if we could add memory-hard s2k functions. I'm not sure what NIST is prepared to consider here. I guess anything provably not weaker than PBKDF2 should be acceptable, but I'm not sure how to construct such a thing (XOR of two s2ks is not necessarily provably not weaker than either of the s2ks; consider the case where they are the same s2k!). For a memory- and compute-hard s2k the strength measure might be composed of two numbers, one indicating memory strength and the other indicating compute strength. Nico -- From jhutz@cmu.edu Mon Dec 2 13:38:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C01ADF8B for ; Mon, 2 Dec 2013 13:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6g6BGQgZhv0 for ; Mon, 2 Dec 2013 13:38:56 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id E97961ADF87 for ; Mon, 2 Dec 2013 13:38:55 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rB2LcqUp029511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 16:38:52 -0500 (EST) Message-ID: <1386020332.9407.118.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Mon, 02 Dec 2013 16:38:52 -0500 In-Reply-To: <32722_1386018295_rB2L4rvE023770_CAK3OfOgeJW9XoaNYKytKQqeTzjgCE4xNnhhhCyhBzZZ=kJ+o4w@mail.gmail.com> References: <32722_1386018295_rB2L4rvE023770_CAK3OfOgeJW9XoaNYKytKQqeTzjgCE4xNnhhhCyhBzZZ=kJ+o4w@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [kitten] New s2k and exposing the strength (iteration count) part of s2kparams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 21:38:58 -0000 On Mon, 2013-12-02 at 15:04 -0600, Nico Williams wrote: > ISTM that we should: > > 1) Expose the iteration count of the otherwise-opaque s2k params, and > standardize it, renaming it a strength indication and leaving its > interpretation as mechanism-specific. I.e., from now on all new > enctypes with s2kparams will have theirs start with a four-octet, > network byte order unsigned measure of strength. I don't think that's necessary. The s2k parameters aren't really opaque; they're enctype-specific and pseudo-opaque at the Kerberos protocol layer, in the same way that PA-DATA and authorization data are. IMHO it works better that way, because it means we can carry such things end-to-end without all of the intermediate pieces having to understand them. This has brought us extensibility that otherwise would have been impossible, and even some that we previously thought _was_ impossible (e.g. ticket extensions using a magic enctype). It might be useful for Kerberos libraries, admin tools, and KDC implementations to include interfaces for managing s2k parameters. However, I don't think doing so requires that we mandate that future enctypes use a particular format for s2k parameters, or use a single linear "strength" parameter. Future S2K algorithms may have arbitrary numbers of parameters, and while it may be possible and even desirable to compute a single "strength indication" from those parameters, the operation is not likely to be reversible, which means that s2k params will need to encode the actual individual parameters. > 2) It'd be nice if we could add memory-hard s2k functions. I'm not > sure what NIST is prepared to consider here. I guess anything > provably not weaker than PBKDF2 should be acceptable, but I'm not sure > how to construct such a thing (XOR of two s2ks is not necessarily > provably not weaker than either of the s2ks; consider the case where > they are the same s2k!). > > For a memory- and compute-hard s2k the strength measure might be > composed of two numbers, one indicating memory strength and the other > indicating compute strength. Oh, look; you've just made my point for me. :-) -- Jeff From nico@cryptonector.com Mon Dec 2 14:02:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DFD1ADF95 for ; Mon, 2 Dec 2013 14:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP5O03Z95G0v for ; Mon, 2 Dec 2013 14:02:07 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC01ADF79 for ; Mon, 2 Dec 2013 14:02:07 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id CA60D6B0059; Mon, 2 Dec 2013 14:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=loufnOUeC33iCQ ++KISf//wMfZU=; b=cXJAwJmWhrTMXuHy9/0u36MNHnu7eEKhrWoaR7tTyZHKFm A6xEPLiVwj5dMIR/cM2VQmglbQbYzZxew0luI5TGXd7oxAEkCOZTEyjVyps9xMyy Tzmf4OHaVnFKT8WNVvH6IP1CPepbIjbXUhUyro6zrURKOgC9jnN3TyEIgaSAQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 6AB326B0078; Mon, 2 Dec 2013 14:02:04 -0800 (PST) Date: Mon, 2 Dec 2013 16:02:03 -0600 From: Nico Williams To: Jeffrey Hutzelman Message-ID: <20131202220159.GX21240@localhost> References: <32722_1386018295_rB2L4rvE023770_CAK3OfOgeJW9XoaNYKytKQqeTzjgCE4xNnhhhCyhBzZZ=kJ+o4w@mail.gmail.com> <1386020332.9407.118.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1386020332.9407.118.camel@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] New s2k and exposing the strength (iteration count) part of s2kparams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:02:09 -0000 On Mon, Dec 02, 2013 at 04:38:52PM -0500, Jeffrey Hutzelman wrote: > On Mon, 2013-12-02 at 15:04 -0600, Nico Williams wrote: > > 2) [...] > > Oh, look; you've just made my point for me. :-) Maybe I should start writing backwards :) (Hey look, I'm responding backwards!) > > 1) Expose the iteration count of the otherwise-opaque s2k params, and > > standardize it, renaming it a strength indication and leaving its > > interpretation as mechanism-specific. I.e., from now on all new > > enctypes with s2kparams will have theirs start with a four-octet, > > network byte order unsigned measure of strength. I conflated two things, actually: on-the-wire representation, and logical representation. Let me clarify my proposal in light of that: - every new enctype shall have a 32-bit unsigned integer strength measure - I don't care how that's represented on the wire (but I think it'd be convenient to stick to my original proposal above) > I don't think that's necessary. The s2k parameters aren't really > opaque; they're enctype-specific and pseudo-opaque at the Kerberos > protocol layer, in the same way that PA-DATA and authorization data are. They are most definitely opaque (OCTET STRING) because they are enctype- specific and layers above the enctype musn't interpret them, which means that... ...in practice what has happened is that this opaqueness has been an impediment to exposing these parameters in any interfaces (CLIs, GUIs, BUIs, APIs) other than configuration, and changing the default therefore results in non-interoperability (e.g., can't use ktutil to add password- derived keys to a keytab -- I know, that's almost a useful authorization feature, except it's neither). Yes, we could preserve opaqueness of s2kparams at all layers above the enctype and yet manage to add suitable interfaces. But we've had a decade and we haven't. I think that's evidence that the original approach hasn't worked well. We should either hardcode the s2kparams or provide at least one knob that all can share. > IMHO it works better that way, because it means we can carry such things > end-to-end without all of the intermediate pieces having to understand > them. This has brought us extensibility that otherwise would have been > impossible, and even some that we previously thought _was_ impossible > (e.g. ticket extensions using a magic enctype). In theory I agree, in practice I don't. > It might be useful for Kerberos libraries, admin tools, and KDC > implementations to include interfaces for managing s2k parameters. It most definitely would be. It hasn't happened. We've had a decade. Perhaps if we make such interfaces a requirement implementors will get to it? I doubt it... There's no Internet standard-compliance police. > However, I don't think doing so requires that we mandate that future > enctypes use a particular format for s2k parameters, or use a single > linear "strength" parameter. Future S2K algorithms may have arbitrary > numbers of parameters, and while it may be possible and even desirable > to compute a single "strength indication" from those parameters, the > operation is not likely to be reversible, which means that s2k params > will need to encode the actual individual parameters. I understand this quite well. I don't think that argument will cause implementors to finally add the missing interfaces. Therefore I'd rather settle for a much-more-likely-to-succeed compromise. A single synthetic strength measure is *clearly* problematic (you and I, and others on this list too, have commiserated over SASL's SSF many a time, so you know I agree), but for s2kparams it's much more workable and less dangerous than for mechanisms that involve negotiations (which is half the source of SSF's problems). Nico -- From nico@cryptonector.com Wed Dec 4 23:19:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2D21A1F74 for ; Wed, 4 Dec 2013 23:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_12LTRDOM=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLf-LAriY5cF for ; Wed, 4 Dec 2013 23:18:59 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C549D1A1F5D for ; Wed, 4 Dec 2013 23:18:59 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id B52C576806F for ; Wed, 4 Dec 2013 23:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=g466QncW02JmiJE9uavv0p+ORkE=; b=wWxsNRGYPee 7QPbarzf8q7SogFTmJ9U2w7DD1PEUufnbaiLppn97XH0q/2pwefPZN4a+VdY3A4y R1WXKCm4T5bVYWR4gHvV9kWvDlsLjBp/5NveY60/rmUvuIPWTFxmVrOUPYXcaRkK UsLXrbbAqtBKZ2+bzd92+P+lNGGEaDdM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 65C6276806C for ; Wed, 4 Dec 2013 23:18:56 -0800 (PST) Date: Thu, 5 Dec 2013 01:18:55 -0600 From: Nico Williams To: kitten@ietf.org Message-ID: <20131205071852.GO21240@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 07:19:00 -0000 PKINIT (RFC4556) adds a PKIX certicate SAN (id-pkinit-san) for representing Kerberos principal names of AS clients and servers. I believe that id-pkinit-san does not denote "for PKINIT", and therefore was misnamed. It should have been named id-kerberos-san. Presense of a id-pkinit-san in a certificate is not sufficient to grant the subject access to the given Kerberos principal name nor to resources that that name is authorized to access. Additional policy is needed, and I believe the RFC is clear about this. I ask because I'd like RFC6717 (kerberized online CA protocol) servers to include the client's cname and crealm in an id-pkinit-san in the certificate to be issued. I see no reason not to, though it is probably important to note that the kx509 service's PKIX issuer credentials should not be acceptable as issuers of PKINIT client certs by any KDCs (particularly the same as the issuing kx509 service's realm's)... ...unless one *really* wants to use Kerberos->kx509->PKINIT as a form of PKCROSS... :) ...which conveniently just happens to be my proposal for PKCROSS! Nico -- From nico@cryptonector.com Wed Dec 4 23:28:07 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EFA1A8034 for ; Wed, 4 Dec 2013 23:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_13NZ2NP3lL for ; Wed, 4 Dec 2013 23:28:06 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9901A1F78 for ; Wed, 4 Dec 2013 23:28:06 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 617532005D105 for ; Wed, 4 Dec 2013 23:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=bbOejoH1TsaOJSTqIYic0gfHnJ0 =; b=kqn96Em5PIjI71riard5AHssAbDTgPek2aOncc2Lcm6k1/5EHaj+EWAOrB1 6NtbdmSbo4RQGU0XBMKR/1F5hqD9oIBbnBnW/43sI72ATcyBp9JJbYPSixHRPO2E 6yIptbT5n1A1he7c3S1cZBzmO9TkDAnd013aBur4aaILd4fE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 1570D2005D102 for ; Wed, 4 Dec 2013 23:28:03 -0800 (PST) Date: Thu, 5 Dec 2013 01:28:02 -0600 From: Nico Williams To: kitten@ietf.org Message-ID: <20131205072759.GR21240@localhost> References: <20131205071852.GO21240@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131205071852.GO21240@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 07:28:07 -0000 On Thu, Dec 05, 2013 at 01:18:55AM -0600, Nico Williams wrote: > ...unless one *really* wants to use Kerberos->kx509->PKINIT as a form of > PKCROSS... :) > > ...which conveniently just happens to be my proposal for PKCROSS! Sidebar: PKINIT ASes would need to encode the certification trust path of their clients as Kerberos transited paths. And we'd have more pressure to support X.500-style names in transit paths (and transit path validation policies), though at least PKINIT ASes could insist that foreign-realm client cert issuers have id-pkinit-sans in their issuer certs so as to avoid having to have X.500-style names in transit paths. From lukeh@padl.com Wed Dec 4 23:33:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331921AC3FA for ; Wed, 4 Dec 2013 23:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI7Hx39dguic for ; Wed, 4 Dec 2013 23:33:23 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1471AC3DD for ; Wed, 4 Dec 2013 23:33:23 -0800 (PST) Received: by us.padl.com with ESMTP id rB57X7sx005934; Thu, 5 Dec 2013 02:33:11 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luke Howard In-Reply-To: <20131205071852.GO21240@localhost> Date: Thu, 5 Dec 2013 18:33:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <325FF802-C49E-4D99-AFC4-F7B78F182A38@padl.com> References: <20131205071852.GO21240@localhost> To: Nicolas Williams X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 07:33:25 -0000 PKU2U (draft-zhu-pku2u), BrowserID (draft-howard-gss-browserid) also use = id-pkinit-san. So I don't think there is a problem using it in other = specifications. -- Luke On 5 Dec 2013, at 6:18 pm, Nico Williams wrote: > PKINIT (RFC4556) adds a PKIX certicate SAN (id-pkinit-san) for = representing Kerberos > principal names of AS clients and servers. >=20 > I believe that id-pkinit-san does not denote "for PKINIT", and = therefore > was misnamed. It should have been named id-kerberos-san. >=20 > Presense of a id-pkinit-san in a certificate is not sufficient to = grant > the subject access to the given Kerberos principal name nor to = resources > that that name is authorized to access. Additional policy is needed, > and I believe the RFC is clear about this. >=20 > I ask because I'd like RFC6717 (kerberized online CA protocol) servers > to include the client's cname and crealm in an id-pkinit-san in the > certificate to be issued. I see no reason not to, though it is = probably > important to note that the kx509 service's PKIX issuer credentials > should not be acceptable as issuers of PKINIT client certs by any KDCs > (particularly the same as the issuing kx509 service's realm's)... >=20 > ...unless one *really* wants to use Kerberos->kx509->PKINIT as a form = of > PKCROSS... :) >=20 > ...which conveniently just happens to be my proposal for PKCROSS! >=20 > Nico > --=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com | www.padl.com From jhutz@cmu.edu Thu Dec 5 12:45:44 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13121AE10C for ; Thu, 5 Dec 2013 12:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWa6PJCRRwxV for ; Thu, 5 Dec 2013 12:45:31 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id 439FF1AE1C6 for ; Thu, 5 Dec 2013 12:45:21 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rB5KjDCE004309 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 15:45:13 -0500 (EST) Message-ID: <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Thu, 05 Dec 2013 15:45:13 -0500 In-Reply-To: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> 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.201 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 20:45:44 -0000 On Thu, 2013-12-05 at 01:18 -0600, Nico Williams wrote: > PKINIT (RFC4556) adds a PKIX certicate SAN (id-pkinit-san) for representing Kerberos > principal names of AS clients and servers. > > I believe that id-pkinit-san does not denote "for PKINIT", and therefore > was misnamed. It should have been named id-kerberos-san. Indeed. This was always intended to be the way to represent Kerberos principal names in certs; PKINIT was just the first thing to get there. -- Jeff From nico@cryptonector.com Thu Dec 5 12:50:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29711AE123 for ; Thu, 5 Dec 2013 12:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAv3PsbWhDjh for ; Thu, 5 Dec 2013 12:50:12 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id D14AF1AC829 for ; Thu, 5 Dec 2013 12:50:12 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 789B61DE060; Thu, 5 Dec 2013 12:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5OOqkXwse7bx2P 4xuccX1b3a+2Q=; b=HfMaVSodjLkf0kykRu1cZ5y9TY2DwisAo/8H9DqLkL+YXM UWNQZ4AfxxYnKjJW5oHHeNrv7nIew7QZLeChTNuvy+ff37qUXF7+4PuGApM1DB2i MED1V3aNTCGYQVxC5XlgS2EpnZSTgfiD/A7cc/8FDlQcTWj6uCFWYLVsPCLv8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 127891DE059; Thu, 5 Dec 2013 12:50:08 -0800 (PST) Date: Thu, 5 Dec 2013 14:50:07 -0600 From: Nico Williams To: Jeffrey Hutzelman Message-ID: <20131205205004.GA21240@localhost> References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 20:50:16 -0000 On Thu, Dec 05, 2013 at 03:45:13PM -0500, Jeffrey Hutzelman wrote: > On Thu, 2013-12-05 at 01:18 -0600, Nico Williams wrote: > > PKINIT (RFC4556) adds a PKIX certicate SAN (id-pkinit-san) for > > representing Kerberos principal names of AS clients and servers. > > > > I believe that id-pkinit-san does not denote "for PKINIT", and > > therefore was misnamed. It should have been named id-kerberos-san. > > Indeed. This was always intended to be the way to represent Kerberos > principal names in certs; PKINIT was just the first thing to get there. Thanks. Should we file an erratum against RFC4556 to rename it? Nico -- From nico@cryptonector.com Thu Dec 5 12:58:21 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD8C1AE0C9 for ; Thu, 5 Dec 2013 12:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PiB3uZjsFlm for ; Thu, 5 Dec 2013 12:58:20 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1264C1AE0B8 for ; Thu, 5 Dec 2013 12:58:20 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 872042005D908; Thu, 5 Dec 2013 12:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=R7KlMYQ85NreDi vd68X92L9LoD8=; b=D/1Tvm/J86cBd5R+nR5na4IvAcTf+F1CZ3R1P8g2iUVHv8 8KjSWfnhuDzFvzzNcSGbksNFuEQVhBcphmUwIdTu9CzvoKLJ9hw9GyTP5EOQb3WT ALhcXZ5U+kKvHPjSk7booEuhgwt1iU697DhHQQX5HrZ2ApBmX3HbmHIbDplHk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 293302005D907; Thu, 5 Dec 2013 12:58:16 -0800 (PST) Date: Thu, 5 Dec 2013 14:58:15 -0600 From: Nico Williams To: Jeffrey Hutzelman Message-ID: <20131205205812.GB21240@localhost> References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> <20131205205004.GA21240@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131205205004.GA21240@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 20:58:21 -0000 On Thu, Dec 05, 2013 at 02:50:07PM -0600, Nico Williams wrote: > Thanks. Should we file an erratum against RFC4556 to rename it? Just did. From jhutz@cmu.edu Thu Dec 5 13:17:53 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D51AE180 for ; Thu, 5 Dec 2013 13:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlvB1c02d8np for ; Thu, 5 Dec 2013 13:17:51 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id A7C1B1AE149 for ; Thu, 5 Dec 2013 13:17:51 -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 rB5LHivK008821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 16:17:45 -0500 (EST) Message-ID: <1386278264.9407.142.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Thu, 05 Dec 2013 16:17:44 -0500 In-Reply-To: <20131205205812.GB21240@localhost> References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> <20131205205004.GA21240@localhost> <20131205205812.GB21240@localhost> 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.200 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 21:17:53 -0000 On Thu, 2013-12-05 at 14:58 -0600, Nico Williams wrote: > On Thu, Dec 05, 2013 at 02:50:07PM -0600, Nico Williams wrote: > > Thanks. Should we file an erratum against RFC4556 to rename it? > > Just did. No, that's not merely editorial; it's the name of an identifier in what is effectively a published interface. Even though it doesn't affect anything on the wire, it does affect things that import the ASN.1 module, so a name change would be backward-incompatible. I think we're better off leaving it alone and just clarifying that it's intended use is more general than just PKINIT. -- Jeff From nico@cryptonector.com Thu Dec 5 13:46:44 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7081AC3DA for ; Thu, 5 Dec 2013 13:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZro9kfyfWdd for ; Thu, 5 Dec 2013 13:46:41 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9501AE1BA for ; Thu, 5 Dec 2013 13:46:41 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id D43CD428076; Thu, 5 Dec 2013 13:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4iEHH/0QkG5c4C 4Z1DM7N9QocpY=; b=fkD91YbnSJ8fdFVGCVMncGYywAxwJhvIwzb77lPZv1ycSR m+N07ZK1K9pPlXH//QwAeEHYnCuyCw95iHm0IGHky566xmSji981wxRv6tAn14gV JeWT6V9VVhFsAqRdPHSKwBOIjCssRYJf61QB7Pf1YlX1qNHd4Ij28lLRxwKcs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPA id 749F6428075; Thu, 5 Dec 2013 13:46:37 -0800 (PST) Date: Thu, 5 Dec 2013 15:46:36 -0600 From: Nico Williams To: Jeffrey Hutzelman Message-ID: <20131205214633.GD21240@localhost> References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> <20131205205004.GA21240@localhost> <20131205205812.GB21240@localhost> <1386278264.9407.142.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1386278264.9407.142.camel@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 21:46:44 -0000 On Thu, Dec 05, 2013 at 04:17:44PM -0500, Jeffrey Hutzelman wrote: > On Thu, 2013-12-05 at 14:58 -0600, Nico Williams wrote: > > On Thu, Dec 05, 2013 at 02:50:07PM -0600, Nico Williams wrote: > > > Thanks. Should we file an erratum against RFC4556 to rename it? > > > > Just did. > > No, that's not merely editorial; it's the name of an identifier in what > is effectively a published interface. Even though it doesn't affect > anything on the wire, it does affect things that import the ASN.1 > module, so a name change would be backward-incompatible. I think we're > better off leaving it alone and just clarifying that it's intended use > is more general than just PKINIT. OK, so I should update the erratum, or the AD can do it. From nico@cryptonector.com Thu Dec 5 13:47:32 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CC31AE1BE for ; Thu, 5 Dec 2013 13:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmAtilzlj1_g for ; Thu, 5 Dec 2013 13:47:30 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id BD6201AC3DA for ; Thu, 5 Dec 2013 13:47:30 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 7273042807A; Thu, 5 Dec 2013 13:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=E9tSAoOTwV53HQ /CTz4OlSNuDFM=; b=KFgLBUFAYPdMyoSlME9NJQKu8qjyJxfSdypgJX/hSWrGX0 LSubip3wWxKBj5zgWoAEbiHIL3A6sv3sM3Nx5qdAwcOipkmdjg3n3JfHB+ZB8g2i 101VWurKIB8DqOPVjUeKvEeAk0y5mXwDjfKI2s9iQVuuYounne/DtgVXR1ie0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPA id 12CBE428078; Thu, 5 Dec 2013 13:47:26 -0800 (PST) Date: Thu, 5 Dec 2013 15:47:26 -0600 From: Nico Williams To: Jeffrey Hutzelman Message-ID: <20131205214722.GE21240@localhost> References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> <20131205205004.GA21240@localhost> <20131205205812.GB21240@localhost> <1386278264.9407.142.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1386278264.9407.142.camel@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 21:47:32 -0000 On Thu, Dec 05, 2013 at 04:17:44PM -0500, Jeffrey Hutzelman wrote: > On Thu, 2013-12-05 at 14:58 -0600, Nico Williams wrote: > > On Thu, Dec 05, 2013 at 02:50:07PM -0600, Nico Williams wrote: > > > Thanks. Should we file an erratum against RFC4556 to rename it? > > > > Just did. > > No, that's not merely editorial; it's the name of an identifier in what > is effectively a published interface. Even though it doesn't affect > anything on the wire, it does affect things that import the ASN.1 > module, so a name change would be backward-incompatible. I think we're > better off leaving it alone and just clarifying that it's intended use > is more general than just PKINIT. Although... we can always add an alias for a type. Nico -- From prvs=1052909841=jaltman@secure-endpoints.com Thu Dec 5 16:50:32 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9361AE236 for ; Thu, 5 Dec 2013 16:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1E2B4k9W9CP for ; Thu, 5 Dec 2013 16:50:30 -0800 (PST) Received: from mail.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2595A1AE23F for ; Thu, 5 Dec 2013 16:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1386291026; x=1386895826; q=dns/txt; h=DomainKey-Signature:Received:VBR-Info:Message-ID: Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:OpenPGP:Content-Type; bh=PDkC8U1/hI2oHKQ5 h1OhvjOhDsSL/vJ16zzNRLFfJp8=; b=fKVrkgoDXTYPQRcyw8GOF5gdvdeBeklT F40rFL+kqRcidHaOvkywChTJOdG5JrwNKdUK0rozhKcY1eXwYglDBVLeEa/NFtZJ qxCKJFHrBCg04A7N7hJyQ6oWXh1EZrPYsndmroaIOp6DmJYY5sOjR3NpY/VQHt8h D8Nw2ue1FCo= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=qcnT/jbKam964RcvFPqD/OAKum1WWV++mM36+zltcH1BJR6jz87rE4/1XwrF YpqYWS/3siD3z+c3on+tgHWkFyDC35JmyFjn7yULJRr7wAqh31da/PWTX 0fwHW6o9kKpqhS56axZhdSzg6alKrC+8DAaQOIGU9T/4j/7ZtvDHy4=; X-MDAV-Result: clean X-MDAV-Processed: mail.secure-endpoints.com, Thu, 05 Dec 2013 19:50:26 -0500 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v13.6.0) with ESMTP id md50000555604.msg for ; Thu, 05 Dec 2013 19:50:25 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-Spam-Processed: mail.secure-endpoints.com, Thu, 05 Dec 2013 19:50:25 -0500 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:131206:md50000555604::zJHM61cPi5jYA1w3:0000UtpZ X-Return-Path: prvs=1052909841=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <52A11F4C.90605@secure-endpoints.com> Date: Thu, 05 Dec 2013 19:50:20 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Jeffrey Hutzelman , Nico Williams References: <24661_1386227942_rB57J0KZ025231_20131205071852.GO21240@localhost> <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1386276313.9407.139.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.6 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090705060207010007030606" Cc: kitten@ietf.org Subject: Re: [kitten] Is id-pkinit-san misnamed? Can it be reused by kca? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 00:50:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090705060207010007030606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/5/2013 3:45 PM, Jeffrey Hutzelman wrote: > On Thu, 2013-12-05 at 01:18 -0600, Nico Williams wrote: >> PKINIT (RFC4556) adds a PKIX certicate SAN (id-pkinit-san) for represe= nting Kerberos >> principal names of AS clients and servers. >> >> I believe that id-pkinit-san does not denote "for PKINIT", and therefo= re >> was misnamed. It should have been named id-kerberos-san. >=20 > Indeed. This was always intended to be the way to represent Kerberos > principal names in certs; PKINIT was just the first thing to get there.= >=20 > -- Jeff Just for the record, the UMich kx509 KCA service uses /* * krb5PrincipalName, as defined in RFC 1510 and pkinit draft * * Realm ::=3D GeneralString * * PrincipalName ::=3D SEQUENCE { * name-type[0] INTEGER, * name-string[1] SEQUENCE OF GeneralString * } * * KerberosName ::=3D SEQUENCE { * realm [0] Realm, -- as define in RFC 1510 * principalName [1] PrincipalName, -- as define in RFC 1510 * } * * krb5 OBJECT IDENTIFIER ::=3D { * iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) * } * * krb5PrincipalName OBJECT IDENTIFIER ::=3D { krb5 2 } * */ This was taken from draft-ietf-cat-kerberos-pk-init-09. It was removed in draft-ietf-cat-kerberos-pk-init-17. Jeffrey Altman --------------ms090705060207010007030606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjA2MDA1MDIwWjAjBgkqhkiG9w0BCQQxFgQUJLmFMpEksnc0bqdC/7qfZrfi/gowbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB ADeQCPosviuXp185Vkt7qqIHN8RvDhuLbTLpGqkCcqTIzY7t4FvGlk6pWRMoKdBkOGA3cra4 M1ecG/phw4/WgB+1gQowHwmEomgApA5GwWK8wGgNL/yqrqiXZs8+HAthgmCuZkUVMwjcI5qO 4Q9P5eoDdEpSXPfdAuT2isOC9rGgC9SK/xE4E2WEXiV8rVlz5GXURFiprnnMmWq/JxHFXT6o 2PaqOrH6ua2bktyABCWtd+QgO9ol6OHVD9iJ5ER/EHG77rytq76yIzOju//cJQk18eVCn7Qj F+5hbAmIaxkgHsDBDslmG9tTC7zkjwSDBLxRGkN/OuB2Jhk53qdbRbcAAAAAAAA= --------------ms090705060207010007030606-- From kaduk@mit.edu Fri Dec 6 10:37:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD06A1AE328 for ; Fri, 6 Dec 2013 10:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbhuSx_-7r0w for ; Fri, 6 Dec 2013 10:37:13 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBF71AE0D4 for ; Fri, 6 Dec 2013 10:37:12 -0800 (PST) X-AuditID: 12074424-b7fa56d000000be4-3e-52a21955c2b6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A1.18.03044.55912A25; Fri, 6 Dec 2013 13:37:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rB6Ib8oO019274; Fri, 6 Dec 2013 13:37:08 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rB6Ib6C9020899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Dec 2013 13:37:08 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rB6Ib634020716; Fri, 6 Dec 2013 13:37:06 -0500 (EST) Date: Fri, 6 Dec 2013 13:37:06 -0500 (EST) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrBsquSjI4ModDoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro2f3BbaCzZwVnx7HNzBuY+9i5OCQEDCRWPvKuIuRE8gUk7hw bz1bFyMXh5DAbCaJZz2rWSGcDYwSj+beZIdwDjJJPFz7mQmkRUigXmLat4msIDaLgJbEy76v YDabgIrEzDcb2UBsEQFJiWNPzjOD2MwCwhLrz80As4UFNCQ2vT0AVsMpYCnRdquPHcTmFXCU WDT9CzvEfAuJJbs/gtWICuhIrN4/hQWiRlDi5MwnLBAzLSXO/bnONoFRcBaS1CwkqQWMTKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0zfVyM0v0UlNKNzGCQpLdRWUHY/MhpUOMAhyMSjy8HKsW BAmxJpYVV+YeYpTkYFIS5c0RXRQkxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3yJ2FQUK8KYmV ValF+TApaQ4WJXHeWxz2QUIC6YklqdmpqQWpRTBZGQ4OJQneFgmgoYJFqempFWmZOSUIaSYO TpDhPEDDe0FqeIsLEnOLM9Mh8qcYFaXEebeDJARAEhmleXC9sJTxilEc6BVh3vkgVTzAdAPX /QpoMBPQ4OYH80AGlyQipKQaGDd2zZw/obegxMjE3UC2s8L9foXIgkaVG+tzfiptWCqwhWuq YvIBxsupv602yqroy2pNCXpvf/PAFIcnBxc7rZlREqduP+GWgUyAo21x47dlNpEJLCzPHnvY GxwIdQ04styge55HasRF1sInYSyy8VNjp7NJFEWsEE9JvxB61mnvtmZVlpLDSizFGYmGWsxF xYkA/6lmhvQCAAA= Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:37:19 -0000 On Thu, 7 Nov 2013, Tom Yu wrote: > Here are what I think are the remaining open issues for CAMMAC. > > Wrapping of CAMMAC: > > Do we recommend enclosing a CAMMAC inside an AD-IF-RELEVANT? RFC 4120 > says that authorization data are critical, i.e., an implementaiton > must reject unrecognized authorization data. Alternatively, we could > require that CAMMAC be enclosed in an AD-KDCIssued, and drop the > consequently redundant "svc-verifier" from CAMMAC. It looks like this bit got all the follow-up and no one replied to the rest. > Minor encoding change: > > Do we change "other-verifiers" from "[3] SEQUENCE OF Verifier" to > "[3] SEQUENCE (SIZE (1..MAX)) OF Verifier OPTIONAL"? > > I think we should do this because it would reduce the encoding size in > what I believe will be the common case of no additional verifiers. That seems okay; we don't have any reason to expect an unbounded number of other verifiers. I'll let you pick the MAX, though. > Motivations text: > > I'm still looking over Ben's suggestions for the rewording of the > "Motivations" section. > > CAMMAC-BINDING: > > I think I'll cover this in a separate message. Okay. -Ben From jhutz@cmu.edu Mon Dec 9 10:17:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD4A1AE055 for ; Mon, 9 Dec 2013 10:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxfUXLKwpfV4 for ; Mon, 9 Dec 2013 10:17:35 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7A1AE041 for ; Mon, 9 Dec 2013 10:17:35 -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 rB9IHT5h012603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 13:17:29 -0500 (EST) Message-ID: <1386613049.9407.149.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Mon, 09 Dec 2013 13:17:29 -0500 In-Reply-To: <8939_1386355038_rB6IbHjk011550_alpine.GSO.1.10.1312061329390.27579@multics.mit.edu> References: <8939_1386355038_rB6IbHjk011550_alpine.GSO.1.10.1312061329390.27579@multics.mit.edu> 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.200 Cc: jhutz@cmu.edu Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:17:37 -0000 On Fri, 2013-12-06 at 13:37 -0500, Benjamin Kaduk wrote: > > Minor encoding change: > > > > Do we change "other-verifiers" from "[3] SEQUENCE OF Verifier" to > > "[3] SEQUENCE (SIZE (1..MAX)) OF Verifier OPTIONAL"? > > > > I think we should do this because it would reduce the encoding size in > > what I believe will be the common case of no additional verifiers. > > That seems okay; we don't have any reason to expect an unbounded number of > other verifiers. I'll let you pick the MAX, though. I'm pretty sure MAX here is to be taken literally, not as a placeholder. The change Tom proposes has no effect on the number of verifiers that can be encoded, or on the encoding when at least one verifier is present. However, it reduces the encoding size by something like 4 octets when no verifiers are present. -- Jeff From ghudson@mit.edu Wed Dec 11 13:13:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17061A1F5D for ; Wed, 11 Dec 2013 13:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcDoEMpL8eQn for ; Wed, 11 Dec 2013 13:13:13 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0501AD694 for ; Wed, 11 Dec 2013 13:13:13 -0800 (PST) X-AuditID: 1209190c-b7f7f6d000000bbd-f9-52a8d5636d4d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 16.7C.03005.365D8A25; Wed, 11 Dec 2013 16:13:07 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id rBBLD6nL007088 for ; Wed, 11 Dec 2013 16:13:07 -0500 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rBBLD5dN012021 for ; Wed, 11 Dec 2013 16:13:06 -0500 From: Greg Hudson To: kitten@ietf.org Date: Wed, 11 Dec 2013 16:12:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6nrpt8dUWQwY0bChZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxretC9gKZvJW3Ow6z9bAuIKri5GDQ0LARKJnt2YXIyeQKSZx 4d56ti5GLg4hgdlMEn1bjjBCOMcZJVafvcgC4XQwSXye+pANpIVNQFni4NlvLCC2iICwxO6t 75hBbGEBG4lvcx6AxVkEVCW2fekHi/MKGEqs72pig7AFJU7OfAJWwyygJXHj30umCYw8s5Ck ZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKXmlK6iREUHJySPDsY3xxUOsQo wMGoxMP74uCKICHWxLLiytxDjJIcTEqivFUXgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeHcc AcrxpiRWVqUW5cOkpDlYlMR5b3LYBwkJpCeWpGanphakFsFkZTg4lCR4Y68ANQoWpaanVqRl 5pQgpJk4OEGG8wANb74MMry4IDG3ODMdIn+KUVFKnPcdSEIAJJFRmgfXC4veV4ziQK8I87aC rOABRj5c9yugwUxAg28HLwcZXJKIkJJqYAzIzTJ9snjXwc9xC7MC90bb9EktjPs+QXbBC4vq hUtPF5/+vTfLRq21Lo4xabei9ITjz58/L7LJuffmnPQDhc0xumfCcq/Z3NY8MTOwNTY04sXh p/d79vf1L+bcbKgzaenR78V5M5uEav49475wfNrhNPlTwv4r4/ve1F++/TBNLefdJXW9lLVK LMUZiYZazEXFiQC2q/23uQIAAA== Subject: [kitten] krb5 gss_pseudo_random implementation/spec variance X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 21:13:17 -0000 RFC 4402 defines the output of gss_pseudo_random using a function named PRF+, defined as: PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn) Tn = pseudo-random(K, n || S) where '||' is the concatenation operator, 'n' is encoded as a network byte order 32-bit unsigned binary number, truncate(L, S) truncates the input octet string S to length L, and pseudo-random() is the Kerberos V pseudo-random function [RFC3961]. So the successive calls to RFC 3961 input should have input like: 00 00 00 01 00 00 00 02 . . . The MIT krb5 implementation (present since release 1.8 in early 2010) starts at 00 00 00 00 instead of 00 00 00 01. The Heimdal implementation (present since release 1.4 in late 2010) also starts at 00 00 00 00. Heimdal encoded the counter in little-endian, but this was changed to big-endian on master on 2013-10-30. Because both implementations start at zero, the difference in endianness doesn't cause a discrepancy in the first block of output. Shishi does not appear to have an implementation. I don't think Solaris does either. I'm not sure whether Microsoft has an implementation (they don't provide a GSSAPI implementation to my knowledge, but maybe there is an SSPI function which is supposed to be compatible?) or if Oracle has one in JGSS. Has anyone else run across this variance? If all implementations begin at 00 00 00 00, then this is similar to the KeyExchange vs. KEYEXCHANGE issue with RFC 6112: the constants involved are arbitrary and it would be more painful to change the implementations than the spec. From jhutz@cmu.edu Wed Dec 11 14:17:35 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2101AE0D6 for ; Wed, 11 Dec 2013 14:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRcGfuO9wa6W for ; Wed, 11 Dec 2013 14:17:33 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3B1ADDD2 for ; Wed, 11 Dec 2013 14:17:32 -0800 (PST) Received: from [128.237.252.124] ([128.237.252.124]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rBBMHPVK021074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 17:17:26 -0500 (EST) Message-ID: <1386800244.25257.10.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Wed, 11 Dec 2013 17:17:24 -0500 In-Reply-To: <3541_1386796395_rBBLDESk020467_x7d61qv852r.fsf@equal-rites.mit.edu> References: <3541_1386796395_rBBLDESk020467_x7d61qv852r.fsf@equal-rites.mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Cc: jhutz@cmu.edu Subject: Re: [kitten] krb5 gss_pseudo_random implementation/spec variance X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:17:35 -0000 On Wed, 2013-12-11 at 16:12 -0500, Greg Hudson wrote: > The MIT krb5 implementation (present since release 1.8 in early 2010) > starts at 00 00 00 00 instead of 00 00 00 01. > > The Heimdal implementation (present since release 1.4 in late 2010) also > starts at 00 00 00 00. Heimdal encoded the counter in little-endian, > but this was changed to big-endian on master on 2013-10-30. Because > both implementations start at zero, the difference in endianness > doesn't cause a discrepancy in the first block of output. ... and this is why things like this ought to have test vectors. Which, of course, only helps you if the test vectors weren't generated by running an incorrect implementation. -- Jeff From kaduk@mit.edu Wed Dec 11 16:14:39 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56DE1AE1BE for ; Wed, 11 Dec 2013 16:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl0kPmD58-lJ for ; Wed, 11 Dec 2013 16:14:38 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id EE9AE1AE1BB for ; Wed, 11 Dec 2013 16:14:37 -0800 (PST) X-AuditID: 1209190f-b7fb86d000000c36-c6-52a8ffe83fae Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 64.12.03126.8EFF8A25; Wed, 11 Dec 2013 19:14:32 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id rBC0EVf6013032; Wed, 11 Dec 2013 19:14:31 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rBC0ET2H004994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 19:14:30 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rBC0ES9G014362; Wed, 11 Dec 2013 19:14:28 -0500 (EST) Date: Wed, 11 Dec 2013 19:14:28 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrfvi/4ogg6457BZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuG/LUwFW5grLjWcZ2lgvMnUxcjJISFgItG1+iobhC0mceHe eiCbi0NIYDaTxO/LC9ghnI2MEsu3tkJlDjFJdH+4wgLhNDBK3NvYDzaLRUBb4vPiLWCz2ARU JGa+2QhmiwgoSvxe+ZYRxGYWEJZYf24GM4gtLOApcfTafbBeTgEjiUvzzrCD2LwCjhKPT38A qxESMJToP/8JLC4qoCOxev8UFogaQYmTM5+wQMy0lDj35zrbBEbBWUhSs5CkFjAyrWKUTcmt 0s1NzMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgOTEn+HYzfDiodYhTgYFTi4Z2wf0WQEGti WXFl7iFGSQ4mJVFetp9AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8O44A5XhTEiurUovyYVLS HCxK4rw3OeyDhATSE0tSs1NTC1KLYLIyHBxKErxb/wE1ChalpqdWpGXmlCCkmTg4QYbzAA0/ A1LDW1yQmFucmQ6RP8WoKCXO2wCSEABJZJTmwfXCEscrRnGgV4R5r4BU8QCTDlz3K6DBTECD bwcvBxlckoiQkmpgVF9WcDlnv9VeiZbFky7MmNL5ufXv3E1Spsd2XnnEqDT3evrF+5mcf6W2 vv2w1PBKpX2Ez4ofWvsTmNgVT/OsMUi/5aZx7ZrHp7e589P1bj1pK3ksVf5dLfeJUofBL4b2 6LdX2p9v/t6278V6zTYuvrVb3wnPd8nuZ3711pXde+nvBdqxm56c5lJiKc5INNRiLipOBADM ntjc9wIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] krb5 gss_pseudo_random implementation/spec variance X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 00:14:40 -0000 On Wed, 11 Dec 2013, Greg Hudson wrote: > Has anyone else run across this variance? If all implementations begin > at 00 00 00 00, then this is similar to the KeyExchange vs. KEYEXCHANGE > issue with RFC 6112: the constants involved are arbitrary and it would > be more painful to change the implementations than the spec. Meaning that we should submit an erratum and accordingly get told to re-issue the document? -Ben From nico@cryptonector.com Wed Dec 11 16:33:27 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9851AE11B for ; Wed, 11 Dec 2013 16:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQvCPMdbp394 for ; Wed, 11 Dec 2013 16:33:26 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE441AE106 for ; Wed, 11 Dec 2013 16:33:26 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 8E00D674058 for ; Wed, 11 Dec 2013 16:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=uvppsIckrFFj6x0PR9SI uDEwm9Q=; b=KtARezBKOAR1BMnVfTGs5j8ZvZMW3kIWsjuAy6ns0tTKkJonvRqc 9Obfut+Bo3SnZwAUSu9XuEJ1sVnUuviyzVe/SaV6nGvyihkIeH/jOmKVmUOsa87J Kw8CC6sN6MqaEz+hatu5nFMUFZBA/52tXTCaWwg20xFv/kI0Vfg5tb0= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 37481674057 for ; Wed, 11 Dec 2013 16:33:20 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so36915wib.5 for ; Wed, 11 Dec 2013 16:33:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9xYPZmZEMACVCMAH7mNXAl5nEsRojP4aL37V4F2TAl0=; b=Ez1H+8+pQtaRpoDgBZSsJ8W/ApQmd8mJEesL7nd52Gw5qk77EbNvcJJ94jcpbkMRG0 Uzf6UXo/AlZv5PqfXBez62OgiVEy0EFa6ixfiytizSAlT9CjJansrwLfReBpiKDf6lOi RSeGTW+d4JOitmD4l+LkWKwJlmyajmcdarwoVSXksty2whSXSbMiCzJa1iSr5SsGVsy+ VrDA14CZJ73UE4ZQfwFHnUz5uLcwOZGyUoeS0i7OFG2Dnp0936TcVDwmJpQFvSojbbUR VLbOWsGCD8BFKBqGZ/aP8iM0cWBzM/d1ybySPSX29+7GhEb0DzfKkaujzyJZMvmEXSTD 0F0w== MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr4052609wjt.64.1386808398105; Wed, 11 Dec 2013 16:33:18 -0800 (PST) Received: by 10.217.10.6 with HTTP; Wed, 11 Dec 2013 16:33:17 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Dec 2013 18:33:17 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] krb5 gss_pseudo_random implementation/spec variance X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 00:33:27 -0000 I think we should submit an I-D with a) the update to the original, b) test vectors. (b) is difficult because we have no standard way to get a security context with specific keys in it. We really should standardize something like the lucid context stuff specifically so that a) we could publish test vectors for the mechanism, b) re-use RFC4121 tokens in other non-Kerberos mechanisms. Nico -- From internet-drafts@ietf.org Sat Dec 14 22:33:08 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BB1AE13F; Sat, 14 Dec 2013 22:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX0rgGzFSGiK; Sat, 14 Dec 2013 22:33:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EC71AE12A; Sat, 14 Dec 2013 22:33:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131215063304.5124.30859.idtracker@ietfa.amsl.com> Date: Sat, 14 Dec 2013 22:33:04 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-12.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 06:33:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-12.txt Pages : 19 Date : 2013-12-14 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shawn.emery@oracle.com Sun Dec 15 22:13:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EA71AE2AE for ; Sun, 15 Dec 2013 22:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58lYUsd0wklq for ; Sun, 15 Dec 2013 22:13:55 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 44ECC1AE106 for ; Sun, 15 Dec 2013 22:13:55 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBG6Drah007707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Dec 2013 06:13:54 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBG6Dqak024089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Dec 2013 06:13:53 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBG6DqXs003385 for ; Mon, 16 Dec 2013 06:13:52 GMT Received: from [10.159.78.201] (/10.159.78.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Dec 2013 22:13:52 -0800 Message-ID: <52AE9A65.1010700@oracle.com> Date: Sun, 15 Dec 2013 23:15:01 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 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] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 06:13:58 -0000 This message officially starts the 2nd kitten Working Group Last Call for the following document: A set of SASL Mechanisms for OAuth http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-12 The Working Group Last Call for this document starts today on Sunday, December 15th and will end on Tuesday, December 31st. Please send any comments to the kitten mailing list or directly to the chairs. Even if you reviewed this document and found no issues then please provide this feed-back. Thank you, Shawn Emery kitten co-chair -- From mamille2@cisco.com Tue Dec 17 14:47:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D381ADBCA for ; Tue, 17 Dec 2013 14:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 283puVaCNYRM for ; Tue, 17 Dec 2013 14:46:58 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id B2B9D1AD75F for ; Tue, 17 Dec 2013 14:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4613; q=dns/txt; s=iport; t=1387320417; x=1388530017; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hPH3NA3JhLlzBnqBCPQ45Tf85k4NTKRMrKuR6goV2Lc=; b=csM+1g8xayrE3QAYadNgJdM/HsZhtxnmPVD7ZlWBO4jlVrGvCqAxvCbo jXGO43pT3YvR47bki3ujN5SMb2IOu7x2ghxOwuPPFTDKugIrn6DUj1XyO S7ip5XqhgRH2vMQOOMBihfT8iigicFV06VamMZmVY7EqxtaL6UbzyYrv6 I=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAL3TsFKtJXG+/2dsb2JhbABQCYMKOFWvNok1gR8WdIIlAQEBAwEdURsCAQhGMiUCBAESDoduCA3JRheON2KDI4ETAQOMW4NYgTGGMoEwhhCKVIMrgio X-IronPort-AV: E=Sophos;i="4.95,503,1384300800"; d="asc'?scan'208";a="7474839" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-3.cisco.com with ESMTP; 17 Dec 2013 22:46:57 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBHMkv4m020314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 22:46:57 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.22]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 17 Dec 2013 16:46:57 -0600 From: "Matt Miller (mamille2)" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 Thread-Index: AQHO+iYGh/HTVxoMc0+2BQxVCnN2eJpZZA6A Date: Tue, 17 Dec 2013 22:46:57 +0000 Message-ID: References: <52AE9A65.1010700@oracle.com> In-Reply-To: <52AE9A65.1010700@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.73] Content-Type: multipart/signed; boundary="Apple-Mail=_610D75FA-E396-4124-B7F8-9F28439DF436"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 22:47:00 -0000 --Apple-Mail=_610D75FA-E396-4124-B7F8-9F28439DF436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 15, 2013, at 11:15 PM, Shawn M Emery = wrote: >=20 > This message officially starts the 2nd kitten Working Group Last Call = for the following document: >=20 > A set of SASL Mechanisms for OAuth > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-12 >=20 > The Working Group Last Call for this document starts today on Sunday, = December 15th and will end on Tuesday, December 31st. >=20 > Please send any comments to the kitten mailing list or directly to the = chairs. Even if you reviewed this document and found no issues then = please provide this feed-back. >=20 Here are my current comments on this draft (more might come later): MAJOR: * Removing the GS2-header (which was done in revision -11) also removed = the ability for the client to specify an authorization identity. If the = lack of an authorization identity is acceptable (and I suspect it is not = for some), then the document needs to state these mechanisms do not = support authz-id. * In section 3.2.2. Server Response to Failed Authentication, returning = a space-separated list for the "scope" field is NOT RECOMMENDED, but = also says the lack of a "scope" (value or field) implies the client = SHOULD request tokens that are unscoped (empty list of scopes). = However, RFC 6749 =A7 3.3 does not permit unscoped tokens; the ABNF does = not allow for "scope=3D" (i.e., the empty list), and the text regarding = the lack of scope means the authorization server uses a default scope = value (or fails authorization outright). To me, this seems like a = contradiction that would lead to interoperability problems. MINOR: * In section 2. Terminology, it does not explicitly state that the = reader ought to be familiar with terminology from RFC 4422. This should = be added. * In section 3.2.2. Server Response to Failed Authentication, the last = paragraph still discusses channel binding. It should be removed. * All of the examples include a gs2-header, but this was removed from = the ABNF. The examples need to be updated to remove the header. * In section 8.1. Normative References, there is an entry for RFC 5056, = but this reference is no longer used in the document. It should be = removed. NITS: * HTTP is mentioned but no citation or definition is included. * XMPP is mentioned but no citation or definition is included. * In section 1. Introduction, SMTP is mentioned with a citation but = without a definition (unlike SASL and IMAP immediately preceding). * In section 3. OAuth SASL Mechanism Specifications, the two lists = describing success and failure flows are in fact ordered (numbered), but = the document presents them as unordered (symbols). * In section 3.2.2. Server Response to Failed Authentication, replace [[ = need registry name ]] with "OAuth Extensions Error Registry". * In section 4.2. Failed Exchange, the "status" value of "401" is not in = the OAuth Extensions Error Registry; "invalid_request" seems appropriate = here instead. * In section 4.3. SMTP Example of a Failed Negotiation, the (encoded) = server response uses a "status" value of "401", which is not in the = OAuth Extensions Error Registry; "invalid_token" seems appropriate here = instead. * In section 5. Security Considerations, he phrase "This document = specifies three SASL mechanisms should be "This document specifies two = SASL mechanisms". * In Appendix A. Acknowledgements, "area directors" should be "area = director". - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_610D75FA-E396-4124-B7F8-9F28439DF436 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSsNRgAAoJEDWi+S0W7cO1YQAIAKibsEK26U2cSNNIfLR5Zlvo aKqDWzdih9VJ170azETWwJJ1SWDVKuEVVlkAHddMYNpQBDbOBCfhsJKj6CCJXWNz e8/SLtes8yAKtVTC7PDwHZSKMAtPpMi4lk9ZdnZkcCpOwNdVnDlMorN8wxiBjUzn BSbtYGqrmTa3OJqsE18iVSHCP/JX1LbkZXcYOX25dF1RqffPkb6Yh0olQqKlLsLR V1H7xIqpoNgZaqrB42fQYZjbQj9rM/OR+vHnjVXGoqaGS44nxp9lnuE4429B4kWa Vqy5vunfNzJeHkDKfS68z5p8cQflOE4F34fOnyNp+ndGWPcKUOrSPZMMASvSXdU= =Mfmz -----END PGP SIGNATURE----- --Apple-Mail=_610D75FA-E396-4124-B7F8-9F28439DF436-- From wmills@yahoo-inc.com Tue Dec 17 17:25:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1881ADF80 for ; Tue, 17 Dec 2013 17:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-9oB4q56OU3 for ; Tue, 17 Dec 2013 17:25:06 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id E466B1ADFA4 for ; Tue, 17 Dec 2013 17:25:06 -0800 (PST) Received: from BF1-EX10-CAHT05.y.corp.yahoo.com (bf1-ex10-caht05.corp.bf1.yahoo.com [10.74.209.60]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBI1OYSf010868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 17:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1387329876; bh=05EsTYBPHRANhC2iFhH6XPepqhHhE3Q9m2xS3DaiD4w=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=xWitPYX3y0lbTaKR+sOGtTJch2fmi8yigKhdZ7cRCSshi3CI+mKQjhBYFEQvJVGzx bV8o5MWpTHeHtP8OKs02a+6NLbr8+jVbNesPAmYzihQC05VnOQce6Trp8yUgFQmurf JOT0ZDnGiqERanPXdqBBlzQzcHWpUoM19d+3Vk/g= Received: from omp1050.mail.ne1.yahoo.com (98.138.89.192) by BF1-EX10-CAHT05.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 17:25:12 -0800 Received: (qmail 22218 invoked by uid 1000); 18 Dec 2013 01:24:33 -0000 Received: (qmail 51764 invoked by uid 60001); 18 Dec 2013 01:24:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1387329873; bh=Z8k1RhZ3gARB6/z+FbqzEOEvr75FWoTnTh+rYrVD/Is=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=EVsamA5FUbBvfJysBvXNqg+qmSKP0pP6ED1mp040v7eWBRjfoiaz/24UPEXFaoAZ7dVYaRjMzrzBXI+Icvtdu4mEeR8XO6NJD89JRangVMQvUwMN0ayCxEHDkZDjiT/AZazUM517f3chSJke2+wQ7WFkEZjwv/+0ONPB/XBI2/I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AZ722gzbiW4CXsFb2LdC1wCQUyB7paiIaeJrielKnLhG+5U+k8UiqDLWQ4paQ7MvYrD3zEG539r2KShzFSZ8wdO3m0kx3VdbphmB75S0hDmIaQlLfvvDVtb9uuBQyc7PsRdMP1BxE7jtjPlWD//CCOrSwDePKPxwmThDiHNk6x8=; X-YMail-OSG: D4tHi4IVM1m6.pRCt3_0LwzdzkDkrna7J29UgYE_.YzDpp4 JVbZfjDL.jNVGMjPorynrDGONhBP_JL2a4qpw50qEvSGiIkx1_kWoSizKq_J 1KxwuepPXYNn06dLteJS8gYIeHyMxnnhXLF_rOruB0IxyHGf2YrsWJZp1Txt bLh_Zqx5EU8z_9lX98hnajc.prOKz43ajIeij.XZt9.CEAe1H5v4yl2pL_BZ 3R9zRSALnz8dqr6H2KlefKrHsrqeKt89vctyd6IzNC7h_Ic7E_BDS0BoCgJE GtNYM6izLxgTJbJBs5QNCx2US Received: from [209.131.62.113] by web125604.mail.ne1.yahoo.com via HTTP; Tue, 17 Dec 2013 17:24:33 PST X-Rocket-MIMEInfo: 002.001, SW5saW5lIGJlbG93LsKgIEkgbmVlZCB0byBmaXggdGhlIGV4YW1wbGVzIGFzIHlvdSBub3RlLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiBUdWVzZGF5LCBEZWNlbWJlciAxNywgMjAxMyAyOjQ3IFBNLCBNYXR0IE1pbGxlciAobWFtaWxsZTIpIDxtYW1pbGxlMkBjaXNjby5jb20.IHdyb3RlOgogCk9uIERlYyAxNSwgMjAxMywgYXQgMTE6MTUgUE0sIFNoYXduIE0gRW1lcnkgPHNoYXduLmVtZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.170.612 References: <52AE9A65.1010700@oracle.com> Message-ID: <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 17 Dec 2013 17:24:33 -0800 From: Bill Mills To: "Matt Miller (mamille2)" , Shawn M Emery , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-107077065-1387329873=:35383" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 329875000 Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 01:25:09 -0000 ---685807438-107077065-1387329873=:35383 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline below.=A0 I need to fix the examples as you note.=0A=0A=0A=A0=0A-bil= l=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoi= d" Yahoo!=0A=0A=0A=0A=0A=0AOn Tuesday, December 17, 2013 2:47 PM, Matt Mill= er (mamille2) wrote:=0A =0AOn Dec 15, 2013, at 11:15 P= M, Shawn M Emery wrote:=0A=0A> =0A> This message o= fficially starts the 2nd kitten Working Group Last Call for the following d= ocument:=0A> =0A> A set of SASL Mechanisms for OAuth=0A> http://tools.ietf.= org/html/draft-ietf-kitten-sasl-oauth-12=0A> =0A> The Working Group Last Ca= ll for this document starts today on Sunday, December 15th and will end on = Tuesday, December 31st.=0A> =0A> Please send any comments to the kitten mai= ling list or directly to the chairs.=A0 Even if you reviewed this document = and found no issues then please provide this feed-back.=0A> =0A=0AHere are = my current comments on this draft (more might come later):=0A=0AMAJOR:=0A= =0A* Removing the GS2-header (which was done in revision -11) also removed = the ability for the client to specify an authorization identity.=A0 If the = lack of an authorization identity is acceptable (and I suspect it is not fo= r some), then the document needs to state these mechanisms do not support a= uthz-id.=0A=0A[wmills] This is addressed in 3.2.1 of -12=A0 authz-id is pos= sible in some OAuth schemes.=0A=0A* In section 3.2.2. Server Response to Fa= iled Authentication, returning a space-separated list for the "scope" field= is NOT RECOMMENDED, but also says the lack of a "scope" (value or field) i= mplies the client SHOULD request tokens that are unscoped (empty list of sc= opes).=A0 However, RFC 6749 =A7 3.3 does not permit unscoped tokens; the AB= NF does not allow for "scope=3D" (i.e., the empty list), and the text regar= ding the lack of scope means the authorization server uses a default scope = value (or fails authorization outright).=A0 To me, this seems like a contra= diction that would lead to interoperability problems.=0A=0A[wmills] "scope"= is an optional parameter, so if you want an empty value you don't send sco= pe at all.=0A=0AMINOR:=0A=0A* In section 2. Terminology, it does not explic= itly state that the reader ought to be familiar with terminology from RFC 4= 422.=A0 This should be added.=0A=0A[wmills] OK=0A=0A* In section 3.2.2. Ser= ver Response to Failed Authentication, the last paragraph still discusses c= hannel binding.=A0 It should be removed.=0A=0A[wmills] OK=0A=0A* All of the= examples include a gs2-header, but this was removed from the ABNF.=A0 The = examples need to be updated to remove the header.=0A=0A=0A* In section 8.1.= Normative References, there is an entry for RFC 5056, but this reference i= s no longer used in the document.=A0 It should be removed.=0A=0A[wmills] OK= =0A=0ANITS:=0A=0A* HTTP is mentioned but no citation or definition is inclu= ded.=0A* XMPP is mentioned but no citation or definition is included.=0A=0A= [wmills] OK x2=0A=0A=0A* In section 1. Introduction, SMTP is mentioned with= a citation but without a definition (unlike SASL and IMAP immediately prec= eding).=0A=0A[wmills] I see "SMTP=A0[RFC5321]" there=0A=0A* In section 3. O= Auth SASL Mechanism Specifications, the two lists describing success and fa= ilure flows are in fact ordered (numbered), but the document presents them = as unordered (symbols).=0A=0A[wmills] OK=0A=0A* In section 3.2.2. Server Re= sponse to Failed Authentication, replace [[ need registry name ]] with "OAu= th Extensions Error Registry".=0A=0A[wmills] OK=0A=0A* In section 4.2. Fail= ed Exchange, the "status" value of "401" is not in the OAuth Extensions Err= or Registry; "invalid_request" seems appropriate here instead.=0A=0A* In se= ction 4.3. SMTP Example of a Failed Negotiation, the (encoded) server respo= nse uses a "status" value of "401", which is not in the OAuth Extensions Er= ror Registry; "invalid_token" seems appropriate here instead.=0A=0A[wmills]= Will fix the 2 above (as opposed to OK which indicates I already did the e= dit)=0A=0A* In section 5. Security Considerations, he phrase "This document= specifies three SASL mechanisms should be "This document specifies two SAS= L mechanisms".=0A=0A[wmills] OK=0A=0A* In Appendix A. Acknowledgements, "ar= ea directors" should be "area director".=0A=0A[wmills] OK=0A=0A=0A- m&m=0A= =0AMatt Miller < mamille2@cisco.com >=0ACisco Systems, Inc.=0A=0A=0A_______= ________________________________________=0AKitten mailing list=0AKitten@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten ---685807438-107077065-1387329873=:35383 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Inline be= low.  I need to fix the examples as you note.

 
-bill


----------------------------= ----
William J. Mills
"Paranoid" Yahoo!



<= font face=3D"Arial" size=3D"2"> On Tuesday, December 17, 2013 2:47 PM, Matt= Miller (mamille2) <mamille2@cisco.com> wrote:
On Dec 15, 2013, at 11:15 PM, Shawn M Emery <= shawn.emery@oracle.com> wrote:

>
> This message officiall= y starts the 2nd kitten Working Group Last Call for the following document:=
>
> A set of SASL Mechanisms fo= r OAuth
> http://tools.ie= tf.org/html/draft-ietf-kitten-sasl-oauth-12
>
> The Working Group Last Call for this document starts to= day on Sunday, December 15th and will end on Tuesday, December 31st.
>
> Please send any comments to the ki= tten mailing list or directly to the chairs.  Even if you reviewed thi= s document and found no issues then please provide this feed-back.
>

Here are my current comments on this draft (m= ore might come later):

MAJOR:

* Removing the GS2-header (which was done in r= evision -11) also removed the ability for the client to specify an authoriz= ation identity.  If the lack of an authorization identity is acceptabl= e (and I suspect it is not for some), then the document needs to state thes= e mechanisms do not support authz-id.

[wmills] This i= s addressed in 3.2.1 of -12  authz-id is possible in some OAuth scheme= s.

* In section 3.2.2. Server Response to Failed Auth= entication, returning a space-separated list for the "scope" field is NOT R= ECOMMENDED, but also says the lack of a "scope" (value or field) implies th= e client SHOULD request tokens that are unscoped (empty list of scopes).&nb= sp; However, RFC 6749 =A7 3.3 does not permit unscoped tokens; the ABNF does n= ot allow for "scope=3D" (i.e., the empty list), and the text regarding the = lack of scope means the authorization server uses a default scope value (or= fails authorization outright).  To me, this seems like a contradictio= n that would lead to interoperability problems.

[wmil= ls] "scope" is an optional parameter, so if you want an empty value you don= 't send scope at all.

MINOR:

* In section 2. Terminology, it does not expli= citly state that the reader ought to be familiar with terminology from RFC = 4422.  This should be added.

[wmills] OK

* In section 3.2.2. Server Response to Failed Authentication= , the last paragraph still discusses channel binding.  It should be re= moved.

[wmills] OK

* All of the= examples include a gs2-header, but this was removed from the ABNF.  The exampl= es need to be updated to remove the header.


* In section 8.1. Normative References, there is an entry for RFC= 5056, but this reference is no longer used in the document.  It shoul= d be removed.

[wmills] OK

NITS:

* HTTP is mentioned bu= t no citation or definition is included.
* XMPP is mentioned but no cita= tion or definition is included.

[wmills] OK x2


* In section 1. Introduction, SMTP is me= ntioned with a citation but without a definition (unlike SASL and IMAP imme= diately preceding).

[wmills] I see "SMTP [RFC5321]" there
* In section 3. OAuth SASL Mechanism Specifications, the tw= o lists describing success and failure flows are in fact ordered (numbered)= , but the document presents them as unordered (symbols).
=
[wmills] OK

* In section 3.2.2. Se= rver Response to Failed Authentication, replace [[ need registry name ]] wi= th "OAuth Extensions Error Registry".

[wmills] OK

* In section 4.2. Failed Exchange, the "status" value of "4= 01" is not in the OAuth Extensions Error Registry; "invalid_request" seems = appropriate here instead.

* In section= 4.3. SMTP Example of a Failed Negotiation, the (encoded) server response u= ses a "status" value of "401", which is not in the OAuth Extensions Error R= egistry; "invalid_token" seems appropriate here instead.
=
[wmills] Will fix the 2 above (as opposed to OK which indicates I alrea= dy did the edit)

* In section 5. Secur= ity Considerations, he phrase "This document specifies three SASL mechanism= s should be "This document specifies two SASL mechanisms".

[wmills] OK

* In Appendix A. Ack= nowledgements, "area directors" should be "area director".

[wmills] OK


- m&m


Matt Miller < mamille2@cisco.com >Cisco Systems, Inc.


_______________________________________________
= Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten<= br clear=3D"none">



---685807438-107077065-1387329873=:35383-- From wmills@yahoo-inc.com Tue Dec 17 18:12:17 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E8F1AE203 for ; Tue, 17 Dec 2013 18:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HlUjxt2ahwS for ; Tue, 17 Dec 2013 18:12:15 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 55E891AE1F1 for ; Tue, 17 Dec 2013 18:12:15 -0800 (PST) Received: from GQ1-EX10-CAHT17.y.corp.yahoo.com (gq1-ex10-caht17.corp.gq1.yahoo.com [10.73.119.198]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBI2Bsco077828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 18:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1387332715; bh=ZuCy/eKTE21UV+OVTLs2C9LIKBt+kEmd+5kVAYjXf88=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=f90EM0d7cqEH4hXgmt8bDDqIWBAUSjmU0xbG+efqD4I/HU1Sd2fWmWwFf55I0iBlV kWCbpz/VIyy8g3V9l4CkeFesmYqqZ00ft4Gu0q3CArpqyOOa940Pcs8ahwtPMuXken E5XNt12s5WjYRZKQRt7IPZAI2uUOjBpFuyuZC0gc= Received: from omp1087.mail.ne1.yahoo.com (98.138.101.176) by GQ1-EX10-CAHT17.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 18:11:53 -0800 Received: (qmail 16188 invoked by uid 1000); 18 Dec 2013 02:11:52 -0000 Received: (qmail 27271 invoked by uid 60001); 18 Dec 2013 02:11:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1387332711; bh=Yd7a4d4eDkBUuDRmAqVdCHdax1ZfatE1m6n9Qgwrjys=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jAEEWDGieSlRwDbSv3K77rI7go9NUJZIiY3UQpvVkkTQOMEUhl+mGDIZVJic+bBmkufetyAUicyC9fEBTSnAYyS1yqRbDBuTu7sXsVIoNRllFOfNTUFg/fSxj/28EozYKpEy9kWgi3XgOJlR0rNq+ucb7cGeJoXapbWpsYGRNZU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hmgv4oTBRCVefM9k5H+9ihevsHdxppP4tThQcY27sdRd5+6NLMYvDsVLUcoPebKVQ0cyVjKg18N1oef2iD8ANnW+IJgWLnR2MOX3X+LCO1rdRdSzZ/VTHn64oZ8oorOh4wlTNvvs46gtdoTYSYLI3kh349Agun3c2+tQHfMAi1c=; X-YMail-OSG: uPP3DzQVM1lT9Z6SqhfES0ElhNrpwYzApr_gtZLwMtEwqrD fhm9nogZ6ytcTnfbSa3VU9V2_YZZBkcGAz5s6bnZCPHYg.IbeBEdfPsWYI8z 2w.W8uS54FOMPtTb8xh59bT0Ml5B4RUcKWZczse7s4_MKlPhYlNXDbTWtO68 54JjEblzI_DhLfYh7GLf5HwvUzzqmYa1zsgQZk7MwzrU.DHewS7BYR5vMXQl huQO8f4VF36oEGrK.eHThvinasqvn8kysnCgdOnEkfyTM0Wny5vpHtdcMdTj 7Ec7bnVVMd3309Epvj1Lxaq3. Received: from [209.131.62.113] by web125606.mail.ne1.yahoo.com via HTTP; Tue, 17 Dec 2013 18:11:51 PST X-Rocket-MIMEInfo: 002.001, TWF0dCdzIGVkaXRzIGFyZSBpbmNsdWRlZCBpbiBteSB3b3JraW5nIGNvcHkgYW5kIHZpZXdhYmxlL2NvbW1lbnRhYmxlIGF0IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEI5OVlTa3hTNlplZmRHMWZTRkZJZVd4dE5VRS9lZGl0P3VzcD1zaGFyaW5nIHRob3VnaCBJIGRvbid0IGhhdmUgdGhlIGZhbmN5IGRpZmYgdmVyc2lvbi4KCgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgWWFob28hCgoKCgoKT24gVHVlc2QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.170.612 References: <52AE9A65.1010700@oracle.com> <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> Message-ID: <1387332711.90725.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Tue, 17 Dec 2013 18:11:51 -0800 From: Bill Mills To: Bill Mills , "Matt Miller (mamille2)" , Shawn M Emery , "kitten@ietf.org" In-Reply-To: <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607277540-2050968581-1387332711=:90725" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 332715001 Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 02:12:17 -0000 --607277540-2050968581-1387332711=:90725 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt's edits are included in my working copy and viewable/commentable at ht= tps://drive.google.com/file/d/0B99YSkxS6ZefdG1fSFFIeWxtNUE/edit?usp=3Dshari= ng though I don't have the fancy diff version.=0A=0A=0A=A0=0A-bill=0A=0A=0A= =0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!= =0A=0A=0A=0A=0A=0AOn Tuesday, December 17, 2013 5:25 PM, Bill Mills wrote:=0A =0AInline below.=A0 I need to fix the examples as= you note.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------= =0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Tuesday, Decemb= er 17, 2013 2:47 PM, Matt Miller (mamille2) wrote:=0A = =0AOn Dec 15, 2013, at 11:15 PM, Shawn M Emery wro= te:=0A=0A> =0A> This message officially starts the 2nd kitten Working Group= Last Call for the following document:=0A> =0A> A set of SASL Mechanisms fo= r OAuth=0A> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-12=0A> = =0A> The Working Group Last Call for this document starts today on Sunday, = December 15th and will end on Tuesday, December 31st.=0A> =0A> Please send = any comments to the kitten mailing list or directly to the chairs.=A0 Even = if you reviewed this document and found no=0A issues then please provide th= is feed-back.=0A> =0A=0AHere are my current comments on this draft (more mi= ght come later):=0A=0AMAJOR:=0A=0A* Removing the GS2-header (which was done= in revision -11) also removed the ability for the client to specify an aut= horization identity.=A0 If the lack of an authorization identity is accepta= ble (and I suspect it is not for some), then the document needs to state th= ese mechanisms do not support authz-id.=0A=0A[wmills] This is addressed in = 3.2.1 of -12=A0 authz-id is possible in some OAuth schemes.=0A=0A* In secti= on 3.2.2. Server Response to Failed Authentication, returning a space-separ= ated list for the "scope" field is NOT RECOMMENDED, but also says the lack = of a "scope" (value or field) implies the client SHOULD request tokens that= are unscoped (empty list of scopes).=A0=0A However, RFC 6749 =A7 3.3 does = not permit unscoped tokens; the ABNF does not allow for "scope=3D" (i.e., t= he empty list), and the text regarding the lack of scope means the authoriz= ation server uses a default scope value (or fails authorization outright).= =A0 To me, this seems like a contradiction that would lead to interoperabil= ity problems.=0A=0A[wmills] "scope" is an optional parameter, so if you wan= t an empty value you don't send scope at all.=0A=0AMINOR:=0A=0A* In section= 2. Terminology, it does not explicitly state that the reader ought to be f= amiliar with terminology from RFC 4422.=A0 This should be added.=0A=0A[wmil= ls] OK=0A=0A* In section 3.2.2. Server Response to Failed Authentication, t= he last paragraph still discusses channel binding.=A0 It should be removed.= =0A=0A[wmills] OK=0A=0A* All of the examples=0A include a gs2-header, but t= his was removed from the ABNF.=A0 The examples need to be updated to remove= the header.=0A=0A=0A* In section 8.1. Normative References, there is an en= try for RFC 5056, but this reference is no longer used in the document.=A0 = It should be removed.=0A=0A[wmills] OK=0A=0ANITS:=0A=0A* HTTP is mentioned = but no citation or definition is included.=0A* XMPP is mentioned but no cit= ation or definition is included.=0A=0A[wmills] OK x2=0A=0A=0A* In section 1= . Introduction, SMTP is mentioned with a citation but without a definition = (unlike SASL and IMAP immediately preceding).=0A=0A[wmills] I see "SMTP=A0[= RFC5321]" there=0A=0A* In section 3. OAuth SASL Mechanism Specifications, t= he two lists describing success and failure flows are in fact ordered (numb= ered), but the document presents them as unordered (symbols).=0A=0A[wmills]= OK=0A=0A* In section 3.2.2. Server Response to Failed Authentication, repl= ace [[ need registry name ]] with "OAuth Extensions Error Registry".=0A=0A[= wmills] OK=0A=0A* In section 4.2. Failed Exchange, the "status" value of "4= 01" is not in the OAuth Extensions Error Registry; "invalid_request" seems = appropriate here instead.=0A=0A* In section 4.3. SMTP Example of a Failed N= egotiation, the (encoded) server response uses a "status" value of "401", w= hich is not in the OAuth Extensions Error Registry; "invalid_token" seems a= ppropriate here instead.=0A=0A[wmills] Will fix the 2 above (as opposed to = OK which indicates I already did the edit)=0A=0A* In section 5. Security Co= nsiderations, he phrase "This document specifies three SASL mechanisms shou= ld be "This document specifies two SASL mechanisms".=0A=0A[wmills] OK=0A=0A= * In Appendix A. Acknowledgements, "area directors" should be "area directo= r".=0A=0A[wmills] OK=0A=0A=0A=0A- m&m=0A=0A=0AMatt Miller < mamille2@cisco.= com >=0ACisco Systems, Inc.=0A=0A=0A_______________________________________= ________=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/kitten=0A=0A=0A=0A=0A=0A_____________________________________= __________=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/kitten --607277540-2050968581-1387332711=:90725 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Matt's ed= its are included in my working copy and viewable/commentable at https://drive.google.com/file/d/0B99YSkxS6ZefdG1fSFFIeWxtNUE/edit?usp= =3Dsharing though I don't have the fancy diff version.
 
-bill


--------------------= ------------
William J. Mills
"Paranoid" Yahoo!



On Tuesday, December 17, 2013 5:25 PM, Bill M= ills <wmills@yahoo-inc.com> wrote:
Inline below.  I need to fix the examples as= you note.

 
-bill


--------------------------------
William J. Mills<= br clear=3D"none">"Paranoid" Yahoo!



On Tuesday, Decem= ber 17, 2013 2:47 PM, Matt Miller (mamille2) <mamille2@cisco.com> wro= te:
On Dec 15, 2013, at 11:15 PM, Shawn M Emery <shawn.emery@oracle.com> wrot= e:

>
> This m= essage officially starts the 2nd kitten Working Group Last Call for the fol= lowing document:
>
> A set of SA= SL Mechanisms for OAuth
> http:/= /tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-12
= >
> The Working Group Last Call for this document = starts today on Sunday, December 15th and will end on Tuesday, December 31s= t.
>
> Please send any comments = to the kitten mailing list or directly to the chairs.  Even if you rev= iewed this document and found no=0A issues then please provide this feed-ba= ck.
>

Here are m= y current comments on this draft (more might come later):

MAJOR:

* Removing = the GS2-header (which was done in revision -11) also removed the ability fo= r the client to specify an authorization identity.  If the lack of an = authorization identity is acceptable (and I suspect it is not for some), th= en the document needs to state these mechanisms do not support authz-id.
[wmills] This is addressed in 3.2.1 of -= 12  authz-id is possible in some OAuth schemes.

* In section 3.2.2. Server Response to Failed Authentication= , returning a space-separated list for the "scope" field is NOT RECOMMENDED= , but also says the lack of a "scope" (value or field) implies the client S= HOULD request tokens that are unscoped (empty list of scopes). =0A However, RFC 6749 =A7 3.3 does not permit unscoped to= kens; the ABNF does not allow for "scope=3D" (i.e., the empty list), and th= e text regarding the lack of scope means the authorization server uses a de= fault scope value (or fails authorization outright).  To me, this seem= s like a contradiction that would lead to interoperability problems.

[wmills] "scope" is an optional parameter, s= o if you want an empty value you don't send scope at all.

MINOR:

* In sectio= n 2. Terminology, it does not explicitly state that the reader ought to be = familiar with terminology from RFC 4422.  This should be added.

[wmills] OK

* In section 3.2.2. Server Response to Failed Authentication, the last= paragraph still discusses channel binding.  It should be removed.

[wmills] OK

* All of t= he examples=0A include a gs2-header, but this was removed from the ABNF.&nb= sp; The examples need to be updated to remove the header.


* In section 8.1. Normative Referenc= es, there is an entry for RFC 5056, but this reference is no longer used in= the document.  It should be removed.

[wmills] OK

NITS:

* HTTP is mentioned but no citation or definition is = included.
* XMPP is mentioned but no citation or definiti= on is included.

[wmills] OK x2


* In section 1. Introducti= on, SMTP is mentioned with a citation but without a definition (unlike SASL= and IMAP immediately preceding).

[wmi= lls] I see "SMTP [RFC5321]" there

* In section 3. OAuth SASL Mechanism Specifications, the two li= sts describing success and failure flows are in fact ordered (numbered), bu= t the document presents them as unordered (symbols).

[wmills] OK

* In sectio= n 3.2.2. Server Response to Failed Authentication, replace [[ need registry name ]] with "OAuth Extens= ions Error Registry".

[wmills] OK

* In section 4.2. Failed Exchange, the "st= atus" value of "401" is not in the OAuth Extensions Error Registry; "invali= d_request" seems appropriate here instead.

* In section 4.3. SMTP Example of a Failed Negotiation, the (encoded) = server response uses a "status" value of "401", which is not in the OAuth E= xtensions Error Registry; "invalid_token" seems appropriate here instead.
[wmills] Will fix the 2 above (as oppos= ed to OK which indicates I already did the edit)

* In section 5. Security Considerations, he phrase "This documen= t specifies three SASL mechanisms should be "This document specifies two SA= SL mechanisms".

[wmills] OK

* In Appendix A. Acknowledgements, "area directors" should = be "area director".

[wmills] OK



- m&m


Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


_________________________________________= ______
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
<= /div>



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


--607277540-2050968581-1387332711=:90725-- From mamille2@cisco.com Wed Dec 18 08:25:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226AB1AE411 for ; Wed, 18 Dec 2013 08:25:09 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snVQuQ_q6cau for ; Wed, 18 Dec 2013 08:25:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2B1AE339 for ; Wed, 18 Dec 2013 08:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8391; q=dns/txt; s=iport; t=1387383905; x=1388593505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SwOSrnG5XUcsXaam/R8rsccTpL95jIBdpcqSRP3KFZ4=; b=CJggIborpJHhEKLFd3SZ74+4Loyt3xeUjxLo7OqXD/qp+gxPLr18QCOE eO4pfCDWqaNiOO61N2IAFK3hpiKyCKPEcFEtMCF+LTc9NTV09YAc5rGic 2olr+09W5CKO3f0+6hgw1u1s4ZYS8P64/ty3uwshF0a8rItxltMT+LCBc o=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAHjLsVKtJV2b/2dsb2JhbABQCYMKOFW4YYEbFnSCJQEBAQMBeQULAgEIDh8ZMiUCBA4FDoduCMoTF443WwcKgxmBEwEDkDOBMYYykhSDK4FqJBw X-IronPort-AV: E=Sophos;i="4.95,508,1384300800"; d="asc'?scan'208";a="292420590" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 18 Dec 2013 16:25:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBIGP4sq026649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 16:25:04 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.22]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 10:25:04 -0600 From: "Matt Miller (mamille2)" To: Bill Mills Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 Thread-Index: AQHO+iYGh/HTVxoMc0+2BQxVCnN2eJpZZA6AgAAsCoCAAPuZgA== Date: Wed, 18 Dec 2013 16:25:03 +0000 Message-ID: <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com> References: <52AE9A65.1010700@oracle.com> <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> In-Reply-To: <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.238] Content-Type: multipart/signed; boundary="Apple-Mail=_8823340F-62A1-4DFB-A6E3-33F3B1359223"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 16:25:09 -0000 --Apple-Mail=_8823340F-62A1-4DFB-A6E3-33F3B1359223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks for the rapid turnover! One additional item I just noticed: the reference to = [I-D.draft-ietf-oauth-v2-http-mac] is out of date. It should be = draft-ietf-oauth-v2-http-mac-04, not -01. More inline, stripping all but what I'm responding to: On Dec 17, 2013, at 6:24 PM, Bill Mills wrote: > MAJOR: >=20 > * Removing the GS2-header (which was done in revision -11) also = removed the ability for the client to specify an authorization identity. = If the lack of an authorization identity is acceptable (and I suspect = it is not for some), then the document needs to state these mechanisms = do not support authz-id. >=20 > [wmills] This is addressed in 3.2.1 of -12 authz-id is possible in = some OAuth schemes. >=20 Section 3.2.1. talks about authentication identities (authn-id), not = authorization identities (authz-id). The two are different: authn-id is = who holds the credentials (such as they are in OAuth) and authz-id is = whom the authn-id is acting as. The more I read that section, the less convinced I am that it meets the = requirements for SASL mechanisms (RFC 4422 =A7 5). Identities (at least = authn-id, and often authzid) are provided for all other SASL mechanisms, = and all of the SASL-using protocols I'm familiar with rely on an = identity coming out of the SASL exchange. I understand that the access token itself is not guaranteed to contain = this information, but at some level the resource server needs to be able = to associate the SASL authentication credentials (OAuth access token) = with an authentication and/or authorization identity. =46rom what I've = seen of existing OAuth software, there is some way to determine an = identity -- if not encoded directly in the access token, then by = agreement between the resource server and the authorization server = (e.g., REST APIs specific to the authorization server). I suppose one possible transposition is for the authn-id to be the OAuth = client identity and the authz-id to be the OAuth resource owner = identity. I personally don't find this mapping interesting or = appropriate, and doesn't account for the resource owner acting as a = different identity within the context of the SASL-using application. A possible starting point for text (not sure where in 3.2.1. to place = it): """" The authentication identity is determined by the resource server using = information associated with the access token. This information might be = encoded within the access token itself, or the resource server might = obtain the information from the authorization server through other = means. The specific method is outside the scope of this work. """" This still doesn't account for the authorization identity. This could be = handled by adding a new kvpair (e.g., "authzid") and maybe some language = about how the resource server might validate/verify its use against the = provided credentials. Or, I'm just tilting at windmills. > * In section 3.2.2. Server Response to Failed Authentication, = returning a space-separated list for the "scope" field is NOT = RECOMMENDED, but also says the lack of a "scope" (value or field) = implies the client SHOULD request tokens that are unscoped (empty list = of scopes). However, RFC 6749 =A7 3.3 does not permit unscoped tokens; = the ABNF does not allow for "scope=3D" (i.e., the empty list), and the = text regarding the lack of scope means the authorization server uses a = default scope value (or fails authorization outright). To me, this = seems like a contradiction that would lead to interoperability problems. >=20 > [wmills] "scope" is an optional parameter, so if you want an empty = value you don't send scope at all. >=20 My apologies for not being clear. As I read the document, there are two ways I can see how to interpret = the term "unscoped": 1. scope of "" during the authorization request 2. omit the scope from the authorization request The first is clearly in violation of RFC 6749 (the ABNF requires at = least one scope-token, and the scope-token requires at least one = printable non-whitespace ACII character). The second, however, seems to = invite failure because the authorization server MUST either use the = default scope (if it has one) or fail authorization. According to this document, the resource server providing a scope of = something other than "" is NOT RECOMMENDED. That means (as I interpret = from RFC 2119) that "I can try to return a non-empty scope, but it will = likely cause problems in most cases". This document states that clients that receive an error response with an = empty scope (or no scope at all) SHOULD omit the scope from the = authorization request (since, again, specifying a scope of "" violates = RFC 6749). SHOULD means (as I interpret from RFC 2119) that "I can try = to specify a scope anyway, but it will likely cause problems in most = cases". I am then balancing all this against what I've experienced with already = deployed OAuth frameworks: not specifying a scope results in a failure = from the authorization server. Many -- if not most -- OAuth client = libraries won't send an authorization request with a scope specified. This is the interoperability problem I see in this document. It seems = (to me) that it is destined to cause confusion and at best, and = non-functioning (if following the SHOULDs and NOT RECOMMENDEDs) or = non-compliant (ignoring the SHOULDs and NOT RECOMMENDEDs) code at worst. I think this could be fixed by either removing the NOT RECOMMENDED about = presenting a space-separated list for scope, or by changing the SHOULD = to a MAY regarding what the client sends for the authorization request. = I think it would also help to define what unscoped means, or not use the = term at all. Suggested starting point for text (replacing all of section 3.2.2): """" For a failed authentication the server returns a JSON [RFC4627] = formatted error result, and fails the authentication. The error result = consists of the following values: status (REQUIRED): The authorization error code. Valid error codes are defined in = the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core = specification.=20 scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be = empty or a space separated list. Use of a space separated list is NOT = RECOMMENDED.=20 If the resource server provides a scope value that is not the empty = string then the client MUST always request scoped tokens from the token = endpoint. If the resource server provides no scope to the client then = the client MAY omit the scope from the authorization request. """" > * In section 1. Introduction, SMTP is mentioned with a citation but = without a definition (unlike SASL and IMAP immediately preceding). >=20 > [wmills] I see "SMTP [RFC5321]" there >=20 What I see: * Simple Authentication and Security Layer (SASL) [RFC4422] * Internet Message Access Protocol (IMAP) [RFC3501] * SMTP [RFC5321] One of these things is not like the others (-: This is very clearly a nit. The lack of consistency erks me somewhat, = but I doubt it truly matters. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_8823340F-62A1-4DFB-A6E3-33F3B1359223 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSscxfAAoJEDWi+S0W7cO19QoH/RD0gX1EqRLvc8o7XL82P0hU wOrsPFkLEZ9eytt0+vavPUaG9kpAq5GKga7PXLhiqRAm9D4Le4UaDudDmsQuU6D1 5EOL4E7/4MA7Oz4wtYFZihOVFwrf9PjOJNxu80SUmgM842M4heIxJGZP+uS+Vxce zLYJKNVZa1tQJFWbxkaND1izXQuaMRU0xhSHioMn0A12Ve3VlMZZK1zkVv8cBuPU mFVk99P8GDCNqQ30lUhQObKp2PGilRJ89LX1PX2yeqfehSxh91iOAuasYosL4Tn+ +IxZvZxhb0tHn3NU6mx1QAprglyAHf4C+OWItU2RrEfB4DbaEeyxNtVKAZa8SQo= =qKtv -----END PGP SIGNATURE----- --Apple-Mail=_8823340F-62A1-4DFB-A6E3-33F3B1359223-- From wmills@yahoo-inc.com Wed Dec 18 10:25:56 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936B41AE052 for ; Wed, 18 Dec 2013 10:25:56 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -16.919 X-Spam-Level: X-Spam-Status: No, score=-16.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZV49kJMgSXm for ; Wed, 18 Dec 2013 10:25:51 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id DAD071AE03B for ; Wed, 18 Dec 2013 10:25:51 -0800 (PST) Received: from BF1-EX10-CAHT14.y.corp.yahoo.com (bf1-ex10-caht14.corp.bf1.yahoo.com [10.74.226.58]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBIIORGh082895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Dec 2013 10:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1387391068; bh=wcpmjtRYQQueM4jum4S2k0Zy9jQMDEWw629GGED4ZJ8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=Gj5NWCMtYipU54VLTSoBeWLNrNYoZsvbdF0gmn0TVIlAYbu9JOEQycizoza9wVGWF STClC6vPL4mqQPNx8luzvStTiAY5I9eqCTXzZerVdF4f0H4PKIJybh9D7f6eHNQ8+m QxYs85SOGZqDL2GjZhKNAnucwifpfgc1z3SyHmNg= Received: from omp1019.mail.ne1.yahoo.com (98.138.89.163) by BF1-EX10-CAHT14.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 13:25:10 -0500 Received: (qmail 57853 invoked by uid 1000); 18 Dec 2013 18:24:25 -0000 Received: (qmail 48854 invoked by uid 60001); 18 Dec 2013 18:24:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1387391065; bh=xhMN6y/BPBlZA/QP/PCoh2tJEBsiLpdZCOHziUZ/RAU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lZExJ/2tZqLxVkRC9wC5uBOirg4X2Z0LDWWsfhLLn6PfwxqUkLLnFlZa04rA3ebfxBYPZqCiXHLTIgpb0V/i3MxJH3FxIijywLShwqpsSkMzsU4OIrRNlJmmV5wSIkCgw+s/3sFtXa+JgPUKARMm5pOumqg32oRz/OthCLGKMos= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Pt7L4gyzY6idlZ6J98DFvF+EHoXwhX4OSnRwOSE7oj67kRgBa7tKkudcllRHcpZS/gtOQ7GcHkKenzBWlJsRCipo8F4mF/2CclNDAaj9WCHOzyvxJVGCmk+KJq046JBiVuT/06yCc8wkzFvytNYj867ShSC5qLQGD7GsutMq9lw=; X-YMail-OSG: no_2p8QVM1kp4qNDwI9GUDIcPrvBS.DdmPjQ_.yaNbnjlfK FjIcU_LCzSS6kenM6HKehnmd8MuP41iGlownFMcHABQfLYQXjUip6qKcvoVa ZosEvtH2WgbGcBVHr5PjsYRrdlDsCPYBZXBkUZGu9NA4WEQ1T8Es6LQCcIPd MCBXVXbZNVzch28qO4d14iupbnxp8wCobldzml39tVYpYUv6qwS2678iTmO7 _82aqvj8UpmXy65gM9MfOGKyVrQgOJjap5volFUapwHRChFNlB3wxoirXXJK .e5ZtFShgUaEeyLqess7ilcUFrKANCLeIsCk- Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Wed, 18 Dec 2013 10:24:25 PST X-Rocket-MIMEInfo: 002.001, CldlIHdlbnQgYXJvdW5kIGEgbnVtYmVyIG9mIHRpbWVzIG9uIHRoZSBTQVNMIGlkZW50aXRpZXMuwqAgVGhlIHByb2JsZW0gSSBzZWUgaXMgdGhhdCB0aGUgYXNzZXJ0aW9uIG9mIGF1dGh6LWlkIGlmIGl0J3Mgc3BlY2lmaWVkIHNlcGFyYXRlbHkgaW4gcHJvdG9jb2wganVzdCBoYXMgdG8gYmUgbWF0Y2hlZC9jb25maXJtZWQgYnkgdGhlIHRva2VuIGFueXdheSBzbyB0aGUgdmFsdWUgc2hvdWxkIGp1c3QgYmUgZGVyaXZlZCBmcm9tIHRoYXQuCgoKTm90IHN1cmUgd2h5IHRoZSBNQUMgdG9rZW4gZHJhZnQgbnUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.170.612 References: <52AE9A65.1010700@oracle.com> <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com> Message-ID: <1387391065.73288.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Wed, 18 Dec 2013 10:24:25 -0800 From: Bill Mills To: "Matt Miller (mamille2)" In-Reply-To: <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-1467257001-1387391065=:73288" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 391068000 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 18:25:56 -0000 ---1981468715-1467257001-1387391065=:73288 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0AWe went around a number of times on the SASL identities.=A0 The problem = I see is that the assertion of authz-id if it's specified separately in pro= tocol just has to be matched/confirmed by the token anyway so the value sho= uld just be derived from that.=0A=0A=0ANot sure why the MAC token draft num= ber is wrong.=A0 I'm using the xml2rfc format and referring to so I'm not sure what to fix.=0A=0AOn scopes, I'm not liki= ng your changes but see the problem.=A0 The current text is:=0A=0A"An OAuth= scope which is valid to access the service. This may be empty which implie= s that unscoped tokens are required, or a space separated list. Use of a sp= ace separated list is NOT RECOMMENDED."=0A=0AI propose:=0A=0A"An OAuth scop= e which is valid to access the service. This may be empty which implies tha= t unscoped tokens are required, or a scope value.=A0 If a scope is specifie= d then a single scope is preferred, use of a space separated list of scopes= is NOT RECOMMENDED."=0A=A0=0A-bill=0A=0AP.S. Nits...=A0 "erk" is actually = a sound made when you drop something on your foot, "irk" is indicative of t= he reaction to excessive pedantry. :)=0A=0A=0A-----------------------------= ---=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Wednesday, D= ecember 18, 2013 8:25 AM, Matt Miller (mamille2) wrote= :=0A =0AThanks for the rapid turnover!=0A=0AOne additional item I just noti= ced: the reference to [I-D.draft-ietf-oauth-v2-http-mac] is out of date. It= should be draft-ietf-oauth-v2-http-mac-04, not -01.=0A=0AMore inline, stri= pping all but what I'm responding to:=0A=0AOn Dec 17, 2013, at 6:24 PM, Bil= l Mills wrote:=0A=0A> MAJOR:=0A> =0A> * Removing the= GS2-header (which was done in revision -11) also removed the ability for t= he client to specify an authorization identity.=A0 If the lack of an author= ization identity is acceptable (and I suspect it is not for some), then the= document needs to state these mechanisms do not support authz-id.=0A> =0A>= [wmills] This is addressed in 3.2.1 of -12=A0 authz-id is possible in some= OAuth schemes.=0A> =0A=0ASection 3.2.1. talks about authentication identit= ies (authn-id), not authorization identities (authz-id).=A0 The two are dif= ferent: authn-id is who holds the credentials (such as they are in OAuth) a= nd authz-id is whom the authn-id is acting as.=0A=0AThe more I read that se= ction, the less convinced I am that it meets the requirements for SASL mech= anisms (RFC 4422 =A7 5).=A0 Identities (at least authn-id, and often authzi= d) are provided for all other SASL mechanisms, and all of the SASL-using pr= otocols I'm familiar with rely on an identity coming out of the SASL exchan= ge.=0A=0AI understand that the access token itself is not guaranteed to con= tain this information, but at some level the resource server needs to be ab= le to associate the SASL authentication credentials (OAuth access token) wi= th an authentication and/or authorization identity.=A0 From what I've seen = of existing OAuth software, there is some way to determine an identity -- i= f not encoded directly in the access token, then by agreement between the r= esource server and the authorization server (e.g., REST APIs specific to th= e authorization server).=0A=0AI suppose one possible transposition is for t= he authn-id to be the OAuth client identity and the authz-id to be the OAut= h resource owner identity.=A0 I personally don't find this mapping interest= ing or appropriate, and doesn't account for the resource owner acting as a = different identity within the context of the SASL-using application.=0A=0AA= possible starting point for text (not sure where in 3.2.1. to place it):= =0A=0A""""=0AThe authentication identity is determined by the resource serv= er using information associated with the access token. This information mig= ht be encoded within the access token itself, or the resource server might = obtain the information from the authorization server through other means. T= he specific method is outside the scope of this work.=0A""""=0A=0AThis stil= l doesn't account for the authorization identity. This could be handled by = adding a new kvpair (e.g., "authzid") and maybe some language about how the= resource server might validate/verify its use against the provided credent= ials.=0A=0AOr, I'm just tilting at windmills.=0A=0A> * In section 3.2.2. Se= rver Response to Failed Authentication, returning a space-separated list fo= r the "scope" field is NOT RECOMMENDED, but also says the lack of a "scope"= (value or field) implies the client SHOULD request tokens that are unscope= d (empty list of scopes).=A0 However, RFC 6749 =A7 3.3 does not permit unsc= oped tokens; the ABNF does not allow for "scope=3D" (i.e., the empty list),= and the text regarding the lack of scope means the authorization server us= es a default scope value (or fails authorization outright).=A0 To me, this = seems like a contradiction that would lead to interoperability problems.=0A= > =0A> [wmills] "scope" is an optional parameter, so if you want an empty v= alue you don't send scope at all.=0A> =0A=0AMy apologies for not being clea= r.=0A=0AAs I read the document, there are two ways I can see how to interpr= et the term "unscoped":=0A=0A1. scope of "" during the authorization reques= t=0A2. omit the scope from the authorization request=0A=0AThe first is clea= rly in violation of RFC 6749 (the ABNF requires at least one scope-token, a= nd the scope-token requires at least one printable non-whitespace ACII char= acter).=A0 The second, however, seems to invite failure because the authori= zation server MUST either use the default scope (if it has one) or fail aut= horization.=0A=0AAccording to this document, the resource server providing = a scope of something other than "" is NOT RECOMMENDED.=A0 That means (as I = interpret from RFC 2119) that "I can try to return a non-empty scope, but i= t will likely cause problems in most cases".=0A=0AThis document states that= clients that receive an error response with an empty scope (or no scope at= all) SHOULD omit the scope from the authorization request (since, again, s= pecifying a scope of "" violates RFC 6749).=A0 SHOULD means (as I interpret= from RFC 2119) that "I can try to specify a scope anyway, but it will like= ly cause problems in most cases".=0A=0AI am then balancing all this against= what I've experienced with already deployed OAuth frameworks: not specifyi= ng a scope results in a failure from the authorization server.=A0 Many -- i= f not most -- OAuth client libraries won't send an authorization request wi= th a scope specified.=0A=0AThis is the interoperability problem I see in th= is document.=A0 It seems (to me) that it is destined to cause confusion and= at best, and non-functioning (if following the SHOULDs and NOT RECOMMENDED= s) or non-compliant (ignoring the SHOULDs and NOT RECOMMENDEDs) code at wor= st.=0A=0AI think this could be fixed by either removing the NOT RECOMMENDED= about presenting a space-separated list for scope, or by changing the SHOU= LD to a MAY regarding what the client sends for the authorization request. = I think it would also help to define what unscoped means, or not use the te= rm at all.=0A=0ASuggested starting point for text (replacing all of section= 3.2.2):=0A=0A""""=0AFor a failed authentication the server returns a JSON = [RFC4627] formatted error result, and fails the authentication. The error r= esult consists of the following values:=0A=0A=A0 =A0 status (REQUIRED):=0A= =A0 =A0 =A0 =A0 The authorization error code. Valid error codes are defined= in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 cor= e specification. =0A=A0 =A0 scope (OPTIONAL):=0A=A0 =A0 =A0 =A0 An OAuth sc= ope which is valid to access the service. This may be empty or a space sepa= rated list. Use of a space separated list is NOT RECOMMENDED. =0A=0AIf the = resource server provides a scope value that is not the empty string then th= e client MUST always request scoped tokens from the token endpoint. If the = resource server provides no scope to the client then the client MAY omit th= e scope from the authorization request.=0A""""=0A=0A> * In section 1. Intro= duction, SMTP is mentioned with a citation but without a definition (unlike= SASL and IMAP immediately preceding).=0A> =0A> [wmills] I see "SMTP [RFC53= 21]" there=0A> =0A=0AWhat I see:=0A=0A* Simple Authentication and Security = Layer (SASL) [RFC4422]=0A* Internet Message Access Protocol (IMAP) [RFC3501= ]=0A* SMTP [RFC5321]=0A=0AOne of these things is not like the others (-:=0A= =0AThis is very clearly a nit.=A0 The lack of consistency erks me somewhat,= but I doubt it truly matters.=0A=0A=0A=0A- m&m=0A=0AMatt Miller < mamille2= @cisco.com >=0ACisco Systems, Inc. ---1981468715-1467257001-1387391065=:73288 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We we= nt around a number of times on the SASL identities.  The problem I see= is that the assertion of authz-id if it's specified separately in protocol= just has to be matched/confirmed by the token anyway so the value should j= ust be derived from that.


Not sure why the MAC token draft numbe= r is wrong.  I'm using the xml2rfc format and referring to <?rfc in= clude=3D'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oaut= h-v2-http-mac.xml' ?> so I'm not sure what to fix.

On scopes, I'm= not liking your changes but see the problem.  The current text is:
"An OAuth scope which is valid to access the service. This may be = empty which implies that unscoped tokens are required, or a space separated= list. Use of a space separated list is NOT RECOMMENDED."
=
I propose:

"An OAuth scope which is valid to access the serv= ice. This may be empty which implies that unscoped tokens are required, or a sc= ope value.  If a scope is specified then a single scope is preferred, = use of a space separated list of scopes is NOT RECOMMENDED."<= br> 
-bill

P.S. Nits...  "erk" is actually a sound mad= e when you drop something on your foot, "irk" is indicative of the reaction= to excessive pedantry. :)

--------------------------------
Will= iam J. Mills
"Paranoid" Yahoo!



On Wednesday, December 18, 2013 8:25 AM, Matt Miller (mamille2= ) <mamille2@cisco.com> wrote:
Thanks for the rapid turnover!

One additional item I just noticed: the reference to [I-D.draft-ietf-o= auth-v2-http-mac] is out of date. It should be draft-ietf-oauth-v2-http-mac= -04, not -01.

More inline, stripping a= ll but what I'm responding to:

On Dec = 17, 2013, at 6:24 PM, Bill Mills <wmills@yahoo-inc.c= om> wrote:

> MAJOR:
>
> * Removing the GS2-header (which was= done in revision -11) also removed the ability for the client to specify a= n authorization identity.  If the lack of an authorization identity is= acceptable (and I suspect it is not for some), then the document needs to state these mechan= isms do not support authz-id.
>
>= ; [wmills] This is addressed in 3.2.1 of -12  authz-id is possible in = some OAuth schemes.
>

Section 3.2.1. talks about authentication identities (authn-id), not = authorization identities (authz-id).  The two are different: authn-id = is who holds the credentials (such as they are in OAuth) and authz-id is wh= om the authn-id is acting as.

The more= I read that section, the less convinced I am that it meets the requirement= s for SASL mechanisms (RFC 4422 =A7 5).  Identities (at least authn-id= , and often authzid) are provided for all other SASL mechanisms, and all of= the SASL-using protocols I'm familiar with rely on an identity coming out = of the SASL exchange.

I understand tha= t the access token itself is not guaranteed to contain this information, but at some le= vel the resource server needs to be able to associate the SASL authenticati= on credentials (OAuth access token) with an authentication and/or authoriza= tion identity.  From what I've seen of existing OAuth software, there = is some way to determine an identity -- if not encoded directly in the acce= ss token, then by agreement between the resource server and the authorizati= on server (e.g., REST APIs specific to the authorization server).

I suppose one possible transposition is for th= e authn-id to be the OAuth client identity and the authz-id to be the OAuth= resource owner identity.  I personally don't find this mapping intere= sting or appropriate, and doesn't account for the resource owner acting as = a different identity within the context of the SASL-using application.

A possible starting point for text (not su= re where in 3.2.1. to place it):

""""The authentication identity is determined by the resource s= erver using information associated with the access token. This information = might be encoded within the access token itself, or the resource server mig= ht obtain the information from the authorization server through other means= . The specific method is outside the scope of this work.
= """"

This still doesn't account for th= e authorization identity. This could be handled by adding a new kvpair (e.g= ., "authzid") and maybe some language about how the resource server might v= alidate/verify its use against the provided credentials.
=
Or, I'm just tilting at windmills.
> * In section 3.2.2. Server Response to Failed Authenti= cation, returning a space-separated list for the "scope" field is NOT RECOM= MENDED, but also says the lack of a "scope" (value or field) implies the client SHOULD= request tokens that are unscoped (empty list of scopes).  However, RF= C 6749 =A7 3.3 does not permit unscoped tokens; the ABNF does not allow for= "scope=3D" (i.e., the empty list), and the text regarding the lack of scop= e means the authorization server uses a default scope value (or fails autho= rization outright).  To me, this seems like a contradiction that would= lead to interoperability problems.
>
> [wmills] "scope" is an optional parameter, so if you want an empty = value you don't send scope at all.
>

My apologies for not being clear.
As I read the document, there are two ways I can see how t= o interpret the term "unscoped":

1. sc= ope of "" during the authorization request
2. omit the sc= ope from the authorization request

The first is cl= early in violation of RFC 6749 (the ABNF requires at least one scope-token,= and the scope-token requires at least one printable non-whitespace ACII ch= aracter).  The second, however, seems to invite failure because the au= thorization server MUST either use the default scope (if it has one) or fai= l authorization.

According to this doc= ument, the resource server providing a scope of something other than "" is = NOT RECOMMENDED.  That means (as I interpret from RFC 2119) that "I ca= n try to return a non-empty scope, but it will likely cause problems in mos= t cases".

This document states that cl= ients that receive an error response with an empty scope (or no scope at al= l) SHOULD omit the scope from the authorization request (since, again, spec= ifying a scope of "" violates RFC 6749).  SHOULD means (as I interpret= from RFC 2119) that "I can try to specify a scope anyway, but it will likely ca= use problems in most cases".

I am then= balancing all this against what I've experienced with already deployed OAu= th frameworks: not specifying a scope results in a failure from the authori= zation server.  Many -- if not most -- OAuth client libraries won't se= nd an authorization request with a scope specified.

This is the interoperability problem I see in this document.&= nbsp; It seems (to me) that it is destined to cause confusion and at best, = and non-functioning (if following the SHOULDs and NOT RECOMMENDEDs) or non-= compliant (ignoring the SHOULDs and NOT RECOMMENDEDs) code at worst.

I think this could be fixed by either removi= ng the NOT RECOMMENDED about presenting a space-separated list for scope, o= r by changing the SHOULD to a MAY regarding what the client sends for the authorization request. I think it would also help to define what unscoped = means, or not use the term at all.

Sug= gested starting point for text (replacing all of section 3.2.2):

""""
For a failed authentica= tion the server returns a JSON [RFC4627] formatted error result, and fails = the authentication. The error result consists of the following values:

    status (REQUIRED):
        The authorization error code. Valid e= rror codes are defined in the IANA "OAuth Extensions Error Registry" specif= ied in the OAuth 2 core specification.
    sco= pe (OPTIONAL):
        An OAuth scope= which is valid to access the service. This may be empty or a space separat= ed list. Use of a space separated list is NOT RECOMMENDED.

If the resource server provides a scope value that is not t= he empty string then the client MUST always request scoped tokens from the = token endpoint. If the resource server provides no scope to the client then= the client MAY omit the scope from the authorization request.
""""

> * In section 1. Introd= uction, SMTP is mentioned with a citation but without a definition (unlike = SASL and IMAP immediately preceding).
>
> [wmills] I see "SMTP [RFC5321]" there
>

What I see:

* Simple Authentication and Security Layer (SASL) [RFC4422]
* Internet Message Access Protocol (IMAP) [RFC3501]
* SMTP [RFC5321]

One of thes= e things is not like the others (-:

Th= is is very clearly a nit.  The lack of consistency erks me somewhat, but I doubt it truly matters.


- m&m

Ma= tt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


= ---1981468715-1467257001-1387391065=:73288-- From mamille2@cisco.com Wed Dec 18 11:10:04 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62021AE1C2 for ; Wed, 18 Dec 2013 11:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn0so5GqRwTJ for ; Wed, 18 Dec 2013 11:10:02 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BE8851AE1C3 for ; Wed, 18 Dec 2013 11:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4240; q=dns/txt; s=iport; t=1387393800; x=1388603400; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K3NbzEwJW9LNUc6p8lPye6Kc3QK0cbxWZRLRMonQ/KQ=; b=T26ohjWruQ+LRNuo42jSnVos8DgmmXtCmZo8Vj/HzivS3D7jws1Tw5xF XDC3SQ4TeGu3qtLQ8/DFMKMQIwMdxWOX7oRHennzKUFl02iAvXOxBRgK2 LDiHBToHBUOtIt69kcy6+EKh6hMuAlpo7/oK3GI0Ngt2DOWRyaRR3trHv 4=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAEbysVKtJXHB/2dsb2JhbABQCYMKOFW4dYEbFnSCJQEBAQMBeQULAgEIDjgyJQIECgQFDoduCA3KOReON1sHgyOBEwSQM4ExhjKSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,508,1384300800"; d="asc'?scan'208";a="292457410" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 18 Dec 2013 19:10:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBIJ9xsZ032573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 19:10:00 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.22]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 13:09:59 -0600 From: "Matt Miller (mamille2)" To: Bill Mills Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 Thread-Index: AQHO+iYGh/HTVxoMc0+2BQxVCnN2eJpZZA6AgAAsCoCAAPuZgIAAIVqAgAAMugA= Date: Wed, 18 Dec 2013 19:09:59 +0000 Message-ID: <4D6B8140-7BE7-4F6C-83A9-6746BEEDC3D6@cisco.com> References: <52AE9A65.1010700@oracle.com> <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com> <1387391065.73288.YahooMailNeo@web125601.mail.ne1.yahoo.com> In-Reply-To: <1387391065.73288.YahooMailNeo@web125601.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.238] Content-Type: multipart/signed; boundary="Apple-Mail=_8A60EB42-2944-4162-BE50-25C90C4F1106"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 19:10:05 -0000 --Apple-Mail=_8A60EB42-2944-4162-BE50-25C90C4F1106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 18, 2013, at 11:24 AM, Bill Mills wrote: >=20 > We went around a number of times on the SASL identities. The problem = I see is that the assertion of authz-id if it's specified separately in = protocol just has to be matched/confirmed by the token anyway so the = value should just be derived from that. >=20 I still think you're still conflating authn-id and authz-id here. An example: let's say we have an XMPP service, where a session is = long-lived and have a strong identity (effectively, the sender address = cannot be anything other than what the user logged in with). Our = resource owner has multiple identities on this service = ("john.smith@example.com", "bofh@example.com", = "slumber.viking@example.com"), but one set of credentials on the = authorization server. In this case, what should the XMPP service use for the identity? For most other SASL mechanisms, this is where authz-id is used. It = still absolutely requires the resource server to confirm the authz-id is = appropriate for the given credentials (token). If there were only one = possible identity, then the client shouldn't even specify an authz-id = (IMO). But where there are multiple possible identities, the user might = want to pick one other than the default. Now, it could very well be that the above is not something that ought to = be supported for SASL-OAuth. It could be that the resource owner needs = to choose the specific identifier to use as part of the OAuth = authorization flow before the token is even granted. If this is the = most desired case, then the mechanisms need to specifically state that = they do not transfer authorization identity strings. >=20 > Not sure why the MAC token draft number is wrong. I'm using the = xml2rfc format and referring to so I'm not sure what to fix. >=20 Hrm. Maybe there is an overly aggressive caching proxy between you and = xml.resource.org, or an overly aggressive local cache? I would suggest using "https://", but it looks like the cert isn't valid = for xml.resource.org! /me notes to follow up on that... > On scopes, I'm not liking your changes but see the problem. The = current text is: >=20 > "An OAuth scope which is valid to access the service. This may be = empty which implies that unscoped tokens are required, or a space = separated list. Use of a space separated list is NOT RECOMMENDED." >=20 > I propose: >=20 > "An OAuth scope which is valid to access the service. This may be = empty which implies that unscoped tokens are required, or a scope value. = If a scope is specified then a single scope is preferred, use of a = space separated list of scopes is NOT RECOMMENDED." > =20 That works for me, and I think that's what most deployments will want to = do. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > -bill >=20 > P.S. Nits... "erk" is actually a sound made when you drop something = on your foot, "irk" is indicative of the reaction to excessive pedantry. = :) >=20 I said erk out loud when i saw it, does that count (-: --Apple-Mail=_8A60EB42-2944-4162-BE50-25C90C4F1106 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSsfMHAAoJEDWi+S0W7cO1tTsH/1jFAuSfUpigYvF/HxxhuNIX xfZ7YuLxB3Nb1SzZ1SugukeAkJMRP4ALQt8npFkirM6X1a7A2ouZhPaFKJ/iDyHU G3mdejBxqEmU8ErU781ujvAFTnOqgQFkrrdXK8axcazx2CNdmTng0pOVH3JKYqSU e9K1bN7HJdicJjPBZrRHSSEBSBogpcoJlxSWU3Pea6QkTqXTZq7C+2vdn0Hz5RFa GU/kSa/bTlyk8h4zRHEhWGk4s/ciIU1ooKl/RMGO5jW0MWrSM9XF2HsxUZaFAzKq 1yuR8OVCiPrXUnJ9UunFcc4I1vnbuvr0AQuhfb5YhZioKZj1hgJheVULkvUhFCY= =b0YG -----END PGP SIGNATURE----- --Apple-Mail=_8A60EB42-2944-4162-BE50-25C90C4F1106-- From wmills@yahoo-inc.com Thu Dec 19 10:21:39 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53941AE4B2 for ; Thu, 19 Dec 2013 10:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi3vHkJ9fryM for ; Thu, 19 Dec 2013 10:21:37 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 247E61AE47B for ; Thu, 19 Dec 2013 10:21:37 -0800 (PST) Received: from BF1-EX10-CAHT04.y.corp.yahoo.com (bf1-ex10-caht04.corp.bf1.yahoo.com [10.74.209.59]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBJIKpqO007262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Dec 2013 10:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1387477252; bh=HMtFkTGS3sd+0f5ILUut5oe6q+xzsmjd0kMCxnIfAng=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=BBj5bRFn5qH5TOf3lc1bphRA754T7iY8uVJ+L7c5bT5LDlWBs03Kb48KEEwU2zwK5 //Cfk9CLZ3b34gPGwD/wUDFJOKB0IkxRNMHElJtDXOP5stJLdgHyZERb6knuMXsAUr ehzcQprwfhmnOStyb7t8qXHNtBhRYEzTK8MPadoI= Received: from omp1019.mail.ne1.yahoo.com (98.138.89.163) by BF1-EX10-CAHT04.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 19 Dec 2013 13:21:41 -0500 Received: (qmail 61149 invoked by uid 1000); 19 Dec 2013 18:20:49 -0000 Received: (qmail 7344 invoked by uid 60001); 19 Dec 2013 18:20:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1387477249; bh=fxc6fw/jaD18T/bQwQ7LzC068iPriLHzJ5/kAC81jEQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hCNzQVY5DSc36Qc9t1dbIz7HENyVV+EKeHdwjx+GKkr4HXSeDPtmyT/pOAPyUNrVRfJzYE/ZNu4OC/bIHYPWQHt0XoGr+W0gmgTiBwmqrMgjRu8jjKToy6FWky3yKCEk1mco/iskOSFspKEKkmSRLzfgsZvGKOdrcid8qoOduwk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EqBF+alpctYrCE/KwlcCE1C1XigDXE0P7406oC7biES/E7hOCfvZ/vXkhdddT76yeLuRzBK4b9zUb/MxRdHScke9HSpoTwNcv8MTyNyl/piXgA04SZwx8m0MmKaPXtUzrpAdENKkaVuVdGYo5iJpgxCb21HwAtF0R50gcKz9UHs=; X-YMail-OSG: Xo6WovEVM1m52t2hAT3muDlGmvVkfa.AjGSJ005ICZvG.HK 02gZX0EOrOcVDjDvZRpTLtx3Nx6JEtngCvOu9F9bCtOIutdC3UhN0Cb3D_wk KRD9hqtx69t9ilPmEMHqYLqADdVY8ttaV5.RNTg9WDqL4RhVzbzf5FWQ7d9w 4fNPAnoyR68ZD1pWEovkS9KZLy7NeMYJfXAdIffHsM.ZsDfOCxkNtQVDPJhm xjulPUCCXTrqL6OF32A_tcrZLDdq3_OKWj9oaYfoyA2q1azoJ_7AMLTM0Bq4 2VTqRlhDzKMpHN8H7HujdUBUpknd7NOQKXFY- Received: from [209.131.62.115] by web125602.mail.ne1.yahoo.com via HTTP; Thu, 19 Dec 2013 10:20:49 PST X-Rocket-MIMEInfo: 002.001, SSd2ZSBpbmNsdWRlZCB0aGUgbGFuZ3VhZ2UgY2hhbmdlIGZvciBzY29wZS4KCgpPbiBBdXRoei1JRCB3ZSBlbmRlZCB1cCB3aXRoIHNvbWUga2luZCBvZiBmdXp6eSBsYW5ndWFnZSB0aGVyZSBhbmQgd2Uga25ldyBpdC7CoCBUaGUgcHJvYmxlbSBiZWluZyB0aGF0IGl0IHdpbGwgZGVwZW5kIG9uIHRoZSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbi7CoCBJdCdzIHBvc3NpYmxlIHRvIGRvIE9BdXRoIDEuMGEgd2l0aG91dCBhbnkgdXNlZnVsIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgZXhhbXBsZS7CoCBJJ20BMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <52AE9A65.1010700@oracle.com> <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com> <1387391065.73288.YahooMailNeo@web125601.mail.ne1.yahoo.com> <4D6B8140-7BE7-4F6C-83A9-6746BEEDC3D6@cisco.com> Message-ID: <1387477249.80645.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Thu, 19 Dec 2013 10:20:49 -0800 From: Bill Mills To: "Matt Miller (mamille2)" In-Reply-To: <4D6B8140-7BE7-4F6C-83A9-6746BEEDC3D6@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-459962602-1387477249=:80645" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 477252002 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 18:21:40 -0000 ---1088529044-459962602-1387477249=:80645 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've included the language change for scope.=0A=0A=0AOn Authz-ID we ended u= p with some kind of fuzzy language there and we knew it.=A0 The problem bei= ng that it will depend on the specific implementation.=A0 It's possible to = do OAuth 1.0a without any useful client authentication for example.=A0 I'm = not in love with the current language, but I can't see a better way without= forcing some set of reasonable implementations into non-compliance.=0A=0A= =A0=0A-bill=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills= =0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Wednesday, December 18, 2013 11:10= AM, Matt Miller (mamille2) wrote:=0A =0A=0AOn Dec 18,= 2013, at 11:24 AM, Bill Mills wrote:=0A=0A> =0A> We= went around a number of times on the SASL identities.=A0 The problem I see= is that the assertion of authz-id if it's specified separately in protocol= just has to be matched/confirmed by the token anyway so the value should j= ust be derived from that.=0A> =0A=0AI still think you're still conflating a= uthn-id and authz-id here.=0A=0AAn example: let's say we have an XMPP servi= ce, where a session is long-lived and have a strong identity (effectively, = the sender address cannot be anything other than what the user logged in wi= th).=A0 Our resource owner has multiple identities on this service ("john.s= mith@example.com", "bofh@example.com", "slumber.viking@example.com"), but o= ne set of credentials on the authorization server.=0A=0AIn this case, what = should the XMPP service use for the identity?=0A=0AFor most other SASL mech= anisms, this is where authz-id is used.=A0 It still absolutely requires the= resource server to confirm the authz-id is appropriate for the given crede= ntials (token).=A0 If there were only one possible identity, then the clien= t shouldn't even specify an authz-id (IMO).=A0 But where there are multiple= possible identities, the user might want to pick one other than the defaul= t.=0A=0ANow, it could very well be that the above is not something that oug= ht to be supported for SASL-OAuth.=A0 It could be that the resource owner n= eeds to choose the specific identifier to use as part of the OAuth authoriz= ation flow before the token is even granted.=A0 If this is the most desired= case, then the mechanisms need to specifically state that they do not tran= sfer authorization identity strings.=0A=0A> =0A> Not sure why the MAC token= draft number is wrong.=A0 I'm using the xml2rfc format and referring to so I'm not sure what to fix.=0A> =0A=0AHrm.=A0 = Maybe there is an overly aggressive caching proxy between you and xml.resou= rce.org, or an overly aggressive local cache?=0A=0AI would suggest using "h= ttps://", but it looks like the cert isn't valid for xml.resource.org!=0A= =0A/me notes to follow up on that...=0A=0A> On scopes, I'm not liking your = changes but see the problem.=A0 The current text is:=0A> =0A> "An OAuth sco= pe which is valid to access the service. This may be empty which implies th= at unscoped tokens are required, or a space separated list. Use of a space = separated list is NOT RECOMMENDED."=0A> =0A> I propose:=0A> =0A> "An OAuth = scope which is valid to access the service. This may be empty which implies= that unscoped tokens are required, or a scope value.=A0 If a scope is spec= ified then a single scope is preferred, use of a space separated list of sc= opes is NOT RECOMMENDED."=0A>=A0 =0A=0AThat works for me, and I think that'= s what most deployments will want to do.=0A=0A=0A- m&m=0A=0AMatt Miller < m= amille2@cisco.com >=0ACisco Systems, Inc.=0A=0A=0A> -bill=0A> =0A> P.S. Nit= s...=A0 "erk" is actually a sound made when you drop something on your foot= , "irk" is indicative of the reaction to excessive pedantry. :)=0A> =0A=0AI= said erk out loud when i saw it, does that count (-: ---1088529044-459962602-1387477249=:80645 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've incl= uded the language change for scope.

= On Authz-ID we ended up with some kind of fuzzy language there and we knew = it.  The problem being that it will depend on the specific implementat= ion.  It's possible to do OAuth 1.0a without any useful client authent= ication for example.  I'm not in love with the current language,= but I can't see a better way without forcing some set of reasonable implem= entations into non-compliance.
 
-bill<= br>

--------------------------------
William J. Mills
"Paranoid" Yah= oo!



On Wednesd= ay, December 18, 2013 11:10 AM, Matt Miller (mamille2) <mamille2@cisco.c= om> wrote:

On Dec 18, 2013, at 11:24 AM, Bill Mills <= wmills@yahoo-inc.com> wrote:

&g= t;
> We went around a number of times on the SASL ide= ntities.  The problem I see is that the assertion of authz-id if it's specified separate= ly in protocol just has to be matched/confirmed by the token anyway so the = value should just be derived from that.
>

I still think you're still conflating authn-id an= d authz-id here.

An example: let's say= we have an XMPP service, where a session is long-lived and have a strong i= dentity (effectively, the sender address cannot be anything other than what= the user logged in with).  Our resource owner has multiple identities= on this service ("john.smith@example.com", "bofh@example.com", "slumber.viking@example.com"= ), but one set of credentials on the authorization server.

In this case, what should the XMPP service use for the= identity?

For most other SASL mechani= sms, this is where authz-id is used.  It still absolutely requires the= resource server to confirm the authz-id is appropriate for the given crede= ntials (token).  If there were only one possible identity, then the cl= ient shouldn't even specify an authz-id (IMO).  But where there are mu= ltiple possible identities, the user might want to pick one other than the = default.

Now, it could very well be th= at the above is not something that ought to be supported for SASL-OAuth.&nb= sp; It could be that the resource owner needs to choose the specific identi= fier to use as part of the OAuth authorization flow before the token is eve= n granted.  If this is the most desired case, then the mechanisms need = to specifically state that they do not transfer authorization identity stri= ngs.

>
> Not = sure why the MAC token draft number is wrong.  I'm using the xml2rfc f= ormat and referring to <?rfc include=3D'http://xml.resource.org/public/rfc/bibxml3/referen= ce.I-D.ietf-oauth-v2-http-mac.xml' ?> so I'm not sure what to fix.>

Hrm.  Mayb= e there is an overly aggressive caching proxy between you and xml.resource.= org, or an overly aggressive local cache?

I would suggest using "https://", but it looks like the cert isn't vali= d for xml.resource.org!

/me notes to f= ollow up on that...

> On scopes, I'm not likin= g your changes but see the problem.  The current text is:
>
> "An OAuth scope which is valid to access= the service. This may be empty which implies that unscoped tokens are requ= ired, or a space separated list. Use of a space separated list is NOT RECOM= MENDED."
>
> I propose:
>
> "An OAuth scope which is valid to ac= cess the service. This may be empty which implies that unscoped tokens are = required, or a scope value.  If a scope is specified then a single sco= pe is preferred, use of a space separated list of scopes is NOT RECOMMENDED= ."
> 

That = works for me, and I think that's what most deployments will want to do.


- m&m

Matt Miller < mamille2@cisco.com >= ;
Cisco Systems, Inc.


> -bill
>
> P.S. Nits...  "erk" is actually a soun= d made when you drop something on your foot, "irk" is indicative of the rea= ction to excessive pedantry. :)

>

I said erk out loud when i saw it, does that count = (-:

=

---1088529044-459962602-1387477249=:80645-- From rickardbrown@hushmail.com Tue Dec 24 10:25:48 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BD1AE03E for ; Tue, 24 Dec 2013 10:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_NEUTRAL=0.112, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhHqKUuilzVF for ; Tue, 24 Dec 2013 10:25:46 -0800 (PST) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id D66451AE055 for ; Tue, 24 Dec 2013 10:25:24 -0800 (PST) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 17776A01B6 for ; Tue, 24 Dec 2013 17:50:04 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: 473ccb327b891ddac9c92aab03ede216 Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Tue, 24 Dec 2013 17:50:03 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E0B956020E; Tue, 24 Dec 2013 17:50:03 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 24 Dec 2013 17:50:03 +0000 To: kitten@ietf.org From: rickardbrown@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20131224175003.E0B956020E@smtp.hushmail.com> Subject: [kitten] Fake Conferences CSCI and WORLDCOMP of Hamid Arabnia X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2013 18:25:48 -0000 Fake Conferences CSCI and WORLDCOMP of Hamid Arabnia Hamid Arabnia from University of Georgia is well known for his fake WORLDCOMP conferences https://sites.google.com/site/dumpconf This website has an open challenge posted sometime in 2012 and it also has comments from several well-known researchers on WORLDCOMP. Hamd Arabnia never responded to these because his conferences are bogus. Hamid Arabnia (the money hungry professor) has recently started 2014 International Conference on Computational Science and Computational Intelligence (CSCI'14) http://www.americancse.org to deceive researchers further. CSCI'14 is started under the title of “American Council on Science and Education” which is a dummy corporation (does not exist anywhere in the world). Hamid Arabnia buried his name in the list of names of other innocent steering and program committee members of CSCI’14 to avoid any special attention. He knows that if his name is given any special attention then researchers immediately notice that the conference is fake due to his “track record” with WORLDCOMP. Hamid Arabnia (Guru of Fake Conferences and champion of academic scam) spoiled the reputations and careers of many authors who submitted papers to his infamous WORLDCOMP for more than a decade and he is now ready to do the same using CSCI. Interestingly, CSCI is scheduled to be held at the same venue where WORLDCOMP was held until 2012. CSCI has no general chair. It has no physical person’s name or physical address or phone number to contact. Only contact address is an email address. Hamid Arabnia and his puppets answer the emails, if needed, using fake names. Do not spoil your resume by submitting your papers in this bogus conference CSCI which will not be held beyond 2014. CSCI will not be indexed by DBLP. Recently, Hamid Arabnia paid money and published few “news articles” claiming him a victim of online harassment and cyber bullying. Now he started posting (using fake names and through his puppets) in various emails, blogs and forums, referring to those “news articles” and trying to get back sympathy and trust of the research community to make his CSCI successful. Hamid Arabnia is a Wolf in a Sheep’s skin. We challenge Hamid Arabnia to openly publish the names and affiliation details of the reviewers for thousands of research papers submitted to WORLDCOMP for the last thirteen years. We also challenge Hamid Arabnia to openly publish all the reviews (after removing authors identification details) for all the thousands of research papers submitted to WORLDCOMP for the last thirteen years. There are more challenges at https://sites.google.com/site/moneycomp1 We know that he never accepts these challenges because there were no reviews and no reviewers and he simply cheated the research community for all these years. We are not surprised if he comes out tomorrow claiming that his computer crashed and he lost the reviews and reviewers’ details. He can play any deceiving trick. See the important website https://sites.google.com/site/worlddump1 for more information on WORLDCOMP, including links to DBLP stop indexing WORLDCOMP proceedings. See http://worldcomp-fake-bogus.blogspot.com for Hamid Arabnia and his puppet’s Anti-Christmas Greetings campaign. We ask Hamid Arabnia and his puppets to address the above issues and challenges before posting any other message. Do not spoil your resume by publishing in the fake conferences of Hamid Arabnia. Sincerely, Many researchers cheated by the conferences of Hamid Arabnia