[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Will the real PFS please stand up?

> To:            "David M. Balenson" <balenson@TIS.COM>
> Cc:            ipsec@TIS.COM
> Subject:       Re: Will the real PFS please stand up? 
> Date:          Wed, 28 Aug 1996 16:29:23 -0400
> From:          Bill Sommerfeld <sommerfeld@apollo.hp.com>

> On a related note, the skip-pfs draft does PFS in a different way from
> how it's done in the other protocols.
> 
> Now, I don't consider myself a cryptographer, but something in
> skip-pfs struck me as somewhat unconventional...

I don't believe that SKIP PFS is the only protocol proposed
that has the property that you are discussing. I believe that
a scheme proposed by Hugo (SKEME :) also has the same
property with respect to identity protection, as I recall
from his presentation. 

> 
> This is not the first time that I've raised this issue, but I don't
> think it's been resolved..

I believe that I sent a response to the ipsec mailing
list the last time this issue was raised. Perhaps this got
lost somewhere?

> 
> 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
> 
> 	(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.
> 
> 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.

I'll me repeat what I said about this the last time.

SKIP PFS does not provide PFS for identities. It does
provide PFS for traffic. The issue here is a tradeoff
between susceptibility of identity disclosure due to an
active (man-in-the-middle) attack, or susceptibility
to identity disclosure due to long-term key compromise.

SKIP PFS provides protection against identity disclosure
from a man-in-the-middle attack. Schemes that provide
PFS for identities do not typically have this property.
This means that identities can be discovered by an
active attack on the key-exchange.

This appears to be the trade-off. You can either have
protection of identities from an active attack without
PFS for indentities; or you can have PFS for identities
but susceptibility to identity disclosure from a 
man-in-the-middle attack.

Like I said, if the WG is strongly in favor of one
or the other, then SKIP PFS can be modified accordingly.

However, the last time I asked this question, there
was no response on the mailing list. 

Personally, I prefer to keep it the way it is, because 
providing PFS for identity information, at the expense of 
protecting identities from man-in-the-middle, is more complex 
than the current exchange. 

Ashar.