Re: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02

Nico Williams <nico@cryptonector.com> Tue, 10 June 2014 04:03 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939061A0398 for <kitten@ietfa.amsl.com>; Mon, 9 Jun 2014 21:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 IhBdBVAiwagF for <kitten@ietfa.amsl.com>; Mon, 9 Jun 2014 21:03:51 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAA1A0396 for <kitten@ietf.org>; Mon, 9 Jun 2014 21:03:51 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id AFB5231805D for <kitten@ietf.org>; Mon, 9 Jun 2014 21:03:51 -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=4uRjefeH8oH5FgzDPDHQ hjo1K/8=; b=rUiQXHntrF5Xr1z22h58qijPZkzr6lFx+LvUXH0T742g/X+Airfc DPuCrQP/4oYKnghWb1QrElTQmSs/LyjdyKyNyKBrP/PydcQAzN92e8j4SONBjzj8 e5DQxD/QW+dyBeV+TkWkHkKgExQZr8SDxBmnPWYbQgItpjcX51GrLGE=
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-a89.g.dreamhost.com (Postfix) with ESMTPSA id 621BC318059 for <kitten@ietf.org>; Mon, 9 Jun 2014 21:03:51 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f8so5331297wiw.16 for <kitten@ietf.org>; Mon, 09 Jun 2014 21:03:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.195.11.132 with SMTP id ei4mr263479wjd.95.1402373030223; Mon, 09 Jun 2014 21:03:50 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 9 Jun 2014 21:03:50 -0700 (PDT)
In-Reply-To: <53967E76.8050200@mit.edu>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> <CAK3OfOi1RWQuzN=RN8Ej5Z6hf33h_z-eaUXqJg6O_FwwiTdotA@mail.gmail.com> <53967E76.8050200@mit.edu>
Date: Mon, 09 Jun 2014 23:03:50 -0500
Message-ID: <CAK3OfOiSjPuL3z2iZmfmFXkx98UEk1VL44oj5zEOj9Jc-J1ycw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Hu53ccU5srNMyIGIh2fFIE7baHk
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Jun 2014 04:03:52 -0000

On Mon, Jun 9, 2014 at 10:41 PM, Greg Hudson <ghudson@mit.edu> wrote:
> On 06/09/2014 10:45 PM, Nico Williams wrote:
>> As I wrote the I-D you'd use an AS exchange, but I do believe a TGS
>> would be better, if only because it'd be weird to have an AS-REP issue
>> a non-INITIAL ticket or a ticket with non-empty transit path, or a
>> ticket for client and service principals with different realms.
>
> The TGS-REQ path is already too complicated.  The KDC already has to
> deal with at least five cases:
> ...
>
> Cases 4 and 5 aren't the IETF's doing, of course, but that doesn't mean
> we can reasonably avoid supporting them.  I'd probably rather add a
> third type of KDC request than add a sixth variant of TGS which uses the
> AS-REQ preauth machinery and doesn't use a header ticket.  (An AS-REQ
> variant might still be a reasonable option; I haven't reviewed the draft
> in enough detail to have a strong opinion about that.)

I find adding a new request type that will differ mostly only as to
the application tag and pre-auth choice a bit silly.  There's a cost
to it too: dissectors for things like Wireshark and Netmon won't know
about the new requests, even though the new request will be so like
the old.

The main reason to separate these at all is for separation of
services, which for Kerberos is really mostly about class of service /
load balancing -- give higher priority to TGS requests than to PKINIT.
TGS requests are usually fast: it's all symmetric key crypto, while
PKINIT AS requests are slower due to the PK crypto.

At a high-level we have:

 - has PA-TGS -> TGS
 - has x-realm PKINIT -> new thing
 - anything else -> AS

Separation of service should have been done by using [optionally]
different port numbers, not different tag numbers.

Thinking of it this way this, I'd rather use AS for this and not a new
request type, due a) to the fact that we already have slow AS
requests, but not slow TGS requests, b) AS req

Nico
--