Subject: [kitten] firewalls and cross realm trusts

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Sat, 15 Feb 2014 21:06:10 +0000

I appreciate your patience in advance. :)

> Also, to use Kerberos outside the firewall would require configuring the
> firewall to permit DNS and Kerberos, which might be too difficult, and
> anyways might be considered risky (considering all that can be smuggled in
> DNS and Kerberos messages).

Please elaborate these issues within the context of cross-realm trusts and perhaps your pkcross draft. It seems like no matter where you are, you're always outside of somebody's firewall and DNS is not very mobility friendly.

In particular, I'm curious about the following: Say person A and laptop B belong to realm X. Person A and laptop B visit realm Y. Person A is the same, laptop B is the same, but laptop B's DNS entry (if it exists) is now issued by realm Y instead of X. Assume no firewalls and realms X and Y have a cross realm trust. Will laptop B be recognized by realm X even though its DNS is wrong? :) Can it, for instance, be an NFS client?

Now X and Y both have firewalls.  Say realms X and Y don't have a cross realm trust, but they both are pkcross friendly. Can pkcross + iakerb allow realm Y to contact realm X to validate person A and laptop B? Can pkcross concepts be used to eliminate the need for Y  to contact X? (e.g., A and B have been issued certificates signed by X, which has a certificate that Y would either trust or not, so why bother contacting a firewalled X?)

Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Feb 2014 21:58:23 -0600

On Sat, Feb 15, 2014 at 09:06:10PM +0000, Nordgren, Bryce L -FS wrote:
> Please elaborate these issues within the context of cross-realm trusts
> and perhaps your pkcross draft. It seems like no matter where you are,
> you're always outside of somebody's firewall and DNS is not very
> mobility friendly.

If you're using a remote access protocol then you're outside the
firewall until you establish the necessary tunnel.  (Almost by
definition, since the remote access gateway [and protocol] generally
exists only to get past a firewall.)

> In particular, I'm curious about the following: Say person A and
> laptop B belong to realm X. Person A and laptop B visit realm Y.
> Person A is the same, laptop B is the same, but laptop B's DNS entry

Laptops shouldn't count on having names published in the DNS reliably
and kept up to date in real-time.

> (if it exists) is now issued by realm Y instead of X. Assume no

DNS entries aren't issued by Kerberos realms :)  (Frequently realms' KDC
and DNS zones' infrastructures are co-located, at least in Microsoft's
Active Directory.  But that's incidental, not essential.)

> firewalls and realms X and Y have a cross realm trust. Will laptop B
> be recognized by realm X even though its DNS is wrong? :) Can it, for
> instance, be an NFS client?

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.

At least the Solaris/Illumos NFS stack will work fine, both as to
mobile clients and their servers, at least as to authentication.  And
this will work even without any machine credentials.

(The laptop might not get root-equivalent access to any NFS shares
though.  The Solaris/Illumos NFS server will want the client's
credential to be a host-based name for the "root" service and will want
the hostname from that name to match the name observed through the name
service.  But this is probably not a problem.)

> Now X and Y both have firewalls.  Say realms X and Y don't have a
> cross realm trust, but they both are pkcross friendly. Can pkcross +

Today that can't happen: there's no PKCROSS protocol.

> iakerb allow realm Y to contact realm X to validate person A and
> laptop B? Can pkcross concepts be used to eliminate the need for Y  to
> contact X? (e.g., A and B have been issued certificates signed by X,
> which has a certificate that Y would either trust or not, so why
> bother contacting a firewalled X?)

If there's no trust path from X to Y of any kind, then nothing can make
this work, not PKI, not Kerberos, nothing.

I think you're asking if there's an offline (in that X is not reachable
from Y) mechanism for X's users to be able to authenticate to Y.
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.

The main reason to want PKCROSS is really to complete a PKI/Kerberos
duality, leading to more application protocols being available with a
single credential than would be the case otherwise.  It's just one more
bridge in a world that needs more bridges because of how it came about.

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.

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).
IAKERB basically invites the network attachment point to engage in a
very limited form of routing.  The client's realm's KDCs (and possibly
others'), as well as the network attachment point's, will have to be
reachable from the inside (from within Y), but not necessarily from the
outside.

(Of course, a client could smuggle all sorts of things in Kerberos
payloads, just as clients can do the same over DNS.  A network that
wants to prevent this will simply not allow IAKERB to be used to reach
any realms' KDCs not on a white-list, or perhaps it won't allow IAKERB
at all.)

Nico
--

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 19 Feb 2014 00:14:18 +0000

> DNS entries aren't issued by Kerberos realms :)  (Frequently realms' KDC and
> DNS zones' infrastructures are co-located, at least in Microsoft's Active
> Directory.  But that's incidental, not essential.)

> 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 conveys information about the host: specifically "home.dns.here" is supposed to be the internet domain name per RFC4120 section 6.2.1. The client side services supporting an nfs connection (idmapd, etc) would be "nfs/home.dns.here".

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? 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.

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?

> I think you're asking if there's an offline (in that X is not reachable from Y)
> mechanism for X's users to be able to authenticate to Y.

Yes.

> 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.

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.

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.

> 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?

> 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 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.

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.

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Feb 2014 19:04:42 -0600

On Wed, Feb 19, 2014 at 12:14:18AM +0000, Nordgren, Bryce L -FS wrote:
> 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.

[...]
> 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.

> 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.

> > 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
--