ĐỒ ÁN HỆ THỐNG MẠNG
Đề tài:
BẢO MẬT TRONG WLAN
CHƯƠNG III
BẢO MẬT TRONG WLAN


Bảng3-2 :Dải các tùy chọn bảo mật cho mạng vô tuyến


Mức độ
bảo mật
Cấu hình Bảo đảm Ứng dụng

0


Không
bảo mật
Mạng ở ngoài và
không cấu hình
Không có
gì
Các dịch vụ ứng dụng
không được bảo mật thông
tin. Tuy nhiên nhiều người
sử dụng vẫn dùng các dịch
vụ mạng này.

1

Truy nhập
công cộng

Nhận thực người sử
dụng
Truy nhập
mạng
Thư viện, cửa hàng cafe,
khách sạn, sân bay….



2


Bảo mật
giới hạn
40- or 128-bit WEP,
MAC access control
list (ACL), và không
quảng bá
Một số
mạng truy
nhập và
bảo mật
dữ liệu
Home và SOHO với tính
di chuyển.

3



Bảo mật
cơ sở
Truy nhập bảo mật
Wi-Fi (WPA) (later
802.11i)
Truy nhập
mạng và
bảo mật
dữ liệu
Nhà, SOHO, và các hệ
thống nhỏ linh động.


4


Bảo mật
cấp cao
802.1x/EAP-X và
RADIUS
Truy nhập
mạng và
bảo mật
dữ liệu
Các hệ thống linh động
5



Bảo mật
đầu cuối –
tới – đầu
cuối
VPNs cũng như
Point-to-Point
Tunneling Protocol
(PPTP), PPTPv2,
Layer 2 Tunneling
Protocol (L2TP),
Kerberos, và IP
Security (IPSec)
Truy nhập
mạng và
bảo mật
dữ liệu
Các ứng dụng đặ biệt, trao
đổi thường mại, liên lạc…

3.5.1 Truy nhập công cộng
Truy nhập công cộng giống như việc để các khoá cho mọi người đều biết và
sử dụng. NoCat Auth, Sputnik, và Wayport hạn chế truy nhập tới người sử dụng
công cộng bằng cách nhận thực họ. Tiến trình nhận thực họ bảo vệ mạng bởi các
sự khác nhau của uỷ nhiệm truy nhập. Trong một số trường hợp, quảng cáo được
trao đổi để giành quyền truy nhập hệ thống. Trong các trường hợp NoCat Auth,
truy nhập có thể bị loại bỏ để tránh việc người ta lạm dụng hệ thống. Nhiều giải
pháp loại này không cung cấp một cơ chế (tunnel) bảo mật cho những người sử
dụng của chúng. Dữ liệu gửi trên không khí là trong điều kiện rõ ràng. Những
người sử dụng phải được cung cấp sự bảo vệ của riêng mình chống lại những lỗ
hổng của độ tin cậy như là sử dụng một VPN để tạo tunnel quay lại công trình

mạng của họ.
3.5.2 Điều khiển truy nhập cơ bản
Hiện nay, truy nhập cơ bản cũng giống như việc giấu một khoá dưới một
tấm thảm. Khoá được dấu ngoài để cho những người thông minh có thể tìm thấy,
nhưng mạng truy nhập và dữ liệu được truy nhập sẽ không có giá trị do sự cố ngắt
mạng.
Tối thiểu, người sử dụng nên kích hoạt WEP, các mật khẩu bảo vệ các thiết
bị dùng chung và các tài nguyên, thay đổi tên mạng từ SSID mặc định, sử dụng lọc
địa chỉ MAC, và tắt quảng bá nếu có thể. Viện công nghệ điện và điện tử (IEEE)
đang làm việc để loại bỏ khoá tránh tình trạng “khóa dưới thảm” bằng hai giải
pháp - cải tiến WEP tạm thời và thay thế WEP lâu dài.
3.5.3 Các phương thức bảo mật 802.11 ngoài WEP
Truy nhập bảo vệ Wi-Fi (WPA): tháng 11 năm 2002, liên minh Wi – Fi
thông báo tiêu chuẩn bảo mật WPA. Nó sẽ thay thế tiêu chuẩn WEP hiện tại trên
thiết bị Wi – Fi. Có thể thấy trước rằng nhiều nhà cung cấp sẽ đưa ra phần sụn và
phần mềm nâng cấp cho các sản phẩm Wi – Fi sẵn có để chúng làm việc với WPA.
WPA sử dụng giao thức toàn vẹn khoá tạm thời (TKIP), một kỹ thuật mật
mã cứng rắn hơn được sử dụng trong WEP. TKIP sử dụng khoá băm (KeyMix) và
kiểm tra tính toàn vẹn bản tin phi tuyến (MIC). TKIP cũng sử dụng một giao thức
rapid – rekeying (ReKey) thay đổi khoá mật mã cho khoảng 10.000 gói tin. Tuy
nhiên, TKIP không loại trừ những điểm yếu cơ bản trong bảo mật Wi – Fi. Nếu
một attacker tấn công TKIP, anh ta hoặc cô ta không chỉ bẻ gãy độ tin cậy, mà còn
điều khiển truy nhập và nhận thực.
WPA sẽ làm việc trong hai phương pháp khác nhau, tuỳ thuộc vào loại
mạng. Trong nhà và các văn phòng nhỏ, công nghệ sẽ làm việc trong chế độ khoá
“tiền chia sẻ”. Những người sử dụng nhập khoá mạng để giành quyền truy nhập.
Trong chế độ quản lý, nó sẽ làm việc với các AS và sẽ yêu cầu sự hỗ trợ của
802.1x và EAP.802.1x và EAP cho phép một bộ thích ứng mạng khách đàm phán
qua một AP với một back – end AS sử dụng các giao dịch mật mã an toàn để trao
đổi các khoá phiên.

WPA bao gồm nhiều phần của 802.11. Tuy nhiên, một số các phần tử khoá
không được bao gồm trong đó như là sự hỗ trợ cho một thuật toán mật mã mới gọi
là tiêu chuẩn mật mã hoá cấp cao (AES), tiêu chuẩn này sẽ thay thế thuật toán mật
mã RC4 cơ sở khi 802.11i trở nên phổ biến.
3.5.4 802.11 Phương pháp bảo mật ngoài WPA
WPA khi trở nên phổ biến, sẽ là một bước chuyển tiếp tốt bảo mật một nhà
hoặc một SOHO WLAN. Tuy nhiên, cho một hệ thống lớn, 802.1x/EAP và VPN là
vẫn có thể phát triển và tồn tại được .
3.5.5 802.1x và EAP—bảo mật cấp cao
802.11x cung cấp một Framework nhận thực cho các WLAN, cho phép một
người sử dụng được nhận thực bởi một trung tâm nhận thực. Thuật toán thực tế
được sử dụng để xác định một người sử dụng là đúng hoặc sai và có thể ghép nhiều
thuật toán với nhau.
802.11x sử dụng EAP, một giao thực sẵn có làm việc trên Ethernet, Token
Ring, hoặc các WLAN cho việc trao đổi bản tin trong thời gian tiến trình nhận
thực.
3.5.6 Nhận thực cổng mạng 802.1x :
Nhận thực 802.1 x cho các WLAN có ba thành phần chính : Supplicant
(thường là các phần mềm máy khách), bộ nhận thực (AP), và AS (thông thường là
một server RADIUS). Các bộ nhận thực kết nối tới mạng LA. Hình 3-14 minh họa
tiến trình này.


Hình 3-14 : Nhận thực 802.1x
Dạng thông thường cho một nhân thực 802.11x như sau : Supplicant (trong
máy khách ) thử kết nối tới AP bằng cách gửi một bản tin bắt đầu. AP tìm ra
Supplicant và làm cho các cổng supplicant trong trạng thái không được phép, vì
vậy chỉ các bản tin 802.1x/EAP được chuyển tiếp. Tất cả các lưu lượng khác bị
chặn.
Supplicant sau đó gửi một bản tin EAP khởi động. AP tin tưởng vào một bản

tin toàn vẹn EAP - Yêu cầu để giành được nhận dạng Supplicant. Gói tin EAP –
Trả lời của máy khách bao gồm nhận dạng Supplicant để chuyển tiếp tới AS.
AS nhận thực Supplicant và các trả lời khác bằng cách chấp nhận hoặc loại
bỏ Supplicant.
3.5.7 Giao thức nhận thực mở rộng (EAP)
3.5.7.1 Giới thiệu
Để thiết lập liên lạc trên một liên kết Point – to – Point, mỗi đầu cuối của
của liên kết PPP đầu tiên phải gửi các gói tin LCP để định cấu hình liên kết dữ liệu
trong thời gian thiết lập liên kết. Sau khi các kết nối đã thiết lập, PPP cung cấp một
giai đoạn nhận thực tùy chọn trước khi đi đến giai đoạn giao thức tầng mạng.
Mặc định rằng, nhận thực là khôngbắt buộc. Nếu nhận thực của liên kết
được mong muốn, một thực thi phải chỉ rõ tùy chọn cấu hình giao thức nhận thực
trong thời gian Phase thiết lập liên kết.
Các giao thức nhận thực này được chỉ định cho sử dụng đầu tiên bởi các
Host và các router kết nối tới một server mạng PPP qua các chuyển mạch hoặc các
đường dial – up, nhưng có thể được chấp nhận để xác định các kết nối. Server có
thể sử dụng sự nhận dạng của kết nối host hoặc router trong sự lựa chọn các tùy
chọn cho tầng mạng.
3.5.7.2. Giao thức nhận thực có thể mở rộng điểm tới điểm (EAP)
Giao thức nhận thực có thể mở rộng (EAP) là một giao thức bảo mật tầng
giao vận của mô hình OSI, nói chung là một giao thức cho nhận thực PPP hỗ trợ
nhiều kĩ thuật nhận thực. EAP không lựa chọn một cơ chế nhận thực cụ thể tại Giai
đoạn điều khiển liên kết (Link Control Phase), đúng hơn là nó trì hoãn điều này
cho đến giai đoạn nhận thực. Điều này cho phép bộ nhận thực yêu cầu thêm thông
tin trước khi xác định cơ chế nhận thực rõ ràng. Điều này cũng chấp nhận sự sử
dụng một server “back - end” thi hành nhiều cơ chế khác nhau trong khi server
PPP chỉ đơn thuần đi qua tổng đài nhận thực.
1. Sau khi giai đoạn thiết lập kết nối được hoàn thành, bộ nhận thực gửi một
hoặc nhiều Request để nhận thực điểm. Request có một trường Type để xác
định những gì đang được yêu cầu. Ví dụ về các loại Request bao gồm

Identity, MD5-challenge, One-Time Passwords, Generic Thẻ bài Card…
Thông thường, bộ nhận thực sẽ gửi một Indentity Request theo sau bởi một
hoặc nhiều Request cho thông tin nhận thực. Tuy nhiên, một Indentity
Request không được yêu cầu, và có thể bỏ qua trong các trường hợp
Indentity là đoán được.
2. Điểm (Peer) gửi một gói tin Response trong trường Reply cho mỗi Request.
Cũng như gói tin Request, gói tin Respone bao gồm một trường Type tương
ứng với trường Type của Request.
3. Bộ nhận thực chấm dứt giai đoạn nhận thực với một gói tin thành công hoặc
thất bại (Succes or Failure packet).
Ưu điểm
Giao thức EAP có thể hỗ trợ nhiều cơ chế nhận thực không phải thực hiện
giai đoạn tiền đàm phán một cách riêng biệt trong giai đoạn LCP.
Các thiết bị không cần thiết phải hiểu mỗi loại Request và cũng có thể đơn
giản các hoạt động như một tác nhân passthrough cho một server “back - end” trên
một host. Thiết bị chỉ cần xem mã thành công/ thất bại để kết thúc giai đoạn nhận
thực.
Các nhược điểm
EAP thực hiện yêu cầu bổ sung một loại nhận thực mới cho LCP và vì thế
các thực thi PPP sẽ cần thiết phải được sử đổi để sử dụng nó. Nó cũng đi lạc khỏi
mô hình nhận thực PPP trước đó của một cơ chế nhận thực rõ ràng trong thời gian
LCP.
3.5.7.3 Cấu hình khuôn dạng tùy chọn
Cấu hình khuôn dạng tổng quát tùy chọn như sau:

Hình 3-15 : Khuông dạng tổng quát gói tin
Type 3
Length 4
3.5.7.4 Khuôn dạng gói tin
Chính xác một gói tin PP EAP được đóng gói trong trường thông tin của một

khung PPP tầng liên kết dữ liệu ở đây trường giao thức chỉ rõ loại Hex C227 (PPP
EAP). Dạng tổng quát của khuôn dạng gói tin EAP được biểu diễn như sau. Các
trường được phát từ trái qua phải.
Code Indentifier Length Data

Hình 3-15 : Khuôn dạng gói tin

Code
Trường code là một Octet và nhận dạng loại gói tin EAP. Các mã EAP được
gán như sau :
1 Request
2 Response
3 Success
4 Failure
Identifier :Trường Identifier gồm một octet.
Length : Trường Length gồm hai octet và chỉ rõ chiều dài của các gói tin
EAP bao gồm Code, identifier, Length và Data. Các octet bên ngoài phạm vi của
trường Length có thể coi là đệm tầng liên kết dữ liệu và không cần để ý khi tiếp
nhận.
Data : Trường Data gồm 0 hoặc nhiều octet. Khuôn dạng trường dữ liệu
được quyết định bởi trường Code.
Request and Response : Gói tin Request được gửi bởi bộ nhận thực tới
Peer. Mỗi Request có một loại trường phục vụ việc xác định những gì đang được
yêu cầu. Bộ nhận thực phải phát một gói tin EAP với tập trường mã tới 1
( Request). Các gói tin Request bổ sung được gửi cho đến khi một gói tin Response
hợp lệ được nhận. Các Request phát lại phải được gửi với cùng giá trị nhận dạng
để mà phân biệt được chúng với các Request mới. Các nội dung của trường dữ liệu
là phụ thuộc loại Request. Peer phải gửi một gói tin Request trả lời gói tin
Request.
Lưu ý : Bởi vì tiến trình nhận thực sẽ thường bao gồm đầu vào người sử

