Unpickable?
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