Subject: Stronger QoP for GSS-API

From: [email-masked]
Date: Tue, 25 Jan 2000 12:04:25 -0600

With the recent changes in U.S. Federal Gov't crypto export
regulations, is there any interest in the CAT community in extending
GSS-API (actually, I think this deals more with specific mechanisms
and SPNEGO) to provide stronger QoP that can interoperate between
multiple implementations?

My own interest is driven by new crypto algorithms showing up in
Kerberos (e.g., 3DES from MIT, RC4 from Microsoft).  However, as it
stands now, the Kerberos Mechanism for GSS-API (RFC 1964) only
supports 56-bit DES as the standard confidentiality algorithm used to
implement the GSS_Wrap() and GSS_Unwrap() calls.  I think I understand
the existing RFCs and any active Draft submissions, but as always I'm
happy to be informed otherwise.

David K. Hemsath, IBM Tivoli Security Business Unit

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 25 Jan 2000 16:32:55 -0500

> happy to be informed otherwise.

Well, we could always add more numbers to the tables, but then we have
to keep extending the krb5 mechanism spec every time krb5 itself gets
a new cryptosystem.

I think the first thing to try is to work out whether it's possible to
derive more information from the Kerberos messages exchanged.  For
example, the current SEAL_ALG values defined are

	ff ff	- none
	00 00	- DES

to which Microsoft adds

	01 00	- RC4

and perhaps we could add

	00 02	- whatever enctype is indicated for the session key

with a suggestion to implementors that they use 00 00 for a DES key.
And add some text specifying usage values for key derivation.

And replace all descriptions of padding to multiples of 8 bytes with
padding to multiples of the cryptosystem block size (which in the DES
case would be 8, so no incompatibility there).  IIRC there's at least
one case where padding is done as 1 to 8 bytes; that just needs some
careful wording to indicate the next multiple of the block size that's
*higher* than the existing field size.

And, thanks to the MICROS~1 scheme, the sequence number byte order is
dependent on the cryptosystem type.  *sigh*

Some of it would be tricky, but I think it would be possible to extend
RFC1964 in a way fully backwards compatible with the original RFC, and
not totally ugly.

I'd been thinking of working out the details and writing up something
along these lines in my Copious Free Time[TM], but haven't gotten
around to it yet.  (Though it'll probably become a priority very
soon.)  However, all of this does ignore the possible desire to have
SPNEGO compare the actual cryptosystems that the available mechanisms
would use....

Ken