dụng.
Dạng tổng quát của gói tin Request và Respone được biểu diễn như sau.
Các trường được phát từ trái qua phải

Hình 3-16 : Gói tin Request và Respone
Code
1 cho Request;
2 cho Response.
Identifier
Trường Identifier gồm một octet. Trường Identifier phải giống nhau nếu một
gói tin Request được phát lại trong thời gian timeout trong khi đang chờ một
Response. Bất kỳ các Request mới nào cũng phải sửa đổi trường Identifier. Nếu
một Peer nhận một bản sao Request khi nó đã gửi một Response, nó phải gửi lại
một Respone. Nếu một Peer nhận một bản sao Request trước khi nó đã gửi một
Response tới Request đầu tiên, nó sẽ lặng lẽ loại bỏ bản sao Request.
Length
Trường Length gồm hai octet và chỉ rõ chiều dài của gói tin EAP bao gồm
Code, Indentifier, Length, Type, và Type – Data. Các octet ngoài phạm vi của
trường Length có thể coi là phần đệm tầng liên kết dữ liệu và không cần quan tâm
tới khi nhận.
Type
Trường Type gồm một octet. Trường này chỉ rõ loại Request và Response.
Chỉ một Type phải được xác định rõ trên Request hoặc Respone EAP. Thông
thường, trường Type của Response giống trường Type của Request. Tuy nhiên,
cũng có một Nak Response Type cho việc xác định rằng một Request Type không
được chấp nhận tới một điểm. Khi gửi một Nak trong một Respone tới một
Request, Peer có thể xác định rõ một Type nhận thực luân phiên.
Type-Data
Trường Type – data thay đổi cùng với Type của Request và Response.
Thành công và thất bại

Các gói tin thành công được gửi bởi bộ nhận thực tới điểm để xác nhận nhận
thực thành công. Bộ nhận thực phải phát một gói tin EAP với trường code thiết lập
3 (Success).
Nếu bộ nhận thực không thể nhận thực điểm khi ấy sự thực thi phải phát mọt
gói tin EAP với trường mã thiết lập bằng 4 (thất bại). Một bộ nhận thực có thể
muốn phát ra nhiều Request trước khi gửi một trả lời Failure để mà cho phép
người ta gõ sửa lỗi.
Dạng tổng quan của khuôn dạng gói tin Success và Failure được biểu diễn
như sau. Các trường được phát từ trái qua phải :

Hình 3-17 : Các trường gói tin
Code
3 cho Success;
4 cho Failure.
Identifier
Trường Identifier gồm một octet. Trường Identifier phải trùng với trường
Identifier của gói tin Response.
Length : 4 octet
3.5.7.5 Các loại Request /Response EAP ban đầu
Trường Type gồm một Octet và các nhận dạng cấu trúc của gói tin Request
hoặc Respone EAP. 3 Type đầu tiên được dành cho các Type đặc biệt. Các Type
còn lại định nghĩa các trao đổi nhận thực. Nak Type là hợp lệ chỉ đối với các gói
tin Respone, nó không được gửi trong một Request. Nak Type chỉ được gửi trong
việc trả lời tới một Request sử dụng một mã Type nhận thực. Tất cả các thực thi
EAP phải hỗ trợ các Type 1 – 4. Các Type này, cũng như các Type 5 và 6.
1 Nhận dạng
2 Khai báo
3 Nak (Response only)
4 MD5-Challenge
5 Mật khẩu một lần (OTP)

6 Generic Token Card
Nhận dạng
Trường Indentity được sử dụng để truy vấn nhận dạng điểm. Nói chung, bộ
nhận thực sẽ đưa ra điều này cũng như Request ban đầu. Có thể bao gồm Một
bản tin có thể hiển thị tùy chọn để nhắc Peer trong trường hợp mong muốn tương
tác với người sử dụng. Một Respone phải được gửi tới Request này với một Type1
(Nhận dạng).
Type : 1 octet
Type-Data : Trường này có thể bao gồm một bản tin có thể hiển thị Request.
Respone sử dụng trường này để trả về Indetity. Nếu Identity là không được biết,
trường này sẽ nhận các byte toàn 0. Trường không được kết thúc bằng Null. Chiều
dài của trường xuất phát từ trường Length của gói tin Request/Response và vì thể
một Null không được yêu cầu.
Khai báo (Notification)
Notification Type được sử dụng tùy ý để truyển một bản tin có thể hiển thị
từ một bộ nhận thực tới Peer. Peer nên hiển thị bản tin này tới người sử dụng hoặc
bản ghi nó nếu nó không thể được hiển thị. Nó được dự định để cung cấp một
thông báo xác nhận của một số tình trạng khẩn cấp.
Type : 2 octet
Type-Data : Trường Type-Data trong Request bao gồm một bản tin có thể
hiển thị. Độ dài của bản tin được xác định bởi trường Length của gói tin Request.
Bản tin phải không được kết cuối bằng Null. Một Respone phải được gửi trong sự
trả lời tới Request với một trường Type của 2 (Notification). Response nên được
gửi ngay lập tức.
Nak
Type-Data là hợp lệ chỉ trong bản tin Response. Nó được gửi trong trả lời tới
một Request ở dây Type nhận thực là không thể được chấp nhận. Các Type nhận
thực được đánh số 4.
Type : 3octet
Type-Data : Trường này phải bao gồm một octet đơn xác định loại

nhận thực mong muốn3.5.2 Điều khiển truy nhập cơ bản
Hiện nay, truy nhập cơ bản cũng giống như việc giấu một khoá dưới một
tấm thảm. Khoá được dấu ngoài để cho những người thông minh có thể tìm thấy,
nhưng mạng truy nhập và dữ liệu được truy nhập sẽ không có giá trị do sự cố ngắt
mạng.
Tối thiểu, người sử dụng nên kích hoạt WEP, các mật khẩu bảo vệ các thiết
bị dùng chung và các tài nguyên, thay đổi tên mạng từ SSID mặc định, sử dụng lọc
địa chỉ MAC, và tắt quảng bá nếu có thể. Viện công nghệ điện và điện tử (IEEE)
đang làm việc để loại bỏ khoá tránh tình trạng “khóa dưới thảm” bằng hai giải
pháp - cải tiến WEP tạm thời và thay thế WEP lâu dài.
3.5.3 Các phương thức bảo mật 802.11 ngoài WEP
Truy nhập bảo vệ Wi-Fi (WPA): tháng 11 năm 2002, liên minh Wi – Fi
thông báo tiêu chuẩn bảo mật WPA. Nó sẽ thay thế tiêu chuẩn WEP hiện tại trên
thiết bị Wi – Fi. Có thể thấy trước rằng nhiều nhà cung cấp sẽ đưa ra phần sụn và
phần mềm nâng cấp cho các sản phẩm Wi – Fi sẵn có để chúng làm việc với WPA.
WPA sử dụng giao thức toàn vẹn khoá tạm thời (TKIP), một kỹ thuật mật
mã cứng rắn hơn được sử dụng trong WEP. TKIP sử dụng khoá băm (KeyMix) và
kiểm tra tính toàn vẹn bản tin phi tuyến (MIC). TKIP cũng sử dụng một giao thức
rapid – rekeying (ReKey) thay đổi khoá mật mã cho khoảng 10.000 gói tin. Tuy
nhiên, TKIP không loại trừ những điểm yếu cơ bản trong bảo mật Wi – Fi. Nếu
một attacker tấn công TKIP, anh ta hoặc cô ta không chỉ bẻ gãy độ tin cậy, mà còn
điều khiển truy nhập và nhận thực.
WPA sẽ làm việc trong hai phương pháp khác nhau, tuỳ thuộc vào loại
mạng. Trong nhà và các văn phòng nhỏ, công nghệ sẽ làm việc trong chế độ khoá
“tiền chia sẻ”. Những người sử dụng nhập khoá mạng để giành quyền truy nhập.
Trong chế độ quản lý, nó sẽ làm việc với các AS và sẽ yêu cầu sự hỗ trợ của
802.1x và EAP.802.1x và EAP cho phép một bộ thích ứng mạng khách đàm phán
qua một AP với một back – end AS sử dụng các giao dịch mật mã an toàn để trao
đổi các khoá phiên.
WPA bao gồm nhiều phần của 802.11. Tuy nhiên, một số các phần tử khoá

không được bao gồm trong đó như là sự hỗ trợ cho một thuật toán mật mã mới gọi
là tiêu chuẩn mật mã hoá cấp cao (AES), tiêu chuẩn này sẽ thay thế thuật toán mật
mã RC4 cơ sở khi 802.11i trở nên phổ biến.
3.5.4 802.11 Phương pháp bảo mật ngoài WPA
WPA khi trở nên phổ biến, sẽ là một bước chuyển tiếp tốt bảo mật một nhà
hoặc một SOHO WLAN. Tuy nhiên, cho một hệ thống lớn, 802.1x/EAP và VPN là
vẫn có thể phát triển và tồn tại được .
3.5.5 802.1x và EAP—bảo mật cấp cao
802.11x cung cấp một Framework nhận thực cho các WLAN, cho phép một
người sử dụng được nhận thực bởi một trung tâm nhận thực. Thuật toán thực tế
được sử dụng để xác định một người sử dụng là đúng hoặc sai và có thể ghép nhiều
thuật toán với nhau.
802.11x sử dụng EAP, một giao thực sẵn có làm việc trên Ethernet, Token
Ring, hoặc các WLAN cho việc trao đổi bản tin trong thời gian tiến trình nhận
thực.
3.5.6 Nhận thực cổng mạng 802.1x :
Nhận thực 802.1 x cho các WLAN có ba thành phần chính : Supplicant
(thường là các phần mềm máy khách), bộ nhận thực (AP), và AS (thông thường là
một server RADIUS). Các bộ nhận thực kết nối tới mạng LA. Hình 3-14 minh họa
tiến trình này.


Hình 3-14 : Nhận thực 802.1x
Dạng thông thường cho một nhân thực 802.11x như sau : Supplicant (trong
máy khách ) thử kết nối tới AP bằng cách gửi một bản tin bắt đầu. AP tìm ra
Supplicant và làm cho các cổng supplicant trong trạng thái không được phép, vì
vậy chỉ các bản tin 802.1x/EAP được chuyển tiếp. Tất cả các lưu lượng khác bị
chặn.
Supplicant sau đó gửi một bản tin EAP khởi động. AP tin tưởng vào một bản
tin toàn vẹn EAP - Yêu cầu để giành được nhận dạng Supplicant. Gói tin EAP –

Trả lời của máy khách bao gồm nhận dạng Supplicant để chuyển tiếp tới AS.
AS nhận thực Supplicant và các trả lời khác bằng cách chấp nhận
hoặc loại bỏ Supplicant. 3.5.7 Giao thức nhận thực mở rộng (EAP)
3.5.7.1 Giới thiệu
Để thiết lập liên lạc trên một liên kết Point – to – Point, mỗi đầu cuối của
của liên kết PPP đầu tiên phải gửi các gói tin LCP để định cấu hình liên kết dữ liệu
trong thời gian thiết lập liên kết. Sau khi các kết nối đã thiết lập, PPP cung cấp một
giai đoạn nhận thực tùy chọn trước khi đi đến giai đoạn giao thức tầng mạng.
Mặc định rằng, nhận thực là khôngbắt buộc. Nếu nhận thực của liên kết
được mong muốn, một thực thi phải chỉ rõ tùy chọn cấu hình giao thức nhận thực
trong thời gian Phase thiết lập liên kết.
Các giao thức nhận thực này được chỉ định cho sử dụng đầu tiên bởi các
Host và các router kết nối tới một server mạng PPP qua các chuyển mạch hoặc các
đường dial – up, nhưng có thể được chấp nhận để xác định các kết nối. Server có
thể sử dụng sự nhận dạng của kết nối host hoặc router trong sự lựa chọn các tùy
chọn cho tầng mạng.
3.5.7.2. Giao thức nhận thực có thể mở rộng điểm tới điểm (EAP)
Giao thức nhận thực có thể mở rộng (EAP) là một giao thức bảo mật tầng
giao vận của mô hình OSI, nói chung là một giao thức cho nhận thực PPP hỗ trợ
nhiều kĩ thuật nhận thực. EAP không lựa chọn một cơ chế nhận thực cụ thể tại Giai
đoạn điều khiển liên kết (Link Control Phase), đúng hơn là nó trì hoãn điều này
cho đến giai đoạn nhận thực. Điều này cho phép bộ nhận thực yêu cầu thêm thông
tin trước khi xác định cơ chế nhận thực rõ ràng. Điều này cũng chấp nhận sự sử
dụng một server “back - end” thi hành nhiều cơ chế khác nhau trong khi server
PPP chỉ đơn thuần đi qua tổng đài nhận thực.
4. Sau khi giai đoạn thiết lập kết nối được hoàn thành, bộ nhận thực gửi một
hoặc nhiều Request để nhận thực điểm. Request có một trường Type để xác
định những gì đang được yêu cầu. Ví dụ về các loại Request bao gồm
Identity, MD5-challenge, One-Time Passwords, Generic Thẻ bài Card…
Thông thường, bộ nhận thực sẽ gửi một Indentity Request theo sau bởi một

hoặc nhiều Request cho thông tin nhận thực. Tuy nhiên, một Indentity
Request không được yêu cầu, và có thể bỏ qua trong các trường hợp
Indentity là đoán được.
5. Điểm (Peer) gửi một gói tin Response trong trường Reply cho mỗi Request.
Cũng như gói tin Request, gói tin Respone bao gồm một trường Type tương
ứng với trường Type của Request.
6. Bộ nhận thực chấm dứt giai đoạn nhận thực với một gói tin thành công hoặc
thất bại (Succes or Failure packet).
7. Ưu điểm
8. Giao thức EAP có thể hỗ trợ nhiều cơ chế nhận thực không phải thực hiện
giai đoạn tiền đàm phán một cách riêng biệt trong giai đoạn LCP.
9. Các thiết bị không cần thiết phải hiểu mỗi loại Request và cũng có thể đơn
giản các hoạt động như một tác nhân passthrough cho một server “back -
end” trên một host. Thiết bị chỉ cần xem mã thành công/ thất bại để kết thúc
giai đoạn nhận thực.
10. Các nhược điểm
11. EAP thực hiện yêu cầu bổ sung một loại nhận thực mới cho LCP và vì thế
các thực thi PPP sẽ cần thiết phải được sử đổi để sử dụng nó. Nó cũng đi lạc
khỏi mô hình nhận thực PPP trước đó của một cơ chế nhận thực rõ ràng
trong thời gian LCP.
12. 3.5.7.3 Cấu hình khuôn dạng tùy chọn
13. Cấu hình khuôn dạng tổng quát tùy chọn như sau:
14.

15. Hình 3-15 : Khuông dạng tổng quát gói tin
16. Type 3
17. Length 4
18. 3.5.7.4 Khuôn dạng gói tin
19. Chính xác một gói tin PP EAP được đóng gói trong trường thông tin của một
khung PPP tầng liên kết dữ liệu ở đây trường giao thức chỉ rõ loại Hex C227

(PPP EAP). Dạng tổng quát của khuôn dạng gói tin EAP được biểu diễn như
sau. Các trường được phát từ trái qua phải.
20.
Code Indentifier Length Data

21. Hình 3-15 : Khuôn dạng gói tin
22.
23. Code
24. Trường code là một Octet và nhận dạng loại gói tin EAP. Các mã EAP được
gán như sau :
25. 1 Request
26. 2 Response
27. 3 Success
28. 4 Failure
29. Identifier :Trường Identifier gồm một octet.
30. Length : Trường Length gồm hai octet và chỉ rõ chiều dài của các gói tin
EAP bao gồm Code, identifier, Length và Data. Các octet bên ngoài phạm vi
của trường Length có thể coi là đệm tầng liên kết dữ liệu và không cần để ý
khi tiếp nhận.
31. Data : Trường Data gồm 0 hoặc nhiều octet. Khuôn dạng trường dữ liệu
được quyết định bởi trường Code.
32. Request and Response : Gói tin Request được gửi bởi bộ nhận thực tới
Peer. Mỗi Request có một loại trường phục vụ việc xác định những gì đang
được yêu cầu. Bộ nhận thực phải phát một gói tin EAP với tập trường mã tới
1 ( Request). Các gói tin Request bổ sung được gửi cho đến khi một gói tin
Response hợp lệ được nhận. Các Request phát lại phải được gửi với cùng giá
trị nhận dạng để mà phân biệt được chúng với các Request mới. Các nội
dung của trường dữ liệu là phụ thuộc loại Request. Peer phải gửi một gói tin
Request trả lời gói tin Request.
33. Lưu ý : Bởi vì tiến trình nhận thực sẽ thường bao gồm đầu vào người sử

dụng.
34. Dạng tổng quát của gói tin Request và Respone được biểu diễn như sau.
Các trường được phát từ trái qua phải
35.
36. Hình 3-16 : Gói tin Request và Respone
37. Code
38. 1 cho Request;
39. 2 cho Response.
40. Identifier
41. Trường Identifier gồm một octet. Trường Identifier phải giống nhau nếu một
gói tin Request được phát lại trong thời gian timeout trong khi đang chờ một
Response. Bất kỳ các Request mới nào cũng phải sửa đổi trường Identifier.
Nếu một Peer nhận một bản sao Request khi nó đã gửi một Response, nó
phải gửi lại một Respone. Nếu một Peer nhận một bản sao Request trước khi
nó đã gửi một Response tới Request đầu tiên, nó sẽ lặng lẽ loại bỏ bản sao
Request.
42. Length
43. Trường Length gồm hai octet và chỉ rõ chiều dài của gói tin EAP bao gồm
Code, Indentifier, Length, Type, và Type – Data. Các octet ngoài phạm vi
của trường Length có thể coi là phần đệm tầng liên kết dữ liệu và không cần
quan tâm tới khi nhận.
44. Type
45. Trường Type gồm một octet. Trường này chỉ rõ loại Request và Response.
Chỉ một Type phải được xác định rõ trên Request hoặc Respone EAP.
Thông thường, trường Type của Response giống trường Type của Request.
Tuy nhiên, cũng có một Nak Response Type cho việc xác định rằng một
Request Type không được chấp nhận tới một điểm. Khi gửi một Nak trong
một Respone tới một Request, Peer có thể xác định rõ một Type nhận thực
luân phiên.
46. Type-Data

47. Trường Type – data thay đổi cùng với Type của Request và Response.
48. Thành công và thất bại
49. Các gói tin thành công được gửi bởi bộ nhận thực tới điểm để xác nhận nhận
thực thành công. Bộ nhận thực phải phát một gói tin EAP với trường code
thiết lập 3 (Success).
50. Nếu bộ nhận thực không thể nhận thực điểm khi ấy sự thực thi phải phát mọt
gói tin EAP với trường mã thiết lập bằng 4 (thất bại). Một bộ nhận thực có
thể muốn phát ra nhiều Request trước khi gửi một trả lời Failure để mà cho
phép người ta gõ sửa lỗi.
51. Dạng tổng quan của khuôn dạng gói tin Success và Failure được biểu diễn
như sau. Các trường được phát từ trái qua phải :
52.
53. Hình 3-17 : Các trường gói tin
54. Code
55. 3 cho Success;
56. 4 cho Failure.
57. Identifier
58. Trường Identifier gồm một octet. Trường Identifier phải trùng với trường
Identifier của gói tin Response.
59. Length : 4 octet
60. 3.5.7.5 Các loại Request /Response EAP ban đầu
61. Trường Type gồm một Octet và các nhận dạng cấu trúc của gói tin Request
hoặc Respone EAP. 3 Type đầu tiên được dành cho các Type đặc biệt. Các
Type còn lại định nghĩa các trao đổi nhận thực. Nak Type là hợp lệ chỉ đối
với các gói tin Respone, nó không được gửi trong một Request. Nak Type
chỉ được gửi trong việc trả lời tới một Request sử dụng một mã Type nhận
thực. Tất cả các thực thi EAP phải hỗ trợ các Type 1 – 4. Các Type này,
cũng như các Type 5 và 6.
62. 1 Nhận dạng
63. 2 Khai báo

64. 3 Nak (Response only)
65. 4 MD5-Challenge
66. 5 Mật khẩu một lần (OTP)
67. 6 Generic Token Card
68. Nhận dạng
69. Trường Indentity được sử dụng để truy vấn nhận dạng điểm. Nói chung, bộ
nhận thực sẽ đưa ra điều này cũng như Request ban đầu. Có thể bao gồm
Một bản tin có thể hiển thị tùy chọn để nhắc Peer trong trường hợp mong
muốn tương tác với người sử dụng. Một Respone phải được gửi tới Request
này với một Type1 (Nhận dạng).
70. Type : 1 octet
71. Type-Data : Trường này có thể bao gồm một bản tin có thể hiển thị Request.
Respone sử dụng trường này để trả về Indetity. Nếu Identity là không được
biết, trường này sẽ nhận các byte toàn 0. Trường không được kết thúc bằng
Null. Chiều dài của trường xuất phát từ trường Length của gói tin
Request/Response và vì thể một Null không được yêu cầu.
72. Khai báo (Notification)
73. Notification Type được sử dụng tùy ý để truyển một bản tin có thể hiển thị
từ một bộ nhận thực tới Peer. Peer nên hiển thị bản tin này tới người sử dụng
hoặc bản ghi nó nếu nó không thể được hiển thị. Nó được dự định để cung
cấp một thông báo xác nhận của một số tình trạng khẩn cấp.
74. Type : 2 octet
75. Type-Data : Trường Type-Data trong Request bao gồm một bản tin có thể
hiển thị. Độ dài của bản tin được xác định bởi trường Length của gói tin
Request. Bản tin phải không được kết cuối bằng Null. Một Respone phải
được gửi trong sự trả lời tới Request với một trường Type của 2
(Notification). Response nên được gửi ngay lập tức.
76. Nak
77. Type-Data là hợp lệ chỉ trong bản tin Response. Nó được gửi trong trả lời tới
một Request ở dây Type nhận thực là không thể được chấp nhận. Các Type

nhận thực được đánh số 4.
78. Type : 3octet
79. Type-Data : Trường này phải bao gồm một octet đơn xác định loại nhận
thực mong muốn