Unpickable?
Radius Authentication Server Project
We implement a simple Radius Authentication server, mostly compliant with the protocol given RFC 2865: Remote Authentication Dial In User Service
NAME
mini-radius
SYNOPSIS
mini-radius [-vR -k shared-key -p port] -h host username password
mini-radius [-vLR -k shared-key -p port] password-file
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
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)*.
NOTES
The program will have simplifying limitations, as given in the detailed
project instructions.
BUGS
The cryptography uses MD5 and is therefore might not be secure. The username
is not included in the reply packet and therefore not involved in the response
authenticator. The RFC allows a username attribute, but not the password attribute,
in the reply packet, and perhaps should be required.
HISTORY
First introduced in Spring 2017.
LAST UPDATED
26 April 2019
Detailed description
Because the algorithm for masking the password is complicated by variable length passwords, and because the length of the password should not be disclosed, our mini-radius will MD5 hash the password to exactly 16 bytes, and use the hashed-password in the user-password attribute.
This is a simple one round protocol, consisting of the client leading off with a UDP packet to the server, and the server responding with a UDP packet back to the client. The server port is well-known, and the client port can be ephemeral.
The initial packet from client to server is an Access-Request followed by an User-Name attribute and an User-Password attribute, in any order. The response packet from server to client is an Access-Accept or an Access-Reject, as the case may be, with no attributes.
ubuntu@ip-172-30-1-169:~$ sudo tcpdump -i lo -X port 1812 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes 14:52:46.572877 IP localhost.34598 > localhost.radius: RADIUS, Access-Request (1), id: 0x01 length: 47 0x0000: 4500 004b fde0 4000 4011 3ebf 7f00 0001 E..K..@.@.>..... 0x0010: 7f00 0001 8726 0714 0037 fe4a 0101 002f .....&...7.J.../ 0x0020: 38c4 87b9 8273 d799 9d69 ed58 5c79 d584 8....s...i.X\y.. 0x0030: 0109 7069 6b61 6368 7502 124d d0fe ecbd ..pikachu..M.... 0x0040: 7d95 7f50 3e9d 0e7b a60c f2 }..P>..{... 14:52:46.573237 IP localhost.radius > localhost.34598: RADIUS, Access-Accept (2), id: 0x01 length: 20 0x0000: 4500 0030 fde1 4000 4011 3ed9 7f00 0001 E..0..@.@.>..... 0x0010: 7f00 0001 0714 8726 001c fe2f 0201 0014 .......&.../.... 0x0020: 5a84 5bda c3d7 5068 05d9 8749 7a49 ebc6 Z.[...Ph...IzI.. Legend: client > server Code Identifier Length Request-Authenticator Type Length String Type Length String server > client Code Identifier Length Response-Authenticator
Sample Run using No Randomness
Running the test targets in the makefile, with the -R (no randomness) option, verbose.
The Cryptography
The client must be assured that the server response is authentically from the server, and has not been replayed, modified, or forged. A form of Message Authentication Code (MAC) is used to cryptographically attest to the authenticity and integrity of the response.
The MAC is a signature on the return message based on a secret shared between the client and the server. Knowledge of the secret is required to correctly compute the MAC, it is exponentially unlikely to guess the MAC, and computationally infeasible to forge a MAC if the secret is unknown. It is important to calculate this MAC precisely. The formula is in Section 3, paragraph Response-Authenticator.
The password is encrypted using a Vernon Cipher, see the User-Password attribute, section 5.2.
A pseudo-random pad (key stream) is needed for the Vernum cipher. The pad is computed by both the client and server by hasing the concatenation of secret shared key and the Request-Authenticator by the MD5 hash function. The MD5 hash function is cryptographically strong — i.e. there is strong circumstantial evidence that the function acts as if it is assigning a randomly chosen output for each input.
The openssl library has the MD5 function, see [man 3 md5].
Cryptographic Hashes
MD5 is a function that approximates (ad-hoc) a cryptographic hash. A cryptographic hash is defined in terms of algorithmic complexity theory and probability. It is a function f(x)=y from strings to strings that has complexity properties,
In the definition of preimage hardness, we give the attacking algorithm black-box access to the function f — the algorithm can query the value of f(x) for its choice of x.
The complexity property then implies mathematically a security property, such as:
Authenticator Unforgability, any polynomial algorithm, given black box access to the has function f, and unlimited transcripts of correct authentication protocol runs, (but not the shared secret) can only produce a correct Response Authenticator to a new Request Authenticator with exponentially small probability.
Authentication Logic
______
request / pw |
packet +--+ | file |
| | +------+
| | |
+-+ | | +-+ |
|/| | | |/| +-----+ +-----+
user-name ------------------------->|/| ======> |/|--->| SEL |--->| MD5 |
|/| | | |/| +-----+ +-----+
+-+ | | +-+ |
| | |
+-+ | | +-+ V
+-----+ +-----+ |/| | | |/| +-----+ +----+
user-passwd --->| MD5 |--->| ENC |--->|/| ======> |/|--->| ENC |--->| =? |---> Y/N
+-----+ +-----+ |/| | | |/| +-----+ +----+
^ ^ + + | | +-+ ^ ^
| | | | | |
shared-key --+ | +-+ | | +-+ | +-- shared-key
| |/| | | |/| |
auth request ---------------+----->|/| ======> |/|------+
|/| | | |/|
+-+ | | +-+
| |
MD5 - hash function | | the request packet includes user-name,
ENC - encryption +--+ encrypted user-passd, auth request
SEL - select pw by username chosen randomly, and the header: code,
ID and length.
MAC Calculation
+-+ | | +-+ +-------+ +-+ | | +-+
ACC_REQ |/| | | |/| | Auth | |/| | | |/| ACC_ACE/ACC_REJ
Id |/| ======> |/| | Dec- | |/|---+------->|/| Id
Length |/| | | |/| | ision | |/| | | | |/| Length
+-+ | | +-+ +-------+ +-+ | | | +-+
| | | | |
| | +---------------+ | |
+-+ | | | ++ | | +-+
| | | | | | \ | | | |
Request | | | | 128 +-->| \ 128 | | | | Response
Authenti. | | ==========/===========>|MD5\ ==/===========>| | Authenticator
| | | | +------->| / | | | |
| | | | | | / | | | |
+-+ | | +------------+ | / | | +-+
| | | shared key | ++
+----------+ | | +------------+
| username | -------------------------> attributes
+----------+ | | in
+----------+ | | any
| pw (enc) | -------------------------> order
+----------+ | |
Hash and encryption test vectors
pwd=password, md5(pwd)=5f4dcc3b 5aa765d6 1d8327de b882cf99 buf.data: 02 -Access-Accept 01 -Identifier 0014 - Length (20 bytes) d39e0d8d 69f8cd89 10616f73 9ccac085 -authenticator received buf.password: 70613535 776f7264 30 -"pa55word0" buf=02010014 d39e0d8d 69f8cd89 10616f73 9ccac085 70613535 776f7264 30 md5(buf)=63905cc0 917fab66 f0738ebd 30a90f19
Author: Burton Rosenberg
Created: 28 March 2017
Last Update: 4 April 2022