One document matched: draft-ietf-pppext-l2tp-sec-00.txt

   3.1 Start-Control-Connection-Request/-Reply

      Session Key 

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1|0|0|0|        Length         |               0               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               ?               |    Encoded Session Key...     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
      A new AVP MAY be present in the tunnel initiation messages. When
	  present, the L2TP peer is indicating that a session key is to be
	  used to perform the message digest functions.

      It is encoded as the Attribute ?, Mandatory, with the indicated 
      number of bytes representing the session key.  This AVP is 
      optional.
     
      When present the MIC in the L2TP header is computed using the 
      decoded Session Key and the key is encoded as follows:
     
      encodedKey = MD5( IV | Master Key ) Xor Session Key

      and decoded as follows:

      decodedKey = MD5( IV | Master Key ) Xor encodedKey

     


Calhoun                    expires January 1997                  [Page 6] 

INTERNET DRAFT                                                  June 1997


   3.1 Renegotiate-Security-Association
     
      The Renegotiate-Security-Association message type is an L2TP 
      control message used to renegotiate a new security association. 
      It can be sent after establishment of the control connection. 
     
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    L2TP Control Message Header      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Renegotiate Security Association   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Session Key   |
      +-+-+-+-+-+-+-+-+
     
      Renegotiate-Security-Association
     
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1|0|0|0|        8              |               0               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                0              |               ?               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
      The Message Type AVP contains a Value of ?, indicating 
      Renegotiate-Security-Association.  The Flags indicate a mandatory 
      option.  Details associated with this security renegotiation 
      session follow in additional AVP's within the packet.
   
     
      Session Key 
     
     
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1|0|0|0|        Length         |               0               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               ?               |    Encoded Session Key...     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
      The Session Key AVP contains a new session key for a control 
	  channel. It is encoded as the Attribute ?, Mandatory, with the 
	  indicated number of bytes representing the session key.  This AVP 
	  is mandatory.



Calhoun                    expires January 1997                  [Page 7] 

INTERNET DRAFT                                                  June 1997


      When present the MIC in the L2TP header is computed using the 
      decoded Session Key and the key is encoded as follows:
     
      encodedKey = MD5( IV | Previous Key ) Xor Session Key

      and decoded as follows:

      decodedKey = MD5( IV | Previous Key ) Xor encodedKey
     
     
4.0 Acknowledgments
     
   I would like to thank Baiju Patel from Intel Corp. and Sumit Vakil 
   for their assistance. 
     
     
5.0 Contacts
     
   Pat R. Calhoun
   3Com Corporation
   1800 Central Ave.
   Mount Prospect, Il, 60056
   pcalhoun@usr.com
   (847) 342-6898
     
   W. Mark Townsley
   IBM Corporation
   700 Park Office Drive
   Research Triangle Park, NC 27709
   wmt@raleigh.ibm.com
   (919) 543-7522
     
     
6.0 References
     
     
   [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, 
       A. J. Valencia, W. Verthein "Layer Two Tunneling Protocol (L2TP)", 
       Internet draft, March 1997
     
   [2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
       07/21/1994
     
   [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
       Message Authentication", RFC 2104, February 1997
     
   [4] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 
       04/16/1992
Calhoun                    expires January 1997                  [Page 8] 
