Subject: RE: FW: Exportable encryption & Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Fri, 6 Mar 1998 12:11:55 -0800

True. However, adding a mechanism to the AP request to negotiate an
encryption type would be useful both to upgrade the encryption type to a
stronger mechanism as well as downgrade it to a weaker mechanism.
- Mike

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Friday, March 06, 1998 12:05 PM
To: Mike Swift (NT)
Cc: [email-masked]
Subject: Re: FW: Exportable encryption & Kerberos

Mike Swift wrote:
> 
> Dropping this idea means that US vendors can't ship Kerberos outside the
> U.S. Are you asking us to write off 90% of the world population from using
> products implemented in the US? This is not an option - we have to find a
> solution.

Dropping this idea means that 90% of the world population will have
a much stronger incentive to use strong crypto, because it will be
much harder for (certain) vendors to spread interoperable weak crypto.

But the main point acutally is:  if those that currently have implemented
stronger crypto would have to add weak crypto to become compliant
and fully interoperable with an updated Kerberos 5 specification,
then this it is indeed a very bad idea.  

I'm sorry for having launched another round of "beating the dead horse".

-Martin

---

From: [email-masked] (Johan Danielsson)
Date: 07 Mar 1998 16:20:40 +0100

"Mike Swift (NT)" <[email-masked]> writes:

> encryption type would be useful both to upgrade the encryption type
> to a stronger mechanism as well as downgrade it to a weaker
> mechanism.

Not true. You can't ever upgrade an ongoing session to something
stronger (without involving the KDC). Why this is the case is left as
an exercise to the reader.

/Johan

---

From: Sam Hartman <[email-masked]>
Date: 07 Mar 1998 20:26:11 -0500

>>>>> "Johan" == Johan Danielsson <[email-masked]> writes:

    Johan> "Mike Swift (NT)" <[email-masked]> writes:
    >> True. However, adding a mechanism to the AP request to
    >> negotiate an encryption type would be useful both to upgrade
    >> the encryption type to a stronger mechanism as well as
    >> downgrade it to a weaker mechanism.

    Johan> Not true. You can't ever upgrade an ongoing session to
    Johan> something stronger (without involving the KDC). Why this is
    Johan> the case is left as an exercise to the reader.

	There might be some slight advantages for long-lived sessions
in terms of reducing the window in which a passive attack on the weak
key would be successful, but the benefits would be minimal.

	I would also like to point out that Kerberos already allows a
client to request a strong session key in the kdc_req message's etypes
sequence.  Even if it did add some real security to upgrade a
subsession key, I'm unconvinced that the additional complexity would
be worthwhile in the presence of a similar feature in the KDC exchange.

	I am somewhat concerned about interoperability if some vendors
go off and add fields to the end of the authenticator structure.  It
would make it difficult for the IETF to extend the structure in the
future, forcing a potentially unnecessary increase in the protocol
version number.
    Johan> /Johan