radius server 1205

34

Upload: tang-luong

Post on 25-Oct-2015

41 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Radius Server 1205

`

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

KHOA ĐIỆN TỬ - VIỄN THÔNG

BÁO CÁO ĐỀ TÀI

Môn học: Công nghệ mạng

Tìm hiểu Radius Server

Giảng viên phụ trách : CH. Nguyễn Việt Hà

Nhóm thực hiện: Nguyễn Văn Quốc Bảo 0820005

Nguyễn Quốc Hùng 0820073

Nguyễn Tiến Hoàng 0820061

Trương Quang Thông 0820165

Lớp 08ĐVT1

- Tháng 10/2011 -

Page 2: Radius Server 1205

`

Quá trình thực hiện đề tài:

Tìm hiểu tổng quan Radius Server – tuần 1(16-9==>23-9)

Thảo luận,trao đổi ....(24-9==>29-9)Bốc thăm thuyết trình với nhóm 2.

Chỉnh sửa nội dung và làm slide gửi thầy. Lập dàn bài thuyết trình và làm slide .Thuyết trình thử. (30-9==>12/10)

Page 3: Radius Server 1205

`

Mục Lục

Phần I. Giao thức RADIUS............................................................................................................2

1. Tổng quan về giao thức RADIUS............................................................................................2

2. Giới thiệu.................................................................................................................................3

3. Tính chất của RADIUS............................................................................................................3

4. Giao thức RADIUS 1...............................................................................................................4

4.1. Cơ chế hoạt động..............................................................................................................4

4.2. Dạng gói của packet..........................................................................................................6

4.3. Packet type (kiểu packet)..................................................................................................9

5. Giao thức RADIUS 2.............................................................................................................15

5.1. Cơ chế hoạt động............................................................................................................15

5.2. Packet Format.................................................................................................................15

6. Phương pháp mã hóa và giả mã.............................................................................................16

Phần II. RADIUS SERVER.........................................................................................................17

1. Tổng quan..............................................................................................................................17

2. Xác thực- cấp phép và kiểm toán...........................................................................................17

3. Sự bảo mật và tính mở rộng...................................................................................................19

4. Áp dụng RADIUS cho WLAN..............................................................................................19

5. Các tùy chọn bổ sung.............................................................................................................20

Tài liệu tham khảo.

1

Page 4: Radius Server 1205

`

Phần I. Giao thức RADIUS

1. Tổng quan về giao thức RADIUS

Authentication, Authorization, and Accounting

Giao thức Remote Authentication Dial In User Service (RADIUS) được định nghĩa trong RFC 2865 được đưa ra với định nghĩa: Với khả năng cung cấp xác thực tập trung, cấp phép và điều khiển truy cập (Authentication, Authorization, và Access Control – AAA) cho các phiên làm việc với SLIP và PPP Dial-up – như việc cung cấp xác thực của các nhà cung cấp dịch vụ Internet (ISP) đều dựa trên giao thức này để xác thực người dùng khi họ truy cập Internet. Nó cần thiết trong tất cả các Network Access Server (NAS) để làm việc với danh sách các username và password cho việc cấp phép, RADIUS Access-Request sẽ chuyển các thông tin tới một Authentication Server, thông thường nó là một AAA Server (AAA – Authentication, Authoriztion, và Accounting). Trong kiến trúc cua hệ thống nó tạo ra khả năng tập trung các dữ thông tin của người dùng, các điều kiện truy cập trên một điểm duy nhất (single point), trong khi có khả năng cung cấp cho một hệ thống lớn, cung cấp giải pháp NASs.

Khi một user kết nối, NAS sẽ gửi một message dạng RADIUS Access-Request tới máy chủ AAA Server, chuyển các thông tin như username và password, thông qua một port xác định, NAS identify, và một message Authenticator.

Sau khi nhận được các thông tin máy chủ AAA sử dụng các gói tin được cung cấp như, NAS identify, và Authenticator thẩm định lại việc NAS đó có được phép gửi các yêu cầu đó không. Nếu có khả năng, máy chủ AAA sẽ tìm kiểm tra thông tin username và password mà người dùng yêu cầu truy cập trong cơ sở dữ lệu. Nếu quá trình kiểm tra là đúng thì nó sẽ mang một thông tin trong Access-Request quyết định quá trình truy cập của user đó là được chấp nhận.

Khi quá trình xác thực bắt đầu được sử dụng, máy chủ AAA có thể sẽ trả về một RADIUS Access-Challenge mang một số ngẫu nhiên. NAS sẽ chuyển thông tin đến người dùng từ xa (với ví dụ này sử dụng CHAP). Khi đó người dùng sẽ phải trả lời đúng các yêu cầu xác nhận (trong ví dụ này, đưa ra lời đề nghị mã hoá password), sau đó NAS sẽ chuyển tới máy chủ AAA một message RADIUS Access-Request.

Nếu máy chủ AAA sau khi kiểm tra các thông tin của người dùng hoàn toàn thoả

0

Page 5: Radius Server 1205

`

mãn sẽ cho phép sử dụng dịch vụ, nó sẽ trả về một message dạng RADIUS Access-Accept. Nếu không thoả mãn máy chủ AAA sẽ trả về một tin RADIUS Access-Reject và NAS sẽ ngắt kết nối với user.

Khi một gói tin Access-Accept được nhận và RADIUS Accounting đã được thiết lập, NAS sẽ gửi mộtgói tin RADIUS Accounting-Request (Start) tới máy chủ AAA. Máy chủ sẽ thêm các thông tin vào file Log của nó, với việc NAS sẽ cho phép phiên làm việc với user bắt đầu khi nào, và kết thúc khi nào, RADIUS Accouting làm nhiệm vụ ghi lại quá trình xác thực của user vào hệ thống, khi kết thúc phiên làm việc NAS sẽ gửi một thông tin RADIUS Accounting-Request (stop).

RADIUS là một giao thức sử dụng rộng rãi cho phép xác thực tập trung, ủy quyền

và kiểm toán truy cập cho mạng. Ban đầu được phát triển cho thiết lập kết nối từ xa.

Radius bâu giờ thì hỗ trợ cho máy chủ VPN, các điểm truy cập không dây, chứng thực

chuyển mạch internet, truy cập DSL, và các loại truy cập mạng khác. RADIUS được mô

tả trong RFC 2865, "Remote Authentication Dial-in User Service (RADIUS), (IETF

Draft Standard) and RFC 2866, "RADIUS Accounting" (Informational).

2. Giới thiệu

Có 2 loại giao thức RADIUS mô tả về:

Giao thức RADIUS 1: 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 (NAS-Network Access

Server) 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 RADIUS 2: Thông tin về tài khoảng giữa NAS và máy chủ quản lý tài

khoản dùng chung.

3. Tính chất của RADIUS

RADIUS thực ra là một giao dịch được xây dựng trên giao thức có các tính chất

chính như sau:

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

1

Page 6: Radius Server 1205

`

(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).

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

sang chờ trong nhiều giây để cho việc xác nhận quyền được hoàn thành. Việc truyền lại

thường xảy ra đối với các TCP dựa trên thời gian truyền nhận trung bình 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ề. 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ờ đợi quá lâu là không

hữu ích. Việc sử dụng luân phiên nhanh chóng các server sẽ cho phép user truy cập được

vào mạng trước khi họ bỏ cuộc.

Trạng thái rất tự do của RADIUS đã đơn giản hóa việc sử dụng UDP. Các client

và server 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 đó, như: Nguồn điện bị mất…Các sự kiện bất thường này nói chung sẽ không gây

nguy hiểm nếu như có những timeout 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 client và server có thể một “

chuyến vận chuyển dữ liệu” UDP 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ó.

UDP đơn giản hóa việc thực hiện server. Ở những phiên bản trước, server được

thực hiện đơn luồng (single thread), có nghĩa là mỗi lúc chỉ có một 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). 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 quay vòng của yêu cầu sẽ lớn hơn rất nhiều so với thời

gian mà user chờ đợi. Do vậy, giải pháp được chọn là thực hiện server chế độ đa luồng

(multu-thread) với UDP. Những quá trình xử lý độc lập sẽ được sinh ra trên server tương

ứng với mỗi yêu cầu và những quá trình này sẽ trả lời trực tiếp với các NAS khách hàng

bằng gói UDP tới lớp truyền dẫn chính của client.

2

Page 7: Radius Server 1205

`

4. Giao thức RADIUS 1

4.1. Cơ chế hoạt động

Khi một client được cấu hình để sử dụng RADIUS, thì bất kỳ user nào của client

đều giới thiệu những thông tin xác nhận quyền với client. Đó có thể là dấu nhắc lệnh

đăng ký vào mạng yêu cầu user nhập username và password 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 các gói dữ

liệu chẳng hạn như PPP.

Mỗi 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ư trên: mật khẩu của user, ID của client và ID port mà user này sẽ truy cập vào. Mật

khẩu khi nhập vào sẽ được ẩn (Mã hóa RSA hoặc 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 trả lời trong một khoảng thời gian qui ước thì yêu cầu sẽ được gửi lại. Client

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-bin.

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 với RADIUS sẽ không được xác

nhận và trả lời. 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 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ả ID của client và ID 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 thỏa mãn, 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 theo một thông báo dạng văn bản (text massage) trong access-reject để client có

3

Page 8: Radius Server 1205

`

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 thỏa mãn 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” (original access-

request) vơi một số hiệu yêu cầu (request ID) mới, nhưng thuộc tính usename-password

được lấy từ thông tin vừa mới nậ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 một access-request bằng một access-accept,

access-reject hoặc một access-challenge khác.

Nếu cuối cùng tất cả các điều kiện trên được thỏa mãn, thì danh sách các giá trị

cấu hình cho user được đặt vào trả lời “access-accept”. Các giá trị này bao gồm kiểu của

dịch vụ (SLIP, PPP, Login..) và các giá trị cần thiết để cấp phát dịch vụ này. Ví dụ như

đối với SLIP hay PPP, các giá trị này có thể là địa chỉ IP, subnet mask, MTU, phương

pháp nén và số hiệu lọc gói. ở chế độ ký tự (character mode), các giá trị này có thể là giao

thức và tên máy chủ.

4.2. Dạng gói của packet

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, và trường địa chỉ đích có số hiệu cổng là 1812. 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 xác định như sau (các trường được gửi đi từ

trái sang phải).

4

Page 9: Radius Server 1205

`

Hình 4-1 Packet Format

Code: Code field là một octet, và xác định kiểu gói của RADIUS. Khi một gói

có mã không hợp lệ sẽ không được xác nhận

RADIUS code (decimal) được chỉ định như sau:

1 Access-Request

2 Access-Accept

3 Access-Reject

4 Accounting-Request

5 Accounting-Response

11 Access-Challenge

12 Status-Server (experimental)

13 Status-Client (experimental)

255 Reserved

Mã số 4 và số 4 được che đậy trong tài liệu RADIUS accouting [5]. Mã số 12 và

13 là dành riêng cho việc có thể sử dụng, nhưng nó không được đề cập ở đây.

Identifier (Trường định danh )

5

Page 10: Radius Server 1205

`

Indentifier field là một octet, và phù hợp với việc hỗ trợ yêu cầu và trả lời. Các

máy chủ RADIUS có thể phát hiện một yêu cầu trùng lặp, nếu có các client có cùng một

địa chỉ IP nguồn và UDP port và định danh trong một thời gian ngắn.

Length

Length field là hai octet, nó bao gồm các code field, indentifier, length,

authentication, và trường thuộc tính (attribute field). Những byte nằm ngoài khoảng qui

định bởi 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. Giá trị nhỏ nhất của

trường length là 20 và giá trị lớn nhất là 4096.

Authenticator

Trường authenticator là 16 octet. Octet lớn nhất được truyền đi đầu tiên. Giá trị

này được sử dụng để xác nhận các trả lời từ RADIUS server và được sử dụng trong thuật

toán ẩn mật khẩu.

Request Authenticator: Trong các gói 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 không thể dự đoán trước và duy nhất trong suốt thời

gian sống của “thông tin bí mật” (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 attacker có thể trả lời câu hỏi này

không cần sự xác nhận của RADIUS server. Do đó, bộ xác nhận yêu cầu nên có giá trị

toàn cục và duy nhất theo thời gian. Mặc dù, giao thức RADIUS không có khả năng ngăn

chặn sự nghe lé phiên xác thực qua đường dây, nhưng việc sinh ra các giá trị không thể

đoán trước đượ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 chung này có được sau khi

giá trị của “bộ xác nhận yêu cầu” được thuật toán MD5 băm để tạo ra giá trị 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-accept.

6

Page 11: Radius Server 1205

`

Response authenticator: Giá trị của trường xác nhận (authenticator field value)

trong các gói access-request, access-reject, access-challenge được coi là bộ xác nhận trả

lời (response authenticator). Giá trị này được tính bởi băm MD5 chuỗi các byte của code

field, indentifier, length, xác nhận của gói access-request, 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) where +

denotes concatenation.

Administrative Note

Thông tin bí mật (chia sẽ password giữa client và RADIUS server) nên ít nhất là

lớn và phứt tạp đó là cách lựa chọn mật khẩu tốt. Mức ưu tiên có thể chấp nhận được ít

nhất là 16 octet. Điều này để đảm bảo phạm vi đủ lớn cho việc cung cấp các cơ chế bảo

mật chống lại các cuộc tấn công tìm kiếm.

4.3. Packet type (kiểu packet)

Packet type được xác định bởi code field chiếm byte đầu tiên của gói RADIUS.

Access-Request

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. Code field của gói phải có giá trị 1. Gói access-request phải chứa các 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-Indentifier, NAS-PORT, NAS-PORT-TYPE.

Trường indentifier phải được thay đổi khi nội dung của trường thuộc tính bị 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, trường indentifier không đượ thay

đổi.

7

Page 12: Radius Server 1205

`

Hình 4-2 Access-request Packet Format

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 code 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 access-request tương ứng đã gởi trước đó và phải có xác

nhận (response authenticator) phù hợp với thông tin bí mật dùng chung.

Hình 4-3 Access-accept Packet Format

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 code của mã phải có giá trị 3. Gói có thể chứa 1 hoặc nhiều thuộc tính

8

Page 13: Radius Server 1205

`

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

indentifier của gói access-reject chính là bản sao của gói access-request tương ứng.

Hình 4-4 Access-reject packet format

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 code 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 trong gói access-chanllenge. Trường indentifier của gói access-

challenge phải trùng khớp với gói access-request tương ứng đã gửi đi trước đó và phải có

trường xác nhận (authenticator field) phù hợp với thông tin bí mật dùng chung. Nếu NAS

không được trang bị challenge/ response thì gói access-challenge nhận được sẽ coi như

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.

9

Page 14: Radius Server 1205

`

Hình 4-5 Access-challenge packet format

Attributes (các thuộc tính)

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 thực 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ị

các trường length của gói RADIUS sẽ qui đị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:

Hình 4-6 Attributes type

o Type

Mỗi trường type là một octet, giá trị từ 192-223 là dành riêng cho nghiên cứu, giá

trị từ 224-240 là dành cho việc thực hiện cụ thể, 241-255 là dành riêng và không nên sử

dụng.

RADIUS server có thể bỏ qua các thuộc tính với một loại không rõ.

RADIUS client có thể bỏ qua các thuộc tính với một loại không rõ.

Điều này quan tâm đặc tả các giá trị sau:

1 User-Name

10

Page 15: Radius Server 1205

`

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

13 Framed-Compression

14 Login-IP-Host

15 Login-Service

16 Login-TCP-Port

17 (unassigned)

18 Reply-Message

19 Callback-Number

20 Callback-Id

21 (unassigned)

22 Framed-Route

23 Framed-IPX-Network

24 State

25 Class

26 Vendor-Specific

27 Session-Timeout

28 Idle-Timeout

29 Termination-Action

30 Called-Station-Id

11

Page 16: Radius Server 1205

`

31 Calling-Station-Id

32 NAS-Identifier

33 Proxy-State

34 Login-LAT-Service

35 Login-LAT-Node

36 Login-LAT-Group

37 Framed-AppleTalk-Link

38 Framed-AppleTalk-Network

39 Framed-AppleTalk-Zone

40-59 (reserved for accounting)

60 CHAP-Challenge

61 NAS-Port-Type

62 Port-Limit

63 Login-LAT-Port

o Length (trường độ dài)

Biểu thị độ dài của thuộc tính cho các trường kiểu, length và value. 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 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.

o Value (trường giá trị)

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:

Text 1-253 octets containing UTF-8 encoded 10646 [7]

characters. Text of length zero (0) MUST NOT be sent;

omit the entire attribute instead.

String 1-253 octets containing binary data (values 0 through

12

Page 17: Radius Server 1205

`

255 decimal, inclusive). Strings of length zero (0)

MUST NOT be sent; omit the entire attribute instead.

Address 32 bit value, most significant octet first.

Integer 32 bit unsigned value, most significant octet first.

Time 32 bit unsigned value, most significant octet first --

seconds since 00:00:00 UTC, January 1, 1970. The

standard Attributes do not use this data type but it is

presented here for possible use in future attributes.

5. Giao thức RADIUS 2

5.1. Cơ chế hoạt động

Khi client được cài đặt để sử dụng RADIUS Accouting, 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” 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

accouting server mà tới lượt nó sẽ gửi lại một thông báo nhận biết 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” mô

tả kiểu dịch đã được cấp phát và các thông tin thống kê có thể lọc dựa như thời gian trôi

qau, các byte nhập/ xuất, các gói nhập/xuất; sau đó gửi gói này đến RADIUS accouting

server mà tới lượt nó sẽ gửi lại một thông báo nhận biết là gói đã nhận được.

“Yêu cầu cấp phát tài khoản” (accouting-request) của hai loại start và stop được

gửi cho RADIUS accouting server qua mạng. thường thì client sẽ tiếp tục cố gắng gửi gói

accouting-request sau một khoảng thời gian nhất định cho tới khi nhận được phản hồi

(ACK).

Client có thể gởi tiếp (forward) cho các server khác nhau trong trường hợp server

chính bị off hoặc hỏng. Trong trường hợp này RADIUS accouting server đóng vai trò của

một client.

13

Page 18: Radius Server 1205

`

5.2. Packet Format

Giống như giao thức RADIUS 1, giao thức RADIUS 2 cũng có 4 trường: code,

indentifier, length, authentication, 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 accouting-request

và accouting-response.

Các thuộc tính hợp lệ trong gói RADIUS dạng access-request, access-accept sẽ

hợp lệ trong các gói accouting-request, trừ một số thuộc tính không thể hiện như: User-

Password, CHAP-Password, Reply-Message,State. Một số thuộc tính phải luôn luôn có

mặt trong gói accouting-request như: NAS-IP-Address, NAS-Indentifier và một số thuộc

tính khác nên có mặt như: NAS-port, NAS-Port-Type.

Còn một số chi tiết khác các bạn có thể tham khảo tại :

http://www.faqs.org/rfcs/rfc2865.html

6. Phương pháp mã hóa và giả mã

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 buye. 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” giữa NAS và RADIUS server và thường xác nhận yêu

cầu.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ị 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ẽ 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 tiếp theo cứ tiếp diễn đến khi

hết các đoạn (segment) được chia của mật khẩu (tối đa là 128 ký tự).

Bạn có thể tham khảo thêm ở tài liệu RFC 2865

14

Page 19: Radius Server 1205

`

Giả sử gọi “thông tin bí mật chung” là S, giá trị của trường xác định yêu cầu

(request authentication) 128 bit là RA. Chia mật khẩu đã được lắp đầy 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.

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

The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation.

Khôi gói RADIUS được nhận, quá trình sẽ diễn ra ngược lại trong quá trình giải

mã.

Phần II. RADIUS SERVER

1. Tổng quan

Việc bảo mật WLAN sử dụng chuẩn 802.11x kết hợp với xác thực người dùng

trên AP. Một máy chủ thực hiện việc xác thực trên nền tảng RADIUS có thể là một giải

pháp tốt nhất cung cấp xác thực cho chuẩn 802.11x

15

Page 20: Radius Server 1205

`

Hình 4-7 Mô hình xác thực sử dụng RADIUS Server

2. Xác thực- cấp phép và kiểm toán

Giao thức RADIUS được định nghĩa trong RFC 2865 như sau: Với khả năng cung

cấp xác thực tập trung, cấp phép và điều khiển truy cập (Authentication, Authorization và

Accouting-AAA) cho các phiên làm việc với SLIP và PPP Dial-Up. Như việc cung cấp

dịch vụ internet (ISP) đều dựa trên giao thức này để xác thực người dùng khi họ truy cập

internet.

Nó cần thiết trong các NAS để làm việc với danh sách các username và password

cho việc cấp phép, RADIUS Access-request sẽ chuyển thông tin tới một Authentication

Server, thông thường nó là một AAA Server. Trong kiến trúc của hệ thống nó tạo ra khả

năng tập trung các dữ liệu, thông tin của người dùng, các điều khiển truy cập trên một

điểm duy nhất (single point), trong khi có khả năng cung cấp cho một hệ thống lớn, cung

cấp giải pháp NASs

16

Page 21: Radius Server 1205

`

Khi một user kết nối, NAS sẽ gửi một message dạng RADIUS Access-request tới

máy chủ AAA Server, chuyển các thông tin như Username, Password , UDP port, NAS

indentifier và một Authentication message.

Sau khi nhận các thông tin AAA sử dụng gói tin được cung cấp như NAS

Indentify, và Authentication thẩm định lại việc NAS đó có được phép gửi các yêu cầu đó

không?Nếu có khả năng, AAA server sẽ kiểm tra thông tin username và password mà

người dùng yêu cầu truy cập trong database. Nếu quá trình kiểm tra là đúng thì nó sẽ

mang một thông tin trong Access-request quyết định quá trình truy cập của user đó là

được chấp nhận.

Khi quá trình chứng thực bắt đầu được sử dụng, AAA server có thể trả về một

RADIUS Access-Challenge mang một số ngẫu nhiên. NAS sẽ chuyển thông tin đến

người dùng từ xa. Khi đó người dùng sẽ phải trả lời đúng yêu cầu xác nhận, sau đó NAS

sẽ chuyển đến AAA server một RADIUS Access-Request

AAA server sau khi kiểm tra các thông tin của người dùng hoàn toàn thỏa mãn sẽ

cho phép sử dụng dịch vụ, nó sẽ trả về một message dạng RADIUS Access-accept. Nếu

không thỏa mãn AAA server sẽ trả về một tin RADIUS Access-reject và NAS sẽ ngắt

dịch vụ.

Khi gói tin Access-accept được nhận và RADIUS Accouting đã được thiết lập,

NAS sẽ gửi một gói tin RADIUS Accouting –request tới AAA server. Máy chủ sẽ thêm

các thông tin vào logfile của nó, với việc NAS sẽ cho phép phiên làm việc với User bắt

đầu khi nào và kết thúc khi nào. RADIUS Accouting làm nhiệm vụ ghi lại quá trình xác

thực của user vào hệ thống, khi kết thúc phiên làm việc NAS sẽ gửi thông tin RADIUS

Accouting-request

3. Sự bảo mật và tính mở rộng

Tất cả các message của RADIUS đều đóng gói bởi UDP Datagram s, nó bao gồm

các thông tin như: message type, sequence number, length, authenticator, và một loạt các

attributes values mà chúng ta đã tìm hiểu ở trên.

17

Page 22: Radius Server 1205

`

4. Áp dụng RADIUS cho WLAN

Trong một mạng WLAN sử dụng 802.11x port access control, các máy trạm sử

dụng Wireless đóng vai trò Remote Access và Wireless Access Point làm việc như một

NAS-Network Access Server. Để thay thế việc kết nối đến NAS với dial-up như giao

thức PPP, Wireless station kết nối đến AP bằng việc sử dụng giao thức 802.11

Một quá trình được thực hiện , wireless station gửi một EAP-Start tơi AP. AP sẽ

yêu cầu station nhận dạng và chuyển thông tin đó tới một AAA server với thông tin là

RADIUS Access-request Usename attribute.

AAA server và Wireless Station hoàn thành bằng việc chuyển các thông tin

RADIUS Access-challenge và Access-request qua AP. Được quyết định bởi phía trên là

một dạng EAP, thông tin này được chuyển trong một đường hầm được mã hóa TLS

(Encypted TLS Tunnel).

Nếu AAA server gửi một message Access-accept, AP và Wireless station sẽ hoàn

thành quá trình kết nối và hoàn thành phiên làm việc với việc sử dụng WEP hay TKIP để

mã hóa dữ liệu. Và tại điểm đó, AP sẽ không cấm cổng và wireless station có thể gửi và

nhận dữ liệu từ hệ thống mạng một cách bình thường.

Cần chú ý là quá trình mã hóa dữ liệu giữa wireless station và AP khác quá trình

mã hóa từ AP đến AAA server.

Nếu AAA server gửi một message Access-reject, AP sẽ ngắt kết nối đến wireless

station. Wireless station có thể cố gắng thử lại quá trình xác thực, nhưng AP cấm wireless

station này không được gửi các gói UDP đến các AP gần đó. Chú ý là station này hoàn

toàn có thể lắng nghe các dữ liệu được truyền đi từ các station khác. Trên thực tế dữ liệu

được truyền qua song radio và đó là lí do tại sao bạn phải mã hóa dữ liệu khi truyền trên

mạng không dây.

Attribute-value pare bao gồm tròn các message của RADIUS có thể sử dụng AAA

server để quyết định phiên làm việc giữa AP và wireless station, như session-timeout hay

VLAN tag (Tunnel-Type=VLAN, Tunnel-Private-Group-ID=TAG). Chính xác thông tin

18

Page 23: Radius Server 1205

`

thêm vào có thể phụ thuộc vào AAA server hay AP và wireless station mà bạn đang sử

dụng.

5. Các tùy chọn bổ sung

Một vấn đề đầu tiên bạn phải hiểu vai trò của RADIUS trong quá trình xác thực

của WLAN, bạn cần thiết lập một AAA server hỗ trợ interaction.

Nếu một AAA server gọi là RADIUS, nó sẵn sang để hỗ trợ xác thực cho chuẩn

802.11x và cho phép lựa chọn các dạng EAP. Nếu đã có bạn chuyển đến bước tiếp theo là

làm thế nào để thiết lập tính năng này.

Nếu bạn có một RADIUS hỗ trợ 802.11x, hoặc không hỗ trợ dạng EAP, bạn có thể

lựa chọn bằng cách cập nhật các phiên bản phần mềm mới hơn cho server, hay bạn có thể

cài đặt một máy chủ mới. Nếu bạn cài một server mới có hỗ trợ xác thực cho chuẩn

802.11x, bạn có thể sử dụng tính năng RADIUS proxy để thiết lập một chuỗi các máy

chủ, cùng chia sẽ một cơ sở dữ liệu tập trung, RADIUS proxy có thể sử dụng để chuyển

các yêu cầu xác thực đến các máy chủ có khả năng xác thực chuẩn 802.11x

Nếu bạn không có máy chủ RADIUS, bạn cần thiết phải cài đặt một máy chủ cho

quá trình xác thực WLAN, lựa chọn cài đặt này là một công việc thú vị.

Với cơ sở trung tâm –Giải pháp sử dụng RADIUS cho mạng WLAN là rất quan

trọng bởi nếu một hệ thống mạng của bạn có nhiều AP thì việc cấu hình bảo mật hệ thống

này rất khó để quản lí riêng biệt, người dùng có thể xác thực từ nhiều AP khác nhau và

điều đó là không thực sự bảo mật

Khi sử dụng RADIUS cho WLAN mang lại khả năng tiện lợi rất cao, xác thực cho

toàn bộ hệ thống nhiều AP,…cung cấp các giải pháp thông minh hơn.

19

Page 24: Radius Server 1205

`

Tài liệu tham khảo[1] Wikipedia.org

[2] RFC 2059,2865....

[3]www.nhatnghe.com/forum

[4]www.netpro.com.vn

20