Subject: RE: Exportable encryption & Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Mon, 19 Jan 1998 15:23:47 -0800

I am very open to other suggestions on how best to implement weakened
encryption in Kerberos. I proposed a solution that is of limited scope but
will work. If anybody else has other concrete suggestions I would very much
like to hear them.

- Mike

> -----Original Message-----
> From:	Richard Salz [SMTP:[email-masked]]
> Sent:	Saturday, January 17, 1998 6:24 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked]; Mike Swift (NT)
> Subject:	Re: Exportable encryption & Kerberos
> 
> > An Informational RFC on 40 bit
> >Kerberos V5 privacy would be useful for that reason.
> 
> If the members of the IETF decide it's useful to standardize emasculated
> crypto to ensure interoperability, then I hope we'll all be very blatant
> and define things such that the "naught bits" (n>41:) are sent in the
> clear
> by the protocol(s) in question.  In no way should this be sugar-coated.
> 	/r$

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 20 Jan 1998 01:12:53 -0500

>will work. If anybody else has other concrete suggestions I would very much

Okay, politics aside:

- The binary values of "strong" and "weak" bother me.  Not enough room for
  expansion or adaptation (what if X version of Kerberos implements
  "weak", circa 1998, but Y implements "weak" circa 2002?).  I really
  think these should be new encryption types.
- I still think that a general framework for negotiating encryption
  types in an AP_REQ would be useful, for a number of reasons (for
  example, when 3DES gets into MIT Kerberos, I'd like to be able to
  use it as quickly as possible, but not have to upgrade all of
  our application servers).  I know, this is tricky ... but I still
  think it's solvable.

--Ken

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Jan 1998 14:05:33 -0800

(deleted stuff)

> Okay, politics aside:
 
(deleted stuff)

>   our application servers).  I know, this is tricky ... but I still

If negotiation is required, the question is where to perform the
negotiation: either within Kerberos or using SNEGO, which means outside
Kerberos.

I would recommend the use of SNEGO (soon to be closed) which allows to
negotiate all Kerberos flavours as soon as you suffix the Kerberos
mechanism with some identifier.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 20 Jan 1998 13:01:41 -0500

>negotiation: either within Kerberos or using SNEGO, which means outside

Oh, sure ... I was putting off reading the SNEGO draft, but now you're
making me do it! :-)

Well, I had understood that SNEGO was for the GSS-API.  It would be
nice if we could have something that would work for non-GSS apps (i.e. -
telnet).  Or are you talking about applying the general negotiation
to that SNEGO does to "raw Kerberos" as well?

--Ken

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Jan 1998 21:39:06 +0100 (MEZ)

> mechanism with some identifier.

I strongly recommend NOT to use SNEGO but define some QOP handshake and
default to the "strongest" algorithms from this handshake.

This is much easier to handle for the application -- since the app isn't
actually bothered with it -- especially when all other "characteristics"
remain unchanged, like:
   - namespace
   - number of message exchanges for context establishment
   - availability of message integrity
   - availability of message confidentiality

When an application offers provisions to deal with gssapi mechanisms
of completely different nature (X.500 DNs and such), it tries to recognize
them by mechanism OID, and if you change that all the time, it will become
a real pain to update and maintain such mechanism OIDs in the application.

SPNEGO may be useful to select among a bunch of completely different
mechanisms with completely differing mechanism OIDs as part of
an infrastructure  (SPKM, Kerberos5, DASS(rip), MS-NTLM, ...).
which includes a standardized mapping between the differing native
namespaces.

-Martin

---

From: Tatu Ylonen <[email-masked]>
Date: Wed, 21 Jan 1998 03:48:26 +0200 (EET)

> will work. If anybody else has other concrete suggestions I would very much

If I've understood right, Kerberos (the version distributed by MIT)
only implements weak encryption (i.e., single DES).  If this is no
longer the case, why not just revert to the single DES method used
earlier?  Single DES is demonstrably breakable even by groups of
amateurs on the internet.

Or do you want something that is so weak that it can be broken by
individual university undergraduates?  What would be the point of
using encryption that is so weak?  It would no longer protect
passwords or other data.

There is also a Kerberos implementation freely available from Sweden
that supports both DES and 3DES.  If you cannot export, why not just
use that?

Best regards,

    Tatu

-- 
SSH Communications Security	      http://www.ssh.fi/
SSH IPSEC Toolkit		      http://www.ssh.fi/ipsec.html
Free Unix SSH                         http://www.cs.hut.fi/ssh/