From stpeter@stpeter.im Tue Jul 2 12:57:02 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E14421F9B26; Tue, 2 Jul 2013 12:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myp8-84kIBjT; Tue, 2 Jul 2013 12:56:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61A21F9AE0; Tue, 2 Jul 2013 12:56:55 -0700 (PDT) Received: from sjc-vpn5-1046.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D3D141101; Tue, 2 Jul 2013 13:57:35 -0600 (MDT) Message-ID: <51D33084.5060903@stpeter.im> Date: Tue, 02 Jul 2013 13:56:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:57:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/3/13 1:39 PM, Nico Williams wrote: > Please forgive my apparent apathy. I lost track of this due to > business travel. And please forgive my delay in replying. It's good to know you're not apathetic. And as you can tell, we're proceeding rather slowly with this work. That doesn't mean it is unimportant. This recent example from the blogosphere might of interest: http://labs.spotify.com/2013/06/18/creative-usernames/ PRECIS might have helped those folks avoid some significant pain. > I'm not sure where the case mapping requirement for usernames came > from. Are you referring to global case mapping or local case mapping? > I guess it has something to do with the Turkish I and such. Yes, that is a nasty problem with even nastier consequences: http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail Just to be clear, that's an issue of what we're calling local case mapping (where locale is taken into consideration). > I can't say I'm excited about this case mapping requirement; if > anything it strikes as silly. In general, the opinion so far has been that, say, StPeter is treated the same as stpeter when it comes to authentication and authorization based on usernames. Do you disagree? If so, why? For example, would you be inclined to leave this up to the protocol that uses SASL (say, IMAP or XMPP) instead of specifying it in SASLprepbis? > Why would we apply mappings to usernames (which are sent on the > wire) that we don't apply to passwords (which servers generally > don't get the plaintext of)? We need mappings for passwords to > make password entry reliable. The same does NOT apply to > usernames. My naïve perspective is that the combination of username and password is your credential (for password-based systems). If I provide StPeter and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure want the password to be treated in a case-sensitive manner (since that reduces the possibility of false positives), whereas we want the username to be treated in a case-insensitive manner (since most application protocols treat StPeter@example.com as the same account as stpeter@example.com). > Also, looking at SASLprep and PRECIS, I see no mention of query > strings vs. display vs. storage. These distinctions matter. But > maybe I'm just failing to search for the right terms. Would you be so kind as to expand on that a bit? I'd like to make sure I understand what you mean by each of those terms. > Heck, we're not even told whether these rules should be applied by > the client, the server, or both. That is a very good point. This was something that bit us in RFC 3920 (for XMPP) and we've cleared that up in 6122bis: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3 In my experience, we can *say* that the client needs to do this, but the server will need to do it anyway since it can't trust the client to do the right thing. However, for passwords (which, as you note, we hope the server never sees in plaintext) the client would need to enforce the rules. > Anyways, I'm for applying as few transformations as possible to > usernames on the *client* side and leaving the server to apply > RECOMMENDED, and a few REQUIRED rules for matching. I'd agree with that sentiment. > I don't see room for case folding in general, Even on the server side? Again, do you think it would be better to leave that up to the application? > but I do for specific cases (e.g., Turkish I handling). Unfortunately, local case mapping might be difficult for the server to perform because it doesn't necessarily have information about the locale of the user. So this is something that might best be handled at the client. > If this review is too late to make a difference, well, c'est la > vie. But do give the above some thought before rejecting my > comments for being late. Once more, I'm sorry I let this slip. You are not too late and your comments are important! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0zCEAAoJEOoGpJErxa2p7xEQAJROFDCBZfnrP+9+h0qi29VL SBmWvTXkJTcLzRTUJja6bsTp75vqdFfckFT4apWeTuBrABktt8ny0/kNPAGue41H Q1avmi0y06oonL49zMbSiEmnPBakgOL75q5V1z218iV4w6cUFFh/AJtL36Dh8t// VZABcnuitQYknJbHR4HXZ0iAp4Aeo6EUHSkX9YSspf3IZJkXivXG3cCYNfw08B6p 5YrwXdsu4q7wH6bZcEDQBrQO1puaFG5/svOI/YnfvdIZH5ulYg0eeKOPp8VBVD4E exssCzttwTOGUDA2QLWovNHyHBKIHpfNAEiOvXj976UIPX5revaR6o0VUq7ekJfj uoaO+xvVAaKHI6huv1EUtVtbOxW248heZxci6eaQEYzheOrsyUInGgjpAYcMUdRy UjPmGtYQAgiZNIcLLCCdbZIjl8soF4rxu1LUBeVLkgW5widbHN1DXxvpHM499Kyf FyS2xC2WSDxV6c0oueFTG6VlXjevyCamAc4AjEycPTR+180or7OTaH841SSGAN5j IVRZVlK4CmYdDQTUAoPYacpYE4Y1jXqI+G5VZQVOIrlYoIGUu1RvujzJH1zDKBjQ 9uJyd6NtdTvc0ABBhoGLOiF/RcXzIwiLNHg1of5XVUWygs8KGUZxYtbepw0+nw08 JPzjpq3IyDXhavrqStFp =rkzA -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Jul 2 16:20:47 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6A21F9A65; Tue, 2 Jul 2013 16:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8owcRoTFaBWP; Tue, 2 Jul 2013 16:20:42 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 595A321F9A64; Tue, 2 Jul 2013 16:20:42 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id BB6E1350082; Tue, 2 Jul 2013 16:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=HbeJvHav0w9/psSm4/vGDapOLKg=; b=o1hrgt7wuk3 kf+QchyviIbWGeZ4uHAtts/KRT0k+dc5LSHdlCiMztwkz+aju8QdL3k1ji3UJlDY eW2cds+glpoYZtYbXV1w+UO6wk4z9V8newt/XhCohxT7oGGZl2zi1MWPqjEfdxhN pNaXmHWvJJldPLqjrR3wEefWWTT5vf04= Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 811B335007A; Tue, 2 Jul 2013 16:20:41 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so13481003ieb.2 for ; Tue, 02 Jul 2013 16:20:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lC0HEmJLMZnj8FmkH88L9Zcbdjv2KLA+WlKHIlDbH98=; b=L07hhB63G9weUjZ5wuIOXZEYWG/Vt1LfPf3U3FDUrAIHrU3gdDecTx/biIFxgxC7T3 lfPURQbYRivTgLarOLjhOUI8YaX+KxEcQbj1EpDLw5EY+fUelLPfoU0YJAPLefMxoCHV FyNX0gpjpgVkkAzrXcokXbhBy0Mg3rmGxfsjm+SXJQOC76X1wMb40jJq11ZvLHxHFQtN E31jrN82J/EdEq/GWb7Y02wKQv6w2UizQ2X3r1xYLcLQgEUCYX5F5gPnRjT1v984FT73 lgQ1xFrtAOr7ybdOlwc4SZV82qtS8dQ3dI7LX1q3jqqQgAaXxjgdzYFzWwF9T7yFRV3E PNVg== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr22805598igb.38.1372807240866; Tue, 02 Jul 2013 16:20:40 -0700 (PDT) Received: by 10.64.130.169 with HTTP; Tue, 2 Jul 2013 16:20:40 -0700 (PDT) In-Reply-To: <51D33084.5060903@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> Date: Tue, 2 Jul 2013 18:20:40 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 23:20:47 -0000 On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre wrot= e: > On 5/3/13 1:39 PM, Nico Williams wrote: > >> Please forgive my apparent apathy. I lost track of this due to >> business travel. > > And please forgive my delay in replying. It's good to know you're not > apathetic. And as you can tell, we're proceeding rather slowly with > this work. That doesn't mean it is unimportant. This recent example > from the blogosphere might of interest: > > http://labs.spotify.com/2013/06/18/creative-usernames/ > > PRECIS might have helped those folks avoid some significant pain. > >> I'm not sure where the case mapping requirement for usernames came >> from. > > Are you referring to global case mapping or local case mapping? > >> I guess it has something to do with the Turkish I and such. > > Yes, that is a nasty problem with even nastier consequences: > > http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-= three-more-in-jail ! But that can't apply here. Or, if anything, case mappings makes it more likely. Let's say I'm logged in in some app and it shows the username I typed in, but because of case mapping some typos are tolerated, so the username shown could offend someone. Whereas if I'm required to type my username exactly one way (not including NF) then that can't happen. So if anything that link indicates we should not have case mappings here... :) > Just to be clear, that's an issue of what we're calling local case > mapping (where locale is taken into consideration). > >> I can't say I'm excited about this case mapping requirement; if >> anything it strikes as silly. > > In general, the opinion so far has been that, say, StPeter is treated > the same as stpeter when it comes to authentication and authorization > based on usernames. Do you disagree? If so, why? For example, would > you be inclined to leave this up to the protocol that uses SASL (say, > IMAP or XMPP) instead of specifying it in SASLprepbis? I think it'd be nice if *servers* got to choose whether to do this. The principle here is that the server should make right when it comes to the username. This means that clients should be pretty much able to send just about anything as a username and let the server figure it out. Whether it's a server application or the mechanisms (or SASL library) that applies such rules is a different story, and one I don't think I care much about here. >> Why would we apply mappings to usernames (which are sent on the >> wire) that we don't apply to passwords (which servers generally >> don't get the plaintext of)? We need mappings for passwords to >> make password entry reliable. The same does NOT apply to >> usernames. > > My na=C3=AFve perspective is that the combination of username and passwor= d > is your credential (for password-based systems). If I provide StPeter > and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure > want the password to be treated in a case-sensitive manner (since that > reduces the possibility of false positives), whereas we want the > username to be treated in a case-insensitive manner (since most > application protocols treat StPeter@example.com as the same account as > stpeter@example.com). It's not just false positives: many sites require multiple character classes in password data, but case folding would nullify part of such policies :) If the user's password must survive with case intact then the user must be able to enter it portably (i.e., on many devices). Surely asking the same of usernames is not an undue additional burden for the user. Still, I don't mind if some site wants to have case-insensitive usernames. I just don't want us to impose that policy on *all* sites. Once again I'm thinking of online games, ones where people often convey ideas (usually comical ones) via their usernames. Providing the most freedom possible here seems like the right thing to do; requiring case-insensitivity is denying some freedom. >> Also, looking at SASLprep and PRECIS, I see no mention of query >> strings vs. display vs. storage. These distinctions matter. But >> maybe I'm just failing to search for the right terms. > > Would you be so kind as to expand on that a bit? I'd like to make sure > I understand what you mean by each of those terms. Sure. Query string =3D=3D a string entered by a user in some UI, to be matched against some thing's name. Display string =3D=3D a thing's name, as displayed to users in UIs. Storage string =3D=3D a thing's name as stored, and usually this is the canonical form of the thing's name. For example, "nico" might be a query name for my Kerberos principal, but the display name might be nico@CRYPTONECTOR.COM, and the storage string will be in some format we don't really care about here but roughly equivalent to the display string form. To continue the example, if my KDC was case-insensitive then "Nico" would also work as a query string; what I get for the display string might either match the query string or the storage string, and the storage string could be any of the many case variants of "nico" (but almost certainly would be case-folded in many implementations). The relevance here is that we should apply as few transformations as possible to *query* strings on the client-side and just send them. What transformations a server applies then can be up to the server and/or the mechanism (e.g., a federated mechanism might need to apply transformations specified by it). SASLprep-like stringpreps are very useful, especially for *passwords* because passwords may need to be in canonical form because they are used as inputs to client-side cryptographic functions (e.g., Digest). But they are less relevant for usernames, unless they too are used as inputs to client-side cryptographic functions (e.g., as salts), but even then the username query string might still be sent as-is separately to the server. >> Heck, we're not even told whether these rules should be applied by >> the client, the server, or both. > > That is a very good point. This was something that bit us in RFC 3920 > (for XMPP) and we've cleared that up in 6122bis: This is where the distinction between query, display, and storage (or canonical) forms comes in. > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3 > > In my experience, we can *say* that the client needs to do this, but > the server will need to do it anyway since it can't trust the client > to do the right thing. However, for passwords (which, as you note, we > hope the server never sees in plaintext) the client would need to > enforce the rules. Correct, as to the last part. I don't think we need the client to apply this to anything that isn't an input to a cryptograhic function on the client-side -- just send the darned thing as is. >> Anyways, I'm for applying as few transformations as possible to >> usernames on the *client* side and leaving the server to apply >> RECOMMENDED, and a few REQUIRED rules for matching. > > I'd agree with that sentiment. Great. >> I don't see room for case folding in general, > > Even on the server side? Again, do you think it would be better to > leave that up to the application? I'd leave it to the site/mechanism/app -- whatever's appropriate. >> but I do for specific cases (e.g., Turkish I handling). > > Unfortunately, local case mapping might be difficult for the server to > perform because it doesn't necessarily have information about the > locale of the user. So this is something that might best be handled at > the client. Ah, well, if we're dealing in Unicode we could send a language tag in the string. That's a non-starter. But note that the server probably has a username database anyways, so it knows the relevant language at account-creation time (or should anyways). Nico -- From nico@cryptonector.com Tue Jul 2 16:36:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBF711E80E6 for ; Tue, 2 Jul 2013 16:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahDeg8KY3Fva for ; Tue, 2 Jul 2013 16:36:04 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAF711E80FA for ; Tue, 2 Jul 2013 16:36:04 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id F2511200D5786 for ; Tue, 2 Jul 2013 16:36:03 -0700 (PDT) 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=CPFyqJG2MVTaH0emBaiu mAQO4A0=; b=fIuFPStliZODT6a2/pcWf1EdkcpigXy6gK6JkJMIoi2hyEF8hphR qhY7SFfp9a0HbdP9udhPNh1aCHdaiL3+TkQAUh6Zb29mgf9mv5+lJHds8Ib/QHN7 SZF1R1rC0IARJXfSfsecFgkpgfPQuyLe7mqWpqsJugKMCD5gbUXS9+w= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id C6FD3200D5780 for ; Tue, 2 Jul 2013 16:36:03 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so13479346iea.39 for ; Tue, 02 Jul 2013 16:36:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=boprvQy9UQG6MFUazAmXLgVxB9WFd5OGQSsjXnm+tL8=; b=VLws9hWgoJY6vJbtaX4yMyGjpIPEJ1XLWwoRShIx5U3tt4FbZ7lJpmyDn6kmRng7B1 JWV9xOElT9pcg4ac0Yj11dqbMbSff92Xl8Y8nigKCWCNprLNTIrjMx11bzqSSDE4vy3p tzioXkrV1wPepvMIyORX4qPv4cfB8/EJ7GGmSFOR8V5G/yjtn1IIbng1ianz85KYOyD/ kDryeeMyQjkB2jqUtZS+OU5tgimsZCGEX7urzqMCDcThiknlVIpDiP4bxolwVhnfqpRD y7vRpzAPBX6B4GTHCBlvmECqa2MIL9OY4ksLYwwfguoBX6+qVyFitOwTJvhnM8S4Ou+g MFqA== MIME-Version: 1.0 X-Received: by 10.42.33.129 with SMTP id i1mr449069icd.95.1372808163204; Tue, 02 Jul 2013 16:36:03 -0700 (PDT) Received: by 10.64.130.169 with HTTP; Tue, 2 Jul 2013 16:36:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jul 2013 18:36:03 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Adopting draft-williams-kitten-channel-bound-flag X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 23:36:09 -0000 On Fri, Jun 21, 2013 at 6:49 PM, Sam Hartman wrote: > Nico, based on Shawn's consensus call, I believe we have consensus to > adopt draft-williams-kitten-channel-bound-flag. > > based on discussions with Stephen today, we don't need to recharter to > do that. > So if you want to submit a 00, the chairs would be happy to approve. Oh, I thought I had a WG -00. I didn't, and I missed the deadline for that. From hartmans@mit.edu Wed Jul 3 06:10:12 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC611E81AB for ; Wed, 3 Jul 2013 06:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELKjceN39Njr for ; Wed, 3 Jul 2013 06:10:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B4AA811E81A9 for ; Wed, 3 Jul 2013 06:10:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E1F842013B; Wed, 3 Jul 2013 09:05:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4XkT0E0OgFE; Wed, 3 Jul 2013 09:05:32 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 3 Jul 2013 09:05:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ABDCB81454; Wed, 3 Jul 2013 09:09:22 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Wed, 03 Jul 2013 09:09:22 -0400 In-Reply-To: (Nico Williams's message of "Tue, 2 Jul 2013 18:36:03 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Adopting draft-williams-kitten-channel-bound-flag X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:10:12 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Fri, Jun 21, 2013 at 6:49 PM, Sam Hartman wrote: >> Nico, based on Shawn's consensus call, I believe we have >> consensus to adopt draft-williams-kitten-channel-bound-flag. >> >> based on discussions with Stephen today, we don't need to >> recharter to do that. So if you want to submit a 00, the chairs >> would be happy to approve. Nico> Oh, I thought I had a WG -00. I didn't, and I missed the Nico> deadline for that. No, you missed the fake deadline for that. If you can get it in and then make sure I approve it before the real 00 deadline everything should work fine. From nico@cryptonector.com Wed Jul 3 08:57:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6F11E81E8 for ; Wed, 3 Jul 2013 08:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRrCjLALsk5F for ; Wed, 3 Jul 2013 08:56:59 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5611E81CB for ; Wed, 3 Jul 2013 08:56:58 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id B928828606F for ; Wed, 3 Jul 2013 08:56:56 -0700 (PDT) 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=o0u74nhdLAwsbtOeoLbb cVXSxNk=; b=f/zMEMffF3ZzrvaOV/vUjOzhy3l84QD/1EUZeG6P5yUHDSm7m+s7 0bNV9G9aA8RrcJf2csEggODCP96jEvoPVAwB+DZ15Vb2TF10ptQx5B+LaRMwggAJ nOkOVIhVGygN/MQSP8DTc0ElfiU5NXSGWsxC4UaxDMkiJXj7DgLBQU8= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 993DB286079 for ; Wed, 3 Jul 2013 08:56:54 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so265401wes.24 for ; Wed, 03 Jul 2013 08:56:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XcpGVAUFizQ2qEDdCAzVx7rgxS8rZuHf0Sp92J90mkE=; b=nKRGR7eYiOLH+YdashhTXsTazyyV5bvFc9WKxy6GiJmbJAOjWfg1+WnXlqWtjbrBWT FVQHV3KuNhSyq8lqzEDVrh+gtdRVCxTcFcBPx6WYt6tTu+zzfCPzI86hz/AqPt7huFtz A3Hmn8+cuOf7zE3lXpKIj2VhaExBMvs9rQduvhpRzXaRna4EbXWqIxGGLT5OgwNzfi88 wJ5pp6wse63F/NvEcnIJDn3VAWy+vgt5SmAT1wHBhWxlNdgWIPRT9n9ESVUNttjutE/j gC1D/k+I63/1kB8fk1/yrXGWASLmfHrKXPJYffoSBeZi0FZt4rG7SNI8+SmZrNem+PmM sSHQ== MIME-Version: 1.0 X-Received: by 10.194.173.37 with SMTP id bh5mr1058783wjc.30.1372867012033; Wed, 03 Jul 2013 08:56:52 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 08:56:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 10:56:51 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Adopting draft-williams-kitten-channel-bound-flag X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 15:57:03 -0000 OK, I'll get it done today. BTW, I hate these deadlines. From nico@cryptonector.com Sun Jul 7 14:37:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC8B11E812F for ; Sun, 7 Jul 2013 14:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16-RgQi1mZlI for ; Sun, 7 Jul 2013 14:36:58 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21011E8114 for ; Sun, 7 Jul 2013 14:36:58 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id BDEA726C05E for ; Sun, 7 Jul 2013 14:36:57 -0700 (PDT) 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=TWDKetiEDO4zACatQULujhRRGFY=; b=jTzIIK2lo7h 9KYc6UwIvbeVQl+fffJELA46jVYwBDf6cyqSnmEZBTwRyLoFVUnHxPzR2uQDUMYL Z9TMOzaM057RHjBDfXrKz1KyPbKIm3mScfpv3BtzVxVFPq5BMAmqmb4VrPMHeBNj CTGXQCS8rRfZ5q1Xc9MASVO+zEGlAP5I= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 6545C26C05B for ; Sun, 7 Jul 2013 14:36:57 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so3149115wes.19 for ; Sun, 07 Jul 2013 14:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=umx705CY9VtWAKmDXX2QG+I2EbeFx7BErkykUoAZIS0=; b=nqYZjvlOEvF3YTdHa8VVZrRhwuUHluM9RhgwER2lk0pbm+LjOnDv9ZOC/+VpL0DBSH CHDaf/fZ9qb65xZ8zPEpGaDMS6c74q+/wi1RSfjNpSqu4v7Pci7AM1JMTiviSJul5XQ2 my5eyMawXNcc3E6B0watAs2yuLSwVxRjzTylgGvHPMkOLUuxf0NHhuz7C5y6WHIQNvet uFAk134EInZXYqTuuJoNLtkpuRKNZRC8xnbC4jsQTe15aqXuMNAIgoupmQO8iisW8Bsx YAbB+qfBTdKCn9OJ6CTNTvL1BQRsulB7kY0vdYCZ+G86uAxXFrEaahYbk9PMZj9Hr4UX 96sQ== MIME-Version: 1.0 X-Received: by 10.194.20.97 with SMTP id m1mr10574793wje.31.1373233015503; Sun, 07 Jul 2013 14:36:55 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sun, 7 Jul 2013 14:36:55 -0700 (PDT) Date: Sun, 7 Jul 2013 16:36:55 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] New I-Ds: channel bound flag and simple + async API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 21:37:03 -0000 I've just submitted: - draft-ietf-kitten-channel-bound-flag-00 (pending chair approval) - draft-williams-kitten-ctx-simple-async-00 The latter really ought to be a working group item, but the charter does not mention it. We should probably re-charter to include: - extensions that result in API simplification - async functionality - maybe even interaction functionality (e.g., for IAKERB, ABFAB) (this is probably more controversial, if only because it's really difficult to design a decent and generic API for user interaction) Nico -- From nico@cryptonector.com Sun Jul 7 15:47:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FA021F9CC4 for ; Sun, 7 Jul 2013 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHwPY8R4amVR for ; Sun, 7 Jul 2013 15:47:47 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0F21F9D0A for ; Sun, 7 Jul 2013 15:47:42 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 1848126C05E for ; Sun, 7 Jul 2013 15:47:41 -0700 (PDT) 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=LhpR8+Cxdb8f6VeX3ry5wg23l9s=; b=QZ0NwWCvh1l qNCy2+ivNhWlGcKJkyDibPCFbmJ4oE8c9QWk8ItTuIbXBnpRl2FFABiroZBWzMv7 YOFjspzLlzQuCVrSNvsqVfo+iIgE2F6VH+v0jcBLj6oy3hGPnRUY5P/VvJKvyuTk ssDUPZcudfCiki9epdHq0eCbFDrUIVrM= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id B01A626C05B for ; Sun, 7 Jul 2013 15:47:40 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so3132552wes.21 for ; Sun, 07 Jul 2013 15:47:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=18V2+aYjozbudehowaLi0yOlzP/cFwsqNsHe01WRzRA=; b=FUDPgPea/dbdRowOVg1ucdBp0l4d/Kx/GlO6YMRE0OZaHhZbMgsigwh/Z8Ld+lRBJV LfRYDJ0ZlltmGege5rzfnhXgzoIMfnHHXa1+v0Mlm2DrBBuO9izoepFQsyJuuv68cNNJ cnqfICbHsU/FjjSg6fxUUgk+Zvn93EmDSxgJluvysIFZsG2RdRbmgIQlxGMOYLCMLr0e 2PU2ZXXGvlqeg5Sk6MrqDMls4WHPyeKHsCbv3YLEHncRl6X7sOULOvDln7IQ4X5TWY3u wnsyYN3RGe+3uFojgsdbb6MeGrBK3+caTJCdPnlxfREu8f6MwlJNyt5Q6/toCnq1mB3s TPyQ== MIME-Version: 1.0 X-Received: by 10.180.75.144 with SMTP id c16mr30545410wiw.1.1373237258737; Sun, 07 Jul 2013 15:47:38 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sun, 7 Jul 2013 15:47:38 -0700 (PDT) Date: Sun, 7 Jul 2013 17:47:38 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] New I-D: generic name attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 22:47:51 -0000 I've just posted draft-williams-kitten-generic-naming-attributes-00 An implementation can be found here: https://github.com/nicowilliams/heimdal/tree/name_attrs-rebase1 I believe these should be rather useful. A common use case would be to authorize host-based initiator principals by hostname. Future name attributes that could be added include: - the PAC/PAD - SIDs/UIDs/GIDs of the principal - ... From internet-drafts@ietf.org Sun Jul 7 19:11:07 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFAD11E817A; Sun, 7 Jul 2013 19:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un7PzHJHOw4n; Sun, 7 Jul 2013 19:11:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6A311E8176; Sun, 7 Jul 2013 19:11:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708021106.14072.49434.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2013 19:11:06 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 02:11:07 -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 : Channel Binding Signalling for the Generic Security Serv= ices Application Programming Interface Author(s) : Nicolas Williams Filename : draft-ietf-kitten-channel-bound-flag-00.txt Pages : 13 Date : 2013-07-07 Abstract: Channel binding is a technique that allows applications to use a secure channel at a lower layer without having to use authentication at that lower layer. The concept of channel binding comes from the Generic Security Services Application Programming Interface (GSS- API). It turns out that the semantics commonly implemented are different that those specified in the base GSS-API RFC (RFC2743), and that that specification has a serious bug. This document addresses both, the inconsistency as-implemented and the specification bug. This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior reflecting existing implementation deployments, and a behavior that is only safe when the application specifically tells the GSS-API that it (the application) supports the new behavior. Additional API elements related to this are also added, including a new security context establishment API. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-channel-bound-flag There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tlyu@mit.edu Tue Jul 9 16:46:35 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9254321F9CAE for ; Tue, 9 Jul 2013 16:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XcT4Hai6GpP for ; Tue, 9 Jul 2013 16:46:29 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id E660A21F9C72 for ; Tue, 9 Jul 2013 16:46:28 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-9e-51dca0d47882 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B8.D8.02471.4D0ACD15; Tue, 9 Jul 2013 19:46:28 -0400 (EDT) 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 r69NkRae030955 for ; Tue, 9 Jul 2013 19:46:28 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r69NkPl7020540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Jul 2013 19:46:26 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r69NkPiR001659; Tue, 9 Jul 2013 19:46:25 -0400 (EDT) To: kitten@ietf.org References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> From: Tom Yu Date: Tue, 09 Jul 2013 19:46:25 -0400 In-Reply-To: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 28 Jun 2013 10:30:17 -0700") Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixG6nrntlwZ1Agx9/JC2Obl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHObNrIVbOSvOPx/MlMD4wmeLkZODgkBE4mf/0+zQthiEhfu rWfrYuTiEBLYxyix7vg6KOcYo8TuBavZIZzHTBLNO95DZToZJRY/+cME0i8iICyxe+s7ZhBb WCBP4v7sqywgtpCAg8T2ybsYuxg5ONgEpCWOLi4DCbMIqEpsufAPbCinQDejxNOmNWwgCV4B C4kf91sYQWweAU6JvhX9LBBxQYmTM5+A2cwCWhI3/r1kmsAoMAtJahaS1AJGplWMsim5Vbq5 iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxhBAcgpybeD8etBpUOMAhyMSjy8BxTuBAqxJpYV V+YeYpTkYFIS5Z03ByjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhDd2NlCONyWxsiq1KB8mJc3B oiTO++zp2UAhgfTEktTs1NSC1CKYrAwHh5IEryow0oQEi1LTUyvSMnNKENJMHJwgw3mAhguB 1PAWFyTmFmemQ+RPMSpKifOygiQEQBIZpXlwvbAE8YpRHOgVYV4tkCoeYHKB634FNJgJaPCe FLDBJYkIKakGRomsjo0JR/0CLDKcZublTy7967rbNfZ1nj7/ulWNJ9e/y/3XwHpO/vabX0Vz bXP3vJb//OmH8/2H1/tDX+lc3aNqIqy8InBbZf6dHW8uL0jbu0joy79bLs3HXu2UiNinsejg tik2So/u+XV3JVwwW7U6a8UVBenoZy8apKT4S74qHPIqWXFg2iklluKMREMt5qLiRAAWYqOF 6wIAAA== Subject: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 23:46:35 -0000 I've looked at the diff against the previous version of this document. Most of the changes look reasonable to me, but the special case handling of short plaintexts seems too complicated from an implementation perspective. I'd prefer to go back to the more widely accepted practice of CBC mode with explicit IV and PKCS#7-ish padding. It seems that one of the goals of this effort is to use, as much as possible, the off-the shelf capabilities of cryptographic modules that are validated to FIPS 140-2 or other relevant standards. As far as I know, few (if any) validated cryptographic modules support CTS mode directly. At this point, I think it is useful to try moving away from CTS: the benefits of CTS do not outweigh the implementation complexity, particularly when dealing with the short plaintext case. Implementing CTS mode has already proven to be a challenge even for the existing AES-CTS enctypes, and I'm reluctant to magnify that difficulty with the new enctypes in this document. Returning to a scheme based on conventionally padded CBC would further the goal of using the existing capabilities of validated cryptographic modules, and poses fewer implementation risks. Statements from Microsoft imply that the main problems caused by variable-length ciphertext expansion would be limited to SSPI applications that do not use the APIs correctly. SSPI functions exist such that an application can use to obtain the required lengths for use with the in-place encryption functions. I realize we've spent a significant amount of effort trying to make CTS work in the short-plaintext case. I'd like to thank to Nico, Kelley, and others who participated in trying to make CTS mode work in this specification. Looking at this document as an implementer, I think using CTS mode, especially with the short-plaintext special case, presents too much risk, and I'd like us to consider going back to a more normal CBC mode. From lukeh@padl.com Tue Jul 9 16:53:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0187F21F9C4D for ; Tue, 9 Jul 2013 16:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp0LuqcLpj5I for ; Tue, 9 Jul 2013 16:53:15 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id AC26E21F9CC1 for ; Tue, 9 Jul 2013 16:53:11 -0700 (PDT) Received: by us.padl.com with ESMTP id r69Nr0ww014288; Tue, 9 Jul 2013 19:53:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: Date: Wed, 10 Jul 2013 09:52:59 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> To: Tom Yu X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,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] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 23:53:31 -0000 The objection to CTR mode is because there is no maximum message size = and the counter may wrap, or something else? -- Luke= From tlyu@mit.edu Tue Jul 9 17:01:49 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A8321F9C86 for ; Tue, 9 Jul 2013 17:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hU17JFoskhS for ; Tue, 9 Jul 2013 17:01:43 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2705521F9C87 for ; Tue, 9 Jul 2013 17:01:42 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-34-51dca466626e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 26.91.02359.664ACD15; Tue, 9 Jul 2013 20:01:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r6A01fPs030825; Tue, 9 Jul 2013 20:01:42 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6A01dfr024321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jul 2013 20:01:41 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r6A01dCE001709; Tue, 9 Jul 2013 20:01:39 -0400 (EDT) To: Luke Howard References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> From: Tom Yu Date: Tue, 09 Jul 2013 20:01:39 -0400 In-Reply-To: (Luke Howard's message of "Wed, 10 Jul 2013 09:52:59 +1000") Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nopu25E6gwYtjchZHN69isbh76T+7 A5PHkiU/mTzmfpjGEsAUxWWTkpqTWZZapG+XwJXxdsoE9oJmlopdB/vZGxjnMncxcnJICJhI XH7yD8oWk7hwbz0biC0ksI9RovG6QhcjF5C9gVHi2oE1rBDOWSaJ4ydbmSGcTkaJ1s3rWEFa RAQUJCbvXws2illAWGL5mrNgo4QFiiSe/m+EaljIKLHiznUgh4ODTUBa4ujiMpAaFgFViQk3 VrOA2JwClRL7991iArF5BSwkpp1ZARbnEeCU+DT1CjtEXFDi5MwnLBC7tCRu/HvJNIFRcBaS 1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCQpVTkncH47uDSocY BTgYlXh4DyjcCRRiTSwrrsw9xCjJwaQkyuuzECjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhDd2 NlCONyWxsiq1KB8mJc3BoiTO+/Tp2UAhgfTEktTs1NSC1CKYrAwHh5IEr8VioEbBotT01Iq0 zJwShDQTByfIcB6g4TEgNbzFBYm5xZnpEPlTjIpS4rxBIAkBkERGaR5cLyyVvGIUB3pFmLcY pIoHmIbgul8BDWYCGrwnBWxwSSJCSqqBcdIxQ8O9SlvW7UyK2pZ2VZA9L6vL1t7bbu87Xf+c hAmSml9P3zO5lP5KrWiH5P427zkz/y7+c/1U5dNLmsVTo6xnTd7j1fuh/O6EzHnOqfFhF6vV 82VVypMXns1wPBKqu0287eFWd2GmY0fkpfujHltz/8jelpw3aa9I1q+O0EjpDe9TOtMtlViK MxINtZiLihMB8OwP0QADAAA= Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 00:01:49 -0000 Luke Howard writes: > The objection to CTR mode is because there is no maximum message size and the counter may wrap, or something else? I'm not sure whether plain CTR mode (with HMAC?) was proposed. GCM and CCM each have multiple problems, especially when used with long-term keys. Repetition of a GCM IV can lead to forgeries, and I think there were length encoding issues in both GCM and CCM. I'd have to check the archives for details, but I think we discussed them extensively. From stpeter@stpeter.im Wed Jul 10 12:01:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18721F8808; Wed, 10 Jul 2013 12:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wskkcO8VVZHn; Wed, 10 Jul 2013 12:01:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 94CD421F8D0D; Wed, 10 Jul 2013 12:00:44 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EE87E413F5; Wed, 10 Jul 2013 13:01:49 -0600 (MDT) Message-ID: <51DDAF59.4040800@stpeter.im> Date: Wed, 10 Jul 2013 13:00:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:01:43 -0000 On 7/2/13 5:20 PM, Nico Williams wrote: > On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre wrote: >> On 5/3/13 1:39 PM, Nico Williams wrote: >> >>> Please forgive my apparent apathy. I lost track of this due to >>> business travel. >> >> And please forgive my delay in replying. It's good to know you're not >> apathetic. And as you can tell, we're proceeding rather slowly with >> this work. That doesn't mean it is unimportant. This recent example >> from the blogosphere might of interest: >> >> http://labs.spotify.com/2013/06/18/creative-usernames/ >> >> PRECIS might have helped those folks avoid some significant pain. >> >>> I'm not sure where the case mapping requirement for usernames came >>> from. >> >> Are you referring to global case mapping or local case mapping? >> >>> I guess it has something to do with the Turkish I and such. >> >> Yes, that is a nasty problem with even nastier consequences: >> >> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail > > ! > > But that can't apply here. Or, if anything, case mappings makes it > more likely. Let's say I'm logged in in some app and it shows the > username I typed in, but because of case mapping some typos are > tolerated, so the username shown could offend someone. Whereas if I'm > required to type my username exactly one way (not including NF) then > that can't happen. So if anything that link indicates we should not > have case mappings here... :) > >> Just to be clear, that's an issue of what we're calling local case >> mapping (where locale is taken into consideration). >> >>> I can't say I'm excited about this case mapping requirement; if >>> anything it strikes as silly. >> >> In general, the opinion so far has been that, say, StPeter is treated >> the same as stpeter when it comes to authentication and authorization >> based on usernames. Do you disagree? If so, why? For example, would >> you be inclined to leave this up to the protocol that uses SASL (say, >> IMAP or XMPP) instead of specifying it in SASLprepbis? > > I think it'd be nice if *servers* got to choose whether to do this. > The principle here is that the server should make right when it comes > to the username. This means that clients should be pretty much able > to send just about anything as a username and let the server figure it > out. > > Whether it's a server application or the mechanisms (or SASL library) > that applies such rules is a different story, and one I don't think I > care much about here. Ah, I see. It seems to me that there are numerous layers here: 1. SASL (including preparation and comparison rules) 2. The application protocol that's using SASL (e.g., IMAP) 3. A software implementation of the application protocol, which likely embeds or links to a SASL implementation (e.g., dovecot) 4. A deployment of said software implementation (e.g., example.net) By "server" I think you mean a deployment. Correct? Rather than legislating in saslprepbis that all application protocols shall leave casemapping up to implementations or deployments, I think that it would be reasonable for the specification of an application protocol using SASL (e.g., draft-ietf-xmpp-6122bis) to recommend or require casemapping behavior for all implementations or deployments of that application protocol, or to leave such decisions up to the implementation or deployment. For example, perhaps the XMPP spec would say "all implementations shall perform case mapping, full stop" whereas the IMAP spec might leave that up to implementations or deployments. >>> Why would we apply mappings to usernames (which are sent on the >>> wire) that we don't apply to passwords (which servers generally >>> don't get the plaintext of)? We need mappings for passwords to >>> make password entry reliable. The same does NOT apply to >>> usernames. >> >> My naïve perspective is that the combination of username and password >> is your credential (for password-based systems). If I provide StPeter >> and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure >> want the password to be treated in a case-sensitive manner (since that >> reduces the possibility of false positives), whereas we want the >> username to be treated in a case-insensitive manner (since most >> application protocols treat StPeter@example.com as the same account as >> stpeter@example.com). > > It's not just false positives: many sites require multiple character > classes in password data, but case folding would nullify part of such > policies :) Indeed! > If the user's password must survive with case intact then the user > must be able to enter it portably (i.e., on many devices). Surely > asking the same of usernames is not an undue additional burden for the > user. > > Still, I don't mind if some site wants to have case-insensitive > usernames. I just don't want us to impose that policy on *all* sites. I now agree that I don't want the SASLprepbis spec to impose that policy on all sites, but I also don't think that I want the SASLprepbis spec to impose deployment-layer policies on all application protocols. However, I do think it's reasonable for the SASLprepbis spec to say "specifications for application protocols that use SASLprepbis must specify the casemapping policy for that application protocol; options include but are not limited to legislating behavior for all implementations or leaving casemapping up to particular deployments". > Once again I'm thinking of online games, ones where people often > convey ideas (usually comical ones) via their usernames. Providing > the most freedom possible here seems like the right thing to do; > requiring case-insensitivity is denying some freedom. The SASLprepbis document is about comparison and what gets sent over the wire. An application might preserve case for user interface purposes but still lowercase "StPeter" to "stpeter" for comparison purposes during authentication. See also the nickname spec (what you're talking about sounds more like a nickname or screen name than a username, but that might be a distinction without a difference): http://tools.ietf.org/id/draft-ietf-precis-nickname-05.txt >>> Also, looking at SASLprep and PRECIS, I see no mention of query >>> strings vs. display vs. storage. These distinctions matter. But >>> maybe I'm just failing to search for the right terms. >> >> Would you be so kind as to expand on that a bit? I'd like to make sure >> I understand what you mean by each of those terms. > > Sure. > > Query string == a string entered by a user in some UI, to be matched > against some thing's name. > > Display string == a thing's name, as displayed to users in UIs. > > Storage string == a thing's name as stored, and usually this is the > canonical form of the thing's name. > > For example, "nico" might be a query name for my Kerberos principal, > but the display name might be nico@CRYPTONECTOR.COM, and the storage > string will be in some format we don't really care about here but > roughly equivalent to the display string form. > > To continue the example, if my KDC was case-insensitive then "Nico" > would also work as a query string; what I get for the display string > might either match the query string or the storage string, and the > storage string could be any of the many case variants of "nico" (but > almost certainly would be case-folded in many implementations). > > The relevance here is that we should apply as few transformations as > possible to *query* strings on the client-side and just send them. > What transformations a server applies then can be up to the server > and/or the mechanism (e.g., a federated mechanism might need to apply > transformations specified by it). > > SASLprep-like stringpreps are very useful, especially for *passwords* > because passwords may need to be in canonical form because they are > used as inputs to client-side cryptographic functions (e.g., Digest). > But they are less relevant for usernames, unless they too are used as > inputs to client-side cryptographic functions (e.g., as salts), but > even then the username query string might still be sent as-is > separately to the server. Thanks for clarifying. >>> Heck, we're not even told whether these rules should be applied by >>> the client, the server, or both. >> >> That is a very good point. This was something that bit us in RFC 3920 >> (for XMPP) and we've cleared that up in 6122bis: > > This is where the distinction between query, display, and storage (or > canonical) forms comes in. Yes. >> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3 >> >> In my experience, we can *say* that the client needs to do this, but >> the server will need to do it anyway since it can't trust the client >> to do the right thing. However, for passwords (which, as you note, we >> hope the server never sees in plaintext) the client would need to >> enforce the rules. > > Correct, as to the last part. I don't think we need the client to > apply this to anything that isn't an input to a cryptograhic function > on the client-side -- just send the darned thing as is. > >>> Anyways, I'm for applying as few transformations as possible to >>> usernames on the *client* side and leaving the server to apply >>> RECOMMENDED, and a few REQUIRED rules for matching. >> >> I'd agree with that sentiment. > > Great. > >>> I don't see room for case folding in general, >> >> Even on the server side? Again, do you think it would be better to >> leave that up to the application? > > I'd leave it to the site/mechanism/app -- whatever's appropriate. OK, good. That's consistent with what I typed earlier in this message. >>> but I do for specific cases (e.g., Turkish I handling). >> >> Unfortunately, local case mapping might be difficult for the server to >> perform because it doesn't necessarily have information about the >> locale of the user. So this is something that might best be handled at >> the client. > > Ah, well, if we're dealing in Unicode we could send a language tag in > the string. That's a non-starter. > > But note that the server probably has a username database anyways, so > it knows the relevant language at account-creation time (or should > anyways). Quite possible. In XMPP the client can tell the server its locale, but that might not be supported yet in other application protocols... Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 10 13:49:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE06421F9E85; Wed, 10 Jul 2013 13:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS6+WdMbYZur; Wed, 10 Jul 2013 13:49:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8B21F9E7C; Wed, 10 Jul 2013 13:49:34 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8EA8413F5; Wed, 10 Jul 2013 14:50:32 -0600 (MDT) Message-ID: <51DDC8D3.5060808@stpeter.im> Date: Wed, 10 Jul 2013 14:49:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> In-Reply-To: <51DDAF59.4040800@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:49:39 -0000 Hi Nico, I've looked at this a bit further. Proposed text changes below... On 7/10/13 1:00 PM, Peter Saint-Andre wrote: > On 7/2/13 5:20 PM, Nico Williams wrote: >> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >> wrote: >>> On 5/3/13 1:39 PM, Nico Williams wrote: >>> >>>> Please forgive my apparent apathy. I lost track of this due >>>> to business travel. >>> >>> And please forgive my delay in replying. It's good to know >>> you're not apathetic. And as you can tell, we're proceeding >>> rather slowly with this work. That doesn't mean it is >>> unimportant. This recent example from the blogosphere might of >>> interest: >>> >>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>> >>> PRECIS might have helped those folks avoid some significant >>> pain. >>> >>>> I'm not sure where the case mapping requirement for usernames >>>> came from. >>> >>> Are you referring to global case mapping or local case >>> mapping? >>> >>>> I guess it has something to do with the Turkish I and such. >>> >>> Yes, that is a nasty problem with even nastier consequences: >>> >>> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail >> >> >>> ! >> >> But that can't apply here. Or, if anything, case mappings makes >> it more likely. Let's say I'm logged in in some app and it shows >> the username I typed in, but because of case mapping some typos >> are tolerated, so the username shown could offend someone. >> Whereas if I'm required to type my username exactly one way (not >> including NF) then that can't happen. So if anything that link >> indicates we should not have case mappings here... :) >> >>> Just to be clear, that's an issue of what we're calling local >>> case mapping (where locale is taken into consideration). >>> >>>> I can't say I'm excited about this case mapping requirement; >>>> if anything it strikes as silly. >>> >>> In general, the opinion so far has been that, say, StPeter is >>> treated the same as stpeter when it comes to authentication and >>> authorization based on usernames. Do you disagree? If so, why? >>> For example, would you be inclined to leave this up to the >>> protocol that uses SASL (say, IMAP or XMPP) instead of >>> specifying it in SASLprepbis? >> >> I think it'd be nice if *servers* got to choose whether to do >> this. The principle here is that the server should make right >> when it comes to the username. This means that clients should be >> pretty much able to send just about anything as a username and >> let the server figure it out. >> >> Whether it's a server application or the mechanisms (or SASL >> library) that applies such rules is a different story, and one I >> don't think I care much about here. > > Ah, I see. > > It seems to me that there are numerous layers here: > > 1. SASL (including preparation and comparison rules) > > 2. The application protocol that's using SASL (e.g., IMAP) > > 3. A software implementation of the application protocol, which > likely embeds or links to a SASL implementation (e.g., dovecot) > > 4. A deployment of said software implementation (e.g., > example.net) > > By "server" I think you mean a deployment. Correct? > > Rather than legislating in saslprepbis that all application > protocols shall leave casemapping up to implementations or > deployments, I think that it would be reasonable for the > specification of an application protocol using SASL (e.g., > draft-ietf-xmpp-6122bis) to recommend or require casemapping > behavior for all implementations or deployments of that application > protocol, or to leave such decisions up to the implementation or > deployment. For example, perhaps the XMPP spec would say "all > implementations shall perform case mapping, full stop" whereas the > IMAP spec might leave that up to implementations or deployments. Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: OLD 3. Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. NEW 3. Uppercase and titlecase characters MAY be mapped to their lowercase equivalents. Then add the following sentence at the end of that section: Application protocols that use this profile MUST specify whether case mapping or additional mapping is to be applied by implementations or deployments of that protocol. Does that seem acceptable? Peter -- Peter Saint-Andre https://stpeter.im/ From tlyu@mit.edu Wed Jul 10 14:04:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BAB21F9D69 for ; Wed, 10 Jul 2013 14:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBiiDyG7XLuU for ; Wed, 10 Jul 2013 14:04:24 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D07A21F9D4B for ; Wed, 10 Jul 2013 14:04:20 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-40-51ddcc53ebf8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 22.FF.02359.35CCDD15; Wed, 10 Jul 2013 17:04:19 -0400 (EDT) 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 r6AL4INn004916; Wed, 10 Jul 2013 17:04:19 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6AL4F9B017963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 17:04:17 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r6AL4Fo1004893; Wed, 10 Jul 2013 17:04:15 -0400 (EDT) To: Nico Williams References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <20130710002854.GB8773@gmail.com> From: Tom Yu Date: Wed, 10 Jul 2013 17:04:15 -0400 In-Reply-To: <20130710002854.GB8773@gmail.com> (Nico Williams's message of "Tue, 9 Jul 2013 19:28:56 -0500") Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrRt85m6gwdFHZhZHN69isbh76T+7 xalrR9gcmD1enjrH6LFkyU8mj7kfprEEMEdx2aSk5mSWpRbp2yVwZWzZMZOp4BRLxdY/fcwN jOeZuxg5OSQETCROPl/PBmGLSVy4B2JzcQgJ7GOUaLhylhHC2cgocX3bQVYI5xyTxPWva6HK uhgl3v46zQLSLyKgKXF93lKwWcwChhJ7nk9iBLGFBYoknv5vZIZo+MIocWbGOqAGDg42AWmJ o4vLQGpYBFQlfn/8AlbPKZAjcX9xG9gcXgELiVVtX5lAynkEOCVOTKmECAtKnJz5hAVilZbE jX8vmSYwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcPhK 8u5gfHdQ6RCjAAejEg+vRuzdQCHWxLLiytxDjJIcTEqivMGngEJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeE9OAcrxpiRWVqUW5cOkpDlYlMR5nz49GygkkJ5YkpqdmlqQWgSTleHgUJLg7TkN 1ChYlJqeWpGWmVOCkGbi4AQZzgM0vBOkhre4IDG3ODMdIn+KUVFKnLcXJCEAksgozYPrhaWX V4ziQK8I804HqeIBpia47ldAg5mABu9JuQMyuCQRISXVwGh3+afA/mtHJf1uHsxtSeGKs4no O/+G2aNQazPDOc7uJd3lqjO+zmVo2mPgHzajfa+E/gbRNK5z550rtrqynuYPvODqut7oB3+A acLvNRtWehybWfPjm8EpkaVF1bZm3Rcc1h946xThsHrm7zuTzUPfNWq8e/PY3ke0o8fTI8w1 lXWZ2yG5l0osxRmJhlrMRcWJAPvkUHUKAwAA Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:04:31 -0000 Nico Williams writes: > If we're going to use GCM/CCM then I would strongly prefer if we had a > key derivation method that uses a 256-bit IV to derive keys from > long-term keys (so that we can have enough bits for a nonce, a high-res > timestamp, a KDC or other ID, and a use counter). I don't think that's > a lot to ask for, but it will do more violence to existing > implementations than a non-confounded CTS mode would, so I would prefer > a non-confounded CTS mode, but it's a mild preference. I still think we should avoid GCM or CCM mode. From nico@cryptonector.com Wed Jul 10 14:20:53 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185CE21F9A30; Wed, 10 Jul 2013 14:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBTph78rDOOq; Wed, 10 Jul 2013 14:20:48 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2483221F99FA; Wed, 10 Jul 2013 14:20:48 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 14C0E678089; Wed, 10 Jul 2013 14:20:41 -0700 (PDT) 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=iduQE6CaJQL5QIfe2giP ql/rWXk=; b=Z94b2l3FWuZNEyAZWH58fuDfWPtQsQaU3Vj2HHWO6D8anh1f9P3f POJMzx1nsWWElLixc8OEfa8rEWkWtT3sYz6GckMTZuOXy50BaY4ni5bjcDvGKlXb qSBNQDBjYT8CU7hd/w2QwTEooB5Cb3ge7C7aB77hODTp1thhinAzENo= 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-a25.g.dreamhost.com (Postfix) with ESMTPSA id 028AB67808D; Wed, 10 Jul 2013 14:20:18 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so12904569wid.5 for ; Wed, 10 Jul 2013 14:20:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LABTzHsiRrtfmVtvWTjrzGDA5KQk5U4Lvcqd1pK/beU=; b=iRwnUdexvtUSdi8iboWJWlZ9IKdIeNNv84nLIxZmeAIm+p/aAVtF0mjBnRBQ18wLNL 0vAtO1x708yUIvLzjD+/SZ845SzkfldQx2dFoXExmoSWQLdAvdyRBCZqWVVHilH0pPE8 6wXOYOt2Q6akxPnTBUHcbNWMCDQpHqQnxqZXTIsUk/MgHIXA6SmPbkESYzsDAUSWCbYI 4UAyOrgs8c1WccPhRljlT+fjg93vLsLTMNRyxR3Dkt9gqWaQbJFvI97pVwwdSdAWIkW9 R++XGSmNjxiHj35pZKlj7DbJ9MTzYP65jdoQdGyFprslHulUsc5yt8NM9dAg0L1yGAPl w73g== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr18554445wjc.90.1373491217156; Wed, 10 Jul 2013 14:20:17 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 14:20:16 -0700 (PDT) In-Reply-To: <51DDAF59.4040800@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> Date: Wed, 10 Jul 2013 16:20:16 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:20:53 -0000 On Wed, Jul 10, 2013 at 2:00 PM, Peter Saint-Andre wrote: > On 7/2/13 5:20 PM, Nico Williams wrote: >> I think it'd be nice if *servers* got to choose whether to do this. >> The principle here is that the server should make right when it comes >> to the username. This means that clients should be pretty much able >> to send just about anything as a username and let the server figure it >> out. >> >> Whether it's a server application or the mechanisms (or SASL library) >> that applies such rules is a different story, and one I don't think I >> care much about here. > > Ah, I see. > > It seems to me that there are numerous layers here: Yes. Lots of layers. Consider SASL/GS1 and SASL/GS2 as well. > By "server" I think you mean a deployment. Correct? Generally, yes. > Rather than legislating in saslprepbis that all application protocols > shall leave casemapping up to implementations or deployments, I think > that it would be reasonable for the specification of an application > protocol using SASL (e.g., draft-ietf-xmpp-6122bis) to recommend or > require casemapping behavior for all implementations or deployments of > that application protocol, or to leave such decisions up to the > implementation or deployment. For example, perhaps the XMPP spec would > say "all implementations shall perform case mapping, full stop" whereas > the IMAP spec might leave that up to implementations or deployments. We could have: - apps specify whether to case fold - apps specify that the server can casefold if it wants That's fine with me. Note that the second comes naturally from speaking of query/display/store syntaxes. The client only deals in query and display syntaxes for usernames, so the server can make right. >> Still, I don't mind if some site wants to have case-insensitive >> usernames. I just don't want us to impose that policy on *all* sites. > > I now agree that I don't want the SASLprepbis spec to impose that policy > on all sites, but I also don't think that I want the SASLprepbis spec to > impose deployment-layer policies on all application protocols. However, > I do think it's reasonable for the SASLprepbis spec to say > "specifications for application protocols that use SASLprepbis must > specify the casemapping policy for that application protocol; options > include but are not limited to legislating behavior for all > implementations or leaving casemapping up to particular deployments". No, not MUST, but MAY is fine, and I might go along with SHOULD. First, we'd be informing authors of app protocol specs -- we can use RFC2119 language for that, but it's hard to enforce -- this language doesn't deal with interop. >> Once again I'm thinking of online games, ones where people often >> convey ideas (usually comical ones) via their usernames. Providing >> the most freedom possible here seems like the right thing to do; >> requiring case-insensitivity is denying some freedom. > > The SASLprepbis document is about comparison and what gets sent over the > wire. An application might preserve case for user interface purposes but > still lowercase "StPeter" to "stpeter" for comparison purposes during > authentication. The only party doing comparisons is the server, therefore the only party that should have to apply any sort of normalization should also be the server -- otherwise if the client also normalizes *prevents* some names from being useful/usable. Normalizations that preserve equivalence can be OK on the client side (e.g., Unicode normalization), but case folding loses information. This principle, that the party doing comparisons/lookups (because the server might be comparing hashes for all we know) is the party that should normalize, is a very useful principle here. It follows from distinguishing types of name syntax. If multiple parties have to do these comparisons/lookups *then* we may need to say more about who normalizes and when (and why). > See also the nickname spec (what you're talking about sounds more like > a nickname or screen name than a username, but that might be a > distinction without a difference): Remember that what I have in mind is a bevy of online games where users are free to pick usernames we'd *never* consider valid in an enterprise environment, like "Joe 6-pack (I'm the best)". (For an example you can see for yourself, download bzflag and play for a bit. It's an open source game with user-contributed maps, user-run servers, and so on. Its users tend to have weird names -- these aren't nicknames, they *are* the usernames, it's what you type in at login time.) >> I'd leave it to the site/mechanism/app -- whatever's appropriate. > > OK, good. That's consistent with what I typed earlier in this message. Well, except I want to be able to leave it to the server if the app protocol authors think that's fine. I don't want to prescribe that app protocols must prescribe which normalization the clients apply. I don't mind if some app protocols do. But I want it to be possible that the client doesn't have to. In fact, I'd prefer if SASL clients *never* had to normalize usernames *except* when they must use them for salting purposes (but still send the unmodified original as the actual username) -- it's far simpler and most flexible this way. >> Ah, well, if we're dealing in Unicode we could send a language tag in >> the string. That's a non-starter. >> >> But note that the server probably has a username database anyways, so >> it knows the relevant language at account-creation time (or should >> anyways). > > Quite possible. In XMPP the client can tell the server its locale, but > that might not be supported yet in other application protocols... Right, but I think the server still has enough context. In the worst case scenario it might have to try N different normalizations and lookups, but I kinda doubt N will ever be larger than 1. Nico -- From nico@cryptonector.com Wed Jul 10 14:31:08 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1F21F9BC1 for ; Wed, 10 Jul 2013 14:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRqcUou5bL1r for ; Wed, 10 Jul 2013 14:31:03 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id DDB5921F91B4 for ; Wed, 10 Jul 2013 14:30:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 89514674070 for ; Wed, 10 Jul 2013 14:30:48 -0700 (PDT) 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=sL/f8pdxLP9oMcS/LRfS i1cx8dA=; b=hMWwgXJOVihiuoNTdd/DFmQPRaPGjaXrx4FMEOkr/Umwtgayuqk7 um4a5NbgAObtL7z5yx5eqPJlG56hjAworEcIJYoJh6lQ+To47t3ZnCnSU8rb8PxR 3jQg0g4UbpQHJmBg65Lt6CEFOc6tWDrKjnnIs32gseVG8NPZclj0iLk= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 DC5A567406A for ; Wed, 10 Jul 2013 14:30:47 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so6264617wev.22 for ; Wed, 10 Jul 2013 14:30:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YNRtTlKjBOKwYxueIYac7u/vQbZEMU+orgJXZ+VvoeQ=; b=H1W/2liHqbJmyLX0SU3wbcHwWdxELZFUF/2KajVw3FZhSRVoP5RzIK+nxi+svE9rmZ n8GH/QhxFXg4Ks7Ys/miSJ/dVvNJsgHd+j5kL6VIkPof6bjsNJkbjzkm78zv3gC40PTI E1plrr9zPOtrWMfZ1ydDPMoIjd0yXw/39JyVvO3hFJmD/jfzlWDmx15XidwUEunmhyDA SE7b+6a9ZIra8QZIUlMYtZJLq0qksaY6obSF2p4tzKbTKlUacliZCvWK7OHm6DgwS+cO GNvSf6PcWOTSug0J4cpn3Ejgfg0g/kOKN/qn3A554/hinM90N89gLuChCVzOg9tuCpci plIw== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr19543851wjn.23.1373491846308; Wed, 10 Jul 2013 14:30:46 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 14:30:46 -0700 (PDT) In-Reply-To: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 16:30:46 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:31:08 -0000 On Tue, Jul 9, 2013 at 6:46 PM, Tom Yu wrote: > I've looked at the diff against the previous version of this document. > Most of the changes look reasonable to me, but the special case > handling of short plaintexts seems too complicated from an > implementation perspective. I'd prefer to go back to the more widely > accepted practice of CBC mode with explicit IV and PKCS#7-ish padding. > > It seems that one of the goals of this effort is to use, as much as > possible, the off-the shelf capabilities of cryptographic modules that > are validated to FIPS 140-2 or other relevant standards. As far as I > know, few (if any) validated cryptographic modules support CTS mode > directly. > > At this point, I think it is useful to try moving away from CTS: the > benefits of CTS do not outweigh the implementation complexity, > particularly when dealing with the short plaintext case. Implementing > CTS mode has already proven to be a challenge even for the existing > AES-CTS enctypes, and I'm reluctant to magnify that difficulty with > the new enctypes in this document. Returning to a scheme based on > conventionally padded CBC would further the goal of using the existing > capabilities of validated cryptographic modules, and poses fewer > implementation risks. I'm not at all worried about implementation risks. We can test every possible plaintext length between the shortest (zero-bytes) and a small multiple of the block size (in bytes), both with test vectors and random data (making sure it round-trips). I think the only risk we should be concerned about here is the risk that we might design-in a cryptographic weakness. I definitely don't want to be even partly to blame for that :) so it's a risk that bothers me. I think we can analyze the non-confounded CTS we came up with, and we could/should/must ask for review by strong cryptographers before we go forward with it (or otherwise we must show that the new thing must have the same properties as the old confounded CTS, which I think we informally did, but we'd have to redo that analysis). Another risk I care about is the risk that we lose some hardware optimizations as a result of using CTS. Though with the trend towards on-die hardware cipher implementations that problem becomes much less relevant. > Statements from Microsoft imply that the main problems caused by > variable-length ciphertext expansion would be limited to SSPI > applications that do not use the APIs correctly. SSPI functions exist > such that an application can use to obtain the required lengths for > use with the in-place encryption functions. This was a big deal to them once. It might still be. It'd be nice to hear from someone at Microsoft as to whether this is still an issue. > I realize we've spent a significant amount of effort trying to make > CTS work in the short-plaintext case. I'd like to thank to Nico, > Kelley, and others who participated in trying to make CTS mode work in > this specification. Looking at this document as an implementer, I > think using CTS mode, especially with the short-plaintext special > case, presents too much risk, and I'd like us to consider going back > to a more normal CBC mode. I'll be fine with ditching the no-padding requirement if the implementors we've known to care for no-padding modes are ok with it now and no new ones show up to tell us otherwise. Nico -- From tlyu@mit.edu Wed Jul 10 15:24:34 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61EC21F9CC5 for ; Wed, 10 Jul 2013 15:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi3m47aAdw6t for ; Wed, 10 Jul 2013 15:24:28 -0700 (PDT) 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 0A56B21F9B5B for ; Wed, 10 Jul 2013 15:24:27 -0700 (PDT) X-AuditID: 1209190c-b7fa48e000000947-4b-51dddf1a657b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.DE.02375.A1FDDD15; Wed, 10 Jul 2013 18:24:26 -0400 (EDT) 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 r6AMOPKf025252; Wed, 10 Jul 2013 18:24:26 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6AMONLe011783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 18:24:25 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r6AMONGm005090; Wed, 10 Jul 2013 18:24:23 -0400 (EDT) To: Nico Williams References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> From: Tom Yu Date: Wed, 10 Jul 2013 18:24:23 -0400 In-Reply-To: (Nico Williams's message of "Wed, 10 Jul 2013 16:30:46 -0500") Message-ID: Lines: 59 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrit1/26gwfZjZhZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXx//5jtoLf4hUzTzawNTDOFe5i5OSQEDCR mPxqDjOELSZx4d56ti5GLg4hgX2MEoffrGaCcDYyStx8fo0VwjnHJLHp2Rkop4tRYv2FRnaQ fhEBTYnr85aygdjMAsISy9ecBbOFBYoknv5vBNshJLCNUeLcJJkuRg4ONgFpiaOLy0DCLAKq Et2bDoDN5BSYwCjxb/EbsJm8AhYSr68eZQOp5xHglFiyNB4iLChxcuYTFohVWhI3/r1kmsAo OAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBocopybOD8c1B pUOMAhyMSjy8DfF3A4VYE8uKK3MPMUpyMCmJ8grdAwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4T05BSjHm5JYWZValA+TkuZgURLnffr0bKCQQHpiSWp2ampBahFMVoaDQ0mCNwxkqGBRanpq RVpmTglCmomDE2Q4D9BwsBre4oLE3OLMdIj8KUZdjslnt7xnFGLJy89LlRLnVQMpEgApyijN g5sDSzGvGMWB3hLmTQKp4gGmJ7hJr4CWMAEt2ZNyB2RJSSJCSqqBkWXmlusHPj7bE165rzh9 WTtf7+bWi9OaZE7b7ZfaIKCv4bwk436Y4S5h7uXssTzrme2kDyVNCf38+9PUHQ19pnwhmtKZ M6fr60deYrvlOU3uWOTql1ea7UR/ny7s7GfP/JFSJLqR6e0e4f3zmuIf8M7gfsXJn6Z3vPTL vKrgzgmstyL2NF/+rcRSnJFoqMVcVJwIAD8lbHYMAwAA Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:24:34 -0000 Nico Williams writes: > I'm not at all worried about implementation risks. We can test every > possible plaintext length between the shortest (zero-bytes) and a > small multiple of the block size (in bytes), both with test vectors > and random data (making sure it round-trips). I think it's still unavoidably more code, which carries its own risks. > I think the only risk we should be concerned about here is the risk > that we might design-in a cryptographic weakness. I definitely don't > want to be even partly to blame for that :) so it's a risk that > bothers me. I think we can analyze the non-confounded CTS we came up > with, and we could/should/must ask for review by strong cryptographers > before we go forward with it (or otherwise we must show that the new > thing must have the same properties as the old confounded CTS, which I > think we informally did, but we'd have to redo that analysis). The new CTS constructions are different from what we use for the current aes-cts-hmac enctypes, and the short-plaintext special cases are even more different. If we can make a cryptographic best practice (CBC with padding, encrypt-then-MAC, explicit random IV, etc.) work for us, I think that would be better from a cryptographic risk standpoint. I'd rather use a construction that's been analyzed extensively in the literature than use something we invented and maybe had some cryptographers (even if they're good ones) glance at briefly. > Another risk I care about is the risk that we lose some hardware > optimizations as a result of using CTS. Though with the trend towards > on-die hardware cipher implementations that problem becomes much less > relevant. It could still be a problem for validated hardware security modules, which I think would be a likely way for Suite B cryptography to be implemented in practice. > On Tue, Jul 9, 2013 at 6:46 PM, Tom Yu wrote: >> Statements from Microsoft imply that the main problems caused by >> variable-length ciphertext expansion would be limited to SSPI >> applications that do not use the APIs correctly. SSPI functions exist >> such that an application can use to obtain the required lengths for >> use with the in-place encryption functions. > > This was a big deal to them once. It might still be. It'd be nice to > hear from someone at Microsoft as to whether this is still an issue. No, I think some non-Microsoft WG participants once believed it to be a big deal for Microsoft, but we never had any confirmation from anyone at Microsoft that it was a problem (at least none that I could find). The most recent information that I have from Microsoft (from a few months ago in private mail) is that it would only be a problem for legacy applications that aren't using the SSPI correctly. > I'll be fine with ditching the no-padding requirement if the > implementors we've known to care for no-padding modes are ok with it > now and no new ones show up to tell us otherwise. Thanks. From nico@cryptonector.com Wed Jul 10 15:33:48 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24A811E8141 for ; Wed, 10 Jul 2013 15:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfYFmwlqKQnd for ; Wed, 10 Jul 2013 15:33:44 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C807311E813D for ; Wed, 10 Jul 2013 15:33:40 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 2FF8020203C for ; Wed, 10 Jul 2013 15:33:40 -0700 (PDT) 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=xAK4p+b4KZsKWmAMC3WX NTlSvRs=; b=SVer9FZBVTAMJHwJAmdR+gxnQngpccpZV09//UJoYKVWJKGpKjAU jB1sewv8JxrZik/mWI5Sb4CdYPVAB0sM/3dFnA3PV4SwufVJSsAmf3tzeK6lMmEP ++xLuG4la0Ze4g8X74fXEbUV6IvsFCIuvCKRdUEPwwYo87Rm+VCVLJI= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 989B1202018 for ; Wed, 10 Jul 2013 15:33:39 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so6312458wgh.18 for ; Wed, 10 Jul 2013 15:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O0Quk1ph19Bi64yi9wN6p+tILqI0uutdKVDaLd9udKg=; b=SPyebu7hMv9mxZw4iBU/3cUXsmrAF5UOutg1AmCWLzaj3zb1yejPp/2zA3KbxPN4IL GNHY/Y2Wnyb7jOhJFtN5I2WqYvyKZiqwVKzMO7n4QEDr95QIc1PLMYfhhAFNoNWDVMHF 7QCtxPaeYukRJ9x0hDfxxyH+sNd4TUN7gFPWiUl/Bykzlbu5zTX5ugQnYvXv1Jc2NuXW pWKyB1rf5/WyAH0cEARDkJZyg/rdufEyDMAcQuqm2BLWB4w4c5c8MvI5wZVx47FX0yrA GJbKu5jmKMyzc0kDuwApIhkFNcXtbvBLe9gtPv5S5Qs6SF7HdzzSEyODt4M629y00qV5 qv5w== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr19673224wjn.23.1373495617978; Wed, 10 Jul 2013 15:33:37 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 15:33:37 -0700 (PDT) In-Reply-To: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 17:33:37 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:33:49 -0000 On Wed, Jul 10, 2013 at 5:24 PM, Tom Yu wrote: > Nico Williams writes: > >> I'm not at all worried about implementation risks. We can test every >> possible plaintext length between the shortest (zero-bytes) and a >> small multiple of the block size (in bytes), both with test vectors >> and random data (making sure it round-trips). > > I think it's still unavoidably more code, which carries its own risks. It's code with very low rates of change. >> I think the only risk we should be concerned about here is the risk >> that we might design-in a cryptographic weakness. I definitely don't >> want to be even partly to blame for that :) so it's a risk that >> bothers me. I think we can analyze the non-confounded CTS we came up >> with, and we could/should/must ask for review by strong cryptographers >> before we go forward with it (or otherwise we must show that the new >> thing must have the same properties as the old confounded CTS, which I >> think we informally did, but we'd have to redo that analysis). > > The new CTS constructions are different from what we use for the > current aes-cts-hmac enctypes, and the short-plaintext special cases > are even more different. If we can make a cryptographic best practice > (CBC with padding, encrypt-then-MAC, explicit random IV, etc.) work > for us, I think that would be better from a cryptographic risk > standpoint. I'd rather use a construction that's been analyzed > extensively in the literature than use something we invented and maybe > had some cryptographers (even if they're good ones) glance at briefly. So you'd object to even the CTS mode we have in use today? >> Another risk I care about is the risk that we lose some hardware >> optimizations as a result of using CTS. Though with the trend towards >> on-die hardware cipher implementations that problem becomes much less >> relevant. > > It could still be a problem for validated hardware security modules, > which I think would be a likely way for Suite B cryptography to be > implemented in practice. Sure, but if they can be used in such a way as to use Suite B modes then the problem devolves to a performance problem. (The currently in-use CTS mode has this property.) >> On Tue, Jul 9, 2013 at 6:46 PM, Tom Yu wrote: > >>> Statements from Microsoft imply that the main problems caused by >>> variable-length ciphertext expansion would be limited to SSPI >>> applications that do not use the APIs correctly. SSPI functions exist >>> such that an application can use to obtain the required lengths for >>> use with the in-place encryption functions. >> >> This was a big deal to them once. It might still be. It'd be nice to >> hear from someone at Microsoft as to whether this is still an issue. > > No, I think some non-Microsoft WG participants once believed it to be > a big deal for Microsoft, but we never had any confirmation from > anyone at Microsoft that it was a problem (at least none that I could > find). The most recent information that I have from Microsoft (from a > few months ago in private mail) is that it would only be a problem for > legacy applications that aren't using the SSPI correctly. Oh! Well then, in that case to heck with CTS. Hurry! :) Nico -- From nico@cryptonector.com Wed Jul 10 15:37:12 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2411E8144; Wed, 10 Jul 2013 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcXCQZpteEtO; Wed, 10 Jul 2013 15:37:07 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8258611E8124; Wed, 10 Jul 2013 15:37:07 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id A025540122425; Wed, 10 Jul 2013 15:37:06 -0700 (PDT) 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=FpPp/OwLxlRo2gFKh12Z 8xAUimU=; b=azeIUAyoHm0jTfMX0vqREqPQ7bk/iDO+CoYXHaI67kFofV6bwN6w SFEsehocUWJHCVUBK7kCKD9gzHr8LyyY3cT+JEtzMsO80+UEYz2YwcTHspvydLgO D/BUXISfQohGNOrdmG+8JsIW1g2NuDIG1YC8GLTr8NXMiM7Kmmp2LPU= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 206924012241C; Wed, 10 Jul 2013 15:37:05 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so11957093wib.12 for ; Wed, 10 Jul 2013 15:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tze3ce0Qt5Hee+R1/X3HqY6oVMIgcDe6ypuNt5HGK5k=; b=o5ZXRlwqnAsnXlgvVgdDBAxTtIR8TpRVe590Gd1RebtQPMNoqYkyWahkPaxXyM+EBM rGdXLib4W2+MB1Hxr5Lm6H9hJ2m3GuYrRoQ8jofZ809IFyEq6nWE6cxherysml96NsZo owiKbPVQqCNtD5MYtL9np3FBDb4Mti/xu7S/x9AU/En88nrg3q6bleduHOAJfivtgQRa HUkXJaUKM6inmWsMc2qFS9wur6JQuGbQynzdd65MD79U94KZlruUhn5N00G4eHnsca4h x28H737GCR/zbVK26cbBJzAI+Rae2SmwWFCHaR8JL9yNMy4KaJH5j3aUqGNyyuhxCYhK j/AQ== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr18703595wjc.90.1373495824379; Wed, 10 Jul 2013 15:37:04 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 15:37:04 -0700 (PDT) In-Reply-To: <51DDC8D3.5060808@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> Date: Wed, 10 Jul 2013 17:37:04 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:37:12 -0000 On Wed, Jul 10, 2013 at 3:49 PM, Peter Saint-Andre wrote: > Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: > > OLD > 3. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. > > NEW > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. Do we need to give advice regarding the use of query strings for cryptographic protocols? E.g., usernames as salts. I think we do. Specifically, *mechanisms* must specify what normalizations (and let's provide a nice one for them to all use) for such purposes. > Then add the following sentence at the end of that section: > > Application protocols that use this profile MUST specify whether case > mapping or additional mapping is to be applied by implementations or > deployments of that protocol. > > Does that seem acceptable? Yes. Nico -- From nico@cryptonector.com Wed Jul 10 15:41:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE421F9CC2; Wed, 10 Jul 2013 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waIVwK7Djhvn; Wed, 10 Jul 2013 15:41:46 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id E49F821F9CBF; Wed, 10 Jul 2013 15:41:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 91778508072; Wed, 10 Jul 2013 15:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=jVYMAzIE+etpnZVZXMwwGBVOXx0=; b=aOB1g4X1Wal 0zelm8gp92mCFe/Z2wPe95yC87beYJhV4Ji7B3bdMJEx531V9bKVFeXRYcxC5iRf Y6kncLmEusRvoOHto9fNgxJ2SWhrEKElVYhAYA5Od8/ZILVc9QLOvp+EsnyA74Yl +HK6B369EG3o0YI20RciqtN/W5K3uRHY= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 19CF9508063; Wed, 10 Jul 2013 15:41:44 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so6432727wev.28 for ; Wed, 10 Jul 2013 15:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=skX79uj6vm5EdVWFb6wH3W0CE0/m/h9nD8JfX7q7dos=; b=Z9SaMhifEBpUAfn3b887qlsanp4kmM3/xBy2FHbhRi9hyIpQVOh/KqsrWpZ7yTPGX5 UcowRmPKiENDQBfKjM4ZeNTp+R+EXO3RcLpb9l6ClGKbkQSPD2q6PDCqbnXZGxOAOFzp w1qu4jcd8zMXwk8PaLB0777FKvY5fWRv5oknuv/ztRPfWeIg5PrIz8QuIRiR6/G1eAkU 63aOFlvDi/6e3FpANGVFRS4R4rqJbU3OIJluBjsd7QzGmnTAA7QCZiYnI01YsKbOYOIA SeqgfsmERT6VYVR7770oyx3GBFs20QTWOgQboUBjBo8GPn1E9f6ljLMwR5LfRB+1GOxb YBxg== MIME-Version: 1.0 X-Received: by 10.180.84.70 with SMTP id w6mr18243964wiy.36.1373496103676; Wed, 10 Jul 2013 15:41:43 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 15:41:43 -0700 (PDT) In-Reply-To: <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> Date: Wed, 10 Jul 2013 17:41:43 -0500 Message-ID: From: Nico Williams To: Marc Blanchet Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:41:51 -0000 On Wed, Jul 10, 2013 at 5:07 PM, Marc Blanchet wrote: > Le 2013-07-10 =C3=A0 16:49, Peter Saint-Andre a =C3= =A9crit : >> Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: >> >> OLD >> 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW >> 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. >> >> Then add the following sentence at the end of that section: >> >> Application protocols that use this profile MUST specify whether case >> mapping or additional mapping is to be applied by implementations or >> deployments of that protocol. > > I have a hard time thinking that, especially for credentials, app protoco= l 1 chooses no mapping and app protocol 2 chooses mapping and that both are= using the SASL layer below. Looks like looking for trouble here. no? The mechanism on the server side absolutely must apply whatever normalization is appropriate for it. The client should not have to. The app protocol could specify whether the client does or does not have to, I don't mind that. But it'd be silly to specify something that conflicts with whatever the mechanism will apply, so, that's a good point. All the more reason to have the app do nothing with usernames. Just pass them to the mechanism. Let the mechanism work it out. The mechanism on the client side should only normalize usernames for the purposes of generating salts. Also, the mechanism on the client side may want to apply Unicode normalization if the client has an input mode that produces NFD (say) when most servers happen to not implement a normalization (though they should) and expect NFC (say, which mostly they do). Nico -- From tlyu@mit.edu Wed Jul 10 15:47:52 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E3511E8135 for ; Wed, 10 Jul 2013 15:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF709f1i2QOA for ; Wed, 10 Jul 2013 15:47:45 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7086F11E8146 for ; Wed, 10 Jul 2013 15:47:44 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-74-51dde485cd43 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 84.CA.02471.584EDD15; Wed, 10 Jul 2013 18:47:33 -0400 (EDT) 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 r6AMlVUo013943; Wed, 10 Jul 2013 18:47:32 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6AMlUuJ018225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 18:47:31 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r6AMlU5N005158; Wed, 10 Jul 2013 18:47:30 -0400 (EDT) To: Nico Williams References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> From: Tom Yu Date: Wed, 10 Jul 2013 18:47:30 -0400 In-Reply-To: (Nico Williams's message of "Wed, 10 Jul 2013 17:33:37 -0500") Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrdv65G6gwcllnBZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJWx7dldxoIVrBXzbixnamCcydLFyMkhIWAi 0Xe+C8oWk7hwbz1bFyMXh5DAPkaJNT//MkM4Gxklzu75xAjhnGOSePutixXC6WKU+LjpDztI v4iApsT1eUvZQGxmAWGJ5WvOgtnCAkUST/83Qo1awyTx8c9yoG4ODjYBaYmji8tAalgEVCX+ b90KtptTYAKjxK+n85lAErwCFhITjm1kBKnnEeCUuP3aESIsKHFy5hMWiF1aEjf+vWSawCg4 C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrGermZJXqpKaWbGMHBKsm3g/HrQaVD jAIcjEo8vA3xdwOFWBPLiitzDzFKcjApifJGPwQK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE9 OQUox5uSWFmVWpQPk5LmYFES53329GygkEB6YklqdmpqQWoRTFaGg0NJgrf5MVCjYFFqempF WmZOCUKaiYMTZDgP0PA6kBre4oLE3OLMdIj8KUZFKXFeO5CEAEgiozQPrheWTF4xigO9Iszb A1LFA0xEcN2vgAYzAQ3ek3IHZHBJIkJKqoGRa/6m0rfuAca/0/N2iUwO2afkf+7aeqmarqMJ xSJdef1XduddW56n7+m1uHut8qo/i/bGvOhMV8k+kdQvuHa+st+UBAvT0FbG5G9h6/sfRt+7 dPtMTYTKqw+NjkuUUksiX53awfDN6pT9+fW/g/9p2kVIyBlf1Pkv159go5N8+4y8utWt9HlK LMUZiYZazEXFiQBApL5XAQMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:47:52 -0000 Nico Williams writes: > So you'd object to even the CTS mode we have in use today? For new enctypes, I would like us to move toward cryptographic best practice. It seems that the Suite B proponents would prefer that as well. > Sure, but if they can be used in such a way as to use Suite B modes > then the problem devolves to a performance problem. (The currently > in-use CTS mode has this property.) Yes, you can use a normal CBC implementation to build CTS mode, at the cost of doubling the setup overhead on decryption (and possibly encryption), as people who have had to implement CTS on top of HSM type interfaces have told me. From jhutz@cmu.edu Wed Jul 10 16:09:32 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477CB11E814C for ; Wed, 10 Jul 2013 16:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpXy246ia4Wd for ; Wed, 10 Jul 2013 16:09:26 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 5B85911E813D for ; Wed, 10 Jul 2013 16:09:26 -0700 (PDT) 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 r6AN9KB7004029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Jul 2013 19:09:21 -0400 (EDT) Message-ID: <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Tom Yu Date: Wed, 10 Jul 2013 19:09:20 -0400 In-Reply-To: <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.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.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:09:32 -0000 On Wed, 2013-07-10 at 18:24 -0400, Tom Yu wrote: > No, I think some non-Microsoft WG participants once believed it to be > a big deal for Microsoft, but we never had any confirmation from > anyone at Microsoft that it was a problem (at least none that I could > find). The most recent information that I have from Microsoft (from a > few months ago in private mail) is that it would only be a problem for > legacy applications that aren't using the SSPI correctly. What about non-legacy applications implementing standards-track GSS-API-using protocols according to a specification that isn't written with the SSPI in mind? It's all well and good to say "call the API to see what length you should use", but if the protocol says to send a 1025-byte message, then I have to send a 1025-byte message, even if the SSPI would rather I somehow only send a 1016-byte message. -- Jeff From nico@cryptonector.com Wed Jul 10 16:33:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FBA11E814C for ; Wed, 10 Jul 2013 16:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwwKI+fskaaN for ; Wed, 10 Jul 2013 16:33:37 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0F521F9C20 for ; Wed, 10 Jul 2013 16:33:37 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 8F0B9508072 for ; Wed, 10 Jul 2013 16:33:36 -0700 (PDT) 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=cYp8Bs3rl8nlmEvzGRqZ gJ06n+Q=; b=LhY0sFLhIs6brg4vLf7RwKox8An4lW7yrKRDIpuIbA6Hbk/SHS5h hSX6jVGDWGRwPIYmTwBEBXHNP5tmOywiV2anI6hVOsmgmeo/8mdqy6eiWL5dnCP8 LnbUEnXFGO27FaBneyOFRU8/bCUYchVeVnB5yF0YSfOmx7KSEQ/aaUY= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 36776508063 for ; Wed, 10 Jul 2013 16:33:36 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so6518510wgh.30 for ; Wed, 10 Jul 2013 16:33:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Owwc5AS0ak+cLx5/+kZa4VHUsirNejW3vy1vdePssS8=; b=KH8W7yHGVlksFr99D0PFfU+MSup4aaDWXDEptYcYhJLU4aUo4Tx0Nb/RrHUXsIaGUs c5mL4OaPB/ycwIN7OzeDZpyY2gzkbUpobLcxiPzOJpA85ke+VwI5o2uuYbMglFfZTVCt KSsLrCahOHjsizvFFyjK4FwFvNyATXWoCqS2fWsYeNJSwpf3OxBT5r205vT8R1iuCxSs EFKU1EErI3B11rGZ3GLryJ+NIhAH4l2shM7u722lPnxOyTRRvZQnP3tCbO2fQ5CSyvV8 xoQdOCiwL+6YVjAiNTAQa5ar5JtiVDXv3Lt541sZfc7OzPwNCCC3HlE4ke2aUvRWbQUA di2Q== MIME-Version: 1.0 X-Received: by 10.194.22.1 with SMTP id z1mr19924045wje.14.1373499214464; Wed, 10 Jul 2013 16:33:34 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 16:33:34 -0700 (PDT) In-Reply-To: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 18:33:34 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:33:43 -0000 On Wed, Jul 10, 2013 at 5:24 PM, Tom Yu wrote: >> This was a big deal to them once. It might still be. It'd be nice to >> hear from someone at Microsoft as to whether this is still an issue. > > No, I think some non-Microsoft WG participants once believed it to be > a big deal for Microsoft, but we never had any confirmation from > anyone at Microsoft that it was a problem (at least none that I could > find). The most recent information that I have from Microsoft (from a > few months ago in private mail) is that it would only be a problem for > legacy applications that aren't using the SSPI correctly. Could we get some details? Doesn't have to be on-list, since wouldn't be on-topic. I'm thinking of a) MSDN links to the relevant SSPI docs (that is, for the relevant functions), b) examples of correct and typical incorrect code using them. I just want to make sure before we leave one implementor unhappy. Nico -- From ghudson@mit.edu Wed Jul 10 16:42:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454CB11E80AD for ; Wed, 10 Jul 2013 16:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pOhuS7vB-n7 for ; Wed, 10 Jul 2013 16:42:24 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7824221F9B38 for ; Wed, 10 Jul 2013 16:42:24 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-1e-51ddf15f96be Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 47.33.02387.F51FDD15; Wed, 10 Jul 2013 19:42:23 -0400 (EDT) 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 r6ANgMiF018263; Wed, 10 Jul 2013 19:42:23 -0400 Received: from [18.101.8.84] (vpn-18-101-8-84.mit.edu [18.101.8.84]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6ANgIgp000744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 19:42:20 -0400 Message-ID: <51DDF15A.8020705@mit.edu> Date: Wed, 10 Jul 2013 19:42:18 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1o3/eDfQ4PcvRYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp40LuYveAfT0XL1H9sDYwHuboYOTkkBEwk /s5dxQhhi0lcuLeerYuRi0NIYB+jxIP3J6CcjYwSk6fNZIdwDjJJHL14ByjDwcEroCaxZUkN SDeLgKpEw5xudhCbTUBZ4uDZbywgJaICIRJLT3KDhHkFBCVOznzCAmKLCGhKXJ+3lA3EZhbQ kti0aD1Yq7BAkcTT/43MEKs2MUr8blgIVsQpEChxYttHJohLJSUWTetkgWjWkXjX94AZwpaX 2P52DvMERqFZSPbNQlI2C0nZAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRboWermZJXqpKaWb GEGBze6iuoNxwiGlQ4wCHIxKPLwN8XcDhVgTy4orcw8xSnIwKYnyJn4ACvEl5adUZiQWZ8QX leakFh9ilOBgVhLhPTkFKMebklhZlVqUD5OS5mBREud9/vRsoJBAemJJanZqakFqEUxWhoND SYL363ugRsGi1PTUirTMnBKENBMHJ8hwHqDhn0FqeIsLEnOLM9Mh8qcYFaXEeTVALhIASWSU 5sH1whLPK0ZxoFeEeX+BtPMAkxZc9yugwUxAg/ek3AEZXJKIkJJqYHSN8mGTkfzlrPllgoyZ nlX3/6hfZ8/+Wbm4e3O0eFYko/AnK7MXP0U0NrpOiuLb/Wze/7YdqYtf9VeuCQk/epX12KFY wRS++JBJonnyUQkm8lcntjYsUt5kY2HRI3qGRTUnJuOGW1uV/6c8fhGfk5dv3TU7tK1x9kSr j1FNk+7VxO1wWKjZo8RSnJFoqMVcVJwIAMPwQX0XAwAA Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:42:31 -0000 On 07/10/2013 05:30 PM, Nico Williams wrote: > I'm not at all worried about implementation risks. I disagree. The RFC 3962 enctypes have an exception case when the plaintext is the empty string. Both MIT's and Heimdal's implementation do the wrong thing with the output cipher state in this case. A more comprehensive suite of test vectors would have helped, but there's no guarantee that someone designing such a suite would have thought to combine cipher state with a zero-length input, or would have interpreted the spec correctly if they did. Nobody appears to care, because encrypting the empty string is rare and using cipher state is also rare, but the lesson remains that even in rarely-changing code, there are implementation risks to having a complicated specification. Details: RFC 3962 adds a confounder to the input, so there is always at least one block to encrypt. If the input plaintext length is 0, then there is exactly one block to encrypt. RFC 3962 section 4 specifies that "If exactly one block is to be encrypted, that block is simply encrypted with AES (also known as ECB mode)." Section 6 specifies the encryption/decryption functions as "AES in CBC-CTS mode (cipher block size 16 octets), with next-to-last block (last block if only one) as CBC-style ivec." One could possibly interpret section 4 as saying that the input state should be ignored, although that would be bogus. In any event, it's clear from section 6 that the output state should be the last (and only) block of ciphertext. What actually happens, in both MIT and Heimdal, is that the cipher state is neither used nor modified. From nico@cryptonector.com Wed Jul 10 17:09:30 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6821F9B5C for ; Wed, 10 Jul 2013 17:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxdz6HJ+7Yl7 for ; Wed, 10 Jul 2013 17:09:25 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0410011E80A5 for ; Wed, 10 Jul 2013 17:09:24 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 8DD581B4061 for ; Wed, 10 Jul 2013 17:09:23 -0700 (PDT) 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=wwaGGi0BlCSLOariDlEy DUZYvHM=; b=aGe+cRdAmVQyNHq21US4wtill7mQ/R48rz+I53pDp4908AJDJAEO x2VBygioysEXzKJkNAYGXlHJ7DBPi5AZE5dKSYDqt12F25jaIXWulTj9RuyBNPVQ qZJoD/+Kg5x3/q8Zqw4GDGP5oe/+OkpwH3EAeLW695zbf7wsRFb3iDo= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 3F1C31B4078 for ; Wed, 10 Jul 2013 17:09:23 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so6384674wes.4 for ; Wed, 10 Jul 2013 17:09:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qvk2r3/m6RNuD1xFmUnJjuF5MqwZehpBZoMRf+nHhzE=; b=V6YoZT0A02l7mvanlrUY0ucqRAQYI6Dms7lZ5+HnZPT6zE/qO3LG+cldJHMwI3yI7R T8xgmYv3zYv0Lq4vxOg2x56aNYr4qByOtY/wf6Y9IRQTnClYZrXZ9jsS5AkWHUHfdYo/ 83kza2MXIznK3t3rnfJF53KVA3SVPIn5DEfhH3/GmrVOf/9MGRaq4bzjnA4zf2jCOrKm 4GQmg6i5WcOXJZ7G2XbmmxXyqOjMC7IN6PQDSmTc1RvYFq+6j8wcI+ddadFUHjur+keD FWi4yoLSmne6afUGxB/HqyEZIvuwrla/Bv7gkXYNsV19x8Kso1cOY3HEX9AXiIwXUXHF MRwA== MIME-Version: 1.0 X-Received: by 10.194.22.1 with SMTP id z1mr19980562wje.14.1373501361550; Wed, 10 Jul 2013 17:09:21 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 17:09:21 -0700 (PDT) In-Reply-To: <51DDF15A.8020705@mit.edu> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <51DDF15A.8020705@mit.edu> Date: Wed, 10 Jul 2013 19:09:21 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 00:09:30 -0000 On Wed, Jul 10, 2013 at 6:42 PM, Greg Hudson wrote: > On 07/10/2013 05:30 PM, Nico Williams wrote: >> I'm not at all worried about implementation risks. > > I disagree. > > The RFC 3962 enctypes have an exception case when the plaintext is the > empty string. Both MIT's and Heimdal's implementation do the wrong > thing with the output cipher state in this case. A more comprehensive > suite of test vectors would have helped, but there's no guarantee that > someone designing such a suite would have thought to combine cipher > state with a zero-length input, or would have interpreted the spec > correctly if they did. > > Nobody appears to care, because encrypting the empty string is rare and > using cipher state is also rare, but the lesson remains that even in > rarely-changing code, there are implementation risks to having a > complicated specification. Interesting. Only Kerberos applications that use the Kerberos cryptosystem directly and *chain( encryptions are affected. Not GSS apps, for example, nor apps that use any Kerberos PDUs. In any case, I stand by what I said. I find the cryptographic vulnerability risk of much higher concern. There's no point to properly implementing a broken algorithm. > Details: RFC 3962 adds a confounder to the input, so there is always at > least one block to encrypt. If the input plaintext length is 0, then > there is exactly one block to encrypt. RFC 3962 section 4 specifies > that "If exactly one block is to be encrypted, that block is simply > encrypted with AES (also known as ECB mode)." Section 6 specifies the > encryption/decryption functions as "AES in CBC-CTS mode (cipher block > size 16 octets), with next-to-last block (last block if only one) as > CBC-style ivec." One could possibly interpret section 4 as saying that > the input state should be ignored, although that would be bogus. In any > event, it's clear from section 6 that the output state should be the > last (and only) block of ciphertext. What actually happens, in both MIT > and Heimdal, is that the cipher state is neither used nor modified. This is good to know. This doesn't really change my opinion, but that will be moot anyways once we have the details showing that we don't have to worry about not padding for SSPI apps. Nico -- From lukeh@padl.com Wed Jul 10 17:17:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F4211E80C5 for ; Wed, 10 Jul 2013 17:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXSTXxEF-h+2 for ; Wed, 10 Jul 2013 17:17:20 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4B38111E80D1 for ; Wed, 10 Jul 2013 17:17:18 -0700 (PDT) Received: by us.padl.com with ESMTP id r6B0H4rd024416; Wed, 10 Jul 2013 20:17:07 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> Date: Thu, 11 Jul 2013 10:17:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,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] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 00:17:25 -0000 Good point Jeff. An SSPI application can call QueryContextAttributes(SECPKG_ATTR_SIZES), = but unlike gss_wrap_iov_length(), that data to be wrapped is not passed = as an argument. So it can only return the maximum security trailer size = (trailer being the RFC4121 wrap token/rotated checksum). If an in-place wrap truncates the trailer length, the application = protocol may not be able to update it (consider something like DCE RPC = where the message length is also authenticated). (It's sort of = irrelevant whether the padding is done inside the trailer -- via EC -- = or by the application.) I would need to do some research; from memory DCE RPC always pads PDUs = to 16 bytes, so for common block sizes the trailer is effectively = constant length (there is no requirement for EC). I will investigate. Of course, there are other SSPI applications than DCE RPC, but I'm not = sure if they have the limitation of not allowing the trailer size to be = shorter after wrap. -- Luke= From marc.blanchet@viagenie.ca Wed Jul 10 15:07:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107CE21F9CE6; Wed, 10 Jul 2013 15:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c8DpvNmdxAS; Wed, 10 Jul 2013 15:07:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0045F21F9CCC; Wed, 10 Jul 2013 15:07:55 -0700 (PDT) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AA630403ED; Wed, 10 Jul 2013 18:07:46 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51DDC8D3.5060808@stpeter.im> Date: Wed, 10 Jul 2013 18:07:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 11 Jul 2013 00:10:42 -0700 Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:07:57 -0000 Le 2013-07-10 =E0 16:49, Peter Saint-Andre a =E9crit = : > Hi Nico, I've looked at this a bit further. Proposed text changes = below... >=20 > On 7/10/13 1:00 PM, Peter Saint-Andre wrote: >> On 7/2/13 5:20 PM, Nico Williams wrote: >>> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >>> wrote: >>>> On 5/3/13 1:39 PM, Nico Williams wrote: >>>>=20 >>>>> Please forgive my apparent apathy. I lost track of this due >>>>> to business travel. >>>>=20 >>>> And please forgive my delay in replying. It's good to know >>>> you're not apathetic. And as you can tell, we're proceeding >>>> rather slowly with this work. That doesn't mean it is >>>> unimportant. This recent example from the blogosphere might of >>>> interest: >>>>=20 >>>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>>>=20 >>>> PRECIS might have helped those folks avoid some significant >>>> pain. >>>>=20 >>>>> I'm not sure where the case mapping requirement for usernames >>>>> came from. >>>>=20 >>>> Are you referring to global case mapping or local case >>>> mapping? >>>>=20 >>>>> I guess it has something to do with the Turkish I and such. >>>>=20 >>>> Yes, that is a nasty problem with even nastier consequences: >>>>=20 >>>> = http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-t= hree-more-in-jail >>>=20 >>>=20 >>>>=20 > ! >>>=20 >>> But that can't apply here. Or, if anything, case mappings makes >>> it more likely. Let's say I'm logged in in some app and it shows >>> the username I typed in, but because of case mapping some typos >>> are tolerated, so the username shown could offend someone. >>> Whereas if I'm required to type my username exactly one way (not >>> including NF) then that can't happen. So if anything that link >>> indicates we should not have case mappings here... :) >>>=20 >>>> Just to be clear, that's an issue of what we're calling local >>>> case mapping (where locale is taken into consideration). >>>>=20 >>>>> I can't say I'm excited about this case mapping requirement; >>>>> if anything it strikes as silly. >>>>=20 >>>> In general, the opinion so far has been that, say, StPeter is >>>> treated the same as stpeter when it comes to authentication and >>>> authorization based on usernames. Do you disagree? If so, why? >>>> For example, would you be inclined to leave this up to the >>>> protocol that uses SASL (say, IMAP or XMPP) instead of >>>> specifying it in SASLprepbis? >>>=20 >>> I think it'd be nice if *servers* got to choose whether to do >>> this. The principle here is that the server should make right >>> when it comes to the username. This means that clients should be >>> pretty much able to send just about anything as a username and >>> let the server figure it out. >>>=20 >>> Whether it's a server application or the mechanisms (or SASL >>> library) that applies such rules is a different story, and one I >>> don't think I care much about here. >>=20 >> Ah, I see. >>=20 >> It seems to me that there are numerous layers here: >>=20 >> 1. SASL (including preparation and comparison rules) >>=20 >> 2. The application protocol that's using SASL (e.g., IMAP) >>=20 >> 3. A software implementation of the application protocol, which >> likely embeds or links to a SASL implementation (e.g., dovecot) >>=20 >> 4. A deployment of said software implementation (e.g., >> example.net) >>=20 >> By "server" I think you mean a deployment. Correct? >>=20 >> Rather than legislating in saslprepbis that all application >> protocols shall leave casemapping up to implementations or >> deployments, I think that it would be reasonable for the >> specification of an application protocol using SASL (e.g., >> draft-ietf-xmpp-6122bis) to recommend or require casemapping >> behavior for all implementations or deployments of that application >> protocol, or to leave such decisions up to the implementation or >> deployment. For example, perhaps the XMPP spec would say "all >> implementations shall perform case mapping, full stop" whereas the >> IMAP spec might leave that up to implementations or deployments. >=20 > Here is what I suggest in Section 2.2 of = draft-ietf-precis-saslprepbis: >=20 > OLD > 3. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. >=20 > NEW > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. >=20 > Then add the following sentence at the end of that section: >=20 > Application protocols that use this profile MUST specify whether = case > mapping or additional mapping is to be applied by implementations or > deployments of that protocol. I have a hard time thinking that, especially for credentials, app = protocol 1 chooses no mapping and app protocol 2 chooses mapping and = that both are using the SASL layer below. Looks like looking for = trouble here. no? Marc. >=20 > Does that seem acceptable? >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From alexey.melnikov@isode.com Thu Jul 11 00:43:26 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86C521F964C; Thu, 11 Jul 2013 00:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDweO68jQXPy; Thu, 11 Jul 2013 00:43:26 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0049F21F963F; Thu, 11 Jul 2013 00:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1373528604; d=isode.com; s=selector; i=@isode.com; bh=na+NfkCLyLJlyodF4CjeH3dPwkTCRpDFHslhujzTljw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZPUIjKPIMA257gf3W8XN9vPbBJU0g5UVpv2826rXEo/AmqTO8oCc98nnnHKhJZltTMy8FA ZYghQyAoeBHOM+olo8A/YBKSJK4fQxC681XOF/WF1nI/jPo/Cxzj3DbEKevxAfUd+sIyHJ 3Ci8BrrFvvh3qtBhr1Bu2GiPhHKlg1s=; Received: from [10.243.90.242] ((unknown) [212.183.128.181]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 11 Jul 2013 08:43:24 +0100 X-SMTP-Protocol-Errors: NORDNS References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> In-Reply-To: <51DDC8D3.5060808@stpeter.im> Message-Id: <0145BE0C-08DA-48D3-9F25-77714EDBA2D6@isode.com> X-Mailer: iPhone Mail (10A523) From: Alexey Melnikov Date: Thu, 11 Jul 2013 08:44:59 +0100 To: Peter Saint-Andre MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:43:26 -0000 On 10 Jul 2013, at 21:49, Peter Saint-Andre wrote: >> Rather than legislating in saslprepbis that all application >> protocols shall leave casemapping up to implementations or >> deployments, I think that it would be reasonable for the >> specification of an application protocol using SASL (e.g., >> draft-ietf-xmpp-6122bis) to recommend or require casemapping >> behavior for all implementations or deployments of that application >> protocol, or to leave such decisions up to the implementation or >> deployment. For example, perhaps the XMPP spec would say "all >> implementations shall perform case mapping, full stop" whereas the >> IMAP spec might leave that up to implementations or deployments. > > Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: > > OLD > 3. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. > > NEW > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > Then add the following sentence at the end of that section: > > Application protocols that use this profile MUST specify whether case > mapping or additional mapping is to be applied by implementations or > deployments of that protocol. > > Does that seem acceptable? Yes. From derek@ihtfp.com Thu Jul 11 06:02:02 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C498A11E814C for ; Thu, 11 Jul 2013 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOl0Kq8PQhP9 for ; Thu, 11 Jul 2013 06:02:02 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36221F9EEE for ; Thu, 11 Jul 2013 06:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B3A2B260268; Thu, 11 Jul 2013 09:01:59 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14427-07; Thu, 11 Jul 2013 09:01:58 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1A5F2260248; Thu, 11 Jul 2013 09:01:58 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r6BD1pFC020261; Thu, 11 Jul 2013 09:01:51 -0400 From: Derek Atkins To: Tom Yu References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 09:01:51 -0400 In-Reply-To: (Tom Yu's message of "Wed, 10 Jul 2013 18:47:30 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:02:02 -0000 Tom Yu writes: > Nico Williams writes: > >> So you'd object to even the CTS mode we have in use today? > > For new enctypes, I would like us to move toward cryptographic best > practice. It seems that the Suite B proponents would prefer that as > well. > >> Sure, but if they can be used in such a way as to use Suite B modes >> then the problem devolves to a performance problem. (The currently >> in-use CTS mode has this property.) > > Yes, you can use a normal CBC implementation to build CTS mode, at the > cost of doubling the setup overhead on decryption (and possibly > encryption), as people who have had to implement CTS on top of HSM > type interfaces have told me. Having recently implemented Krb5 CTS mode myself, it is just one extra block and a little bit-fudging on decryption. It's really not a lot of code. I think the encryption and decryption routines added about 20-40 LoC (I'd have to actually look again to count if you want an exact number). > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From jhutz@cmu.edu Thu Jul 11 07:56:06 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A343E21F9C22; Thu, 11 Jul 2013 07:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWlFxUaES4fG; Thu, 11 Jul 2013 07:55:52 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7965F21F9BD0; Thu, 11 Jul 2013 07:55:51 -0700 (PDT) Received: from [192.168.202.142] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r6BEteXQ020249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 10:55:41 -0400 (EDT) Message-ID: <1373554540.23328.87.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Thu, 11 Jul 2013 10:55:40 -0400 In-Reply-To: <14735_1373496114_r6AMfr0J008900_CAK3OfOijd2AvHgHd_Wi3+S=PZkTyUjRuRAXj5fV26ArsRO8zKg@mail.gmail.com> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <14735_1373496114_r6AMfr0J008900_CAK3OfOijd2AvHgHd_Wi3+S=PZkTyUjRuRAXj5fV26ArsRO8zKg@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, Marc Blanchet , precis@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:56:07 -0000 On Wed, 2013-07-10 at 17:41 -0500, Nico Williams wrote: > The app protocol could specify whether the client does or does not > have to, I don't mind that. But it'd be silly to specify something > that conflicts with whatever the mechanism will apply, so, that's a > good point. > > All the more reason to have the app do nothing with usernames. Just > pass them to the mechanism. Let the mechanism work it out. This is a key point. SASL doesn't have usernames. It has authentication names and authorization names. SASL application protocols do not get a say in how authentication names are handled, period. It's just not up to them; these names are artifacts of the SASL mechanism, and their handling is generally dictated by the underlying authentication technology. SASLprep is not and never was about setting down general rules for handling authentication names or what SASL application protocols must do. It was about providing a profile for use by specific SASL mechanisms that are in the position of defining "username" or password elements that need one. Applications do get a say about authorization names; in fact, they get the _only_ say. They are the application's "usernames", and SASL doesn't get to say what they look like or what they mean. That is the purview of the application, which is entirely responsible for authorization. SASL is merely the authentication framework, and not necessarily even the only one supported by any given application. Of course, we can give advice to application protocol designers, but we can't effectively impose requirements, and there's not really even any reason to do so. Further, any advice we do give would not be in any way SASL-specific, so while it might be appropriate for PRECIS to do such a thing, saslprep might not be the best place to do so. > The mechanism on the client side should only normalize usernames for > the purposes of generating salts. This is almost right. From what I've seen, in authentication, filesystems, and other places, the right thing is almost always to apply normalization or any other canonicalizations at the last possible moment, and no later. For example, if you're going to look up a name in a database, normalize just before the lookup and not before. Or, better yet, don't normalize keys that go into the database, and do normalization-insensitive comparison instead. This can be a bit tricky depending on the nature of the database, but not impossible. The case you mention is an interesting one, though stated slightly too narrowly. Any string that is going to be used as a salt, or to derive keying material, or as input to a cryptographic hash, will need to be normalized before doing that. But, _only if the string itself will not be sent_. If the string is being sent, then send and use the un-normalized form, and the far end can use a normalization-insensitive comparison to decide if it got what it was expecting, or it can normalize (as late as possible!) and do whatever database lookup is needed. Note again that there is nothing about this advice that's specific to SASL or SASL mechanisms or SASL application protocols. However, it does apply to protocol designs, not implementations -- if a protocol says to normalize at a particular point, an implementation cannot decide to instead follow the "as late as possible" rule, or interoperability will suffer. I think that means we need to be careful about anything we specify here; we can offer advice to protocol designers, but we cannot impose requirements directly on implementations about whether or when to normalize or case-convert. Otherwise, we risk hindering interoperability instead of helping it. Now, back to the original point... > >> Application protocols that use this profile MUST specify whether > case > >> mapping or additional mapping is to be applied by implementations > or > >> deployments of that protocol. > > > > I have a hard time thinking that, especially for credentials, app > protocol 1 chooses no mapping and app protocol 2 chooses mapping and > that both are using the SASL layer below. Looks like looking for > trouble here. no? The key phrase is "Application protocols that use this profile". Such a protocol can apply the profile, and rules about whether to do case-mapping, only to protocol elements that belong to it. For example, an application might apply the profile to its SASL authorization names, or to some other protocol element that is not related to SASL at all. But it cannot apply the profile to protocol elements that a particular SASL mechanism depends on, because those belong to the mechanism and exist below the SASL abstraction, where the application protocol spec cannot even see them. That said, I think we need to be clear that the profile is _also_ available for use by SASL _mechanisms_, since after all, that was no small part of the original purpose of SASLprep. The same requirement applies -- a mechanism that uses the profile must specify whether to do case folding. FWIW, I think both the "OLD" and "NEW" variants from Peter's message are wrong. We should not say that case-folding MUST be done, because that mandates its use everywhere. However, we should also not say that it MAY be done, because that looks like we are granting permission for implementations of the profile to do case-folding anytime they want, even if that's not what the protocol says. Instead, we should keep only the sentence Peter proposes adding at the end, or some variation thereof, which has the effect of leaving the case-folding question up to the protocol applying the profile. -- Jeff From stpeter@stpeter.im Thu Jul 11 10:49:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3AC21E804C; Thu, 11 Jul 2013 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znZy9h8yzxP6; Thu, 11 Jul 2013 10:49:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98421F9B2A; Thu, 11 Jul 2013 10:49:12 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E5FA41400; Thu, 11 Jul 2013 11:50:21 -0600 (MDT) Message-ID: <51DEF015.70608@stpeter.im> Date: Thu, 11 Jul 2013 11:49:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexey Melnikov References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0145BE0C-08DA-48D3-9F25-77714EDBA2D6@isode.com> In-Reply-To: <0145BE0C-08DA-48D3-9F25-77714EDBA2D6@isode.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:49:20 -0000 On 7/11/13 1:44 AM, Alexey Melnikov wrote: > On 10 Jul 2013, at 21:49, Peter Saint-Andre wrote: > >>> Rather than legislating in saslprepbis that all application >>> protocols shall leave casemapping up to implementations or >>> deployments, I think that it would be reasonable for the >>> specification of an application protocol using SASL (e.g., >>> draft-ietf-xmpp-6122bis) to recommend or require casemapping >>> behavior for all implementations or deployments of that application >>> protocol, or to leave such decisions up to the implementation or >>> deployment. For example, perhaps the XMPP spec would say "all >>> implementations shall perform case mapping, full stop" whereas the >>> IMAP spec might leave that up to implementations or deployments. >> >> Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: >> >> OLD >> 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW >> 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. >> >> Then add the following sentence at the end of that section: >> >> Application protocols that use this profile MUST specify whether case >> mapping or additional mapping is to be applied by implementations or >> deployments of that protocol. >> >> Does that seem acceptable? > > Yes. Thanks for the feedback. I was wondering last night whether we want to add some guidance or recommendations on this topic, or truly just leave it up to those who define application protocols. (For example, we could say something about balancing interoperability and user expectations.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 12:27:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6795E21F9E05; Thu, 11 Jul 2013 12:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC0wOGrJwPpr; Thu, 11 Jul 2013 12:27:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8078921F9E13; Thu, 11 Jul 2013 12:27:52 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 04AF841403; Thu, 11 Jul 2013 13:29:01 -0600 (MDT) Message-ID: <51DF0735.8000006@stpeter.im> Date: Thu, 11 Jul 2013 13:27:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> In-Reply-To: <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:27:58 -0000 On 7/10/13 4:07 PM, Marc Blanchet wrote: > Le 2013-07-10 à 16:49, Peter Saint-Andre a écrit > : > >> Hi Nico, I've looked at this a bit further. Proposed text changes >> below... >> >> On 7/10/13 1:00 PM, Peter Saint-Andre wrote: >>> On 7/2/13 5:20 PM, Nico Williams wrote: >>>> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >>>> wrote: >>>>> On 5/3/13 1:39 PM, Nico Williams wrote: >>>>> >>>>>> Please forgive my apparent apathy. I lost track of this >>>>>> due to business travel. >>>>> >>>>> And please forgive my delay in replying. It's good to know >>>>> you're not apathetic. And as you can tell, we're proceeding >>>>> rather slowly with this work. That doesn't mean it is >>>>> unimportant. This recent example from the blogosphere might >>>>> of interest: >>>>> >>>>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>>>> >>>>> PRECIS might have helped those folks avoid some significant >>>>> pain. >>>>> >>>>>> I'm not sure where the case mapping requirement for >>>>>> usernames came from. >>>>> >>>>> Are you referring to global case mapping or local case >>>>> mapping? >>>>> >>>>>> I guess it has something to do with the Turkish I and >>>>>> such. >>>>> >>>>> Yes, that is a nasty problem with even nastier consequences: >>>>> >>>>> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail >>>> >>>> >>>>> >> >>>>> ! >>>> >>>> But that can't apply here. Or, if anything, case mappings >>>> makes it more likely. Let's say I'm logged in in some app and >>>> it shows the username I typed in, but because of case mapping >>>> some typos are tolerated, so the username shown could offend >>>> someone. Whereas if I'm required to type my username exactly >>>> one way (not including NF) then that can't happen. So if >>>> anything that link indicates we should not have case mappings >>>> here... :) >>>> >>>>> Just to be clear, that's an issue of what we're calling >>>>> local case mapping (where locale is taken into >>>>> consideration). >>>>> >>>>>> I can't say I'm excited about this case mapping >>>>>> requirement; if anything it strikes as silly. >>>>> >>>>> In general, the opinion so far has been that, say, StPeter >>>>> is treated the same as stpeter when it comes to >>>>> authentication and authorization based on usernames. Do you >>>>> disagree? If so, why? For example, would you be inclined to >>>>> leave this up to the protocol that uses SASL (say, IMAP or >>>>> XMPP) instead of specifying it in SASLprepbis? >>>> >>>> I think it'd be nice if *servers* got to choose whether to do >>>> this. The principle here is that the server should make right >>>> when it comes to the username. This means that clients should >>>> be pretty much able to send just about anything as a username >>>> and let the server figure it out. >>>> >>>> Whether it's a server application or the mechanisms (or SASL >>>> library) that applies such rules is a different story, and one >>>> I don't think I care much about here. >>> >>> Ah, I see. >>> >>> It seems to me that there are numerous layers here: >>> >>> 1. SASL (including preparation and comparison rules) >>> >>> 2. The application protocol that's using SASL (e.g., IMAP) >>> >>> 3. A software implementation of the application protocol, which >>> likely embeds or links to a SASL implementation (e.g., dovecot) >>> >>> 4. A deployment of said software implementation (e.g., >>> example.net) >>> >>> By "server" I think you mean a deployment. Correct? >>> >>> Rather than legislating in saslprepbis that all application >>> protocols shall leave casemapping up to implementations or >>> deployments, I think that it would be reasonable for the >>> specification of an application protocol using SASL (e.g., >>> draft-ietf-xmpp-6122bis) to recommend or require casemapping >>> behavior for all implementations or deployments of that >>> application protocol, or to leave such decisions up to the >>> implementation or deployment. For example, perhaps the XMPP spec >>> would say "all implementations shall perform case mapping, full >>> stop" whereas the IMAP spec might leave that up to >>> implementations or deployments. >> >> Here is what I suggest in Section 2.2 of >> draft-ietf-precis-saslprepbis: >> >> OLD 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. >> >> Then add the following sentence at the end of that section: >> >> Application protocols that use this profile MUST specify whether >> case mapping or additional mapping is to be applied by >> implementations or deployments of that protocol. > > I have a hard time thinking that, especially for credentials, app > protocol 1 chooses no mapping and app protocol 2 chooses mapping and > that both are using the SASL layer below. Looks like looking for > trouble here. no? I see your point, although I agree with Nico and Jeff that for SASL purposes these things will be mostly or completely determined by the mechanism (not all mechanisms have a concept of a "simple user name" -- the ones I'm familiar with are CRAM-MD5, DIGEST-MD5, and SCRAM). However, I think that this PRECIS profile might be used by non-SASL-using application protocols, such as HTTP authentication (see message from Yutaka Oiwa). I will try to formulate some corrected text. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 12:46:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B10121F999C; Thu, 11 Jul 2013 12:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG3LQBmIRrNx; Thu, 11 Jul 2013 12:45:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B3DE621F992E; Thu, 11 Jul 2013 12:45:58 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E9A141403; Thu, 11 Jul 2013 13:47:08 -0600 (MDT) Message-ID: <51DF0B74.5000808@stpeter.im> Date: Thu, 11 Jul 2013 13:45:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> In-Reply-To: <51DF0735.8000006@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:46:03 -0000 On 7/11/13 1:27 PM, Peter Saint-Andre wrote: > On 7/10/13 4:07 PM, Marc Blanchet wrote: >> Le 2013-07-10 à 16:49, Peter Saint-Andre a écrit >> : >> >>> Hi Nico, I've looked at this a bit further. Proposed text changes >>> below... >>> >>> On 7/10/13 1:00 PM, Peter Saint-Andre wrote: >>>> On 7/2/13 5:20 PM, Nico Williams wrote: >>>>> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >>>>> wrote: >>>>>> On 5/3/13 1:39 PM, Nico Williams wrote: >>>>>> >>>>>>> Please forgive my apparent apathy. I lost track of this >>>>>>> due to business travel. >>>>>> >>>>>> And please forgive my delay in replying. It's good to know >>>>>> you're not apathetic. And as you can tell, we're proceeding >>>>>> rather slowly with this work. That doesn't mean it is >>>>>> unimportant. This recent example from the blogosphere might >>>>>> of interest: >>>>>> >>>>>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>>>>> >>>>>> PRECIS might have helped those folks avoid some significant >>>>>> pain. >>>>>> >>>>>>> I'm not sure where the case mapping requirement for >>>>>>> usernames came from. >>>>>> >>>>>> Are you referring to global case mapping or local case >>>>>> mapping? >>>>>> >>>>>>> I guess it has something to do with the Turkish I and >>>>>>> such. >>>>>> >>>>>> Yes, that is a nasty problem with even nastier consequences: >>>>>> >>>>>> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail >>>>> >>>>> >>>>>> >>> >>>>>> > ! >>>>> >>>>> But that can't apply here. Or, if anything, case mappings >>>>> makes it more likely. Let's say I'm logged in in some app and >>>>> it shows the username I typed in, but because of case mapping >>>>> some typos are tolerated, so the username shown could offend >>>>> someone. Whereas if I'm required to type my username exactly >>>>> one way (not including NF) then that can't happen. So if >>>>> anything that link indicates we should not have case mappings >>>>> here... :) >>>>> >>>>>> Just to be clear, that's an issue of what we're calling >>>>>> local case mapping (where locale is taken into >>>>>> consideration). >>>>>> >>>>>>> I can't say I'm excited about this case mapping >>>>>>> requirement; if anything it strikes as silly. >>>>>> >>>>>> In general, the opinion so far has been that, say, StPeter >>>>>> is treated the same as stpeter when it comes to >>>>>> authentication and authorization based on usernames. Do you >>>>>> disagree? If so, why? For example, would you be inclined to >>>>>> leave this up to the protocol that uses SASL (say, IMAP or >>>>>> XMPP) instead of specifying it in SASLprepbis? >>>>> >>>>> I think it'd be nice if *servers* got to choose whether to do >>>>> this. The principle here is that the server should make right >>>>> when it comes to the username. This means that clients should >>>>> be pretty much able to send just about anything as a username >>>>> and let the server figure it out. >>>>> >>>>> Whether it's a server application or the mechanisms (or SASL >>>>> library) that applies such rules is a different story, and one >>>>> I don't think I care much about here. >>>> >>>> Ah, I see. >>>> >>>> It seems to me that there are numerous layers here: >>>> >>>> 1. SASL (including preparation and comparison rules) >>>> >>>> 2. The application protocol that's using SASL (e.g., IMAP) >>>> >>>> 3. A software implementation of the application protocol, which >>>> likely embeds or links to a SASL implementation (e.g., dovecot) >>>> >>>> 4. A deployment of said software implementation (e.g., >>>> example.net) >>>> >>>> By "server" I think you mean a deployment. Correct? >>>> >>>> Rather than legislating in saslprepbis that all application >>>> protocols shall leave casemapping up to implementations or >>>> deployments, I think that it would be reasonable for the >>>> specification of an application protocol using SASL (e.g., >>>> draft-ietf-xmpp-6122bis) to recommend or require casemapping >>>> behavior for all implementations or deployments of that >>>> application protocol, or to leave such decisions up to the >>>> implementation or deployment. For example, perhaps the XMPP spec >>>> would say "all implementations shall perform case mapping, full >>>> stop" whereas the IMAP spec might leave that up to >>>> implementations or deployments. >>> >>> Here is what I suggest in Section 2.2 of >>> draft-ietf-precis-saslprepbis: >>> >>> OLD 3. Uppercase and titlecase characters MUST be mapped to their >>> lowercase equivalents. >>> >>> NEW 3. Uppercase and titlecase characters MAY be mapped to their >>> lowercase equivalents. >>> >>> Then add the following sentence at the end of that section: >>> >>> Application protocols that use this profile MUST specify whether >>> case mapping or additional mapping is to be applied by >>> implementations or deployments of that protocol. >> >> I have a hard time thinking that, especially for credentials, app >> protocol 1 chooses no mapping and app protocol 2 chooses mapping and >> that both are using the SASL layer below. Looks like looking for >> trouble here. no? > > I see your point, although I agree with Nico and Jeff that for SASL > purposes these things will be mostly or completely determined by the > mechanism (not all mechanisms have a concept of a "simple user name" -- > the ones I'm familiar with are CRAM-MD5, DIGEST-MD5, and SCRAM). > However, I think that this PRECIS profile might be used by > non-SASL-using application protocols, such as HTTP authentication (see > message from Yutaka Oiwa). > > I will try to formulate some corrected text. How's this? OLD Application protocols that use this profile MUST specify whether case mapping or additional mapping is to be applied by implementations or deployments of that protocol. NEW SASL mechanisms and application protocols that directly re-use this profile MUST specify whether case mapping or additional mapping is to be applied by implementations or deployments thereof. Note that some application protocols themselves re-use SASL (examples include IMAP [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the mapping rules defined for the relevant SASL mechanisms and not specify application-specific rules for that protocol's use of SASL or particular SASL mechanisms. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 13:05:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120B821F9D59; Thu, 11 Jul 2013 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUIkvDmjC7oc; Thu, 11 Jul 2013 13:05:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF61721F9D9D; Thu, 11 Jul 2013 13:05:10 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0B5D041403; Thu, 11 Jul 2013 14:05:52 -0600 (MDT) Message-ID: <51DF0FD8.3090908@stpeter.im> Date: Thu, 11 Jul 2013 14:04:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <14735_1373496114_r6AMfr0J008900_CAK3OfOijd2AvHgHd_Wi3+S=PZkTyUjRuRAXj5fV26ArsRO8zKg@mail.gmail.com> <1373554540.23328.87.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1373554540.23328.87.camel@destiny.pc.cs.cmu.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org, Marc Blanchet Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:05:16 -0000 On 7/11/13 8:55 AM, Jeffrey Hutzelman wrote: [snipping lots of interesting material, since I'm focused on finding appropriate text before the I-D deadline] > Now, back to the original point... > > >>>> Application protocols that use this profile MUST specify whether >> case >>>> mapping or additional mapping is to be applied by implementations >> or >>>> deployments of that protocol. >>> >>> I have a hard time thinking that, especially for credentials, app >> protocol 1 chooses no mapping and app protocol 2 chooses mapping and >> that both are using the SASL layer below. Looks like looking for >> trouble here. no? > > > The key phrase is "Application protocols that use this profile". Such a > protocol can apply the profile, and rules about whether to do > case-mapping, only to protocol elements that belong to it. For example, > an application might apply the profile to its SASL authorization names, > or to some other protocol element that is not related to SASL at all. > But it cannot apply the profile to protocol elements that a particular > SASL mechanism depends on, because those belong to the mechanism and > exist below the SASL abstraction, where the application protocol spec > cannot even see them. Agreed. > That said, I think we need to be clear that the profile is _also_ > available for use by SASL _mechanisms_, since after all, that was no > small part of the original purpose of SASLprep. The same requirement > applies -- a mechanism that uses the profile must specify whether to do > case folding. Right. We have two direct customers here: SASL mechanisms and application protocols that don't use SASL (e.g., HTTP auth). What you're terming "SASL application protocols" are indirect customers and IMHO we don't want to encourage them to do interesting things with the strings that they feed into SASL implementations. > FWIW, I think both the "OLD" and "NEW" variants from Peter's message are > wrong. We should not say that case-folding MUST be done, because that > mandates its use everywhere. However, we should also not say that it > MAY be done, because that looks like we are granting permission for > implementations of the profile to do case-folding anytime they want, > even if that's not what the protocol says. Mostly agree. The PRECIS framework specification says that any PRECIS "usage" (of which so far we have nickname, username, password, XMPP localpart, and XMPP resourcepart) must specify its rules for casemapping (among other things). > Instead, we should keep only the sentence Peter proposes adding at the > end, or some variation thereof, which has the effect of leaving the > case-folding question up to the protocol applying the profile. Right. So we need to re-word the rule: REALLY OLD 2. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 3. Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. MORE RECENT 2. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 3. Uppercase and titlecase characters MAY be mapped to their lowercase equivalents. PROPOSED SOLUTION 2. SASL mechanisms and application protocols that directly use this profile MUST specify whether so-called additional mappings are to be applied, such as those defined in [I-D.ietf-precis-mappings]. 3. SASL mechanisms and application protocols that directly use this profile MUST specify whether uppercase and titlecase characters are be mapped to their lowercase equivalents. Then we'd have something like the follow-on paragraph I just posted: As noted, SASL mechanisms and application protocols that directly use this profile MUST specify whether case mapping and additional mappings are to be applied by implementations or deployments thereof. Note that some application protocols themselves re-use SASL (examples include IMAP [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the mapping rules defined for the relevant SASL mechanisms and not specify application-specific rules for that protocol's use of SASL or particular SASL mechanisms. Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Thu Jul 11 13:13:17 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10FD21F9FF4; Thu, 11 Jul 2013 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tppBgBQ6aAxN; Thu, 11 Jul 2013 13:13:12 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C82B921F9FF9; Thu, 11 Jul 2013 13:13:11 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 06920B807F; Thu, 11 Jul 2013 13:12:56 -0700 (PDT) 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=SIDw9JWOdupHK5sigGWB e0I0nOA=; b=K9oVLbsha19NvtUUCIS4Z+MjrNVKA2cZXS527mWdFjXm7C9Ej1Jy HmpHNzWlfEBdClPqJh9t0Bhjzk58FW7NFrcIvHrEM5cj6sO1ps/zQq0juC7ZrpwN 2k8D+9dYOqawcmQbN2X9ti5pDPZnrILhFMI0f9mVAoR5Rj0HVxgdyn8= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 4B5C7B8076; Thu, 11 Jul 2013 13:12:50 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so7499519wes.10 for ; Thu, 11 Jul 2013 13:12:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XR56LBXPV+rHfkle4LLTPpthXtJ5JF579kswa1Tz3Ho=; b=NZfkp/JuTKbu8Y1ZIDGj8uMqVYundNFNuiXyDoyVA8vEAb7a3QGUefh1cfLi7cD1/B v5vNjIUBfdG+hLW6uXSbCElRqa/H8AcM5RwYPd9SBXK1URi2WdOfKUAFGPrbHVX9vz3s gduqkHHgbw6L8wZuUwo1sAt4pJkvL81R2dO9pvKeDva/WWu40LlzvAp+BcyXy4AKKzri cOBK+FR6PR4PtbDBCLP+tsFX+9fw0c6vwNuCCLKpovj/6bDRHvX+9CpKegw7D0zMXN/Z GL0a68FVGTYHD4P108YibBBkt8HM2xUU1mazdvaI5aMY5SXY5ouvPdQpHwRbDndbFofG xJfQ== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr9516733wiv.36.1373573567834; Thu, 11 Jul 2013 13:12:47 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 13:12:47 -0700 (PDT) In-Reply-To: <51DF0B74.5000808@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> Date: Thu, 11 Jul 2013 15:12:47 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Marc Blanchet , precis@ietf.org Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:13:17 -0000 On Thu, Jul 11, 2013 at 2:45 PM, Peter Saint-Andre wrote: > NEW > > SASL mechanisms and application protocols that directly re-use this > profile MUST specify whether case mapping or additional mapping is to > be applied by implementations or deployments thereof. Note that some > application protocols themselves re-use SASL (examples include IMAP > [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the > mapping rules defined for the relevant SASL mechanisms and not > specify application-specific rules for that protocol's use of SASL or > particular SASL mechanisms. I don't really like the second sentence. In all cases *only* the application applies any stringprep to authorization IDs, and *only* mechanisms apply any stringprep to authentication IDs. (If a SASL framework implementation allows an app to provide an authentication DB for a mechanism then the app is providing a bit of mechanism functionality but it should still be understood as properly a part of the mechanism. We don't usually go into that level of detail in the core SASL RFC, and we shouldn't here. NEW SASL mechanisms that directly re-use this profile MUST specify whether case mapping is to be applied to authentication IDs, and when. SASL mechanisms SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. SASL application protocols that directly re-use this profile MUST specify whether case mapping is to be applied to authorization IDs. SASL application protocols SHOULD delay any case mapping of authorization IDs to the last possible moment, which happens to necessarily be on the server side. Note that, in keeping with RFC4422, SASL applications must not apply this or any other profile to authentication IDs. Note that, in keeping with RFC4422, SASL mechanisms must not apply this or any other profile to authorization IDs. Nico -- From stpeter@stpeter.im Thu Jul 11 13:28:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0E011E8122; Thu, 11 Jul 2013 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXeK6Vc8gq2Y; Thu, 11 Jul 2013 13:27:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8C21F995A; Thu, 11 Jul 2013 13:27:38 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9205341403; Thu, 11 Jul 2013 14:28:32 -0600 (MDT) Message-ID: <51DF1527.6080102@stpeter.im> Date: Thu, 11 Jul 2013 14:27:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:28:00 -0000 On 7/10/13 4:37 PM, Nico Williams wrote: > On Wed, Jul 10, 2013 at 3:49 PM, Peter Saint-Andre wrote: >> Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: >> >> OLD >> 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW >> 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. > > Do we need to give advice regarding the use of query strings for > cryptographic protocols? E.g., usernames as salts. I think we do. It seems to me that rules for handling query strings in a cryptographic protocol would be the responsibility of that protocol. Now, maybe you are suggesting that such protocols would apply the PRECIS profile we're defining here, if it provides what they need. Do you think that the rules in draft-ietf-precis-saslprepbis are sufficient? I get the sense you think more is needed, but I'm not yet sure exactly what. > Specifically, *mechanisms* must specify what normalizations (and let's > provide a nice one for them to all use) for such purposes. When you say "mechanisms" do you mean "SASL mechanisms" and when you say "normalizations" do you mean "Unicode normalization forms"? I ask because I think we have those bases covered, but perhaps you're looking for more... Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 13:30:28 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BA211E815B; Thu, 11 Jul 2013 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHfamRjcu6jJ; Thu, 11 Jul 2013 13:30:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C611E8122; Thu, 11 Jul 2013 13:30:22 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8DC4341403; Thu, 11 Jul 2013 14:31:32 -0600 (MDT) Message-ID: <51DF15DB.1010200@stpeter.im> Date: Thu, 11 Jul 2013 14:30:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Marc Blanchet , precis@ietf.org Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:30:28 -0000 On 7/11/13 2:12 PM, Nico Williams wrote: > On Thu, Jul 11, 2013 at 2:45 PM, Peter Saint-Andre wrote: >> NEW >> >> SASL mechanisms and application protocols that directly re-use this >> profile MUST specify whether case mapping or additional mapping is to >> be applied by implementations or deployments thereof. Note that some >> application protocols themselves re-use SASL (examples include IMAP >> [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the >> mapping rules defined for the relevant SASL mechanisms and not >> specify application-specific rules for that protocol's use of SASL or >> particular SASL mechanisms. > > I don't really like the second sentence. In all cases *only* the > application applies any stringprep to authorization IDs, and *only* > mechanisms apply any stringprep to authentication IDs. (If a SASL > framework implementation allows an app to provide an authentication DB > for a mechanism then the app is providing a bit of mechanism > functionality but it should still be understood as properly a part of > the mechanism. We don't usually go into that level of detail in the > core SASL RFC, and we shouldn't here. > > NEW > SASL mechanisms that directly re-use this profile MUST specify > whether case mapping is to be applied to authentication IDs, and > when. SASL mechanisms SHOULD delay any case mapping to the last > possible moment, such as when doing a lookup by username, username > comparisons, or generating a cryptographic salt from a username. > > SASL application protocols that directly re-use this profile MUST > specify whether case mapping is to be applied to authorization IDs. > SASL application protocols SHOULD delay any case mapping of > authorization IDs to the last possible moment, which happens to > necessarily be on the server side. > > Note that, in keeping with RFC4422, SASL applications must not apply > this or any other profile to authentication IDs. > > Note that, in keeping with RFC4422, SASL mechanisms must not apply > this or any other profile to authorization IDs. That is much more precise than what I had sketched out, and it looks good to me. Peter -- Peter Saint-Andre https://stpeter.im/ From jhutz@cmu.edu Thu Jul 11 13:46:11 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30E721F9DA8; Thu, 11 Jul 2013 13:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li9vk5fASbWy; Thu, 11 Jul 2013 13:46:05 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD921F9D91; Thu, 11 Jul 2013 13:46:05 -0700 (PDT) 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 r6BKjrs3026278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 16:45:53 -0400 (EDT) Message-ID: <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Peter Saint-Andre Date: Thu, 11 Jul 2013 16:45:53 -0400 In-Reply-To: <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, precis@ietf.org, Marc Blanchet , jhutz@cmu.edu Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:46:11 -0000 On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote: > > NEW > > SASL mechanisms that directly re-use this profile MUST specify > > whether case mapping is to be applied to authentication IDs, and > > when. SASL mechanisms SHOULD delay any case mapping to the last > > possible moment, such as when doing a lookup by username, username > > comparisons, or generating a cryptographic salt from a username. > > > > SASL application protocols that directly re-use this profile MUST > > specify whether case mapping is to be applied to authorization IDs. > > SASL application protocols SHOULD delay any case mapping of > > authorization IDs to the last possible moment, which happens to > > necessarily be on the server side. > > > > Note that, in keeping with RFC4422, SASL applications must not apply > > this or any other profile to authentication IDs. > > > > Note that, in keeping with RFC4422, SASL mechanisms must not apply > > this or any other profile to authorization IDs. > > That is much more precise than what I had sketched out, and it looks > good to me. Me too From nico@cryptonector.com Thu Jul 11 14:39:13 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4382E11E818E for ; Thu, 11 Jul 2013 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIgtzMIAgvJS for ; Thu, 11 Jul 2013 14:39:01 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8F611E8183 for ; Thu, 11 Jul 2013 14:39:01 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id EC205778070 for ; Thu, 11 Jul 2013 14:39:00 -0700 (PDT) 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=dFZGdk/8NMc7V2U2uWFoY1q1eNs=; b=VobTkKVslCn RQGxBWTpHoeo6xp3vagJ0n7w3Lm+F0Rdqo12V17cUs2KRCqLZfOJ3xGiJBK2L44t GgE8erTo7JQdAE4G3outGQTENoxpzmY0pyXF8MkIBUA36f/nK/IoJC5sIMKLUfdb tCxN0azDjwq6SOLoVImI5JD4ifc7kJso= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 8F18677805B for ; Thu, 11 Jul 2013 14:39:00 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so7492235wgh.15 for ; Thu, 11 Jul 2013 14:38:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+h6x0JoU3IHWrNyIDRluQdvRbYB3XY6vF6quADqLmrY=; b=WU7u/Cgtn5CrC46Lon1zabJ+Y8PAjc9fJQzUdXfH/4Wn29bWm5QeIyL0Gkn5ID62cv UM87m3cgSOESq+ANNUaPfND7Rw/aH4oZkEb/u8/Jpqcu2JYjXEMd2RpNATDMDVHlUFpN Ju356Y2T9VW6CjIb0irgSciLrI3wpnpiqtj+WLvVvjjiv43Z1LQvrJI+LQhG6a1bDofu KaWSeYfnBLG4zFu1OGH++2P6d+Op8DtxsK7apif5F5Rru/8Xt5mgE8AHA5+ihwfbSU5o Q3qut8JzZpy15SffkT0IiRGznnMlFJ+deIaXUeK2nzk0Z8sxTp6IhWaKrvMOYKu1dXmC EjPg== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr13927134wic.20.1373578738850; Thu, 11 Jul 2013 14:38:58 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 14:38:58 -0700 (PDT) Date: Thu, 11 Jul 2013 16:38:58 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:39:13 -0000 Is it my imagination or did there use to be text in the charter for this? Or was it text for a tutorial or introduction Informational RFC(s)? I looked in the archived charters but didn't see it, so it must have been in my imagination :( Nico -- From nico@cryptonector.com Thu Jul 11 14:40:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8247F11E812F for ; Thu, 11 Jul 2013 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN5Gifxx8LpG for ; Thu, 11 Jul 2013 14:40:04 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9469011E818E for ; Thu, 11 Jul 2013 14:40:04 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 2723942807A for ; Thu, 11 Jul 2013 14:40:04 -0700 (PDT) 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=M3yU8G9jE/tZ+8UwYGGKO9RteBI=; b=iwRsRrWtl5W JmxpX+Wy97cwx/0qeFrxhXZibNFDAkFyb60DnFvnDAc3lhvSse3huNS8rBY0rUi5 eKY1v2kau9uWJGLGW3cXcI/sUMpTAtU+fV3Vk95/ncq2r8jo0614iICCHVDqmCDn Uqd+tBxQ0LUR3LBWDTjwc47Nm8ThOeWI= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id B002A428079 for ; Thu, 11 Jul 2013 14:40:03 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so7351927wes.21 for ; Thu, 11 Jul 2013 14:40:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w7uUcfWFfQRFgT6X77p7fnK9RkpMwmcXQrYfymuFTvM=; b=Je0VJ8wdJRDzGOk9sVzjAF77xiktG32YzP5mO2e2VlA9kYpNCAa6/C2gAt6vdftcZt wSgDWkRBxCc1XR8BqC4MX7w3i0en4dnlMkHr/ZimjLoGYcf5sHfF/xgG2GPfn1RpWs6i yf+d4qUWgUhvl5pc0HqTsfBZNbVCy9MCpWAiEIph+fv/gA924S8PJLhemZmr/ZS2Kjum tDTDa2deDXB5qHa+e1rJ0NacS3y3bEkK+tbtDUHzrWYP3LpK0NU4njBYy3BxXHzLCF5B C/CbqgAhVcDtm74+TsAW9COMyoOR8XcmJzerspI2k0sJBocRkqGzhy9EZ+rp8s6ZLX+x iWEg== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr22653254wjn.23.1373578802221; Thu, 11 Jul 2013 14:40:02 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 14:40:02 -0700 (PDT) Date: Thu, 11 Jul 2013 16:40:02 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:40:09 -0000 I note this text in the current charter: Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. The thought occurs that Kerberos + kx509 + PKINIT can be a sort of PKCROSS. That makes me very interested. It shouldn't be very difficult to build that almost entirely out of off-the-shelf protocol pieces. It's not trival though: we'd definitely need policy for handling PKIX trust paths, and it wouldn't minimize the need for PK crypto. PKCROSS -or similar- is not in-charter at this time. Just a thought, Nico -- From hotz@jpl.nasa.gov Thu Jul 11 15:25:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE5F11E81D1 for ; Thu, 11 Jul 2013 15:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1h6RydefsEI for ; Thu, 11 Jul 2013 15:25:36 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6136B11E81D4 for ; Thu, 11 Jul 2013 15:25:36 -0700 (PDT) Received: from dhcp-128-149-177-90.jpl.nasa.gov (dhcp-128-149-177-90.jpl.nasa.gov [128.149.177.90]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6BMPXYM025703 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 11 Jul 2013 15:25:34 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: Date: Thu, 11 Jul 2013 15:25:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> References: To: Nico Williams X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org Subject: Re: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:25:42 -0000 On Jul 11, 2013, at 2:38 PM, Nico Williams = wrote: > Is it my imagination or did there use to be text in the charter for > this? Or was it text for a tutorial or introduction Informational > RFC(s)? >=20 > I looked in the archived charters but didn't see it, so it must have > been in my imagination :( >=20 > Nico > -- I do recall some discussions along that line, but I don't think they = made it all the way into the charter. I think Tom Yu was collecting the = input. I have advocated such a thing in the past. In particular, I think if we = had an API which hid the lower level tokenization and transport details = so the developer just did open()/send()/receive()/close() it would be = easier to gain adoption into new applications. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From nico@cryptonector.com Thu Jul 11 15:32:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C962A21F9FF4 for ; Thu, 11 Jul 2013 15:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmN-aVXv7o8n for ; Thu, 11 Jul 2013 15:32:34 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id E97AA11E8131 for ; Thu, 11 Jul 2013 15:32:33 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 31441584058 for ; Thu, 11 Jul 2013 15:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=t6PcNfsS8HfmAgM2IbLDeJC/GE0=; b=Eus5OQOQUx9 ilkwxyXJbPBnypTMatcnYQ/aU/1D0zvsVKi8GPyFohYiUDqPmL/Zb6WdGyvnJ6Ej i6dXvnchrWS7v735GF6Dk4SPIzEEAHLekDua1NIkKGNOtyyRsTAH2gRzPS3Tp4N+ pp00lEZBW7Uc2tGRJFE6FdSsM4j3jZKw= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id C0A8E584055 for ; Thu, 11 Jul 2013 15:32:31 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so42509wiv.1 for ; Thu, 11 Jul 2013 15:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bTgpcOHIpaTZeAdcHgayWoKe5iyYRfPqMq28mQlfY5M=; b=lOIGPbn8Wccu7/nJ/TLzTx0eguqJEhCkZAjWAi2vI2i89r8Lpg0xDKkFCyXscOIlMU O9JZ7RhR4BRVoIq1qJQarYK+4ShKJKinOdJOK2T1S3E/1uucMxdir3dkzI07volKIRAt n4OiCcsRu+FQMUPmhGOfKV0MEpwvmAcvgC6k93U/HG5CCXgwz4cC2jdHOujOozwniVvN RyhsSv0OCXh5staBeTh0qxryH0AkVhy1m+3dO/hhdsG8B2ImnSG/zKqI/BLrOSgqXZVg VWty9qMvhW4jSvLPVf0zcxeyZY+yxJq6xcIB0uiLSHaV5Eae9CTV2iJ8IvCTcoBBO59+ x6aQ== MIME-Version: 1.0 X-Received: by 10.180.74.197 with SMTP id w5mr20969wiv.20.1373581950034; Thu, 11 Jul 2013 15:32:30 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 15:32:29 -0700 (PDT) In-Reply-To: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> References: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> Date: Thu, 11 Jul 2013 17:32:29 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:32:38 -0000 On Thu, Jul 11, 2013 at 5:25 PM, Henry B. Hotz wrote: > I do recall some discussions along that line, but I don't think they made= it all the way into the charter. I think Tom Yu was collecting the input. > > I have advocated such a thing in the past. In particular, I think if we = had an API which hid the lower level tokenization and transport details so = the developer just did open()/send()/receive()/close() it would be easier t= o gain adoption into new applications. Roland's libknc does this. I don't think it's released yet, and it only covers the ordered octet stream case, but that, I think, is what you meant. libknc has an empty context + mutators/accessors, like the new API for the channel bound flag. IMO that's much easier to use. I also think that the extended naming API also makes it easier to deal with complex naming problems (as in the TLS server PKI, and PKIX in general) -- easier than dealing in raw, mechanism-specific naming. Nico -- From hotz@jpl.nasa.gov Thu Jul 11 15:50:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84121F9BAB for ; Thu, 11 Jul 2013 15:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STiUWurmjeKX for ; Thu, 11 Jul 2013 15:50:52 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id EE41A21F9AC2 for ; Thu, 11 Jul 2013 15:50:51 -0700 (PDT) Received: from dhcp-128-149-177-90.jpl.nasa.gov (dhcp-128-149-177-90.jpl.nasa.gov [128.149.177.90]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6BMoiig027405 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 11 Jul 2013 15:50:45 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: Date: Thu, 11 Jul 2013 15:50:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8B4A0DB6-EB33-4703-940B-CA06CF29591C@jpl.nasa.gov> References: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> To: Nico Williams X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org Subject: Re: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:50:58 -0000 Is that krb5-specific, or is it GSSAPI in general? On Jul 11, 2013, at 3:32 PM, Nico Williams wrote: > Roland's libknc does this. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Thu Jul 11 15:54:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5448911E8139 for ; Thu, 11 Jul 2013 15:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVBq3r8HI19f for ; Thu, 11 Jul 2013 15:54:45 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 8007511E81B9 for ; Thu, 11 Jul 2013 15:54:45 -0700 (PDT) Received: from dhcp-128-149-177-90.jpl.nasa.gov (dhcp-128-149-177-90.jpl.nasa.gov [128.149.177.90]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6BMsiht015506 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 11 Jul 2013 15:54:44 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: Date: Thu, 11 Jul 2013 15:54:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> References: To: Nico Williams X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:54:51 -0000 On Jul 11, 2013, at 2:40 PM, Nico Williams = wrote: > I note this text in the current charter: >=20 > Prepare a standards-track protocol to solve the use cases addressed > by draft-hotz-kx509-01 including new support for digital > signatures. Yeah, I really, really need to get back to this. > The thought occurs that Kerberos + kx509 + PKINIT can be a sort of > PKCROSS. =20 Please elaborate? The reason *I* would combine kx509 with PKINIT would be the use case of = someone needing X.509 credentials on multiple client computers at once. = This is a real use case for us. I was thinking of PKCROSS the other day as a possible solution to a = rather specialized problem: our realm-name conflict between Unix and AD = kerberos. You might think that for one-way trusts from another realm = (like a smart-card-only realm) it would be OK to have both of them trust = the other one. Trouble is that with symmetric crypto if someone hacked = the AD realm they could use the one-way trust key to forge other-realm = cross-realm authentications to the Unix realm. (Not picking on = Microsoft. The problem is symmetric.) I suspect that PKCROSS might = allow a solution to that, though I have not read the draft to make sure. = I also suspect that it's too specialized a use case to justify the = standards effort that would be required. > That makes me very interested. It shouldn't be very > difficult to build that almost entirely out of off-the-shelf protocol > pieces. It's not trival though: we'd definitely need policy for > handling PKIX trust paths, I've lost a lot of interest in PKIX, per-se. The overall revocation = system is architecturally broken, and I can't tell if the co-chairs even = understand the issues. Instead we have vapor-ware like SCVP and TAMP. > and it wouldn't minimize the need for PK > crypto. >=20 > PKCROSS -or similar- is not in-charter at this time. If we can address use cases which PKIX doesn't, then it sounds valuable. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From lukeh@padl.com Thu Jul 11 15:59:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FF411E813B for ; Thu, 11 Jul 2013 15:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwK-cyV5+jJD for ; Thu, 11 Jul 2013 15:59:37 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDF11E8136 for ; Thu, 11 Jul 2013 15:59:36 -0700 (PDT) Received: by us.padl.com with ESMTP id r6BMxNf5028054; Thu, 11 Jul 2013 18:59:26 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: Date: Fri, 12 Jul 2013 08:59:23 +1000 Content-Transfer-Encoding: 7bit Message-Id: <0B2EBE29-D8C3-412B-B9BA-15DF0E63841B@padl.com> References: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> To: Nico Williams X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,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] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:59:41 -0000 On 12/07/2013, at 8:32 AM, Nico Williams wrote: > Roland's libknc does this. I don't think it's released yet, and it > only covers the ordered octet stream case, but that, I think, is what > you meant. libknc has an empty context + mutators/accessors, like the > new API for the channel bound flag. IMO that's much easier to use. https://github.com/elric1/knc -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From nico@cryptonector.com Thu Jul 11 16:00:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E83B11E813B for ; Thu, 11 Jul 2013 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8ud3tkNMEk9 for ; Thu, 11 Jul 2013 16:00:11 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3051111E81C0 for ; Thu, 11 Jul 2013 16:00:11 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id D0FCB508084 for ; Thu, 11 Jul 2013 16:00:10 -0700 (PDT) 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=5p/ltatnu2ysRDJnzxIJ UzbIEBA=; b=M14IZRf9WyB1lP5m8ozpi1SgnUvw+Hp+TtRoIYWyGIHmEeK4qVhQ HTX6d6JthgA65gcRCfatawMWZ8fDaINkZS7Idnm6qcs13I1a8J5O0lcKtNlujjE/ cXUjUImTn1U8cQ/6z9BEC+1LSgZW8wvgoNqlS7sO56nN6yk4EwNiF94= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 7406E508072 for ; Thu, 11 Jul 2013 16:00:10 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so56651wiv.9 for ; Thu, 11 Jul 2013 16:00:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3USOZaT41ADKd+b2Uu7HaQW6K1wYPjS+kXk85W988Yk=; b=m+vctEsfq40lJcvtRwVT5K458fq4dqB4ib4TlM+CWajbefrFr+qheNTXFmv+iTWJsc 18YLBPWH9wfauFvgRMm73l2dbPNoPmxOctGERzQUbuWIR2qRAaSQx+eqn8ZZaA+EOz3W WXIkI+XlscdK9v6lTv7JdsXUhstFSDdu50X3Cnv8NpEvk8v12BSRH21rjrY8E3BNkZlz 0+MAY9G8DIa/hh3ewD+mo37NgO4NdVg2cHVmvoFqqRFVF7z7sOlAXFziiYp3VUTD9Rh7 4AY08bq8h8rCeNH00a8Ggzy5eR0tNb2uxmbvspcbh9yr6l/YxiSCrPyimIAbPlm8mPvq xcOw== MIME-Version: 1.0 X-Received: by 10.194.22.1 with SMTP id z1mr22958570wje.14.1373583608982; Thu, 11 Jul 2013 16:00:08 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 16:00:08 -0700 (PDT) In-Reply-To: <8B4A0DB6-EB33-4703-940B-CA06CF29591C@jpl.nasa.gov> References: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> <8B4A0DB6-EB33-4703-940B-CA06CF29591C@jpl.nasa.gov> Date: Thu, 11 Jul 2013 18:00:08 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:00:16 -0000 On Thu, Jul 11, 2013 at 5:50 PM, Henry B. Hotz wrote: > Is that krb5-specific, or is it GSSAPI in general? The 'k' in it is for "Kerberos", but in fact it uses the GSS-API in a completely generic way. It uses these GSS functions only: gss_accept_sec_context gss_delete_sec_context gss_display_name gss_display_status gss_import_name gss_init_sec_context gss_release_buffer gss_release_buffer gss_release_cred gss_release_name gss_unwrap gss_wrap and does not interpret principal names in any way, leaving that to the application. (Note that it uses gss_display_name() and not gss_export_name(). IMO it should output all of: display name, exported name token, and exported composite name token if available. I'll file an issue with it.) Also, it should support credential export (where available, and apps should be able to gss_store_cred() delegated creds, also where available). Nico -- From nico@cryptonector.com Thu Jul 11 16:14:21 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D0E21E804D for ; Thu, 11 Jul 2013 16:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcH17AcpGpGe for ; Thu, 11 Jul 2013 16:14:16 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAB721E804B for ; Thu, 11 Jul 2013 16:14:16 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 05DD71B406E for ; Thu, 11 Jul 2013 16:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=30XjUmNM2Zoms56OfCRLdyexX4Q=; b=quj7yV1v3fv dgN3jD6vDkMegSuLE3tjQAKx1hMg5kLjn7JS97QCpV83TyXaT+nxd2qzL9ohe4wH srY8sdxkgBt2sddHtfxztFILYL8JO6L2HVhIgxWSv4ps0FHpWHkfBeaPaOgccWnY JtXwg+mXBOh9/BavNTl0mXopMveKIGoA= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 7FF4F1B406B for ; Thu, 11 Jul 2013 16:14:15 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so83559wgg.3 for ; Thu, 11 Jul 2013 16:14:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=671o3ItJFLNpy8vWRD+srvvuafKixCBceBuTsGM3XgM=; b=lNHGIroN4p+EyR4HxtBDlE7ZTVi8G19elKY6A00t1c9egOUMBgw+ZG48vw4cb22DOB bTlYap7kuEBrgI9g/GH8gAlIoHwCNp+vm0hveZ41Pee7dmudEz6cmiJcE52JEQ7MZWJW QdveC6mlyJYZ07HqitiJy79OBWzH/n6Cbp1UyxKSVchwXMhcGB7xd2Ab//1qpkAsg3B4 TYZsX4/Qg3h1xW4Inqa2w0FSroxygRswzQy6qdic7xh7mDUE3hq1VPz+tPgpQjFI9DwR MwZ4rITXq7+WzAabKN3YugCR7pgQJQI2PbxKjnCnL0XCOC2WxVLxejFfcO1DIvqF1c8n w17Q== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr68951wib.33.1373584453765; Thu, 11 Jul 2013 16:14:13 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 16:14:13 -0700 (PDT) In-Reply-To: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> Date: Thu, 11 Jul 2013 18:14:13 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:14:21 -0000 On Thu, Jul 11, 2013 at 5:54 PM, Henry B. Hotz wrote: > On Jul 11, 2013, at 2:40 PM, Nico Williams wrote: >> The thought occurs that Kerberos + kx509 + PKINIT can be a sort of >> PKCROSS. > > Please elaborate? Assume: - I have a TGT for realm FOO.EXAMPLE. - I want to talk to a service in BAR.EXAMPLE. - I have no credentials for any principal in BAR.EXAMPLE. - I can find no all-Kerberos trust path between FOO.EXAMPLE and BAR.EXAMPL= E. - I can get a certificate for my client principal name using a kx509 service run by FOO.EXAMPLE. Then maybe: - BAR.EXAMPLE accepts my use of that certificate (and private key) with PKINIT and issues me a Ticket with nico@FOO.EXAMPLE for the requested service at BAR.EXAMPLE (likely krbtgt/BAR.EXAMPLE@BAR.EXAMPLE). Here BAR.EXAMPLE's KDC will have to build and validate a trust path for my certificate's trust., extract the krb5 SAN, decide whether to accept it, and if it does, issue a Ticket for that SAN. The transit path recorded in the Ticket should be FOO.EXAMPLE->->BAR.EXAMPLE. It so happens that Kerberos can represent x.500 naming in transit paths -- how convenient! I'm not sure that implementations actually exist of x.500 realm naming in Kerberos, but, hey. > The reason *I* would combine kx509 with PKINIT would be the use case of s= omeone needing X.509 credentials on multiple client computers at once. Thi= s is a real use case for us. Presumably all from different realms? Would that be the same as described above? > I was thinking of PKCROSS the other day as a possible solution to a rathe= r specialized problem: our realm-name conflict between Unix and AD kerbero= s. You might think that for one-way trusts from another realm (like a smar= t-card-only realm) it would be OK to have both of them trust the other one.= Trouble is that with symmetric crypto if someone hacked the AD realm they= could use the one-way trust key to forge other-realm cross-realm authentic= ations to the Unix realm. (Not picking on Microsoft. The problem is symme= tric.) I suspect that PKCROSS might allow a solution to that, though I have= not read the draft to make sure. I also suspect that it's too specialized= a use case to justify the standards effort that would be required. All trusted-third-party protocols have this problem in the end. What can you do? You have to trust all your KDCs, for all those realms that you care about. You might address this partially by havig Tickets bear the certificates used by the clients as KDC-issued authorization-data, so that applications could perform PKIX validation, including cert revocation checking, apply various policies, ... >> That makes me very interested. It shouldn't be very >> difficult to build that almost entirely out of off-the-shelf protocol >> pieces. It's not trival though: we'd definitely need policy for >> handling PKIX trust paths, > > I've lost a lot of interest in PKIX, per-se. The overall revocation syst= em is architecturally broken, and I can't tell if the co-chairs even unders= tand the issues. Instead we have vapor-ware like SCVP and TAMP. Oh, it's not PKIX I care about. I just want something that scales better than symmetrically keyed Kerberos cross-realm principals, and with better security policies (e.g., sysadmins do not have to exchange passwords from which the x-realm keys are derived; they might exchange passwords to authenticate the key exchange, but the sysadmins should not learn the keys as a result, or they might exchange certificate fingerprints, ...). >> PKCROSS -or similar- is not in-charter at this time. > > > If we can address use cases which PKIX doesn't, then it sounds valuable. The use case that PKIX doesn't address is where you've deployed Kerberos widely and you want to either a) scale it up mode widely (e.g., in the EDU world), and/or b) remove the manual symmetric key exchange, and/or c) not have to worry about cross-realm key rollover (or enctype changes, e.g., to go to stronger enctypes as they become available). Nico -- From stpeter@stpeter.im Thu Jul 11 16:32:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D41C11E81CD; Thu, 11 Jul 2013 16:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+bsKwVvfC7u; Thu, 11 Jul 2013 16:32:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4311E81BB; Thu, 11 Jul 2013 16:32:33 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D4FD54134B; Thu, 11 Jul 2013 17:33:42 -0600 (MDT) Message-ID: <51DF408E.6010201@stpeter.im> Date: Thu, 11 Jul 2013 17:32:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org, Marc Blanchet Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:32:38 -0000 On 7/11/13 2:45 PM, Jeffrey Hutzelman wrote: > On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote: > >>> NEW >>> SASL mechanisms that directly re-use this profile MUST specify >>> whether case mapping is to be applied to authentication IDs, and >>> when. SASL mechanisms SHOULD delay any case mapping to the last >>> possible moment, such as when doing a lookup by username, username >>> comparisons, or generating a cryptographic salt from a username. >>> >>> SASL application protocols that directly re-use this profile MUST >>> specify whether case mapping is to be applied to authorization IDs. >>> SASL application protocols SHOULD delay any case mapping of >>> authorization IDs to the last possible moment, which happens to >>> necessarily be on the server side. >>> >>> Note that, in keeping with RFC4422, SASL applications must not apply >>> this or any other profile to authentication IDs. >>> >>> Note that, in keeping with RFC4422, SASL mechanisms must not apply >>> this or any other profile to authorization IDs. >> >> That is much more precise than what I had sketched out, and it looks >> good to me. > > Me too Great. If there are no objections from my co-author in the next 24 hours or so, I'll submit a revised I-D. I'd really like to finish off all this i18n stuff... :-) Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Thu Jul 11 17:20:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5621F9B89 for ; Thu, 11 Jul 2013 17:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf5Ak3Zbg7s4 for ; Thu, 11 Jul 2013 17:20:19 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id D82F421F9B7D for ; Thu, 11 Jul 2013 17:20:18 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 5AD1959805F for ; Thu, 11 Jul 2013 17:20:17 -0700 (PDT) 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=9d5Wt5idD+enVU6JBdVe B8+k7rM=; b=O+SPX0pGgppAS5PYwRSTILln2pupWkamAV3eGaR8D7QQlq+Eh7Iy gXS6npyBvUfcmcdlNHQA7n66J4vReGF+jD0/8LptOBQpSRtAWa8Ts6zKDCzbYn07 9jm4WhEousAi8tYeC1n+6x6vUF5xF3k2CyIXUiEI5ox7bT4hrrO8i7A= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id EF27D598058 for ; Thu, 11 Jul 2013 17:20:16 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so7376808wes.24 for ; Thu, 11 Jul 2013 17:20:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tvDGieD8yQ+sMBn2u7nkA4AZ3YXHXc8lQ/ppv4emMxM=; b=NEAX5WI0hStgMUSVudns3ZfSFFvdfrnUQy45cZGzxCqt/b5Y0Sc5jwqGT2Gi5Qgxtf tvnPEXkg0eU/PSY2GZs8wW/r5kNzw+WHjZUYx/d8MUJ6OV8+IAiaQvmlyZeM2HPgQlOE ZMMCXeCe2WC4bEt+X0na4rpKeoKivlKX+NHm19wYlr2TOJOZcb3idoyJJOBfTLAhssyT 4OHqldB476zh34RAtla5Rz1kjf+0WMJn8ZwSIRtDDOmDL3m9SASjP/dJSfxPX/jwHvuf all4Y8IjP02lTPShbVgjpDKhQ7VDaC9JZ2WES4weVMHlKgola5VfsP0DgEHpGAeJOb85 89Fw== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr21821633wjc.90.1373588415502; Thu, 11 Jul 2013 17:20:15 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 17:20:15 -0700 (PDT) In-Reply-To: References: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> <8B4A0DB6-EB33-4703-940B-CA06CF29591C@jpl.nasa.gov> Date: Thu, 11 Jul 2013 19:20:15 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, "Roland C. Dowdeswell" Subject: Re: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:20:25 -0000 On Thu, Jul 11, 2013 at 6:00 PM, Nico Williams wrote: > On Thu, Jul 11, 2013 at 5:50 PM, Henry B. Hotz wrote: >> Is that krb5-specific, or is it GSSAPI in general? > > The 'k' in it is for "Kerberos", but in fact it uses the GSS-API in a > completely generic way. It uses these GSS functions only: > Also, the libknc API gives the application the actual gss_name_t values, so the application can do what it likes. So, yes, libknc is very much generic, not Kerberos-specific. Perhaps Roland should rename it :) The knc(1) program only deals in display names. It could export the initiator's name and give it to the application; since the protocol by which knc(1) talks to the server program is textual, the exported name token would have to be hex encoded. So knc(1) the program isn't quite generic enough, but it's very close. Nico -- From nico@cryptonector.com Thu Jul 11 18:31:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749A511E81F0 for ; Thu, 11 Jul 2013 18:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWOBq0BxIz26 for ; Thu, 11 Jul 2013 18:31:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id D458611E81DD for ; Thu, 11 Jul 2013 18:31:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 47B36594062 for ; Thu, 11 Jul 2013 18:31:31 -0700 (PDT) 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=ZuVqvuPbGpczg8ERyO/t Ty1O6Ss=; b=bIWEpSiiz75eFrLNzCWHzp7fgToPMGKEVAodKV7hwy7gliQLriHf Q/QB7+1U5e0+FIOrV58ajDJFB9kn5ELyGjC89SnwLW8jNow1m9UGQjgzHkACj37L xjbr3oQZnAHQym9ekeTUNAjjXcogO8Pc9J8DV5yNWxg9sZa5jsv8YZc= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id EBC7A594061 for ; Thu, 11 Jul 2013 18:31:30 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so7562112wev.16 for ; Thu, 11 Jul 2013 18:31:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tOb5R0DUaN/9EznQPqUI4lJvKhLJ48SsdNgtmW4OEdg=; b=mcAwGF788HQbx23pKvbWVNiiuEiNbthKwqR9WYG+GHDFpCWTi6ZtTwGCuWu07vTP3l ime8nn7BzuadCX6nKr2uYuC13/pdLFiwCgmK7xjOIeCb7slh0OyCNrvqMz+Rvcht5y40 3B5zLIlRFfqdYLazI623YQHHEKMIwG1bbFHoQGzk1FXk83lDalmds9Y1GAxpTF/FkjJb vJhtBCphyKQyMT3rfhUQqMQO1J+brvT0CSoz10Bu/4+DG2w0840bi7+5MZCJWCKVQlTW kfWopAGETRI00P17BdLupQxq5kX+eSU0veCCv4wV38Qej7Yei4KXKokRY+Sg/judJUKV jfIw== MIME-Version: 1.0 X-Received: by 10.180.84.70 with SMTP id w6mr264450wiy.36.1373592689062; Thu, 11 Jul 2013 18:31:29 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 18:31:28 -0700 (PDT) In-Reply-To: References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> Date: Thu, 11 Jul 2013 20:31:28 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 01:31:37 -0000 On Thu, Jul 11, 2013 at 6:14 PM, Nico Williams wrote: > On Thu, Jul 11, 2013 at 5:54 PM, Henry B. Hotz wrote: >> On Jul 11, 2013, at 2:40 PM, Nico Williams wrote: >>> The thought occurs that Kerberos + kx509 + PKINIT can be a sort of >>> PKCROSS. >> >> Please elaborate? There are some downsides to this approach: - it requires kx509 (not a big deal, but, it is one more piece) - it requires PK for every x-realm TGT obtained when there's no symmetrically-keyed x-realm principals available - the client realm doesn't find out about the client's interest in talking to the target realm The originally-envisioned PKCROSS protocol, IIUC, also had the first two problems. The third might be considered a feature (privacy!), and probably justifies the first problem. The second problem can be cured by having realms proactively use this same protocol as part of exchanging symmetric cross-realm principal keys. On the plus side, it'd get us exactly what we want from PKCROSS: - PKI or manual trust anchor exchange for x-realm trust setup Note too that leap-of-faith is also possible, both on the client side and on the target side: the target realm's KDCs could accept *any* PKI trust path, record it in the transit path, and NOT set the TRANSIT-POLICY-CHECKED ticket flag. With this and DNS (and DNSSEC) we can scale Kerberos cross-realm. The cross-realm symmetric key exchange protocol would be trivial: - use a cert with a krbtgt/REALM@REALM id-pkinit-san to get a Ticket (with PKINIT) for the target's krbtgt/TARGET@TARGET - use a new KDCOptions flag to indicate that the above Ticket's session key is to become the long-term key for krbtgt/TARGET@REALM which TARGET's KDCs could reject for reasons such as: not supported, couldn't validate the source realm's PKIX trust path, ... Nico -- From nico@cryptonector.com Thu Jul 11 19:57:34 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B921F9A92 for ; Thu, 11 Jul 2013 19:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en9Y7OyEOwBe for ; Thu, 11 Jul 2013 19:57:30 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6457521F9A37 for ; Thu, 11 Jul 2013 19:57:30 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id E5DED20202C for ; Thu, 11 Jul 2013 19:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=q1g+SXhZEkPHlHniaaQ+nK2Ut+g=; b=E5BLFnSYIqU Lh7AuMi9lY7IKGgUrbmtiSXmDou1JpfmPoskzuFaOtY7dugGmwBVAPyf7+3oOUS7 5vu5rQwB/otetr1CFRXATptBZCzBhslcLz9rVVjmNurwu65T+YmqPV42WOnh2UsN 3bNaaf7i3wIz4TM5GMWKZzHe0NlTz9qQ= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 89231202022 for ; Thu, 11 Jul 2013 19:57:29 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so7334626wes.26 for ; Thu, 11 Jul 2013 19:57:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=9iYIY3VbdxrsnHKamluwinqI3c94C1DQj5RLCJnHBUI=; b=X+0c1DcdVNe42aRHOTKjmthLusMXf7M+7gfkZt8FtpNuDMgRgYAo349K1w6YWpgg9V KGYHgt1EH46ddUK9OteJ3AsbiDUY3E0oaJhxb9mGgz3chy+MoEbrlFxvNZ6Gyg1a31vN 49lxu1XRZRj6UlBVDiWEPQwQqB1I5z2iPpDm8Kn5FO0PmRIsD/bRSLNMssuq71Ie83eY gh+NEo1kNb7A4yxub1AD0wUAAAed53Tw7DAe0ifbdVdBN5DX9bAe3pFDaBmFJMbd6rok 7l98muVeiGMYVfanBmLXzW6Tn8Li3vuefD45ODdAHUvCuIxfp+FrncO+j2uY102SrAS3 cE/g== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr390800wiv.36.1373597847941; Thu, 11 Jul 2013 19:57:27 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 19:57:27 -0700 (PDT) Date: Thu, 11 Jul 2013 21:57:27 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS -- I-D submitted X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 02:57:34 -0000 http://www.ietf.org/id/draft-williams-kitten-krb5-pkcross-00.txt From nico@cryptonector.com Thu Jul 11 20:14:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1384911E814E for ; Thu, 11 Jul 2013 20:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M-fKnP5mInl for ; Thu, 11 Jul 2013 20:14:45 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id BE62E11E80E7 for ; Thu, 11 Jul 2013 20:14:45 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 42B6A26C05B for ; Thu, 11 Jul 2013 20:14:45 -0700 (PDT) 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=LeEptJpklAMkkA5TAn4c 3QRm8iQ=; b=NTgoq+itNOht5q9pxQh2ojLeaEvOVqUYvJN8Ji72/zIDEq1k97XK cvZseSa8wap9oWxhdCk3hMhAet25wT0UaQorkYMG2Hy3SPSD6hFMqvg9y2I0Fq+1 f2whX4ykbg6Ayj77eZUG0KOdZvw1HLux6bKCMFuMW+Af3cP+5sbkXd0= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id DA9B726C057 for ; Thu, 11 Jul 2013 20:14:44 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so7709440wev.30 for ; Thu, 11 Jul 2013 20:14:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QjDaAAdvbDH9tITnOytKXGNdsQr014J26Q4ZY55ukqc=; b=D5/4cwRG/7D6N3M8fBztKxx4eZ2AFGTROf+B5BcrH+9qY+j6cvicF429KbZAKvZmPu UReEpJvUoY08aUZO48IJrHBPcAx3I0dB0Phj2rXYcBuiQ/xksq5ok1d6xWdP7KErOkwo jEmiIT/EUfDHdvdXUFKdGNPIoGTTlGMdr2p5SoBXgQRZDJnOtgwnQVnuUuhn9u/DA4Ok ZW44XiX+5bJ81ewBQpW/XIALABblTn/FdvMyDGhYowsh+7kz/orNm1xSbm9YlnAX7IB3 rh2M2y3E2xJztuATh2VNlLjim6E19aDFx/Yhp772MxRn3US6vtMOpiFJFpn/fPBeAa/5 jyNw== MIME-Version: 1.0 X-Received: by 10.180.74.197 with SMTP id w5mr455458wiv.20.1373598883293; Thu, 11 Jul 2013 20:14:43 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 20:14:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 22:14:43 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS -- I-D submitted X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 03:14:50 -0000 On Thu, Jul 11, 2013 at 9:57 PM, Nico Williams wrote: > http://www.ietf.org/id/draft-williams-kitten-krb5-pkcross-00.txt Immediately followed by a -01 adding mention of DANE [RFC6698]. From nico@cryptonector.com Thu Jul 11 21:06:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB5711E80A2 for ; Thu, 11 Jul 2013 21:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiE4YbrVbOjs for ; Thu, 11 Jul 2013 21:06:38 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9024E21F9AEE for ; Thu, 11 Jul 2013 21:06:38 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 024B3B805B for ; Thu, 11 Jul 2013 21:06:38 -0700 (PDT) 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=cc0hGlYNfG0dUGIM98KQ t7pzkdE=; b=qKbKMDau+Iit6+zZBrZPyRz3m63QwlBoo7GmckLudslIDszexkaw 8N89Zp2WZ3pgmRfhwzqXGir86Cs5UYKHpNbXLwrqYrmfZpiSrKj9PQcoQ5EF6q50 7WOB6ceh0IJAW1WxgSLKZswkfQDYG06GB3z/NUNpnO3zqxixHeAaRpM= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 64453B800A for ; Thu, 11 Jul 2013 21:06:37 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so204983wiw.17 for ; Thu, 11 Jul 2013 21:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OXx0ecRCL6Zm0h+tsSLm7e6ZxhitfGs5Dh9Cy1uQ9wE=; b=MjrVnAg1CioKbk/0coji/Hd1TJwEMSJXVTUiAZK5/TL1PaEq8jZOUkN6psfOtHcUUU As9VvXO/OOaGvky6llRt4n+K0CEKRaQ/uZVvM/v74gRFitFic2CE0EB8OhYEQlac+igU mqcHNOfqXMbk4+DA9jElnBCZDA4qqUk2RD8Md3fpaySEn6Az1lvYpdQGG7n0uFNnCvQw qlJgOWeUV8KyoWpNQxA0gia0m7WBWTmehSKWckkqLrHs/vccyyJf6ViF4DhO62xHFfDZ BH0ca0W0+s9YQqT5WEmDxmndD9ZC9BAeWvxF1W05mXgQHgVa09SXp3KUzvvKJldJ4gfB NPsQ== MIME-Version: 1.0 X-Received: by 10.180.74.197 with SMTP id w5mr532796wiv.20.1373601995351; Thu, 11 Jul 2013 21:06:35 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 21:06:35 -0700 (PDT) In-Reply-To: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> Date: Thu, 11 Jul 2013 23:06:35 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:06:43 -0000 On Thu, Jul 11, 2013 at 5:54 PM, Henry B. Hotz wrote: > On Jul 11, 2013, at 2:40 PM, Nico Williams wrote: > >> I note this text in the current charter: >> >> Prepare a standards-track protocol to solve the use cases addressed >> by draft-hotz-kx509-01 including new support for digital >> signatures. > > Yeah, I really, really need to get back to this. Oh. You were being sarcastic. The RFC issued (and I missed that). Har. From rra@stanford.edu Thu Jul 11 21:34:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81BF11E81F7 for ; Thu, 11 Jul 2013 21:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAvagua-Zzf0 for ; Thu, 11 Jul 2013 21:34:13 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id D844611E80BA for ; Thu, 11 Jul 2013 21:34:13 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A041F45DC4B; Thu, 11 Jul 2013 21:34:13 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id C90C045DC3E; Thu, 11 Jul 2013 21:34:12 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id B4F532F4E6; Thu, 11 Jul 2013 21:34:12 -0700 (PDT) From: Russ Allbery To: Nico Williams In-Reply-To: (Nico Williams's message of "Thu, 11 Jul 2013 23:06:35 -0500") Organization: The Eyrie References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Thu, 11 Jul 2013 21:34:12 -0700 Message-ID: <87mwpsflbv.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:34:19 -0000 Nico Williams writes: > On Thu, Jul 11, 2013 at 5:54 PM, Henry B. Hotz wrote: >> On Jul 11, 2013, at 2:40 PM, Nico Williams wrote: >>> I note this text in the current charter: >>> Prepare a standards-track protocol to solve the use cases addressed >>> by draft-hotz-kx509-01 including new support for digital >>> signatures. >> Yeah, I really, really need to get back to this. > Oh. You were being sarcastic. The RFC issued (and I missed that). Har. No, I don't think he was being sarcastic. The RFC that was published documents the existing protocol, which is kind of broken. I'm pretty sure this charter action is about *revising* that protocol and making it more sane. -- Russ Allbery (rra@stanford.edu) From nico@cryptonector.com Thu Jul 11 21:55:13 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C021F9D11 for ; Thu, 11 Jul 2013 21:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iurorh5eRHAs for ; Thu, 11 Jul 2013 21:55:08 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8394321F9CE9 for ; Thu, 11 Jul 2013 21:55:08 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E053D9406E for ; Thu, 11 Jul 2013 21:54:57 -0700 (PDT) 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=Zi3rLploH68RwiExiSb/ nSpQmaM=; b=I2tcGsV7vumGIkN3vgEc7QBlWZvZm4Hq3a9GpHPAViZNj3KMzu8M 9rxHmV4yBArZ6sdOh3q6aH9IBt1f48k7edratwO649IlGirK45A3i+L/pElYYHld ecjQLfnNsGDbeH7Qlu+ceDZXAkiT9H7tfMCydLopg7xYHK3U49u5iwQ= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 819099405C for ; Thu, 11 Jul 2013 21:54:57 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so229555wiv.8 for ; Thu, 11 Jul 2013 21:54:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s91doall324hs9bSq3mCdwCrrYR67Fs5veKJSI5vubA=; b=WT+Xe3aedn253n45udxCSywVnDjIxaXbvfi3JKCPhxr0b4nh9HRufHtAVGuLCcoe3e dLjR+FG/zQzYQxRmNGpgjifyO04EGuI2Zl3dHd4IJz8Q0TwmNwWMEwokfpoaPswEadZH Kb/wKxbXBS2IXxpIEnBf5nHyHglKCh/rkf+GWKXJ+yeBiVOiTy09J2C2w8GCfJJ2raPv Uzst3I80bUbR7kZLxk+FLoY+/jRYKBLYXT8NMAz4VoWBr6IxPqHkof5Ur9FiDwR5g7OF z448Z+tSgR3s0YOzsWUmTBzAy5ngr2sLhi40+xsQjDGcw4+VYt6k5bfiE5qLLKShulHW EhTw== MIME-Version: 1.0 X-Received: by 10.180.74.197 with SMTP id w5mr606350wiv.20.1373604895831; Thu, 11 Jul 2013 21:54:55 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 21:54:55 -0700 (PDT) In-Reply-To: <87mwpsflbv.fsf@windlord.stanford.edu> References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> <87mwpsflbv.fsf@windlord.stanford.edu> Date: Thu, 11 Jul 2013 23:54:55 -0500 Message-ID: From: Nico Williams To: Russ Allbery Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:55:13 -0000 On Thu, Jul 11, 2013 at 11:34 PM, Russ Allbery wrote: > No, I don't think he was being sarcastic. The RFC that was published > documents the existing protocol, which is kind of broken. I'm pretty sure > this charter action is about *revising* that protocol and making it more > sane. Ah. OK. How much change do you think it needs? Some? Or are we talking about a complete re-write? From rra@stanford.edu Thu Jul 11 21:59:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11CA21F9DA6 for ; Thu, 11 Jul 2013 21:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr+Rp4XjfaDR for ; Thu, 11 Jul 2013 21:59:15 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id B317E21F9D9E for ; Thu, 11 Jul 2013 21:59:15 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 80D5F45DA64; Thu, 11 Jul 2013 21:59:15 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 91FFB45CB2D; Thu, 11 Jul 2013 21:59:14 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 7BD8D2F4E6; Thu, 11 Jul 2013 21:59:13 -0700 (PDT) From: Russ Allbery To: Nico Williams In-Reply-To: (Nico Williams's message of "Thu, 11 Jul 2013 23:54:55 -0500") Organization: The Eyrie References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> <87mwpsflbv.fsf@windlord.stanford.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Thu, 11 Jul 2013 21:59:13 -0700 Message-ID: <87ip0gfk66.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:59:20 -0000 Nico Williams writes: > On Thu, Jul 11, 2013 at 11:34 PM, Russ Allbery wrote: >> No, I don't think he was being sarcastic. The RFC that was published >> documents the existing protocol, which is kind of broken. I'm pretty >> sure this charter action is about *revising* that protocol and making >> it more sane. > Ah. OK. How much change do you think it needs? Some? Or are we > talking about a complete re-write? The current protocol is pretty weird. One obvious point is that it uses raw AP-REQs instead of GSS-API. -- Russ Allbery (rra@stanford.edu) From nico@cryptonector.com Thu Jul 11 22:28:10 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D321F9CFB for ; Thu, 11 Jul 2013 22:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INXWa4uGbHrB for ; Thu, 11 Jul 2013 22:28:05 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46021F9CF2 for ; Thu, 11 Jul 2013 22:28:05 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 0C704674058 for ; Thu, 11 Jul 2013 22:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=rNNPWyKMAQOdYon/BDQsvuFQFn4=; b=XmvuxFK14aD DD3d60jqteNlWHMr3VukIFK39RHrLgQTHFTuSzDV9nGIVnGitTNzG5nqsl3cTXCt wZNulMQOR96PMJhfS2OrWen+PMYO1rOM8gAQ8ydGZYbirwKxDM1DXVArxY6/aiT5 VsFp4uuIybIuiRRoF1wBgQs0/Mgd4P14= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (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 B154F674057 for ; Thu, 11 Jul 2013 22:27:53 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so7775353wes.33 for ; Thu, 11 Jul 2013 22:27:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pbmmBO/LHDV3PA9Imv1NK9HZBiigd+I9Y4uUqjryxJk=; b=ef9xkNB72qdTV92nBUSSOusCe9ToQ7JABTdxl6gsoaEcvki992apX3W7e4RJs9L8p9 6kqgpBbdnIhQyRfwq2seX+ivemDwzO51EWBjuhP74S4B7fhNW8Jo635nhN1F53MIfn0X 3WAFwj7UnYUedtijuGUUfP+7EpX358z/cxAUNGNxioftyqk7UwGnbusDJOd7KLTjeJKz Ymdoq0u1u6oGFVl/qnKYu+GtQ8hn5bv85SACa+3zLBI+G3QkDzURkpSJEr1JTT9hlt7x LYChwmPSkYDUm579tkj2gNB0SjcWQFiL6TEiWnlwZp4HovUkor+4TnUfDNqPrYB22Yij 1s6Q== MIME-Version: 1.0 X-Received: by 10.194.22.1 with SMTP id z1mr23592622wje.14.1373606872170; Thu, 11 Jul 2013 22:27:52 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 22:27:52 -0700 (PDT) Date: Fri, 12 Jul 2013 00:27:52 -0500 Message-ID: From: Nico Williams To: Russ Allbery Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: [kitten] kx509 update/redesign (Re: PKCROSS) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:28:10 -0000 On Thu, Jul 11, 2013 at 11:59 PM, Russ Allbery wrote: >> Ah. OK. How much change do you think it needs? Some? Or are we >> talking about a complete re-write? > > The current protocol is pretty weird. One obvious point is that it uses > raw AP-REQs instead of GSS-API. True. Actually, Kerberos itself is like that... (ah no, let's not discuss GSS pre-auth in this thread :) Anyways, if this PKCROSS design is to go anywhere it will need a Standards-Track kx509. If we'd need kx509 to allow for stateless server operation then GSS would be, once more, a bit of an odd-duck, as in KDC exchanges. The same solution (export context, encrypt in local key, send back as state cookie) would work, provided we don't need replay protection, but the obviously easy thing to do is to... use raw AP exchanges. Is it so weird, that kx509 uses AP-REQs instead of GSS, then? Yes, but not quite too weird: If I had to design this and *not* use GSS I'd... start with the thought of shoving a CSR in to an authorization-data element of the Authenticator, sending an AP-REQ, and expecting back an AP-REP + KRB-PRIV in the same reply. Why privacy? Because I might be trying to hide my principal name, but then I'd want something like FAST so I could use an anon PKINIT ticket as an armor ticket. By which point the whole thing really begins to look like a repeat of the existing KDC exchanges, so maybe we should do just that, sending a CSR as authz-data in a KDC-REQ for the kx509 service principal, and re-using the whole FAST machinery. If I had to design this and use GSS, not raw Kerberos, I'd probably do the encrypted state cookies thing and use timestamps and clocks to reduce the window for replays and a small table of extant, unexpired state nonces -- think TCP SYN cookies. Or accept state and set a timer on each partially established security context and its corresponding TCP connection (after all, the web runs on HTTPS on TCP, if they can deal, so can we, and this is a service that can expect much lower load than a normal KDC). Either way privacy protection would be implemented by tunneling GSS in GSS. If we can re-use the FAST machinery of existing FAST clients and KDCs then I think it becomes quite tempting to do so. OTOH, the beauty of using GSS is that the CA could then work with any GSS authentication mechanism that can provide at least integrity protection to the CSR (e.g., via channel binding), and that's not something I'd want to give up on. If we can rely on Alejandro and Rafa finishing GSS pre-auth, then FAST seems like the way to go. No? Nico -- From kwburgi@tycho.ncsc.mil Fri Jul 12 06:29:22 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EAA11E80F3 for ; Fri, 12 Jul 2013 06:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUP189ezJ6yR for ; Fri, 12 Jul 2013 06:29:18 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC321F9E15 for ; Fri, 12 Jul 2013 06:29:16 -0700 (PDT) X-TM-IMSS-Message-ID: <56455c8c000fa826@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 56455c8c000fa826 ; Fri, 12 Jul 2013 09:25:58 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r6CDQRHW014054; Fri, 12 Jul 2013 09:26:27 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kelley Burgin In-Reply-To: <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> Date: Fri, 12 Jul 2013 09:27:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> To: Luke Howard X-Mailer: Apple Mail (2.1503) Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:29:23 -0000 Looks like the choices now are: 1. Come up with a security proof that the current short plaintext = algorithm is secure (so Nico isn't worried about baked-in crypto = weaknesses), and continue with CTS 2. Go back to CBC with padding (my original proposal a couple of years = ago) 3. Wait to see what SSPI (and other?) applications are negatively = affected by plaintext padding, then choose 1. or 2. I still like 2, or 3 then 2 :) Kelley On Jul 10, 2013, at 8:17 PM, Luke Howard wrote: > Good point Jeff. >=20 > An SSPI application can call = QueryContextAttributes(SECPKG_ATTR_SIZES), but unlike = gss_wrap_iov_length(), that data to be wrapped is not passed as an = argument. So it can only return the maximum security trailer size = (trailer being the RFC4121 wrap token/rotated checksum). >=20 > If an in-place wrap truncates the trailer length, the application = protocol may not be able to update it (consider something like DCE RPC = where the message length is also authenticated). (It's sort of = irrelevant whether the padding is done inside the trailer -- via EC -- = or by the application.) >=20 > I would need to do some research; from memory DCE RPC always pads PDUs = to 16 bytes, so for common block sizes the trailer is effectively = constant length (there is no requirement for EC). I will investigate. >=20 > Of course, there are other SSPI applications than DCE RPC, but I'm not = sure if they have the limitation of not allowing the trailer size to be = shorter after wrap. >=20 > -- Luke > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From elric@imrryr.org Fri Jul 12 06:04:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FFC11E810D for ; Fri, 12 Jul 2013 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm7Quk0Eg43f for ; Fri, 12 Jul 2013 06:04:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7819811E810A for ; Fri, 12 Jul 2013 06:04:36 -0700 (PDT) Received: from roofdrak.imrryr.org (roofdrak.imrryr.org [88.96.236.210]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9E0262AAA21; Fri, 12 Jul 2013 13:04:31 +0000 (UTC) Received: by roofdrak.imrryr.org (Postfix, from userid 666) id 84BC210F85A; Fri, 12 Jul 2013 08:54:33 +0000 (UTC) Date: Fri, 12 Jul 2013 09:54:33 +0100 From: "Roland C. Dowdeswell" To: Nico Williams Message-ID: <20130712085433.GL1696@roofdrak.imrryr.org> References: <08C5B7C5-3D73-4DB8-9C8E-31029B818657@jpl.nasa.gov> <8B4A0DB6-EB33-4703-940B-CA06CF29591C@jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 12 Jul 2013 07:59:12 -0700 Cc: kitten@ietf.org Subject: Re: [kitten] What happened to simplifying the API in the charter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:11:15 -0000 On Thu, Jul 11, 2013 at 07:20:15PM -0500, Nico Williams wrote: > > On Thu, Jul 11, 2013 at 6:00 PM, Nico Williams wrote: > > On Thu, Jul 11, 2013 at 5:50 PM, Henry B. Hotz wrote: > >> Is that krb5-specific, or is it GSSAPI in general? > > > > The 'k' in it is for "Kerberos", but in fact it uses the GSS-API in a > > completely generic way. It uses these GSS functions only: > > > > Also, the libknc API gives the application the actual gss_name_t > values, so the application can do what it likes. > > So, yes, libknc is very much generic, not Kerberos-specific. Perhaps > Roland should rename it :) I was certainly thinking of renaming it. When originally written, quite a long time ago, I was only thinking about Kerberos but since then I've made things quite a bit more generic. > The knc(1) program only deals in display names. It could export the > initiator's name and give it to the application; since the protocol by > which knc(1) talks to the server program is textual, the exported name > token would have to be hex encoded. > > So knc(1) the program isn't quite generic enough, but it's very close. Definitely. Lately, I've been putting more work into the library interface which is much more generic than the command line utility at this point, but the plan is to rewrite the command line utility in terms of the library and expose more of the functionality. For naming, on the server side, the command line will set environment variables such as KNC_CREDS which is the gss_display_name() of the other end of the connexion. It would be very easy to add something like KNC_EXPORT_NAME being the base64 encoded export name. I'll probably also make KNC_CREDS specific to the Kerberos case as the gss_display_name() semantics in that case are well understood. (This is similar to the approach that I am using to add Negotiate support to bozohttpd, i.e. set REMOTE_USER to gss_display_name() if Kerberos is used for compatibility with apache and set EXPORT_NAME to the export name in all cases for something with a bit more in the way of correctness for other mechanisms.) -- Roland Dowdeswell http://Imrryr.ORG/~elric/ From stpeter@stpeter.im Fri Jul 12 11:39:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6A711E8168 for ; Fri, 12 Jul 2013 11:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji1YpT7N1lB4 for ; Fri, 12 Jul 2013 11:39:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF4511E811F for ; Fri, 12 Jul 2013 11:39:26 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4F3AE41410; Fri, 12 Jul 2013 12:40:35 -0600 (MDT) Message-ID: <51E04D58.3040602@stpeter.im> Date: Fri, 12 Jul 2013 12:39:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20130712183810.12543.75451.idtracker@ietfa.amsl.com> In-Reply-To: <20130712183810.12543.75451.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130712183810.12543.75451.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:39:31 -0000 FYI, a revised I-D is now available for "SASLprepbis", reflecting input from folks on the KITTEN list. Thanks for your feedback! -------- Original Message -------- Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-03.txt Date: Fri, 12 Jul 2013 11:38:10 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: precis@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-03.txt Pages : 14 Date : 2013-07-12 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis From kaduk@mit.edu Fri Jul 12 12:18:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD56421F9DC7 for ; Fri, 12 Jul 2013 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIQdERaiUIqa for ; Fri, 12 Jul 2013 12:18:37 -0700 (PDT) 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 156B221F9D86 for ; Fri, 12 Jul 2013 12:18:36 -0700 (PDT) X-AuditID: 1209190c-b7fa48e000000947-46-51e0568b5623 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C8.62.02375.B8650E15; Fri, 12 Jul 2013 15:18:35 -0400 (EDT) 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 r6CJIYYl008067; Fri, 12 Jul 2013 15:18:35 -0400 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 r6CJIV1H030518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jul 2013 15:18:33 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r6CJIVvD000245; Fri, 12 Jul 2013 15:18:31 -0400 (EDT) Date: Fri, 12 Jul 2013 15:18:31 -0400 (EDT) From: Benjamin Kaduk To: Kelley Burgin In-Reply-To: Message-ID: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> 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+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrNsd9iDQYMUrc4vr78+xWxzdvIrF Yl5DhsXdS//ZHVg89rceY/VYsuQnk8fcD9NYPLY2/2MMYInisklJzcksSy3St0vgypi99C1T wQeWiknPn7A2ML5k7mLk5JAQMJFoPXmaEcIWk7hwbz1bFyMXh5DAPkaJll1LwYqEBDYyShw4 kwqROMQkMWvxDGYIp4FR4siOmWwgVSwC2hKtLx6wg9hsAioSM99sBIuLCGhJXH04B6iBg4NZ IFbiyGFekLCwQInExO17WEHCnAJOEu1bo0DCvAKOEjs//GOHGD+TWeJT8wMWkISogI7E6v1T WCCKBCVOznwCZjMLWEqc+3OdbQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbp GurlZpbopaaUbmIEh7Mkzw7GNweVDjEKcDAq8fC+EHoQKMSaWFZcmXuIUZKDSUmU91EQUIgv KT+lMiOxOCO+qDQntfgQowQHs5II7z5HoBxvSmJlVWpRPkxKmoNFSZz36dOzgUIC6Yklqdmp qQWpRTBZGQ4OJQneSaFAjYJFqempFWmZOSUIaSYOTpDhPEDD94PU8BYXJOYWZ6ZD5E8xKkqJ 854FSQiAJDJK8+B6YenmFaM40CvCvOdAqniAqQqu+xXQYCagwbdX3QcZXJKIkJJqYNRw5n4t Ui950UrD3uHVCfXap33ey3Qcrui+8TK7U9OrdFu8t+OLv9fTnnsX8/f3Ft4xnxmgrLj0t8ea TV1rkp7sYHrBbL/LNW3TEs6MmfrJN2xt2Z2bWPt2tn53uXjRvj9D/FDP5qAdP8/kfj76t7qv VVjpjkJMYMK+/qv2IRUXbep+rfV4qcRSnJFoqMVcVJwIAFwVCmkSAwAA Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 19:18:43 -0000 On Fri, 12 Jul 2013, Kelley Burgin wrote: > Looks like the choices now are: > > 1. Come up with a security proof that the current short plaintext algorithm is secure (so Nico isn't worried about baked-in crypto weaknesses), and continue with CTS > 2. Go back to CBC with padding (my original proposal a couple of years ago) > 3. Wait to see what SSPI (and other?) applications are negatively affected by plaintext padding, then choose 1. or 2. > > I still like 2, or 3 then 2 :) >From the research I did through the krb-wg mail archives, I do not see reason to support (3). Going with (2) seems fine. -Ben From hotz@jpl.nasa.gov Fri Jul 12 20:35:08 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7672721E80CF for ; Fri, 12 Jul 2013 20:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6Ys6GBEtx74 for ; Fri, 12 Jul 2013 20:35:02 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3221E80C4 for ; Fri, 12 Jul 2013 20:35:02 -0700 (PDT) Received: from [192.168.1.66] (172-11-22-159.lightspeed.irvnca.sbcglobal.net [172.11.22.159]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6D3Yvo1016802 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 12 Jul 2013 20:34:58 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: Date: Fri, 12 Jul 2013 20:34:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> To: Nico Williams X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-JPL-Spam-Score': 80% Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 03:35:08 -0000 On Jul 11, 2013, at 4:14 PM, Nico Williams = wrote: > On Thu, Jul 11, 2013 at 5:54 PM, Henry B. Hotz = wrote: >> On Jul 11, 2013, at 2:40 PM, Nico Williams = wrote: >>> The thought occurs that Kerberos + kx509 + PKINIT can be a sort of >>> PKCROSS. >>=20 >> Please elaborate? >=20 > Assume: >=20 > - I have a TGT for realm FOO.EXAMPLE. > - I want to talk to a service in BAR.EXAMPLE. > - I have no credentials for any principal in BAR.EXAMPLE. > - I can find no all-Kerberos trust path between FOO.EXAMPLE and = BAR.EXAMPLE. > - I can get a certificate for my client principal name using a kx509 > service run by FOO.EXAMPLE. >=20 > Then maybe: >=20 > - BAR.EXAMPLE accepts my use of that certificate (and private key) > with PKINIT and issues me a Ticket with nico@FOO.EXAMPLE for the > requested service at BAR.EXAMPLE (likely > krbtgt/BAR.EXAMPLE@BAR.EXAMPLE). >=20 > Here BAR.EXAMPLE's KDC will have to build and validate a trust path > for my certificate's trust., extract the krb5 SAN, decide whether to > accept it, and if it does, issue a Ticket for that SAN. >=20 > The transit path recorded in the Ticket should be FOO.EXAMPLE-> path>->BAR.EXAMPLE. It so happens that Kerberos can represent x.500 > naming in transit paths -- how convenient! I'm not sure that > implementations actually exist of x.500 realm naming in Kerberos, but, > hey. So the short version would be that we use a kx509-issued cert as a = stand-in for a cross-realm relationship. =20 I recall a bunch of jokes about that while writing the RFC. However = Doug Engert actually proposed that use case for Globus. It's arguably a = minor extension of the existing SLCS policies. The security = considerations just say "here there be [policy] dragons". ;-) Since it's up to the kdc to decide how X.509 cert's are related to = principals, I don't think you actually need anything except a convention = (which your assumptions imply) for when the client should try this = approach. =20 Strict need aside, I can see some value in being able to provide = information about how a foreign principal was validated. Putting an = X.509 name into a transited field doesn't strike me as a bad way to do = it, especially since it gives you a legacy-compatible way for the KDC to = flag policy issues. Another less-compatible way to do it would be to = just issue an X500 principal tgt directly. Formal modeling of Kerberos says "here there be dragons" about = cross-realm. It would be nice if an explicit extension to support X.509 = certs for cross-realm could be restricted in a way which allowed proof = of the desired properties. >> The reason *I* would combine kx509 with PKINIT would be the use case = of someone needing X.509 credentials on multiple client computers at = once. This is a real use case for us. >=20 > Presumably all from different realms? Would that be the same as > described above? Nah. Just a user can only have one PIV card, but they may need to use = more than one computer at a time. Using kx509-issued certs instead of = the originals on the card gives you a way to cache your authentications. = It's also faster to set up than waiting through multiple cycles on an = RSA token. >> I was thinking of PKCROSS the other day as a possible solution to a = rather specialized problem: our realm-name conflict between Unix and AD = kerberos. You might think that for one-way trusts from another realm = (like a smart-card-only realm) it would be OK to have both of them trust = the other one. Trouble is that with symmetric crypto if someone hacked = the AD realm they could use the one-way trust key to forge other-realm = cross-realm authentications to the Unix realm. (Not picking on = Microsoft. The problem is symmetric.) I suspect that PKCROSS might = allow a solution to that, though I have not read the draft to make sure. = I also suspect that it's too specialized a use case to justify the = standards effort that would be required. >=20 > All trusted-third-party protocols have this problem in the end. What > can you do? You have to trust all your KDCs, for all those realms > that you care about. >=20 > You might address this partially by havig Tickets bear the > certificates used by the clients as KDC-issued authorization-data, so > that applications could perform PKIX validation, including cert > revocation checking, apply various policies, =85 >=20 >>> That makes me very interested. It shouldn't be very >>> difficult to build that almost entirely out of off-the-shelf = protocol >>> pieces. It's not trival though: we'd definitely need policy for >>> handling PKIX trust paths, >>=20 >> I've lost a lot of interest in PKIX, per-se. The overall revocation = system is architecturally broken, and I can't tell if the co-chairs even = understand the issues. Instead we have vapor-ware like SCVP and TAMP. >=20 > Oh, it's not PKIX I care about. I just want something that scales > better than symmetrically keyed Kerberos cross-realm principals, and > with better security policies (e.g., sysadmins do not have to exchange > passwords from which the x-realm keys are derived; they might exchange > passwords to authenticate the key exchange, but the sysadmins should > not learn the keys as a result, or they might exchange certificate > fingerprints, =85). We're less concerned with the "insider threat" than most. =20 I agree public-key better models the trust relationship of 1-way cross = realm than symmetric key. Also agree that configuring those = relationships has a lot of practical issues. If it's explicitly = configured, then I don't think PKIX adds any value. Just use asymmetric = encryption instead of symmetric. (Maybe issue a symmetric tgt to make = subsequent tgs requests more efficient?) >>> PKCROSS -or similar- is not in-charter at this time. >>=20 >> If we can address use cases which PKIX doesn't, then it sounds = valuable. >=20 > The use case that PKIX doesn't address is where you've deployed > Kerberos widely and you want to either a) scale it up mode widely > (e.g., in the EDU world), and/or b) remove the manual symmetric key > exchange, and/or c) not have to worry about cross-realm key rollover > (or enctype changes, e.g., to go to stronger enctypes as they become > available). >=20 > Nico > -- ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From internet-drafts@ietf.org Sun Jul 14 17:54:36 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3665B21F9DB1; Sun, 14 Jul 2013 17:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW4fRYeWQ4eU; Sun, 14 Jul 2013 17:54:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B55A021F9BA2; Sun, 14 Jul 2013 17:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715005421.21984.28404.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 17:54:21 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-kerberos-iana-registries-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 00:54:36 -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 : Move Kerberos protocol parameter registries to IANA Author(s) : Tom Yu Filename : draft-ietf-kitten-kerberos-iana-registries-02.txt Pages : 8 Date : 2013-07-14 Abstract: The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registries There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-kerberos-iana-registri= es-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hotz@jpl.nasa.gov Sun Jul 14 18:54:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0121F9A1F for ; Sun, 14 Jul 2013 18:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVsYEd4Gjtca for ; Sun, 14 Jul 2013 18:54:49 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6F21F99D5 for ; Sun, 14 Jul 2013 18:54:47 -0700 (PDT) Received: from [192.168.1.66] (172-11-22-159.lightspeed.irvnca.sbcglobal.net [172.11.22.159]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6F1shTE019804 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Sun, 14 Jul 2013 18:54:44 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: Date: Sun, 14 Jul 2013 18:54:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> <87mwpsflbv.fsf@windlord.stanford.edu> To: Nico Williams X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-JPL-Spam-Score': 80% Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:54:55 -0000 On Jul 11, 2013, at 9:54 PM, Nico Williams = wrote: > On Thu, Jul 11, 2013 at 11:34 PM, Russ Allbery = wrote: >> No, I don't think he was being sarcastic. The RFC that was published >> documents the existing protocol, which is kind of broken. I'm pretty = sure >> this charter action is about *revising* that protocol and making it = more >> sane. >=20 > Ah. OK. How much change do you think it needs? Some? Or are we > talking about a complete re-write? The current RFC has a bunch of comments scattered through it about = changes to be made in a "future incompatible upgrade". One specific = point that multiple people complained about is it uses SHA1, and ought = to use the Kerberos checksum for whatever enctype is in use. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From internet-drafts@ietf.org Sun Jul 14 19:20:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7E21F9D50; Sun, 14 Jul 2013 19:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwF2qGMT1eEh; Sun, 14 Jul 2013 19:20:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EAD21F99AC; Sun, 14 Jul 2013 19:20:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715022019.8130.58331.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 19:20:19 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:20:20 -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 : Kerberos Authorization Data Container Authenticated by M= ultiple MACs Author(s) : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-05.txt Pages : 9 Date : 2013-07-14 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-krb-wg-cammac-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From weijun.wang@oracle.com Sun Jul 14 20:59:06 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE821F9DF0 for ; Sun, 14 Jul 2013 20:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIuDPX5J0Ev6 for ; Sun, 14 Jul 2013 20:59:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F394421F9DB4 for ; Sun, 14 Jul 2013 20:59:00 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6F3wxKq019012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 03:59:00 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6F3wwVa014936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 03:58:59 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6F3ww5J015895; Mon, 15 Jul 2013 03:58:58 GMT Received: from mini.local (/123.122.156.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 14 Jul 2013 20:58:58 -0700 Message-ID: <51E37377.1030704@oracle.com> Date: Mon, 15 Jul 2013 11:58:47 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: kitten@ietf.org, OpenJDK References: <51B1E355.2090301@oracle.com> In-Reply-To: <51B1E355.2090301@oracle.com> X-Forwarded-Message-Id: <51B1E355.2090301@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 03:59:06 -0000 Hi All I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail is about a design flaw in the initSecContext and acceptSecContext methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2]. The GSSContext::initSecContext() method could either return a token (possibly null if no more token is needed) when the call succeeds or throw a GSSException if there is a failure, but not *both*. The same applies to acceptSecContext(). On the other hand, the C bindings of GSS-API has a chance to return both, and it does try to make use of both of them (according to RFC 2743 2.2.1 [3]): It is the caller's responsibility to establish a communications path to the target, and to transmit any returned output_token (independent of the accompanying returned major_status value) to the target over that path. Without the ability to send a token when there is a failure, a Java program has no chance to tell the other side what's happening. This is very user-unfriendly. Also, in the case of SPNEGO, a "reject" NegTokenResp token will never be able to sent out. My current proposal is to add a new method getOutputToken() to the GSSException class (which will be thrown when an error occurs) to return this last token. This means the method calls will be something like try { send(initSecContext(inToken)); } catch (GSSException e) { if (e.getOutputToken() != null) { send(e.getOutputToken()); } throw e; } The getOutputToken() method can only return a non-null value when it's thrown by an initSecContext or acceptSecContext call. The method won't throw another GSSException even if the exception was thrown in other calls. We can use the new JDK 8 default method feature [1] to add this new method to the existing GSSException interface. Thanks Weijun [1] http://tools.ietf.org/html/rfc5653#section-7.4.3[2] http://tools.ietf.org/html/rfc5653#section-7.4.9 [3] http://tools.ietf.org/html/rfc2743#page-46 [4] http://tools.ietf.org/html/rfc5653#section-7.4.5 From jhutz@cmu.edu Mon Jul 15 10:33:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991911E8189 for ; Mon, 15 Jul 2013 10:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyLTVtMLN-dU for ; Mon, 15 Jul 2013 10:33:44 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id CCC4211E814F for ; Mon, 15 Jul 2013 10:33:44 -0700 (PDT) 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 r6FHXfso018426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 13:33:42 -0400 (EDT) Message-ID: <1373909621.23365.286.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Weijun Wang Date: Mon, 15 Jul 2013 13:33:41 -0400 In-Reply-To: <16819_1373860748_r6F3x7Tp017281_51E37377.1030704@oracle.com> References: <51B1E355.2090301@oracle.com> <16819_1373860748_r6F3x7Tp017281_51E37377.1030704@oracle.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, OpenJDK , jhutz@cmu.edu Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:33:50 -0000 On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote: > My current proposal is to add a new method getOutputToken() to the > GSSException class (which will be thrown when an error occurs) to return > this last token. This means the method calls will be something like This seems like an elegant solution to the problem. -- Jeff From nico@cryptonector.com Mon Jul 15 12:37:05 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D823C21E816C for ; Mon, 15 Jul 2013 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHC8W0uaq9E0 for ; Mon, 15 Jul 2013 12:37:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id F3E0311E8122 for ; Mon, 15 Jul 2013 12:37:00 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 82DFF678063 for ; Mon, 15 Jul 2013 12:37:00 -0700 (PDT) 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=uSk2WFiESnZqzUSRqUeo eS9ssfU=; b=eIni/RewLITkzkN6EpLwjjqYE9xJ/AYr0WpMXwD6LOPXe1IWrIN+ o8OdYOdbQUoRYMOerJ0GFYoYKlslzjr6dCWrFI7fIsQWxUsQz6aPGy70Xc4Hm801 Fd9VTxQW7xlcWLvWgQT2oIFYzPLbLEdF87te3BQpOSMCmy5PVp3QIGs= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 2A346678058 for ; Mon, 15 Jul 2013 12:36:59 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so3298047wib.6 for ; Mon, 15 Jul 2013 12:36:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vCDkHqsJy0mk93NnRxjvUeRz53mOJbSpGOc4xCHthuI=; b=Rh/u3DTB8D5Yu1oGTttlOb5kRBtFO8SnAyUbmgU7RgED7wFeTVA84RN2G4qlskxWg+ K9uWwIkzJ8tKrjGM8LZ9RqkuQBpmPrKaN1Hql1r9U5T19zt1eE1nkvXpaGK5clqKxGrC 6Xyfo/v7oyoNCQ+2tiM4SGUej4g/Hrd3vmLu971x5O8cA9clH6tI7ng9bbe5m+Zs4GqT 62brKPh85Ou3gYH/DbOe5YducUWCHXQ9q5nh7TVfb5Oi1I9sdZmmaBhtT6vj0EGSaBZb CobvSNsjWVY1jB8qHRybWuPDRNc8yJQGeO/VReGmp6npLl8inRWSJivO3F4MwXr55fAn dHaA== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr33404634wjn.23.1373917018368; Mon, 15 Jul 2013 12:36:58 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Mon, 15 Jul 2013 12:36:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 14:36:58 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] kx509 update/redesign (Re: PKCROSS) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:37:06 -0000 Having thought about this a bit, I'd like to note one thing and propose a design. The note: there's not much difference between issuing a Ticket and a Certificate, nor, for that matter, is there much difference between asking for a Ticket or a Certificate. In either case we need machinery *like* the machinery we already have for KDC exchanges. The proposed design: - add a new type derived from KDC-REQ and KDC-REP, call it KCA-REQ and KCA-REP - a KCA-REQ would be like a TGS-REQ in that it would carry a PA-TGS-REQ - a KCA-REQ would also carry a PA-KCA-SUBJECT-PUBLIC-KEY or PA-KCA-CSR - a KCA-REQ would also carry a PA-KCA-REQ beaing a signature with that key of the rest of the KDC-REQ (including the other PAs, but excluding, obviously, the PA-KCA-REQ) - the KCA-REP would be like any other KDC-REP, but instead of bearing a Ticket it would bear an OCTET STRING containing a Certificate, and while we're at it, the cert should be in the enc-part of the reply, and while we're at it, might as well include a SEQUENCE OF octet strings containing OCSP Responses for the cert, the KCA's cert, -- the trust path. - use a different RRSet naming for KCA than for KDCs so as to enable isolation, but otherwise default to port 88 and the same hosts as KDCs (they can still isolate the KCA functionality and key material using IPC after all) Rationale: - there's little difference between issuing a ticket and a cert -> reuse the ticket issuance machinery as much as possible - we'll want FAST for KCA for the same reasons as we did for the AS and TGS Cons: - doesn't use GSS But that's OK: we'll just have to finish GSS pre-auth. Nico -- From kaduk@mit.edu Mon Jul 15 14:54:45 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5211E812C for ; Mon, 15 Jul 2013 14:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh0lnlheP7Zk for ; Mon, 15 Jul 2013 14:54:39 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE611E8176 for ; Mon, 15 Jul 2013 14:54:33 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-7d-51e46f99f6e3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 73.E0.02387.99F64E15; Mon, 15 Jul 2013 17:54:33 -0400 (EDT) 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 r6FLsWU5010657 for ; Mon, 15 Jul 2013 17:54:33 -0400 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 r6FLsTLd029906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Jul 2013 17:54:31 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r6FLsTjN003235; Mon, 15 Jul 2013 17:54:29 -0400 (EDT) Date: Mon, 15 Jul 2013 17:54:29 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20130715022019.8130.58331.idtracker@ietfa.amsl.com> Message-ID: References: <20130715022019.8130.58331.idtracker@ietfa.amsl.com> 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+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrTsz/0mgwbbLIhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvf/p5kLHnJXrPrRyNbA+JGji5GTQ0LARGL32XfMELaYxIV7 69m6GLk4hAT2MUq0v73EDOEcZ5SYfa0XKnODSeLc5B4mCKeBUWLPm3dMIP0sAtoSh7svsoDY bAIqEjPfbGQDsUUEhCV2b4XYISzgKNF19TQ7iM0JZD+etAisnhfInr7yBSuILSTgIHGo5xMj iC0qoCOxev8UqBpBiZMzn4DZzAKWEuf+XGebwCgwC0lqFpLUAkamVYyyKblVurmJmTnFqcm6 xcmJeXmpRboWermZJXqpKaWbGEEByO6iuoNxwiGlQ4wCHIxKPLwSPE8ChVgTy4orcw8xSnIw KYnypmUAhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw2gkD5XhTEiurUovyYVLSHCxK4rzPn54N FBJITyxJzU5NLUgtgsnKcHAoSfDezQNqFCxKTU+tSMvMKUFIM3FwggznARrOng8yvLggMbc4 Mx0if4pRUUqcVxAkIQCSyCjNg+uFJYhXjOJArwjzvgBZwQNMLnDdr4AGMwENbp79GGRwSSJC SqqBcXaHl0/4hv+x4b/vf0j7LfS4QFvtTKe9Gu+edRZLXf6vvskzJeHfMqlu0c1WM4WX3Z8R f2Lr/dOzojNP7d5/IGH3PNG430+5uX6Kbj005ZGQtPdlxsv6VSFnCwtvzDzLG/H8vsnkGX9u BlSdueLh8r9646fFDadlb/F+4dj77gbXY69Hi1Kvv6xXYinOSDTUYi4qTgQAT6FLPOsCAAA= Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:54:45 -0000 On Sun, 14 Jul 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Kerberos Authorization Data Container Authenticated by Multiple MACs > Author(s) : Simo Sorce > Tom Yu > Thomas Hardjono > Filename : draft-ietf-krb-wg-cammac-05.txt > Pages : 9 > Date : 2013-07-14 > > Abstract: > Abstract: This document specifies a Kerberos Authorization Data > container that supersedes AD-KDC-ISSUED. It allows for multiple > Message Authentication Codes (MACs) or signatures to authenticate the > contained Authorization Data elements. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac I caught Tom and Simo on IRC, but should summarize to the list: I think we should provide a little more guidance about what the AD_CAMMAC_BINDING element would contain (i.e., what it would be a checksum over). Tom says we could give a "signed ticket" as an example, and Simo suggests that we could put something in the security considerations section, which is fine for me. When an actual implementation is in place, we could put out an informational RFC with the format that is used, to aid interoperability. -Ben From marc.blanchet@viagenie.ca Sun Jul 14 09:31:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7121F944C; Sun, 14 Jul 2013 09:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLxL7GEdCyJB; Sun, 14 Jul 2013 09:31:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD821F93C4; Sun, 14 Jul 2013 09:31:22 -0700 (PDT) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DD846403FF; Sun, 14 Jul 2013 12:31:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51DF408E.6010201@stpeter.im> Date: Sun, 14 Jul 2013 12:31:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58D2B0A9-9A5E-47E7-A551-9814E9033FCA@viagenie.ca> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> <51DF408E.6010201@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Mon, 15 Jul 2013 18:24:42 -0700 Cc: kitten@ietf.org, precis@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] [precis] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:31:23 -0000 Le 2013-07-11 =E0 19:32, Peter Saint-Andre a =E9crit = : > On 7/11/13 2:45 PM, Jeffrey Hutzelman wrote: >> On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote: >>=20 >>>> NEW >>>> SASL mechanisms that directly re-use this profile MUST specify >>>> whether case mapping is to be applied to authentication IDs, and >>>> when. SASL mechanisms SHOULD delay any case mapping to the last >>>> possible moment, such as when doing a lookup by username, = username >>>> comparisons, or generating a cryptographic salt from a username. >>>>=20 >>>> SASL application protocols that directly re-use this profile MUST >>>> specify whether case mapping is to be applied to authorization = IDs. >>>> SASL application protocols SHOULD delay any case mapping of >>>> authorization IDs to the last possible moment, which happens to >>>> necessarily be on the server side. >>>>=20 >>>> Note that, in keeping with RFC4422, SASL applications must not = apply >>>> this or any other profile to authentication IDs. >>>>=20 >>>> Note that, in keeping with RFC4422, SASL mechanisms must not = apply >>>> this or any other profile to authorization IDs. >>>=20 >>> That is much more precise than what I had sketched out, and it looks >>> good to me. >>=20 >> Me too >=20 > Great. If there are no objections from my co-author in the next 24 = hours > or so, you're ok ... ;-) Marc. > I'll submit a revised I-D. I'd really like to finish off all this > i18n stuff... :-) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ From qiminpeng@chinamobile.com Mon Jul 15 21:39:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13A621E81A5 for ; Mon, 15 Jul 2013 21:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[AWL=1.997, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1PLswc9p90x for ; Mon, 15 Jul 2013 21:39:19 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 0973821E8186 for ; Mon, 15 Jul 2013 21:39:18 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151e4ce3d95f-ef95f; Tue, 16 Jul 2013 12:38:21 +0800 (CST) X-RM-TRANSID: 2ee151e4ce3d95f-ef95f Received: from RonPC (unknown[10.2.51.10]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351e4ce3c97a-c80a5; Tue, 16 Jul 2013 12:38:21 +0800 (CST) X-RM-TRANSID: 2ee351e4ce3c97a-c80a5 From: =?utf-8?B?6b2Q5pe76bmP?= To: Date: Tue, 16 Jul 2013 12:39:31 +0800 Message-ID: <017101ce81de$7711ef70$6535ce50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5wgtAdgysqV4bRQJ6fBAPCrl+yywAA0yhgBFX1pZA= Content-Language: zh-cn Subject: [kitten] FW: New Version Notification for draft-zhu-core-groupauth-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 04:39:23 -0000 Dear all, We have submitted a new draft about the group authentication and send it = to saag list for discussion. We also want to find a more suitable = subgroup to discuss it.=20 With advice from some experts, we want to forward it to this working = group and try to attract yours' attention for this draft. All comments and suggested improvements are welcome. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: =E9=BD=90=E6=97=BB=E9=B9=8F = [mailto:qiminpeng@chinamobile.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 = 11:11 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'saag@ietf.org' =E4=B8=BB=E9=A2=98: FW: New Version Notification for = draft-zhu-core-groupauth-00.txt Hi everyone, The authors have submit a new draft for the group authentication. We = will appreciate if you have a look and give us any comment or = suggestion. The link is as below. Here is a problem that for group communication there is only uni-cast = authentication instead of group authentication method can be used. This = draft wants to analyze the problem, to summarize group authentication = requirement and to provide a framework of solutions. This draft is to discuss a new kind of authentication so we think it = would be better to discuss it also in security email list and try to = find a suitable subgroup to discuss it. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 = 10:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ye Tian; Minpeng Qi; Judy Zhu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zhu-core-groupauth-00.txt A new version of I-D, draft-zhu-core-groupauth-00.txt has been successfully submitted by Judy Zhu and posted to the IETF repository. Filename: draft-zhu-core-groupauth Revision: 00 Title: Group Authentication Creation date: 2013-06-24 Group: Individual Submission Number of pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt Status: = http://datatracker.ietf.org/doc/draft-zhu-core-groupauth Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-00 Abstract: The group communication is designed for the communication of Internet of Things. A threat is identified in [I-D.ietf-core-groupcomm] that current DTLS based approach is unicast oriented and there is no supporting on group authentication feature. Unicast oriented authentication will causing serious burden when a large number of terminal nodes will be involved inevitably. In another aspect, some terminals will own the same characteristics, such as owning same features, in the same place, working in the same time, etc. With this mechanism, all terminals can be authenticated together with little signaling and calculation at the same time. It will reduce the network burden and save time. This draft describes the security of group authentication and an group authentication implementation method for the Internet of things. = =20 The IETF Secretariat From ghudson@mit.edu Tue Jul 16 07:39:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC9621E8087 for ; Tue, 16 Jul 2013 07:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE0tI6PbiNzc for ; Tue, 16 Jul 2013 07:39:25 -0700 (PDT) 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 BE14611E80F6 for ; Tue, 16 Jul 2013 07:39:10 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-2e-51e55b07d538 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 15.02.02411.70B55E15; Tue, 16 Jul 2013 10:39:03 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r6GEd2bS022672; Tue, 16 Jul 2013 10:39:02 -0400 Received: from [18.101.8.193] (vpn-18-101-8-193.mit.edu [18.101.8.193]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6GEcsjm016109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 10:39:01 -0400 Message-ID: <51E55AFE.8020800@mit.edu> Date: Tue, 16 Jul 2013 10:38:54 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kelley Burgin References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixG6nosse/TTQoOG4ocX19+fYLY5uXsVi Ma8hw4HZY3/rMVaPJUt+Mnlsbf7HGMAcxWWTkpqTWZZapG+XwJXRs/sCW8EawYpPt9rYGhj/ 8nYxcnJICJhIPHy8gB3CFpO4cG89WxcjF4eQwD5Gia9/5rNCOBsZJXpmzmSEcI4wSRz/M48V pIVXQE1i6qF5TCA2i4CqROPWw2wgNpuAssTBs99Yuhg5OEQFQiSWnuSGKBeUODnzCQuILSKg JXH14RxmEJtZwExi5dfFjCC2sECRxNP/jWBxIYHpzBKfe2pAxnAKOEm0b42COFRSYtG0ThaI Vh2Jd30PoMbIS2x/O4d5AqPQLCTbZiEpm4WkbAEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJd c73czBK91JTSTYzgQHdR2cHYfEjpEKMAB6MSD++LiKeBQqyJZcWVuYcYJTmYlER5uSKBQnxJ +SmVGYnFGfFFpTmpxYcYJTiYlUR4pwQC5XhTEiurUovyYVLSHCxK4rzPnp4NFBJITyxJzU5N LUgtgsnKcHAoSfBOBhkqWJSanlqRlplTgpBm4uAEGc4DNDwTpIa3uCAxtzgzHSJ/ilGXY/LZ Le8ZhVjy8vNSpcR5l4MUCYAUZZTmwc2BJahXjOJAbwnzrgWp4gEmN7hJr4CWMAEtaZ79GGRJ SSJCSqqBcUrv3YZHllYvuzwnKuodrZ9/p1h7le43x43TZhy6vXrzmz3LkqYznskPZ6v5dvd3 qe/x64oyi9MbE7877D03WZ9vCUfxqoqV52MW+f/S4RKrVehKqshfoX7iZC9vaMUSmzPG6fc3 Pr4pdJ63R3T61WMnH6VHrLHPn36V/ZJiq+a82M0JkpcfdSixFGckGmoxFxUnAgCTkaJpKwMA AA== Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:39:31 -0000 On 07/12/2013 09:27 AM, Kelley Burgin wrote: > 1. Come up with a security proof that the current short plaintext algorithm is secure (so Nico isn't worried about baked-in crypto weaknesses), and continue with CTS > 2. Go back to CBC with padding (my original proposal a couple of years ago) > 3. Wait to see what SSPI (and other?) applications are negatively affected by plaintext padding, then choose 1. or 2. At the moment I favor #2. I know I was the one who relayed the SSPI-based objections to padded CBC in the past, so this may seem inconsistent. At the time my reasoning was that we were already used to the pain of having CTS and we aren't going to get away from it any time soon, so even a vaguely-understood objection based on SSPI usage ought to be sufficient. I did not consider that the use of explicit IVs instead of confounders would necessitate a complicated and novel construction to make CTS work for short plaintexts. Now that we have gone through that exercise, I think we would need a much clearer objection from the SSPI front to justify the use of CTS with the proposed enctype. While I'm here, Jeff asked a question which wasn't really answered: > What about non-legacy applications implementing standards-track > GSS-API-using protocols according to a specification that isn't written > with the SSPI in mind? It's all well and good to say "call the API to > see what length you should use", but if the protocol says to send a > 1025-byte message, then I have to send a 1025-byte message, even if the > SSPI would rather I somehow only send a 1016-byte message. I don't understand this question. All RFC 3961 enctypes carry some plaintext expansion, which in turn affects the length of a CFX wrap token. The existing (RFC 3962) AES enctypes have a fixed 28-byte expansion, for instance. Kelley's current draft imposes a 32-byte or 40-byte expansion for aes128 or aes256. We are considering adding a variable 1-16 bytes to that expansion depending on input length. So, what does this hypothetical specification have in mind? Is it making assumptions about the amount of expansion from gss_wrap based on existing GSS mechanisms and enctypes? From jhutz@cmu.edu Tue Jul 16 08:31:11 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59D921F9BD0 for ; Tue, 16 Jul 2013 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVTea6Z3fCGf for ; Tue, 16 Jul 2013 08:31:05 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 733CE21F9A35 for ; Tue, 16 Jul 2013 08:31:01 -0700 (PDT) Received: from [192.168.202.99] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r6GFUq66011789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 11:30:53 -0400 (EDT) From: Jeffrey Hutzelman To: Greg Hudson In-Reply-To: <51E55AFE.8020800@mit.edu> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> Content-Type: text/plain; charset="UTF-8" Date: Tue, 16 Jul 2013 11:30:50 -0400 Message-ID: <1373988650.23943.4.camel@tuzanor.jhutz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:31:12 -0000 On Tue, 2013-07-16 at 10:38 -0400, Greg Hudson wrote: > While I'm here, Jeff asked a question which wasn't really answered: > > What about non-legacy applications implementing standards-track > > GSS-API-using protocols according to a specification that isn't written > > with the SSPI in mind? It's all well and good to say "call the API to > > see what length you should use", but if the protocol says to send a > > 1025-byte message, then I have to send a 1025-byte message, even if the > > SSPI would rather I somehow only send a 1016-byte message. > > I don't understand this question. All RFC 3961 enctypes carry some > plaintext expansion, which in turn affects the length of a CFX wrap > token. The existing (RFC 3962) AES enctypes have a fixed 28-byte > expansion, for instance. Kelley's current draft imposes a 32-byte or > 40-byte expansion for aes128 or aes256. We are considering adding a > variable 1-16 bytes to that expansion depending on input length. > > So, what does this hypothetical specification have in mind? Is it > making assumptions about the amount of expansion from gss_wrap based on > existing GSS mechanisms and enctypes? Huh? No; GSS doesn't promise a particular amount of expansion. My understanding is that Microsoft says the only SSPI applications that are negatively affected are those that don't call Microsoft's API to decide how much data they should put in a wrap token. But GSS tokens aren't a stream; they're discrete, so the amount of data I put in a token has to be based on what the protocol says I put in the token, not what some particular implementation's non-standard API says about how much data I ought to put into a token. -- Jeff From kaduk@mit.edu Tue Jul 16 08:33:44 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7521E8090 for ; Tue, 16 Jul 2013 08:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8tDmOy6k-NW for ; Tue, 16 Jul 2013 08:33:38 -0700 (PDT) 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 E748C21E8050 for ; Tue, 16 Jul 2013 08:33:37 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-a6-51e567d03c3e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 44.66.02411.0D765E15; Tue, 16 Jul 2013 11:33:36 -0400 (EDT) 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 r6GFXZ1K029259; Tue, 16 Jul 2013 11:33:36 -0400 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 r6GFXXRF009326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 11:33:35 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r6GFXW7V027243; Tue, 16 Jul 2013 11:33:32 -0400 (EDT) Date: Tue, 16 Jul 2013 11:33:32 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Hutzelman In-Reply-To: <1373988650.23943.4.camel@tuzanor.jhutz.local> Message-ID: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <1373988650.23943.4.camel@tuzanor.jhutz.local> 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+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrXsh/WmgwaN5phbX359jtzi6eRWL A5PH/tZjrB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYff0Da8ECgYofh38zNzB28HYxcnJICJhI fFs+hRnCFpO4cG89WxcjF4eQwD5GiQevLzNDOBsZJeadeACVOcQk0b5uOSuE08Ao0de7Cqyf RUBbYlfjYlYQm01ARWLmm41sILaIgKrEvTmzWLoYOTiYBYwkLvzKAAkLC5RITNy+hxUkzClg LbH7gDRImFfAUeLRuldQux4zSyy6NY0dJCEqoCOxev8UFogiQYmTM5+A2cwClhLn/lxnm8Ao OAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW65nq5mSV6qSmlmxhBocruorKDsfmQ 0iFGAQ5GJR7eFxFPA4VYE8uKK3MPMUpyMCmJ8q5NAwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4Z0SCJTjTUmsrEotyodJSXOwKInzPnt6NlBIID2xJDU7NbUgtQgmK8PBoSTBaweMSSHBotT0 1Iq0zJwShDQTByfIcB6g4YwgNbzFBYm5xZnpEPlTjLock89uec8oxJKXn5cqJc5rA1IkAFKU UZoHNweWYl4xigO9JczrBVLFA0xPcJNeAS1hAlrSPPsxyJKSRISUVAOj+O03Nr0vzk+4uyt1 r/jKAmGdDKEtGxy3z3bkq/E79uDkxN9t+1KOnJnoynxWbe662tfT3GeH7Dysd0spePc3yz/n ueelpi493PRQ6qJ42zvnPeoHN18OyMwR2XbpUViQ/us3J7Rdtioeehq0+tZXFZGS0rRDuxbG vvv+guGHcfev+W/ynnN+llRiKc5INNRiLipOBAD3tmv4DAMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:33:44 -0000 On Tue, 16 Jul 2013, Jeffrey Hutzelman wrote: > On Tue, 2013-07-16 at 10:38 -0400, Greg Hudson wrote: > >> While I'm here, Jeff asked a question which wasn't really answered: >>> What about non-legacy applications implementing standards-track >>> GSS-API-using protocols according to a specification that isn't written >>> with the SSPI in mind? It's all well and good to say "call the API to >>> see what length you should use", but if the protocol says to send a >>> 1025-byte message, then I have to send a 1025-byte message, even if the >>> SSPI would rather I somehow only send a 1016-byte message. >> >> I don't understand this question. All RFC 3961 enctypes carry some >> plaintext expansion, which in turn affects the length of a CFX wrap >> token. The existing (RFC 3962) AES enctypes have a fixed 28-byte >> expansion, for instance. Kelley's current draft imposes a 32-byte or >> 40-byte expansion for aes128 or aes256. We are considering adding a >> variable 1-16 bytes to that expansion depending on input length. >> >> So, what does this hypothetical specification have in mind? Is it >> making assumptions about the amount of expansion from gss_wrap based on >> existing GSS mechanisms and enctypes? > > Huh? No; GSS doesn't promise a particular amount of expansion. My > understanding is that Microsoft says the only SSPI applications that are > negatively affected are those that don't call Microsoft's API to decide > how much data they should put in a wrap token. But GSS tokens aren't a > stream; they're discrete, so the amount of data I put in a token has to > be based on what the protocol says I put in the token, not what some > particular implementation's non-standard API says about how much data I > ought to put into a token. In this case, isn't it that particular implementation's non-standard API which is generating the actual GSS token? If the implementation is broken, the implementation is broken, but I don't see how the application's behavior comes into play just based on the above. -Ben From nico@cryptonector.com Tue Jul 16 09:55:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD3121F9302 for ; Tue, 16 Jul 2013 09:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMTzpPO65R3E for ; Tue, 16 Jul 2013 09:55:06 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6869821F9B18 for ; Tue, 16 Jul 2013 09:55:02 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 75BF76B0059 for ; Tue, 16 Jul 2013 09:54:58 -0700 (PDT) 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=+xyvVml+/6mCZr8uSeJa eMcYWYU=; b=YC5K+XzBC/+wCmZS6QGpeGhr4EZtJRG3ld+WX7UKU6eogV4sDVOo 5rgivXaE3LNzU4yZ7DS7YXFdr8Q98WbjfugAINiI4A5NXxZmkNh0a5uhSgqu/Dn5 smyN72LacWNjJVtHLm0wgMp1UMcQUrpQHTJCsYDgE1126VSP7mmTeTc= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id E8CBF6B007C for ; Tue, 16 Jul 2013 09:54:57 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so940070wid.4 for ; Tue, 16 Jul 2013 09:54:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XnE3Ps3DIOY/EJ4wVsaDC/nQPvkgGeVdfQwwv4feyv8=; b=ASjBCsPr6NHBG+CUnFu6qqne8XTQF6pzy/xlQYxJE0AuZl8dAVl3a03Ila7DdNrfq5 N5esoykQtrlZiReNOsCRbtVNfx9dRbrlDXogPTYx2TAOONmOI3jzGZvZPxJ3wzOQNc2S lwJgAMaEF5rnci8kB+RmcmOjXwmLVzftX727EyhTYQ2yfUpuWLQfI8T7/ur59J2jyuFy CROiIrWULpEoX5yG8VXvfnrk0a7v229Y894lKlNMTsEKuf/eQIkYWlZFarU/N9rsvZAy Vu2xvS1xFcq0/7zaAYEMH+LmhrDqx8ejA9R9tzhcBGEcFI909m2YmDffB1oIeKqzQNNl AQMw== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr1818325wjc.90.1373993696564; Tue, 16 Jul 2013 09:54:56 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 16 Jul 2013 09:54:56 -0700 (PDT) In-Reply-To: <1373988650.23943.4.camel@tuzanor.jhutz.local> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <1373988650.23943.4.camel@tuzanor.jhutz.local> Date: Tue, 16 Jul 2013 11:54:56 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:55:18 -0000 If the issue is apps using an unsupported interface from SSPI then I think we have our answer: it was important, once, to support them so they could get off 1DES and RC4, but I think it's much less important to get them off HMAC-SHA-1. So I think we can just go with a CBC mode cipher with random IV (and state chaining for RFC3961 apps). Nico -- From kwburgi@tycho.ncsc.mil Tue Jul 16 09:56:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6A221F9302 for ; Tue, 16 Jul 2013 09:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdhLgXjKHqta for ; Tue, 16 Jul 2013 09:56:31 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9EABF21F9A4C for ; Tue, 16 Jul 2013 09:56:31 -0700 (PDT) X-TM-IMSS-Message-ID: <47d680e200120d0f@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 47d680e200120d0f ; Tue, 16 Jul 2013 13:01:22 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r6GGuSdv024885; Tue, 16 Jul 2013 12:56:28 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kelley Burgin In-Reply-To: <51E55AFE.8020800@mit.edu> Date: Tue, 16 Jul 2013 12:57:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1503) Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:56:37 -0000 I've gone through the effort of re-writing the draft using CBC mode with = padding (being hopeful of its return - I'll be on vacation for most of = the next two weeks). I see however that it's past the submission = deadline, so if anyone's interested in seeing the draft before the tool = reopens, I'd be happy to send it to you (assuming this doesn't break any = IETF rules). Kelley On Jul 16, 2013, at 10:38 AM, Greg Hudson wrote: > On 07/12/2013 09:27 AM, Kelley Burgin wrote: >> 1. Come up with a security proof that the current short plaintext = algorithm is secure (so Nico isn't worried about baked-in crypto = weaknesses), and continue with CTS >> 2. Go back to CBC with padding (my original proposal a couple of = years ago) >> 3. Wait to see what SSPI (and other?) applications are negatively = affected by plaintext padding, then choose 1. or 2. >=20 > At the moment I favor #2. >=20 > I know I was the one who relayed the SSPI-based objections to padded = CBC > in the past, so this may seem inconsistent. At the time my reasoning > was that we were already used to the pain of having CTS and we aren't > going to get away from it any time soon, so even a vaguely-understood > objection based on SSPI usage ought to be sufficient. I did not > consider that the use of explicit IVs instead of confounders would > necessitate a complicated and novel construction to make CTS work for > short plaintexts. >=20 > Now that we have gone through that exercise, I think we would need a > much clearer objection from the SSPI front to justify the use of CTS > with the proposed enctype. >=20 > While I'm here, Jeff asked a question which wasn't really answered: >> What about non-legacy applications implementing standards-track >> GSS-API-using protocols according to a specification that isn't = written >> with the SSPI in mind? It's all well and good to say "call the API = to >> see what length you should use", but if the protocol says to send a >> 1025-byte message, then I have to send a 1025-byte message, even if = the >> SSPI would rather I somehow only send a 1016-byte message. >=20 > I don't understand this question. All RFC 3961 enctypes carry some > plaintext expansion, which in turn affects the length of a CFX wrap > token. The existing (RFC 3962) AES enctypes have a fixed 28-byte > expansion, for instance. Kelley's current draft imposes a 32-byte or > 40-byte expansion for aes128 or aes256. We are considering adding a > variable 1-16 bytes to that expansion depending on input length. >=20 > So, what does this hypothetical specification have in mind? Is it > making assumptions about the amount of expansion from gss_wrap based = on > existing GSS mechanisms and enctypes? >=20 From tsitkova@mit.edu Tue Jul 16 13:30:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F33121F9E98 for ; Tue, 16 Jul 2013 13:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx07umWORGDz for ; Tue, 16 Jul 2013 13:30:13 -0700 (PDT) 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 6512221F9ED4 for ; Tue, 16 Jul 2013 13:30:10 -0700 (PDT) X-AuditID: 1209190c-b7fa48e000000947-4e-51e5ad5183e8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 62.61.02375.15DA5E15; Tue, 16 Jul 2013 16:30:09 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r6GKU8I7013253 for ; Tue, 16 Jul 2013 16:30:09 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id r6GKU7kg019877 for ; Tue, 16 Jul 2013 16:30:08 -0400 Received: from W92EXHUB15.exchange.mit.edu (18.7.73.26) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 16 Jul 2013 16:30:07 -0400 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.78]) by W92EXHUB15.exchange.mit.edu ([18.7.73.26]) with mapi id 14.02.0309.002; Tue, 16 Jul 2013 16:30:07 -0400 From: Zhanna Tsitkov To: "kitten@ietf.org" Thread-Topic: CAMMAC-05: Verifier-MAC etc Thread-Index: AQHOgmNC8S9ILC/XQUOa6u9LpBI31w== Date: Tue, 16 Jul 2013 20:30:06 +0000 Message-ID: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.111.100.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1FE0B04EDBBD3547848BB0606D31D2B7@exchange.mit.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsUixG6nohu49mmgwaUfuhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpvF05kKOngq1i58ydjAeJKzi5GTQ0LAROLo7plsELaYxIV7 68FsIYF9jBLNDTZdjFxA9jVGid1ffzBBJO4ySmzuKYNIbGeU2Dp/CwuEs4pRomFpH3MXIwcH m4C6xNIHmSANIkDm3kNTWUBsZgFViS9dn5hBbGEg+86jpSwQNVoSKydsZoSw9SReLXkOVsMC VLP7yX92EJtXIEji3Iv/YHFGoEu/n1rDBDFTXOLWk/lMEB8ISiyavYcZ5pt/ux5CfaYo8f/q b0aIegOJ9+fmM0PY9hJft0+BmqMtsWzha2aIXYISJ2c+YZnAKDELyYpZSNpnIWmfhaR9FpL2 BYysqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3MYKikFOSZwfjm4NKhxgFOBiV eHgnhD0NFGJNLCuuzD3EKMnBpCTK+34FUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr99UoBxv SmJlVWpRPkxKmoNFSZz36dOzgUIC6YklqdmpqQWpRTBZGQ4OJQne+jVAjYJFqempFWmZOSUI aSYOTpDhPEDDW0BqeIsLEnOLM9Mh8qcYFaXEeReCJARAEhmleXC9sCT5ilEc6BVh3ukgVTzA BAvX/QpoMBPQ4ObZj0EGlyQipKQaGPk2PebNrNFf8728rdlBbgn71uYmVZmtLoZVHK1HutS+ mm7fFW7XeM7UKPz2kUvCM80b/X/vjs5S233js5LD+2bZ735fpdNcO91VOMqPOmme3JFz4JDi VPuArydXnTuj8KRhpfnS+wqXT8xi7P3zQPxyycRXTyc/9fI70V4auSL57Npti3eW71JiKc5I NNRiLipOBACxjK1AbQMAAA== Cc: Zhanna Tsitkov Subject: [kitten] CAMMAC-05: Verifier-MAC etc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:30:20 -0000 Couple comments on CAMMAC rev5 draft. 1. Verifier-MAC is defined as a sequence of an optional principal name and= required fields kvno, enctype and a checksum. It seems that in some cas= es providing both kvno and enctype might be redundant and even unnecessary.= (For example, in some cases enctype can be deduced from kvno, while svc-v= erifier may not need them at all.) So, it might be a good idea to make eit= her both these fields (kvno and enctype) "optional", or, at least, mark enc= type as an "optional" field. =20 The following comments are mostly about text clarity: 2. In section 3 "Validation" the third paragraph starts with "The following= information is needed:" and then lists "The KDC MAC" , "The Service MAC" = etc. This text is followed by the statement "The KDC MAC is required to al= low KDC to validate =85" The question that stays unanswered is what is "T= he KDC MAC" , "The Service MAC"? What mac they are of?=20 3. When giving details on AD-CAMMAC-BINDING (section 4.1) at the end of the= paragraph one mentions S4U2proxy scenario. It might be a good idea to mov= e this text closer to the Introduction or, even, have a separate "Use Cases= " section for potential use of AD-CAMMAC. 4. . In "Security Consideration" section the text "protected by the existin= g encryption methods on the ticket" implies that there are multiple enc me= thods on one ticket. Something simple like "encryption method on the tick= et" or similar would do a job. Thanks, Zhanna= From lukeh@padl.com Tue Jul 16 17:13:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393DE21F9C32 for ; Tue, 16 Jul 2013 17:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR1PhN9mPwTx for ; Tue, 16 Jul 2013 17:13:37 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BB2EE21F9CA1 for ; Tue, 16 Jul 2013 17:13:37 -0700 (PDT) Received: by us.padl.com with ESMTP id r6H0DLJF005926; Tue, 16 Jul 2013 20:13:24 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <1373988650.23943.4.camel@tuzanor.jhutz.local> Date: Wed, 17 Jul 2013 10:13:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5168BCEE-AFCF-4290-872C-8E47199C4170@padl.com> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <1373988650.23943.4.camel@tuzanor.jhutz.local> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,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] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:13:43 -0000 > Huh? No; GSS doesn't promise a particular amount of expansion. My > understanding is that Microsoft says the only SSPI applications that = are > negatively affected are those that don't call Microsoft's API to = decide > how much data they should put in a wrap token. But GSS tokens aren't = a > stream; they're discrete, so the amount of data I put in a token has = to > be based on what the protocol says I put in the token, not what some > particular implementation's non-standard API says about how much data = I > ought to put into a token. I think we need more input from Microsoft to know exactly what the issue = is, if anything. At this point in time I actually have no idea. :-) One thing I will point out, though: SSPI doesn't have an equivalent to = gss_wrap_size_limit(); instead one calls = QueryContextAttributes(SECPKG_ATTR_SIZES) and provides a token buffer of = cbMaxToken bytes and and a padding buffer of cbBlockSize. My = understanding is that, for RFC 4121 encryption types, the padding buffer = is not used and instead any padding is rotated into the token. But maybe = Yizeng can correct me (it's hard to tell for AES CTS, because there's no = padding anyway). Anyway, the token/padding buffers may be smaller after calling = EncryptMessage. -- Luke= From kaduk@mit.edu Tue Jul 16 17:17:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECA021F8D10 for ; Tue, 16 Jul 2013 17:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ECH13pF58W for ; Tue, 16 Jul 2013 17:17:48 -0700 (PDT) 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 9E63421F8C4C for ; Tue, 16 Jul 2013 17:17:47 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-9f-51e5e2aa6c6c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 3D.A7.02387.AA2E5E15; Tue, 16 Jul 2013 20:17:46 -0400 (EDT) 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 r6H0HjQZ025893; Tue, 16 Jul 2013 20:17:46 -0400 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 r6H0Hhun013023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 20:17:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r6H0HhUC004475; Tue, 16 Jul 2013 20:17:43 -0400 (EDT) Date: Tue, 16 Jul 2013 20:17:43 -0400 (EDT) From: Benjamin Kaduk To: Kelley Burgin In-Reply-To: Message-ID: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> 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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrLvq0dNAg7ZWZYujm1exWMxryHBg 8liy5CeTx9bmf4wBTFFcNimpOZllqUX6dglcGefa/AuesFT86u5haWC8xtzFyMkhIWAisWTd STYIW0ziwr31QDYXh5DAPkaJOd3/wRJCAhsZJV6dq4RIHGKSWPn/MFRVA6PEhQ2b2EGqWAS0 JVrenWEFsdkEVCRmvtkI1i0ioCVx9eEcsHXMAsIS68/NALOFBUokJm7fA1bPKeAkca39DZjN K+AosXPRFVaIBa+YJaZf+AC2QFRAR2L1/iksEEWCEidnPmGBGGopce7PdbYJjIKzkKRmIUkt YGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZopeaUrqJERyokvw7GL8dVDrEKMDBqMTD OyHsaaAQa2JZcWXuIUZJDiYlUV6X+0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxzLwDleFMS K6tSi/JhUtIcLErivM+eng0UEkhPLEnNTk0tSC2CycpwcChJ8N5/CNQoWJSanlqRlplTgpBm 4uAEGc4DNPwQSA1vcUFibnFmOkT+FKOilDjvSpCEAEgiozQPrheWSF4xigO9Isx7BqSKB5iE 4LpfAQ1mAhrcPPsxyOCSRISUVANj894pP7M+xDn8l1z5jWHaMb4LAeosf3gnnVp4jsdGYmbZ 5+ktsTl3zA9kXl0dm9bx/uCKQAV1Uakpf76InZ2kV9ezOFar0sukY4ZvxKoz9slsgkoWEefZ 1UQfxHWVSK2SUDHyOK0T+Tmdz0F3r/cqZbvaR8LeJ6IWvf17c2NM5PfUlo31ea1KLMUZiYZa zEXFiQAgQkr1/wIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:17:54 -0000 On Tue, 16 Jul 2013, Kelley Burgin wrote: > I've gone through the effort of re-writing the draft using CBC mode with > padding (being hopeful of its return - I'll be on vacation for most of > the next two weeks). I see however that it's past the submission > deadline, so if anyone's interested in seeing the draft before the tool > reopens, I'd be happy to send it to you (assuming this doesn't break any > IETF rules). I think it should be fine to post a rendered copy somewhere on the internet and send a link to the list. I, for one, would be interested in seeing it. Thanks, Ben From zhuhongru@chinamobile.com Tue Jul 16 18:54:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939B821F868C for ; Tue, 16 Jul 2013 18:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVmOZhOgUnII for ; Tue, 16 Jul 2013 18:54:26 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 46FFA21F9A51 for ; Tue, 16 Jul 2013 18:54:20 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151e5f901bde-03bde; Wed, 17 Jul 2013 09:53:06 +0800 (CST) X-RM-TRANSID: 2ee151e5f901bde-03bde Received: from cmccPC (unknown[10.2.51.12]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251e5f900a31-4ce40; Wed, 17 Jul 2013 09:53:06 +0800 (CST) X-RM-TRANSID: 2ee251e5f900a31-4ce40 From: "Judy Zhu" To: =?UTF-8?B?J+m9kOaXu+m5jyc=?= , References: <017101ce81de$7711ef70$6535ce50$@com> In-Reply-To: <017101ce81de$7711ef70$6535ce50$@com> Date: Wed, 17 Jul 2013 09:54:04 +0800 Message-ID: <000101ce8290$84b0e4d0$8e12ae70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5wgtAdgysqV4bRQJ6fBAPCrl+yywAA0yhgBFX1pZAALJqf4A== Content-Language: zh-cn Subject: [kitten] draft-zhu-core-groupauth-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 01:54:31 -0000 And also a very simple clarification here is: this group communications = security is not limited to M2M, actually it can be used in any scenario = which group case does exist.=20 Thanks=20 Judy -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: kitten-bounces@ietf.org = [mailto:kitten-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 = =E9=BD=90=E6=97=BB=E9=B9=8F =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8816=E6=97=A5 = 12:40 =E6=94=B6=E4=BB=B6=E4=BA=BA: kitten@ietf.org =E4=B8=BB=E9=A2=98: [kitten] FW: New Version Notification for = draft-zhu-core-groupauth-00.txt Dear all, We have submitted a new draft about the group authentication and send it = to saag list for discussion. We also want to find a more suitable = subgroup to discuss it.=20 With advice from some experts, we want to forward it to this working = group and try to attract yours' attention for this draft. All comments and suggested improvements are welcome. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: =E9=BD=90=E6=97=BB=E9=B9=8F = [mailto:qiminpeng@chinamobile.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 = 11:11 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'saag@ietf.org' =E4=B8=BB=E9=A2=98: FW: New Version Notification for = draft-zhu-core-groupauth-00.txt Hi everyone, The authors have submit a new draft for the group authentication. We = will appreciate if you have a look and give us any comment or = suggestion. The link is as below. Here is a problem that for group communication there is only uni-cast = authentication instead of group authentication method can be used. This = draft wants to analyze the problem, to summarize group authentication = requirement and to provide a framework of solutions. This draft is to discuss a new kind of authentication so we think it = would be better to discuss it also in security email list and try to = find a suitable subgroup to discuss it. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 = 10:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ye Tian; Minpeng Qi; Judy Zhu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zhu-core-groupauth-00.txt A new version of I-D, draft-zhu-core-groupauth-00.txt has been successfully submitted by Judy Zhu and posted to the IETF repository. Filename: draft-zhu-core-groupauth Revision: 00 Title: Group Authentication Creation date: 2013-06-24 Group: Individual Submission Number of pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt Status: = http://datatracker.ietf.org/doc/draft-zhu-core-groupauth Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-00 Abstract: The group communication is designed for the communication of Internet of Things. A threat is identified in [I-D.ietf-core-groupcomm] that current DTLS based approach is unicast oriented and there is no supporting on group authentication feature. Unicast oriented authentication will causing serious burden when a large number of terminal nodes will be involved inevitably. In another aspect, some terminals will own the same characteristics, such as owning same features, in the same place, working in the same time, etc. With this mechanism, all terminals can be authenticated together with little signaling and calculation at the same time. It will reduce the network burden and save time. This draft describes the security of group authentication and an group authentication implementation method for the Internet of things. = =20 The IETF Secretariat _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From tlyu@mit.edu Tue Jul 16 19:55:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA1021F9C68 for ; Tue, 16 Jul 2013 19:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KApYZnrQOO9A for ; Tue, 16 Jul 2013 19:55:35 -0700 (PDT) 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 F063A21F9C42 for ; Tue, 16 Jul 2013 19:55:34 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-1d-51e607a4c326 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A3.5C.02387.4A706E15; Tue, 16 Jul 2013 22:55:32 -0400 (EDT) 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 r6H2tDMm012751; Tue, 16 Jul 2013 22:55:32 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r6H2tB3k026535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 22:55:12 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r6H2tBaE026748; Tue, 16 Jul 2013 22:55:11 -0400 (EDT) To: Kelley Burgin References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> From: Tom Yu Date: Tue, 16 Jul 2013 22:55:11 -0400 In-Reply-To: (Kelley Burgin's message of "Tue, 16 Jul 2013 12:57:12 -0400") Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrbuE/VmgwY11VhbX359jtzi6eRWL xbyGDAdmj/2tx1g9liz5yeSxtfkfYwBzFJdNSmpOZllqkb5dAldG/8yjTAUv2St+3MltYFzB 1sXIySEhYCKxZNtuJghbTOLCvfVAcS4OIYF9jBJ9jQ+ZIJyNjBK3FrdBZc4xSby4twwq08Uo cXjmSUaQfhEBLYmrD+cwg9jMAnESC95OBpsrLFAk8fR/IzNEww9miXV9p4EcDg42AWmJo4vL QGpYBFQl3h04yQpSwynQyCjxc+sHdpAEr4CFRPPqq2ALeAQ4JX79ncAGEReUODnzCQvEMi2J G/9eMk1gFJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M4PCV 5N/B+O2g0iFGAQ5GJR7eCWFPA4VYE8uKK3MPMUpyMCmJ8t5gfRYoxJeUn1KZkVicEV9UmpNa fIhRgoNZSYR330egct6UxMqq1KJ8mJQ0B4uSOO+zp2cDhQTSE0tSs1NTC1KLYLIyHBxKErxR bEBDBYtS01Mr0jJzShDSTBycIMN5gIZ/AFnMW1yQmFucmQ6RP8WoKCXOmwjSLACSyCjNg+uF pZdXjOJArwjz2oBU8QBTE1z3K6DBTECDm2c/BhlckoiQkmpgdBNKTU+2unjr4y2jFVxOmy8t YsyX8gg+naJ3/tv0z/bCG7gu8jSvnXhUiOWFU/2ihhUZSn/sGW9PTDrWuvW7YaCKV+/PKVoL zystv5Iv8OouC6Nn4MZfPZEvk9PrV+gENmjnP2u7qPH88XTJuDX+zrvjXf5N32n0ddXyjwe+ OPAvvOjJVCV3XomlOCPRUIu5qDgRAKwQVTMKAwAA Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 02:55:42 -0000 Kelley Burgin writes: > I've gone through the effort of re-writing the draft using CBC mode > with padding (being hopeful of its return - I'll be on vacation for > most of the next two weeks). I see however that it's past the > submission deadline, so if anyone's interested in seeing the draft > before the tool reopens, I'd be happy to send it to you (assuming > this doesn't break any IETF rules). The I-D submission cutoff functionally allows the WG Chairs to set reasonable expectations for what participants have read before the in-person WG session. (This is a topic that undergoes some significant recurring debate in the IETF at large.) I believe under exceptional conditions, a WG Chair can work with an AD to allow posting within the blackout window. I also believe that may not be required here, because most of the active participants with an interest in this document already have a good idea of what the CBC mode proposal will look like. From hartmans@mit.edu Wed Jul 17 04:29:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDD121F999C for ; Wed, 17 Jul 2013 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50B6PI-r16OM for ; Wed, 17 Jul 2013 04:29:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCFD21F93F3 for ; Wed, 17 Jul 2013 04:29:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DDBD920141; Wed, 17 Jul 2013 07:29:39 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2uJRtc_i0rw; Wed, 17 Jul 2013 07:29:37 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 17 Jul 2013 07:29:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DFBBC81758; Wed, 17 Jul 2013 07:29:40 -0400 (EDT) From: Sam Hartman To: Kelley Burgin References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> Date: Wed, 17 Jul 2013 07:29:40 -0400 In-Reply-To: (Kelley Burgin's message of "Tue, 16 Jul 2013 12:57:12 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:29:51 -0000 >>>>> "Kelley" == Kelley Burgin writes: Kelley> I've gone through the effort of re-writing the draft using Kelley> CBC mode with padding (being hopeful of its return - I'll be Kelley> on vacation for most of the next two weeks). I see however Kelley> that it's past the submission deadline, so if anyone's Kelley> interested in seeing the draft before the tool reopens, I'd Kelley> be happy to send it to you (assuming this doesn't break any Kelley> IETF rules). Kelley Hi. It would be great to make the text available to people, but not in the form of a WG draft. We're at a point in the process where the presumption is that we will not make a given change unless consensus is demonstrated to make the change. I think most of us can guess what CBC would look like but having text available would still be great. Distributing to people is fine, putting on a web page is fine. The question before the WG is whether to adopt Tom's proposal to change cipher modes as implemented in text by Kelley. Just because editors of the draft are making the proposal does not give it special standing. We'll need to make a consensus call on this after discussion in the meeting and confirm on the list. An alternative would be to post this as an individual draft draft-author-kitten-kerberos-aes256-alternate-cbc or some such. I've asked Stephen if he would grat an exception if you want to go that route. From stephen.farrell@cs.tcd.ie Wed Jul 17 06:54:47 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A749411E80E2 for ; Wed, 17 Jul 2013 06:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE7H5-WRFTb4 for ; Wed, 17 Jul 2013 06:54:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA3811E80A5 for ; Wed, 17 Jul 2013 06:54:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6DCFDBEB6; Wed, 17 Jul 2013 14:54:12 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezAM4BLOsekI; Wed, 17 Jul 2013 14:54:12 +0100 (IST) Received: from [IPv6:2001:770:10:203:588a:ac19:318b:469b] (unknown [IPv6:2001:770:10:203:588a:ac19:318b:469b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4BA94BE38; Wed, 17 Jul 2013 14:54:12 +0100 (IST) Message-ID: <51E6A203.6050002@cs.tcd.ie> Date: Wed, 17 Jul 2013 14:54:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sam Hartman References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:55:06 -0000 On 07/17/2013 12:29 PM, Sam Hartman wrote: > I've asked Stephen if he would grat an exception if you want to go that > route. If the chairs figure that it'll help make for a better wg meeting then I will. Cheers, S. From nico@cryptonector.com Wed Jul 17 09:47:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A8121F9133 for ; Wed, 17 Jul 2013 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcP8Wy0cSlkw for ; Wed, 17 Jul 2013 09:47:32 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3712421F9A5F for ; Wed, 17 Jul 2013 09:47:32 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 582D0768061 for ; Wed, 17 Jul 2013 09:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=+X4EWQ8j6RSU7VmhbunoWTSsmA8=; b=H5VVCNhIPO8 EVKGwiF+cUAROcMgZjIZocFKtc0yloDdVVmMTn+jBBYvNfldd2dDLwOjDfc4v72R 1Ym+Nv9GrPAtDH+rFIJmE+2kogz2aI1x6NcA/fDMxGtbrzrmilmU4ft46jMmWM70 j2XI8UJbT0xvLfQymbew7TFWJOUOisCA= 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-a70.g.dreamhost.com (Postfix) with ESMTPSA id DCE5576803E for ; Wed, 17 Jul 2013 09:47:30 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so5701392wiw.2 for ; Wed, 17 Jul 2013 09:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XRFTWf+u0mJVQbQ2bwLb20y7bPMUxjaPZKkWYxWA/Z4=; b=M0rO68rdHvdHxc/dP6s8VTPj/SM/G1oi6coSTy8tzcC6JXi61ntybvV6KRHYCpIWkY t9fdoKPT2onl0JlMVEXlUi7zuCVZ8DfiDSti7VpsHarWoGm+jUAxZUj1G2nBYMdPPwIv hLoiHn3AU881uWS0+cx9zV6s1LZFrmgw6m+ClahAQ9plHRyEL9GbO1BcT/Sz8guwgoMD uaFz2nTylmEQLq5LL2M0nQ8hKbTVeAABTJ0QjKmTDiGSICF/jXZGTgsKT7HDHGS4NGQf KcwB2JWDfPvkYQMk1joBC3TNAQEtcNdaiRTTCbshcwSPhGadlvj4YT0oq1NpzphTiGHG PRrw== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr5251251wib.33.1374079648965; Wed, 17 Jul 2013 09:47:28 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 17 Jul 2013 09:47:28 -0700 (PDT) In-Reply-To: References: <3E0FEBD9-CCB8-4DE2-A967-5521F9DD6C89@jpl.nasa.gov> Date: Wed, 17 Jul 2013 11:47:28 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:47:37 -0000 On Fri, Jul 12, 2013 at 10:34 PM, Henry B. Hotz wrote: > On Jul 11, 2013, at 4:14 PM, Nico Williams wrote: > > So the short version would be that we use a kx509-issued cert as a stand-= in for a cross-realm relationship. Yes. Well, the kx509-issued cert (or, really, any cert, but generally it'd be a kx509-issued cert) and its cert validation path. > I recall a bunch of jokes about that while writing the RFC. However Doug= Engert actually proposed that use case for Globus. It's arguably a minor = extension of the existing SLCS policies. The security considerations just = say "here there be [policy] dragons". ;-) There's only three dragons, one of which has always existed, and another of which existed in theory but we had no way to exercise: - apps must validate transit paths (pre-existing dragon) - apps and TGSes must know how to handle X.500 naming in transit paths (pre-existing but mostly unexercised dragon) - Leap-of-Faith / Trust on First Use / pseudonymous authentication (which should fail safe because apps should validate transit paths) Also, when using the new PKCROSS system, if the KDC can validate the PK trust path and is happy with it, it can set the TRANSIT-POLICY-CHECKED bit, so that you can have non-LoF/TOFU interop out of the box. > Since it's up to the kdc to decide how X.509 cert's are related to princi= pals, I don't think you actually need anything except a convention (which y= our assumptions imply) for when the client should try this approach. The client should try this approach when: - it can find no non-PKCROSS trust path to the target realm - it's configured to do so and/or - it wants privacy relative to its home realm (this could be a flag in an = API) > Strict need aside, I can see some value in being able to provide informat= ion about how a foreign principal was validated. Putting an X.509 name int= o a transited field doesn't strike me as a bad way to do it, especially sin= ce it gives you a legacy-compatible way for the KDC to flag policy issues. = Another less-compatible way to do it would be to just issue an X500 princi= pal tgt directly. We already have x.500 naming for transit paths, which should support x.509 naming (but it's hard to tell as RFC4120 doesn't give a reference for X.500 naming! neither does RFC1510). > Formal modeling of Kerberos says "here there be dragons" about cross-real= m. It would be nice if an explicit extension to support X.509 certs for cr= oss-realm could be restricted in a way which allowed proof of the desired p= roperties. There's already dragons. And I want the new LoF/TOFU dragon option. Some dragons are cute/snuggly/wuggly. >>> The reason *I* would combine kx509 with PKINIT would be the use case of= someone needing X.509 credentials on multiple client computers at once. T= his is a real use case for us. >> >> Presumably all from different realms? Would that be the same as >> described above? > > Nah. Just a user can only have one PIV card, but they may need to use mo= re than one computer at a time. Using kx509-issued certs instead of the or= iginals on the card gives you a way to cache your authentications. It's al= so faster to set up than waiting through multiple cycles on an RSA token. Ahhh, credential delegation, effectively. >> Oh, it's not PKIX I care about. I just want something that scales >> better than symmetrically keyed Kerberos cross-realm principals, and >> with better security policies (e.g., sysadmins do not have to exchange >> passwords from which the x-realm keys are derived; they might exchange >> passwords to authenticate the key exchange, but the sysadmins should >> not learn the keys as a result, or they might exchange certificate >> fingerprints, =E2=80=A6). > > We're less concerned with the "insider threat" than most. That's nice, for you :) But you should care about it. And we should care about: a) making sysadmins' lives easier, b) removing the need for them to know sensitive secret keys, c) scalability (see (a)), d) removing the need for manual key rollover and outages during key rollover. We might agree that we don't need e) LoF/TOFU, but I think ABFAB is proof that we need something like it, and also, for a very large Internet I think LoF/TOFU makes some sense, and indeed we see some of that in TLS server PKI specifications like key/CA pinning, and in browser plugins like CertPatrol. Anyone who's had to deal with a 1DES migration in a complex multi-realm environment will appreciate (d). > I agree public-key better models the trust relationship of 1-way cross re= alm than symmetric key. Also agree that configuring those relationships ha= s a lot of practical issues. If it's explicitly configured, then I don't t= hink PKIX adds any value. Just use asymmetric encryption instead of symmet= ric. (Maybe issue a symmetric tgt to make subsequent tgs requests more eff= icient?) I don't care if PK better models the trust relationship of a 1-way cross-realm trust than symmetric keys :) though it does -- I don't care because we already have addressed the impedance mismatch of symmetric keying of asymmetric relations (via naming conventions). What matters to me is the features listed above. Nico -- From shawn.emery@oracle.com Wed Jul 17 15:23:24 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D198E21F8FF3 for ; Wed, 17 Jul 2013 15:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKNykBHWCDbk for ; Wed, 17 Jul 2013 15:23:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 34BDA21F8F78 for ; Wed, 17 Jul 2013 15:23:18 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6HMNFTg015112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Jul 2013 22:23:16 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6HMNFP2007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jul 2013 22:23:15 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6HMNFh0014277 for ; Wed, 17 Jul 2013 22:23:15 GMT Received: from [10.159.127.43] (/10.159.127.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 15:23:14 -0700 Message-ID: <51E71984.3060308@oracle.com> Date: Wed, 17 Jul 2013 16:24:04 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [kitten] IETF 87 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:23:25 -0000 I've uploaded a draft agenda for the session in Berlin: http://www.ietf.org/proceedings/87/agenda/agenda-87-kitten Please let me know if there are any omissions/corrections before the final version is due on 7/22. Shawn. -- kitten co-chair From nico@cryptonector.com Wed Jul 17 15:43:22 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1509221F9E7E for ; Wed, 17 Jul 2013 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wDugjc3nTZE for ; Wed, 17 Jul 2013 15:43:08 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A08421F854E for ; Wed, 17 Jul 2013 15:43:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 8CAD0B805C for ; Wed, 17 Jul 2013 15:43:07 -0700 (PDT) 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=dq1ZxLac99xJQEBRZuIY 7rubAsc=; b=pk7Sre64/muhcMTCynD5lJ0wmKCyU0RIfQW9RmgkryaOsAzwBkYh xJkNruVrSEh68G8wemaymyKL4V3KtxwVIIFItxv0Lgplx7abN3p/caabj2ZH1gU/ Bq8SWbDTiIJjkld/Y/4Me9WU6f7U1Qz7gobd2uI4oiLJYR4n/ngad2g= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 3613FB8058 for ; Wed, 17 Jul 2013 15:43:07 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so2554005wiv.9 for ; Wed, 17 Jul 2013 15:43:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eib04eJROwpAez+yf7h9qW1NyuHx7a3lhp1I4PT5Gx4=; b=kqfhcF2cx0BsXs5kOdhv4nskr8TreQjAsj7kORWYFVOWNnaiUokbH1Xac3LmzURYaE XQSsbD5t9RT/ohnHK+BtivikqgKbFvAH870HEo70sdXq7xL+25teBR8dmI04bWnwEaT8 FPmEIfwjJhOVdMoTNMAWzGA32qkLmrEZDvCLz9wLqtPYex+1IZCX6vFp54nKLEgJkk03 DgmYc49IM0Gh9BLnqh27beJTMFrx5CNlX3YoEEPdnF9F81A1PRSES/xnMHdVJ3Ov86yZ hk9+f9eNhx7ETvDpov5Xf8S1PAW0E7Z5dPPhCthvEAOoLax53l1eqC3q8k8pgrTS9W2N zJXw== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr6202462wic.20.1374100985619; Wed, 17 Jul 2013 15:43:05 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 17 Jul 2013 15:43:05 -0700 (PDT) In-Reply-To: <51E71984.3060308@oracle.com> References: <51E71984.3060308@oracle.com> Date: Wed, 17 Jul 2013 17:43:05 -0500 Message-ID: From: Nico Williams To: Shawn M Emery Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] IETF 87 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:43:22 -0000 On Wed, Jul 17, 2013 at 5:24 PM, Shawn M Emery wrote: > Please let me know if there are any omissions/corrections before the final > version is due on 7/22. Roland had a really good suggestion for simplification of the async API extensions. I would submit an update for that it's a day past the deadline. If you want I can post a link anyways -- I'd rather the update be reviewed if it will be reviewed at all in time for the WG meeting, else that it be left for the next meeting (there's no urgency). Nico -- From shawn.emery@oracle.com Thu Jul 18 00:37:19 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7549A21F9B12 for ; Thu, 18 Jul 2013 00:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhsu52g1tU6t for ; Thu, 18 Jul 2013 00:37:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 085FC21F9AED for ; Thu, 18 Jul 2013 00:37:12 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6I7bAXu012804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 07:37:11 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6I7bA9N025598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jul 2013 07:37:10 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6I7b9vt027548; Thu, 18 Jul 2013 07:37:10 GMT Received: from [10.159.126.161] (/10.159.126.161) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jul 2013 00:37:09 -0700 Message-ID: <51E79B57.7020102@oracle.com> Date: Thu, 18 Jul 2013 01:37:59 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nico Williams References: <51E71984.3060308@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: kitten@ietf.org Subject: Re: [kitten] IETF 87 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 07:37:19 -0000 On 07/17/13 04:43 PM, Nico Williams wrote: > On Wed, Jul 17, 2013 at 5:24 PM, Shawn M Emery wrote: >> Please let me know if there are any omissions/corrections before the final >> version is due on 7/22. > Roland had a really good suggestion for simplification of the async > API extensions. I would submit an update for that it's a day past the > deadline. If you want I can post a link anyways -- I'd rather the > update be reviewed if it will be reviewed at all in time for the WG > meeting, else that it be left for the next meeting (there's no > urgency). Perhaps we should take this off the agenda for now. We can continue the discussion on-list based on the new draft when submissions are allowed on 7/29. Shawn. -- kitten co-chair From mayank@google.com Thu Jul 18 22:34:36 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01F811E829A for ; Thu, 18 Jul 2013 22:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwA4CB00l92i for ; Thu, 18 Jul 2013 22:34:35 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 38E7611E8292 for ; Thu, 18 Jul 2013 22:34:35 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so3491437wev.8 for ; Thu, 18 Jul 2013 22:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=FcBRTUjycs7V4J9c82MUc2YC82A3VcJqYZpSyjiZQWs=; b=igWZckILJZvraFgsjIvnDjk0xfyJaU4tfjbfE9ZQE5DfjYiERwwfy15WkHos3rWSEG 0uxZ8sdh7aNR9GMj6CMtI+fvL2b63biMZ84wlC3R2YJIUFWtRVPzuRW9F3dTbA4HK9ev jkRWyN5GcTHRi/70/+M8MLwbWXZbUo0anX/ztCoK2spGYjKKTV8xQF7rnTbdqCM8z4x2 EqRYe6mo0BEZvOJ6QtEvL/qcpuVJ8kNl1OfnjdfD4yyLQOPJRbK0G681YXYEOYqT32nW n0ffKy4UWYU0zHdDD67O1tsdHXoTE9ZcD15VoAGgQXns8DES3+Z3gWsgno+9NfpU/V/7 cRig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=FcBRTUjycs7V4J9c82MUc2YC82A3VcJqYZpSyjiZQWs=; b=PBBhq6ZVqBpUVaE7sCVpmSDY/MiIuyVKiMFfM9YVbNZQQtSOX5kkt0+pN2gjJTo/uz NjikZOf+sCuaxZWpJ4aNZAIMqMfsnBAr6rMyFGkjiFjOuegdo+cdT0kbLL6FEOrWwENS 0zyGg2GbXOgjR1TtESF8atoJrMWMqpuILfnqODkUT/lYxL2j/busljqUDrL4sIFW5cQQ Q/Qi8IeEaeTaKB9hvP8rTVaRfRTgoopnlr/PHrbsXs7jo/LtNL/Fj0g+LNzZsIOBC9NT 7/090u3tSxW++4chn/Xj9nz7EI1NgW7t275RFn8zIKDj7odOW/ZsWCphY+4kohSFlfCH j0ag== X-Received: by 10.194.93.74 with SMTP id cs10mr11146522wjb.9.1374212074302; Thu, 18 Jul 2013 22:34:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.46.195 with HTTP; Thu, 18 Jul 2013 22:34:04 -0700 (PDT) In-Reply-To: References: From: Mayank Upadhyay Date: Thu, 18 Jul 2013 22:34:04 -0700 Message-ID: To: Jeffrey Hutzelman , Weijun Wang , kitten@ietf.org, OpenJDK Content-Type: multipart/alternative; boundary=047d7bf0c86c8918e804e1d6ae00 X-Gm-Message-State: ALoCoQkYu/xXxysHy98sei0CmbuuG+YESMkStjsLgGeYE27WqBze3nEW0UHBfLf1wohRepMSYCABgwC3CLd0FFn1G7eXgMlhJ4siE/0ACqNTRoeTcllmi4N1uUUwX7QcnoEZAyF41o54PiLZY2CKR87EdyMlB2ELghkukZ9iGJoFOWqYcDAMgsADiYi7N8hYem/jkXs2J7ol Subject: [kitten] Fwd: Kitten Digest, Vol 104, Issue 14 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:34:36 -0000 --047d7bf0c86c8918e804e1d6ae00 Content-Type: text/plain; charset=ISO-8859-1 Hi Weijun, You point out a legitimate problem, but I want to understand a couple of assumptions: 1. Why allow only initSecContext() and acceptSecContext() to have this new behavior? Imagine a mechanism built on top of TLS which is renegotiating the session intermixed with actual payload, and had some error it wanted to communicate to the peer (e.g., a TLS Alert). Is there any particular reason you'd like to avoid that scenario? 2. I didn't quite follow the comment about the default method (maybe it shows that my Java is dated :). GSSException is not an interface but a concrete class, and adding a method to it adds it in the JRE starting at some particular version. What happens when applications that call the new method are run on an older JRE? 3. Don't we also need to set this token when the mechanism creates a GSSException instance? Note that the concrete class has no setter methods of any kind at this time, but two constructors. Thanks, Mayank ---------- Forwarded message ---------- From: Date: Mon, Jul 15, 2013 at 12:01 PM Message: 4 Date: Mon, 15 Jul 2013 11:58:47 +0800 From: Weijun Wang To: kitten@ietf.org, OpenJDK Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails Message-ID: <51E37377.1030704@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi All I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail is about a design flaw in the initSecContext and acceptSecContext methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2]. The GSSContext::initSecContext() method could either return a token (possibly null if no more token is needed) when the call succeeds or throw a GSSException if there is a failure, but not *both*. The same applies to acceptSecContext(). On the other hand, the C bindings of GSS-API has a chance to return both, and it does try to make use of both of them (according to RFC 2743 2.2.1 [3]): It is the caller's responsibility to establish a communications path to the target, and to transmit any returned output_token (independent of the accompanying returned major_status value) to the target over that path. Without the ability to send a token when there is a failure, a Java program has no chance to tell the other side what's happening. This is very user-unfriendly. Also, in the case of SPNEGO, a "reject" NegTokenResp token will never be able to sent out. My current proposal is to add a new method getOutputToken() to the GSSException class (which will be thrown when an error occurs) to return this last token. This means the method calls will be something like try { send(initSecContext(inToken)); } catch (GSSException e) { if (e.getOutputToken() != null) { send(e.getOutputToken()); } throw e; } The getOutputToken() method can only return a non-null value when it's thrown by an initSecContext or acceptSecContext call. The method won't throw another GSSException even if the exception was thrown in other calls. We can use the new JDK 8 default method feature [1] to add this new method to the existing GSSException interface. Thanks Weijun [1] http://tools.ietf.org/html/rfc5653#section-7.4.3[2] http://tools.ietf.org/html/rfc5653#section-7.4.9 [3] http://tools.ietf.org/html/rfc2743#page-46 [4] http://tools.ietf.org/html/rfc5653#section-7.4.5 ------------------------------ Message: 5 Date: Mon, 15 Jul 2013 13:33:41 -0400 From: Jeffrey Hutzelman To: Weijun Wang Cc: kitten@ietf.org, OpenJDK , jhutz@cmu.edu Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails Message-ID: <1373909621.23365.286.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote: > My current proposal is to add a new method getOutputToken() to the > GSSException class (which will be thrown when an error occurs) to return > this last token. This means the method calls will be something like This seems like an elegant solution to the problem. -- Jeff --047d7bf0c86c8918e804e1d6ae00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Weijun,

You point out a legitimate p= roblem, but I want to understand a couple of assumptions:
    Why allow only initSecContext() and acceptSecContext() to have this new be= havior? Imagine a mechanism built on top of TLS which is renegotiating the = session intermixed with actual payload, and had some error it wanted to com= municate to the peer (e.g., a TLS Alert). Is there any particular reason yo= u'd like to avoid that scenario?

  1. I didn't quite follow the comment about the default method= (maybe it shows that my Java is dated :). GSSException is not an interface= but a concrete class, and adding a method to it adds it in the JRE startin= g at some particular version.=A0What happens when applications that call th= e new method are run on an older JRE?

  2. Don't we also need to set this token when the mechanism cr= eates a GSSException instance? Note that the concrete class has no setter m= ethods of any kind at this time, but two constructors.
Thanks= ,
Mayank

---------- Forwarded messag= e ----------
From: = <kitten-request@ietf.org&= gt;
Date: Mon, Jul 15, 2013 at 12:01 PM

Message: 4
Date: Mon, 15 Jul 2013 11:58:47 +0800
From: Weijun Wang <weijun.wang= @oracle.com>
To: kitten@ietf.org, OpenJDK <security-dev@openjdk.java.net= >
Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way
=A0 =A0 =A0 =A0 to return a token when context establishment fails
Message-ID: <51E37377.103= 0704@oracle.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Hi All

