[18828] in Kerberos_V5_Development
Re: Automatic FAST via Anonymous PKINIT
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Wed Jun 11 14:04:10 2014
Message-ID: <1402509832.2955.23.camel@ipa.example.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Date: Wed, 11 Jun 2014 14:03:52 -0400
In-Reply-To: <53989764.1020302@mit.edu>
Mime-Version: 1.0
Cc: 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 13:52 -0400, Greg Hudson wrote:
> On 06/11/2014 11:36 AM, Nathaniel McCallum wrote:
> > Further thought has, I think, recognized a further problem with this
> > proposal. State attribute #3 needs to be clarified as: "No known preauth
> > mechs are offered except anonymous-only PKINIT."
> [...]
> > The easiest solution to me seems to be the creation of a new padata id
> > which implies that the PKINIT is anonymous-only PKINIT.
>
> See also our IRC conversation here:
> http://colabti.org/irclogger/irclogger_log/krbdev?date=2014-05-16#l55
>
> If the KDC knows that the principal cannot authenticate using PKINIT, I
> don't think it should offer PKINIT at all. Right now, the MIT KDC
> doesn't know what principals have client certificates issued to them (if
> any), so it offers PKINIT to all principals if the KDC is configured
> with a KDC cert. But that's an implementation issue.
Are you suggesting that PKINIT shouldn't be offered even when anonymous
PKINIT is supported? Put otherwise, that the client should try anonymous
PKINIT even when not offered it?
Nathaniel
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
