[Prev][Next][Index][Thread]
Re: Missing requirements
In message <9605222126.AA04598@mordred.sware.com>, Charles Watt writes:
> [ separation into two protocols ]
>
> This is only common sense and good protocol design. It certainly isn't
> "spec'ing out a fully generic, do everything protocol" and doesn't mention
> signing every packet. I've no idea where you came up with that.
I mentioned non-repudiation because you pointed me to Hannah as what
is good. I looked at Hannah and saw non-repudiation that as one of
Hannah's optional specs.
While separation into two protocols may be "common sense" most of the
time, we do have to be careful that the separation does not break the
links in trust between the keys from the key exchange/management
protocol and the data privacy/integrity protocol.
As a somewhat contrived / degenerate example, a dual protocol approach
where the key management subsystem can be fooled into installing a new
key that was exchanged with user A for an existing channel to user B
would allow A to eavesdrop on the traffic to B (at least until B
complains).
> Of course they dictate system design. There is no way to implement either
> one except by bundling them together over the same communication channel.
> They should be designed to support both in-band and out-of-band key
> negotiation so that they can support datagram-based services and higher
> assurance implementations. This is not difficult to do, and the current
> versions of SSL and PCT could be easily modified to meet these requirements
> much like Hannah (NDSEP/PAKMP), IPSEC (IPSEC/Oakley), SP4 (SP4/KMP) and
> other similar systems.
Both SSL and PCT send records down a pipe. At the -cryptographic-
-protocol- level, it matters naught whether that pipe is a single TCP
connection or two or three. The security of the protocols don't
depend on this -- that is necessarily so, obviously.
At the actual transport level, of course, a decision has to be made
how those records actually get there. This is independent of the
crypto-protocol design. If we decide to shuffle those records and
send them over N different TCP connections, that's fine -- as long as
we can put them back together again in the right order. Now, if what
you're really pushing for is a centralized security server that
maintains one key management channel open and uses it to setup keys
for several different channels (i.e., hierarchical key management
layer; one public key operation for the key management channel; key
management channel's longer key is used to distribute the shorter data
channel keys), that's a slightly different different story. Or if you
want to permit a trusted third party to hand out keys (more Kerberos
style), then, yes, this won't work; on the other hand, I don't think
we'll need to worry about something like this coming out of IPSEC or
other groups.
The real difficulty with datagram-based services is that channel
ciphers have state (DES CBC chaining variable, RC4 stream state, etc),
and datagram support require either reliable datagrams or a new set of
keys per datagram (in an extra header). To directly modify SSL or PCT
to send the data records over UDP by just having in-band or
out-of-band key negotiation doesn't work: when each UDP datagram has
per-datagram keys/iv in its header, it's very different from either
in-band or out-of-band key negotiation. And if you have reliable,
in-order datagrams, you didn't really need any changes.
Now, you are right that there are other ways to make dual channel (key
mgmt vs traffic) work better. And I wouldn't mind seeing datagram
based services being supported if it wasn't too messy either.
However, the TLS charter is for transport level security (TCP), not
network level security (UDP/IP), so we should definitely weigh
carefully the extra complexity overhead against the expected benefits
(or change the charter).
As to whether we should make the TLS protocol by default permit both
in-band and out-of-band key exchanges, I think that that might be just
unnecessary complications. Certainly cipher-spec negotiations are
complicated enough; why add extra negotiation as to over which channel
the keys should be exchanged? Certainly with the primary consumer of
the TLS protocol being web browsers (and maybe a few telnet sessions),
the extra complexity doesn't seem to buy much. What's the benefit to
pay for the extra complexity?
Maybe in a Hannah-like environment where machines can have long-lived
interactions and there is a requirement for mandatory security policy
enforcement, having a per-machine centralized security server handle
all key management functions (to enforce key lengths and/or escrowing
as well as amortize the public key overhead better) over its own
channel is nice. I can certainly see how a separation would benefit
this scenario. But as far as I know such long-lived interactions has
not been a focus of this WG. Should it be?
> There are several problems with linking authenticated identity with
> DNS names:
>
> 1) A domain name contains little meaningful information about the entity
> with which it is associated. They are handed out first come, first
> serve. If a customer connects to www.llbean.com, are they connected
> to the famous mail order company or an imposter?
This policy regarding issuance of domain names is changing, but
regardless you're missing my point. See below.
> 2) Because DNS is insecure, an attacker can, at least within an isolated
> region, assume any domain name they choose. If they can convince any of
> the standard CA's supported by Netscape that they are www.netscape.com,
> or convince the user to accept a new CA, then they are netscape.
>
> 3) Do you suggest similar rules for client certificates? If so, it is
> unreasonable for me to be identified as watt@sware.com if I am also
> watt@mindspring.com and watt@directpc.com. If not, then the protocol
> is worthless for many applications such as banking where it is perhaps
> more important to identify the client than the server.
I have not mentioned client certs. If you need a cert that says you
are watt@{sware,mindspring,directpc}.com, that's fine. Whether the
a cert should have multiple names or whether multiple certs are needed
is still something that needs to be thought out. For -some-
applications, host-independent mobile certs is appropriate; not so for
others.
> My own opinion on this matter is that resolving authenticated name to
> DNS name is a non-issue. Who cares what domain name L.L. Bean uses for
> their server as long as I am sure I am talking to L.L. Bean when I place
> my order. Establishing this assurance cannot be achieved by linking
> the certificate name to the domain name. I would prefer to encode
> additional identification information in the certificate extension fields,
> which can be verified by the CA during certification and displayed in
> convenient, human readable format. But what ever scheme is chosen, the
> crux of the trust issue boils down to whether or not you can trust the
> other guy's CA to properly identify and register those entities that
> it certifies.
I'll give an example as to why the DNS namespace and the certificate
namespace needs some kind of linking.
Scenario: user sees a TV or a magazine ad. The ad says to connect to
http://foobar.com. It doesn't matter whether it says LLBean or not.
The user expects that if s/he connects to that site with his/her
browser, s/he is visiting the site that placed the ad. The user knows
that the real, full name of the company is "Froobnitz Inc".
The certified namespace may very well say -- in the certificate --
that the entity that posesses a certain private key is "Froobnitz
Inc". It should. We can not, however, always expect the user to
actually look at the cert. Nor could we expect the user to
communicate to the browser the name "Froobnitz Inc" -- getting them to
type in a URL is enough already.
How does the user know, when s/he see the order form, that s/he is
really talking to "Froobnitz Inc"? S/he has to check the cert. That
seems to be your preferred approach. Now, maybe we can automatically
pop up the cert and force the user to click it away whenever s/he does
a POST operation. Any Human-Computer Interface person will tell you,
however, that this will become automatic very quickly, and there would
be very little security benefit in practice. (And there are other
security-relevant scenarios sans POSTing.) And the attacker would end
up with the user's credit card number.
Can we solve this problem at the protocol level? Of course not. Can
we make some kinds of automatic checks feasible to make such an attack
less likely? Yes we can, by having CN checks. (Even with checking IP
addresses, lower IP-level spoofing [rather than DNS level] can still
cause trouble -- the CN checks is just an extra band-aid.) And no,
I'm not saying to get rid of nice, human readable stuff -- by all
means retain that as well, and display it to the user if possible.
The issue does *not* boil down to trusting the CA. It's more complex
than that and requires a more holistic approach -- what it does boil
down to is that we don't trust the users to not shoot themselves
through negligence. While for non-MAC systems we can't really -force-
the users to behave securely (nor A or B level systems, but...) we can
try to aid the users as much as possible. If we don't, I think we're
doing a bad job -- look, we've designed this unpickable lock; oops, we
have to leave the windows open.
> But this is not a protocol issue and this is not the forum for deciding
> such issues.
Maybe it isn't a protocol issue. DNS was not a Java security issue
either. We should be aware of the potential problems and at least
think about hooks in the protocol or overall system design where we
can attach partial solutions if not complete solutions. Even though
it's not a protocol issue, it would nonetheless be embarrassing to
have security problems arise due to this non-issue when our security
protocol was in use.
> > To provide security with application transparency, after the
> > authentication protocol runs -- which authenticates in the certified
> > namespace -- the implementation should try to make sure that the name
> > supplied by the user -- which is a DNS name or a raw IP address -- has
> > something to do with the authenticated peer.
>
> How does this work with mobile IP?
It does not work with mobile IP. Never claimed that it did. The
common scenario that I am addressing is server auth. Web servers tend
not to use mobile IP.
This mailing list sure suck down too much time.
-bsy
--------
Bennet S. Yee Phone: +1 619 534 4614 Email: bsy@cs.ucsd.edu
Web: http://www-cse.ucsd.edu/users/bsy/
USPS: Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114
Follow-Ups:
References: