Re: [kitten] firewalls and cross realm trusts

[Nico Williams <[e-mail]>]

On Wed, Feb 19, 2014 at 12:14:18AM +0000, Nordgren, Bryce L -FS wrote:
> > Yes, it doesn't have to have its IP address be resolvable to its hostname,
> > whatever it might be, nor does that need to match the laptop's client
> > credentials in any way.
> 
> I fear I miscommunicated. The laptop's identity in the KDC is likely
> an NT_SRV_HST host/home.dns.here. The fact that NT_SRV_HST is used
> [...]

You're assuming that, probably due to habit from working with Kerberos,
but nothing says that a) the laptop must have _client_ credentials, b)
that they must be host-based, nor c) that they must correspond to
whatever the laptop's apparent current FQDN might be.

I know because I was involved in seeing to it that Solaris' NFS stack
doesn't have these requirements :)  Of course, it once did, and for the
same reason that you thought it might: because someone thought it should
because they thought that the situation (device authentication) was
symmetric.  But that's wrong: it's not symmetric at all.  The client of
a host-based service starts out knowing the desired service and host
names, while a service does not start out knowing its client's names
until they authenticate.

Constructing a desired target service name out of the desired hostname
for it is a form of light-weight authorization of the service to the
client.  Once the service is authenticated, it's also implicitly
authorized.  (This is feasible when the client has a priori knowledge of
the server's hostname.)

The service, on the other hand, has to authorize clients based on their
authenticated names.

> I guess a better question would have been: Can hosts given NT_SRV_HST
> principal names still function within the Kerberos universe if their
> DNS entry does not exist or does not match that in the principal name?

As a client, yes, *typically* because most service applications don't
actually care about the form of the client's name, with very few
exceptions.

I mentioned one such exception (root equivalent access to NFS shares).
That exception derives from the fact that the server's root-equivalent
authorization check is based on client name forms.  Though even then,
nothing actually requires such a check, and it exists as it does mostly
due to inertia.

> If it's even possible that a KDC or service could use the hostname in
> the principal as part of its authorization decision, and RFC4120 tells
> it how to derive hostname from principal name, then it seems to me
> that this is an essential, not incidental, feature of the Kerberos
> protocol.

When acting as a client it's only incidental, not essential.  When
acting as a service it's essential (for services whose names are
specifically intended to be host-based names).

Nothing stops a service from requiring specific name forms from their
clients, or applying arbitrary authorization checks.  But generally the
only requirement is that there be some sort of authorization, not a
particular for.

Whereas clients authorize host-based services by the form of their
names matching the desired service and host names.

> Does this suggest that if one wants to promote mobility-friendly
> deployments, that host principals should be NT_PRINCIPALS? Is it just
> lucky chance that the Solaris NFS stack works for mobile clients, or
> was it compelled to by the protocol itself?

It's not by chance.  The Solaris Kerberos team noticed the need for that
as part of eating their own dogfood long ago.

[...]
> > Needham-Shroeder is out, as it's online.  PK-based protocols can do it, but
> > PKIX is not really offline: there's CRLs to check (and/or OCSP).
> > That includes PKINIT and a hypothetical PKCROSS, but again, if the client's
> > PKIX credentials aren't fresh enough then the protocol will become online
> > and therefore fail.
> 
> A couple of things: online and offline are not necessarily binary
> quantities. Maybe a service has a pre-configured path to a KDC
> unavailable to a client. Connectivity between entities may also be
> "spotty", allowing an opportunistic refreshing of credentials which
> does not necessarily align with demand for services.

Offline/online is very much a binary attribute of a protocol (or
deployments).  If two entities cannot authenticate (and authorize) each
other due to needing but lacking connectivity to online infrastructure,
then the protocol is online; otherwise it's offline.

The only middle-of-the-road is a fallback from online to offline
behavior, but such fallbacks generally have security considerations.  If
you have such a fallback then you have an offline protocol anyways.

> One thing I have been asked to do in the past is to create a little
> portable network having a raid server for scientists to upload data to
> during a field campaign. The usage pattern would be to come to the
> network island on the conference table, plug in, transfer data, paw
> through other people's data, and go back to their hotels at night;
> checking email and such.

The host-based client credential naming issue is eithe a non-issue or a
bug in the services you're using.

The online nature of Kerberos (but also, really, PKIX) means that you
must either give visitors local credentials or you must have
connectivity back to [possibly a small portion of] the visitors' home
networks.

> In this situation, if their clients were "disconnect-aware", they
> could renew their tickets every night. Alternatively, allowing
> services to accept expired tickets would also go a long way toward
> making Kerberos more disconnect-tolerant.

That would work for PKIX (get OCSP responses and if the services are
happy with at least 8-10 hours of OCSP response freshness, then all's
good).

For Kerberos the users would have to get all the service tickets they'll
need during that day.  One way or another that will mean cross-realm
operations, *unless* you give visitors local credentials.

> > There really isn't anything you can do here to address your hypothetical use
> > case: Y will just have to be able to reach some part of X's infrastructure.  This
> > isn't usually a problem, and it's neither the motivation for IAKERB, nor PKINIT,
> > nor PKCROSS.
> 
> What I'm really trying to get at is: disconnects break Kerberos so
> often that all machines using it have a fallback plan (cached
> credentials); so is it worth trying to define a fallback that's
> actually a part of the protocol?

The nature of Needham-Schroeder is such that the protocol is and must be
online unless you have all of a) a list of services you'll need tickets
for a priori (difficult), b) connectivity and trust paths to get them
once (difficult), c) workable freshness (ticket lifetime, cert/OCSP
response freshness) policies (feasible).

The story doesn't end there though.  You can use hx509 to bridge
Kerberos to PKI.  And later you can even bridge back to Kerberos using
PKINIT (this is my proposal for PKCROSS!).  PKI requires only (c),
workable freshness policies, so you can get there.

The last mile will be online when using Kerberos, offline when using
PKIX with the hx509-acquired cert.  In the Kerberos case, if you're
using hx509/PKCROSS then the last mile will be online but local to the
local site (in your use case).  So either way Kerberos and PKI can work
for this use case.

> > IAKERB exists to deal with the lack of any network connectivity at
> > network attachment time.  The client wants to authenticate with a
> > mechanism (Kerberos, but it could be something else) that requires
> > connectivity to one or more infrastructure services, but this can't
> > be retrofitted into the network attachment protocol (for whatever
> > reasons).
> 
> May I restate this? The Kerberos model assumes uninterrupted
> connectivity between the KDC and all clients. IAKERB is motivated by

Well, Needham-Shroeder does.  Kerberos is an incarnation of
Needham-Schroeder, but it's not pure (PKINIT, hx509, past efforts at
PKCROSS and PKTAPP).

> the fact that an "admission onto the network" authorization decision
> inherently means that the client not on the network is not connected
> to the KDC. IAKERB enhances Kerberos by allowing new authorization
> decisions formerly prohibited by the technical design.

Well, by allowing message flow.  Authorization is orthogonal (but you
can't have it until you have authentication, which is what IAKERB makes
feasible in these cases).

> IAKERB seems to have a lot of potential beyond its initial motivation.
> In particular, it could serve to reduce the number of situations in
> which a client would have to rely on cached credentials.

There's no reason not to use IAKERB outside its originally intended use
cases, but those will remain the primary use cases.

Don't mix up IAKERB with PKCROSS and such :)

Nico
--