[radext] Question about CoA-Request and Tunnel-Password

[Alan DeKok <[e-mail]>]

  I think there's an issue with CoA-Request and Tunnel-Password

  RFC 5176 Section 2.3 says:

      Request Authenticator

         In Request packets, the Authenticator value is a 16-octet MD5
         [RFC1321] checksum, called the Request Authenticator.  The
         Request Authenticator is calculated the same way as for an
         Accounting-Request, specified in [RFC2866].

  Where RFC 2866 Section 3 says:

      The NAS and RADIUS accounting server share a secret.  The Request
      Authenticator field in Accounting-Request packets contains a one-
      way MD5 hash calculated over a stream of octets consisting of the
      Code + Identifier + Length + 16 zero octets + request attributes +
      shared secret (where + indicates concatenation).  The 16 octet MD5
      hash value is stored in the Authenticator field of the
      Accounting-Request packet.

    This means that for CoA-Request packets, all attribute obfuscation is calculated with the Reply Authenticator being all zeroes.

  RFC 5176 Section 3.6 allows for Tunnel-Password in CoA-Request packets:

   ...
   Change-of-Authorization Messages

   Request   ACK      NAK   #   Attribute
   ...
   0+        0        0    69   Tunnel-Password (Note 5)
   ...
   (Note 5) When included within a CoA-Request, these attributes
   represent an authorization change request.  Where tunnel attributes
   are included within a successful CoA-Request, all existing tunnel
   attributes are removed and replaced by the new attribute(s).


  However, RFC 2868 Section 3.5 says that Tunnel-Password is encrypted with the Request Authenticator:

   ...
         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
  ...

  The assumption that the Request Authenticator is random data is true for Access-Request packets.  It's not true for CoA-Request packets

  i.e. when the Tunnel-Password attribute is used in CoA-Request packets, the *only* randomness in the encryption is the salt.  Again, RFC 2868 Section 3.5 says:

   Salt
      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.
 

  Which means that there's only 15 bits of entropy in the Tunnel-Password obfuscation (plus the secret).

  I don't think this is a serious issue, given that the secret is used to obfuscate the Tunnel-Password.  But it can't be a good thing.

  Since this hasn't been brought up before in RADEXT, I thought I'd make a note.

  Alan DeKok.