Automatic FAST via Anonymous PKINIT

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Automatic FAST via Anonymous PKINIT

Nathaniel McCallum-5
FAST is useful, especially for OTP. But FAST is also difficult to get
setup. In the FreeIPA community, we work around this problem by using
SSSD on the client-side and it establishes FAST automatically. However,
kinit doesn't work. Making this process not only smoother, but with a
similar behavior to what web-user expect is highly desirable. To this
end, I would like to propose a design for a zero-conf client FAST
channel. This breaks down into three distinct tasks: client behavior,
client trust and server policy.

=== CLIENT BEHAVIOR ===

The client should detect the following state:
1. Preauth is required.
2. FAST is offered.
3. No known preauth mechs are offered.

Currently, when this state exists, the client fails to authenticate. I
would like to propose that when this state exists, the client should
instead attempt to perform anonymous PKINIT and use the resulting ticket
to establish the FAST channel to find if new preauth mechs are
available.

=== CLIENT TRUST ===

Using other methods of establishing the FAST channel imply an already
established trust between the client and the server. In the case of
SSSD, for instance, the client has already been added to the FreeIPA
realm. This added level of trust is necessary because, unlike
non-preauth Kerberos, long term secrets are going over the wire. When
using Anonymous PKINIT, this trust takes the form of trusting a
certificate's CA chain. We have discussed four approaches with MIT.

1. Manual Configuration

The user will have to manually create a CA trust chain anchor.

This is the current behavior which does not fulfill our requirements for
requiring zero configuration. Regardless of what other option we pursue,
this method should be retained as a possibility.

2. Leap of Faith

The user would be prompted to trust the certificate.

This is a similar model to SSH. As Greg joked on the call today, this
isn't "web scale." There are obvious difficulties with:
A. how to prompt the user
B. which certificate in the chain to trust
B. how to handle when certificates change

This is particularly problematic because certificates change frequently
compared to ssh server keys and are not automatically generated.

3. Trusting Host Certificate Anchors

The user would accept the same CA trusted by his browser.

Fedora, for instance, now has a unified global certificate anchor
database with admin tools to manage it. This would most likely not be an
upstream MIT patch, but would be carried by distributions.

The problems with the browser CA trust model are well known (let's not
hash them out here). On top of this, forcing each platform to configure
this right will make the feature somewhat useless. This will, in turn,
cause admins not to deploy it.

4. DNSSEC (the preferred option)

The user would trust certificates offered by DNSSEC/DANE.

An implicit mapping already exists between the realm and a DNS name when
looking up SRV records. We could extend this mapping such that signed
TLSA records are used to identify the canonical certificate for the KDC
realm. The client then ensures that the certificate provided by the KDC
matches the certificate provided by DNSSEC.

If connecting directly to a KDC, the server name could be validated from
the certificate. However, forcing this behavior would make proxying the
packets (for instance, over HTTP) impossible to verify. For this reason,
I am advocating not forcing this validation.

=== SERVER POLICY ===

The server needs to take care to ensure that if some preauth mechs are
available over FAST only, that no non-FAST preauth mechs are offered.
For instance, if a user is configured for either OTP or PKINIT, because
PKINIT is offered outside of the FAST channel the client state for
automatic FAST will never be triggered. The end result is that the user
never knows that OTP is an option for authentication.

Hence, some kind of per-user preauth policy needs to be implemented on
the server. This policy should define which preauth mechs are available
for the user and whether they require the FAST channel or not. If any
preauth mech requires the FAST channel, the server should enforce that
all of them do as well.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nico Williams
On Tue, May 20, 2014 at 1:59 PM, Nathaniel McCallum
<[hidden email]> wrote:
> === CLIENT TRUST ===
>
> Using other methods of establishing the FAST channel imply an already
> established trust between the client and the server. In the case of
> SSSD, for instance, the client has already been added to the FreeIPA
> realm. This added level of trust is necessary because, unlike
> non-preauth Kerberos, long term secrets are going over the wire. When
> using Anonymous PKINIT, this trust takes the form of trusting a
> certificate's CA chain. We have discussed four approaches with MIT.

One more possible method for establishing trust would be for the user
to convey it via their realm name, something like:

foouser@+MYREALM

or

foouser@WELLKNOWN:FAST:MYREALM

I like the first because it's easy to use, though technically it is
camping, but I don't think I care in this case.

This has the added benefit that setting +MYREALM as a default/user
realm in krb5.conf is all that would have to be done to configure FAST
support.  Unfortunately this would probably break things like Java
JGSS, so never mind this part.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Greg Hudson
In reply to this post by Nathaniel McCallum-5
On 05/20/2014 02:59 PM, Nathaniel McCallum wrote:
> The client should detect the following state: [...]
>
> Currently, when this state exists, the client fails to authenticate. I
> would like to propose that when this state exists, the client should
> instead attempt to perform anonymous PKINIT and use the resulting ticket
> to establish the FAST channel to find if new preauth mechs are
> available.

I think this is a good idea, but we need to consider how to cache the
resulting anonymous armor ticket.  We don't want the same armor ticket
used by multiple uids, but multiple AS requests made by the same uid
will be substantially more efficient if they can reuse the armor ticket
from a previous request.  Options include:

1. Don't cache it; get a new anonymous credential each time we run into
this situation.

2. Cache it in a MEMORY ccache with a fixed name.

3. If the default ccache is collection-enabled, add the ticket to the
collection using the anonymous name.  This might be a bad idea; we don't
necessarily want WELLKNOWN/ANONYMOUS to become one of the identities to
consider authenticating with.

4. Introduce the concept of the default fast ccache with discovery
options paralleling the regular default ccache ($KRB5FASTCCNAME,
[libdefaults]->default_fast_ccache_name, a hardcoded default like
/tmp/krb5fastcc_%{uid} overridable at build time).  This could also be
used by pam_krb5 to provide an armor ticket from the keytab for use by
AS requests, on systems with keytabs.

Option 4 has the biggest footprint, but is my current preference.  If
the default fast ccache doesn't exist or can't be used, we can fall back
to option 2.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nico Williams-2
Greg's #1 works, just inefficiently.  It's a lot better than nothing and a
no-brainer.  #2 doesn't help much.  #3 might be more useful than you think,
but I'd store the FAST armor ticket (it's constrained, isn't it?) in the
normal ccache, with a link to it from a ccconfig entry.  #4 is clearly
desirable from a systems pov, though i would prefer an IPC protocol so as
to be better able to apply least privilege principles.  Still, #4 looks
very nice, so it gets my +1.

Nico
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nathaniel McCallum-5
On Fri, 2014-05-30 at 09:16 -0500, Nico Williams wrote:
> Greg's #1 works, just inefficiently.  It's a lot better than nothing
> and a no-brainer.  #2 doesn't help much.  #3 might be more useful than
> you think, but I'd store the FAST armor ticket (it's constrained,
> isn't it?) in the normal ccache, with a link to it from a ccconfig
> entry.  #4 is clearly desirable from a systems pov, though i would
> prefer an IPC protocol so as to be better able to apply least
> privilege principles.  Still, #4 looks very nice, so it gets my +1.

Thinking through this, I don't know that anything other than #1 is
really needed. Caching only provides a benefit when the ratio of
non-Anonymous ASReqs to Anonymous ASReqs is high. In the typical case of
kinit, this ratio is essentially 1:1, providing no benefit.

The only case I can think of where caching provides a significant
benefit is in the case of a login system. In this case, the ratio could
be very high. If the login system is a single, stateful process #2 might
make sense. But I can't think of a single login system that is
architected this way.

So my vote is #1 now and #4 at a later time.

Nathaniel



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Benjamin Kaduk-2
In reply to this post by Greg Hudson
On Thu, 29 May 2014, Greg Hudson wrote:

> On 05/20/2014 02:59 PM, Nathaniel McCallum wrote:
>> The client should detect the following state: [...]
>>
>> Currently, when this state exists, the client fails to authenticate. I
>> would like to propose that when this state exists, the client should
>> instead attempt to perform anonymous PKINIT and use the resulting ticket
>> to establish the FAST channel to find if new preauth mechs are
>> available.
>
> I think this is a good idea, but we need to consider how to cache the

I re-read the original proposal, and also think it's a good idea.

