[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] Negotiating IKE_SAs
At 11:37 AM -0500 11/7/06, David Wierbowski wrote:
>>In the IKE_SA_INIT exchange the initiator sends an SA payload
listing acceptable proposals. The responder picks one and sends the
chosen proposal to the initiator. The identities of the IKE
endpoints are not exchanged until the IKE_AUTH exchange. If the
identities are not exchanged until the IKE_AUTH exchange, how does
the responder know which of the initiator's proposals are acceptable
during the IKE_SA_INIT exchange?
By looking at its own security policy.
Where is this policy defined?
In the application.
Is this considered to be a matter
of "local policy" and outside the scope of the RFCs?
>>RFC 4301 discusses the use of the SPD to find acceptable policy for
the creation of CHILD_SAs and it discusses the use of the PAD to
authenticate IKE endpoints. It does not appear to define a construct
to identify what policy is acceptable for the creation of a of an
IKE_SA with a specific IKE peer. Does this mean that RFCs 4301 and
4306 do support the definition of peer specific policy for IKE_SAs?
No. They support definition of peer-specific policies for IPSEC_SAs.
Strangely enough I don't think the term IPSEC_SA appears in RFC 4301
or 4306. By IPSEC_SA do you mean ESP and AH SAs?
>>RFC 4306 states, "All implementations of IKEv2 MUST include a
management facility that enables a user or system administrator to
specify the suites that are acceptable for use with IKE." This seems
to imply that peer specific IKE_SA policy should not be defined and
that the responder should pick the most secure proposal that the
responder supports. Is that correct?
Could you clarify why you said approximately? To me approximately
means almost correct :>).
Yes and yes. Peer-specific IKE_SA should not be used because it is a
bad security policy in many cases, but not all.
--Paul Hoffman, Director
Ipsec mailing list