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

Re: SIPP and SKIP. 2 subjects.


James P. Hughes says:
> In thinking about the compatibility of SKIP (with its implicit key
> exchange) with explicit key management, it seemed that SIPP
> encapsulation would require that the version be used to
> differentiate SAIDs that were generated by explicit key management
> and packets that use implicit key exchange of SKIP.

The model we developed holds that SAIDs are assigned at the pleasure
of the recipient. (Actually, for multicast purposes thats the pleasure
of the entity controlling the address.) SKIP has several good features
that should be incorporated in any key management protocol that is
standardized on, but I think that purely implicit key management is
not one of them.  Explicitly assigning a security identifier is a
cheap operation. Once assigned, a particular SAID might identify all
subsequent packets bearing it as SKIP-style "implicit key exchange"
encrypted packets. However, I'm very reluctant to support use of the
four bit version field (which in the draft I am defining as an Must Be
Zero field, at least for the moment) for this purpose, since it seems
that the same purpose can be cheaply achieved without using the
version space. Using the version number seems to just be a way to
end-run around assigning a SAID for the purpose, which, as I said, is
cheap.

> In SKIP, could the overhead be reduced even further if the SAID was
> used cache the session key (Kp) and, if the stream offset (IV or
> other per packet info) were in the clear, then DES would not usually
> be needed at all on a per block basis. DES would only be needed if
> Kp (and the SAID changes).  In SKIP, the SAID could be a one way
> random identifier.

The intention of the scheme we came up with was that particular
security associations would be identified via the SAID and the SAID
alone, but that the security transformation associated with the
security association could use the encapsulated part of the packet in
any manner it liked provided that 1) it is standardized for that
transformation so that interoperable implementations are possible and
2) that the result of inverting the security transform was a 64 bit
aligned packet (this being demanded by the IPv6 people). Anything that
needs to be conveyed with the packet, be it a sequence number, an IV,
or anything else that is not purely a SAID, is supposed to be
contained in the encapsulated area in a security transformation
dependant way.

Perry
References: