How to enable Freeradius to support a smart card with AES encryption algorithm?

[yao guoxian]

Thanks, Alan.
But I have lots of problems.
First, what is difference between challenge-response and chap?In my opinion,
challenge-response is a authentication mechanism and flow while chap is a
method to hide and transport user' password. In challenge-response, the
random challenge is produced by the radius server and has not length limited
while the 16 bytes random authenticator used in chap is produced by the  NAS
or the  client. Is  that  right?

Second,suppose we have enabled the NAS(client) and Freeradius to support our
specified attribute "My-Aes-Password" , how to write the new module to
handle the attribute? Is it like follows:
    1. code a program like
freeradius-parth/src/modules/rlm_example/rlm_exmple.c and name it as
rlm_aes;
    2. compile it and store the aes.exe file in  the /bin/ directory;
    3. edit the radiusd.conf as follow:
        #in the modules section
        ...
        exec aes{
                wait = yes;
                program ="/bin/aes %My_Aes_Password "
                input_pairs = request
                output_pairs = reply
       }
       ...
       authorize {
             preprocess
             chap
             mschap
             suffix
             sql
             aes
      }
      ...
   or we needn't compile the rlm_aes.c and just leave it to the Freeradius
to do what need to do ?

   Third , how to enable Freeradius and Nas(client) to support our new
attribute?Does it need to append the dictionary file a new entry?

regards
Guoxian

2007/2/1, Alan DeKok <aland at deployingradius.com>:
>
> yao guoxian wrote:
> > Hi!
> >     I have a smart card emluator which suports AES, not MD5 encryption
> > algorithm. Is it possible to enable Freeradius to support my smart card
> > emlulator?
>
>   Edit the code.
>
> >     I have an idea as follow:
> >     First,amending client agent (NAS) daemon program to make it send
> > chap-password which is produced with AES, not MD5.
>
>   Don't do that.  It isn't CHAP, and you will break a lot of things.
>
> > The usual md5
> > chap-password is produced as MD5( user-packet-ID+user-secret+16 bytes
> > authenticator), while the aes chap-password is produced as AES(16 bytes
> > authenticator) using user-secret as key.The usual md5 chap-passwor
> > attribute in an Access Request packet is as follow:
> > __________________________________________________
> >
> > |  code = 3 |  Length = 19  | user-packet-ID  |  16 bytes value|
> > __________________________________________________
> > While the aes chap-password replaced the 16 bytes value ( MD5(
> > user-packet-ID+user-secret+16 bytes authenticator)) with AES(16 bytes
> > authenticator).
> >     Second ,amending rlm-chap.c to alter it  to  use  AES  to  analyze
> > the  request packet.
> >     Is it practical? Appreciate any suggestions.
>
>   No, it's not practical.
>
>   What you're missing is that none of the NASes will do the AES
> calculation, so changing FreeRADIUS won't help.
>
>   If you control the software on the NAS, just invent a new attribute,
> "My-AES-Password", and use that.  That's what attributes are for.  Then,
> write a new module to support that attribute.  That's what modules are
> for.
>
>   Hacking existing attributes and modules is a recipe for disaster.
> Don't do it.
>
>   Alan DeKok.
> --
>   http://deployingradius.com       - The web site of the book
>   http://deployingradius.com/blog/ - The blog
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070203/c43f6da4/attachment.html>