Giao thức tiêu đề xác thực AH được định nghĩa trong RFC 1826 và sau đó phát triển lại trong REC 2402. AH cung cấp khả năng xác thực nguồn gốc dữ liệu (Data Origin Authentication), kiểm tra tính toàn vẹn dữ liệu (Data Integrity) và dịch vụ chống phát lại (Anti-replay Service). Đến đây, cần làm rõ hơn hai khái niệm toàn vẹn dữ liệu và chống phát lại. Toàn vẹn dữ liệu là kiểm tra những thay đổi của từng gói tin IP, không quan tâm đến vị trí các gói tin trong luồng lưu lượng. Còn dịch vụ chống phát lại là kiểm tra sự phát lặp lại một gói tin tới địa chỉ đích nhiều hơn một lần.
AH cho phép xác thực các trường của tiêu đề IP cũng như dữ liệu của các giao thức lớp trên. Tuy nhiên, do một số trường của tiêu đề IP thay đổi trong khi truyền và phía phát không dự đoán trước được giá trị của chúng khi tới phía thu, giá trị của các trường này không bảo vệ được bằng AH. Có thể nói AH chỉ bảo vệ một phần của tiêu đề IP mà thôi. AH không cung cấp bất cứ xử lý nào để bảo mật dữ liệu của các lớp trên, tất cả đều được truyền dưới dạng văn bản rõ. AH nhanh hơn ESP, nên có thể chọn AH trong trường hợp cần yêu cầu chắc chắn về nguồn gốc và tính toàn vẹn của dữ liệu, còn tính bảo mật dữ liệu thì không yêu cầu cao.
Giao thức AH cung cấp chức năng xác thực bằng cách thực hiện một hàm băm một chiều (One-way Hash Funtion) đối với dữ liệu của gói để tạo ra một đoạn mã xác thực (Hash hay Message Digest). Đoạn mã này được chèn vào
trong quá trình truyền đi đều được phía thu phát hiện khi nó thực hiện cùng một hàm băm một chiều đối với gói dữ liệu nhận được và đối với giá trị mã xác thực truyền cùng với gói dữ liệu. Hàm băm được thực hiện trên toàn bộ gói dữ liệu, trừ một số trường trong tiêu đề IP có giá trị thay đổi trong quá trình truyền.
3.2.2.2 AH Mode
AH có hai mode: Transport và Tunnel.
- Tunnel mode, AH tạo 1 IP Header mới cho mỗi gói tin.
- Transport mode, AH không tạo IP Header mới.
Trong cấu trúc IPSec mà sử dụng gateway, địa chỉ thật của IP nguồn và đích của các gói tin phải thay đổi thành địa chỉ IP của gateway. Vì trong Transport Mode không thay đổi IP Header nguồn hoặc tạo một IP Header mới, Transport Mode thường sử dụng trong cấu trúc host-to-host.
AH cung cấp tính năng đảm bảo tính toàn vẹn cho toàn bộ gói tin, bất kỳ mode nào được sử dụng .
Hình 3-4: AH Tunnel Mode Packet
Hình 3-5: AH Transport Mode Packet
Hoạt động của giao thức AH
Hướng tốt nhất để hiểu AH làm việc như thế nào, ta sẽ xem và phân tích các gói tin AH.
Hình 3-7: Sample AH Transport Mode Packet.
Hình trên cho thấy các thành phần của gói tin AH thật sự. Mỗi section của AH Packet gồm : Ethernet header , IP header , AH header và Payload. Dựa trên các trường của phần AH mode, ta thấy đây là gói tin ở Transport Mode vì nó chỉ chứa IP Header. Trong trường hợp này, payload chứa ICMP echo request (hay là Ping). Ping gốc chứa chuỗi mẫu tự được miêu tả trong gói tin tăng dần bởi giá trị Hex ( vd : 61, 62, 63). Sau khi giao thức AH được applied, ICMP Payload không thay đổi. Vì AH chỉ cung cấp dịch vụ đảm bảo toàn vẹn dữ liệu, không mã hoá.
Hình 3.8: AH Header Fields from Sample Packet.
Các trường trong AH Header từ 4 gói tin đầu tiên trong AH session giữa host A và host B. Các trường trong header đầu tiên chỉ là nhãn, để đáp ứng trong việc nhận dạng AH mode.
3.2.3 Giao thức đóng gói tải tin an toàn ESP
ESP là giao thức bảo mật chính thứ hai. Trong phiên bản đầu của IPSec , ESP chỉ cung cấp mã hoá cho packet payload data. Khi cần, giao thức AH cung cấp dịch vụ đảm bảo toàn vẹn. Trong phiên bản thứ hai của IPSec, ESP trở nên mềm dẻo hơn. Nó có thể thực hiện xác thực để cung cấp dịch vụ đảm bảo toàn vẹn, mặc dù không hỗ trợ cho outermost IP header. Sự mã hoá của ESP có thể bị vô hiệu hoá qua thuật toán mã hoá Null ESP algorithm. Do đó, ESP có thể cung
cấp chỉ mã hoá; mã hoá và đảm bảo toàn vẹn dữ liệu; hoặc chỉ đảm bảo toàn vẹn dữ liệu.
ESP Mode
ESP có hai mode : Transport Mode và Tunnel Mode.
Trong Tunnel Mode : ESP tạo một IP Header mới cho mỗi gói tin. IP Header mới liệt kêt các đầu cuối của ESP Tunnel ( như hai IPSec gateway) nguồn và đích của gói tin. Vì Tunnel mode có thể dùng với tất cả 3 mô hình cấu trúc VPN.
Hình 3.9: ESP Tunnel Mode Packet
ESP Tunnel Mode được sử dụng thường xuyên nhanh hơn ESP Transport Mode.
Trong Tunnel Mode, ESP dùng IP header gốc thay vì tạo một IP header mới. Trong Transport Mode, ESP có thể chỉ mã hoá và/hoặc bảo đảm tính toàn vẹn nội dung gói tin và một số các thành phần ESP, nhưng không có với IP header. Giao thức AH, ESP trong Transport mode thường sử dụng trong cấu trúc host- to-host. Trong Transport mode không tương thích với NAT.
Hình 3.10: ESP Transport Mode Packet
Hình 3.12 Quá trình mã hóa ESP
ESP sử dụng mật mã đối xứng để cung cấp sự mật hoá dữ liệu cho các gói tin IPSec. Cho nên, để kết nối của cả hai đầu cuối đều được bảo vệ bởi mã hoá ESP thì hai bên phải sử dụng key giống nhau mới mã hoá và giải mã được gói tin .
Khi một đầu cuối mã hoá dữ liệu, nó sẽ chia dữ liệu thành các block nhỏ, và sau đó thực hiện thao tác mã hoá nhiều lần sử dụng các block dữ liệu và key. Thuật toán mã hoá hoạt động trong chiều này được xem như blocks cipher
algorithms.
Khi một đầu cuối khác nhận được dữ liệu mã hoá, nó thực hiện giải mã sử dụng key giống nhau và quá trình thực hiện tương tự, nhưng trong bước này ngược với thao tác mã hoá.
Khi so sánh với gói tin AH , gói tin ESP có dạng giống với gói tin AH. chuỗi mẫu tự có thể xác định được trong AH-protected Payload nhưng không xác định được trong ESP-protected payload, vì trong ESP nó đã được mã hoá.
Gói tin ESP có chứa 5 đoạn : Ethernet Header , IP Header, ESP Header, Encrypted Data (Payload và ESP Trailer), và (option) authentication information . Dữ liệu được mã hoá không thể xác định được dù gói tin truyền trong Transport Mode hay Tunnel Mode. Tuy nhiên, vì IP Header không được mã hoá, trường giao thức IP trong Header vẫn phát hiện được giao thức dùng cho Payload ( trong trường hợp này là ESP).
Hình trên cho thấy, các trường ESP Header từ 4 gói tin đầu trong ESP session giữa host A và host B . Các trường SPI và Sequence Number trong ESP làm việc một chiều như chúng đã thực hiện trong AH . Mỗi host sử dụng một giá trị SPI khác nhau cho các gói tin của nó, tương thích với kết nối ESP gồm hai thành phần kết nối một chiều. Cả hai host cũng bắt đầu thiết lập sequence number là 1, và sẽ tăng dần lên là 2 cho gói tin thứ hai.
Bảng so sánh giữa giao thức AH và ESP
3.3 Kết hợp an ninh và hoạt động trao đổi khóa
3.3.1 Kết hợp an ninh
IPSec cung cấp nhiều lựa chọn để thực hiện các giải pháp mật mã và xác thực ở lớp mạng. Phần này sẽ định nghĩa các thủ tục quản lý SA cho cả IPv4 và IPv6 để thực thi AH hoặc ESP hoặc cả hai, phụ thuộc vào lựa chọn của người sử dụng. Khi thiết lập kết nối IPSec, hai phía phải xác định chính xác các thuật toán nào sẽ được sử dụng, loại dịch vụ nào cần đảm bảo an toàn. Sau đó bắt đầu xử lý thương lượng để chọn một tập các tham số và các giải thuật toán học áp dụng cho mã hóa bảo mật hay nhận thực. Theo IETF thì dịch vụ bảo mật quan hệ giữa hai hoặc nhiều thực thể để thỏa thuận truyền thông an toàn được gọi là SA (Security Association).
Một SA là một kết nối đơn công, nghĩa là với mỗi cặp truyền thông với nhau, có ít nhất 2 SA (một từ A tới B và một từ B tới A). Khi lưu lượng cần truyền trực tiếp 2 chiều qua VPN, giao thức trao đổi khóa IKE (Internet Key Exchange) thiết lập một cặp SA trực tiếp và sau đó có thể thiết lập thêm nhiều SA khác. Mỗi SA có một thời gian sống riêng. SA được nhận dạng duy nhất bởi bộ 3 gồm có: chỉ dẫn thông số an ninh (SPI), địa chỉ IP đích và một nhận dạng giao thức an toàn (AH hay ESP). Tập các giá trị SPI trong dãy từ 1 đến 255 được để dành bởi IANA để sử dụng cho tương lai. Theo nguyên lý, địa chỉ IP đích có thể là một địa chỉ đơn nhất (unicast), một địa chỉ quảng bá (broadcast) hay một địa chỉ nhóm (multicast). Tuy nhiên, cơ chế quản lý SA IPSec hiện nay được định nghĩa chỉ cho những SA đơn nhất (unicast).
Một lên kết an ninh có thể là một trong hai kiểu: Transport và Tunnel, phụ thuộc vào kiểu của giao thức sử dụng SA. Một SA kiểu Transport là một liên kết an toàn giữa hai host, hoặc liên kết an toàn được yêu cầu giữa hai hệ thống trung gian dọc trên đường truyền. Trong trường hợp khác, kiểu Transport cũng có thể được sử dụng để hỗ trợ IP-in-IP hay đường ngầm GRE qua các SA kiểu Transport. SA kiểu Tunnel là một SA cơ bản được ứng dụng tới một đường ngầm IP. Một SA giữa 2 cổng an toàn là một SA kiểu Tunnel điển hình giống như một SA giữa một host và một cổng an toàn. Tuy nhiên, trong những trường hợp mà lưu lượng đã được định hình từ trước như những
lệnh SNMP, cổng an toàn làm nhiệm vụ như host và kiểu Transport được cho phép.
SA cung cấp nhiều lựa chọn cho các dịch vụ IPSec, nó phụ thuộc vào giao thức an toàn được lựa chọn (AH hay ESP), kiểu SA, điểm kết thúc của SA đó và một sự tuyển chọn của các dịch vụ tùy ý các bên trong giao thức đó. Ví dụ như khi sử dụng AH để xác minh nguồn gốc dữ liệu, tính toàn vẹn phi kết nối cho gói IP, có thể sử dụng dịch vụ chống phát lại hoặc không tùy thuộc vào các bên.
Khi một bên IP-VPN muốn gửi lưu lượng IPSec tới đầu bên kia, nó kiểm tra để biết nếu có một đã tồn tại một SA trong cơ sở dữ liệu hay chưa để hai bên có thể sử dụng dịch vụ an ninh theo yêu cầu. Nếu nó tìm được một SA tồn tại, nó để SPI của SA này trong tiêu đề IPSec, thực hiện các thuật toán mã hóa và gửi gói tin đi. Bên thu sẽ lấy SPI, địa chỉ đích và giao thức IPSec (AH hay ESP) và tìm SA trong cơ sở dữ liệu phù hợp để xử lý gói tin đó. Lưu ý rằng một đầu cuối IP-VPN có thể đồng thời tồn tại nhiều kết nối IPSec, vì vậy cũng có nghĩa là tồn tại nhiều SA.
3.3.1.2 Kết hợp các SA
Các gói IP truyền qua một SA riêng biệt được cung cấp sự bảo vệ một cách chính xác bởi giao thức an ninh có thể là AH hoặc ESP nhưng không phải là cả hai. Đôi khi một chính sách an toàn có thể được gọi cho một sự kết hợp của các dịch vụ cho một luồng giao thông đặc biệt mà không thể thực hiện được với một SA đơn lẻ. Trong trường hợp đó cần thiết để giao cho nhiều SA thực hiện chính sách an toàn được yêu cầu. Thuật ngữ cụm SA được sử dụng để một chuỗi các SA xuyên qua lưu lượng cần được xử lý để thỏa mãn một tập chính sách an toàn.
Đối với kiểu Tunnel, có 3 trường hợp cơ bản của kết hợp an ninh như sau:
1) Cả hai điểm cuối SA đều trùng nhau: mỗi đường ngầm bên trong hay bên ngoài là AH hay ESP, mặc dù host 1 có thể định rõ cả hai đường ngầm là như nhau, tức là AH bên trong AH và ESP bên trong ESP.
Hình 3.15: Kết hợp SA kiểu Tunnel khi 2 điểm cuối trùng nhau 2) Một điểm cuối SA trùng nhau: đường hầm bên trong hay bên ngoài có thể là AH hay ESP.
Hình 3.16: Kết hợp SA kiểu Tunnel khi một điểm cuối trùng nhau 3) Không có điểm cuối nào trùng nhau: Mỗi đường hầm bên trong và bên ngoài là AH hay ESP.
Hình 3.17: Kết hợp SA kiểu Tunnel khi không có điểm cuối trùng nhau Chi tiết về kết hợp các SA có được trình bày trong RFC 2401.Host 1
Host 1 Security Gwy 1 Security
Gwy 1 SecurityGwy 2
Security
Gwy 2 Host 2Host 2 Interne
t
SA 1 (Tunnel)
Security Association 2 (Tunnel) Host 1
Host 1 Security Gwy 1 Security
Gwy 1 SecurityGwy 2
Security
Gwy 2 Host 2Host 2 Interne
t Security Association 1
(Tunnel)
Security Association 2 (Tunnel) Host 1
Host 1 Security Gwy 1 Security
Gwy 1 Interne SecurityGwy 2SecurityGwy 2 Host 2Host 2 t
Security Association 1 (Tunnel) Security Association 2 (Tunnel)
3.3.1.3 Cơ sở dữ liệu SA
Có hai cơ sở dữ liệu, đó là: Cơ sở dữ liệu chính sách an ninh (Security Policy Database SPD) và có sở dữ liệu kết hợp an ninh (Security Association Database SAD).
SPD: chỉ ra các dịch vụ an toàn được đề nghị cho lưu lượng IP, phụ thuộc vào các nhân tố như nguồn, đích, đi ra hay đi về. Nó chứa đựng một danh sách những lối vào chính sách, tồn tại riêng rẽ cho lưu lượng đi vào và đi ra. Các lối vào này có thể nhận định một vài lưu lượng không qua xử lý IPSec, một vài phải được loại bỏ và còn lại thì được xử lý bởi IPSec. Các lối vào này là tương tự cho firewall hay bộ lọc gói.
SAD: chứa thông số về mỗi SA, giống như các tính toán và khóa AH hay ESP, số trình tự, kiểu giao thức và thời gian sống SA. Cho xử lý đi ra, một lối vào SPD trỏ tới một lối vào trong SAD. SAD quyết định SA nào được sử dụng cho một gói đã cho. Cho xử lý đi về, SAD được tham khảo để quyết định gói được xử lý như thế nào.
3.3.2 Hoạt động trao đổi khóa
Về cơ bản được biết như ISAKMP/Oakley, ISAKMP là chữ viết tắc của Internet Security Association and Key Management Protocol, IKE giúp các bên giao tiếp hòa hợp các tham số bảo mật và khóa xác nhận trước khi một phiên bảo mật IPSec được triển khai. Ngoài việc hòa hợp và thiết lập các tham số bảo mật và khóa mã hóa, IKE cũng sữa đổi những tham số khi cần thiết trong suốt phiên làm việc. IKE cũng đảm nhiệm việc xoá bỏ những SAs và các khóa sau khi một phiên giao dịch hoàn thành. Thuận lợi chính của IKE include bao gồm:
• IKE không phải là một công nghệ độc lập, do đó nó có thể dùng với bất kỳ cơ chế bảo mật nào.
• Cơ chế IKE, mặc dù không nhanh, nhưng hiệu quả cao bở vì một lượng
lớn những hiệp hội bảo mật thỏa thuận với nhau với một vài thông điệp khá ít.
3.3.2.1 IKE Phases
Giai đoạn I và II là hai giai đoạn tạo nên phiên làm việc dựa trên IKE, hình 6-14 trình bày một số đặc điểm chung của hai giai đoạn. Trong một phiên
làm việc IKE, nó giả sử đã có một kênh bảo mật được thiết lập sẵn. Kênh bảo mật này phải được thiết lập trước khi có bất kỳ thỏa thuận nào xảy ra.
3.3.2.1.1 Giai đoạn I của IKE
Giai đoạn I của IKE đầu tiên xác nhận các điểm thông tin, và sau đó thiết lập một kênh bảo mật cho sự thiết lập SA. Tiếp đó, các bên thông tin thỏa thuận một ISAKMP SA đồng ý lẫn nhau, bao gồm các thuật toán mã hóa, hàm băm, và các phương pháp xác nhận bảo vệ mã khóa.
Sau khi cơ chế mã hóa và hàm băm đã được đồng ý ở trên, một khóa chi sẽ bí mật được phát sinh. Theo sau là những thông tin được dùng để phát sinh khóa bí mật :
Giá trị Diffie-Hellman
• SPI của ISAKMP SA ở dạng cookies
• Số ngẩu nhiên known as nonces (used for signing purposes) Nếu hai bên đồng ý sử dụng phương pháp xác nhận dựa trên public key, chúng cũng cần trao đổi IDs. Sau khi trao đổi các thông tin cần thiết, cả hai bên