Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04

Benjamin Kaduk <kaduk@mit.edu> Thu, 05 January 2017 19:47 UTC

Return-Path: <kaduk@mit.edu>
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 444CB129654; Thu, 5 Jan 2017 11:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.301
X-Spam-Level:
X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 1ziZHGatVHtu; Thu, 5 Jan 2017 11:47:36 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 67443129653; Thu, 5 Jan 2017 11:47:36 -0800 (PST)
X-AuditID: 12074425-80fff70000001995-49-586ea2d7c2d9
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 61.0C.06549.7D2AE685; Thu, 5 Jan 2017 14:47:35 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v05JlX8R011228; Thu, 5 Jan 2017 14:47:34 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v05JlTRQ027616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jan 2017 14:47:31 -0500
Date: Thu, 5 Jan 2017 13:47:29 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christian Huitema <huitema@huitema.net>
Message-ID: <20170105194728.GU8460@kduck.kaduk.org>
References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org> <00c901d26766$566e9ae0$034bd0a0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00c901d26766$566e9ae0$034bd0a0$@huitema.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hTV1r2+KC/C4OUtPou5Lb9ZLCY3zma3 mPFnIrPF0c2rWCwmvLnNajH36yxWiw8LH7I4sHvcmnGKxWPJkp9MHu/3XWULYI7isklJzcks Sy3St0vgylje9Yyx4I17xZfnz1gbGPutuhg5OCQETCS6N2V1MXJxCAm0MUl8+T+DFcLZwCjx +fw0JgjnCpPEoy+n2boYOTlYBFQk5h3byw5iswHZDd2XmUFsEQFtiTWz74E1MAvsZpT4s38x E0hCWMBP4vX1yywgNq+AscThlsuMEFMPM0q8OPOQGSIhKHFy5hOwImYBLYkb/14ygdzHLCAt sfwfB0iYU8BK4sCfF6wgtqiAskTDjAfMExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJ usXJiXl5qUW6Fnq5mSV6qSmlmxhBQc7uorqDcc5fr0OMAhyMSjy8EV55EUKsiWXFlbmHGCU5 mJREeVNnAIX4kvJTKjMSizPii0pzUosPMUpwMCuJ8K6bB5TjTUmsrEotyodJSXOwKInzXsp0 jxASSE8sSc1OTS1ILYLJynBwKEnwci8EahQsSk1PrUjLzClBSDNxcIIM5wEaXgFSw1tckJhb nJkOkT/FqCglzlu5ACghAJLIKM2D6wUlIYns/TWvGMWBXhHm/QLSzgNMYHDdr4AGMwEN3h6Q DTK4JBEhJdXAWLu2W4M7yYXbpCTqTvMWsQ+bkuS3dvkWXXLl/WXqPSNuWw773RmnxUo2CU/k u/gzedM9V2PXtxcmmHyuLvFjXDzB05rha7e1/wTBpe/2pEwRLj0ZUb/L1Tog/mhuiuLXW8pT fu2NVD301OW8Q+N6nXQmvX/1+t967qmm9L37G7Rn9fGDnBMilViKMxINtZiLihMBVU0XNB0D AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ovLABKuq8dzH4-rmyesdnP9Nljo>
Cc: 'secdir' <secdir@ietf.org>, nkinder@redhat.com, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, npmccallum@redhat.com, kitten@ietf.org, 'IESG' <iesg@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 19:47:39 -0000

On Thu, Jan 05, 2017 at 07:13:55AM -0800, Christian Huitema wrote:
> 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.

Thanks for finding the new document -- I was going to send you a pointer
today to confirm that it addressed your concerns, but you beat me to it.

> 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"?

I don't think so, but will loop in the WG to confirm.
The ad-type should indicate what is immediately inside the next encoding
layer of the ad-data.  So a Ticket might have an AuthorizationData that
contains ad-type 1 (AD-IF-RELEVANT), that itself contains AuthorizationData
with ad-type 96 (AD-CAMMAC), that in turn contains AuthorizationData with
ad-type 97 (AD-AUTHENTICATION-INDICATOR).  So, 97 should appear only at
the lowest level, and correspond to ad-data that's just the
AD-AUTHENTICATION-INDICATOR itself.

But thanks again for double-checking!

-Ben

> 
> 
> 
> -----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>rg>; 'secdir' <secdir@ietf.org>rg>;
> 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>rg>; 'secdir' <secdir@ietf.org>rg>;
> > 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
>