I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail
is about a design flaw in the initSecContext and acceptSecContext
methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2]= .

The GSSContext::initSecContext() method could either return a token
(possibly null if no more token is needed) when the call succeeds or
throw a GSSException if there is a failure, but not *both*. The same
applies to acceptSecContext().

On the other hand, the C bindings of GSS-API has a chance to return
both, and it does try to make use of both of them (according to RFC 2743 2.2.1 [3]):

=A0 =A0 It is the caller's responsibility to establish a communications= path
=A0 =A0 to the target, and to transmit any returned output_token (independe= nt
=A0 =A0 of the accompanying returned major_status value) to the target over=
=A0 =A0 that path.

Without the ability to send a token when there is a failure, a Java
program has no chance to tell the other side what's happening. This is<= br> very user-unfriendly. Also, in the case of SPNEGO, a "reject"
NegTokenResp token will never be able to sent out.

My current proposal is to add a new method getOutputToken() to the
GSSException class (which will be thrown when an error occurs) to return this last token. This means the method calls will be something like

=A0 =A0 =A0 =A0 =A0try {
=A0 =A0 =A0 =A0 =A0 =A0 =A0send(initSecContext(inToken));
=A0 =A0 =A0 =A0 =A0} catch (GSSException e) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0if (e.getOutputToken() !=3D null) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0send(e.getOutputToken());
=A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0throw e;
=A0 =A0 =A0 =A0 =A0}

