Re: [kitten] Token Preauth for Kerberos

"Zheng, Kai" <kai.zheng@intel.com> Tue, 08 July 2014 12:10 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 67A221A03B0 for <kitten@ietfa.amsl.com>; Tue, 8 Jul 2014 05:10:39 -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 Xhgh5eYcBdao for <kitten@ietfa.amsl.com>; Tue, 8 Jul 2014 05:10:36 -0700 (PDT)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7A11B2AC9 for <kitten@ietf.org>; Tue, 8 Jul 2014 05:10:36 -0700 (PDT)
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 08 Jul 2014 05:10:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="566691484"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by fmsmga002.fm.intel.com with ESMTP; 08 Jul 2014 05:10:09 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 05:10:08 -0700
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 05:10:09 -0700
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.122]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 20:10:00 +0800
From: "Zheng, Kai" <kai.zheng@intel.com>
To: Simo Sorce <simo@redhat.com>
Thread-Topic: [kitten] Token Preauth for Kerberos
Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAACyy6gADKjG2g///1jYD/3rPSIA==
Date: Tue, 08 Jul 2014 12:10:00 +0000
Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FB475@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>
In-Reply-To: <1403009009.22737.129.camel@willson.usersys.redhat.com>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dSXJO7-JZK93-lfsJ_EimUNTuuA
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: Tue, 08 Jul 2014 12:10:39 -0000

Hi Simo,

I apologize for the very late response. 

>> I think AD data can be added with s4u2self/s4u2proxy as well, what other modifications do you have in mind ?
Yes I agree. Adding AD data like AD_TOKEN won't be an issue if we could enhance S4U to support token adding something like PA_S4U_TOKEN 
in lieu with PA_FOR_USER and PA_S4U_X509_USER. :)
I might be just repeating what I have said already, why I would prefer to do it in pre-authentication framework:
1. Token can be used in AS-REQ/AS-REP exchange via token-preauth mechanism to acquire a TGT, making kinit tool support that is easy.
S4U works in TGS-REQ/TGS-REP exchange to acquire service ticket, which involves corresponding GSSAPI support for applications to make use of it. 
2. In token-preauth approach, we can also achieve the effect of S4U in some degree. Web server accepting token submitted by browser page form,
doing Kerberos login stuff via token-preauth, then performing GSSAPI/SASL negotiation with backend service, works great.

>> Do you have a standardized AD element in mind, or are you going to define a new one ?
How about having a new one like AD-TOKEN that contains the token derivation. It can encapsulated into AD-KDC-ISSUED, with checksum. The thinking
would be, KDC validates incoming token and determines to issue ticket, by escaping any encryption/signature layers of the token, gets the token derivation,
and put it into the issued ticket. As such it's natural to wrap the new AD data into AD-KDC-ISSUED.

Thanks for thinking about this. 

Regards,
Kai


-----Original Message-----
From: Simo Sorce [mailto:simo@redhat.com] 
Sent: Tuesday, June 17, 2014 8:43 PM
To: Zheng, Kai
Cc: kitten@ietf.org; krbdev@mit.edu
Subject: Re: [kitten] Token Preauth for Kerberos

On Tue, 2014-06-17 at 05:35 +0000, Zheng, Kai wrote:
> >> You need to modify something anyway, constrained delegation sound
> like a better way than trying to devise a whole new pre-auth plugin.
> As far as I know s4u2self & s4u2proxy plus contrained delegation are 
> from MS and I'm not sure we could modify it as we need. A new 
> token-preauth based on existing Kerberos and framework is more 
> preferred for us since the plugin is easy to deploy, also we believe 
> the mechanism using JWT token will open the door to integrate Kerberos 
> with OAuth.

I think AD data can be added with s4u2self/s4u2proxy as well, what other modifications do you have in mind ?

> >>However you should only transmit the authorization data, not the
> whole token, otherwise you destroy every single security property of 
> Kerberos.
> >>I can't see any krb admin as accepting something like that.
> Yes I agree. As discussed with Greg and also said here in my previous 
> email, we will not pass the token itself to service, instead token 
> attributes or the derivation that can't be used to authenticate with 
> KDC.

Do you have a standardized AD element in mind, or are you going to define a new one ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York