Subject: Some Text on Security

From: Bob Mahoney <[email-masked]>
Date: Thu, 25 Mar 1999 19:04:14 -0500

First, a mild disclaimer:

The whole area of "Security & Standards" is seriously intricate. 
Unless you are a lawyer, a developer, *and* a cryptographer, you're 
probably confused about some aspect of all this at some point.  I'll 
state right up front that I'm not any of these things.  But I know 
clever folks from each category, and I'm very interested in the 
field, so I've tried to absorb a working understanding of the issues. 
If you think I have something wrong, speak up, and we can hunt for 
verification/refutation...

I haven't been able to find any recent applications that have passed 
IESG review that can give us any real guidance.  There appear to be a 
number of folks just about where we are, but no one far enough ahead 
of us to be a useful model.  (I'm still looking, though)

Now, the IESG has made it clear that plaintext passwords are an 
unacceptable security mechanism.  So whatever we need to do will 
involve some cryptographic mechanism.

The US Government imposes significant restrictions on the export of 
strong cryptography from the US.

The  IESG has also stated that the IETF is an international 
organization, so legal restrictions in individual countries are not a 
relevant factor in creating internet standards.

You can see where this is going...  :-)

Things are not exactly as dire as they were when we started working 
on the calsch documents.  56-bit DES encryption ("Data Encryption 
Standard") is now becoming generally exportable from the US.  You 
don't have to escrow the keys with the government, either.

Of course, a lot of press in the past year has made it clear that 
56-bit DES is pretty weak in today's world.  It has proven to be 
breakable at increasingly low price points, most notably with the EFF 
"Deep Crack" effort.  A lot of people are scrambling to improve their 
products using 56-bit DES, frequently with triple-strength DES 
("3DES").  There was a general sentiment at the Security Area 
Advisory Group meeting in Minneapolis that DES just didn't cut it any 
more.

However, 56-bit DES *does* meet the IESG "no plaintext" test.  There 
would seem to be some event convergence here that might be useful for 
our efforts.

Bruce Kahn mentioned the possibility of SASL  ("Simple Authentication 
and Security Layer", RFC 2222), calling TLS  ("Transport Layer 
Security" RFC 2246).  There seemed to be some confusion as to whether 
this would be possible.  SASL (an ASCII protocol), can issue a "start 
tls" command, after which the stream becomes binary, and is encrypted 
with a TLS crypto algorithm.

So this seems possible.  And it would certainly be attractive to 
vendors to go this route.  (Because once you're moving over a TLS 
negotiated stream, you can do all the things your code used to do, 
like plaintext passwords, because the whole stream is now encrypted) 
However, it looks like the mandatory cipher for TLS is 3DES. So for 
the US vendors, this could be headaches still. (someone correct me 
here if I'm misreading this)

The puzzle ahead of us is to pick some standard that we can reference 
for a mandatory cipher.  I think that for some parts of our work, 
like the store and forward documents, S/MIME and or OpenPGP are 
useful routes to take.  (See that IPJ article for a good overview of 
the issues)

By the way, for any of you that weren't around the last time we took 
a whack at this, the security features *must* be in compliant 
implementations, but it's perfectly acceptable for them to be 
disabled by end-users.  (actually, the IESG makes no statement about 
the default setting for such features to my knowledge, on or off, but 
I assume they will expect it to be something reasonable for the 
application involved)

That's all the typing I have in me at the moment.  Any questions thus far?

-Bob

---

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Mon, 29 Mar 1999 18:29:38 -0800

The only part of SASL that is actually TEXT is the SASL package identifiers.
Other than that, SASL allows its payload to be transmitted over ANY
mechanism.  For example, the LDAP authentication RFCs use SASL on an ASN.1
protocol.

I suspect that SASL is a MUST implement for the calendering protocols, the
only issue is really what SASL mechanisms are mandated as manditory, and I'd
guess that the HTTP-DIGEST authentication mechanism is the most likely
choice for a must-implement mechanism.

I care VERY strongly about requiring SASL, I think it's going to be required
for all new application protocols.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

-----Original Message-----
From: Bob Mahoney [mailto:[email-masked]]
Sent: Thursday, March 25, 1999 4:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: Some Text on Security

-Bob

---

From: Doug Royer <[email-masked]>
Date: Mon, 29 Mar 1999 18:46:16 -0800 (PST)

> From: "Larry Osterman (Exchange)" <[email-masked]>
> Date: Mon, 29 Mar 1999 18:29:38 -0800
> 
> only issue is really what SASL mechanisms are mandated as manditory,

I agree 'I' think that SASL is a MUST.

>    and I'd

Why? - as in "Sell it"

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL