[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Session Management
Ran advised me that I missed replying to this message earlier in the week.
> Date: Mon, 09 Oct 1995 16:57:19 -0400
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>
> There's enough support in the protocol for replay detection if some
> restrictions are made on SPI reuse. Some sort of timestamp or sequence
> number would reduce the amount of storage needed to provide replay
> protection, but it's not really necessary.
>
Yes.
> I think the "change" message is misnamed, since it either creates a
> new SPI, or deletes an existing one. I'm not going to suggest edits
> to change that, however....
>
There previously were 2 messages (5 and 6) for Re_Key and Delete_Key,
but I was convinced to combine them. Change_Key eventually became
Change_Message, since it doesn't change the _key_ (and was confusing to
some for that reason), it changes the accumulated state.
For a short period of time (draft -03), it also allowed modification.
However, there was not WG consensus that this was useful, and that was
removed in -04.
> The draft doesn't explicitly disallow modifying an existing SPI, but
> it doesn't specifically allow it, either. I don't see how one could
> change arbitrary SPI attributes reliably, since packets sent using the
> SPI could be reordered around the change request.
>
I have added a section specifically disallowing modification.
> The fix is relatively simple:
> - limit the lifetime of the shared secret, and require that
> photuris remember the existance of all SPI's created using the shared
> secret until the shared secret expires.
>
This is already true. Obviously not clearly enough. Although I have
quoted the sections in other messages, they are apparently too dispersed
for folks to remember.
Therefore, I have gathered many of them into a new section just before
Multicast, called "Session Management". This also includes the
user-oriented keying material which previously was an implementation
note in the early protocol description section.
> Here's my suggested additions to the spec; there's admittedly some redundancy
> here, but I don't think it's excessive.
>
> [these should go into section 5.4]:
>
> The shared secret, and any SPIs created using it, must be
> destroyed once the initial SPI, created here, expires.
>
This is wrong, the SPI can outlive the shared-secret. This is important
to allow traffic to continue without interruption during new Photuris
exchanges.
> [These should go into section 6.4 implementation guidelines]:
>
> Change_Message packets must not be allowed to *modify* already
> existing SPI's, or to resurrect SPI's which have been deleted.
>
Correct.
> If an otherwise-valid change_message is received which would produce
> an SPI which would live beyond the expiration time of the shared
> secret, the new SPI must be silently adjusted to expire when the
> shared secret expires.
>
No. It is computationally infeasible to recreate the shared-secret from
the session-key.
> To prevent resurrection of already-used SPI's, implementations MUST
> remember, but mark as unusable, deleted or expired SPIs until the
> shared secret used to create them also expires.
>
Yes.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2