Subject: draft-ietf-iakerb-xx.txt discussion

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 9 Aug 2000 15:33:22 -0700

This mail has been copied the KINK mailing list, as the discussion seems
germane to their endeavor.

The standard way people seem to be thinking about deploying Kerberos in
conjunction with 802.1X style networks and remote access IPsec is covered by
draft-ietf-iakerb-xx.txt. In this model the connecting client assumes the
role of the Kerberos client, and the "attachment point" (be it a VPN
Gateway, 802.1 switch, whatever) or server occupies a dual role, first of a
proxy as described in the draft, and then as the Kerberos server. The server
proxies client ticket requests to the KDC, and then proxies any response
back to the client. The client uses the proxied ticket to authenticate with
the server sitting between it and the KDC.

I am wondering whether there is an opportunity to do something else,
something that on first blush appears a modest improvement, at least to me.
The existing proxy model appears to have several features that render it
somewhat less desirable than we might otherwise wish it to be.

First, to be used in many of the environments people will want to use the
protocol (e.g., remote access IPsec, authentication to a wired
infrastructure over wireless LANs, etc.), the client will be "outside" the
firewall and therefore completely untrusted. While assuming an untrusted
client is standard, and while Kerberos was designed for this kind of
environment, experience shows that many organizations have had trouble
properly deploying Kerberos (their KDCs get hacked), and even more bitter
experience shows they are therefore unwilling to expose their KDCs to
messages from clients situated beyond their firewalls, because "the ones
inside can be trusted and the ones outside the firewall can't be" (yeah,
right). You can call this a deployment error (it is) and ignorance (it's
that, too), but it is also market reality, because most people managing
networks are not trained security professionals and never will be. It is
certainly feasible that the proxy can protect the KDC (e.g., rate limiting
messages, filter buffer overrun attacks, and the like), but I expect many
organizations will still be loath to use such a system based on their
experiences; implementors, after all, have a dubious track record at best of
getting the security properties of proxies right the first or second or even
third time around.

Another problem is the client needs to know too much. It needs to know the
identity of the server to format its ticket request, and this spells
configuration, or at least the wrong kind. Configuration on clients is
almost always a deployment barrier, and always a scaling issue. The draft
attempts to address the problem by allowing the proxy (aka server) to fill
in the realm name, but from my  (perhaps warped) way of thinking, this is
not quite right. It seems more likely to me that people will want to
configure their remote access clients with the realm name, and connect to
any attachment point that offers realm services, without regard to the
identities of the servers providing that service. And the push toward
greater mobility seems to indicate that clients are likely to belong to
several realms, meaning they will possess credentials from multiple realms
(with differing principal names), meaning they won't be able to identify
themselves properly until they know what realm they are trying to enter. The
realm is something that has to be configured on the client, because it will
serve as the locator for the client's own proper principal name.
Configuration is bad, but some kinds of configuration can't be avoided.

A third problem is the proxy doesn't seem to be able to know the messages
from the KDC it proxies back to the client are indeed live, because it
doesn't contribute to the nonce, and it can't inspect the nonce in the KDC's
response to the client. This seems to make the protocol susceptible to
collusion between an insider and an outsider.

A final potential problem to any network engineer is "unnecessary" messages.
The proxy (i.e., server) has all it needs to initiate Kerberos-based mutual
authentication with the client, but instead it is still in proxy mode,
"squandering" the opportunity to optimize at least one message away.

All of this makes me wonder whether it might be advantageous to alter the
responsibilities of both the proxy and the client somewhat, effectively
interchanging their roles. The client wanting to mutually authenticate would
forward its identity to the proxy. The proxy would request from the KDC a
ticket from its own host to the requesting client. Once it received the
ticket, the proxy could use the ticket to initiate the authentication
protocol with the client.

This design seems to address all of the questions I raised above. It
addresses the first issues, because the proxy/servers themselves (presumed
to be under the organization's control) generate ticket requests, not the
"untrusted" clients. It addresses the second problem in that client's don't
have to care about the name of the attachment point, since the returned
ticket and authenticator supply this. It addresses the third problem,
because the proxy/server supplies the nonce (but that exposes the client to
replay; see the discussion below). And it addresses the last issue, as it
removes at least one message from the entire exchange.

As noted above, the biggest problem I can see with this type of approach
(aside from the disadvantage it is not what people are doing) seems to be
the real remote access client needs to protect itself from replay attack by
a rogue proxy/server; this is what its nonce in the ticket request does,
after all. One way to address this might be to require the client to supply
a nonce with its identity, and for the proxy/server to concatentate its own
nonce at the end of the client's to insert into its ticket request. We would
need some sort of convention to transfer the nonce back into, e.g., the
server's authenticator to the client. I haven't worked out the details, only
speculated that this might be a fruitful approach.

I don't know if the above analysis of the current draft holds water, or
whether the germ of an idea presented here actually represents an
improvement on the draft, or is good idea, or even works. What do other
people think?

Jesse Walker
Intel Corporation
JF3-448
2111 N.E. 25th Avenue
Hillsboro, OR  97124
(503) 712-1849

---

From: Ken Raeburn <[email-masked]>
Date: 16 Aug 2000 07:17:45 -0400

> protocol with the client.

If the client's key is derived from a password, interception of the
message from the proxy to the client can lead to a dictionary attack
opening against the client, because it has to be encrypted in the that
key.  Plain Kerberos doesn't prevent such an attack either when
getting the initial TGT, but preauthentication methods can be designed
to do so, and they only work when getting the initial TGT.  Using the
"user to user" mode is more secure when the "server" may be a user
with a relatively weak password-based key instead of a service with a
stronger random binary key.

We shouldn't design protocols that shut out such measures, if we can
avoid it.  I think the extra protection is worth the extra traffic.

Ken