[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Will the real PFS please stand up?
Robert Moskowitz wrote:
> >What concerns me is the use of g^xj to protect the ephemeral
> >certificates; it appears to me as if subsequent compromise of j will
> >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
> >revealing the identities of everyone who has corresponded with j
> >during the period of interest.
>
> Does this mean that an escrowing of J can yield j? And thus escrowing is
> effective against SKIP PFS? If so, this is unexceptable. PFS must be
> immune to key escrowing.
Yes, by escrowing J, you can get j. But this is *not* effective against SKIP
PFS. The reason for this is that 'j' is used as an authentication key. If
the escrowing agent does not get x and/or y, which are ephemeral DH secret
values, the escrowing agent can only find out who communicated with J,
and can naturally impersonate J. This would work the same way with all other
schemes too, if authenticated exchanges are foreseen.
Friendly greetings,
Germano
by the way:
In my opinion escrowing communicated data is nuts anyway, you want key
escrow for long term archived data, where key owners (and their secrets)
may 'get lost'...
From: Rich Skrenta <skrenta@osmosys.incog.com>
Message-Id: <199608291706.KAA00973@miraj.incog.com>
Subject: Re: Will the real PFS please stand up?
To: Robert Moskowitz <rgm3@chrysler.com>
Date: Thu, 29 Aug 1996 10:06:57 -0700 (PDT)
Cc: sommerfeld@apollo.hp.com, balenson@TIS.COM, ipsec@TIS.COM
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Does this mean that an escrowing of J can yield j? And thus escrowing is
> effective against SKIP PFS?
No, it means what Bill said -- that anonymity of the participants is not
covered by the PFS. `J' above is the identity of one of the communicating
parties; it doesn't make sense to talk about escrowing it.
If we're talking about host-host communication, the identities of the
two parties are known anyway. Hence this paragraph from the draft:
"The encryption of each principal's certificate using g^xj is
optional. It is used to provide anonymity of the parties
involved in the ephemeral exchange. In case anonymity is not
desired or necessary (e.g. node to node communications) the
encryption using g^xj may be omitted."
Date: Thu, 29 Aug 1996 13:03:36 -0500
From: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>
Message-Id: <MSMAIL PC */PRMD=MOT/ADMD=MOT/C=US/@MHS>
Subject: Everything degenerates to Key Management
To: ipsec@TIS.COM
X400-Mts-Identifier: [ /P=MOT/A=MOT/C=US/ ; m\gstmd\960829130336b ]
X-Mailer: Worldtalk (4.0.2-p15)/STREAM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I've been listening/reading the group's discussions for some time.It is
clear
that IPSEC, we, must produce and field a viable solution within the next
year
or be overcome by events. This truth, while brutal, I think can be
confirmed
independently by all of us.
Every discussion seems to degenerate into the fixed camps of key management
proponents, and it seems nearly impossible to unify until this issue is well
put to bed.
I agree heartily with Mr. Harald Koch:
>The people working on other protocols requiring security (TLS, L2TP, LDAP,
>and probably others) have all been overheard saying the same thing:
>
> Wouldn't it be nice to have a single key negotiation protocol for
> IPsec *and* for our protocols?
>
>So, Before we run around in a frenzy removing 'user oriented keying', we
>should remember that AH/ESP are no longer the only customers of an IPSEC WG
>key management protocol.
Though my preference would be an ISAKMP/OAKLEY key management solution for
IPSEC, I understand Phil's concern at how far we have gone from the original
goals.
>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.
>...
>how can my laptop get back through my company's
>firewall in a safe and secure fashion?
>...
>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.
I do however feel strongly that we have a responsibility to position the
Internet protocols for future capability. Ignoring the need that is well
voiced for a common, flexible, and extensible key managment protocol would
border on deliquency.
As Germano Caronni requested, I would like to reiterate, that it would be
helpful to review the TECHNICAL reasons for failure of unifying the key
management approaches.
>To my deep sorrow, Hilarie Orman has announced the failure of the design
>group that was supposed to come up with a unified key management approach.
>It might be very interesting for the group as a whole to understand why
this
>occurred. Could perhaps some of the group members elaborate on their
>respective views to what technical differences were not acquiescable?
It would be helpful if this exchange were HIGHLY moderated - much like a
debate. However, written form - through the mail list - would be a much
better forum than a meeting.
I propose that key designers/proponents of the key management protocols
collaberate and present a SHORT position paper on the primary aspects/
features of their respective protocols that cannot be unified with other
approaches; a single submittal for each protocol may be forwarded to Ran or
Paul who will then post to the group. A SINGLE, UNIFIED rebuttal from each
party be allowed to be posted following the first submittal, again through
one of the chairs.
This process will allow us the read a clearly presented position from the
major contributors WITHOUT a lot of bantering clogging up the exchange.
Folks, we need a unfied approach, or we will continue to bicker until
someone else produces a workable compromise and we will all end up looking
like fools -- many other groups/companies are doing this. If we can't get
there, and come to a professional concenus, then maybe Phil is right --
we'll
need to rope in our goals.
Dave Wheeler
Motorola, SSTG
Scottsdale, Az
"What's the difference between a wise man and a fool arguing in the street?
A stranger can't tell the difference between the wise man and the fool."