NAME

  SG_I_RFC2409_3_2_1 - [Initiator Test] Encryption of ISAKMP payload

TARGET

  SGW

SYNOPSIS

  SG_I_RFC2409_3_2_1.seq [-tooloption ...] -pkt SG_I_RFC2409_3_2_1.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.


           IDENTITY PROTECTION EXCHANGE


 #   Initiator(NUT)     Direction      Responder(TN)
(1)  HDR; SA            ========>


(2)                     <========       HDR; SA


(3)  HDR; KE; NONCE     ========>


(4)                     <========     HDR; KE; NONCE


(5)  HDR*; IDii; HASH_I ========>                    <---must be encrypted
                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).


   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. 


   3. Receive the third message from NUT
      In the third (3) message, the initiator send keying material 
      used to arrive at a common shared secret and random information 
      which is used to guarantee liveness and protect against replay attacks.


   4. Send the fourth message from TN
      In the fourth (4) message, the responder send keying material 
      used to arrive at a common shared secret and random information 
      which is used to guarantee liveness and protect against replay attacks.


   5. Receive the fifth message from NUT
      In the fifth (5) message, the initiator send identification 
      information and the results of the agreed upon authentication 
      function(hash function).

JUDGEMENT

       The first to the fourth message must be exchanged correctly.
       The fifth message must be encrypted and received.
       And must conform to above Configuration.

TERMINATION

  Clean up SAD and SPD

REFERENCE

  RFC2408 
  3.1 ISAKMP Header Format


   (omit)


    o  Flags (1 octet) - indicates specific options that are set for the
       ISAKMP exchange.  The flags listed below are specified in the
       Flags field beginning with the least significant bit, i.e the
       Encryption bit is bit 0 of the Flags field, the Commit bit is bit
       1 of the Flags field, and the Authentication Only bit is bit 2 of
       the Flags field.  The remaining bits of the Flags field MUST be
       set to 0 prior to transmission.


      --  E(ncryption Bit) (1 bit) - If set (1), all payloads following
          the header are encrypted using the encryption algorithm
          identified in the ISAKMP SA. The ISAKMP SA Identifier is the
          combination of the initiator and responder cookie.  It is
          RECOMMENDED that encryption of communications be done as soon
          as possible between the peers.  For all ISAKMP exchanges
          described in section 4.1, the encryption SHOULD begin after
          both parties have exchanged Key Exchange payloads.  If the
          E(ncryption Bit) is not set (0), the payloads are not
          encrypted.


   (omit)


  RFC2409
  3.2 Notation


   (omit)


   Message encryption (when noted by a '*' after the ISAKMP header) MUST
   begin immediately after the ISAKMP header. When communication is
   protected, all payloads following the ISAKMP header MUST be
   encrypted.  Encryption keys are generated from SKEYID_e in a manner
   that is defined for each algorithm.

SEE ALSO

  perldoc V6evalTool

  IKE.html IKE Test Common Utility