|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Kerb auth issue 1 - checksumSorry 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
Home Last updated: Thu Jan 02 16:19:03 2003 12106 messages in chronological order |