[18829] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Automatic FAST via Anonymous PKINIT

daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jun 11 14:22:21 2014

Message-ID: <53989E53.4000807@mit.edu>
Date: Wed, 11 Jun 2014 14:22:11 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Nathaniel McCallum <npmccallum@redhat.com>
In-Reply-To: <1402509832.2955.23.camel@ipa.example.com>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On 06/11/2014 02:03 PM, Nathaniel McCallum wrote:
> Are you suggesting that PKINIT shouldn't be offered even when anonymous
> PKINIT is supported?

Yes.  The method-data in a preauth-required error is a list of
mechanisms the client can use to authenticate as that principal, not a
general summary of KDC capabilities.

> Put otherwise, that the client should try anonymous PKINIT even when not offered it?

If the client knows it needs FAST and doesn't have another way of
producing an armor ticket, yes.  An assertion that the KDC supports
PKINIT isn't really interesting because it doesn't imply that the KDC
supports anonymous.

If we decide that we need a more explicit way for the KDC to say "I
would offer you additional mechanisms if you used FAST and I support
anonymous PKINIT" then we could define an informational padata type for
that.  But its meaning should be be orthogonal to PKINIT being offered
as a mechanism for authenticating as the client principal.
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post