Xem mẫu

  1. ĐỒ Á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….
  2. 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. 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
  4. 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 .
  5. 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
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. 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 :
  12. 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
  13. 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
  14. 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
  15. 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.
  16. 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.
  17. 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ử
  18. 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
  19. 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
  20. 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