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

From: Alan DeKok <[email-masked]>
Date: Tue, 9 May 2017 11:59:35 -0400

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.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 May 2017 20:30:00 -0400

Yeah, this is an instance where RADIUS's lame security is even "lamerer". Does anyone still use Tunnel-Password?

Makes me wonder if enough evidence has accrued to justify declaring RADIUS security deprecated and recommend a replacement.  

> On May 9, 2017, at 11:59 AM, Alan DeKok <[email-masked]> wrote:
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Tue, 9 May 2017 21:36:50 -0400

> On May 9, 2017, at 8:30 PM, Bernard Aboba <[email-masked]> wrote:
> 

  Not a lot.  And I've never seen it used in CoA-Request packets, which makes this issue less of a problem.

  Any attack based on the limited randomness available is mitigated by the fact that even if you had a 100% attack against Tunnel-Password, you still couldn't forge request packets.

  So the main vulnerability appears to be that it's easier to brute-force crack Tunnel-Password, as there are only 15 bits of randomness available.  Which means pre-computation of hashes becomes that much easier...

> Makes me wonder if enough evidence has accrued to justify declaring RADIUS security deprecated and recommend a replacement.  

  I'd suggest requiring DTLS, except the most widely used TLS implementation has had security issue after issue with their DTLS replacement.

  Deprecating UDP-only RADIUS would be a procedural step.  It wouldn't really affect existing (or most future) deployments.

  My $0.02 is to just move to RADIUS over TLS, and call it done...

  What other deprecation / replacement would you suggest?

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 9 May 2017 21:47:38 -0400

Out of curiosity, do you have any notion of the relative prevalence of RADIUS over TLS in deployments today? 

Sent from my iPhone - Not proofread.

> On May 9, 2017, at 9:36 PM, Alan DeKok <[email-masked]> wrote:
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 9 May 2017 21:53:39 -0400

> Out of curiosity, do you have any notion of the relative prevalence of RADIUS over TLS in deployments today? 

  Eduroam is largely RADIUS over TLS for inter-site proxying.

  Most commercial WiFi roaming is still RADIUS over IPSec the last I heard.

  I don't think any switch / NAS vendors have implemented RADIUS over TLS.

  Overall, RADIUS over TLS is a small percentage of the total.

  Alan DeKok.