Re: [kitten] [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: 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 E660512948A for <kitten@ietfa.amsl.com>; Thu, 5 Jan 2017 12:18:51 -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 2mdwn18orqKk for <kitten@ietfa.amsl.com>; Thu, 5 Jan 2017 12:18:50 -0800 (PST)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 CB51D1293EB for <kitten@ietf.org>; Thu, 5 Jan 2017 12:18:50 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cPEUq-0005rm-SX for kitten@ietf.org; Thu, 05 Jan 2017 21:18:50 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cPEUp-0005KE-6V for kitten@ietf.org; Thu, 05 Jan 2017 15:18:48 -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, 05 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.223
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 Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqRU0WDTzT2VA4QSJJCiEdMRcOb18WfxGyg6Om6u4YYm8Ex7JmehmyvzkXA 1zAmRsc5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKRQRCdMNhge1Unb77YyuZq46nmCFK02cH99LuT/CgH0hRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqS3AA1zi4L4OJ0M18xnuBW/6 592ULW4vfh/b1HrXegYtEnYI0EWZRGihOmWEw9sJYqlGM+xDguDxJnnDh3alUJG6elFFgxvixKHD +ndZqoQq0JFb5sY5yvsuaKnQYvhP+274nM+117vLjWiTA8zC3e5qTjAEzQR26Rr0dPOgWImrjs9/ BX0barm2Y4IT1WcBZEH9asyhHPHrk1fOl/Hbtww=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/78Qb85OUH4-vc29DN1YjLafzxcA>
Cc: 'secdir' <secdir@ietf.org>, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, kitten@ietf.org, 'IESG' <iesg@ietf.org>
Subject: Re: [kitten] [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 20:18:52 -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