Subject: NULL etype removed by clarifications?

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Dec 2003 04:14:52 +0100

Where did the NULL encryption algorithm go?  I.e., RFC 1510 section
6.3.1.  I have a use for it, so I'd like for it to remain in
clarifications.  With proper warnings and precautions, of course.

Thanks,
Simon

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 18 Dec 2003 02:39:22 -0500

> clarifications.  With proper warnings and precautions, of course.

All of section 6 (the crypto stuff) moved out into the crypto draft.

What sort of use have you got for it?  When working on the crypto i-d, 
all we could come up with was debugging an implementation, for which 
local-use numbers or zero (if the implementations chose not to reject 
the "invalid" value) would seem to work okay without standardization...

Ken

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Dec 2003 12:20:15 +0100

> the "invalid" value) would seem to work okay without

Interoperability testing between implementations is one use, although
I believe backwards compatibility with RFC 1510 is sufficient
motivation for keeping the definition in the crypto clarifications.
Implementing private use encryption algorithms in all implementations
you want to interop test with can be tedious, and sometimes impossible
for proprietary implementations.  Doing interop testing with encrypted
packets is of course possible, but I've found that being able to use
tcpdump on the ASN.1 packets directly can be useful.  Compare the
TLS_NULL_WITH_NULL_NULL algorithm for TLS, which is useful for the
same reasons.  Another motivation is self tests; many existing
encryption algorithms add a random confounder that make the output
difficult to check against test vectors.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Dec 2003 10:49:41 -0500

In practice people don't implement the null encryption type in the
existing implementations and manage to do interop testing and
debugging adequately.

The draft in question has already been sent to the IESG and has
already exited IETF last call.  It does not sound like you have a new
issue here; it sounds like you have an issue that the WG already
discussed previously.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 19 Dec 2003 06:01:30 +0100

> issue here; it sounds like you have an issue that the WG already

Sorry, I only found previous discussion, and agreement on, removing
the null checksum type (which was never part of 1510), not the null
encryption type.  Browsing the mailing list archive, I could only find
the following regarding the null etype.  It may be referring to
ancient implementations, but it suggest null is implemented and even
used.  The implementation note in section 3.6.1 of clarification seem
to refer to null etype as "unencrypted" now.  I understand it may be
poor timing to bring this up now, and I don't claim the issue is new,
but I didn't discover it earlier.  A pointer to the previous
discussion on null etype you mentioned is appreciated, and would
settle my question.

From: "John Brezak" <[email-masked]>
Date: Thu, 28 Feb 2002 17:43:46 -0800

5) Section 3.6.1 - To remain compatible with MIT and Heimdal, the
encrypted part of the KERB-CRED message in a GSSAPI initial context
token is encrypted with the null enctype. Microsoft does use the null
enctype when either des-cbc-crc or des-cbc-md5 is used to retain compat
with other implementations. For rc4-hmac, the encrypted part of the
kerb-cred is encrypted with rc4-hmac.

Thanks,
Simon

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 19 Dec 2003 00:28:11 -0500

Most of the discussion I recall concerning the null enctype, once we 
started the crypto framework discussions, was as a sort of placeholder 
so that unkeyed checksum types would have an encryption type associated 
with them.  I don't think any of us particularly wanted implementations 
to have a null enctype once they got deployed; accidentally turning it 
on and throwing away all security seemed like too big a risk.

I don't think any of these early discussions were public; this would've 
been among those of us working on the initial crypto framework spec -- 
me, Sam, Tom, Jeff H, etc.  As for actually removing the null enctype, 
and including unkeyed checksums, between the -02 and -03 drafts, I 
don't remember if that discussion was public or not...

Ken

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Dec 2003 07:54:03 -0500

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> checksums, between the -02 and -03 drafts, I don't remember
    Ken> if that discussion was public or not...

I'm not sure if the discussion was public but I believe the WG was
notified of the change.