The getOutputToken() method can only return a non-null value when it's<= br> thrown by an initSecContext or acceptSecContext call. The method won't<= br> throw another GSSException even if the exception was thrown in other calls.=

We can use the new JDK 8 default method feature [1] to add this new
method to the existing GSSException interface.

Thanks
Weijun

[1] http://tools.ietf.org/html/rfc5653#section-7.4.3[2]
http://tools.ietf.org/html/rfc5653#section-7.4.9
[3] http://tools.ietf.org/html/rfc2743#page-46
[4] http://tools.ietf.org/html/rfc5653#section-7.4.5


------------------------------

Message: 5
Date: Mon, 15 Jul 2013 13:33:41 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu<= /a>>
To: Weijun Wang <weijun.wang@o= racle.com>
Cc: kitten@ietf.org, OpenJDK <security-dev@openjdk.java.net= >,
=A0 =A0 =A0 =A0 jhutz@cmu.edu
Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a
=A0 =A0 =A0 =A0 way to return a token when context establishment fails
Message-ID: <1373909621.23365.286.camel@minbar.fac.cs.cmu.edu>
Content-Type: text/plain; charset=3D"UTF-8"

On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote:

> My current proposal is to add a new method getOutputToken() to the
> GSSException class (which will be thrown when an error occurs) to retu= rn
> this last token. This means the method calls will be something like
This seems like an elegant solution to the problem.

-- Jeff


--047d7bf0c86c8918e804e1d6ae00-- From mayank@google.com Thu Jul 18 22:38:12 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86E11E8297 for ; Thu, 18 Jul 2013 22:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p854wENDdhp for ; Thu, 18 Jul 2013 22:38:11 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8FE11E8294 for ; Thu, 18 Jul 2013 22:38:11 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so3493195wev.8 for ; Thu, 18 Jul 2013 22:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=NUCnYRjIox+AGF55OuGqyAgoiARgPelndieCqLNSZRY=; b=TuPXFrRfKxMMu+957ruSdzXkRgQ06m4zrfEnoxzdklCy77JjzXsnbazCtBlrYkCviA 7lafcVrbzeTqH33JEDJKhFy3PxvYMYHRrx62umexujvUCbF39Qw2b8UqypON7DJMyuX1 Xc/qjqZKrLObRlpF10wnueFyh95/M68Wk+Ko6tzRu+eMzybyRtnUc5C+okhQlllB9nzk rB3Q9rQQv3xvNWH/WgDN9RmSbHetCSn7Ac4y74V8+zCVjAxskxaogSO3KOJUtr3NwjNM TbODN0n7tti+mb31/KvKm6W97SvYf05wHMR6Z6/Z4dIeaLR7it76Qo3PZDDh0sI1hHM7 2iag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=NUCnYRjIox+AGF55OuGqyAgoiARgPelndieCqLNSZRY=; b=cWSvWIlH2KdfFtXkpcMNo/psuErCIX9LND0TyR9iYCvHFB8VQREg9hcn1AZsnV4tl0 qyJkHvh7YukMK8eQD+csMkryPrjm1YhN0AMFn5UiY+GFDw+u/Z7IZzUsdyanseScQmWk xLj1eigMuhJPr//s75eox1VAVgNofrb5JnPaNgqQVdXfW6mhc+yS9KL0vOsxcVxHMR+K ugmc8g0eYCddIzqV1tXAsZRXf4/vMCTp2titTs+wqnVVPxtPoejWcO/Alluk22t7whvI cKH1W5+MYyrbeS9fDIMa2Kk8Vo+wNzMZCx4N111mAVQBb8rxSCK4mdvWOeFF0Wca/LVG LthA== X-Received: by 10.194.93.74 with SMTP id cs10mr11153641wjb.9.1374212290315; Thu, 18 Jul 2013 22:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.46.195 with HTTP; Thu, 18 Jul 2013 22:37:40 -0700 (PDT) From: Mayank Upadhyay Date: Thu, 18 Jul 2013 22:37:40 -0700 Message-ID: To: Jeffrey Hutzelman , Weijun Wang , kitten@ietf.org, OpenJDK Content-Type: multipart/alternative; boundary=047d7bf0c86c69204e04e1d6bb5e X-Gm-Message-State: ALoCoQkLEqqB9OI/Og1g624teYZ/TvO/ylsxL1irFm3Be26/WOUrgew13w5Wb20f/ZHlH7NgyQoTiQesrWy0MPHDt3xk4qDsaR/DPHv5K2phB1+wD0APFZvIW77VDWFHfL2niaXk5QHHTEUhw4ieghbm7oaqNh7/rDsiNQktsYFhM2BV/+lOmPqcFGywXTQmSfwkBa7eea/M Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:38:12 -0000 --047d7bf0c86c69204e04e1d6bb5e Content-Type: text/plain; charset=ISO-8859-1 (My apologies for resending, but with the right subject this time.) Hi Weijun, You point out a legitimate problem, but I want to understand a couple of assumptions: 1. Why allow only initSecContext() and acceptSecContext() to have this new behavior? Imagine a mechanism built on top of TLS which is renegotiating the session intermixed with actual payload, and had some error it wanted to communicate to the peer (e.g., a TLS Alert). Is there any particular reason you'd like to avoid that scenario? 2. I didn't quite follow the comment about the default method (maybe it shows that my Java is dated :). GSSException is not an interface but a concrete class, and adding a method to it adds it in the JRE starting at some particular version. What happens when applications that call the new method are run on an older JRE? 3. Don't we also need to set this token when the mechanism creates a GSSException instance? Note that the concrete class has no setter methods of any kind at this time, but two constructors. Thanks, Mayank ---------- Forwarded message ---------- From: Date: Mon, Jul 15, 2013 at 12:01 PM Message: 4 Date: Mon, 15 Jul 2013 11:58:47 +0800 From: Weijun Wang To: kitten@ietf.org, OpenJDK Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails Message-ID: <51E37377.1030704@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi All I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail is about a design flaw in the initSecContext and acceptSecContext methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2]. The GSSContext::initSecContext() method could either return a token (possibly null if no more token is needed) when the call succeeds or throw a GSSException if there is a failure, but not *both*. The same applies to acceptSecContext(). On the other hand, the C bindings of GSS-API has a chance to return both, and it does try to make use of both of them (according to RFC 2743 2.2.1 [3]): It is the caller's responsibility to establish a communications path to the target, and to transmit any returned output_token (independent of the accompanying returned major_status value) to the target over that path. Without the ability to send a token when there is a failure, a Java program has no chance to tell the other side what's happening. This is very user-unfriendly. Also, in the case of SPNEGO, a "reject" NegTokenResp token will never be able to sent out. My current proposal is to add a new method getOutputToken() to the GSSException class (which will be thrown when an error occurs) to return this last token. This means the method calls will be something like try { send(initSecContext(inToken)); } catch (GSSException e) { if (e.getOutputToken() != null) { send(e.getOutputToken()); } throw e; } The getOutputToken() method can only return a non-null value when it's thrown by an initSecContext or acceptSecContext call. The method won't throw another GSSException even if the exception was thrown in other calls. We can use the new JDK 8 default method feature [1] to add this new method to the existing GSSException interface. Thanks Weijun [1] http://tools.ietf.org/html/rfc5653#section-7.4.3[2] http://tools.ietf.org/html/rfc5653#section-7.4.9 [3] http://tools.ietf.org/html/rfc2743#page-46 [4] http://tools.ietf.org/html/rfc5653#section-7.4.5 ------------------------------ Message: 5 Date: Mon, 15 Jul 2013 13:33:41 -0400 From: Jeffrey Hutzelman To: Weijun Wang Cc: kitten@ietf.org, OpenJDK , jhutz@cmu.edu Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails Message-ID: <1373909621.23365.286.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote: > My current proposal is to add a new method getOutputToken() to the > GSSException class (which will be thrown when an error occurs) to return > this last token. This means the method calls will be something like This seems like an elegant solution to the problem. -- Jeff --047d7bf0c86c69204e04e1d6bb5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(My apologies for resending, but with the righ= t subject this time.)

Hi Weijun,

You point out a legitimate problem, but I want to understand a couple of as= sumptions:
=
  1. Why allow only initSecContext() and acce= ptSecContext() to have this new behavior? Imagine a mechanism built on top = of TLS which is renegotiating the session intermixed with actual payload, a= nd had some error it wanted to communicate to the peer (e.g., a TLS Alert).= Is there any particular reason you'd like to avoid that scenario?

  2. I didn't quite follow the comme= nt about the default method (maybe it shows that my Java is dated :). GSSEx= ception is not an interface but a concrete class, and adding a method to it= adds it in the JRE starting at some particular version.=A0What happens whe= n applications that call the new method are run on an older JRE?

  3. Don't we also need to set this = token when the mechanism creates a GSSException instance? Note that the con= crete class has no setter methods of any kind at this time, but two constru= ctors.
Thanks,
Mayank

---------- Forwarded message -----= -----
From:=A0<kitten-request@i= etf.org>
Date: Mon, Jul 15, 2013 at 12:01 PM

Message: 4
Date: Mon, 15 Jul = 2013 11:58:47 +0800
From: Weijun Wang <weijun.wang@oracle.com>
To:=A0kitten@ietf.org, OpenJD= K <se= curity-dev@openjdk.java.net>
Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way
= =A0 =A0 =A0 =A0 to return a token when context establishment fails
Messa= ge-ID: <51E37377.1030704@oracle.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Hi A= ll

I am Weijun Wang from the Java SE Seurity Team at Oracle, and thi= s mail
is about a design flaw in the initSecContext and acceptSecContext=
methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2]= .

The GSSContext::initSecContext() method could either return a toke= n
(possibly null if no more token is needed) when the call succeeds or throw a GSSException if there is a failure, but not *both*. The same
app= lies to acceptSecContext().

On the other hand, the C bindings of GSS= -API has a chance to return
both, and it does try to make use of both of= them (according to RFC 2743
2.2.1 [3]):

=A0 =A0 It is the caller's responsibility to establi= sh a communications path
=A0 =A0 to the target, and to transmit any retu= rned output_token (independent
=A0 =A0 of the accompanying returned majo= r_status value) to the target over
=A0 =A0 that path.

Without the ability to send a token when there is= a failure, a Java
program has no chance to tell the other side what'= ;s happening. This is
very user-unfriendly. Also, in the case of SPNEGO,= a "reject"
NegTokenResp token will never be able to sent out.

My current propos= al is to add a new method getOutputToken() to the
GSSException class (wh= ich will be thrown when an error occurs) to return
this last token. This= means the method calls will be something like

=A0 =A0 =A0 =A0 =A0try {
=A0 =A0 =A0 =A0 =A0 =A0 =A0send(initSecCont= ext(inToken));
=A0 =A0 =A0 =A0 =A0} catch (GSSException e) {
=A0 =A0 = =A0 =A0 =A0 =A0 =A0if (e.getOutputToken() !=3D null) {
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0send(e.getOutputToken());
=A0 =A0 =A0 =A0 =A0 =A0 =A0= }
=A0 =A0 =A0 =A0 =A0 =A0 =A0throw e;
=A0 =A0 =A0 =A0 =A0}

