[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG last call for IPv4 AH and ESP
Ref: Your note of Tue, 21 Feb 1995 12:31:41 -0800 (attached)
> I have an issue. I would like to be able to do in-band signalled
> keys. Does the draft preclude this? If not, then I believe that
I think Ashar is right about not precluding in-band keys.
The one change I believe may help this is to define two kind of
SAIDs: structured and unstructured.
Unstructured SAIDs are the usual ones, i.e. chosen by the local implementation
and transmitted to the other party; they are the perfect mechanism
when keys are established interactively (as should be the prevalent case).
Structured SAIDs are necessary in case of non-interactive establishment of
keys (e.g., when establishing in-band keys as proposed in the SKIP draft).
In this case, there should be some semantics to the SAID (e.g., pointer
to specific transformations, possibly a seq number, etc) understandable
by both sender and receiver.
All what is needed to support both kinds of SAIDs is just one bit
that determines whether the SAID is structured or not.
For example, a least significant bit of 0 will mean unstructured
and lsb of 1 means structured. In particular, the current range of
"reserved SAIDs" would fall in the structured category.
This still leaves 31 free bits for unstructured SAIDs which should
be enough.
In addition to the mentioned use for in-band signalled keys,
structured SAIDs can be used for periodic non-interactive refreshment
of shared keys. For example, two parties may decide that each two hours
they refresh their keys by applying to the current key a one-way
transformation. (This way a compromised key does not compromise
past keys). For such a mechanism one may want to add some counter
to the SAID structure in order to point to the correct key.
Hugo