I just hit a really odd problem with a secrets. We were asked to use FreeRadius to provide IP addresses to an Ericsonn NAS. We set up the server and have some test clients with simple secrets. If those are right it works, if they are wrong it fails. Then we put in the secret for the Ericsonn (I can not put it in this note as it is someone else's secret and I do not know what else it might be the secret for, but privately I could make it available for testing). This secret is 13 digits long, mixed numbers and letters, looks reasonably random, and in the proper secret all the letters were upper case. However somehow one of the letters (an O) got put into the server in lower case. The server happily accepts Access-Request packets with an authenticator built from the all upper case secret, even though its secret was different, it was only the client which rejected the Access-Accept. Diagnosing this however was very difficult as we had no access to the Ericsonn box and any console messages it might log (we could only see what went on the wire and whether the connection succeeded). A quick look at the code did not find anywhere where the secret gets folded to all upper case (but I might have missed it) and if there were such folding it would be unfortunate if this was only done on checking the received packet not on generating the reply. I am new to RADIUS, and I could not find any rules about case folding for secrets, but I might have missed them. It could simply be one of those freak places where the MD5 checksum happens to be the same for the request but not the response, but that does not feel right. I am using 1.1.1 (I am also using JRadius which last time I looked only produced patches for 1.1.1, not 1.1.2). David
This has been explained before in this list and it's how RADIUS works. The Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication. The server then signs the response packet with it's version of the secret. The client doesn't trust the server and checks the signature. If the signature is not correct the client rejects the packet. The opposite is true with accounting packets - the client signs the request and the server checks the signature. The Message-Authenticator attribute can be used to sign the Access-Request packet which will cause the server to reject a packet with the an incorrect MA signature. David Goodenough wrote:
I just hit a really odd problem with a secrets.
We were asked to use FreeRadius to provide IP addresses to an Ericsonn NAS. We set up the server and have some test clients with simple secrets. If those are right it works, if they are wrong it fails.
Then we put in the secret for the Ericsonn (I can not put it in this note as it is someone else's secret and I do not know what else it might be the secret for, but privately I could make it available for testing).
This secret is 13 digits long, mixed numbers and letters, looks reasonably random, and in the proper secret all the letters were upper case. However somehow one of the letters (an O) got put into the server in lower case.
The server happily accepts Access-Request packets with an authenticator built from the all upper case secret, even though its secret was different, it was only the client which rejected the Access-Accept. Diagnosing this however was very difficult as we had no access to the Ericsonn box and any console messages it might log (we could only see what went on the wire and whether the connection succeeded).
A quick look at the code did not find anywhere where the secret gets folded to all upper case (but I might have missed it) and if there were such folding it would be unfortunate if this was only done on checking the received packet not on generating the reply.
I am new to RADIUS, and I could not find any rules about case folding for secrets, but I might have missed them.
It could simply be one of those freak places where the MD5 checksum happens to be the same for the request but not the response, but that does not feel right.
I am using 1.1.1 (I am also using JRadius which last time I looked only produced patches for 1.1.1, not 1.1.2).
David - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication.
I might have missed something here, sorry in advance ;-) Since the secret is incorrect, Freeradius wont be able to correctly decrypt the user-password. So authentication shouldn't be succesful ? (section 4.1 of http://www.freeradius.org/faq/). Have you got any pointer to the thread you are talking about (I haven't found it with a wuick googleing) ? Thibault
Most authentication methods don't use the secret as part of the password encoding and use independent information for encoding. PAP is the only authentication method that depends on the secret. For example CHAP uses the password, two random numbers and MD5 to encode the password. Thibault Le Meur wrote:
Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication.
I might have missed something here, sorry in advance ;-)
Since the secret is incorrect, Freeradius wont be able to correctly decrypt the user-password. So authentication shouldn't be succesful ? (section 4.1 of http://www.freeradius.org/faq/).
Have you got any pointer to the thread you are talking about (I haven't found it with a wuick googleing) ?
Thibault
Most authentication methods don't use the secret as part of the password encoding and use independent information for encoding.
PAP is the only authentication method that depends on the secret.
For example CHAP uses the password, two random numbers and MD5 to encode the password.
Thanks a lot, I understand your previous mail now. Thibault
On Wednesday 19 July 2006 13:55, Michael Lecuyer wrote:
This has been explained before in this list and it's how RADIUS works.
The Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication. Why then if the secret is a lot different does the server reject the client? Or is it just that MD5 can generate identical results from two different input strings, and we were just unlucky?
David
The server then signs the response packet with it's version of the secret. The client doesn't trust the server and checks the signature. If the signature is not correct the client rejects the packet.
The opposite is true with accounting packets - the client signs the request and the server checks the signature.
The Message-Authenticator attribute can be used to sign the Access-Request packet which will cause the server to reject a packet with the an incorrect MA signature.
David Goodenough wrote:
I just hit a really odd problem with a secrets.
We were asked to use FreeRadius to provide IP addresses to an Ericsonn NAS. We set up the server and have some test clients with simple secrets. If those are right it works, if they are wrong it fails.
Then we put in the secret for the Ericsonn (I can not put it in this note as it is someone else's secret and I do not know what else it might be the secret for, but privately I could make it available for testing).
This secret is 13 digits long, mixed numbers and letters, looks reasonably random, and in the proper secret all the letters were upper case. However somehow one of the letters (an O) got put into the server in lower case.
The server happily accepts Access-Request packets with an authenticator built from the all upper case secret, even though its secret was different, it was only the client which rejected the Access-Accept. Diagnosing this however was very difficult as we had no access to the Ericsonn box and any console messages it might log (we could only see what went on the wire and whether the connection succeeded).
A quick look at the code did not find anywhere where the secret gets folded to all upper case (but I might have missed it) and if there were such folding it would be unfortunate if this was only done on checking the received packet not on generating the reply.
I am new to RADIUS, and I could not find any rules about case folding for secrets, but I might have missed them.
It could simply be one of those freak places where the MD5 checksum happens to be the same for the request but not the response, but that does not feel right.
I am using 1.1.1 (I am also using JRadius which last time I looked only produced patches for 1.1.1, not 1.1.2).
David - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
David Goodenough -
Michael Lecuyer -
Thibault Le Meur