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 program runs as either client or server, depending on the whether the -h option
is present. If server, the password-file is opened and the servers listens on the
port of authentication requests. If client, the given username password is
authenticated to the server/port as given in the option, and YES or NO is
printed, according to the result.
The protocol is described in RFC 2865, simplified for only password authentication.
The access-request (code 1) packet sent by the client has two attributes, user-name
(code 1) and user-password (code 2); and the response is either an access-accept
(code 2) or an access-reject (code 3).
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.
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 an 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