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

Re: Status of IPSEC Key Management



Stuart,

        I believe that the current mobile IP specs talk only about shared
secrets between the mobile nodes (MNs) and home agents (HAs), but are
silent on how these values are established and maintained.  Some folks at
BBN have been working on certificate-based support for creation and
management of the shared secrets, to help address the scaling issues.  We
adopted D-H certificates and a SKIP-variant computation to create
per-transaction keys.  I expect an MN to have cached the certificate
(public key) for his HA (or HAs if there are a few) before leaving home.
Similarly, the HA(s) should have no trouble caching (or quickly accessing
from a local directory) certs and the CRL(s) for all of the MNs it serves.


Thus, for these sorts of interactions, the only possible retrieval
requirement would be for an MN to get the CRL for his HA(s).  It may not be
necessary to fetch this CRL very frequently, since the HA(s) can be made
fairly secure (there are fewer of them and they ought to use hardware to
protect keying material and for increased performance).  Moreover, if you
look at the implications of a disclosed HA private key used in this
context, it isn't clear that the MN has a lot to lose if it is spoofed in
this exchange.  So, I think this approach can scale well.

I agree that HA-FA secure communication is appropriate, and we anticipate
establishing long duration SAs between these entities, probably muxing all
forwarded traffic between these agents on a single SA.  This strategy ought
to minimize the need for lots of cert/CRL fetches, especially since the
number of HA-FA parirs is much, much smaller than the number of MNs.
Admittedly, though, there may be more situation here where one needs to
fetch the certs and CRL from directories, if the HA-FA pairs are diverse
and cachhing doesn't help as much.

Our view has been that while signing of registration messages would be
conceptually simple, the costs for signature generation and validation are
high enough to deter use of this technique. For RSA signing, the amount of
data transferred is also much larger, comparsed to a key hash value, which
may be an issue in some instances.  Finally, I would expect the cert/CRL
caching requirements to be equivalent for the signed message approach vs.
the keyed hash approach that we are pursuing, so there ought not any
savings there.

Steve




Follow-Ups: