SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Kerb auth issue 1 - checksum



    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
    
    


Home

Last updated: Thu Jan 02 16:19:03 2003
12106 messages in chronological order