[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>
> 

That's clear. I would recommend adding the above text or something like
that to the IKE and ISAKMP drafts. Thanks.

cheers,
suresh


References: