"Craig T. Hancock" <[EMAIL PROTECTED]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
