Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
"Christian Huitema" <huitema@huitema.net> Thu, 05 January 2017 15:14 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4D129B51 for <secdir@ietfa.amsl.com>; Thu, 5 Jan 2017 07:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOfC7hfIY4ng for <secdir@ietfa.amsl.com>; Thu, 5 Jan 2017 07:14:13 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A68129B4A for <secdir@ietf.org>; Thu, 5 Jan 2017 07:14:12 -0800 (PST)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cP9k1-00058B-Up for secdir@ietf.org; Thu, 05 Jan 2017 16:14:11 +0100
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cP9jv-0008BW-62 for secdir@ietf.org; Thu, 05 Jan 2017 10:14:08 -0500
Received: (qmail 21929 invoked from network); 5 Jan 2017 15:14:02 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.38.210]) (envelope-sender <huitema@huitema.net>) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-kitten-krb-auth-indicator.all@ietf.org>; 5 Jan 2017 15:14:00 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Benjamin Kaduk' <kaduk@mit.edu>
References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org>
In-Reply-To: <20170103062001.GN8460@kduck.kaduk.org>
Date: Thu, 05 Jan 2017 07:13:55 -0800
Message-ID: <00c901d26766$566e9ae0$034bd0a0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQEaPs7iLwqOaTNknblhLQFEtN95CQJSROSwAhA+0NaidzjJMA==
X-Originating-IP: 168.144.250.245
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.05)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoA6Y1VfyGGMltVgOLwMgmmRcOb18WfxGyg6Om6u4YYm3WJW+kg3QAx4RnO qbcEsZE5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qhQRCdMNhge1Unb77YyuZq41nA42b0gFbNywN+yolirFRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqYh2OsKXXkoVR3vRgp+PhUTh 7upESYb585WZ0BSQoLJUjOCcLUUG/UOs31dB7P9JEwxIEpbinxK0oowxQTVJtR37NlKfHadlY9VB h5JyIzzQ/I1dpLTifeoHWo0A7trCgivvMbIIty1BrdRX3euPU+v6hYCF0D67O+iDK8Lnv/b7J/X5 GQwKZQYRThYbfgBJgSejWzj+l6oKAXkmxo75jgs=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SOrxGsJvvzo6mo1zgCZzT8khyVY>
Cc: npmccallum@redhat.com, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, nkinder@redhat.com, 'IESG' <iesg@ietf.org>, 'secdir' <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 15:14:15 -0000
Thanks for the corrections. I checked the new draft version, draft-ietf-kitten-krb-auth-indicator-06, and the changes address my concern. The new section "4. Assigned Numbers" provides a clear update to RFC 4120, and the added paragraph in the security section addresses cross-realm indicator collisions. One point, though. The new section 4 states: o The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR". Should that not be "DER encoding of AD-AUTHENTICATION-INDICATOR wrapped in a CANMAC container"? -- Christian Huitema -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu] Sent: Monday, January 2, 2017 10:20 PM To: Christian Huitema <huitema@huitema.net> Cc: 'IESG' <iesg@ietf.org>; 'secdir' <secdir@ietf.org>; draft-ietf-kitten-krb-auth-indicator.all@ietf.org; nkinder@redhat.com; npmccallum@redhat.com Subject: Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 Hi Christian, Thanks for the review! On Sat, Dec 31, 2016 at 06:39:21PM -0800, Christian Huitema wrote: > Copying to Nathan Kinder and Nathaniel McCallum, since their mail server > rejects messages relayed by the IETF server. > > -----Original Message----- > From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Christian Huitema > Sent: Saturday, December 31, 2016 6:20 PM > To: 'IESG' <iesg@ietf.org>; 'secdir' <secdir@ietf.org>; > draft-ietf-kitten-krb-auth-indicator.all@ietf.org > Subject: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 > [...] > The document is almost ready, by I wish a few issues were addressed before > publication. > > My first issue is that the document describes an update to the Kerberos > protocol specification, RFC 4120, but does not define the specific way in > which RFC 4120 is updated. Could the draft be updated to include something > like the section "6. Assigned Numbers" of RFC 7751? If I understand > correctly, the changes are a new ad-type number 97, pointing to a CAMMAC > container, in which the "elements" are encoded according to the syntax > specified in Appendix A of the draft. Having that explained succinctly would > help future readers. I noticed the "Updates but doesn't really update" issue while preparing the shepherd review, and opted to leave in the "Updates" marker since it's probably something an implementor of 4120 should know about. The "Assigned Numbers" section is a good idea, thanks for pointing it out (and yes, you understand correctly). Authors, can you prepare another update? > My second issue is with the use of site-defined strings. I understand that > the site defined strings are defined by the administrator of a realm. What > happens if these strings appear outside the original realm, for example in > an environment connecting multiple realms? Don't we have a potential there > for name collision? Should there not be some guidance to implementers? There is maybe some potential for confusion, though not, I think, at the protocol level. The authentication indicator should always originate from the realm of orignial authentication, which is the realm of the client principal (in general). Even with some of the more exotic flows, like anonymous (or semi-anonymous) principals and making cross-realm TGS requests for foreign-realm TGTs, the client principal's realm is unchanged, so at a protocol level, the meaning of "this realm asserts that this authentication mechanism was used" remains clear. The confusion is when applications just check strings against a table without special-casing foreign-realm principals (which is likely to happen and the natural thing for application authors to do; I am not trying to belittle the issue you raised). In many cases, cross-realm operations occur when the administrators of the different realms are tightly coordinated (or even the same group), in which case they probably use the same semantics for the authentication indicator. In cases where the administrators of the different realms are genuinely different organizations, there are already risks for application services in such realms, such as for applications that grant access to "valid user". That said, the authentication indicator does introduce a new type of risk, and it is appropriate to have some text about it in the security considerations. Authors, do you think you can come up with text, or should one of us try to make a contribution? > I note that the proposed short string syntax forbids use of the ":" > character in site-defined strings. Did the WG look at the consequences of > that choice? If site administrators cannot use the URI like syntax, what is > the preferred way of defining unique strings and preventing collisions? I don't think the WG looked at the consequences, no -- IIRC this requirement was introduced at my urging due to the shepherd review, in order to avoid conflict between the two classes of possible values. If URIs must be LoA profiles and site-local values must be not-URIs, then there is no conflict. My expectation is that what will happen in practice is that the site-local short strings will actually be implementation-local, and the name of the preauthentication plugin or module will be used, like "otp" or "pkinit" or "spake". I don't expect anyone to try to make globally unique values, but of course there are always options like UUIDs or using alternate separator characters for those who wish to try. (It is debatable whether UUIDs count as "short", but there is no enforcement on "short", so they are in practice fair game.) > What are application services supposed to do when they encounter URI or > site-defined strings that they do not understand? The same thing they do now (in practice) when receiving other unknown authorization data types: ignore it. (This is in violation of the spec, that says unknown types should be treated as critical unless wrapped in AD-IF-RELEVANT, but that behavior is not implemented in the major implementations.) That may end up being a default-deny or default-permit mode, depending on the application service's configuration. > The ASN.1 syntax defines the element as a "SEQUENCE OF UTF8String". The > document mentions that "Each UTF8String value is a short string". How short > exactly should these strings be? How many of them should an application > expect in the "SEQUENCE OF" element? The syntax itself does not constrain > the length or number of these strings. Are we not worried with potential > interoperability issues? Could this be abused in some attacks? Should the > security considerations mention that? If I remember the history of the document correctly, there is intentionally no limit. URIs for LoA profiles could end up being pretty long, and there was a desire to not artificially limit those; it doesn't seem worth complicating the semantics of the indicator just to impose a length restriction on the non-URI strings. As far as the number of elements in the sequence, in practice there is probably no issue, since the authentication indicator is issued by the KDC in response to the actual authentication that occurred -- well-behaved KDCs should only include as many strings as authentication methods were used (which is in practice one or two at the moment, and probably not going to get much above three ever). There is always the concern about a client parsing untrusted/unvalidated input, but the consumer should be validating the MAC(s) in the CAMMAC container before parsing, and the implementation ticket size (and similar) constraints will also limit the possible size here. So, probably no attacks (absent compromised KDCs, which have other ways to wreak havoc) and probably no need for security consideration mention. I can't come up with any potential interoperability issues, either, but I didn't spend a whole lot of time thinking about it. Thanks again, Ben
- [secdir] SECDIR review of draft-ietf-kitten-krb-a… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Benjamin Kaduk
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Benjamin Kaduk
- Re: [secdir] [kitten] SECDIR review of draft-ietf… Greg Hudson
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Nathaniel McCallum
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema