Radius Authentication Server Project
We follow on the Radius Server Project with an challenge-response extension that implements One Time Passwords
NAME mini-radius SYNOPSIS mini-radius [-vR -k shared-key -p port] -h host username password mini-radius [-vWR -k shared-key -p port] -h host username password-seed mini-radius [-vLR -k shared-key -p port] password-file mini-radius [-v -n num] password-seed DESCRIPTION The radius client/server code implemented as the previous project is extended to implement a One Time Passwords (OTP) authentication scheme, described in this man page. The program runs as either client or server, depending on whether the -h option is present. Without the -h option, the program runs as server. The password-file is opened and the server listens for authentication requests on the specified port, or the default port. If client, using password authentication is as the previous project. With the -W options, only the user name is sent in the initial message to the server, and a challenge is received in return. The client then sends the response to the challenge as the username/password pair of an authentication request, and receives the accept/reject result, as per RFC 2865. An access-request that does not have a password attribute triggers an access-challenge response from the server. An access-request that has a password attribute has either a 16 or 20 byte password. According the password attribute length, a password authentication is performed (16 bytes) or the second half of an OTP authentication is concluded (20 bytes). OPTIONS -k the shared key for encrypting, the default is pa55word0 -p the port the server listens (is listening) on, the default is 1812 -h the radius server hostname -v Verbose. Helpful debugging output to stdout. -R no randomness. The stream of random bytes used by the program is set to 1, 2, 3, ... -L when run as a server, do not loop; answer one full request and terminate -W use OTP scheme for authentication. -n the option overrides the behavior and prints out the n-times iteration of the SHA-1 hash of the password-seed, formated as base 16 with characters 0-9, a-f. FILE FORMAT Username/Passwords are stored in file on the server. It is of the format (name:password\n)+ where name and password are non-empty strings from (a-z, A-Z, 0-9)*. For OTP Authentication, the password file is updated. OTP AUTHENTICATION In addition to the Radius Server implementation, this version will be extended to support a form of one-time password. Let H be the SHA-1 hash-function. The user shall know the password seed s. The server shall store in the password file Hi(s), the i-th iterate of the seed hashed by H. 1) The Access-Request will have the User-Name attribute. 2) The server shall respond with an Access-Challenge, with the Reply-Message Attribute the current Hi(s) in its database, encoded in base 16 using the the character set 0-9, a-f. 3) The client shall reissue the Access-Request, including the User-Name Attribute as the original request, and the User-Password Attribute the response Hi-1(s) to the challenge. 4) The server issues an Access-Accept or Access-Reject. The server replaces Hi(s) by Hi-1(s) in the password database, for the next authentication. The server does not know any hash pre-images, and must learn them from the client in the response. The client generates Hi-1(s) for whichever i requested, by hashing forward s until a match with the challenge, then returning the previous value in the hash chain. Note: Per the RFC, the Reply-Message attribute is text, and the User-Password attribute is string encrypted per the RFC. Because MD4 is 16 bytes, and SHA-1 is 20 bytes, the method of section 5.2 of the RFC is followed, to form what in that section is denoted by b2. The server will infer that OTP is requested by the client when it receives an Access-Request with a User-Name Attribute but no User-Password Attribute. The server can remember the identifier for the next round of messages, or the server can infer from the length of the password attribute, 16 byte or 20 bytes, which method the client is requesting. The client will check and never respond to a challenge with either the raw password-seed, or its first hash. The client will impose reasonable limits on the largest number of iterations it will attempt in generating the response. NOTES The OTP has not be subjected to a rigorous security analysis. HISTORY First introduced in Spring 2017. BUGS The client hashes forward indefinitely. The server could maintain and send the pair (pw,i) The client can check i for responableness, and that his)=pw, as proof that the server is a legitimate challenger. The presence of a whitespace delimited password pair signals to the server to use OTP for verification. The length of the password attribute clearly signals the client's selected password verification method. LAST UPDATED 26 April 2017
Detailed description
Please read the RFC carefully, including the discussion of text versus string for attributes, and which Attributes are required or forbidden in which messages.
Author: Burton Rosenberg
Created: 18 April 2017
Last Update: 26 April 2017