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

Re: PFS SKIP Draft

>            SKIP extension for Perfect Forward Secrecy (PFS)
>                   <draft-ietf-ipsec-skip-pfs-00.txt>
>This document describes an optional extension specifying how to use an
>ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol
>in order to provide perfect forward secrecy for situations where forward
>secrecy is necessary.

Anonymity is also offered. (Or will be, after modification)

>In addition a new type of Master Key-ID (MKID) type is defined here, to
>indicate the use of ephemeral master keys. In addition to perfect
>forward secrecy, principal anonymity is also supported in the context of
>the ephemeral certificate exchange.

How about using 'NSID' instead of 'MKID type' ?

>2.  Cryptographic Description of Ephemeral Certificate Exchange
>
>Cryptographic Notation used for describing Ephemeral Certificates:
>
>Note: All exponentiations (e.g. g^x) are mod p. The mod p reduction is
>assumed, and is omitted for the sake of brevity.
>
>g^x:            Ephemeral Diffie-Hellman public value of initiator (I)
>g^y:            Ephemeral Diffie-Hellman public value of responder (J)
>g^i:            Certified long-term Diffie-Hellman value of initiator
>g^j:            Certified long-term Diffie-Hellman value of responder
>Cert_I:         Long-Lived Certificate of initiator, containing value g^i
>Cert_J:         Long-Lived Certificate of responder, containing value g^j
>{Message}K:     Message authenticated with a Message Authentication Code
>                (MAC) computed using key K
>[Message]K:     Message encrypted using key K
>EMKID_J_I:      Ephemeral Master Key-ID used in packets from J to I
>EMKID_I_J:      Ephemeral Master Key-ID used in packets from I to J
>
>The ephemeral certificate exchange is described using the
>notation above as follows:
>
>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

I see two problems with this exchange. One has already been pointed out by 
Bill Sommerfeld: 

>The problem is that the certificate is encrypted with a key g^xj which
>has an ephemeral public component and a long-term private component.
>If the long-term DH secret key `j' is later compromised, an attacker
>than then decrypt both [Cert_I] and [Cert_J] and figure out who the
>parties to the exchange really are.

The other (not so immediate) problem is the employment of authentication 
using Kij on the outmost level. An atacker having a bunch of ressources, who 
can lay hands on either one of the secret value 'i' or 'j', can then go and 
combine the value with the public value of a probable partner. He can verify 
his guess by simply recalculating the authentication. If it matches, he has 
found the partners.

Both problems can easily be fixed, if we allow for a 3-pass exchange. I am 
aware that this complicates the issue of key establishment, but if somebody 
wants PFS and anonymity bad enough, he will have to pay the price, e.g.:

I->J: g^x, g, p, Cookie_1
J->I: {g^y, g, p, [Cert_J, EMKID_I_J, Cookie_1, Cookie_2}Kij]g^xy
I->J: [{g^x, g, p, Cert_I, EMKID_J_I, Cookie_2}Kij]g^xy

Cookie_1 & _2 allow I & J to check that the peer really holds Kij, and is 
not an impostor reusing some old messages. I admitt that I just reinvented 
the wheel, for a 'full' solution see e.g. page 5 of the current Oakley draft 
;-) But I believe the exchange presented above is sufficient for the special 
case SKIP PFS key exchange needs. 

>The values EMKID_I_J and EMKID_J_I refer to the ephemeral
>Master Key-ID to be used in SKIP packets sent from I to J
>and J to I, respectively. I picks the ephemeral MKID to
>be used in packets sent from J to I, and J picks the
>ephemeral MKID to be used in packets sent from I to J.

As a distinct namespace is defined for the EMKIDs, you _must_ define the 
size of these new key IDs. I suggest using 32 bit.

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

Change this to g^xy

>3.
>
>"Cert MAC Alg" identifies the MAC algorithm which is used to compute a
>MAC over the certificate contents. The scope of the MAC computation is
>the entire certificate, with the MAC field treated as zero filled for
>the purposes of the MAC computation.

Always if a MAC is present, it must be encrypted usig an g^xy derived key, 
if anonymity is to be provided.

>
>The "Validity Interval" specifies how long the ephemeral master key
>derived from this exchange should be used for. This value is in seconds.
>A responder MAY choose a different value for this field than the
>initiator, in which case the actual validity interval for this master
>key is the minimum of the two values in the exchange. At the end of the
>validity interval, the ephemeral master key and the all associated
>secret information is destroyed by both the responder and the initiator.
>A new exchange may be initiated either subsequent or prior to the expiry
>of the ephemeral master key, in case there is still encrypted traffic
>that needs to be sent in PFS mode.

Here lies another small problem: It is not clear when the interval *starts*. 
Provided that the time of the participating systems is not vulnerable to 
attack, it might be better to use 'Expires at (seconds GMT since xxx)', or 
'Expires at SKIP N=xxx'. 

Perhaps it could also be defined that if a new key exchange using the same 
EMKID is initiated, the old keying material is droppped. Or an authenticated 
ICMP message could be defined that has the meaning 'drop all ephemeral 
keying material partaining to me'.


>When I receives an ephemeral certificate, it uses the value EMKID_J_I to
>locate the request for which this is the corresponding response. A non-
>zero EMKID_I_J field indicates that this a response to an ephemeral
>certificate request initiated by I, as opposed to a new certificate
>exchange initiated by J.
> .P
 ^^^^

>7.  Security Considerations
>
>The topic of this memo is security.

My word. ;-) 

Section 7 currently holds negligible content. You could add a discussion of 
advantages / disadvantages against pure SKIP?


I hope my abovementioned protocol & arguments are valid. Comments anyone?

Friendly greetings,
        
        Germano


p.s. Concerning key separation issues: As Hugo suggested some months ago, it 
would be wise to use different keying material for different crypt & auth 
algs in SKIP. How about adding the two algorithm numbers to the key 
speration process?