Subject: RE: Draft minutes, Adelaide CAT session

From: Tony Andrea <[email-masked]>
Date: Mon, 10 Apr 2000 09:53:15 -0700

cybersafe has not agreed to do key derivation. there is
little to no advantage in doing so.  microsoft and cybersafe
have tentatively agreed to implement des3-cbc-sha1 (etype 7),
with no key derivation.  cybersafe also supports des3-cbc-md5
(etype 5).  

later,
tony.

> -----Original Message-----
> From: Assar Westerlund [mailto:[email-masked]]
> Sent: Sunday, April 09, 2000 9:55 AM
> To: 'CAT-WG List'
> Subject: Re: Draft minutes, Adelaide CAT session
> 
> 
> "Linn, John" <[email-masked]> writes:
> > Updates since the last revision include integrated 3DES options, new
> > registered types, and various edits, some of which require 
> discussion.
> > Cliff reported that the current 3DES description integrates 
> all options in a
> > single parameterized discussion, but that it references 
> currently expired
> > drafts and material must therefore be adapted from them.  
> List discussion is
> > needed to resolve whether or not to use the key derivation 
> variant; Cliff
> > reported that Microsoft and CyberSafe have tentatively 
> agreed to accept key
> > derivation, though that some skepticism was observed about 
> its value.
> 
> I would think it a really bad idea having tow different kinds of 3DES
> in the spec.  And since, as I'm lead to believe from the minutes,
> everybody agrees on using 3DES with key-derivation, I propose that we
> just keep that in the spec, of course letting the assignment of the
> etype to the old 3DES stay.  Any comments?
> 
> /assar
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 10 Apr 2000 15:00:29 -0400

From: Tony Andrea <[email-masked]>
   Date: Mon, 10 Apr 2000 09:53:15 -0700

That's interesting; that's not what Cliff Neumann reported at the CAT
working group meeting in Adelaide, and given that he's a Chief Scientist
at Cybersafe, I thought he was speaking authoratatively.

						- Ted

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Assar Westerlund <[email-masked]>
Date: 11 Apr 2000 02:12:48 +0200

Tony Andrea <[email-masked]> writes:
> cybersafe has not agreed to do key derivation.

Ok, sorry if I was implying something that was not true.  I got that
impression from reading the minutes (I wasn't in Adelaide).

> microsoft and cybersafe have tentatively agreed to implement
> des3-cbc-sha1 (etype 7), with no key derivation.  cybersafe also
> supports des3-cbc-md5 (etype 5).

I really think it's un-optimal there being one 3DES variant used by
MIT-Heimdal and another by Cybersafe-Microsoft.  Don't you?  How can
we try to resolve this?

You said earlier that there was `little to no advantage'.  Is there
any disadvantage to doing so?  Other than a little bit of more code.

/assar

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Apr 2000 17:24:42 -0400

I've been largely ignoring CAT for a while, but I'll butt in here
since I was around for some of the early discussions of key
derivation.

Key derivation was designed to eliminate one of the cryptographic
"sins" from the original kerberos design: namely, the use of a single
key with multiple algorithms for multiple purposes.  If you assume the
algorithms you're using are perfect, this doesn't add any real
strength, but well, we're living in the real world, and the algorithms
aren't perfect, so you do key derivation to add a margin of safety.

For the most part, we here in CAT-land are plumbers who use
cryptography, not cryptographers.  When real cryptographers have
things to say, and say them strongly, we should listen to them.
I believe it would be unwise to discard their contribution.

I'll go back to lurking now..

						- Bill

---

From: David Margrave <[email-masked]>
Date: Tue, 11 Apr 2000 16:03:25 -0700

I wasn't at adelaide, but as a user (not an implementer) I can say that
microsoft&cybersafe being non-interoperable with MIT&Heimdal in this regard
would be very disappointing.   What choice do I have for interoperable
etypes > 56 bit DES?  Microsoft uses RC4-HMAC which nobody else supports,
Cybersafe uses 3DES without key derivation which nobody else supports to my
knowledge.

---

From: Assar Westerlund <[email-masked]>
Date: 12 Apr 2000 12:11:34 +0200

> Cybersafe uses 3DES without key derivation which nobody else supports to my

I've started implementing RC4-HMAC but haven't gotten anything that
interoperates with w2k yet.  And if Microsoft and/or Cybersafe starts
using 3DES without key-derivation we'll add it in Heimdal to be able
to interoperate with them, but I would prefer that everybody plays the
same 3DES game.

This is getting off-topic for the CAT list, so please move it over to
the Heimdal mailing list for further implementation-discussions.

/assar

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 13 Apr 2000 21:12:39 -0700

SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP

The Authentication, Authorization and Accounting (AAA) Working
Group of the Internet Engineering Task Force is currently
soliciting submission of protocols for authentication,
authorization and accounting as applied to network access.

Submissions are being solicited effective immediately. 
Authors of candidate protocols are required to notify 
the AAA WG chairs, Bernard Aboba <[email-masked]> 
and Paul Krumviede <[email-masked]> of their intent to 
submit a candidate protocol. It is desirable that 
this notification be sent by May 1, 2000.  

Protocol submissions and compliance description 
documents are to be submitted in Internet Draft 
format by email to [email-masked]. The
deadline for submissions is June 1, 2000. 
To be considered as a candidate, submissions must 
include an unqualified RFC 2026 statement,
as described at: http://www.ietf.org/Sec10.txt

Information on the Internet Draft format is available at:
http://www.ietf.org/ietf/1id-guidelines.txt

The compliance description document must explain on
a detailed requirement-by-requirement basis how
the submitted protocol satisfies the AAA network access
requirements. The requirements are available for inspection
at:

http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.txt
(or later version). 

The protocol submission and compliance description documents
will then be used as the basis for an independent evaluation.
Based on the results of the independent evaluation, the working group
will decide whether one or more submissions meet the requirements
sufficiently to become the basis of the subsequent design phase,
or whether it is necessary to design a protocol from scratch.

In the protocol development process, it is to be understood
that the IETF does not function as a rubber stamp. A protocol,
if accepted, will likely be changed significantly
during the process of development.

Authors of candidate protocols must be willing to give
up change control to the IETF, so as to allow modification
of the candidate protocols to AAA WG needs.

For further information on the IETF AAA WG, including working
group drafts and milestones, please consult the working group
web page at:

http://www.ietf.org/html.charters/aaa-charter.html