[18858] in Kerberos_V5_Development
RE: [kitten] Token Preauth for Kerberos
daemon@ATHENA.MIT.EDU (Zheng, Kai)
Fri Jun 13 04:08:40 2014
From: "Zheng, Kai" <kai.zheng@intel.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Date: Fri, 13 Jun 2014 08:07:50 +0000
Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118ED099@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <1402498324.2955.2.camel@ipa.example.com>
Content-Language: en-US
MIME-Version: 1.0
Cc: "kitten@ietf.org" <kitten@ietf.org>,
"Jiang,
Weihua" <weihua.jiang@intel.com>,
"krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Nathaniel,
Yes I like the idea and hopefully token-preauth mechanism can benefit from it. Thanks.
Regards,
Kai
-----Original Message-----
From: Nathaniel McCallum [mailto:npmccallum@redhat.com]
Sent: Wednesday, June 11, 2014 10:52 PM
To: Zheng, Kai
Cc: Greg Hudson; kitten@ietf.org; krbdev@mit.edu; Jiang, Weihua
Subject: Re: [kitten] Token Preauth for Kerberos
On Wed, 2014-06-11 at 08:15 +0000, Zheng, Kai wrote:
> Hi Greg,
>
> Thanks for your valuable feedback and suggestions!
>
> 1. Yes you're right I'm taking the OTP approach and use the FAST armor
> key as the reply key. As mentioned in the proposal we suggest PKINIT
> be deployed along with this mechanism, And client uses PKINIT
> anonymous to obtain the armor ticket. It doesn't provide mutual authentication since only KDC is authenticated to client with the configured certificate of KDC and client doesn't due to lacking of certificate as to avoid the deployment overhead in our solution. So protecting the token here in AS-REQ exchange mainly depends on the FAST tunnel and client should be careful about the armor ticket.
You may be interested in this proposal:
http://mailman.mit.edu/pipermail/krbdev/2014-May/011958.html
Nathaniel
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
