|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Kerb auth issue 1 - checksum
Bill,
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).
If IPsec is not used, m-i-m can hijack the connection after
the login anyway.
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
Bill Studenmund
<wrstuden@wasabis To: <ips@ece.cmu.edu>
ystems.com> cc:
Sent by: Subject: iSCSI: Kerb auth issue 1 - checksum
owner-ips@ece.cmu
.edu
18/12/2002 03:22
There is one aspect of Kerberos 5 mk_req/mk_rep authentication that was
not covered in the iSCSI draft, the use of a "checksum". In this context,
a "checksum" is generated from a string of data (will elaborate in a sec)
and is used to tie the kerberos authentication packet to a specific
authentication instance. Its intent is so that neither a man-in-the-middle
nor a passive listener can take the authentication info and authenticat
itself to the server in a separate connection; you can't re-use the
authentication info.
telnet uses: the authenticator's type and authentication "way." Not being
100% on telnet, I can't say more.
rsh uses: a string which contains the source port number, if encruption is
present, the remote command, and the remote username.
In this note I'd like to propose one for iSCSI.
I think the checksum string for iSCSI should contain the initiator name,
the isid, the target name, the target portal group tag, and the connection
id. This checksum would limit the reuse window of kerberos authentication
data to doing a login-with-auth-logout of the just-created connection. I
think the initiator would notice this.
Specifically I think the string should be (indistinguishable from) the
output of:
uint8_t *initiator_name, *target_name;
uint8_t
buffer[SIZE_LARGE_ENOUGH_TO_NOT_OVERFLOW];
uint8_t isid_buffer[6];
uint64_t isid;
uint16_t tsih;
uint16_t connid;
/*
* Assume that initiator_name, target_name, tsih, and connid
are
* initialized to the appropriate values, and that isid_buffer
* contains a copy of the isid used
*/
/* turn the isid buffer into a 64-bit big-endian number */
isid = ((uint64_t)ntohl(*((uint32_t *)isid_buffer))) << 16
| ntohs(*((uint16_t *)(&isid_buffer[4])));
sprintf(buffer, "%si%" PRIx64 ",%st%x,%d",
initiator_name, isid, target_name, tsih, connid);
PRIx64 is the c99 printf macro that will give the correct formatting to
print a 64-bit number in hex.
Note that the isid handling above is equivalent to the hex string
representation of the isid as a binary string (without the leading 0x).
For the initiator name "iqn.2000-05.com.wasabisystems.wonderdriver",
target name "iqn.2000-05.com.wasabisystems.storagebox", isid
0x400038873ff4 (inside Wasabi's enterprise number), tsih 1, and connection
id 64, the checksum string would be:
"iqn.2000-05.com.wasabisystems.wonderdriveri400038873ff4,iqn.2000-05.com.wasabisystems.storageboxt1,64"
Thoughts?
Take care,
Bill
Home Last updated: Thu Dec 19 14:18:58 2002 12091 messages in chronological order |