[18829] in Kerberos_V5_Development
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