[Prev][Next][Index][Thread]
Re: Missing requirements
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
AoIzRz4VKUD++GN3kdx9vEIIQm2jFpC0YDEMdvSlrHs/leooIPAdI+lGPfgwsUoI
BUruSQt69rdwKDqvEOf4YWc=
Bennet Yee writes:
> In message <9605201546.AA01595@mordred.sware.com>, Charles Watt writes:
You missed the entire point of my message, which had nothing to do with
any specifics of our Hannah product. I will reiterate as succinctly
as I can that one point, and then address individual comments below.
THE POINT:
Integrating key management, authentication and data security
services into a single, in-band protocol is a BAD idea for a
generic transport layer security protocol. It effectively
eliminates architectures that are capable of providing higher
security and assurance. It also ensures redundant key management
facilities when other services such as IPSEC are deployed.
> >
> > .... 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"?
"Secure" is a relative term. The specific level of security that you need
will depend upon the specific application you are running and the value of
the service you provide. We provide security products for a wide range
of systems up to and including B-level (see
http://www.secureware.com/papers/secureweb/). The point again is simply:
"Can the protocol support high security, high assurance implementations?"
If not, it is not a suitably generic protocol. The current drafts of SSL
and PCT.
> > As an admittedly biased example, SecureWare's Hannah product
> > (see http://www.secureware.com/papers for a white paper and protocol
> > specifications) creates a secure system by providing transport
> > layer security for ALL network communications in a manner that is
> > transparent to the applications -- i.e., existing applications are
> > secured without modification. It then controls access to transport
> > layer networking (who can access which applications, what security
> > services must be enforced, which algorithms and key sizes must be
> > used, etc...) through ties to the system's underlying security policy.
> > Although a security-aware user or application can request specific
> > security services and algorithms, such requests cannot override
> > security policy.
>
> >From the white paper, it appears that Hannah "creates a secure system"
> only in the sense that it tries to mediate in all network traffic and
> provides some node management functionality. It is not multi-level
> security, obviously, since there's no data labelling and the node
> management functionality apparently provide basic, low level access
> control for network connections.
Yes, and on a B-level system this is pretty damn secure. On a standard
Windows/Unix platform it greatly enhances the security of the system by
providing very tight controls over who can access the system and what
services they can access.
>
> 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).
Like ISAKMP, PAKMP is a generic, higher level authentication/key management
protocol that is capable of implementing any specific cryptographic protocols
for authentication and key management. Thus the high level protocol is
described first. The specific cryptographic protocols that are supported
are described later.
From the currently known (published literature) set of cryptographic
protocols and algorithms, there are perhaps seven generic classes of
algorithms for key-exchange and authentication (e.g., D-H-like key
exchange plus signature, asymmetric encryption for both key exchange and
authentication plus keyed hash for PDU integrity, etc...) that could
conceivably be of interest, each offering different benefits/security.
Of this set we chose to implement three, as explained in the document.
Family C was not one of them, as is obvious from the document, in part
for the reasons you cite. This was stated on page 12, and was heavily
implied from the sentence immediately following the one you quote above
on page 13, which heartily recommends using a different Family.
>
> 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
... long dissertation on irrelevant protocol Family removed
> In any case, a clearer document that describes the protocols involved
> rather than a which-byte-goes-where document (which is more useful to
> an implementer than a cryptographer) would be nice.
There are two levels of protocols being discussed in the document:
1) Over-the-wire protocol, which, in fact, is described fairly well
in a top down manner. It describes bytes because that is its intent.
2) Specific cryptographic protocols used for authentication and
key exchange. The reason you found nothing about this for Family
C is that Family C was not considered appropriate for implementation.
Those families that were, A, D and G, are fully described. That is
why their sections are not listed as "TBD".
>
> I haven't looked at any of the other families A-G (or whatever the
> highest letter is); C just jumped out at me.
I'll try to make the document more clear about which of the protocol
families were deemed worthy of implementation.
>
> > In order to provide such pervasive security, Hannah implements
> > transport security services within the protocol stack. This can best
> > be achieved when there is clean separation between the actual transport
> > layer security protocol and its supporting key management and
> > authentication -- the approach taken by SDNS's SP4, OSI's TLSP, and
> > other previous attempts to "standardize" transport layer security.
>
> 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.
Porting is not a problem to any Unix or Winsock-based operating system.
The limited number of platforms supported in our beta release comes from
the fact that you've got to start somewhere. We started with the platforms
for which we had signed contracts to support.
>
> -bsy
>
> p.s.: the Hannah protocol description appears to be missing a
> requirement to verify that the cert matches the DNS name somehow. For
> web use, we wouldn't want a certified but malicious web server to be
> providing Web documents that are purportedly from e.g. SecureWare
> using DNS spoofing tricks and its own certificate(s), which the users
> (or users' Web browsers) would not be able to examine in a completely
> transparent scheme.
With the lack of security in the currently deployed DNS infrastructure
such a requirement adds little, if anything, to the assurance of a
certificate. Hannah's approach is MUCH stronger, restricting access to
users/hosts with certificates issued by trusted CA's. This is why Hannah
comes with a fully functional CA, so an organization can control the issue
of its own certificates and the structure of its trusted certificate
hierarchy. Its support for cross-certificates permits an organization
to build any trust model it wants, from a strict PEM-like hierarchy to
a free-and-easy PGP web.
Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
Follow-Ups:
References: