Hoạt động của Radius Server và WebAdmin trên WAN đơn giản - Chương 4 potx

33


Chương IV:
GIAO THỨC RADIUS

Có hai giao thức RADIUS mô tả về:
 [Giao thức RADIUS1] Xác nhận quyền (authentication), phân quyền (authorization),
thông tin cấu hình giữa máy chủ quản lý truy cập mạng (Network Access Server -
NAS) mà có các yêu cầu cần xác nhận và máy chủ xác nhận quyền dùng chung
(Shared Authentication Server).
 [Giao thức RADIUS2] Thông tin về tài khoản giữa NAS và máy chủ quản lý tài khoản
dùng chung (Shared Accounting Server).
 RADIUS được xây dựng dựa trên giao thức lớp transport nào?
Một câu hỏi thường được đặt ra là tại sao RADIUS lại sử dụng giao thức UDP thay vì TCP ở
lớp transport. UDP được chọn vì một số chỉ tiêu kỹ thuật nghiêm ngặt được đặt ra.
RADIUS thật ra là một giao dòch (transaction) được xây dựng dựa trên giao thức có các tính
chất chính như sau:
1. Nếu như yêu cầu (request) gởi tới máy chủ xác nhận quyền sơ cấp (primary
authentication server) thất bại, thì yêu cầu này phải được gởi tới máy chủ sơ
cấp (secondary server). Để thực hiện yêu cầu này, một bản sao yêu cầu phải
được lưu trên lớp transport để cho phép việc truyền luân phiên. Điều này có
nghóa là phải có timers cho việc truyền lại (retransmission).
34

2. Các đòi hỏi về thời gian của RADIUS rất khác biệt so với TCP. Một mặt,
RADIUS không yêu cầu "câu trả lời" (responsive) về việc dò tìm dữ liệu bò
mất. User sẳn sàng chờ trong nhiều giây để cho việc xác nhận quyền
(authentication) được hoàn tất. Việc truyền lại thường xảy ra đối với TCP dựa
trên thời gian truyền nhận trung bình (average round trip time) không cần thiết
nữa, kể cả thời gian hao tốn cho việc nhận biết phản hồi về (acknowledgement

overhead). Mặt khác, user không thể chờ đợi quá lâu trong nhiều phút cho việc
xác nhận quyền. Việc phải chờ quá hai phút để dữ liệu được truyền đi tin cậy
là không hữu ích. Việc sử dụng luân phiên nhanh chóng server sẽ cho phép
user truy cập được vào mạng trước khi họ "bỏ cuộc".
3. Trạng thái rất tự do của RADIUS đã đơn giản hóa việc sử dụng UDP. Các
clients và servers có thể đăng ký vào hoặc ra khỏi mạng; Hệ thống bò khởi
động lại vì một lý do nào đó; Nguồn điện bò mất… Các sự kiện bất thường
(anomalous events) này nói chung sẽ không gây nguy hiểm nếu như có những
timeouts tốt và xác đònh được các cầu nối TCP đã bò đứt. Tuy nhiên UDP hoàn
toàn bỏ qua các sự cố đặt biệt này; Các clients và servers có thể mở một
"chuyến vận chuyển dữ liệu" UPD ngay lập tức và để nó tự nhiên truyền trên
mạng với các sự kiện có thể có.
4. UPD đơn giản hóa việc thực hiện (implementation) server. những phiên bản
trước, server được thực hiện đơn luồng (single threaded), có nghóa là mỗi lúc
chỉ có 1 yêu cầu được nhận, xử lý và trả về. Điều này không thể quản lý được
trong môi trường kỹ thuật an toàn quay vòng (back-end security mechanism)
dùng thời gian thực (real-time) (1 hoặc nhiều giây). Hàng đợi yêu cầu của
server sẽ bò đầy, và trong một môi trường có hàng trăm người được yêu cầu xác
nhận quyền trong mỗi phút, thời gian quan vòng của yêu cầu (request turn-
35

around time) sẽ lớn hơn nhiều so với thời gian mà user mong đợi (Việc tìm tiếp
trong một cơ sở dữ liệu hoặc trên một DNS chiếm mất trên 30 giây). Do vậy,
giải pháp được chọn là thực hiện server chế độ đa luồng (multi-threaded) với
UDP. Những quá trình (processes) độc lập sẽ được sinh ra (spowned out) trên
server ứng với mỗi yêu cầu (request) và những quá trình này sẽ trả lời trực tiếp
với các NAS khách bằng gói UDP tới lớp truyền dẫn chính (original transport)
của client.
II. Giao thức RADIUS1:
1. Cơ chế hoạt động (operation)

Khi một client được đònh cấu hình để sử dụng RADIUS, thì bất cứ user nào của client đều giới
thiệu những thông tin xác nhận quyền (authentication information) với client. Đó có thể là dấu
nhắc lệnh đăng ký vào mạng (login prompt) yêu cầu user nhập tên và mật khẩu vào. User có
thể lựa chọn việc sử dụng protocol thích hợp để thực hiện giới thiệu những thông tin này bằng
các gói dữ liệu (packets), chẳng hạn như PPP (Point to Point Protocol).
Mỗi lần client nhận được thông tin như vậy, nó có thể chọn dùng RADIUS để xác nhận
quyền. Client sẽ tạo ra một "yêu cầu truy cập" (Access-Request) chứa các thuộc tính như tên,
mật khẩu của user, số hiệu (ID) của client và số hiệu cổng (port ID) mà user sẽ truy cập vào.
Mật khẩu khi nhập vào sẽ được ẩn (phương pháp dựa trên giải thuật RSA Message Digest
Algorithm MD5).
"Yêu cầu truy cập" (Access-Request) sẽ được gửi cho RADIUS thông qua mạng. Nếu không
có trả lời trong một khoảng thời gian quy ước thì yêu cầu sẽ được gửi lại. Client cũng có thể
chuyển (forward) yêu cầu cho các server dự phòng trong trường hợp server chính bò tắt hoặc
hư hỏng hoặc hoạt động theo kiểu round-robin.
36

Mỗi khi RADIUS server nhận được yêu cầu, nó sẽ xác nhận client gởi. Những yêu cầu từ các
client nào không chia sẽ thông tin bảo mật (shared secret) với RADIUS sẽ không được xác
nhận và trả lời (silently discarded). Nếu client là hợp lệ, RADIUS server sẽ tìm kiếm trong cơ
sở dữ liệu (CSDL) user có cùng tên trong yêu cầu. Chỉ mục của user (user entry) trong CSDL
sẽ chứa danh sách các đòi hỏi cần thiết cho phép user truy cập vào mạng. RADIUS luôn luôn
xác nhận mật khẩu của user và có thể cả số hiệu của client và port mà user được phép truy
cập.
RADIUS server có thể yêu cầu các server khác xác nhận yêu cầu. Lúc đó RADIUS đóng vai
trò của một client.
Nếu bất cứ điều kiện nào không được thỏa, RADIUS server sẽ gởi một trả lời "từ chối truy
cập" (Access-Reject) biểu thò rằng yêu cầu của user là không hợp lệ. Server có thể kèm một
thông báo dạng văn bản (text message) trong Access-Reject để client có thể hiển thò cho user.
Không có một thuộc tính nào khác được phép chưa trong Access-Reject.
Nếu tất cả các điều kiện đều được thỏa và RADIUS server muốn đưa ra một yêu cầu đòi hỏi

user phải trả lời, thì RADIUS sẽ gởi một trả lời "đòi hỏi truy cập" (Access-Challenge), nó có
thể dưới dạng một thông báo dạng văn bản được hiển thò cho user bởi client hoặc là một thuộc
tính trạng thái (State attribute). Client sẽ nhận Access-Challenge, và nếu nó được trang bò
challenge/response, nó sẽ hiển thò thông báo nhắc nhở user trả lời yêu cầu. Sau đó client sẽ
gửi lại (re-submit) "yêu cầu truy cập" gốc (original Access-Request) với một số hiệu yêu cầu
(request ID) mới, nhưng thuộc tính tên - mật khẩu được lấy từ thông tin vừa mới nhập vào, và
kèm luôn cả thuộc tính trạng thái từ Access-Challenge. RADIUS server có thể trả lời "yêu
cầu truy cập" mới bằng "chấp nhận truy cập" (Access-Accept), "từ chối truy cập" (Access-
Reject) hoặc một "đòi hỏi truy cập" (Access-Challenge) khác.
Nếu cuối cùng tất cả các điều kiện được thỏa, thì danh sách các giá trò cấu hình cho user được
37

đặt vào trả lời "chấp nhận truy cập" (Access-Accept). Các giá trò này bao gồm kiểu của dòch
vụ (ví dụ: SLIP, PPP, Login user) và các giá trò cần thiết để cấp phát dòch vụ này. Tỉ dụ như
đối với SLIP hay PPP, các giá trò này có thể là đại chỉ IP, đòa chỉ mạng con (subnet mask),
MTU, phương pháp nén và số hiệu lọc gói (filtering packet ID). chế độ ký tự (character
mode), các giá trò này có thể là giao thức (protocol) và tên máy chủ (host).
2. Dạng của gói (packet format)
Một cách chính xác, một gói RADIUS được bao bọc trong trường dữ liệu của gói UDP (UDP
data field), và trường đòa chỉ đích (UDP Destination Port field) có số hiệu cổng là 1645. Khi
gói trả lời được tạo ra, số hiệu cổng của đòa chỉ nguồn và đích được bảo lưu.
Một gói dữ liệu của RADIUS được đònh dạng như sau (các trường được gởi đi từ trái sang
phải).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |

| |
| |
38

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes
+-+-+-+-+-+-+-+-+-+-+-+-+-

a. Trường mã (code): 1 byte
Xác đònh kiểu của gói RADIUS. Gói có mã không hợp lệ sẽ không được xác nhận và trả lời
(silently discarded).
(decimal)
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
1. Access-Challenge
12 Status-Server (experimental - thực tế)
1. Status-Client (experimental - thực tế)
1. Reserved (dự trữ)
3
39

Accounting-Request/ Accounting-Response sẽ được trình bày ở giao thức RADIUS2.

b. Trường danh hiệu (Identifier): 1 byte
Dùng so trùng yêu cầu (request) và trả lời (reply).

c. Trường độ dài (length): 2 bytes

Biểu thò độ dài của gói bao gồm các trường mã (code), danh hiệu (identifier), độ dài
(length), xác nhận (authenticator), thuộc tính (attribute). Những byte nằm ngoài khoảng
quy đònh bởi trường length sẽ được coi là những byte thừa, và sẽ bò bỏ qua khi nhận.
Nếu gói ngắn hơn giá trò trường length, nó sẽ không được xác nhận và trả lời (silently
discarded). Giá trò nhỏ nhất của trường length là 20, giá trò lớn nhất là 4096.
d. Trường xác nhận (authentication): 16 bytes
Giá trò của trường xác nhận được dùng để xác nhận sự trả lời từ RADIUS server và nó được
dùng trong thuật toán ẩn mật khẩu (password hiding algorithm). MSB (the most significant
byte) sẽ được gởi trước.
 Bộ xác nhận yêu cầu (Request Authenticator)
Trong các gói "yêu cầu truy cập" (Access-Request), giá trò của trường xác nhận
(authenticator field) là một số ngẫu nhiên 16 byte được gọi là bộ xác nhận yêu cầu
(request authenticator). Giá trò này phải không thể được dự đoán trước (unpredictable) và
duy nhất (unique) trong suốt thời gian sống của "thông tin bí mật" (secret) (mật khẩu dùng
chung giữa client và RADIUS server); Vì nếu có sự lặp lại của giá trò này có nghóa là một
nhân vật nào đó (attaker) có thể trả lời câu hỏi này không cần sự xác nhận của RADIUS
40

server. Do đó bộ xác nhận yêu cầu nên có giá trò toàn cục (global) và duy nhất theo thời
gian (temporal uniqueness). Mặc dù giao thức RADIUS không có khả năng ngăn cản sự
nghe lén phiên xác nhận (authenticated session) qua đường dây, nhưng việc sinh ra các giá
trò không thể dự đoán trước cho bộ xác nhận yêu cầu có thể hạn chế rất nhiều sự kiện này.
NAS và RADIUS server chia sẻ "thông tin bí mật". Thông tin bí mật dùng chung này có
được sau khi giá trò của "bộ xác nhận yêu cầu" được đưa vào bộ băm một chiều MD5
(one-way MD5 hash) để tạo ra một giá trò số 16 byte. Giá trò này được XOR với mật khẩu
mà user nhập vào, kết quả sẽ được đặt vào thuộc tính User-Password trong gói Access-
Request.
 Trường xác nhận trong gói "trả lời" (Response Authenticator)
Giá trò của trường xác nhận (authenticator field) trong các gói Access-Request, Access-
Reject, Access-Challenge được gọi là bộ xác nhận trả lời (Response Authenticator). Giá

trò này được tính bởi băm một chiều MD5 chuỗi các byte của các trường mã, danh hiệu, độ
dài, xác nhận của gói "yêu cầu truy cập", và cộng thêm các thuộc tính trả lời và thông tin
bí mật dùng chung.
ResponseAuth= MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
b. Trường thuộc tính (Attributes)
Có những thuộc tính có nhiều phiên bản (instances). Những thuộc tính cùng loại được giữ
nguyên thứ tự. Đối với mỗi loại gói chỉ cho phép các thuộc tính nhất đònh mà thôi.
3. Kiểu của gói (packet types)
Kiểu của gói được xác đònh bởi trường mã (code field) chiếm byte đầu tiên của gói RADIUS.
3.1- Gói "yêu cầu truy cập" (Access-Request)
41

Gói Access-Request được gởi tới RADIUS server. Nó chuyên chở thông tin dùng để xác đònh
xem user có được phép truy cập vào NAS và các dòch vụ được chỉ đònh hay không. Trường mã
của gói phải có giá trò 1. Gói Access-Request phải chứa thuộc tính User-Name, User-
Password hoặc CHAP-Password , và có thể chứa các thuộc tính NAS-IP-Address, NAS-
Identifier, NAS-Port, NAS-Port-Type.
Trường danh hiệu (Identifier field) phải được thay đổi khi nội dung của trường thuộc tính bò
thay đổi hoặc là đã nhận được trả lời hợp lệ cho yêu cầu trước đó. Trong trường hợp phải gởi
lại gói (retransmission), trường danh hiệu không được thay đổi.
3.2- Gói "chấp nhận truy cập" (Access-Accept)
Gói Access-Accept được gởi trả bởi RADIUS server khi tất cả các giá trò thuộc tính của gói
Access-Request . Nó cung cấp thông tin cấu hình cần thiết để cấp phát các dòch vụ cho user.
Trường mã của gói phải có giá trò 2. Gói Access-Accept nhận được ở NAS phải có trường
danh hiệu trùng khớp với gói Access-Request tương ứng đã gởi trước đó và phải có trường xác
nhận (Response Authenticator) phù hợp với thông tin bí mật dùng chung (shared secret).
3.3- Gói "từ chối truy cập" (Access-Reject)
Gói Access-Reject được gởi trả từ RADIUS server khi có giá trò thuộc tính không được thỏa.
Trường mã của gói phải có giá trò 3. Gói có thể chứa 1 hoặc nhiều thuộc tính Reply-Message
với một thông báo dạng văn bản mà NAS sẽ hiển thò nó với user. Trường danh hiệu của gói

Access-Reject chính là bản sao của gói Access-Request tương ứng.
3.4- Gói "đòi hỏi truy cập" (Access-Challenge)
Gói Access-Challenge được RADIUS server gởi đến user đòi hỏi thêm thông tin cần thiết mà
user phải trả lời. Trường mã của gói phải có giá trò 11. Gói có thể chứa 1 hoặc nhiều thuộc
tính Reply-Message và có thể có 1 thuộc tính State. Các thuộc tính khác không được xuất hiện
42

trong gói Access-Challenge. Trường danh hiệu của gói Access-Challenge phải trùng khớp với
gói Access-Request tương ứng đã gởi trước đó và phải có trường xác nhận (Response
Authenticator) phù hợp với thông tin bí mật dùng chung (shared secret). Nếu NAS không được
trang bò challenge/response thì gói Access-Challenge nhận được sẽ coi như là gói Access-
Reject. Nếu NAS được trang bò chức năng challenge /response và gói Access-Challenge nhận
được là hợp lệ thì NAS sẽ hiển thò thông báo và yêu cầu user trả lời thông tin mà RADIUS
server yêu cầu. Sau đó NAS sẽ gởi gói Access-Request gốc nhưng với danh hiệu yêu cầu
(request ID) và xác nhận yêu cầu (request authenticator) mới, đồng thời thuộc tính User-
Password cũng được thay thế bởi thông tin trả lời của user (đã được mã hóa) và có thể bao
gồm cả thuộc tính State từ gói Access-Challenge.
4. Các thuộc tính (attributes)
Các thuộc tính của RADIUS, chứa trong các gói yêu cầu-trả lời, mang thông tin xác nhận
quyền, phân quyền, cấu hình cần thiết để cấp phát các dòch vụ cho user. Giá trò trường độ dài
của gói RADIUS sẽ quy đònh điểm kết thúc của các thuộc tính trong gói. Dạng của thuộc tính
như sau:

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

43

 Trường kiểu (Type): 1 byte
Đặc trưng cho 256 loại thuộc tính có giá trò từ 0 đến 255. Đây là những con số quy ước
(tham khảo thêm trong tài liệu draft-ietf-radius-radius-05).
RADIUS server và client có thể bỏ qua các thuộc tính có kiểu không xác đònh.
Ví dụ:
Kiểu Mô tả
1 User-Name
2 User-Password
3 CHAP-Password
4 NAS-IP-Address
5 NAS-Port
6 Service-Type
7 Framed-Protocol
8 Framed-IP-Address
9 Framed-IP-Netmask
10 Framed-Routing
11 Filter-Id
12 Framed-MTU
44

…………….

 Trường độ dài (Length): 1 byte
Biểu thò độ dài của thuộc tính cho các trường kiểu, độ dài và giá trò. Nếu thuộc tính
trong gói Access-Request có trường độ dài không hợp lệ thì RADIUS server sẽ trả
về gói Access-Reject. Nếu thuộc tính trong các gói Access-Reject, Access-Accept,
Access-Challenge có trường độ dài không hợp lệ thì NAS client sẽ xem như là gói
Access-Reject hoặc là không xác nhận và trả lời (silently discarded).
 Trường giá trò (Value):

Dạng và chiều dài của trường giá trò được xác đònh bởi trường Kiểu (Type field) và
trường độ dài (Length field). Có 4 loại dữ liệu cho trường giá trò như sau:
Loại dữ liệu độ dài
String 0-253 bytes
Address 32 bits, MSB đứng trước
Interger 32 bits, MSB đứng trước
Time 32 bits, MSB đứng trước. (Tính từ 00:00:00 GMT 1/1/1970).
5. Ví dụ
Dạng gói cụ thể khi user telnet đến một máy chủ chỉ ra (specified host) sẽ như thế nào?
 Giả sử NAS có đòa chỉ là 199.200.201.9 gởi một gói UDP dạng Access-Request tới
RADIUS server cho user tên jerry đăng ký truy cập tại port 4 có dạng như sau:
45

Code = 1 (Access-Request)
ID = 0
Request Authenticator = số 16 byte ngẫu nhiên
Attributes :
User-Name = "jerry"
User-Password = [mật khẩu16 byte XOR MD5("thông tin bí mật chung", "bộ
xác nhận quyền")]
NAS-IP-Address = 199.200.201.9
NAS-Port = 4
 Giả sử RADIUS server xác nhận quyền của jerry và gởi một gói UDP dạng Access-
Accept tới NAS để báo cho NAS hãy telnet jerry tới máy chủ 199.200.201.4 .
Code = 2 (Access-Accept)
ID = 0 (giống như trong Access-Request)
Response Authenticator = [16 byte băm MD-5 (code=2,
Id=0, Request Authenticator của yêu cầu ở trên, các thộc tính trả lời, "thông tin
bí mật dùng chung"]
Attributes:

Service-Type = Login-User
Login-Service = Telnet
46

Login-Host = 199.200.201.4
III. Giao thức RADIUS2:
1. Cơ chế hoạt động (operation)
Khi client được cài đặt để sử dụng RADIUS Accounting, thì lúc bắt đầu cấp phát dòch vụ
client sẽ sinh ra một gói "bắt đầu cấp phát tài khoản" (Accounting Start packet) mô tả kiểu
của dòch vụ sẽ được cấp phát và user sẽ được cấp phát dòch vụ đó; sau đó gửi gói này đến
RADIUS Accounting server mà tới lượt nó sẽ gửi lại một thông báo nhận biết
(acknowledgement) là gói đã được nhận. Lúc kết thúc cấp phát dòch vụ client sẽ sinh ra một
gói "kết thúc cấp phát tài khoản" (Accounting Stop packet) mô tả kiểu của dòch vụ đã được
cấp phát và các thông tin thống kê có thể lọc lựa như thời gian trôi qua (elapsed time), các
byte nhập/xuất (input / output bytes), các gói nhập/xuất (input/output packets); sau đó gửi gói
này đến RADIUS Accounting server mà tới lượt nó sẽ gửi lại một thông báo nhận biết
(acknowledgement) là gói đã được nhận.
"Yêu cầu cấp phát tài khoản" (Accounting-Request) [của cả hai loại Start và Stop] được gửi
cho RADIUS Accounting server qua mạng. Thường thì client sẽ tiếp tục cố gắng gửi gói
Accounting-Request sau mộ khoảng thời gian nhất đònh cho tới khi nó nhận được phản hồi
(acknkowledgement).
Client có thể gởi tiếp (forward) cho các server khác trong trường hợp server chính bò tắt hoặc
hỏng. Trong trường hợp này RADIUS Accounting server đóng vai trò của một client.
1. Dạng gói (Packet format)
Giống như giao thức RADIUS1, có 4 trường Code, Length, Authenticator, Attributes và chỉ
khác ở nội dung thể hiện.
Trường Code chỉ có hai giá trò 4 và 5 đặc trưng cho hai kiểu gói "yêu cầu cấp phát tài khoản"
47

(Accouting Request) và "trả lời cấp phát tài khoản" (Accounting Response).

Các thuộc tính hợp lệ trong các gói RADIUS dạng Access-Request, Access-Accept sẽ hợp lệ
trong các gói Accounting-Request, trừ một số thuộc tính không thể hiện diện như: User-
Password, CHAP-Password, Reply-Message, State. Một số thuộc tính phải luôn có mặt trong
gói Accounting-Request như: NAS-IP-Address, NAS-Identifier và một số thuộc tính khác nên
có mặt như: NAS-Port, NAS-Port-Type.
Một số chi tiết cụ thể khác có thể tham khảo thêm trong tài liệu draft-ietf-radius-accounting-
05 hoặc hoặc
IV. Phương pháp mã hóa (encryption) và giải mã (decryption) dùng trong RADIUS.
Thuộc tính User-Password chứa trong các gói Access-Request hoặc Access-Challenge, đặc
trưng cho mật khẩu (password) của user, sẽ được ẩn trong khi truyền tới RADIUS server. Mật
khẩu sẽ được thêm vào các ký tự NULL sao cho độ dài là bội của 16 byte. Băm MD5 một
chiều (One-way MD5 hash) sẽ được xây dựng từ chuỗi các byte của "thông tin bí mật chung"
(shared secret) giữa NAS - RADIUS server và trường xác nhận yêu cầu (Request
authenticator). Giá trò tính được sẽ được XOR với đoạn 16 byte đầu tiên của mật khẩu, kết
quả sẽ được đặt vào 16 byte đầu tiên của trường giá trò kiểu string của thuộc tính User-
Password. Nếu password dài hơn 16 ký tự thì giá trò băm thứ hai được tính từ chuỗi các byte
tiếp theo của "thông tin bí mật chung" và kết quả của xor lần trước. Giá trò băm có được sẽ
được XOR với 16 byte tiếp theo của mật khẩu, kết quả sẽ được đặt vào 16 byte tiếp theo của
trường giá trò kiểu string của thuộc tính User-Password. Quá trình cứ tiếp diễn cho tới khi hết
các đoạn (segment) được chia của mật khẩu (tối đa là 128 ký tự).
Phương pháp dùng ở đây có thể tham khảo chi tiết hơn trong tài liệu Network Security của
Kaufman, Perlman và Speciner được mô tả ngắn gọn như sau:
48

Giả sử gọi "thông tin bí mật dùng chung" (shared secret) là S, giá trò của trường xác đònh yêu
cầu (Request Authenticator) 128 bits là RA. Chia mật khẩu (password) đã được lấp đầy
(padding) bởi các ký tự NULL (nếu cần) thành các phần con (chunks) p1, p2,…. Gọi các khối
mật mã dạng văn bản (ciphertext blocks) là c(1), c(2),… và các giá trò trung gian là b1,b2,…
Dấu + là phép cộng chuỗi (concatenation).

b1 = MD5(S + RA) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
……………………
bi = MD5(S + c(i-1)) c(i) = pi xor bi

Khi gói RADIUS được nhận, quá trình sẽ diễn ra ngược lại để lấy lại giá trò thực của mật
khẩu.
V. Cài đặt RADIUS và sử dụng
1. Cài đặt:
- Download mã nguồn: mã nguồn của chương trình RADIUS được lấy từ đòa chỉ

Cấu trúc thư mục của RADIUS như sau:
- radcheck - phần kiểm tra RADIUS ( tương tự lệnh ping)
- radiusd - thực thi RADIUS Server.
49

- radpwtst - phần kiểm tra RADIUS Client.
- dnscheck - phần kiểm tra ánh xạ DNS.
- /raddb gồm các file sau:
authfile: file ánh xạ kiểu authenticate
clients : file chứa các thông tin client như đòa chỉ IP của client và khoá Key để
ánh xạ.
Users: file chứa thông tin về user.
dictionary: file chứa các thông tin đònh nghóa bởi radiusd
- /radacct chứa các record accounting theo dạng RADIUS.
- Sau khi uncompress file nêu trên , soạn lại Makefile cho đúng cấu hình của hệ điều
hành đang sử dụng ví dụ Linux.
Bỏ tham số -DNOSHADOW nếu trong thư mục /usr/include đã có file shadow.h
Dùng lệnh Make all để dòch chương trình.
- Sửa đổi và thêm các thông số trong file clients, users, authfile.

Ví dụ: dưới đây là các thông số đã được sửa chữa khi cài đặt RADIUS trên hệ điều
hành Linux 4.2
File clients:
#Client Name Key user/authfile prefix
#
50

9. testingabc123
File Authfile:
DEFAULT_RADIUS_SERVER lnsrv.quantic.ac.vn
#Realm [(alias[,alias])] [-prot] Type REALM/DNS address Filter ID
#
# Authentication requests for realm "umich.edu" which contain CHAP
# protocol information are handled by the first entry. Non-CHAP
# requests for umich.edu are all handled by the second entry.
quantic.ac.vn UNIX-PW

# This entry says to pass requests with authentication realm names
# which didn't appear in this file along to another RADIUS server.
DEFAULT RADIUS lnsrv.quantic.ac.vn

File Users

quanticPassword = "abc123", Authentication-Type = Unix-PW
Service-Type = Login,
51

Login-Service = Telnet,
Login-IP-Host = 199.200.201.9,
Login-TCP-Port = 23

dien Password = "dien", Authentication-Type = Unix-PW
Service-Type = Login,
Login-Service = Telnet,
Login-IP-Host = 199.200.201.9,
Login-TCP-Port = 23

test Password = "abc123"
Service-Type = Framed,
Framed-Protocol = PPP,
Framed-IP-Address = 199.200.201.9

DEFAULT Authentication-Type = Realm
Filter-Id = "unlim"

52

File /etc/inetd.conf

radius dgram udp wait root /usr/local/sbin/radiusd radiusd

File /etc/services
radius 1645/udp # radius deamon
radacct 1646/udp # radius accounting deamon

2. Sử dụng:
- Khởi động Radius Server.
cd /usr/local/sbin
./radiusd -d /usr/local/etc/raddb -p 1645 -x -x&
- Kiểm tra Radius Server có hoạt động không:

cd /usr/local/sbin
./radcheck –d /usr/local/etc/raddb –p 1645 –x <servername> (ví dụ lnsrv.quantic.ac.vn)
- Kiểm tra Radius client
./radpwtst –d /usr/local/etc/radd –p 1645 –s lns.quantic.ac.vn –u PPP –w abc123 –x test
./radpwtst –d /usr/local/etc/radd –p 1645 –s lns.quantic.ac.vn –w abc123 –x quantic
53

V. Giải thuật của RADIUS server
Giải thuật của RADIUS server sau đây được trình bày dựa trên mã nguồn của
Livingston Enterprises, Inc. ( hoặc ).


Quá trình mã hoá và giải mã gói giữa Radius Client và Server được mô tả sơ lược như
sau:
- Các gói Radius được lồng vào các gói UDP. Người ta dùng một số cấu trúc sau để
mã hóa/giải mã các gói Radius.
 Kiểu Header của gói Radius
typedef struct
{
u_char code; /* Loại của gói: 0-Access-Request ; 1-Access-Accept,…*/
u_char id; /* ID của gói dùng nhận diện (fetch) gói*/
u_short length; /* độ dài gói */
u_char vector[AUTH_VECTOR_LEN]; /* Authenticator 16 byte*/
u_char data[2]; /* Con trỏ tới phần nội dung thuộc tính của gói*/
} AUTH_HDR;

54

 Kieåu cuûa moät Radius Authentication Request
typedef struct

{
UINT4 ipaddr; /* IP address of requestor */
u_short udp_port; /* UDP reply socket of requestor */
u_char id; /* Original request seq. number */
u_char code; /* Type of RADIUS packet */
u_char vector[AUTH_VECTOR_LEN];
char *secret;
char *file_pfx;
char *realm_filter;
u_char ttl; /* Global queue time-to-live secs */
u_char timer; /* General utility timer */
u_char reply_id; /* RADIUS-to-RADIUS seq. number */
u_char retry_cnt; /* Counter for duplicate requests */
u_char state; /* State of current request */
u_char sws; /* Switches, flags, etc. */
int result; /* Result of previous action */
55

int cur_count; /* Original number request pairs */
struct aatv *fsm_aatv; /* Pointer to current FSM action */
struct aatv *direct_aatv; /* Pointer to actual action */
struct event_ent *event_q; /* Pointer to active event queue */
struct auth_req *next; /* Global request queue link */
VALUE_PAIR *request; /* Original client a/v pairs */
VALUE_PAIR *cur_request; /* Represents current a/v pairs */
VALUE_PAIR *user_check; /* List of users file check items */
} AUTH_REQ;
 Mã hóa gói Radius ( ở Client )

auth = (AUTH_HDR *) send_buffer;

auth->code = 1; /* Giả sử gói Radius loại yêu cầu xác nhận quyền*/
random_vector (auth->vector); /* Sinh số 16 byte ngẫu nhiên: Authenticator */
srand (time (0)); /* Tạo dãi ngẫu nhiên với đối số thời gian*/
auth->id =(u_char *) rand (); /* tạo request ID duy nhất */

ptr = auth->data; /* Con trỏ tới vùng thuộc tính*/
56

Chèn thuộc tính UserName vào vùng thuộc tính ptr
Chèn thuộc tính Password vào vùng thuộc tính sau khi đã mã hóa ptr
+Khởi động passbuf dài 16 byte với giá trò ‘\0’
+Chép Password vào passbuf
+đọc Secret từ file clients
+Tính MD5-hash (giới thiệu ở mục B-IV) với đối số là secret+auth->vector, kết quả
sau khi băm được đặt vào vùng thuộc tính ptr sau đã XOR lần lượt từng byte một với
passbuf
Chèn thuộc tính ServiceType vào vùng thuộc tính
Chèn thuộc tính Client IP Address , Client Port vào vùng thuộc tính
…
Tính Tổng độ dài totalLength
Auth->length = totalLength
Gởi gói tới server: sendto (sockfd, (char *) send_buffer, (int) totalLength,…)

 Giải mã gói Radius ( ở Server )

Nhận gói từ Client: recv(sockfd, (char *) recv_buffer, …)
auth = (AUTH_HDR ) recv_buffer; /* Lấy header của gói Radius*/
57

get_radrequest (&authreq…) /* Xây dựng cấu trúc Radius Request*/

Lấy auth->id để kiểm tra duplicate?
Kiểm tra xác nhận quyền tuỳ theo kiểu, như rad_authenticate(authreq) ứng với RADIUS
authentication.
+Lấy ra các thuộc tính
(ví dụ lấy thuộc tính ServiceType:
get_vp ( authreq->request, PW_SERVICE_TYPE)->lvalue
hoặc lấy thuộc tính UserName:
get_vp ( authreq->request,PW_USER_NAME)->strvalue )
Và kiểm tra tính hợp lệ của các thuộc tính này
+ Lấy password ở dạng ascii: get_passwd (authreq, &passwd)
+ Lấy password ở Unix file trong trường hợp Unix-PW authentication:
pwd = getpwnam (filename)
+ So sánh pwd và passwd để kiểm tra tính hợp lệ
Authentication thành công khi tất cả các thuộc tính đều thỏa