Subject: RE: Exportable encryption & Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Tue, 20 Jan 1998 12:31:22 -0800

As an alternative, we could extend that AUTHENTICATOR by allowing the subkey
to be a sequence. This would allow the client to propose a list of subkeys
and allow the server to select a subkey to return in the AP reply. This
would allow the introduction of new encryption types of various strengths.
The client can propose keys for the various encryption types it supports (if
it was weakened, then only weak encryption types) and the server could
select an encryption type it considered acceptible. This requires that the
client do mutual authentication and ask for an AP reply, though.

Authenticator ::=    [APPLICATION 2] SEQUENCE    {
               authenticator-vno[0]          INTEGER,
               crealm[1]                     Realm,
               cname[2]                      PrincipalName,
               cksum[3]                      Checksum OPTIONAL,
               cusec[4]                      INTEGER,
               ctime[5]                      KerberosTime,
-->            subkey[6]                     SEQUENCE OF EncryptionKey
OPTIONAL,
               seq-number[7]                 INTEGER OPTIONAL,
               authorization-data[8]         AuthorizationData OPTIONAL
                     }

- Mike
> -----Original Message-----
> From:	Ken Hornstein [SMTP:[email-masked]]
> Sent:	Monday, January 19, 1998 10:13 PM
> To:	Mike Swift (NT)
> Cc:	[email-masked]
> Subject:	Re: Exportable encryption & Kerberos 
> 
> >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.
> 
> 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: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 20 Jan 1998 22:08:53 -0500

From: "Mike Swift (NT)" <[email-masked]>
   Date: Tue, 20 Jan 1998 12:31:22 -0800

   As an alternative, we could extend that AUTHENTICATOR by allowing the subkey
   to be a sequence. This would allow the client to propose a list of subkeys
   and allow the server to select a subkey to return in the AP reply. 

This won't work, because the result will be completely incompatible with
existing implementations, that won't be expecting an ASN.1 sequence
there.

					- Ted