Re: [kitten] firewalls and cross realm trusts

["Nordgren, Bryce L -FS" <[e-mail]>]

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





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.