|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Kerb auth issue 1 - checksumBill, 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 |