Re: [kitten] firewalls and cross realm trusts

[Nico Williams <[e-mail]>]

On Sat, Feb 15, 2014 at 09:06:10PM +0000, Nordgren, Bryce L -FS wrote:
> > 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.

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