Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-01.txt

[Benjamin Kaduk <[e-mail]>]

My apologies for the delay in responding ... hopefully the relevant
thoughts have not since been forgotten.

On Sat, 15 Feb 2014, Nordgren, Bryce L -FS wrote:

> -- Comments on draft-ietf-kitten-iakerb-01.txt --
>
> Comment 5: This approach may be summarized as a "message relay" from
> client to app to KDC. Compare and contrast this approach with a "ticket
> relay", where a strawman (fake) KDC requests and relays proxiable and/or
> forwardable tickets from the "real" KDC on the client's behalf, using
> its own identity. Outline the tradeoffs in terms of compatibility with
> deployed Krb5 clients and KDCs, amount of "extension" required, types of
> situations to which the approach applies, state information required at
> the relay point, and security implications. Make the case that "message
> relay" is a superior strategy, and show that alternatives were
> considered and rejected.

It's not really clear to me that this sort of comparison is necessary.
If I understand correctly, this proposed strawman fake KDC would also need
to be in the DMZ, with network connectivity to both the real KDC and the
client.  The real KDC would need some way to authorize the fake KDC's
principal as permitted to get tickets for (arbitrary? particular?) client
principals.

Then one considers whether the fake KDC gets a copy of the session keys
for those tickets.  If it does, how does it securely transmit those back
to the client, given that the client is not really authenticated yet.  If
it doesn't, then what it is sending back to the client is fundamentally
equivalent to a KDC-REP, at which point we've degenerated back to the
message-passing paradigm.

Maybe I'm missing something, but is there even a real strawman to prop up
here?

> Comment 6: This message relay approach intentionally establishes many
> persistent "men in the middle", potentially piggybacking on every
> kerberized app you have.  Note this in the security considerations.

I guess we could mention that.  It doesn't matter, because kerberos is
designed to run on the open internet anyway so all the interesting bits
are encrypted.

> -- Technical discussion about draft-ietf-kitten-iakerb-01.txt --
>
> Comments 2 and 3 boil down to: should an IAKERB enabled Kerberos client
> keep track of KDC connection failures so that it can try and get tickets
> when it later discovers a path to the KDC? Conversely, should an IAKERB
> enabled Kerberos client keep track of proxies so that it doesn't just
> give up when it can't contact the KDC? Details below.
>
> 2nd comment details...Proxies may be asked to acquire tickets for other

They may be, yes.  That is not the intended use case, though.
(We should still talk about any relevant security considerations, of
course.)

> services, and the order in which services are accessed by clients seems
> to matter. (Person A is at home, accessing web services "X" and "Y".
> Both X and Y are kerberized. X is IAKERB enabled and Y is not. If A
> connects to X first, it SHOULD request a ticket for Y using X once it
> discovers that Y isn't IAKERB enabled. If A connects to Y first, it has
> no TGT nor a means of getting one, so Y must behave like a gateway.
> After A connects to X, and "discovers" a pathway to its KDC, should it
> then request tickets for Y? How is Y informed that A now has a ticket? )
> This may not require much in the way of verbage, but I think it probably
> should be included. The proposed improvement is to eliminate gatewaylike
> behavior.

Since this is not the intended use case of the document, I don't think we
need to cover it at all, other than any security considerations this
client workflow might entail (which I have not yet attempted to analyze).
If at some later date, someone has a use case for this client workflow,
then we can revisit the issue, but it seems like it's really an
implementation issue, anyway.

This workflow feels quite strange anyway, since the GSSAPI security
context tokens are nominally working towards a single authentication
event, and this workflow is abusing the IAKERB proxy to exchange messages
which are relevant to a different authentication event.  I don't think we
necessarily need to forbid it at the present time, though.

> 3rd comment details...what if the service also does not have a path to
> the KDC? In the VPN example above, I log in to my host using cached
> credentials. Once I connect to an IAKERB proxy (VPN server), should the
> host try to grab a valid ticket?

I don't think I follow this question, but I'll take a couple of stabs at
it.

If the GSS acceptor ("service") does not have a network path to the KDC,
then the IAKERB mechanism must fail; there is simply no way for the
initiator to get its desired KDC responses.  There is no provision for
another layer of network proxying.

If you log onto a host by validating against cached credentials, and then
later (after the cached credentials are expired, say) go to authenticate
to a remote service over the IAKERB mechanism and obtain a new TGT during
that GSS negotiation loop, I would expect the new TGT to be retained in
your krb5 credentials cache on the original host.  Even if you already had
a TGT and were just using IAKERB to get a service ticket, I would still
expect it to be cached.  I would not expect the mechanism to proactively
go and get a service ticket for the local host's service principal and
cache that.

-Ben