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

"Christian Huitema" <huitema@huitema.net> Thu, 05 January 2017 20:18 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 E0FB4129609 for <secdir@ietfa.amsl.com>; Thu, 5 Jan 2017 12:18:55 -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=unavailable 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 dOA2Z2FTXpN2 for <secdir@ietfa.amsl.com>; Thu, 5 Jan 2017 12:18:55 -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 07EDE129606 for <secdir@ietf.org>; Thu, 5 Jan 2017 12:18:55 -0800 (PST)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cPEUv-0002oG-5U for secdir@ietf.org; Thu, 05 Jan 2017 21:18:53 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cPEUp-0002I4-6a for secdir@ietf.org; Thu, 05 Jan 2017 15:18:51 -0500
Received: (qmail 28148 invoked from network); 5 Jan 2017 20:18:46 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.38.210]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-kitten-krb-auth-indicator.all@ietf.org>; 5 Jan 2017 20:18:46 -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> <00c901d26766$566e9ae0$034bd0a0$@huitema.net> <20170105194728.GU8460@kduck.kaduk.org>
In-Reply-To: <20170105194728.GU8460@kduck.kaduk.org>
Date: Thu, 5 Jan 2017 12:18:40 -0800
Message-ID: <042f01d26790$e936a5f0$bba3f1d0$@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+0NYCGZkF0AHkJ1kioledNuA=
X-Originating-IP: 168.144.250.177
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.03)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXp3+eDq3ngOgAQn1xwUS0XtRcOb18WfxGyg6Om6u4YYm8Ex7JmehmyvzkXA 1zAmRsc5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQxQRCdMNhge1Unb77YyuZq76lAzddpUcwS9Qm3gS0C5jRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqYh2OsKXXkoVR3vRgp+PhUTh 7upESYb585WZ0BSQoLJUc3YD8Cz3MOYLfFCW0hRKKw246snhpY0AHiBL6U5bHxz7NlKfHadlY9VB 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/1OLPjdae7CoguaZHQAKgm-cqlUc>
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 20:18:56 -0000

On Thursday, January 5, 2017 11:47 AM, Benjamin Kaduk wrote:
>
> 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.

Blame Tero Kivinen. He sent me a reminder this morning.

>> 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
>> CAMMAC 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.

OK, I get that now. It was not entirely obvious from reading the text.

What is supposed to happen if the outside Authorization Data type is set to
97 instead of 96? Should that be specified somewhere? The text says:

   Authorization data elements of type AD-AUTHENTICATION-INDICATOR MUST
   be included in an AD-CAMMAC container so that their contents can be
   verified as originating from the KDC.

That's a fine constraint for the sender, but what about receivers?

-- Christian Huitema