[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on the latest Security architecture draft
In message <199806022314.QAA15346@server.livingston.com>, Pyda Srisuresh writes:
>
> Makes sense. But, as far as I can tell, this was left unspecified in
> ISAKMP and IKE drafts. In particular, in section 4.1 of the latest
> ISAKMP draft should have specified who sets the SPI number and
> who uses it. The most obvious assumption to make is that the initiator
> sets the SPI number along with the proposals and transforms in SA
> payload and the responder selects one that suits the best.
The IKE negotiation sets up SAs in BOTH directions.
The Initiator sends an SPI along with a series of SA proposals; that is the
initiator's SPI; the one that will be used for Receiving traffic at the
initiator.
The Responder, when it selects a single SA proposal and sends that back, fills
in the SPI field with the Responder's SPI; this is the one that will be used
for receiving traffic at the responder.
This is (unfortunately) only spelled out in a paragraph in section 5.5 of IKE,
which says:
A single SA negotiation results in two security assocations-- one
inbound and one outbound. Different SPIs for each SA (one chosen by
the initiator, the other by the responder) guarantee a different key
for each direction. The SPI chosen by the destination of the SA is
used to derive KEYMAT for that SA.
But, nonetheless, it's pretty obvious that this is the only way to get
different SPIs, and thus different keys, at each end of the negotiation.
--
Harald Koch <chk@utcc.utoronto.ca>
Follow-Ups:
References: