Re: Exportable encryption & Kerberos ?Date: Mon, 12 Jan 1998

[David Hemsath <[e-mail]>]

You might want to consider something less "US-Centric" for your proposal.  In a
recent Open Group meeting, several members from Europe brought up the fact that
other countries have their own sets of crypto import/export laws, so it's more
than just the U.S. Govt's regulations to deal with here.

The DCE community has been investigating the possibility of using the new
Common Data Security Architecture's (CDSA's) crypto facilities to enable DCE to
be shipped w/o a crypto engine for user data confidentiallity, and then hooked
up at installation with a local governing authority-approved crypto service
provider that plugs in "underneath" CDSA.  IBM and Intel both have CDSA
implementations with more than one crypto service provider.

David K. Hemsath, IBM DSS Security Strategy & Architecture

To: "Mike Swift (NT)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Exportable encryption & Kerberos 
Date: Tue, 13 Jan 1998 15:04:20 -0500
From: Bill Sommerfeld <[e-mail]>

The IETF is about engineering, not politics.  Crypto export control is
a political problem, not a technical one.

There's nothing to stop anyone outside the borders of the US from
implementing full-strength crypto, and there's nothing which requires
folks outside the US to buy their crypto from inside the US.

Therefore, there's a workaround to the political problem which doesn't
require weakening the strength of the protocols; the export control
laws only really affect the profitability of US companies.

I object to any attempt to weaken the (already overly weak) crypto in
Kerberos.

						- Bill

To: "Mike Swift (NT)" <[e-mail]>
Cc: [e-mail]
Subject: Re: Exportable encryption & Kerberos 
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Tue, 13 Jan 1998 15:06:40 -0500
From: Ken Hornstein <[e-mail]>

>> encryption. Both these possibilities require new encryption types, and the
>> AP request structure does not allow for easy negotiation of what
>> encryption types are supported.

Could you elaborate on this more?  It seems like Section 3.2.6 of the
latest revision will do what you want ... am I missing something?
(Entirely possible :-) ).

On further reflection, I think I understand what you mean ... you can
only propose one key in the subkey field of an AP_REQ, which kinda limits
your choices.

Maybe the thing to do is make the AP_REQ have an optional list of
enctypes for the server to choose from?

The only thing I don't like about your proposal is the use of "domestic"
vs "exportable"; as someone else pointed out, this is pretty US-centric.
And what do you do if the law changes? :-)

--Ken