BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP.

HCM

ĐỀ TÀI BẢO MẬT THÔNG TIN

EXTENSIBLE AUTHENTICATION PROTOCOL
TRANSPORT LAYER SECURITY (EAP-TLS)

Khoa: Chuyên ngành:

Công Nghệ Thông Tin Mạng Máy Tính

Giảng viên hướng dẫn: Nhóm Sinh viên thực hiện: Mã Chí Trung Mssv: 1191020168 Phạm Minh Trung Mssv: 1191020164 Phạm Gia Đông Mssv: 1191020017 Trịnh Hưng Hưng Mssv: 1191020039 Võ Thanh Tâm Mssv: 1191020120 Trịnh Đăng Tuấn Mssv: 1191020175

Th.S Văn Thiên Hoàng

Lớp: 11HTHM1 Lớp: 11HTHM1 Lớp: 11HTHM1 Lớp: 11HTHM1 Lớp: 11HTHM1 Lớp: 11HTHM1

TP. Hồ Chí Minh, 2012

CHƯƠNG I: GIỚI THIỆU TỔNG QUAN EAP-TLS

1.1 EAP-TLS là gì ?
EAP-TLS là chữ viết tắt của Extensible Authentication Protocol – Transport Layer Security (giao thức thẩm định quyền truy cập có thể mở rộng – bảo mật lớp truyền dẫn). Kết nối dựa trên giao thức này đòi hỏi có một chứng nhận người sử dụng (user certificate) trên cả máy khách và máy chủ IAS . Đây là cơ chế có mức độ an toàn nhất ở cấp độ người sử dụng, nó cho phép một phương pháp xác thực tùy ý được sử dụng để truyền thông tin ủy nhiệm và trao đổi thông tin có chiều dài tùy ý. EAP là một phần mở rộng cho Point-to-point (PPP) và giao thức này được tổ chức IETF định nghĩa trong cuốn RFC 2284. Các đặc tính của EAP-TLS bao gồm:
   

Xác thực lẫn nhau (giữa máy chủ và khách hàng) . Trao đổi khoá (để thiết lập WEP động và khoá TKIP) . Phân mảnh và nối lại (với bản tin EAP dài cần có phần kích thước kiểm tra nếu cần) . Kết nối nhanh (thông qua TLS) .

1.1.1 Nhu cầu sử dụng
EAP được tạo nhằm phản hồi lại yêu cầu về những phương pháp xác thực mạnh mẽ hơn, những phương pháp này sao lưu dự phòng những thiết bị bảo mật bổ sung, chẳng hạn như các chứng nhận hoặc smart card cũng như các tổ hợp tên người dùng và password chuẩn. Hiện nay EAP là phương pháp theo tiêu chuẩn công nghiệp để sử dụng với những phương pháp xác thực bổ sung với PPP. EAP-TLS sử dụng khoá kiểm tra công khai TLS trong EAP để cung cấp việc xác thực lẫn nhau giữa máy chủ và khách hàng. Với EAP-TLS, cả máy chủ và khách hàng đều phải đăng ký chữ ký dạng số thông qua quyền chứng thực (CA) để kiểm tra. EAP cung cấp bảo mật mạnh mẽ bằng cách yêu cầu cả máy chủ lẫn máy khách xác nhận chứng thực bằng PKI.Các gói tin EAP tương tác với máy khách lẫn máy chủ được mã hóa và bảo vệ kết nối mạng bằng TLS. Nhược điểm với giao thức này là sử dụng và cài đặt chứng thực luôn ở cả hai bên.

1.1.2 Giải pháp công nghệ liên quan
Ngày nay các mạng 802.11 xác thực theo chuẩn 802.1x . Chuẩn này xác định giao thức xác thực mở rộng (EAP) trực tiếp qua lớp kết nối. EAP là giao thức truyền thông được sử dụng thông qua các loại cơ chế xác thực khác nhau. Các phương pháp EAP phát triển cho mạng không dây được dựa trên việc kiểm tra thông qua khoá công cộng và giao thức bảo mật tại lớp truyền dẫn (TLS). Các giao thức đó là EAP-TLS, EAP-TTLS và PEAP.  EAP-TTLS : Giao thức chứng thực đường hầm (EAP-TTLS) cung cấp một loạt các thuộc tính cho một bản tin như RADIUS EAP - dùng tầng vận chuyển, EAP-TTLS có thể cung cấp các chức năng như phương thức PEAP . Tuy nhiên nếu mật khẩu của RADIUS hoặc CHAP được mã hoá, thì TTLS có thể bảo vệ được các tính chất kế thừa của RADIUS. Khi máy chủ TTLS gửi bản tin RADIUS tới máy chủ tại đích, nó sẽ giải mã các thuộc tính bảo vệ của EAP-TTLS và chèn chúng trực tiếp vào bản tin chuyển đi. Bởi vì phương thức này giống như PEAP, nên nó ít được sử dụng hơn.

Hình 1- Giao diện TTLS  PEAP : Giống như chuẩn TTLS, PEAP tạo khả năng xác thực cho mạng LAN không dây mà không yêu cầu xác thực. Protected EAP ( PEAP ) thêm lớp TLS lên trên cùng EAP giống như EAP-TTLS, rồi sau đó sử dụng kết quả của phiên TLS như phương tiện vận chuyển để bảo vệ phương thức EAP. PEAP sử dụng TLS để xác thực từ máy chủ tới máy trạm nhưng không có chiều ngược lại. Theo phương thức này chỉ máy chủ yêu cầu khoá xác thực còn khách hàng thì không. Máy chủ và máy trạm trao đổi chuỗi thông tin mã hoá trong TLS, và bản tin TLS được xác thực và mã hoá sử dụng khoá đã được thông qua giữa hai bên.

PEAP cung cấp dịch vụ cho phương thức EAP như sau:

Bản tin xác nhận (Những kẻ tấn công sẽ rất khó khăn trong việc chèn vào bản tin EAP) . Mã hoá bản tin (Những kẻ tấn công sẽ không thể đọc và giải mã bản tin EAP) Xác thực từ máy chủ đến khách hàng (vì thế phương thức này chỉ cần bảo vệ xác thực từ khách hàng tới máy chủ) . Trao đổi khoá (để thiết lập cho WEP động hoặc khoá TKIP) . Phân mảnh và ghép lại (cần thiết nếu bản tin EAP dài) . Thiết lập kết nối nhanh ( thông qua phiên TLS ) .

 

  

1.1.3 Môi trường áp dụng
EAP-TLS thường được sử dụng trong các mô trường doanh nghiệp lớn, tuy nhiên cũng có thể được sử dụng trong các tổ chức nhỏ hơn. 802.1x là chuẩn đặc tả cho việc truy cập dựa trên cổng (port-based) được định nghĩa bởi IEEE. Hoạt động trên cả môi trường có dây truyền thống và không dây. Việc điều khiển truy cập được thực hiện bằng cách: khi một người dùng cố gắng kết nối vào hệ thống mạng, kết nối của người dùng sẽ được đặt ở trạng thái bị chặn ( blocking ) và chờ cho việc kiểm tra định danh người dùng hoàn tất.

Mô hình xác thực 802.1X-EAP cho Client diễn ra như sau:

Quá trình trao đổi thông tin xác thực của 802.1x .Hình 2.

1.4 Phân loại EAP Packet Type 1–6 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Description Assigned by RFC Identity Notification Nak (response only) MD5-Challenge One-Time Password (OTP) Generic Token Card (GTC) Not assigned Not assigned RSA Public Key Authentication DSS Unilateral KEA KEA-VALIDATE EAP-TLS Defender Token (AXENT) RSA Security SecurID EAP Arcot Systems EAP EAP-Cisco Wireless (LEAP) Nokia IP SmartCard authentication SRP-SHA1 Part 1 SRP-SHA1 Part 2 EAP-TTLS Remote Access Service UMTS Authentication and Key Agreement EAP-3Com Wireless PEAP MS-EAP-Authentication Mutual Authentication w/Key Exchange (MAKE) CRYPTOCard .1.

sự bắt tay của giao thức mã hóa và sự trao đổi khóa bảo vệ giữa một client không dây và mạng EAP-TLS là một kỹ thuật cung cấp các khóa mã hóa động cho người dùng và session.29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44-191 192–253 254 255 EAP-MSCHAP-V2 DynamID Rob EAP SecurID EAP EAP-TLV SentriNET EAP-Actiontec Wireless Cogent Systems Biometrics Authentication EAP AirFortress EAP EAP-HTTP Digest SecureSuite EAP DeviceConnect EAP EAP-SPEKE EAP-MOBAC EAP-FAST Not assigned. Chú ý rằng sự truy cập không dây được cung cấp cho tới khi sự xác nhận thành công và các khóa WEP động đã được thiết lập. requires standards action Expanded types Experimental usage 1. Sự trao đổi của các message EAP-TLS cung cấp sự xác nhận lẫn nhau.1x EAP-TLS được sử dụng trong các mô trường cơ bản và an toàn cao.2 Mô hình kiến trúc và triển khai ứng dụng 802. can be assigned by IANA on the advice of a designated expert Reserved. Hai chứng chỉ digital được yêu cầu ở đây: một trên RADIUS server (ví dụ EAS) và một trên Client không dây. Hình dưới đây chỉ ra một chuỗi các sự kiện xuất hiện khi một Client được xác nhận bằng 802.1x EAP-TLS. . Điều này cải thiện một cách đáng kể và vượt qua nhiều điểm yếu trong các mạng không dây.

1x EAP-TLS 802.WLAN có thể sử dụng Windows XP (được xây dựng để hỗ trợ cho 802.1x EAP-TLS hay Windows 98/Me/2000) bằng việc sử dụng Madge Wireless LAN Utility (WLU).1x EAP-TLS với EAS trong Controller Mode Client không dây có chứng chỉ điện tử (digital certificate) được cài đặt từ trước. dữ liệu người dùng cũng có thể được sử dụng EAS mà đã được cấu hình trong Gateway Mode. AP và EAS) hỗ trợ cho quá trình chứng thực 802. Khi xác nhận.1x EAP-TLS. Tất cả ba thành phần (Wireless client. Hình 4. Mạng nội bộ không dây (WLAN) giao tiếp với EAS thông qua Access Point (AP).802.Hình 3-Xác nhận 802.1x EAP-TLS trong Controller Mode .

1 Giao thức EAP-TLS: 2.1 Sơ đồ hoạt động của EAP-TLS (RFC 5216) .1.CHƯƠNG II: GIAO THỨC EXTENSIBLE AUTHENTICATION PROTOCOL – TRANSPORT LAYER SECURITY 2.

session ID. một con số phát sinh ngẫu nhiên và bộ mã hoá được hỗ trợ bởi client. thì gói tin mà nó gửi cho client phải bao gồm thông điệp bắt tay ( handshake message) TLS server_certificate và server_done_hello handshake message phải là thông điệp bắt tay cuối cùng được đóng gói trong gói tin EAP-Request.0 hoặc cao hơn. . cuộc trò chuyện bắt đầu. server_key_exchange. chứa thông điệp bắt tay ( TLS client_hello ). Một khi đã nhận được Identity của client. EAP-Server sẽ trả lời lại với một gói tin EAP-Request với EAP-type=EAP-TLS.Phiên bản TLS của client phải tương ứng với TLS v1.Ngược lại nếu session ID mà server nhận được từ client trùng khớp với session ID client gửi thì phiên giao dịch trước đó sẽ được bắt đầu lại với session ID này. Nếu server không bắt đầu lại với phiên giao dịch đã thiết lập trước đó . Certificate message chứa một chứng chỉ khoá công khai (public key certificate) hoặc là trao đổi khoá công khai ( chẳng hạn như RSA hoặc Diffie-Hellman ) hoặc là chữ ký khoá công khai ( như là RSA hay DSS-Digital Signature Standard ). certificate_request. đó là một gói EAP-Request với EAP-type=EAP-TLS. type=EAP-TLS.Bên server sẽ gửi một gói tin EAP-Request cho client yêu cầu xác định danh tính ( Indentify ).Trong đó server_hello_handshake message gồm TLS version number . Nếu bên phía client hỗ trợ EAP-TLS và được cấu hình để sử dụng giao thức này thì phải phản hồi gói tin EAP-Request bằng gói tin EAP-Response với type=EAP-TLS.Nếu server_hello_message trước đó được gửi bởi EAP-Server trong gói tin EAP-Request trước đó không bắt đầu lại phiên giao dịch trước thì trường dữ liệu của gói tin phải đóng gói bằng một hoặc nhiều TLS record trong đó chứa TLS client_key_exchange. EAP-Server phải phản hồi cho client bằng gói tin EAP-TLS start.Được mô tả trong RFC 5216. cuộc đối thoại sẽ được bắt đầu với bên gửi và bên nhận tiến hành thương lượng các gói tin EAP.server_hello_done. change_cipher_spec và finished message.Trường dữ liệu của gói tin sẽ được đóng gói một hoặc nhiều TLS record ở định dạng TLS record layer. session ID và một bộ mã hoá ( ciphersuite ). Nếu session ID của client là null hoặc server không thể nhận biết được thì lúc này server sẽ phải chọn một session ID khác để thiết lập phiên giao dịch mới. bên phía client sẽ gửi một gói tin EAP-Response. gói tin này bao gồm TLS server_hello handshake message. Client_hello message bao gồm số phiên bản TLS của client ( peer’s TLS version number ).Kể từ đó cuộc nói chuyện sẽ được bắt đầu giữa EAP-Server và client. sau đó client sẽ phản hồi ngược lại cho server bằng gói tin EAP-Response chứa User-ID của mình. một con số phát sinh ngẫu nhiên khác ( another random number ).

2. Nếu server_hello_message trước đó được gửi từ server nằm trong gói EAP-Request bắt đầu lại phiên giao dịch trước thì bên phía client chỉ phải gửi change_cipher_spec và finished_ handshake_message ( chứa client authentication phản hồi lại EAP-Server ). trừ khi client được cấu hình riêng thì client phải gửi bổ sung certificate và certificate_verify_message. 3.1. Success.1 EAP-TLS Packet Format : (RFC 3748) Một EAP-TLS packet có cấu trúc như sau :  Code : code field chiếm 1 octet và nhận dạng các loại gói tin EAP. 2. Identifier: Identifier field chiếm 1 octet và giúp cho Response và Request trùng khớp với nhau.  .Nếu EAP-Server gửi một certificate_request_message trong gói EAP-Request trước đó. Request. 4.1. Response. Failure.EAP-Server sẽ xác nhận certificate của client và chữ ký điện tử nếu server được yêu cầu. 1.

Mỗi octet của gói tin EAP bao gồm Code. Identifier . Length .  2.1. Flags :       L: M: S: R: Length included More fragments EAP-TLS start Reserved . Indentifier : phải được thay đổi trên mỗi Request Packet.1. Type và Data Field.Một message với trường độ dài ( Length Field ) nào mà thiết lập giá trị lớn hơn số lượng các octet nhận được phải được loại bỏ. cho biết độ dài của gói tin. Identifier .2 EAP-TLS Request Packet : (RFC 5216) Một EAP-TLS Request Packet có cấu trúc như sau:    Code : giá trị =1 ( request packet ).Định dạng của trường dữ liệu được xác định bởi Code Field. Length: chiếm 2 octet . Data: có thể là 0 hoặc chiếm nhiều octet. Type : nhận giá trị=13 –EAP-TLS. Length và Data fields.Những octet nào nằm ngoài giá trị của Length field sẽ bỏ qua. Length : cho biết độ dài của gói tin EAP bao gồm Code.

3 EAP-TLS Response Packet : (RFC 5216) Có cấu trúc tương tự EAP-TLS Request Packet. -Bit S : được cài đặt làm EAP-TLS start message. Flags :   . -Bit M : hiển thị tất cả ngoại trừ fragment cuối. Identifier. Type và Data Field.Nó cung cấp tổng chiều dài của TLS Message hoặc bộ message đang được phân đoạn.1. -Bit R : bit dự trữ. Type: nhận giá trị =13-EAP-TLS. -Bit L cho biết sự hiện diện của 4 octets TLS message field và được đặt cho phân đoạn mạng ( fragment ) đầu tiên của fragmented TLS message. Identifier : chiếm 1 octet. khác biệt với fragment acknowledgment. phải trùng khớp với Identifier form request. TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS Record. Length : chiếm 2 octet.  2.1. trường này chỉ hiện diện nếu bit L bật lên. Length.Những byte nào nằm ngoài dãy Lengh Field được xemm như là lớp độn data link layer và phải được bỏ qua khi tiếp nhận. TLS Message Length : chiếm 4 octet . cho biết độ dài của gói tin EAP bao gồm Code.    Code : giá trị = 2 ( response packet ).

. Success & failure packets không được chứa dữ liệu bổ sung và phải không được gửi bởi EAP server nếu phương pháp chứng thực không cho phép kết thúc tại thời điểm đó. -Bit R : bit dự trữ.Trường này cung cấp tổng chiều dài của TLS Message hoặc bộ message đang được phân đoạn.1.  2. L:  M:  R: Length included More fragments Reverved -Bit L : chiếm 4 octet.  TLS Message Length : chiếm 4 octet. -Bit M : gồm tất cả ngoại trừ fragment cuối. chỉ hiện diện nếu bit L bật lên.4 EAP-TLS Success and Failure : (RFC 3748) Gói tin thành công được gửi từ server đến client sau khi hoàn thành bằng phương pháp chứng thực EAP ( type = 4 hoặc lớn hơn ) để cho biết rằng client đã chứng thực thành công bởi server. thì phải truyển một gói tin EAP bổ sung với Code = 4 ( failure ) .1. cho biết sự hiện diện của trường TLS Message và được đặt cho phân đoạn ( fragment ) đầu tiên của fragmented TLS message. TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS record. Server phải truyền một gói tin EAP với Code = 3 ( success ). Nếu server không thể chứng thực được client ( không thể chấp nhận phản hồi từ một hay nhiều yêu cầu ) sau khi chứng thực bằng phương pháp EAP kết thúc không thành công.

2.1. thông báo trên không được yêu cầu.Chẳng hạn như 1 mật khẩu sắp hết hạn thì số thứ tự của mật khẩu đó gần bằng 0.Các thông điệp không được mang giá trị kết thúc là rỗng ( NULL ). . Type: = 2 Type-Data: trường dữ liệu bên Request chứa đúng 1 thông điệp hiển thị có độ dài lớn hơn 0.1. Hầu hết trong các trường hợp. Notification được thiết kế để cung cấp thông báo chấp nhận của 1 số tính chất bắt buộc.3 Nak Chỉ có giá trị trong các tin nhắn phản hồi ( response message ).1.Nếu Identity không rõ ràng thì trường này có chiều dài là 0 octet và không được mang giá trị rỗng ( NULL ).2.2 Initial EAP Request / Respones Types (RFC-2284) 2.Nhà chứng thực sẽ cấp phát yêu cầu lúc ban đầu.Kiểu chứng thực được đánh số thứ tự là 4 và lớn hơn nữa.Chiều dài của thông điệp này được xác định bởi trường độ dài ( Length Field ) của gói tin Request.2.Nó được gửi để trả lời cho bên Request nơi mà nếu kiểu xác thực không thể chấp nhận được.Bên Response chứa kiểu chứng thực mà client mong muốn. Bên phản hồi sử dụng trường này để trả lại Indentity.2 Notification Được tuỳ chọn sử dụng để truyền tải thông tin được hiển thị từ nhà chứng thực đến với client. Type: = 1 Type-Data : trường này chưa thông điệp có thể hiển thị bên phản hồi ( Request).Thông báo phản hồi phải được gửi cho bên Request với type = 1.1 Identity Được sử dụng để xác định danh tính của client. Trường này có chiều dài nhận từ độ dài của gói tin Request/Response do đó giá trị NULL là không cần thiết.Client nên hiển thị thông tin đến với người sử dụng hoặc đăng nhập vào nếu không thể hiển thị được.Trường dữ liệu ( datatype ) của bên phản hồi có độ dài là 0 octet và phải được gửi ngay lập tức.2. 2.2.Một thôn g báo được hiển thị them có thể gồm dấu nhắc lệnh cho client trong trường hợp đang tương tác với người sử dụng.Bên phản hồi ( Response) phải được gửi hồi đáp cho bên yêu cầu ( Request ) tới type = 2 ( notification ).1.

2.1. Type: =5 Type-Data: OPT Challenge là một thông điệp hiển thị của bên Request.4 MD5-Challenge Tương tự như giao thức PPP CHAP. Type : = 4 Type-Data: nội dung của trường dữ liệu này được tóm tắt dưới đây 2.Bên Request chứa 1 “challenge” message và gửi cho client. trường này được sử dụng cho “6 từ” trong “One-Time Password System” ( RFC-1938 ).Type: =3 Type-Data: phải chứ duy nhất 1 octet để chỉ rõ kiểu chứng thực mong muốn. .6 Generic Token Card Được định nghĩa để sử dụng với việc triển khai Token Card khác nhau mà yêu cầu người sử dụng nhập vào. 2.Bên hồi đáp.Bên phía phản hồi ( Response ) phải gửi trả lời cho bên Request và phải thuộc loại 5 ( OPT ) hoặc 3 ( Nak ).1.1.Độ dài của trường này nhận được từ chiều dài của gói tin Request/Response.Việc triển khai EAP phải hỗ trợ cơ chế chứng thực MD5-Challenge.5 One-Time Password (OPT) Bên yêu cầu ( Request ) chứa một thông điệp hiển thị gồm 1 OPT Challenge.2. 2.2.Nak reply cho biết kiểu cơ chế chứng thực mà client mong muốn.Thông tin này được người sủ dụng đọc từ thiết bị Token Card và nhập như dạng văn bản ASCII. bên Response phải được gửi để trả lời cho bên Resquest và có thể có loại 4 ( MD5-Challenge ) hoặc loại 3 ( Nak ).Các thông điệp này không được kết thúc bằng giá trị rỗng ( NULL ).Bên yêu cầu chứa một tin nhắn dạng văn bản ASCII và bên trả lời chứa tin nhắn Token Card cần thiết cho việc chứng thực.

2.Lớp thứ hai là Record Protocol Layer. Record Layer Protocol: giao thức ở lớp này nhận và mã hoá dữ liệu từ lớp ứng dụng (application layer) và cung cấp cho lớp vận chuyển(Transport layer ).Record Protocol lấy dữ liệu.Lớp đầu tiên là Handshake Protocol Layer bao gồm ba giao thức con: Handshake Protocol. và chứa dữ liệu từ Token Card đòi hỏi việc xác thực. phân mảnh nó cho phù hợp với kích thước của thuật toán mã hoá.Chiều dài của thông điệp này được xác định bởi trường độ dài ( Length Field ) của gói tin Request và không được mang giá trị rỗng ( NULL). Handshake Protocol chịu trách nhiệm cho việc thương lượng phiên giao dịch bao gồm các hạng mục sau đây : .Chiều dài của dữ liệu được xác định bởi trường dữ liệu của gói tin Response.Bên phản hồi phải gửi tin nhắn trả lời cho bên yêu cầu với type = 6. Change Cipher Spec Protocol và Alert Protocol.Type: = 6 Type-Data: trường dữ liệu bên yêu cầu chứa thông điệp để hiển thị có độ dài lớn hơn 0 octet.3 TLS Protocol (RFC 4346) TLS Protocol được chia làm hai lớp. áp dụng MAC (Message Authentication code ) hoặc HMAC ( Hash-based Message Authentication Code ) và sau đó mã hoá hoặc giải mã dữ liệu bằng cách sử dụng thông tin đã thoả thuận trước trong Handshake Protocol.1.

 Peer Certificate: chứng chỉ X509v3 [X509] của client.  Compression method: thuật toán dùng để nén dữ liệu trước khi mã hoá.Giao thức gồm một tin nhắn đơn lẻ được mã hoá và nén bằng trạng thái kết nối hiện tại. Change cipher spec message được gửi cho cả client và server để thông báo cho bên nhận rằng các bản ghi ( record ) tiếp theo sẽ được bảo vệ bằng CipherSpec mới nhất và các khoá. . (255) } type. Message này gồm 1 byte riêng lẻ có giá trị = 1 struct { enum { change_cipher_spec(1).1. Sau khi gửi thông điệp này đi. trạng thái này có thể là Null. người gửi (sender) phải hướng dẫn cho Record Layer biết để chuyển sang trạng thái ghi và trạng thái này được kích hoạt.Change cipher spec message được gửi trong suốt quá trình bắt tay ( handshake ) sau khi các thông số bảo mật đạt được thoả thuận nhưng trước khi thông điệp xác nhận kết thúc ( verifying finished message ) được gửi.  Resumable: một lá cờ hiệu cho biết rằng liệu phiên giao dịch có thể được sử dụng để bắt đầu kết nối mới. DES … ) và thuật toán MAC ( MD5 hoặc SHA ). ngoài ra nó còn định nghĩa mã hoá các thuộc tính như kích thước hàm băm ( hash_size ).  Master secret: 48 byte bí mật được chia sẻ giữa client và server.1 Change Cipher Spec Protocol Là giao thức tồn tại để báo hiệu quá trình chuyển đổi chiến lược mã hoá. } ChangeCipherSpec.  Cipher spec: chỉ định các thuật toán mã hoá dữ liệu số lượng lớn ( vd như Null . 2.Việc tiếp nhận thông điệp (message) này được thực hiện đối với bên nhận để chỉ cho Record Layer sao chép trạng thái chờ đọc vào trạng thái đọc hiện hành ngay lập tức.3. Session Identifier: một chuỗi byte tuỳ ý được lựa chọn bởi máy chủ để xác định trạng thái phiên giao dịch một cách chủ động hoặc có thể khôi phục lại.

1.3.2 Alert Protocol Một trong các kiểu nội dung được hỗ trợ bởi phân lớp TLS Record là kiểu báo động ( Alert Type ). tin nhắn cảnh báo được mã hoá và nén như được chỉ định trước bởi trạng thái kết nối hiện hành. Tin nhắn cảnh báo với kết quả mà gây ra thiệt hại nghiệm trọng thì kết nối đó sẽ được huỷ ngay lập tức. Alert Level Types .Change Cipher Spec Protocol 2.Trong trường hợp này. các kết nối khác tương ứng với phiên giao dịch có thể tiến hành tiếp tục nhưng phiên giao dịch định danh ( session identifier ) phải bị mất hiệu lực và ngăn chặn các phiên không thành công ( fail session ) được sử dụng cho việc thiết lập kết nối mới. Alert message truyền đạt mức độ nghiêm trọng của tin nhắn và sự mô tả về cảnh báo.Cũng giống như các tin nhắn khác.

3. Thông điệp bắt tay được cung cấp cho TLS Record Layer. . trao đổi ngẫu nhiên các giá trị và kiểm tra phiên tiếp tục. chúng được xử lý và truyền đi theo quy định của trạng thái phiên kết nối hiện tại đang hoạt động.1. Giao thức này được sử dụng để thương lượng các thuộc tính bảo mật của một phiên.Alert Description types 2. nơi mà các thông điệp này được đóng gói trong một hoặc nhiều cấu trúc TLS Plaintext.3 Handshake Protocol TLS handshake protocol là một trong những máy trạm được định nghĩa ở mức độ cao hơn ( defined higher-level clients ) của TLS Record Protocol. TLS Handshake protocol bao gồm các bước sau: -Exchange hello message đồng ý trao đổi các thuật toán.

-Tạo ra một master secret key từ premaster secret key và trao đổi các giá trị ngẫu nhiên.-Trao đổi các thông số mật mã cần thiết để cho phép client và server thoả thuận premaster secret key. -Cho phép client và server xác minh rằng các máy trong cùng đường mạng tính toán được các thông số bảo mật và như thế quá trình bắt tay ( handshake ) xảy ra mà không có kẻ tấn công can thiệp vào. server_hello_done(14). client_hello(1). case certificate_verify: CertificateVerify. client_key_exchange(16). case certificate_request: CertificateRequest. certificate_request(13). struct { HandshakeType msg_type. } body. case server_hello: ServerHello. server_key_exchange (12). certificate_verify(15). (255) } HandshakeType. . server_hello(2). case server_hello_done: ServerHelloDone. case server_key_exchange: ServerKeyExchange. Cấu trúc của giao thức bắt tay: enum { hello_request(0). case finished: Finished. certificate(11). -Cung cấp các thông số bảo mật cho record layer. /* bytes in message */ select (HandshakeType) { case hello_request: HelloRequest. -Các chứng chỉ trao đổi ( exchange certificates ) và thông tin mật mã cho phép client và server tự chứng thực. case client_hello: ClientHello. /* handshake type */ uint24 length. finished(20). case certificate: Certificate. case client_key_exchange: ClientKeyExchange. } Handshake.

tr ủ g n struct { } HelloRequest.Khi một phiên mới bắt đầu. trạng thái kết nối của Record Layer sẽ mã hoá. tăng cường tính bảo mật giữa máy trạm và máy chủ . nó sẽ ngắt kết nối của client kèm theo một cảnh báo. ngh ủ g n : Hello Request là một thông báo yêu cầu client nên bắt đầu quá trình “trao đổi thông tin ” một lần nữa bằng cách gửi cho client một Hello Message khi thuận tiện. . Khi gói tin trao đổi được gửi đi nó sẽ được cấp độ ưu tiên cao hơn các ứng dụng thông thường. máy chủ không nên gửi lại các yêu cầu cho đến khi việc trao đổi thông tin đã hoàn tất.Sau khi gửi hello message . Nếu như server gửi đi Hello Request nhưng không nhận được phản hồi từ client.Trạng thái kết nối hiện tại được sử dụng cho những thông điệp thương lượng lại (renegotiation messages). hoặc là client sẽ trả lại một thông báo không chấp nhận tin nhắn.  Hello Request : có thể được gửi đi bởi máy chủ ở bất kì thời điểm nào. băm và các thuật toán nén được khởi tạo giá trị Null. nó sẽ thực hiện việc trao đổi với client khi không nhận được quá nhiều record từ client.Hello Message cũng có thể được client bỏ qua nếu nó không muốn thực hiện tác vụ này. Thông báo này sẽ được client bỏ qua nếu client đang thực hiện một tác vụ khác.Chi tiết các gói tin trong Handshake Protocol:  Hello Message: được sử dụng để trao đổi.

.Message này không được bao gồm trong những dữ liệu đã bị phân rã. au khi g i c ient he o meassage c ient s đ i để nh n server hello message. } ClientHello.2^16-1>. u v ng session id r ng thì phải ao g m t nh t cipher suite t session đ . +Cipher_suites : danh sách các tu ch n m hoá đ c h tr i client.  Client Hello : ngh ủa message này : Khi một client kết nối với máy chủ lần đầu tiên. SessionID session_id. u v ng session id r ng n phải ao g m các compression method t session đ .. t k thông điệp b t tay (handshake message) nào khác đ c trả về i máy chủ ngoài he o request đ c em à một i nghi m tr ng.. tr struct { ProtocolVersion client_version. Random random. CipherSuite cipher_suites<2.Client cũng có thể gửi một client hello để phản hồi hello request hoặc dùng một kiểu dữ liệu của chính bản thân mình để trao đổi các thông số bảo mật trong một kết nối đã tồn tại. +Session_id : ID của session mà c ient muốn d ng để thực hiện k t nối. CompressionMethod compression_methods<1. nó sẽ được yêu cầu gửi client hello message . +client_version : các phi n ản của giao thức mà c ient muốn d ng để giao ti p trong session này n n ài những phi n ản m i nh t. thứ mà được duy trì trong suốt quá trình trao đổi thông tin và dùng trong những message kết thúc cũng như chứng thực xác nhận tin nhắn ( certificate verify message). v i u ti n cho c ient đầu tiên .2^8-1>. +Compression_methods : à danh sách các ph ng thức n n h tr i c ient s p p theo y u cầu của c ient. ủ g n +Random : do c ient tạo ra một cách ngẫu nhiên. thông số này n n để trống n u không c session nào t n tại ho c n u c ient muốn tạo ra các thông số ảo m t m i.

session id không r ng (non-empty) thì server s t m trong bộ nh cache của phi n đ một mẫu tin trùng kh p. +compression_method : các ph ng thức n n đ c lựa ch n b i server t danh sách clienthello.  Server Certificate: server phải gửi một chứng thực (certificate) bất cứ khi nào các phương pháp trao đổi khoá được truyền đi không phải là từ một địa chỉ vô danh (anonymous) . ối v i session đ c kh i động ại v ng này mang giá tr t session đ đ c kh i động. CompressionMethod compression_method. Random random. u c ienthe o. C u trúc của message này: struct { ProtocolVersion server_version. . i server và phải đ c tạo ra độc pt +Session_id : à danh t nh của một phiên t ng ứng v i k t nối này. Nếu không thể tìm thấy cái nào trùng khớp. SessionID session_id. Message này sẽ luôn kèm theo server hello message. Server Hello: ngh ủa message này: server gửi cho client gói tin hello message khi có thể tìm thấy một tập hợp các thuật toán có thể chấp nhận được. ối v i các phiên kh i động lại (resumed session) th tr ờng này là giá tr của trạng thái b t đầu lại.cupher suites. u một mẫu tin trùng kh p đ c t m ra và máy chủ s n sàng thi t p k t nối m i ng cách s d ng các session quy đ nh th server s phản h i ại một giá tr t ng tự nh giá tr đ đ c cung c p i c ient. CipherSuite cipher_suite. } ServerHello. +Cipher_suite : ộ m hoá đ c ựa ch n i máy chủ t danh sách trong C ient e o. +Random : đ c tạo ra client hello random . nó sẽ phản hồi một cảnh bảo là quá trình bắt tay thất bại ( handshake failure alert) .compression_methods. +Server version : thông số này chứa những đề ngh th p h n của c ient trong c ient he o message và những h tr cao nh t t server.

struct { opaque rsa_modulus<1.2^16-1>. C u trúc của message này: enum { rsa. +rsa_exponent: b c luỹ th a của khoá tạm thời RSA. } ServerDHParams.2^16-1>. +dh p: các modu e ch nh đ Hellman. DHE_RSA... nếu từ anonymous negotiation). ngh ủa message này: các dạng certificate phải tương thích với các thuật toán trao đổi khoá của bộ mã hoá được lựa chọn. opaque rsa_exponent<1. Server key exchange message được gửi đi bởi server chỉ khi server certificate message không chứa đủ dữ liệu để cho phép client tiến hành trao đổi premaster secret key và đúng với các phương pháp trao đổi khoá như DHE_DSS. c s d ng trong thu t toán Diffie-  +dh_g: b t đầu việc dùng thu t toán Diffie-Hellman.Nó phải chứa một khoá phù hợp với phương thức trao đổi khoá . diffie_hellman } KeyExchangeAlgorithm. struct { select (KeyExchangeAlgorithm) { . DH_DSS. } ServerRSAParams. struct { opaque dh_p<1.2^16-1>. thuật toán chữ ký dùng cho việc chứng thực. DH_anon nhưng không hợp lệ với các phương pháp khác như RSA.  ngh ủa message này: message này truyền tải thông tin mật mã cho phép client giao tiếp với premaster secret. opaque dh_Ys<1.. cũng như khoá công cộng RSA để mã hoá premaster secret key hoặc khoá công cộng Diffie-Hellman mà client có thể hoàn tất việc trao đổi khoá.. opaque dh_g<1.2^16-1>. +dh_Ys: giá tr công cộng của thu t toán Diffie-Hellman (g^X mod p). DH_RSA.phải đồng bộ với thuật toán cho việc chứng thực khoá và khoá công cộng có thể có chiều dài bất kì.Trừ khi có quy định riêng..2^16-1>. +rsa_modulus: module khoá tạm thời RSA của máy chủ.  Server Key Exchange Message: message này được gửi đi ngay sau server certificate message (hoặc server hello message.

dsa } SignatureAlgorithm. với chữ ký (signature) phù hợp với hàm băm (hash) được áp dụng. }. }.random + ServerParams).random + ServerParams). Signature signed_params. +sha_hash : SHA (ClientHello. case rsa: ServerRSAParams params.case diffie_hellman: ServerDHParams params. opaque sha_hash[20]. }. Signature signed_params. struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params. case rsa: ServerRSAParams params. } ServerKeyExchange. }. +md5_hash: MD5 (ClientHello. +Signed_params: đối với việc trao đổi khoá non-anonymous .random + ServerHello. +Param: các thông số của server s key exchange. case dsa: digitally-signed struct { opaque sha_hash[20]. enum { anonymous. } Signature. }. rsa.random + ServerHello. case rsa: digitally-signed struct { opaque md5_hash[16]. }. .quá trình phân rã tương ứng với giá trị params. }Server Params. struct { select (SignatureAlgorithm) { case anonymous: struct { }.

o Giá trị từ 224 đến 225 được dùng cho mục đích sử dụng riêng. struct { ClientCertificateType certificate_types<1. . Certificate Request:  ngh ủa message này: Một non-anonymous server có thể yêu cầu một certificate từ client nếu nó phù hợp với bộ mã hoá được chọn.2^16-1>. +Certificate authorities: t p danh sách những tên phân biệt của trung tâm uỷ quyền chứng thực mà có thể ch p nh n đ c. +Certificate type: tr ờng dữ liệu này g m một danh sách các kiểu chứng thực đ c s p x p theo thứ tự u ti n của máy chủ. dss_sign(2). DistinguishedName certificate_authorities<0. dss_fixed_dh(4). } CertificateRequest. C u trúc của message này:  enum { rsa_sign(1). opaque DistinguishedName<1. o Giá trị nhận từ 64 đến 223 được lưu trữ cho phương thức nonStandards Track.2^8-1>.2^16-1>. dss_ephemeral_dh_RESERVED(6).. fortezza_dms_RESERVED(20).. rsa_ephemeral_dh_RESERVED(5). Nếu thông báo này được gửi thì ngay lập tức sẽ thực hiện theo Server Key Exchange Message.. có thể đ c d ng để chỉ đ nh root CA ho c CA c p d i của nó. (255) } ClientCertificateType. Giá trị của ClientCertificateType được chia làm 3 nhóm sau : o Giá trị từ 0 (zero) đến 63 lưu trữ cho giao thức IETF Standard Track . rsa_fixed_dh(3).

 Server Hello Done: Server hello done được gửi đi từ server để chỉ định việc kết thúc server hello và những tin nhắn liên quan. Sau khi tin nhắn được gửi đi, server sẽ chờ hồi đáp từ client.  ngh ủa message này: khi server hoàn tất việc gửi tin nhắn để hỗ trợ quá trình trao đổi khoá và sau đó client có thể tiến hành giai đoạn trao đổi khoá đó.Dựa vào server hello done message này, client nên xác nhận lại rằng server cung cấp một chứng nhận hợp lý nếu cần thiết và kiểm tra các thông số của server hello message để chấp nhận. C u trúc của message này: struct { } ServerHelloDone;

 Client Certificate: là thông điệp đầu tiên mà client có thể gửi sau khi nhận được server hello done message.Tin nhắn này chỉ được gửi nếu server yêu cầu chứng nhận.Nếu không có sẵn chứng nhận phù hợp có sẵn thì client nên gửi certificate message nội dung là không nhận được chứng nhận.  Client Key Exchange Message : thông điệp này luôn được gửi đi từ client. Nó phải lập tức gửi theo sau client certificate message nếu nó được gửi đi. Ngược lại, nó phải là thông điệp đầu tiên được gửi từ client sau khi nhận được server hello done message.  ngh ủa message này: với thông điệp này, khoá premaster secret được thiết lập mặc dù cả hai đều nhằm vào việc truyền dẫn trực tiếp của khoá mã hoá bí mật RSA bởi những thông số của thuật toán Diffie-Hellman, việc này sẽ cho phép mỗi bên thoả thuận cùng một premaster secret key. Nếu phương pháp trao đổi khoá là DH_RSA hoặc DH_DSS thì chứng nhận của client đã được yêu cầu và client có thể đáp ứng một chứng nhận chứa đựng khoá công khai Diffie-Hellman mà những thông số đó phải phù hợp với những quy định của server, thông điệp này không chứa bất kỳ dữ liệu nào.

C u trúc của message này: struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange;

RSA Encrypted Premaster Secret Message : ngh ủa message này: RSA được sử dụng như là khóa thoả thuận và chứng thực. Client sẽ tạo ra khoá premaster secret có chiều dài là 48 byte và mã hoá khoá này bằng khoá công khai từ server certificate hoặc khoá tạm thời RSA được cung cấp trong server key exchange message.Sau đó client se gửi kết quả đó bằng tin nhắn đã mã hoá premaster secret . C u trúc của message này: struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret; +Client version: phiên bản m i nh t h tr b i c ient đ c s d ng để phát hiện t n công roll-back.Khi nh n đ c premaster secret key, server nên kiểm tra giá tr này có phù h p hay không. +Random: 46 byte ngẫu nhi n đ struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; +Pre_master_secret: giá tr ngẫu nhi n đ c tạo ra b i client và đ c s d ng trong việc tạo ra khoá master_secret. c tạo ra đảm bảo tính an toàn.

Client Diffie-Hellman Public Value : ngh ủa message này: cấu trúc này truyền đạt giá trị công khai Diffie-Hellman của client (gọi tắt là Yc), nó không bao gồm các chứng nhận của client (Client Certificate).Yc được xác định bởi PublicValueEncoding, cấu trúc này là một biến thể của client key exchange message.

C u trúc của message này: enum { implicit, explicit } PublicValueEncoding; +Implicit: n u chứng nh n của c ient đ chứa khoá Diffie-Hellman phù h p thì Yc là implicit và không cần g i lại nữa. rong tr ờng h p này, client key exchange message s đ c g i nh ng phải mang giá tr r ng. +Explicit: Yc cần đ struct { select (PublicValueEncoding) { case implicit: struct { }; case explicit: opaque dh_Yc<1..2^16-1>; } dh_public; } ClientDiffieHellmanPublic; +dh_yc: The c ient s iffie-Hellman public value (Yc).  Certificate Verify : ngh ủa message này : được sử dụng để xác minh rõ ràng việc cung cấp chứng nhận cho client.Thông điệp này chỉ được gửi sau khi client message có hiệu lực.Khi gửi đi nó phải lập tức kèm theo client key exchange message. C u trúc của message này: struct { Signature signature; } CertificateVerify; CertificateVerify.signature.md5_hash MD5(handshake_messages); CertificateVerify.signature.sha_hash SHA(handshake_messages);  Finished Message : được gửi ngay sau change cipher spec message để xác minh rằng việc trao đổi khoá và quá trình chứng thực thành công.Change cipher spec message được nhận giữa các thông điệp bắt tay khác (other handshake message) và finished message. ngh ủa message này: được bảo vệ đầu tiên bằng các thuật toán được thoả thuận trước, khoá và khoá bí mật.Finished message của client phải xác minh rằng nội dung là chính xác. Một khi một bên đã gửi finished c g i.

message, nhận được và xác nhận từ client của nó thì có thể bắt đầu gửi và nhận dữ liệu thông qua kết nối đó. C u trúc của message này: struct { opaque verify_data[12]; } Finished; verify_data PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; +Finish Label: n u à đ c g i t client thì s thông áo à “c ient finish” n u đ c g i t server thì s thông báo à “server finish”. +Handshake_message: t t cả dữ liệu t các thông điệp trong giao thức b t tay này ( không bao g m hello request message ) không bao g m message này. Chỉ có dữ liệu đ c nhìn th y handshake layer và không bao g m header record layer. ây là m c xích của c u trúc b t tay ( handshake structure ) .

2.1.3.4

Application Data Protocol

Những thông điệp dữ liệu tầng ứng dụng được thực hiện bởi Record Layer và được phân đoạn ,nén mã hoá dựa trên trạng thái kết nối hiện hành. Các tin nhắn được xem như là dữ liệu trong suốt đối với Record Layer.

-Length: chiều dài của dữ liệu tầng ứng dụng -MAC: 20 bytes cho thuật toán SHA-1 dựa trên HMAC và 16 bytes cho thuật toán MD5. -Padding: chiều dài có thể thay đổi, byte cuối cùng chứa padding length.

.

1.1 DNS: 192.1. -Máy chủ dịch vụ : Web.100 IAS – Windows 2k3 RADIUS Server IP: 192.com Services Internet Protocol TCP/IP Domain Controller DNS Server DHCP Server Certification Authority IP: 192.255.200 SM: 255.Mô hình thực nghiệm : Mô hình sử dụng phần mềm giả lập máy ảo VMWare Workstation 7 gồm : -Máy Domain Controller (DC) : Windows Server 2003 SP2. Mail.Windows 2k3 Domain Name: hutech.0 GW: 192.1.168.168.1.255.168.100 SM: 255.255.250 SM: 255.100 CLT – Windows 7 Client DHCP Client .1.1.168.168. FTP… -Client : Windows 7.1 DNS: 192. Computer Name-Operating System DC .1.1.168. -Máy IAS Server : Windows Server 2003 SP2.168.0 GW: 192.1 DNS: 192.255.0 GW: 192.1.255.1.168.255.100 IIS – Windows 2k3 Web Server File Server IP: 192.CHƯƠNG III: THỰC NGHIỆM MINH HOẠ 3.168.

Thông số máy Domain Controller Thông số máy IAS (Internet Authentication Service) .

-Enable Certificate Template. -Cài Certificate Services. -Create Certificate Template for wireless users. File Server…)  Domain Controller: -Raise domain functional level.Thông số máy IIS Server ( Web. -Install Certificate Template Snap-in. -Verify Administrator permission for certificates. -Cài đặt và cấu hình DHCP. -Cấp quyền Allow Wireless for User and Computer. -Configure Certificate Template. .

-Tạo RADIUS Client. -Tạo và cấu hình Remote Access Policy. . -Kiểm tra kết nối. -Cấu hình Windows Firewall.  IIS Server: -Cài đặt Internet Information Service. -Xin Certificate cho Computer Account. . -Cấu hình Shared Folder. khai báo RADIUS Server. -Configure to use EAP-TLS authentication. tạo trang web default.  Client: -Cấu hình Wireless Network Connection. -Cấu hình Windows Firewall.  Wireless Access Point: -Cấu hình 802.1x. IAS Server: -Cài đặt và cấu hình Internet Authentication Service (IAS).Configure IAS to use EAP-TLS Authentication.

10 – 192.Range IP : 192.168.2. Các bước cài đặt chi tiết :  Domain Controller: Raise Domain Functional Level Tạo Scope cấp IP cho client.3.1.20 – SM : 24 .1.168.

com .Scope Options Properties hutech.

Tab Security chọn Group Administrator và cấp quyền như trên ở cột Allow Properties Client ( CLT ) .

chọn hutech.Cấp quyền Allow Access cho client Mở Active Directory Users and Computer.com  Users. click phải WirelessUser chọn Properties .

Đưa user WirelessUser và Client vào nhóm WirelessUsers Mở MMC .

click phải User chọn Duplicate Template .Add Certificate Template vào Console mới mở Trong Certificate Template.

Đặt tên cho Template Display Name: Wireless User Certificate Template Properties Wireless User Certificate Template .

Chọn Group Domain Users và check các quyền như trên Tab Subject Name bỏ dấu check dòng Include e-mail name in subject name .

Mở Certification authority Click phải Certificate Templates chọn New Certificate Template to Issue .

Chọn Wireless Users Certificate Template  OK .

com chọn Properties .Mở Active Directory Users and Computers Click phải domain hutech.

Chọn Default Domain Policy  Edit Computer ConfigurationWindows SettingsSecurity Settings . click phải Automatic Certificate Request Settings chọn NewAutomatic Certificate Request .

Chọn Next Chọn computerNext .

Chọn Finish Mở User ConfigurationWindows SettingsSecurity SettingsPublic Key Policy và double click Autoenrollment Settings .

Check vào các option như hình trên  IAS Server : Vào Add/Remove Windows Components chọn Networking Services  check vào Internet Authentication Service .

Mở Internet Authentication Service Click phải Internet Authentication Service chọn Register Server in Active DirectoryOKOK .

StartRun : mmc Menu File chọn Add/Remove Snap-in .

Chọn CertificatesAdd Chọn Computer accountNext .

Chọn Local computerFinish Chọn Close và OK .

Click phải Personal chọn All TasksRequest New Certificate Chọn Next .

Chọn ComputerNext Friendly name: IAS Server CertificateNext .

Chọn Finish Chọn OK .

Kiểm tra đã thấy certificate vừa cấp Mở Internet Authentication Service .

1.Click phải RADIUS Client chọn New RADIUS Client Friendly name: WirelessAP / Client address ( IP or DNS ) 192.168.254 ( địa chỉ AP ) Next .

Client-Vendor: RADIUS Standard / Shared secret và comfirm shared secret : 123456 Kiểm tra .

Click phải Remote Access Policy  New Remote Access Policy Chọn Next .

Policy name: Wireless Access to IntranetNext Chọn Wireless Next .

Chọn Group bấm Add Chọn Locations .

Chọn hutech.com Khai báo group : WirelessUsersCheck NamesOK .

Kiểm traNext Chọn NextFinish .

Double Click vào Wireless Access to Intranet Chọn Edit Profile .

Tab Authentication chọn EAP Methods Bấm Add .

Chọn Smart Card or other certificarteOK Chọn Smart Card or other certificateEdit .

Kiểm tra thấy IAS.hutech.com Chọn Smart Card or orther certificate Move up .

tab General chọn On Tab Exception chọn Add Port.Name : Radius Accouting / port: 1812 /UDP .Mở Control PanelWindows Firewall.

Name : Radius Authentication / Port : 1812 /UDP Kiểm tra .

Tab Advanced. chọn Settings ở mục Security Logging Check vào Log dropped packets và Log successful connections .

 IIS Server : -Cài Internet Information Service -Tạo trang web default có nội dung “ Welcome to hutech.com” -Kiểm tra truy cập thành công Tạo folder DATA và share Everyone quyền full control .

tab Exception check vào File and Printer Sharing.Vào Control PanelWindows Firewall chọn On.Sau đó chọn Add port và khai báo như hình trên. .

Tab Advanced chọn Settings ở mục Security Logging .

Check vào Log dropped packets và Log successful connectionsOK  Access Point : Khai báo thông số như trên .

 Client : Vào địa chỉ http://192.100 /certsrv để tiến hành xin certificate.168. Chọn Request a certificate .1.

Chọn advanced certificate request Chọn Create and summit a request to this CA .

Certificate Template chọn Wireless User Certificate Template CSP: Microsoft Enchanced Crytographic Provider v1.0 .

Install certificate thành công Cấp Certificate thành công cho user Trung .

.

Client đã được cấp IP thành công với thông số như hình trên 2.3.Kết quả giao thức : .

Sign up to vote on this title
UsefulNot useful