Date: Thu, 2 Jan 2003 10:50:36 -0800 (PST)
From: Bill Studenmund <wrstuden@wasabisystems.com>
To: Ofer Biran <BIRAN@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Subject: Re: iSCSI: Kerb auth issue 1 - checksum
In-Reply-To: <OFD2B06FF5.BA813D39-ONC2256C97.007039B1@telaviv.ibm.com>
Message-ID: <Pine.NEB.4.33.0301020947540.1441-100000@candlekeep.home-net.internetconnect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sorry for the delay, I've been off-line for the holidays.

On Sun, 22 Dec 2002, Ofer Biran wrote:

> >> According to RFC1510 the server Kerberos implementation should
> >> maintain a cache of client name/timestamp for a window of the
> >> the allowable clock skew, this prevents a replay usage of
> >> the authenticator. Telnet does not bind the connection either,
> >> just the negotiation result (against m-i-m).
>
> >I'm sorry, are you saying we don't need this?
>
> In telnet m-i-m can take them down to no-encryption when the
> negotiation result would have been encryption. Here there is
> no negotiation result of that sort (well, we could have protected
> the AuthMethod negotiation itself, against being taken down from
> CHAP to Kerberos :-) but as I said with no IPsec m-i-m can hijack
> the connection after login anyway.
>
> For binding initiator/target/sessison_id/connection_id as you
> suggested - the cache of client name/timestamp protects against
> replaying the authenticator. Relying on such binding for not

That didn't parse.

> implementing the cache (i.e., I already have this
> sessison_id/connection_id from that initiator active, so it's a
> replay) has a replay risk in scenario of connection time shorter
> than the allowable clock skew of the authenticator timestamp
> (beside going against RFC1510 requirements).

Ok, I think I see what you think I'm suggesting. I'm not fully sure since
what I _think_ you are talking about isn't what I'm suggesting.

I'm not suggesting not implementing the cache (or I don't think I am). I
am specifically suggesting we have a checksum. i.e. BOTH a cache and a
checksum.

I'm going to assume that telnetd, rshd, and sshd all do kerberos according
to RFC1510. Looking at how their code works, that means that
krb5_mk_req()/krb5_rd_req() (well krb5_mk_req_exact() for heimdal) does
the right thing. So if we use krb5_mk_req()/krb5_rd_req(), we are
following the RFC. If this is NOT true, well, we (and a lot more than
just the iSCSI folks) have problems.

Before I go any farther, do you think the above is correct? Is krb5_mk_req
doing the auth caching you're talking about? If not, then we're arguing
about different things.

Because I'm suggesting we: 1) use a checksum and pass it to krb5_mk_req()
/ check for it after krb5_rd_req(), and 2) use a specific form for said
checksum.

i.e. rather than NULL, we pass a specific blob of data.


Also, _I_ am not suggesting it. I spent most of the IETF hanging out with
the Kerberos folks. Like Ken Hornstein (Kerberos FAQ author), Sam Hartman,
Jeff Hutzelman, and others (whose names I don't have at the tip of my
finger). In the Kerberos working group, these folks were invovled in
pretty much every discussion to each question. The rest of the WG seemed
to be very interested in what they said. So I asked them what to do, and
THEY said we need this. Not, "it would be nice," but, "do this." Do you
think they steered me wrong?

Take care,

Bill