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

Re: IPsec near term work


  In my opinion, there are too many pending security fixes that depend
on having an actual Internet standards-track key management protocol
for us to defer the details of that key management protocol.  If we
cannot exchange session keys interoperably, then none of these efforts
will have much real long-term value.  As an example, Mobile IP
absolutely must have support from a standards-track key management
protocol to get the kind of authentication that it really needs to
have (mobile hosts are unable to predict ahead of time which relays
they might need to use, so manual key mgmt just won't get the entire
job done for Mobile IP).

  As far as an API goes, that seems out of the scope of the IPsec WG
and within the scope of the Common Authentication Technology (CAT) WG
anyway.  CAT has already published an Application Programming
Interface (API) which can be extended with key mgmt interfaces.
However, having an API doesn't solve the problem of how to setup
session keys.

  I've spent some time since Houston experimenting with IP-layer
security implementations (including some work using KA9Q as a base and
some using other IP implementations as a base).  I really don't think
that the syntax is the most important or the hardest problem in
securing IP.  Phil Karn made some persuasive comments along these
lines in Houston.  

  After some messing around on my own, I'm tending to agree with Phil
on the matter of syntax.  People who carefully read my draft on SIPP
Encapsulating Security Payload will discover that I've put my typing
where my mouth is.  The syntax will probably vary slightly with
different algorithm families and the efficient approach is probably to
use a fixed syntax for each algorithm, with the syntax selected from a
small set of possible syntaxes.  Given that both sender and receiver
have to know the algorithm and mode in use for each packet, they can
adapt to slight syntactic differences on a packet by packet basis
without much problem. [1] While algorithm independence is clearly
required of the protocol, I suspect that, in practice, most
implementations will only support one algorithm and mode (i.e. DES in
CBC mode) anyway.  I'm convinced that key management (as usual :-) is
really the subtle and difficult problem here (not only technically but
legally, sigh).

  If the IETF had more people working in the security area, then maybe
I'd suggest splitting IPsec into an IPv4 Encapsulating Protocol WG and
an Internet Key Mgmt Protocol WG.  In practice, we don't have enough
people to vigorously tackle both tasks in parallel and we should
prioritise the work.  IMHO, the key management piece should be tackled
first.  Private email responses to my earlier note indicate that I'm
not alone in this view, though they are not numerous enough to indicate
any sort of trend.

Ran
atkinson@itd.nrl.navy.mil

[1] While I am not advocating reuse of the SIPP ESP syntax for IPv4, I
do believe that it could be easily adapted for use with IPv4 and would
not object if there were group consensus on doing that. :-)
Follow-Ups: