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

Re: DH vs. RSA use for symmetric key exchange

Thanks for taking the time to explain Hugo. I fully understand the desire to
keep IKE's complexity as low as possible.  In particular, as Schneier points
out in his review the more complicated a protocol, the greater the
likelihood of security flaws in it.  I therefore understand why this was not
implemented.  I would like to make sure I understand the point you made
about PFS though.

I thought that using RSA to exchange keys would introduce a "simple" mode
that would eliminate DH entirely.  Especially where an RSA key certificate
is being used for authentication the initiator already has to implement path
processing and other complex PKI logic.  In such a situation if we just drop
DH and use RSA instead to exchange the keys _this_ _particular_ exchange
becomes simpler.  Also, I was under the impression that it would ensure PFS
rather than detract from it.

I thought PFS has to do with not using material from (or related to) a
previous key to generate each subsequent key.  Do we here use PFS to mean
that the symmetric key should not only not be derived from a previous key
but must not be encrypted with the same key as before?

Is PFS intended to cover the risk associated with an RSA private key being
compromised?  If so, I assume it would apply to DH keys as well if they get
reused.  An optimization in IKE ( I think ) is the ability to reuse DH keys
to establish multiple SAs and generate multiple keys.  Is there any
recommendation on how many SAs can be generated or for how long a DH key can
be used?

An slightly related and more practical question:
The appropriate method / approach of benchmarking an IPSec implementation is
likely to be somewhat complex.  Given the flexibility of how SAs can be
established, modes employed etc information like "able to establish n IPSec
sessions per second" is very incomplete!  Are 10 IPSec SAs being established
per IKE SA or one?  What is the ratio of DH exchanges to IKE SAs to IPSec
SAs?   I am guessing that per DH exchange more than one IKE SA can be
established.  Per IKE SA more than one IPSec SA can be established.  Is this
correct?

Khaja


----- Original Message -----
From: "Hugo Krawczyk" <hugo@ee.technion.ac.il>
To: "Khaja E. Ahmed" <khaja.ahmed@home.com>
Cc: "ipsec list" <ipsec@lists.tislabs.com>
Sent: Thursday, December 07, 2000 3:23 AM
Subject: Re: DH vs. RSA use for symmetric key exchange


> Khaja, you make some valid points below.
> IKE could have accomodated a non-PFS (perfect forward secrecy) mode that
> would dispense of the cost of a DH exchange. A suggestion like that
> appeared once as an internet draft that is now expired. Such a mode would
> be useful in some situations. Particularly those that do not require
> confidentiality but just authentication. However, the current
> high-priority goal is to streamline IKE such that implementation
> complexity is lowered and inter-operability improved. In this
> state of affairs adding new modes is not productive.
>
> Hugo
>
>
>
> > Thanks again Sandy for the very useful pointers.
> >
> > I do wonder though...
> >
> > In a situation where one or both parties of a key exchange session has
> > (have) an RSA public key certificate what is the advantage of using DH
to
> > exchange keys and then using RSA to authenticate the party?  Why not do
what
> > happens in SSL / TLS?  Use the RSA public key to exchange the symmetric
key.
> > Is one approach computationally more efficient than the other?  Clearly
IKE
> > does not support use of RSA to do key exchange today.  Is there a reason
why
> > this was not implemented / supported in IKE?   Is this a useful thing to
> > explore?  Would there be any advantage to allowing / supporting both
methods
> > of exchanging keys?
> >
> > Khaja
> >
> >
>
>
Follow-Ups: References: