[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea: Prizes for protocol problems in key agreement
> Designs that invalidate Key Escrow (in otherwords, escrow me all you want,
> it does no good)?
I'm not sure what you mean by this.. (use of ephemeral unescrowed DH
keys and session keys along with escrowed long-term signature keys?)
> Is this possible? It seems that man in the middle attacks are all that is
> left to Key Escrow for some of these?
Either that, or individual transforms which escrow the session key
actually used..
> Is that adequate? If the key escrowers see that they have to launch man in
> the middle attacks to see anything is this raising the cost enough to vastly
> limit its use?
Well, the protocol had better be immune to MITM attacks, at least
assuming there's a trustable certification path between the parties..
I see that as being covered by several of the problems in John's
original list.
"Revealing session keys or parts thereof to observers or attackers"
"Designs that are trivial to circumvent or bypass"
"Enabling session keys to be forced to known or partly-known values"
I'll add one more of my own:
"Failure to provide perfect forward secrecy for user
identities (if user keying is involved)".
which is, of course, a slightly stronger form of the existing:
"Revealing user identities to observers (if user keying is involved)"
- Bill
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5476.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 7:16:18 EDT
Seems reasonable to me, too. I remember Phil Karn espousing this view
repeatedly over the past years, whenever user-oriented keying came
up.... I thought that we had general consensus on this (except for our
WG chairs). I wish that we could get "official" recognition of this
position, too.
For the great class of usage, firewall to firewall tunnels (where only
network origination is authenticated), or laptop to firewall, IP
"network-layer" security easily handles those needs. The "user" or
"principle" or "party" maps nicely to the IP address.
For single-user laptop to multi-user host, the host software can avoid
application and API changes if the admittance can be managed by the host
kernel. The "user" maps nicely to the IP address plus SPI combination.
For multi-user host to multi-user host, with mutually suspicious users,
and/or multi-level security handled in a single session, and/or firewalls
attempting to authenticate user origination, major changes are needed to
the applications, APIs and to the internal segregation and management of
system security. But then, that's the domain of the "transport-layer"
security WG....
> From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
> > From dpkemp@missi.ncsc.mil Wed Aug 21 07:37:18 1996
> > The other viewpoint is top-down: there is a huge universe of applications
> > running on real customer networks that need to be "secured". We could do
> > it by modifying every single application and every application protocol to
> > provide security services at the highest layer, or we could recognize that
> > application protocols fall into classes, and that for some classes (those
> > that don't multiplex services for multiple "users" through a single
> > connection or process), a common IP-layer mechanism can be used without
> > modifying the higher layer protocols. Therefore it is reasonable to
> > provide the mechanism (an SPI field in the IP packet) that can in some
> > cases be used to achieve separation between "users" at the network layer.
>
> Seems reasonable to me.
>
> For those of us who are "securing" application protocols that aren't
> members of the class that can use IP-layer user-oriented security, it
> would be most helpful to have IPSEC "officially" recognize the position
> that David succinctly stated above.
>
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5475.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: Idea: Prizes for protocol problems in key agreement
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 7:17:18 EDT
> From: John Gilmore <gnu@toad.com>
> I have a serious concern that we'll end up standardizing on a protocol
> that has not had the scrutiny required to validate its security. For
> this audience I need not point out that if the key agreement protocol
> is insecure or subvertible, it doesn't matter how strong our packet
> encryption is, nor how solid our public-key infrastructure is.
>
> I hope that we can do something similar for some of the reference
> implementations, once the protocols are nailed down.
>
I like both ideas very much!
> There might be big money for the protocol authors here -- they can
> define buggy protocols and then collect by pointing out the problems!
> But I think the increased general scrutiny is worth that risk.
>
Phooey, too late for Phil and I. :-( Do we get prizes for finding and
fixing past holes in the _original_ specifications? We already had some
help from reviewers, of course....
And what about holes that the WG review process forced us to add into
the protocol? Such as:
> * Revealing user identities to observers (if user keying is involved)
(As folks may remember, the change of Photuris privacy protection from
mandatory to optional, which was the only recent change to Photuris, was
the result of a nearly unanamiously straw poll instigated by Hugo at LA.
Negative prizes -- perhaps future prize disqualification -- for entire
groups of people?)
> Please give me your reactions and suggestions about this idea.
> Suggestions for a set of standards to judge the protocols against would
> be particularly useful. Also suggestions on the appropriate sizes,
> numbers, and categories of prizes, and potential judges.
>
The categories you listed seem to cover most of my concerns, as
specifics such as anti-clogging and key escrow fit under the more general:
> * Inability to scale to daily use on the entire Internet
> * Failure to provide perfect forward secrecy for packet traffic
I suggest that, as in the Nobel prizes, the prize funders be the sole
determiner of categories, sizes, and judges. You might want to find
protocol "customers" like Moskowitz to be on the panel of judges, rather
than potential contributor/recipients like cryptographers or IETF'ers.
And worldwide geographic coverage, rather than US centric.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Date: Mon, 26 Aug 1996 02:09:58 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608260609.CAA00246@mcn.netsec.com>
To: ipsec@TIS.COM
Subject: "user" and "network layer" security. reply to respondents.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The term "user" is undefined in the network layer of IP. It has no
sensible context in a discussion of *network layer* security
mechanisms. Moreover, introducing a parameter to the network layer
that corresponds to "user", breaks the network architecture. These
are basic facts of IP architecture. The basic facts of IP
architecture are established by agreed upon definition.
Important issues are raised by these basic facts. Arguments such
as those based on suggested hacks of network codes and operating
systems, are all specious with respect to the real issues.
Issue #1:
Is it appropriate for IPSEC to break network architecture, given
the absence of experience implementing security on the proposed
scale?
Issue #2:
Where is it established that network layer mechanisms should be
used to implement application layer security?
Regards,
Mitch Nelson
netsec@panix
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: netsec@panix.com
Cc: ipsec@TIS.COM
Reply-To: karn@qualcomm.com
In-Reply-To: <Pine.SUN.3.91.960816155715.811B-100000@panix.com>
(netsec@panix.com)
Subject: Re: "user" and "network layer" security.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 7:15:18 EDT
Message-ID: <9608260715.aa04497@neptune.TIS.COM>
>"User" based security and "network layer" security can each be designed
>and implemented in ways that are consistent with the established network
>architecture. With some pro-forma cross consultation, one should expect
>to arrive at reasonable results that provide good security without
>conflict and without unduly compromising present network functionality.
>The alternative does not offer as much grounds for optimism. Therefore it
>seems that all lanquage related to "user" should be expunged from IPSEC
>and instead treated in a seperate discussion group.
I couldn't agree more. As one of the originators of the IPSEC group, I
have watched with increasing resignation for the last four years as my
original idea has grown completely out of control, with very little to
show for it.
My original desire for security just above IP was to solve an
immediate and well-defined problem: when I use the network at an IETF
meeting or a USENIX, how can my laptop get back through my company's
firewall in a safe and secure fashion?
A closely related problem is the use of the Internet as a low-cost
alternative to leased lines between geographically separate subnets of
a corporate network. Leased lines are easily encrypted at the link
layer, but you have to move up to at least the IP layer to build a
"virtual leased line" over the net.
A security layer immediately above IP is a simple, straightforward and
highly effective solution to both problems.
I was so taken by IPSEC's seeming elegance that I started saying it
could displace security at the application layer. I now realize this
was a serious mistake. The interminable philosphical discussions here
about "user-oriented keying" and the geometrically increasing
complexity of the proposed key management protocols (including
Photuris) are clear proof of that.
Furthermore, there has been considerable progress in public-key-based
application-layer security in the past several years. We now have PGP
for email and files, SHTTP for the web, and SSH for remote login,
command execution and file transfer. Unlike IPSEC, I use all three
every day, and they work. SSH seems likely to develop into a general
purpose transport layer security mechanism that satisfies much (though
not all) of the need for end-to-end Internet security. So our
idealistic idea of avoiding all that application layer work has been
almost completely overtaken by events.
If the IPSEC group's work is to ever have any relevance, it must
return to the original, bare-bones goal of building protected
"tunnels" at the host-to-host or subnet-to-subnet level of
granularity. There's still plenty of need for this function, but
trying to do more than this is likely to continue to get us nowhere.
In this light, SKIP keeps looking better to me all the time. Its claim
to the "simple" label certainly keeps getting stronger. The only real
problem I've ever had with it was the lack of perfect forward secrecy
(PFS) in the original design. But that's in there too. So other than
the lack of support for a facility (user-oriented keying) that we
can't really do properly anyway, what's wrong with it?
Phil