Xem mẫu
- ĐỒ Á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 độ Cấu hình Bảo đảm Ứng dụng
bảo mật
Mạng ở ngoài và Các dịch vụ ứng dụng
Không có
không cấu hình không được bảo mật thông
gì
0 Không
tin. Tuy nhiên nhiều người
bảo mật
sử dụng vẫn dùng các dịch
vụ mạng này.
Truy nhập Nhận thực người sử Truy nhập Thư viện, cửa hàng cafe,
1 công cộng dụng mạng khách sạn, sân bay….
- 40- or 128-bit WEP, Một số Home và SOHO với tính
MAC access control mạng truy di chuyển.
Bảo mật
list (ACL), và không nhập và
giới hạn
quảng bá bả o mật
2 dữ liệu
Truy nhập bảo mật Truy nhập Nhà, SOHO, và các hệ
(WPA) (later mạng và thống nhỏ linh động.
Wi-Fi
Bảo mật
3
bả o mật
802.11i)
cơ s ở
dữ liệu
và Truy nhập Các hệ thống linh động
802.1x/EAP-X
mạng
RADIUS và
Bảo mật
bả o mật
cấp cao
4
dữ liệu
cũng như Truy nhập Các ứng dụng đặ biệt, trao
5 VPNs
mạng và đổi thường mại, liên lạc…
Point-to-Point
Bảo mật
Protocol bảo mật
đầu cuối – Tunneling
PPTPv2, dữ liệu
tới – đầu (PPTP),
Layer 2 Tunneling
cuối
Protocol (L2TP),
Kerberos, và IP
Security (IPSec)
- 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.
Nhận dạng
1
2 Khai báo
3 Nak (Response only)
4 MD5-Challenge
Mật khẩu một lần (OTP)
5
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.
Code Indentifier Length Data
20.
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.
nguon tai.lieu . vn