[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comment on the ISAKMP/Oakley resolution draft (pre-shared)
Shawn and other intersted parties:
Having the pre-shared key in SKEYID and the derived keys increases security.
It was my recommendation to do so. As just one example consider two
parties that use DH with a public prime p. If at some point enough
cryptanalysis and pre-computation is done on p then every exchange using that
prime may be compromised. This is a not-impossible scenario where you
lose (in a hard way) all the advantages of perfect forward secrecy
(your traffic of the last few years may be compromised!).
If, however, you derived your key depending
on both g^xy and your pre-shared key the attacker will need to find the
value of that pre-shared key (which will probably not exist at that point
of time) to find the actual keys used to protect the session traffic.
I agree with you that having to tie the pre-shared key only to IP addresses
is too much of a loss of flexibility and functionality of the protocol.
However, there is the simple solution suggested in Pau-Chen and Dan's messages.
That is, use a key identifier for the pre-shared key: such a key identifier
would be meaningful only to the specific parties sharing that key.
As Dan pointed out you can then dispense of non-aggressive mode and
just do aggressive, thus saving communication. (You may still want
non-aggressive mode for the sake of negotiation). Bottom line: we achieved
more security, a more modular protocol, less communication and full
functionality.
In order to accomodate this key identifier one needs an
"Identifiction Type Value" as defined in the Ipsec DOI
(draft-ietf-ipsec-ipsec-doi-02.txt).
This can be one of the "private" values to be agrred upon by the
communicating parties, or we could have a type value (say 7) added in
that draft for "ID_KEY".
If there is no opposition to do so I would suggest this mininal editorial
change to the DOI draft.
Hugo
Follow-Ups: