NAME

  SG_I_A_RFC2409_5_19 - [Initiator Test] Multiple Transform Payloads check(modify proposal)


TARGET

  SGW


SYNOPSIS

  SG_I_A_RFC2409_5_19.seq [-tooloption ...] -pkt SG_I_A_RFC2409_5_19.def -tooloption : v6eval tool option
  See also ike_common.def and ike_ipsec.def and ike_addr.def and ike_pkt_ph1_recv.def and ike_pkt_ph2_recv.def


INITIALIZATION


TEST PROCEDURE

  This test check is following.

AGGRESSIVE EXCHANGE
# Initiator(NUT) Direction Responder(TN) (1) HDR; SA, KE, Ni, IDii ========>
(2) <======== HDR; SA, KE, Nr, IDir, HASH_R <-----modify proposal(invalid)
(3) HDR[*]; HASH_I ========> X <-----Must not transmit Judgement (Check *1)
1. Receive the first message from NUT In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks are also transmitted. Additionally, the initiator transmits identification information.
2. Send the second message from TN In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks is also transmitted.Additionally, the responder transmits identification information and the results of the agreed upon authentication function(hash function).
3. Receive the third message from NUT In the third (3) message, the initiator send the results of the agreed upon authentication function(hash function).


JUDGEMENT

      The second message must not be accepted. And the third message(3)
      must not be returned.


TERMINATION

  Clean up SAD and SPD


REFERENCE

  RFC2408
  4.2 Security Association Establishment

(omit)
When responding to a Security Association payload, the responder MUST send a Security Association payload with the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison directly and quickly. The initiator MUST verify that the Security Association payload received from the responder matches one of the proposals sent initially.
RFC2409 5. Exchanges
(omit)
During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected.


SEE ALSO

  perldoc V6evalTool
  IKE.html IKE Test Common Utility