Re: [kitten] Token Preauth for Kerberos

"Zheng, Kai" <kai.zheng@intel.com> Wed, 09 July 2014 21:01 UTC

Return-Path: <kai.zheng@intel.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 D90981B27A9 for <kitten@ietfa.amsl.com>; Wed, 9 Jul 2014 14:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level:
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 6EHtwTV2aPPG for <kitten@ietfa.amsl.com>; Wed, 9 Jul 2014 14:01:37 -0700 (PDT)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF51B27A0 for <kitten@ietf.org>; Wed, 9 Jul 2014 14:01:37 -0700 (PDT)
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Jul 2014 14:01:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.01,633,1400050800"; d="scan'208";a="570796095"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54]) by orsmga002.jf.intel.com with ESMTP; 09 Jul 2014 14:01:32 -0700
Received: from fmsmsx120.amr.corp.intel.com (10.19.9.29) by FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 14:01:31 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx120.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 14:01:32 -0700
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by shsmsx102.ccr.corp.intel.com ([169.254.2.21]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 05:01:30 +0800
From: "Zheng, Kai" <kai.zheng@intel.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Thread-Topic: [kitten] Token Preauth for Kerberos
Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAACyy6gADKjG2g///1jYD/3rPSIIBCjV+A//7iu7CAAom9AP//DGOg
Date: Wed, 09 Jul 2014 21:01:30 +0000
Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FBFFA@SHSMSX103.ccr.corp.intel.com>
References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> <1403009009.22737.129.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> <53BC1D53.6040106@mit.edu> <8D5F7E3237B3ED47B84CF187BB17B666118FB9DE@SHSMSX103.ccr.corp.intel.com> <alpine.GSO.1.10.1407091016260.21571@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1407091016260.21571@multics.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2EgmHDjHo59NO_vOIJZq4Zt6RN8
Cc: "kitten@ietf.org" <kitten@ietf.org>, "krbdev@mit.edu" <krbdev@MIT.EDU>
Subject: Re: [kitten] Token Preauth for Kerberos
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: Wed, 09 Jul 2014 21:01:39 -0000

Hi Ben,

> AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data type, but rather that the JWT token therein could contain any sort of information about the user making the request ...

Yes I agree. Thanks for clarifying. I'm thinking of AD-TOKEN as AD-WIN2K-PAC. The difference is AD-TOKEN contained token is from 3rd party token authority and can contain anything like you 
mentioned, and the layout of AD-WIN2K-PAC is well defined by MS-PAC. Also IMO, having a subcontainer like AD-TOKEN for token-preauth mechanism could allow some flexibility for 
future extensions. 

What would you suggest regarding this or any other aspects for the proposed mechanism? Thanks.

Regards,
Kai

-----Original Message-----
From: Benjamin Kaduk [mailto:kaduk@MIT.EDU] 
Sent: Wednesday, July 09, 2014 10:18 PM
To: Zheng, Kai
Cc: kitten@ietf.org; krbdev@mit.edu
Subject: Re: [kitten] Token Preauth for Kerberos

On Tue, 8 Jul 2014, Zheng, Kai wrote:

> Hi Creg,
>
>> this sounds like creating a container-of-anything within an existing container-of-anything.  That is, if you see something within an AD-TOKEN subcontainer, you don't know anything about what it is, only something about where it came from and how it is encoded.
>
> Hmmm, not exactly as what I mean. It's container-of-exactly-token 
> within the existing container-of-anything (AD-KDC-ISSUED). Looking at 
> AD-TOKEN subcontainer, applications are meant to get a token from it, 
> as AD-TOKEN could be defined as:

AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data type, but rather that the JWT token therein could contain any sort of information about the user making the request, restrictions placed on the token, and so on.  (Almost) any sort of information could be in the AD-TOKEN, even if only a single data type is permitted.

-Ben