RADIUS attribute from rfc2868


This Attribute may contain a password to be used to authenticate
      to a remote server.  It may only be included in an Access-Accept

   A summary of the Tunnel-Password Attribute format is shown below.
   The fields are transmitted from left to right.

    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
   |     Type      |    Length     |     Tag       |   Salt
      Salt (cont)  |   String ...

      69 for Tunnel-Password

      >= 5

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the value of the Tag field is greater than 0x00 and
      less than or equal to 0x1F, it SHOULD be interpreted as indicating
      which tunnel (of several alternatives) this attribute pertains;
      otherwise, the Tag field SHOULD be ignored.

      The Salt field is two octets in length and is used to ensure the
      uniqueness of the encryption key used to encrypt each instance of
      the Tunnel-Password attribute occurring in a given Access-Accept
      packet.  The most significant bit (leftmost) of the Salt field
      MUST be set (1).  The contents of each Salt field in a given
      Access-Accept packet MUST be unique.

      The plaintext String field consists of three logical sub-fields:
      the Data-Length and Password sub-fields (both of which are
      required), and the optional Padding sub-field.  The Data-Length
      sub-field is one octet in length and contains the length of the
      unencrypted Password sub-field.  The Password sub-field containsthe actual tunnel password.  If the combined length (in octets) of
      the unencrypted Data-Length and Password sub-fields is not an even
      multiple of 16, then the Padding sub-field MUST be present.  If it
      is present, the length of the Padding sub-field is variable,
      between 1 and 15 octets.  The String field MUST be encrypted as
      follows, prior to transmission:

         Construct a plaintext version of the String field by
         concatenating the Data-Length and Password sub-fields.  If
         necessary, pad the resulting string until its length (in
         octets) is an even multiple of 16.  It is recommended that zero
         octets (0x00) be used for padding.  Call this plaintext P.

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.  Encryption
         is performed in the following manner ('+' indicates

            b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
            b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
                        .                      .
                        .                      .
                        .                      .
            b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

         The resulting encrypted String field will contain

      On receipt, the process is reversed to yield the plaintext String.