The only thing that seems like it might require additional thought is the
server policy side, where the logic could get a bit complicated depending
on what preauth schemes are in play.  I don't think there's anything
non-obvious, just that a KDC serving some clients which only do pkinit,
some that only do OTP, etc., requires some logic to know what to offer in
each case.

> 1. Don't cache it; get a new anonymous credential each time we run into
> this situation.
>
> 2. Cache it in a MEMORY ccache with a fixed name.
>
> 3. If the default ccache is collection-enabled, add the ticket to the
> collection using the anonymous name.  This might be a bad idea; we don't
> necessarily want WELLKNOWN/ANONYMOUS to become one of the identities to
> consider authenticating with.
>
> 4. Introduce the concept of the default fast ccache with discovery
> options paralleling the regular default ccache ($KRB5FASTCCNAME,
> [libdefaults]->default_fast_ccache_name, a hardcoded default like
> /tmp/krb5fastcc_%{uid} overridable at build time).  This could also be
> used by pam_krb5 to provide an armor ticket from the keytab for use by
> AS requests, on systems with keytabs.
>
> Option 4 has the biggest footprint, but is my current preference.  If
> the default fast ccache doesn't exist or can't be used, we can fall back
> to option 2.

Option 4 looks fairly appealing.  It's possible that option 1 would be
reasonable, but I don't have a good feel for what the performance impact
would be of needing to do a public-key operation for every such
authentication.

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Benjamin Kaduk-2
In reply to this post by Nathaniel McCallum-5
On Fri, 30 May 2014, Nathaniel McCallum wrote:

> On Fri, 2014-05-30 at 09:16 -0500, Nico Williams wrote:
>> Greg's #1 works, just inefficiently.  It's a lot better than nothing
>> and a no-brainer.  #2 doesn't help much.  #3 might be more useful than
>> you think, but I'd store the FAST armor ticket (it's constrained,
>> isn't it?) in the normal ccache, with a link to it from a ccconfig
>> entry.  #4 is clearly desirable from a systems pov, though i would
>> prefer an IPC protocol so as to be better able to apply least
>> privilege principles.  Still, #4 looks very nice, so it gets my +1.
>
> Thinking through this, I don't know that anything other than #1 is
> really needed. Caching only provides a benefit when the ratio of
> non-Anonymous ASReqs to Anonymous ASReqs is high. In the typical case of
> kinit, this ratio is essentially 1:1, providing no benefit.
>
> The only case I can think of where caching provides a significant
> benefit is in the case of a login system. In this case, the ratio could
> be very high. If the login system is a single, stateful process #2 might
> make sense. But I can't think of a single login system that is
> architected this way.
>
> So my vote is #1 now and #4 at a later time.

I think that getting to a state where FAST is used for all traffic to the
KDC (which is not being used to obtain an armor ticket) is a very useful
state to be in, and #4 provides a lot of infrastructure that would make
that state more achievable, whether the armor is obtained via anonymous
PKINIT or otherwise.

So I don't think we should give up on #4 quite yet.

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nathaniel McCallum-5
On Fri, 2014-05-30 at 14:42 -0400, Benjamin Kaduk wrote:

> On Fri, 30 May 2014, Nathaniel McCallum wrote:
>
> > On Fri, 2014-05-30 at 09:16 -0500, Nico Williams wrote:
> >> Greg's #1 works, just inefficiently.  It's a lot better than nothing
> >> and a no-brainer.  #2 doesn't help much.  #3 might be more useful than
> >> you think, but I'd store the FAST armor ticket (it's constrained,
> >> isn't it?) in the normal ccache, with a link to it from a ccconfig
> >> entry.  #4 is clearly desirable from a systems pov, though i would
> >> prefer an IPC protocol so as to be better able to apply least
> >> privilege principles.  Still, #4 looks very nice, so it gets my +1.
> >
> > Thinking through this, I don't know that anything other than #1 is
> > really needed. Caching only provides a benefit when the ratio of
> > non-Anonymous ASReqs to Anonymous ASReqs is high. In the typical case of
> > kinit, this ratio is essentially 1:1, providing no benefit.
> >
> > The only case I can think of where caching provides a significant
> > benefit is in the case of a login system. In this case, the ratio could
> > be very high. If the login system is a single, stateful process #2 might
> > make sense. But I can't think of a single login system that is
> > architected this way.
> >
> > So my vote is #1 now and #4 at a later time.
>
> I think that getting to a state where FAST is used for all traffic to the
> KDC (which is not being used to obtain an armor ticket) is a very useful
> state to be in, and #4 provides a lot of infrastructure that would make
> that state more achievable, whether the armor is obtained via anonymous
> PKINIT or otherwise.
>
> So I don't think we should give up on #4 quite yet.

