Subject: I-D ACTION:draft-ietf-krb-wg-gss-crypto-00.txt

From: [email-masked]
Date: Thu, 14 Aug 2003 10:27:26 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kerberos WG Working Group of the IETF.

	Title		: General Kerberos Cryptosystem Support for the Kerberos
                          5 GSSAPI Mechanism
	Author(s)	: K. Raeburn
	Filename	: draft-ietf-krb-wg-gss-crypto-00.txt
	Pages		: 10
	Date		: 2003-8-14
	
This document describes an update to the Kerberos 5 mechanism for
GSSAPI to allow the use of Kerberos-defined cryptosystems directly in
GSSAPI messages, without requiring further changes for each new
encryption or checksum algorithm that complies with the Kerberos
crypto framework specifications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-gss-crypto-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-krb-wg-gss-crypto-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-krb-wg-gss-crypto-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Aug 2003 17:56:51 -0400

Note that there may end up being multiple proposals for GSS AES; there
is still a lot of off-list discussion going on.

Ken's current draft will clearly need to be modified in at least a few
respects.

There is a strong desire from Microsoft to support in-place encryption
of application data with some constraints on where the checksum can
go.  Supporting that with the generic profile has proven a bit tricky,
although I think we've finally found a solution that will presumably
be in a future version of this or some other draft.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 15 Aug 2003 09:39:18 -0500

> Ken's current draft will clearly need to be modified in at least a few

Yes, I would suspect that there will need to be changes, and the other vendors
like Microsoft need to be involved.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 18 Aug 2003 23:12:56 -0400

[I have no idea if saying this is irrelevant because of
behind-the-scenes discussion, but I suspect that is focusing on other
issues.]

|	    16..23   SGN_CKSUM    Checksum of bytes 0..7 and
|				  application data, as described
|				  in [GSSAPI-KRB5].

This appears to say that checksums have to be restricted to 64 bits in
size in order to fit in this gss definition which I thought was
supposed to be sufficiently general that we'll never have to modify it
to support future crypto.  My understanding of what Ferguson +
Schneier's ``Practical Cryptography'' (2003) says is that they
recommend the use of 256 bit checksums, sending 32 bytes in the over
the wire protocol.

I believe it would probably be worthwhile to eventually define 256 bit
AES with HMAC-SHA256 for krb5, sending the entire 32 bytes for the
checksum, but I think until we have better preauth, the strength of
the checksum is probably not the weakest link in the security of
Kerberos.  (Also note that the previous sentence makes no assertions
as to whether it should be counter mode or CBC, or whether we should
do both.)

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 19 Aug 2003 15:46:53 -0400

"Joel N. Weber II" <[email-masked]> writes:

> to support future crypto.

This was for the specific case of SGN_ALG values of 0000, 0100, and
0200, i.e., those already specified in RFC 1964 as DES MAC MD5, MD2.5,
or DES MAC integrity algorithms, each with 64-bit output.  For those
cases, we want to incorporate backwards compatibility.  For newer
cryptosystems, you would use SGN_ALG 0001, and the field layout
described just below the one you quoted.

>   My understanding of what Ferguson +

Others recommend sending a truncated HMAC; see RFC 2104, for example.
I don't know the details of the tradeoff, but Krawczyk et al include
at least one reference on the matter.

Ken