The getO= utputToken() method can only return a non-null value when it's
throw= n by an initSecContext or acceptSecContext call. The method won't
th= row another GSSException even if the exception was thrown in other calls.
We can use the new JDK 8 default method feature [1] to add this new
= method to the existing GSSException interface.

Thanks
Weijun
<= br>[1]=A0http://tools.ietf.org/html/rfc5653#section-7.4.3[2]
http://tools.ietf.org/html/rfc5653#section-7.4.9
[3]=A0http://to= ols.ietf.org/html/rfc2743#page-46
[4]=A0http://tools.ietf.org/html/rfc5653#section-7.4.5

------------------------------

Message: 5
Date: Mon, 15 Jul 2013= 13:33:41 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Weijun Wang <weijun.wang@oracle.com>
Cc:=A0<= a href=3D"mailto:kitten@ietf.org" target=3D"_blank">kitten@ietf.org, Op= enJDK <security-dev@openjdk.java.net>,
=A0 =A0 =A0 =A0=A0jhutz@= cmu.edu
Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API:= Provide a
=A0 =A0 =A0 =A0 way to return a token when context establishm= ent fails
Message-ID: <1373909621.23365.286.camel@minbar.f= ac.cs.cmu.edu>
Content-Type: text/plain; charset=3D"UTF-8"

On Mon, 2013-0= 7-15 at 11:58 +0800, Weijun Wang wrote:

> My current proposal is = to add a new method getOutputToken() to the
> GSSException class (whi= ch will be thrown when an error occurs) to return
> this last token. This means the method calls will be something like
This seems like an elegant solution to the problem.

-- Jeff
--047d7bf0c86c69204e04e1d6bb5e-- From nico@cryptonector.com Thu Jul 18 23:38:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3547E21F8E2A for ; Thu, 18 Jul 2013 23:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ2WNk5OKyhi for ; Thu, 18 Jul 2013 23:37:58 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD421F9D01 for ; Thu, 18 Jul 2013 23:37:55 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 3833D1F0084 for ; Thu, 18 Jul 2013 23:37:55 -0700 (PDT) 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=4zlOQGbaqCH4zQkcjbQN lk39Mz0=; b=xlAW5uqRvtl0z824qKJxEfKJaTMRbMc3vLVQRoZpscmhJ9tzU/Sf u6kbibdBY8AShjWxeqEiRa70Zbpn6ZjbcKN5tK4rzcCaSRQSTTXwOTl7DpRcdGkR J5flToj9FKkuBVjRQ/i6RbrmvEDHTsZDIxn1Mvyfn+jlUb8FJBVwRxc= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id D8B3D1F0081 for ; Thu, 18 Jul 2013 23:37:54 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so4005730wiv.15 for ; Thu, 18 Jul 2013 23:37:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o6iJl8jfDQTKWdqA8ajZAeUAjR/9PXRgadCVE/0BT54=; b=oJTb6Jn7Qf6roNM+ylyhGsOIAK7agLdqL+W81YJY6m7WxqWMX0nPfmMRA7lxzT9abW A2b4iV91E5GIzL1tpSGwJjaZiBKpXsqUY4vCDS8c6MhIiUWbum2om3BirMuwEdY3hlt9 2aJ4aEkb8GdKG59kh/2DinUfOhVIVOwGFDRoYT5AnhccvuIc2mw0hgWSoUEzJ0Ka/pe9 NOhaZ2RDeOnUaq6OWPmPiVtDW4vFs0nPTqFCCAxoq987QR9o3M9Jx0LxPZ5i1Rs1Tfwg 3aYRiRRmz/2ZEyC8M/kCOHkiHkBDj4JSqDR4hYrdTD8aHKNyDV0J37j9+573V15HJo3q Jm6w== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr11225672wjn.23.1374215873164; Thu, 18 Jul 2013 23:37:53 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 18 Jul 2013 23:37:52 -0700 (PDT) In-Reply-To: <51E37377.1030704@oracle.com> References: <51B1E355.2090301@oracle.com> <51E37377.1030704@oracle.com> Date: Fri, 19 Jul 2013 01:37:52 -0500 Message-ID: From: Nico Williams To: Weijun Wang Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, OpenJDK Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 06:38:03 -0000 On Sun, Jul 14, 2013 at 10:58 PM, Weijun Wang wrote: > Without the ability to send a token when there is a failure, a Java program > has no chance to tell the other side what's happening. This is very > user-unfriendly. Also, in the case of SPNEGO, a "reject" NegTokenResp token > will never be able to sent out. I agree. > My current proposal is to add a new method getOutputToken() to the > GSSException class (which will be thrown when an error occurs) to return > this last token. This means the method calls will be something like > > try { > send(initSecContext(inToken)); > } catch (GSSException e) { > if (e.getOutputToken() != null) { > send(e.getOutputToken()); > } > throw e; > } > > The getOutputToken() method can only return a non-null value when it's > thrown by an initSecContext or acceptSecContext call. The method won't throw > another GSSException even if the exception was thrown in other calls. I support this. > We can use the new JDK 8 default method feature [1] to add this new method > to the existing GSSException interface. Excellent, Nico -- From weijun.wang@oracle.com Thu Jul 18 23:48:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B734011E814F for ; Thu, 18 Jul 2013 23:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYj-GEwUgAlt for ; Thu, 18 Jul 2013 23:48:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2511E8135 for ; Thu, 18 Jul 2013 23:48:37 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6J6mWG8005595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jul 2013 06:48:33 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6J6mVor009333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 06:48:32 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6J6mVc4026794; Fri, 19 Jul 2013 06:48:31 GMT Received: from [10.191.4.247] (/10.191.4.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jul 2013 23:48:31 -0700 Message-ID: <51E8E131.3050105@oracle.com> Date: Fri, 19 Jul 2013 14:48:17 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mayank Upadhyay References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: kitten@ietf.org, OpenJDK , Jeffrey Hutzelman Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way to return a token when context establishment fails X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 06:48:42 -0000 Hi Mayank On 7/19/2013 1:37 PM, Mayank Upadhyay wrote: > (My apologies for resending, but with the right subject this time.) > > Hi Weijun, > > You point out a legitimate problem, but I want to understand a couple of > assumptions: > > 1. Why allow only initSecContext() and acceptSecContext() to have this > new behavior? Imagine a mechanism built on top of TLS which is > renegotiating the session intermixed with actual payload, and had > some error it wanted to communicate to the peer (e.g., a TLS Alert). > Is there any particular reason you'd like to avoid that scenario? No, there isn't. I just haven't expected any usage outside these 2 methods. In the final spec, I think I would write something like "If the underlying mechanism defines any error token to be sent to the peer, ....". > > 2. I didn't quite follow the comment about the default method (maybe it > shows that my Java is dated :). GSSException is not an interface but > a concrete class, and adding a method to it adds it in the JRE > starting at some particular version. What happens when applications > that call the new method are run on an older JRE? Oh, I was wrong. I thought everything in JGSS is an interface. We can just add the method there. If someone call the new method on an older JRE, a NoSuchMethodException is thrown. I had thought about creating a new ExtendedGSSException, but I really don't want to create ExtendedExtendedGSSException one day. > > 3. Don't we also need to set this token when the mechanism creates a > GSSException instance? Note that the concrete class has no setter > methods of any kind at this time, but two constructors. New constructors will be provided. Thanks Weijun > > Thanks, > Mayank > > ---------- Forwarded message ---------- > From: **> > Date: Mon, Jul 15, 2013 at 12:01 PM > > Message: 4 > Date: Mon, 15 Jul 2013 11:58:47 +0800 > From: Weijun Wang > > To: kitten@ietf.org , OpenJDK > > > Subject: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a way > to return a token when context establishment fails > Message-ID: <51E37377.1030704@oracle.com > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi All > > I am Weijun Wang from the Java SE Seurity Team at Oracle, and this mail > is about a design flaw in the initSecContext and acceptSecContext > methods of the GSSContext class defined in RFC 5653 7.4.3 [1] and 7.4.9 [2]. > > The GSSContext::initSecContext() method could either return a token > (possibly null if no more token is needed) when the call succeeds or > throw a GSSException if there is a failure, but not *both*. The same > applies to acceptSecContext(). > > On the other hand, the C bindings of GSS-API has a chance to return > both, and it does try to make use of both of them (according to RFC 2743 > 2.2.1 [3]): > > It is the caller's responsibility to establish a communications path > to the target, and to transmit any returned output_token (independent > of the accompanying returned major_status value) to the target over > that path. > > Without the ability to send a token when there is a failure, a Java > program has no chance to tell the other side what's happening. This is > very user-unfriendly. Also, in the case of SPNEGO, a "reject" > NegTokenResp token will never be able to sent out. > > My current proposal is to add a new method getOutputToken() to the > GSSException class (which will be thrown when an error occurs) to return > this last token. This means the method calls will be something like > > try { > send(initSecContext(inToken)); > } catch (GSSException e) { > if (e.getOutputToken() != null) { > send(e.getOutputToken()); > } > throw e; > } > > The getOutputToken() method can only return a non-null value when it's > thrown by an initSecContext or acceptSecContext call. The method won't > throw another GSSException even if the exception was thrown in other calls. > > We can use the new JDK 8 default method feature [1] to add this new > method to the existing GSSException interface. > > Thanks > Weijun > > [1] http://tools.ietf.org/html/rfc5653#section-7.4.3[2] > http://tools.ietf.org/html/rfc5653#section-7.4.9 > [3] http://tools.ietf.org/html/rfc2743#page-46 > [4] http://tools.ietf.org/html/rfc5653#section-7.4.5 > > > ------------------------------ > > Message: 5 > Date: Mon, 15 Jul 2013 13:33:41 -0400 > From: Jeffrey Hutzelman > > To: Weijun Wang > > Cc: kitten@ietf.org , OpenJDK > >, > jhutz@cmu.edu > Subject: Re: [kitten] Suggested update to RFC 5653 JGSS-API: Provide a > way to return a token when context establishment fails > Message-ID: <1373909621.23365.286.camel@minbar.fac.cs.cmu.edu > > > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2013-07-15 at 11:58 +0800, Weijun Wang wrote: > > > My current proposal is to add a new method getOutputToken() to the > > GSSException class (which will be thrown when an error occurs) to return > > this last token. This means the method calls will be something like > > This seems like an elegant solution to the problem. > > -- Jeff From kwburgi@tycho.ncsc.mil Fri Jul 19 08:23:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BA821E80CD for ; Fri, 19 Jul 2013 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puD27Uoyw8sq for ; Fri, 19 Jul 2013 08:23:50 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id DDCF021E80D4 for ; Fri, 19 Jul 2013 08:23:49 -0700 (PDT) X-TM-IMSS-Message-ID: <7abd0bdd00179e4d@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 7abd0bdd00179e4d ; Fri, 19 Jul 2013 11:23:01 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r6JFNjCX028630; Fri, 19 Jul 2013 11:23:45 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kelley Burgin In-Reply-To: Date: Fri, 19 Jul 2013 11:24:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> To: Sam Hartman X-Mailer: Apple Mail (2.1503) Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:23:55 -0000 I've put the draft at = http://www.cs.jhu.edu/~kburgin1/draft-burgin-kitten-aes-cbc-padding-hmac-s= ha2-00.txt Kelley On Jul 17, 2013, at 7:29 AM, Sam Hartman wrote: >>>>>> "Kelley" =3D=3D Kelley Burgin writes: >=20 > Kelley> I've gone through the effort of re-writing the draft using > Kelley> CBC mode with padding (being hopeful of its return - I'll = be > Kelley> on vacation for most of the next two weeks). I see however > Kelley> that it's past the submission deadline, so if anyone's > Kelley> interested in seeing the draft before the tool reopens, I'd > Kelley> be happy to send it to you (assuming this doesn't break any > Kelley> IETF rules). Kelley >=20 >=20 > Hi. > It would be great to make the text available to people, but not in the > form of a WG draft. >=20 > We're at a point in the process where the presumption is that we will > not make a given change unless consensus is demonstrated to make the > change. >=20 > I think most of us can guess what CBC would look like but having text > available would still be great. > Distributing to people is fine, putting on a web page is fine. >=20 > The question before the WG is whether to adopt Tom's proposal to = change > cipher modes as implemented in text by Kelley. > Just because editors of the draft are making the proposal does not = give > it special standing. >=20 > We'll need to make a consensus call on this after discussion in the > meeting and confirm on the list. >=20 >=20 > An alternative would be to post this as an individual draft > draft-author-kitten-kerberos-aes256-alternate-cbc or some such. > I've asked Stephen if he would grat an exception if you want to go = that > route. From simo@redhat.com Tue Jul 23 10:35:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB111E830B for ; Tue, 23 Jul 2013 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOUr9I5jG1hj for ; Tue, 23 Jul 2013 10:35:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3850E11E8302 for ; Tue, 23 Jul 2013 10:35:00 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6NHZ0Hc008428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 13:35:00 -0400 Received: from [10.3.113.18] ([10.3.113.18]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6NHYxaP004261; Tue, 23 Jul 2013 13:34:59 -0400 From: Simo Sorce To: Zhanna Tsitkov In-Reply-To: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Tue, 23 Jul 2013 13:34:59 -0400 Message-ID: <1374600899.18186.1.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "kitten@ietf.org" Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:35:09 -0000 On Tue, 2013-07-16 at 20:30 +0000, Zhanna Tsitkov wrote: > Couple comments on CAMMAC rev5 draft. > > 1. Verifier-MAC is defined as a sequence of an optional principal > name and required fields kvno, enctype and a checksum. It seems > that in some cases providing both kvno and enctype might be redundant > and even unnecessary. (For example, in some cases enctype can be > deduced from kvno, while svc-verifier may not need them at all.) So, > it might be a good idea to make either both these fields (kvno and > enctype) "optional", or, at least, mark enctype as an "optional" > field. I was going to object having them optional but after some out of band discussion I think it is fine to make enctype and kvno optional. > The following comments are mostly about text clarity: > > 2. In section 3 "Validation" the third paragraph starts with "The > following information is needed:" and then lists "The KDC MAC" , "The > Service MAC" etc. This text is followed by the statement "The KDC MAC > is required to allow KDC to validate …" The question that stays > unanswered is what is "The KDC MAC" , "The Service MAC"? What mac > they are of? > > 3. When giving details on AD-CAMMAC-BINDING (section 4.1) at the end > of the paragraph one mentions S4U2proxy scenario. It might be a good > idea to move this text closer to the Introduction or, even, have a > separate "Use Cases" section for potential use of AD-CAMMAC. > > 4. . In "Security Consideration" section the text "protected by the > existing encryption methods on the ticket" implies that there are > multiple enc methods on one ticket. Something simple like > "encryption method on the ticket" or similar would do a job. Thanks, these suggestions to clarify the text are welcome. Simo. -- Simo Sorce * Red Hat, Inc * New York