Re: Missing requirements

> Date: Tue, 21 May 1996 19:53:57 -0700
> From: Bennet Yee <bsy@cs.ucsd.edu>
> 
> In message <9605201546.AA01595@mordred.sware.com>, Charles Watt writes:
> > 
> > ....  The group's focus seems to be "let's slam something together 
> > ASAP so all of our browsers will interoperate, and maybe what we wind up 
> > with will also be useful to other applications".  Although I too would 
> > like to see security deployed ASAP, I find this approach short sighted.  
> > In order to truly support electronic commerce applications, we shall 
> > need secure systems, not just secure applications.  
> 
> To build secure systems, we would need to do a lot more work.  Do you
> mean Orange Book B level at least?  I doubt that you meant to replace
> Windows / MacOS / Unix with an alternative OS.  In this context, what
> do you mean by "secure system"?

I believe the issue is not whether the platform / OS (it's not just
an OS question) will be replaced with something "secure", it is whether
an IETF-standardized protocol should be designed in such a manner as
to facilitate the development of secure systems, as opposed to relying
on each separate application to design and incorporate it's own security.


> I briefly looked at http://www.secureware.com/papers/pakmp/pakmp.ps,
> and have some questions.  It is a 65 page document that dives quickly
> into the layout of the packets and does not seem to include a high
> level description of the cryptographic protocols used.
> 
> On page 13, it states that Family C "provides key management using
> Diffie-Hellman", and that "authentication is achieved by having each
> side encrypt a nonce with the public key of the peer and having the
> peer return the decrypted value."  Presumably with RSA, since that
> paragraph mentions RSA later, and presumably the nonce, both
> RSA-encrypted and not, are actually sent over a channel encrypted with
> the key derived in the D-H exchange.  Later sections that I found on
> Family C had only "TBD" (4.4, pg 46).
> 
> Now, this sort of authentication is subject to a man-in-the-middle
> attack, unless the D-H keys are somehow certified and the RSA
> certificates are linked to the D-H certificates.  This is a very
> important requirement that does not seem to be stated anywhere.
> Now, pg 22 mentions PKCS3, so it does not appear that you're using
> the pair-wise fixed keys scheme but rather D-H with global p,g to
> obtain a shared secret the value of which neither side controls.

Regardless of whether Hannah's *implementation* of D-H is subject to
MITM attacks, D-H can be designed to resist known protocol attacks.
See, for example, the draft ANSI X9.42 - 1996 "Establishment of
Symmetric Algorithm Keys using Diffie-Hellman", available from the
American Bankers Association.

But critiqueing the specific protocols used by Hannah is focusing on
the trees and ignoring the forest.  The big issue is whether the session
key establishment (or Security Association management) protocol should
be cleanly separated from the traffic protection protocol.  Both Hannah
and IPSEC provide entirely separate protocols for key management and
traffic protection; SSL and PCT provide partial separation by having a
"Record Layer" distinct from the "upper layers" (handshake, alert,
cipherspec, and application-data).

The key point is that the traffic protection code (Hannah's NDSEP,
IPSEC's AH and ESP, SSL's record layer) is relatively small and easy
to implement, (although it must be carefully designed).  It can be
built into each application, or be stuffed into the network stack
and shared by all applications, whichever you prefer.

But the key management protocol (Hannah's PAKMP, IPSEC's ISAKMP) is
big, complicated, and requirements are rapidly evolving.  It makes
sense to fully de-couple the two protocols so that:
 1) a single KMP can be shared by all network layers - IP,
    transport, and application,
 2) evolution in key management technology can be accommodated
    without replacing all the software that has it hardwired in, and
 3) each application can be a *lot* smaller.

How much of the code in Netscape Navigator or MS Internet Explorer
is dedicated to web browsing, vs. the amount dedicated to handshaking
and certificate management?  The latter is just overhead, and the
more flexible it becomes, the more the code bloats.


> Maybe Microsoft wouldn't care (;-), but Hannah's implementation -- as
> described in the white paper -- requires in-kernel modifications on
> Unix hosts (Hannah is only available HPUX and SCO -- for Windows
> Hannah takes over the Winsock DLL to control the network connections).
> This is contradictory to one of the (perhaps implicit) goals of being
> usable on all popular systems.  Granted, the Hannah protocols may be
> implemented as a user-level library just like SSL/PCT/etc, but in that
> case the advantage of being pervasive (and thus can handle all network
> connections by mandate) disappears.

Modifying the network stack on Unix hosts only requires kernel
modifications (and source) if you're using an obsolete Unix.  If
the kernel uses Streams networking (Solaris, for example) the
application can just push another Streams module onto the stack.

As mentioned above, it doesn't really matter if the Record Layer
code is built in to the application or the stack - it isn't that
large.  If it isn't in the stack, you can't force all applications
to use it, but it's a lot easier to build applications that do.

I strongly recommend that the TLS working group define separate
protocols for traffic protection and key management.  As Mr. Watt
pointed out, it's not necessary to wait for IPSEC to standardize
ISAKMP/Oakley before getting products to market, we just need to
make the TLS handshake protocol (whatever it turns out to be)
pluggable.

Received on Wednesday, 22 May 1996 11:09:27 UTC