Blank Password and Recommeded RFC standard
Question, The RFC seems to have a provision on how to handle a Radius request with a blank password. As an option the Radius Server can send a request back to a client to stating that a password is needed enter password. However what I am trying to figure out is that is this a requirement of a the RFC or a recommendation. Thanks -- ****************************************************** Craig T. Hancock Systems Engineer, Infrastructure Services Office of Information Technology University of Notre Dame ******************************************************
"Craig T. Hancock" <chancock@nd.edu> wrote:
The RFC seems to have a provision on how to handle a Radius request with a blank password. As an option the Radius Server can send a request back to a client to stating that a password is needed enter password. However what I am trying to figure out is that is this a requirement of a the RFC or a recommendation.
The RFC requirements aren't absolute. You're free to break them in your local system, but doing so may cause catastrophic problems. In this case, what are you trying to do? Alan DeKok.
Alan DeKok wrote:
The RFC requirements aren't absolute. You're free to break them in your local system, but doing so may cause catastrophic problems.
In this case, what are you trying to do?
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. After reading the RFC I don't fully understand why blank passwords seemed to be acceptable. 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. 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.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Craig T. Hancock" <chancock@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.
participants (2)
-
Alan DeKok -
Craig T. Hancock