Subject: FW: Review of draft-ietf-radext-status-server

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 21 Jan 2010 17:06:15 -0800

-----Original Message-----
From: Ignacio Goyret [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 3:30 PM
To: Bernard Aboba
Cc: [email-masked]; 'Alan DeKok'
Subject: Re: Review of draft-ietf-radext-status-server 

At 12:36 PM 1/11/2010 -0800, Bernard Aboba wrote:
>The document Use of Status-Server packets in the RADIUS protocol has now
completed RADEXT WG last call. 
> 
>Since the purpose of the document is to describe an existing deployed
protocol which was first implemented by Ascend Communications, we were
wondering if it would be possible for you to review the document for
accuracy. 
> 
>The document is available here:
>http://tools.ietf.org/html/draft-ietf-radext-status-server
> 

Hi guys,
Sorry for the delay, but I had to process some 6000 emails
after my vacation.

I don't know why you think that Ascend had implemented anything
like this. As far as I have been able to ascertain, neither our
RAS (MAX, TNT or APX) nor any of our RADIUS servers ever implemented
Server-Status. I even checked with the few folks still around
from the old Livingston (the creators of RADIUS) and got the
same story. Do you have any idea which product may have
implemented this? If you have any idea, let me know and
I'll try to find someone that can check the draft.

Anyway, I did a cursory review and have one technical comment
and a few trivial editorial fixes:

1) (tech comment) To be frank, both myself and our RADIUS engineers
were quite surprised that the response to a Server-Status is not
a code+1, or some other code like a fictitiuous "Server-Response".

The overloading of Access-Accept and Accounting-Response for
this purpose (response to a Server-Status command) is a bit
disconcerting and quite dangerous since it opens the door
for potentially bogus authentication.

I know that it is past WGLC so dramatic changes are out of
the question, but if nothing else, you should add some text
explaining the decision for this overloading.

2) page 6, section 2, 4th para:
                                                        vv
-   [RFC2865] Section 2.6.  "Keep-Alives" are sent when an downstream
+   [RFC2865] Section 2.6.  "Keep-Alives" are sent when a downstream
                                                        ^

3) page 6, section 2.1 title:

   Consider changing the title from:
       "Why Access-Request cannot be used"
   to something like:
       "Why Access-Request are not appropriate"

   This would make it more consistent with the 2.1.1 title
   which is a recommendation against, not a prohibition.

   Also, consider a similar change to the title section 2.2
   for the same reasons.

4) Page 10, first line:
                        vvvvvvv
-   same method as used for for calculating the Response Authenticator of
+   same method as used for calculating the Response Authenticator of
                        ^^^
5) page 20, section 6.2:

   The hex dump of the request is shown as:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   but it should be:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   (note change of "80" -> "50" in the 5th byte of the second line)

   Also, the response is wrong. It is shown as:

-----------------------(cut-here)-------------------------
      02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20 16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   but should be:

-----------------------(cut-here)-------------------------
      02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20
      16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   (two changes: "1a" -> "14" in the 4th byte of the first line,
    and a missing newline after "Length = 20").

HTH,
-Ignacio

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 22 Jan 2010 08:38:16 +0100

> From: Ignacio Goyret [mailto:[email-masked]] 
...
> a code+1, or some other code like a fictitiuous "Server-Response".

  Yes.  I think it's because there was no "response" packet pre-defined.
 I suspect that the implementors didn't want to self-allocate.

> for potentially bogus authentication.

  I'm not sure why.  The response packets are signed with the Request
Authenticator of the request.  i.e. the client *knows* that the
Access-Accept is in response to a Status-Server. So it has no "user
session" to authenticate.

> explaining the decision for this overloading.

  OK.  I'll put something together.

  The rest of your comments are editorial, and will go into the document
as-is.

  Alan DeKok.

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 22 Jan 2010 11:28:28 -0800

>session" to authenticate.

That assumes that the client was the one actually sending
the Status-Server. It could have been an attacker.

A client has very little to use to validate an incoming Access-Request
that was generated as a response to an Status-Server.

IOW, a server responding to a Status-Server sent to its auth port
may unintentionally authenticate a bogus session.

That's why I say that using Access-Accept as a response to
anything other than an Access-* is dangerous.

Cheers,
-Ignacio

---

From: Alan DeKok <[email-masked]>
Date: Fri, 22 Jan 2010 21:35:46 +0100

