Embed Size (px)
Citation preview
BỘ GIÁO DỤC VÀ ĐÀO TẠOTRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP. HCM
ĐỀ TÀI BẢO MẬT THÔNG TIN
EXTENSIBLE AUTHENTICATION PROTOCOLTRANSPORT LAYER SECURITY
(EAP-TLS)
Khoa: Công Nghệ Thông TinChuyên ngành: Mạng Máy Tính
Giảng viên hướng dẫn: Th.S Văn Thiên HoàngNhóm Sinh viên thực hiện:
Mã Chí TrungMssv: 1191020168 Lớp: 11HTHM1Phạm Minh TrungMssv: 1191020164 Lớp: 11HTHM1Phạm Gia ĐôngMssv: 1191020017 Lớp: 11HTHM1Trịnh Hưng HưngMssv: 1191020039 Lớp: 11HTHM1Võ Thanh TâmMssv: 1191020120 Lớp: 11HTHM1Trịnh Đăng TuấnMssv: 1191020175 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:
Hình 2- Quá trình trao đổi thông tin xác thực của 802.1x
1.1.4 Phân loại EAP Packet
Type Description
1–6 Assigned by RFC
1 Identity
2 Notification
3 Nak (response only)
4 MD5-Challenge
5 One-Time Password (OTP)
6 Generic Token Card (GTC)
7 Not assigned
8 Not assigned
9 RSA Public Key Authentication
10 DSS Unilateral
11 KEA
12 KEA-VALIDATE
13 EAP-TLS
14 Defender Token (AXENT)
15 RSA Security SecurID EAP
16 Arcot Systems EAP
17 EAP-Cisco Wireless (LEAP)
18 Nokia IP SmartCard authentication
19 SRP-SHA1 Part 1
20 SRP-SHA1 Part 2
21 EAP-TTLS
22 Remote Access Service
23 UMTS Authentication and Key Agreement
24 EAP-3Com Wireless
25 PEAP
26 MS-EAP-Authentication
27 Mutual Authentication w/Key Exchange (MAKE)
28 CRYPTOCard
29 EAP-MSCHAP-V2
30 DynamID
31 Rob EAP
32 SecurID EAP
33 EAP-TLV
34 SentriNET
35 EAP-Actiontec Wireless
36 Cogent Systems Biometrics Authentication EAP
37 AirFortress EAP
38 EAP-HTTP Digest
39 SecureSuite EAP
40 DeviceConnect EAP
41 EAP-SPEKE
42 EAP-MOBAC
43 EAP-FAST
44-191 Not assigned; can be assigned by IANA on the advice of a designated expert
192–253 Reserved; requires standards action
254 Expanded types
255 Experimental usage
1.2 Mô hình kiến trúc và triển khai ứng dụng
802.1x EAP-TLS được sử dụng trong các mô trường cơ bản và an toàn cao. Sự trao đổi của các message EAP-TLS cung cấp sự xác nhận lẫn nhau, 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. Đ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. 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. 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. 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.
Hình 3-Xác nhận 802.1x EAP-TLS
802.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. Mạng nội bộ không dây (WLAN) giao tiếp với EAS thông qua Access Point (AP). Tất cả ba thành phần (Wireless client, AP và EAS) hỗ trợ cho quá trình chứng thực 802.1x EAP-TLS.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). Khi xác nhận, 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.
Hình 4- 802.1x EAP-TLS trong Controller Mode
CHƯƠNG II: GIAO THỨC EXTENSIBLE AUTHENTICATION PROTOCOL – TRANSPORT LAYER SECURITY
2.1 Giao thức EAP-TLS:2.1.1 Sơ đồ hoạt động của EAP-TLS (RFC 5216)
Đượ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.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 ), 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.Kể từ đó cuộc nói chuyện sẽ được bắt đầu giữa EAP-Server và client.
Một khi đã nhận được Identity của client, EAP-Server phải phản hồi cho client bằng gói tin EAP-TLS start, đó là một gói EAP-Request với EAP-type=EAP-TLS, cuộc trò chuyện bắt đầu, bên phía client sẽ gửi một gói tin EAP-Response, type=EAP-TLS.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, chứa thông điệp bắt tay ( TLS client_hello ).
Client_hello message bao gồm số phiên bản TLS của client ( peer’s TLS version number ), session ID, một con số phát sinh ngẫu nhiên và bộ mã hoá được hỗ trợ bởi client.Phiên bản TLS của client phải tương ứng với TLS v1.0 hoặc cao hơn.
EAP-Server sẽ trả lời lại với một gói tin EAP-Request với EAP-type=EAP-TLS, gói tin này bao gồm TLS server_hello handshake message, server_key_exchange, certificate_request,server_hello_done.Trong đó server_hello_handshake message gồm TLS version number , một con số phát sinh ngẫu nhiên khác ( another random number ), 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.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 đó , 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.
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 ).
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, change_cipher_spec và finished message.
Nếu EAP-Server gửi một certificate_request_message trong gói EAP-Request trước đó, trừ khi client được cấu hình riêng thì client phải gửi bổ sung certificate và certificate_verify_message.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.
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 ).
2.1.1.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.
1. Request.2. Response.3. Success.4. Failure.
Identifier: Identifier field chiếm 1 octet và giúp cho Response và Request trùng khớp với nhau.
Length: chiếm 2 octet , cho biết độ dài của gói tin.Mỗi octet của gói tin EAP bao gồm Code, Identifier , Length và Data fields.Những octet nào nằm ngoài giá trị của Length field sẽ bỏ qua.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ỏ.
Data: có thể là 0 hoặc chiếm nhiều octet.Định dạng của trường dữ liệu được xác định bởi Code Field.
2.1.1.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 ).
Indentifier : phải được thay đổi trên mỗi Request Packet.
Length : cho biết độ dài của gói tin EAP bao gồm Code, Identifier , Length , Type và Data Field.
Type : nhận giá trị=13 –EAP-TLS.
Flags :
L: Length included M: More fragments S: EAP-TLS start R: Reserved
-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.-Bit M : hiển thị tất cả ngoại trừ fragment cuối.-Bit S : được cài đặt làm EAP-TLS start message, khác biệt với fragment acknowledgment.-Bit R : bit dự trữ.
TLS Message Length : chiếm 4 octet , trường này chỉ hiện diện nếu bit L bật lên.Nó cung cấp tổng chiều dài của TLS Message hoặc bộ message đang được phân đoạn.
TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS Record.
2.1.1.3 EAP-TLS Response Packet : (RFC 5216)
Có cấu trúc tương tự EAP-TLS Request Packet.
Code : giá trị = 2 ( response packet ).
Identifier : chiếm 1 octet, phải trùng khớp với Identifier form request.
Length : chiếm 2 octet, cho biết độ dài của gói tin EAP bao gồm Code, Identifier, Length, Type và Data Field.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.
Type: nhận giá trị =13-EAP-TLS.
Flags :
L : Length included M: More fragments R: Reverved
-Bit L : chiếm 4 octet, 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.
-Bit M : gồm tất cả ngoại trừ fragment cuối.
-Bit R : bit dự trữ.
TLS Message Length : chiếm 4 octet, chỉ hiện diện nếu bit L bật lên.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.
TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS record.
2.1.1.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.
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, thì phải truyển một gói tin EAP bổ sung với Code = 4 ( failure ) .
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 đó.
2.1.2 Initial EAP Request / Respones Types (RFC-2284)
2.1.2.1 Identity
Được sử dụng để xác định danh tính của client.Nhà chứng thực sẽ cấp phát yêu cầu lúc ban đầu.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.Thông báo phản hồi phải được gửi cho bên Request với type = 1.
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). Bên phản hồi sử dụng trường này để trả lại Indentity.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 ). 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.
2.1.2.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.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.
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.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. Hầu hết trong các trường hợp, thông báo trên không được yêu cầu.
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.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.Các thông điệp không được mang giá trị kết thúc là rỗng ( NULL ).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 ).Trường dữ liệu ( data-type ) 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.1.2.3 Nak
Chỉ có giá trị trong các tin nhắn phản hồi ( response message ).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.Kiểu chứng thực được đánh số thứ tự là 4 và lớn hơn nữa.Bên Response chứa kiểu chứng thực mà client mong muốn.
Type: =3
Type-Data: phải chứ duy nhất 1 octet để chỉ rõ kiểu chứng thực mong muốn.
2.1.2.4 MD5-Challenge
Tương tự như giao thức PPP CHAP.Bên Request chứa 1 “challenge” message và gửi cho client, 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 ).Việc triển khai EAP phải hỗ trợ cơ chế chứng thực MD5-Challenge.
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.1.2.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.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 ).Nak reply cho biết kiểu cơ chế chứng thực mà client mong muốn.
Type: =5
Type-Data: OPT Challenge là một thông điệp hiển thị của bên Request.Bên hồi đáp, trường này được sử dụng cho “6 từ” trong “One-Time Password System” ( RFC-1938 ).Các thông điệp này không được kết thúc bằng giá trị rỗng ( NULL ).Độ dài của trường này nhận được từ chiều dài của gói tin Request/Response.
2.1.2.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.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.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.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.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).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, và chứa dữ liệu từ Token Card đòi hỏi việc xác thực.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.
2.1.3 TLS Protocol (RFC 4346)
TLS Protocol được chia làm hai lớp.Lớp đầu tiên là Handshake Protocol Layer bao gồm ba giao thức con: Handshake Protocol, Change Cipher Spec Protocol và Alert Protocol.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, phân mảnh nó cho phù hợp với kích thước của thuật toán mã hoá, á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.
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 :
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.
Peer Certificate : chứng chỉ X509v3 [X509] của client, trạng thái này có thể là Null.
Compression method : thuật toán dùng để nén dữ liệu trước khi mã hoá.
Cipher spec : chỉ định các thuật toán mã hoá dữ liệu số lượng lớn ( vd như Null , 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.
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.
2.1.3.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á.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.
Message này gồm 1 byte riêng lẻ có giá trị = 1
struct {enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
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á.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.
Sau khi gửi thông điệp này đi, 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.
Change Cipher Spec Protocol
2.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 ). 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. 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.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.Cũng giống như các tin nhắn khác, 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.
Alert Level Types
Alert Description types
2.1.3.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.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.
Thông điệp bắt tay được cung cấp cho TLS Record Layer, 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, 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.
TLS Handshake protocol bao gồm các bước sau:-Exchange hello message đồng ý trao đổi các thuật toán, trao đổi ngẫu nhiên các giá trị và kiểm tra phiên tiếp tục.-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.-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.-Tạo ra một master secret key từ premaster secret key và trao đổi các giá trị ngẫu nhiên.-Cung cấp các thông số bảo mật cho record layer.-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.
Cấu trúc của giao thức bắt tay:
enum {hello_request(0), client_hello(1), server_hello(2),certificate(11), server_key_exchange (12),certificate_request(13), server_hello_done(14),certificate_verify(15), client_key_exchange(16),finished(20), (255)
} HandshakeType;struct {
HandshakeType msg_type; /* handshake type */uint24 length; /* bytes in message */select (HandshakeType) {
case hello_request: HelloRequest;case client_hello: ClientHello;
case server_hello: ServerHello;case certificate: Certificate;case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;case server_hello_done: ServerHelloDone;case certificate_verify: CertificateVerify;case client_key_exchange: ClientKeyExchange;case finished: Finished;
} body;} Handshake;
Chi tiết các gói tin trong Handshake Protocol:
Hello Message: được sử dụng để trao đổi, tăng cường tính bảo mật giữa máy trạm và máy chủ .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á, băm và các thuật toán nén được khởi tạo giá trị Null.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).
Hello Request : có thể được gửi đi bởi máy chủ ở bất kì thời điểm nào.
Y nghia của message nay: 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. 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.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, hoặc là client sẽ trả lại một thông báo không chấp nhận tin nhắ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, 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. Nếu như server gửi đi Hello Request nhưng không nhận được phản hồi từ client, nó sẽ ngắt kết nối của client kèm theo một cảnh báo.Sau khi gửi hello message , 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.
Câu truc của message nay :
struct { } HelloRequest;
Message này không được bao gồm trong những dữ liệu đã bị phân rã, 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).
Client Hello :
Y nghia của message nay : Khi một client kết nối với máy chủ lần đầu tiên, nó sẽ được yêu cầu gửi client hello message .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.
Câu truc của message nay :
struct {ProtocolVersion client_version;Random random;SessionID session_id;CipherSuite cipher_suites<2..2^16-1>;CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
+client_version : các phiên bản của giao thức TLS mà client muốn dung để giao tiêp trong session này, nên xài những phiên bản mơi nhât.
+Random : do client tạo ra một cách ngẫu nhiên.
+Session_id : ID của session mà client muốn dung để thực hiện kêt nối. thông số này nên để trống nêu không co session_ID nào tôn tại hoăc nêu client muốn tạo ra các thông số bảo mât mơi.
+Cipher_suites : danh sách các tuy chon ma hoá đươc hô trơ bơi client, vơi ưu tiên cho client đầu tiên .Nêu vung session_id rông thì phải bao gôm it nhât cipher_suite tư session đo.
+Compression_methods : là danh sách các phương thức nen hô trơ bơi client, săp xêp theo yêu cầu của client. Nêu vung session_id rông, no phải bao gôm các compression_method tư session đo. Sau khi gưi client hello meassage, client se đơi để nhân server hello message. Bât kì thông điệp băt tay (handshake message) nào khác đươc trả về bơi máy chủ ngoài hello request đươc xem là một lôi nghiêm trong.
Server Hello:
Y nghia của message nay: 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. Nếu không thể tìm thấy cái nào trùng khớp, 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) .Câu truc của message nay:
struct {ProtocolVersion server_version;Random random;SessionID session_id;CipherSuite cipher_suite;CompressionMethod compression_method;
} ServerHello;
+Server version : thông số này chứa những đề nghi thâp hơn của client trong client hello message và những hô trơ cao nhât tư server.
+Random : đươc tạo ra bơi server và phải đươc tạo ra độc lâp tư client hello random .
+Session_id : là danh tinh của một phiên tương ứng vơi kêt nối này. Nêu clienthello.session_id không rông (non-empty) thì server se tìm trong bộ nhơ cache của phiên đo một mẫu tin trung khơp. Nêu một mẫu tin trung khơp đươc tìm ra và máy chủ săn sàng thiêt lâp kêt nối mơi băng cách sư dung các session quy đinh thì server se phản hôi lại một giá tri tương tự như giá tri đa đươc cung câp bơi client.
+Cipher_suite : bộ ma hoá đươc lựa chon bơi máy chủ tư danh sách trong ClientHello.cupher_suites. Đối vơi session đươc khơi động lại, vung này mang giá tri tư session đa đươc khơi động.
+compression_method : các phương thức nen đươc lựa chon bơi server tư danh sách clienthello.compression_methods.Đối vơi các phiên khơi động lại (resumed session) thì trường này là giá tri của trạng thái băt đầu lại.
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) . Message này sẽ luôn kèm theo server hello message.
Y nghia của message nay: 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.Nó phải chứa một khoá phù hợp với phương thức trao đổi khoá .Trừ khi có quy định riêng, thuật toán chữ ký dùng cho việc chứng thực.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ì.
Server Key Exchange Message: message này được gửi đi ngay sau server certificate message (hoặc server hello message, nếu từ anonymous negotiation). 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, DHE_RSA, DH_anon nhưng không hợp lệ với các phương pháp khác như RSA, DH_DSS, DH_RSA.
Y nghia của message nay : message này truyền tải thông tin mật mã cho phép client giao tiếp với premaster secret, 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á.
Câu truc của message nay:
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct {opaque rsa_modulus<1..2^16-1>;opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
+rsa_modulus: module khoá tạm thời RSA của máy chủ.
+rsa_exponent: bâc luỹ thưa của khoá tạm thời RSA.
struct {opaque dh_p<1..2^16-1>;opaque dh_g<1..2^16-1>;opaque dh_Ys<1..2^16-1>;
} ServerDHParams;
+dh_p: các module chinh đươc sư dung trong thuât toán Diffie-Hellman.
+dh_g: băt đầu việc dung thuât toán Diffie-Hellman.
+dh_Ys: giá tri công cộng của thuât toán Diffie-Hellman (g^X mod p).
struct {select (KeyExchangeAlgorithm) {
case diffie_hellman:ServerDHParams params;Signature signed_params;
case rsa:ServerRSAParams params;Signature signed_params;
};} ServerKeyExchange;
struct {select (KeyExchangeAlgorithm) {
case diffie_hellman:ServerDHParams params;
case rsa:ServerRSAParams params;
}; }Server Params;
+Param: các thông số của server’s key exchange.
+Signed_params: đối với việc trao đổi khoá non-anonymous ,quá trình phân rã tương ứng với giá trị params, với chữ ký (signature) phù hợp với hàm băm (hash) được áp dụng. +md5_hash: MD5 (ClientHello.random + ServerHello.random + ServerParams).
+sha_hash : SHA (ClientHello.random + ServerHello.random + ServerParams).
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:digitally-signed struct {
opaque md5_hash[16];opaque sha_hash[20];
};case dsa:
digitally-signed struct {opaque sha_hash[20];
};};
};} Signature;
Certificate Request:
Y nghia của message nay: 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.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âu truc của message nay:
enum {rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),fortezza_dms_RESERVED(20),(255)
} ClientCertificateType;opaque DistinguishedName<1..2^16-1>;
struct {ClientCertificateType certificate_types<1..2^8-1>;DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
+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ủ.
+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à co thể châp nhân đươc, co thể đươc dung để chỉ đinh root CA hoăc CA câp dươi của no.
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 .
o Giá trị nhận từ 64 đến 223 được lưu trữ cho phương thức non-Standards Track.
o Giá trị từ 224 đến 225 được dùng cho mục đích sử dụng riêng.
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.
Y nghia của message nay: 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 truc của message nay:
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.
Y nghia của message nay: 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 truc của message nay:
struct {select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;} ClientKeyExchange;
RSA Encrypted Premaster Secret Message :
Y nghia của message nay: 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 truc của message nay:
struct {ProtocolVersion client_version;opaque random[46];
} PreMasterSecret;
+Client version: phiên bản mơi nhât hô trơ bơi client, đươc sư dung để phát hiện tân công roll-back.Khi nhân đươc premaster secret key, server nên kiểm tra giá tri này co phu hơp hay không.
+Random: 46 byte ngẫu nhiên đươc tạo ra đảm bảo tinh an toàn.
struct {public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
+Pre_master_secret: giá tri ngẫu nhiên đươc tạo ra bơi client và đươc sư dung trong việc tạo ra khoá master_secret.
Client Diffie-Hellman Public Value :
Y nghia của message nay: 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 truc của message nay:
enum { implicit, explicit } PublicValueEncoding;
+Implicit: nêu chứng nhân của client đa chứa khoá Diffie-Hellman phu hơp thì Yc là implicit và không cần gưi lại nữa.Trong trường hơp này, client key exchange message se đươc gưi nhưng phải mang giá tri rông.
+Explicit: Yc cần đươc gưi.
struct {select (PublicValueEncoding) {
case implicit: struct { };case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;} ClientDiffieHellmanPublic;
+dh_yc: The client’s Diffie-Hellman public value (Yc).
Certificate Verify :
Y nghia của message nay : đượ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 truc của message nay:
struct {Signature signature;
} CertificateVerify;
CertificateVerify.signature.md5_hashMD5(handshake_messages);
CertificateVerify.signature.sha_hashSHA(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.
Y nghia của message nay: đượ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 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 truc của message nay:
struct {opaque verify_data[12];
} Finished;
verify_dataPRF(master_secret, finished_label, MD5(handshake_messages) +SHA-1(handshake_messages)) [0..11];
+Finish Label: nêu là đươc gưi tư client thì se thông báo là “client finish”, nêu đươc gưi tư server thì se thông báo là “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ỉ co dữ liệu đươc nhìn thây ơ handshake layer và không bao gôm header record layer.Đây là măc xich 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.
CHƯƠNG III: THỰC NGHIỆM MINH HOẠ
3.1.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.
-Máy IAS Server : Windows Server 2003 SP2.
-Máy chủ dịch vụ : Web, Mail, FTP…
-Client : Windows 7.
Computer Name-Operating System
Services Internet Protocol TCP/IP
DC - Windows 2k3
Domain Name: hutech.com
Domain Controller
DNS Server
DHCP Server
Certification Authority
IP: 192.168.1.100
SM: 255.255.255.0
GW: 192.168.1.1
DNS: 192.168.1.100
IAS – Windows 2k3 RADIUS Server IP: 192.168.1.200
SM: 255.255.255.0
GW: 192.168.1.1
DNS: 192.168.1.100
IIS – Windows 2k3 Web Server
File Server
IP: 192.168.1.250
SM: 255.255.255.0
GW: 192.168.1.1
DNS: 192.168.1.100
CLT – Windows 7 Client DHCP Client
Thông số máy Domain Controller
Thông số máy IAS (Internet Authentication Service)
Thông số máy IIS Server ( Web, File Server…)
Domain Controller:
-Raise domain functional level.
-Cài đặt và cấu hình DHCP.
-Cài Certificate Services.
-Verify Administrator permission for certificates.
-Cấp quyền Allow Wireless for User and Computer.
-Install Certificate Template Snap-in.
-Create Certificate Template for wireless users.
-Configure Certificate Template.
-Enable Certificate Template.
IAS Server:
-Cài đặt và cấu hình Internet Authentication Service (IAS).
-Xin Certificate cho Computer Account.
-Tạo RADIUS Client.
-Tạo và cấu hình Remote Access Policy.
- Configure IAS to use EAP-TLS Authentication.
-Cấu hình Windows Firewall.
IIS Server:
-Cài đặt Internet Information Service, tạo trang web default.
-Cấu hình Shared Folder.
-Cấu hình Windows Firewall.
Wireless Access Point:
-Cấu hình 802.1x, khai báo RADIUS Server.
Client:
-Cấu hình Wireless Network Connection.
-Configure to use EAP-TLS authentication.
-Kiểm tra kết nối.
3.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- Range IP : 192.168.1.10 – 192.168.1.20 – SM : 24
Scope Options
Properties hutech.com
Tab Security chọn Group Administrator và cấp quyền như trên ở cột Allow
Properties Client ( CLT )
Cấp quyền Allow Access cho client
Mở Active Directory Users and Computer, chọn hutech.com Users, click phải WirelessUser chọn Properties
Đưa user WirelessUser và Client vào nhóm WirelessUsers
Mở MMC
Add Certificate Template vào Console mới mở
Trong Certificate Template, click phải User chọn Duplicate 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
Mở Active Directory Users and Computers
Click phải domain hutech.com chọn Properties
Chọn Default Domain Policy Edit
Computer ConfigurationWindows SettingsSecurity Settings , click phải Automatic Certificate Request Settings chọn NewAutomatic Certificate Request
Chọn Next
Chọn computerNext
Chọn Finish
Mở User ConfigurationWindows SettingsSecurity SettingsPublic 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 DirectoryOKOK
StartRun : mmc
Menu File chọn Add/Remove Snap-in
Chọn CertificatesAdd
Chọn Computer accountNext
Chọn Local computerFinish
Chọn Close và OK
Click phải Personal chọn All TasksRequest New Certificate
Chọn Next
Chọn ComputerNext
Friendly name: IAS Server CertificateNext
Chọn Finish
Chọn OK
Kiểm tra đã thấy certificate vừa cấp
Mở Internet Authentication Service
Click phải RADIUS Client chọn New RADIUS Client
Friendly name: WirelessAP / Client address ( IP or DNS ) 192.168.1.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 IntranetNext
Chọn Wireless Next
Chọn Group bấm Add
Chọn Locations
Chọn hutech.com
Khai báo group : WirelessUsersCheck NamesOK
Kiểm traNext
Chọn NextFinish
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 certificarteOK
Chọn Smart Card or other certificateEdit
Kiểm tra thấy IAS.hutech.com
Chọn Smart Card or orther certificate Move up
Mở Control PanelWindows Firewall, tab General chọn On
Tab Exception chọn Add Port.Name : Radius Accouting / port: 1812 /UDP
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
Vào Control PanelWindows Firewall chọn On, tab Exception check vào File and Printer Sharing.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 connectionsOK
Access Point :
Khai báo thông số như trên
Client :
Vào địa chỉ http://192.168.1.100 /certsrv để tiến hành xin certificate.
Chọn Request a certificate
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 :
