Blank Password and Recommeded RFC standard

[Alan DeKok]

"Craig T. Hancock" <chancock at nd.edu> wrote:
> I am working with a vendor product that has implemented their own
> Radius and when trying to authenticate to their product they say
> that when using Challenge based authentication they handle blank
> passwords according to the RFC.

  Nonsense.  The RFC doesn't say you *have* to send a challenge.
Please ask them to quote the text they think is relevant, and explain
why.

> After reading the RFC I don't fully understand why blank passwords
> seemed to be acceptable.

  It could be construed as a bug in the original specification.

> Ultimately I don't understand why radius RFC has a provision to ask
> for a password if the original request is empty when doing two
> factor authentication.

  Because some authentication systems work by sending an identity
first, the server responds with a challenge, and the client responds
with a per-session password.  See X9.9 token cards.

> It would seem to me that if the User-Password field is empty (or
> what ever attribute is used with two-factor authentication) that
> Radius should interpret that with an Access-Reject.

  No.  I *think* you're referring to:

   Example: The NAS sends an Access-Request packet to the RADIUS Server
   with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
   just be a fixed string like "challenge" or ignored).  The server
   sends back an Access-Challenge packet ...

  So the User-Password doesn't have to be empty, it can have any
value, including a fixed string.

  The RFC *allows* for X9.9 challenge-response systems to start off
with a fixed or blank password.  It doesn't *require* the server to
respond to an empty User-Password with an Access-Challenge.

  If the server doesn't support X9.9 systems, then responding to an
empty User-Password with an Access-Challenge would be a waste of time.
99% of clients would treat it as Access-Reject, because they don't
expect a challenge.

  So ask the vendor what part of the RFC they think they're following,
and why.  Ask them *why* they're doing it, and what benefit they think
it has.  Odds are the sections of the RFC they quote won't say what
they think it says, and their whole reason for doing it is not because
it make sense, but "because the RFC says so".

  FreeRADIUS breaks a number of RFC suggestions for a number of good
reasons.  In some cases, the RFC's are plain wrong.

  Alan DeKok.