[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Anonymity vs PFS (was: Will the real PFS please stand up?)
Bill Sommerfeld wrote:
> As I read the draft, skip-pfs does not provide PFS protection of the
> identity certificates of the communicating parties.
[...]
>
> The exchange is:
>
> I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
> J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij
[...]
> 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.
[...]
Well, as I see it, SKIP PFS provides PFS (see the definiton of Phil Karn,
to which I fully agree) but it does not provide *perfect* anonymity.
Anonymity of participants and forward secrecy of communications really
are orthogonal properties.
If I remember correctly, we already had this discussion a few months ago?
One (rather old) answer was:
] One solution for anonymity for mobile users is to have anonymous
] principal ids (either per host or per user) (represented by private keys
] in smart cards or encrypted in some user password) that can be handed out
] to mobile users.
] These anonymous smart cards can be rotated among users, so that it isn't
] possible to know who is using a particular anonymous principal
] ID at any point in time.
] This can be implemented with SKIP, without requiring any change to the
] protocol.
This was an organisational solution to the whole issue even before PFS was
done. Unfortunatedly I have other relevant parts of my archives at the wrong
place, so I can not dig up 'conclusions', if there were any, which I doubt.
By the way, by using unsigned DH public values as defined in *-udh-* as
Cert_I and Cert_J, you get true anonymity, and perfect forward secrecy.
Actually, beacuse of the flexibility of SKIP and its namespace approach,
which I confess to like very much ;-), you can combine three types of
'certificates' and use one of them for each side of the message exchange.
The three types are 'unsigned ephemeral', 'signed ephemeral' and
'conventional' certificates. For each two of these combined you get some
nifty properties for the 'security association', and all of this can be
easily done using the certificate discovery protocol, independant of the
underlying key management proposal;-)
Germano
Date: Thu, 29 Aug 1996 07:02:25 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>,
"David M. Balenson" <balenson@TIS.COM>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Will the real PFS please stand up?
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608290746.aa29081@neptune.TIS.COM>
At 04:29 PM 8/28/96 -0400, Bill Sommerfeld wrote:
>
>The exchange is:
>
>I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
>J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij
>
> (key: i,j: long term secrets of I and J
> x,y: ephemeral secrets
> [encryption]
> {integrity protection})
>
>The resulting traffic is protected using a key derived from g^xy,
>which seems to be OK.
>
>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.
For those that are looking for NSA boogiemen everywhere, look carefully at
this :)
>Now, if I and J are just host identities, this isn't interesting
>(because the same information is found in their IP addresses) but if
>SKIP gets extended to do per-user keying I think we have a potential
>problem.
Huh? Please enlighten me.
>It would be fairly simple to fix this by adding another round trip,
>but the resulting protocol would would look a lot like OAKLEY or
>Photuris.
Meaning that these are not open to recorded attacks in this manner. But
what about your comment: "if I and J are just host identities". How does
this relate in Oakley or Photuris?
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
References: