Greetings, I'm working on using FreeRadius to authenticate to our Cisco devices using CryptoCards. I've run into a couple of snags which I don't think can be fixed easily via configuration but will require code changes. Before I start doing anything code-wise, I wanted to see if anybody knew of a workaround. 1) Our tokens display the response in so-called 'phone number' formatting. FreeRadius knows about 4 different CryptoCard formattings according to x99passwd.sample: d7, d8, h7 and h8. Where a response would be formatted as '12345678' in d8 and '1235678' in d7, our tokens display '123-5678'. I was thinking I would either add a new CC encoding setting or modify the module to ignore dashes. But if there is another way I'd love to hear it. 2) The X99 module, if it is performing a resync, generates a State attribute which the authenticating device is expected to return unadultered in the response packet. However, the value includes NULL values in the middle of it. Our Cisco devices (both IOS and CatalystOS) appear to be using strcpy() or something similar to copy the State attribute and only return the value up to the embedded NULL as a result. Code already exists in the module to generate an ASCII state value, and I was planning on changing the module so that the ASCII value was always used. My reading of the relevant RFC tells me that this is in fact a Cisco bug, but I have not had good luck in the past convincing Cisco that my interpretation of RFC's is more correct than theirs. If you know of a way to work around these without hacking on the code, I'd appreciate knowing about it. Or if you have an opinion about how to best fix the above issues in the code, I'd be interested in that as well. Thanks in advance, -David Mitchell --
David Mitchell <mitchell@ucar.edu> wrote:
1) Our tokens display the response in so-called 'phone number' formatting. FreeRadius knows about 4 different CryptoCard formattings according to x99passwd.sample: d7, d8, h7 and h8. Where a response would be formatted as '12345678' in d8 and '1235678' in d7, our tokens display '123-5678'. I was thinking I would either add a new CC encoding setting or modify the module to ignore dashes. But if there is another way I'd love to hear it.
I'd add a new encoding.
2) The X99 module, if it is performing a resync, generates a State attribute which the authenticating device is expected to return unadultered in the response packet. However, the value includes NULL values in the middle of it. Our Cisco devices (both IOS and CatalystOS) appear to be using strcpy()
Yuck. That's a direct violation of the RFC's.
or something similar to copy the State attribute and only return the value up to the embedded NULL as a result. Code already exists in the module to generate an ASCII state value, and I was planning on changing the module so that the ASCII value was always used. My reading of the relevant RFC tells me that this is in fact a Cisco bug, but I have not had good luck in the past convincing Cisco that my interpretation of RFC's is more correct than theirs.
File a bug on bugs.freeradius.org that their implementation is broken. Maybe that will get their attention.
If you know of a way to work around these without hacking on the code, I'd appreciate knowing about it. Or if you have an opinion about how to best fix the above issues in the code, I'd be interested in that as well. Thanks in advance,
For the state problem, just print an ascii state. Alan DeKok.
Alan, those answers are pretty much what I expected. Once I started digging in, I had some other questions and dropped a note to Frank Cusack directly since he seems to be the author of most of that module. One big question I have now is if I should try to write patches against 1.0.5 or 1.1.0-pre0. There are pretty substantial differences between the two WRT the rlm_x99/rlm_otp code. Do you have a feel for when 1.1.0 will be released? Nothing specific of course, I'm just wondering about a ballpark. Days, months, years. Thanks for your help, -David Mitchell Alan DeKok wrote:
David Mitchell <mitchell@ucar.edu> wrote:
1) Our tokens display the response in so-called 'phone number' formatting. FreeRadius knows about 4 different CryptoCard formattings according to x99passwd.sample: d7, d8, h7 and h8. Where a response would be formatted as '12345678' in d8 and '1235678' in d7, our tokens display '123-5678'. I was thinking I would either add a new CC encoding setting or modify the module to ignore dashes. But if there is another way I'd love to hear it.
I'd add a new encoding.
2) The X99 module, if it is performing a resync, generates a State attribute which the authenticating device is expected to return unadultered in the response packet. However, the value includes NULL values in the middle of it. Our Cisco devices (both IOS and CatalystOS) appear to be using strcpy()
Yuck. That's a direct violation of the RFC's.
or something similar to copy the State attribute and only return the value up to the embedded NULL as a result. Code already exists in the module to generate an ASCII state value, and I was planning on changing the module so that the ASCII value was always used. My reading of the relevant RFC tells me that this is in fact a Cisco bug, but I have not had good luck in the past convincing Cisco that my interpretation of RFC's is more correct than theirs.
File a bug on bugs.freeradius.org that their implementation is broken. Maybe that will get their attention.
If you know of a way to work around these without hacking on the code, I'd appreciate knowing about it. Or if you have an opinion about how to best fix the above issues in the code, I'd be interested in that as well. Thanks in advance,
For the state problem, just print an ascii state.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
David Mitchell <mitchell@ucar.edu> wrote:
I have now is if I should try to write patches against 1.0.5 or 1.1.0-pre0. There are pretty substantial differences between the two WRT the rlm_x99/rlm_otp code. Do you have a feel for when 1.1.0 will be released?
Days. I'd like to do it this week, if at all possible. Alan DeKok.
On Jan 11, 2006, at 4:28 PM, Alan DeKok wrote:
David Mitchell <mitchell@ucar.edu> wrote:
I have now is if I should try to write patches against 1.0.5 or 1.1.0-pre0. There are pretty substantial differences between the two WRT the rlm_x99/rlm_otp code. Do you have a feel for when 1.1.0 will be released?
Days. I'd like to do it this week, if at all possible.
Cool. I'll plan on working against 1.1.0 and hopefully any patches I come up with will be ready in time for consideration to be included in 1.1.1. -David Mitchell
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html
participants (2)
-
Alan DeKok -
David Mitchell