[18821] in Kerberos_V5_Development
Re: [kitten] Token Preauth for Kerberos
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Wed Jun 11 11:02:01 2014
Message-ID: <1402498324.2955.2.camel@ipa.example.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: "Zheng, Kai" <kai.zheng@intel.com>
Date: Wed, 11 Jun 2014 10:52:04 -0400
In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118D8E14@SHSMSX103.ccr.corp.intel.com>
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
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
