x99 Token Module Problems

[David Mitchell]

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 at 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