> that was generated as a response to an Status-Server.

  Hmm... OK.

> may unintentionally authenticate a bogus session.

  This requires that the attacker obtain the Request Authenticator from
the Access-Request, put it into a Status-Server, and send that to the
server before it receives the Access-Request.

  It's possible, but hard.

> anything other than an Access-* is dangerous.

  The use of Message-Authenticator means that the attacker won't be able
to sign the Status-Server, meaning the server won't respond.

  We can put some more text into the document highlighting the necessity
for using Message-Authenticator.

  Alan DeKok.

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 22 Jan 2010 12:46:42 -0800

>to sign the Status-Server, meaning the server won't respond.

Which means that the client MUST trust that the server was
properly written and/or configured and will not respond to
bogus Status-Server -- even if the client never generates
them.

A client has *no* reliable way to find out if an incoming
Access-Accept is for an Access-Request it sent or from an
Status-Server sent by an attacker (with a possibly problematic
server).

See why this is a slippery slope?

IMHO, people should be advised to NOT use this method of
checking the servers.

-Ignacio

---

From: Alan DeKok <[email-masked]>
Date: Sat, 23 Jan 2010 01:22:14 +0100

> Status-Server sent by an attacker (with a possibly problematic

  But this attack is possible in RADIUS without Status-Server.

  We can presume that the attacker possesses at least one "known good"
user password.  (i.e. via signing up for a temporary account).  Then
this attack can be performed at will: sniff an Access-Request, and
quickly replace it with a "fake" one containing the same Id && Request
authenticator, but with the "fake" CHAP-Password and CHAP-Challenge.

  The server will respond with Access-Accept, and authorize the other
session.

> See why this is a slippery slope?

  Oh, yes.  But the problem is mostly due to un-authenticated request
packets, and less so to the use of Access-Accept.

> IMHO, people should be advised to NOT use this method of

  Hmm... even though this attack is already possible in RADIUS?

  The only defense is to require that Access-Request (and Status-Server)
packets be signed.  RFC 5080 Section 2.2.2 makes this recommendation for
Access-Requests.  This document makes the same recommendation for
Status-Server.

  We can also presume that the RADIUS client && server will be
configured by people who communicate.  i.e. the "client" is also
partially the admin, who knows that the server supports signed
Status-Server, and therefore can safely enable it on the client.

  Alan DeKok.

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 22 Jan 2010 16:51:19 -0800

>  But this attack is possible in RADIUS without Status-Server.

Exactly. So, why are we trying to add yet another attack vector?

>packets, and less so to the use of Access-Accept.

Let's agree to disagree. IMO, the use of Access-Accept for a use
*other* than what it has always been intended for is opening
a can of worms with potentially unintended consequences.

A clean, simple design would call for specialized codes,
specially considering that there is plenty of unused code
points.

However, in the Security section, it should be mentioned that
both servers and clients can be attacked independently when
either one supports Server-Status, even if the other doesn't.

>  Hmm... even though this attack is already possible in RADIUS?

Yes, because it adds a new and different attack vector.

>packets be signed.

I disagree.

A much better defense (without altering the basic RADIUS paradigm)
would be to use another code for a response, one that cannot be
confused with any possible authentication.

Since the purpose of the Status-Server is to check whether
the server is ok, then the response should be such that 
cannot ever be confused *ever* with anything else.

Barring a solution where the server response cannot be confused,
my opinion against using this method stands.

>Status-Server, and therefore can safely enable it on the client.

Think of the case where one of the two parts has to support it
because *part* of your network supports it (say some clients
or some servers), just not all of it. The choice of using an
Access-Accept response opens new doors for attacks.

It would be enough that *part* of the network can't or doesn't
know how to deal with these new sets of Access-Accept and
the admin has a serious problem. Furthermore, in many cases,
servers or clients are usually not under the same admin SOC
which makes the mixed environment very likely.

But, like I mentioned in earlier emails, this is all academic
and it doesn't really matter much because this is just an
informational RFC. It would be a very different story if
it was intended for standards track.

Take care,
-Ignacio

---

From: Alan DeKok <[email-masked]>
Date: Sat, 23 Jan 2010 09:00:18 +0100

Ignacio Goyret wrote:
> IMO, the use of Access-Accept for a use

  I agree with that.  If the document had been a WG item, Status-Server
packets would have had a Status-Response packet.

> either one supports Server-Status, even if the other doesn't.

  OK.

  Alan DeKok.