Subject: Comments on draft-ietf-krb-wg-hw-auth

From: [email-masked] (Sam Hartman)
Date: Sun, 1 Dec 2002 16:22:36 -0500 (EST)

Hi.  I was discussing your draft with Ken Hornstein at IETF 55 and I
think I've come to the conclusion that your work can be generalized to
cover an additional work item of the working group while failing to be
specific to the SAM preauth mechanism.

In order to do this we need to consider a model for how
preauthentication is processed in the KDC.  This model does not
currently exist in any IETF documents; we'd need to write it down.

Let's say that preauths are handled in some ordered sequence.  One of
the inputs to the preauth method is the current reply key.  One of the
outputs is the new reply key.

Initially the reply key is the long-term key of the user.

The current SAM draft can be thought of as a preauth method that
replaces the reply key with combine_key(old_reply_key,
sam_challenge_key).

What your draft does currently is modify SAM in some way to replace
the reply key with combine_key(host_key, sam_challenge_key).

The SAM version 1 document had a bit that allowed you to exclusively
use the SAM challenge key and discard the long-term key.  Let's assume
for the moment that we convince Ken to bring that behavior back.

We could then replace your current draft with a preauth mechanism that
replaces the reply key with combine_key(host_key, old_reply_key).

By using the SAM draft in the mode where it only uses the challenge
key, and having the SAM draft in the preauth order before your draft,
we get a result that has equivelent security properties to your
current draft, but also allows us to use host keys for security even
when SAM is not being used.

There is some complexity in that the KDC needs to look forward in the
list of preauth mechanisms to see whether or not a host key is being
used.  If a host key is used, then it is probably OK to use the SAM
mechanism in a mode that does not require long term keys, but if no
host key is being used, then the KDC should probably be unwilling to
drop the long-term key.

In addition, we have to think about how we specify the preauth order.
Probably we want to have the order up to the KDC or something like
that.