Even if we use FAST to encrypt all traffic, the temporary anonymous
ticket will only be used for ASReq requests. #4 provides no benefit to
"FAST all the time" apart from ASReqs. The only case where it does make
sense is in a login system. And the login system should (generally) be a
Kerberos service in its own right. This is precisely how SSSD works. No
anonymous ticket is needed because the service has its own ticket which
is managed in the SSSD ticket ccache.

Nathaniel


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nico Williams
On Mon, Jun 2, 2014 at 2:26 PM, Nathaniel McCallum
<[hidden email]> wrote:
> Even if we use FAST to encrypt all traffic, the temporary anonymous
> ticket will only be used for ASReq requests. #4 provides no benefit to
> "FAST all the time" apart from ASReqs. The only case where it does make
> sense is in a login system. And the login system should (generally) be a
> Kerberos service in its own right. This is precisely how SSSD works. No
> anonymous ticket is needed because the service has its own ticket which
> is managed in the SSSD ticket ccache.

Mobile devices might not be keyed, or if they are they might not have
stable hostnames (so don't insist on host-based client credentials for
them, or on their matching the client's IP address).

I agree that a per-session/user FAST armor ticket for protecting AS
_and_ TGS requests would be nice.  Greg's #4 is not incompatible with
that: a PAM / whatever can make sure to obtain such a ticket for the
user, and if none is available, then kinit/krb5_get_init_creds*() can
do it (though in the last case it'd be an anon PKINIT ticket).

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Greg Hudson
In reply to this post by Nathaniel McCallum-5
On 06/02/2014 03:26 PM, Nathaniel McCallum wrote:
> Even if we use FAST to encrypt all traffic, the temporary anonymous
> ticket will only be used for ASReq requests.

TGS requests do not need separate ticket armor to use FAST.  We have
been automatically making FAST TGS requests since 1.11, although we
don't currently do anything to enforce a FAST TGS response.  (And we
can't without additional protocol support, since Heimdal's KDC added
FAST negotiation without supporting FAST TGS.)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Benjamin Kaduk-2
In reply to this post by Nathaniel McCallum-5
On Mon, 2 Jun 2014, Nathaniel McCallum wrote:

> Even if we use FAST to encrypt all traffic, the temporary anonymous
> ticket will only be used for ASReq requests. #4 provides no benefit to

Right.

> "FAST all the time" apart from ASReqs. The only case where it does make
> sense is in a login system. And the login system should (generally) be a
> Kerberos service in its own right. This is precisely how SSSD works. No
> anonymous ticket is needed because the service has its own ticket which
> is managed in the SSSD ticket ccache.

I expect that there are a lot different deployment models for kerberos,
not all of which involve the login manager managing everything.  What you
describe is certainly true for the case that SSSD is trying to solve; I
don't have a good sense for what fraction of deployments it represents.

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nathaniel McCallum-5
In reply to this post by Nico Williams
On Mon, 2014-06-02 at 14:52 -0500, Nico Williams wrote:

> On Mon, Jun 2, 2014 at 2:26 PM, Nathaniel McCallum
> <[hidden email]> wrote:
> > Even if we use FAST to encrypt all traffic, the temporary anonymous
> > ticket will only be used for ASReq requests. #4 provides no benefit to
> > "FAST all the time" apart from ASReqs. The only case where it does make
> > sense is in a login system. And the login system should (generally) be a
> > Kerberos service in its own right. This is precisely how SSSD works. No
> > anonymous ticket is needed because the service has its own ticket which
> > is managed in the SSSD ticket ccache.
>
> Mobile devices might not be keyed, or if they are they might not have
> stable hostnames (so don't insist on host-based client credentials for
> them, or on their matching the client's IP address).

I don't think there is any plan to do this.

> I agree that a per-session/user FAST armor ticket for protecting AS
> _and_ TGS requests would be nice.  Greg's #4 is not incompatible with
> that: a PAM / whatever can make sure to obtain such a ticket for the
> user, and if none is available, then kinit/krb5_get_init_creds*() can
> do it (though in the last case it'd be an anon PKINIT ticket).

Of course not. I'm only trying to point out that #1 is independent of
#4. #4 is a nice feature, but I don't think it should hold back #1 from
being implemented.

Nathaniel

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Dmitri Pal
On 06/02/2014 05:24 PM, Nathaniel McCallum wrote:

> On Mon, 2014-06-02 at 14:52 -0500, Nico Williams wrote:
>> On Mon, Jun 2, 2014 at 2:26 PM, Nathaniel McCallum
>> <[hidden email]> wrote:
>>> Even if we use FAST to encrypt all traffic, the temporary anonymous
>>> ticket will only be used for ASReq requests. #4 provides no benefit to
>>> "FAST all the time" apart from ASReqs. The only case where it does make
>>> sense is in a login system. And the login system should (generally) be a
>>> Kerberos service in its own right. This is precisely how SSSD works. No
>>> anonymous ticket is needed because the service has its own ticket which
>>> is managed in the SSSD ticket ccache.
>> Mobile devices might not be keyed, or if they are they might not have
>> stable hostnames (so don't insist on host-based client credentials for
>> them, or on their matching the client's IP address).
> I don't think there is any plan to do this.

Actually we started poking at this area in attempt to bring FAST to
mobile devices. For initial case a key would be a prerequisite but a
good solution for a general case would be nice to have in a long run.

>
>> I agree that a per-session/user FAST armor ticket for protecting AS
>> _and_ TGS requests would be nice.  Greg's #4 is not incompatible with
>> that: a PAM / whatever can make sure to obtain such a ticket for the
>> user, and if none is available, then kinit/krb5_get_init_creds*() can
>> do it (though in the last case it'd be an anon PKINIT ticket).
> Of course not. I'm only trying to point out that #1 is independent of
> #4. #4 is a nice feature, but I don't think it should hold back #1 from
> being implemented.
>
> Nathaniel
>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nathaniel McCallum-5
In reply to this post by Nathaniel McCallum-5
On Tue, 2014-05-20 at 14:59 -0400, Nathaniel McCallum wrote:

> FAST is useful, especially for OTP. But FAST is also difficult to get
> setup. In the FreeIPA community, we work around this problem by using
> SSSD on the client-side and it establishes FAST automatically. However,
> kinit doesn't work. Making this process not only smoother, but with a
> similar behavior to what web-user expect is highly desirable. To this
> end, I would like to propose a design for a zero-conf client FAST
> channel. This breaks down into three distinct tasks: client behavior,
> client trust and server policy.
>
> === CLIENT BEHAVIOR ===
>
> The client should detect the following state:
> 1. Preauth is required.
> 2. FAST is offered.
> 3. No known preauth mechs are offered.
>
> Currently, when this state exists, the client fails to authenticate. I
> would like to propose that when this state exists, the client should
> instead attempt to perform anonymous PKINIT and use the resulting ticket
> to establish the FAST channel to find if new preauth mechs are
> available.

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." A quick perusal of RFC
6112 does not seem to provide any way for the client to detect if what
is being offered is regular PKINIT, anonymous-optional or anonymous-only
PKINIT.

In other words, the client cannot detect whether or not it should use
PKINIT directly or should use PKINIT to gain an anonymous ticket to
establish FAST to find more preauth mecs.

The easiest solution to me seems to be the creation of a new padata id
which implies that the PKINIT is anonymous-only PKINIT.

Thoughts?

Nathaniel

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nico Williams
The client can just try anon PKINIT.  If the AS doesn't like it, too bad.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Greg Hudson
In reply to this post by Nathaniel McCallum-5
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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nathaniel McCallum-5
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Greg Hudson
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Automatic FAST via Anonymous PKINIT

Nico Williams
In reply to this post by Nathaniel McCallum-5
On Wed, Jun 11, 2014 at 1:03 PM, Nathaniel McCallum
<[hidden email]> wrote:

> On Wed, 2014-06-11 at 13:52 -0400, Greg Hudson wrote:
>> 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?

It should be offered when the cname is the anon cname, if the AS
supports anon PKINIT.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev