Mobile IP định nghĩa cơ chế xác thực cho phép các MN có thể tự xác thực với một FA thông qua một thông điệp mở rộng (mục 3.3.1). Tuy nhiên, cơ chế xác thực này không đủ mạnh để chống lại tấn công replay, đồng thời không cho phép sử
dụng các kỹ thuật xác thực hiện có (như CHAP).
Các đặc tả trong [5] định nghĩa các mở rộng cho các thông điệp quảng bá Agent và yêu cầu đăng ký Mobile IPv4. Các đặc tả này định nghĩa một cơ chế yêu cầu/đáp ứng (challenge/response) cho phép xác thực MN. Cơ chế này là giải pháp cho xác thực và cấp quyền truy nhập. Chuỗi yêu cầu là một giá trị ngẫu nhiên 128 bit và được dùng cho thủ tục xác thực. Một liên kết tin cậy giữa một FA và một HA
được hình thành sử dụng cơ chế của một hạ tầng kiểm tra (verification infrastructure - Hình 32).
Hình 32 Hạ tầng kiểm tra
Sau khi FA nhận được đáp ứng từ MN, FA chuyển xuống hạ tầng quản lý khóa và kiểm tra (Verification and key management Infrustructure) và chờ một trả
lời đăng ký. FA chấp nhận đăng ký từ hạ tầng đó chỉ khi trả lời là đồng ý. Nếu trả
lời là từ chối, FA sẽ xem như chuỗi yêu cầu không thỏa mãn sự kiểm tra.
a) Quảng bá trạm với mở rộng yêu cầu/đáp ứng
Để gửi đi trên mạng một challenge cho các MN đang cần xác thực, FA sử
dụng một mở rộng của giao thức phát hiện định tuyến (Router Discovery Protocol):
Hình 33 Mở rộng challenge
Trong đó:
- Type: nhận giá trị 24
- Length: độ dài giá trị challenge tính theo byte
- Challenge: một giá trị ngãu nhiên, nên có độ lớn tối thiểu 32 bit.
b) Cơ chế MN xử lý các yêu cầu đăng ký
Khi các quảng bá của các Agent chứa mở rộng Challenge, và nếu MN không có một thiết lập bảo mật với FA, MN sẽ phải đưa giá trị Challenge vào trong thông điệp yêu cầu đăng ký. Ngược lại, nếu MN đã có một thiết lập bảo mật với FA, nó không nhất thiết nhưng nên đưa giá trị challenge vào thông điệp yêu cầu đăng ký.
Trong trường hợp MN đã có một thiết lập bảo mật với FA, Và MN sẽ phải gửi cả phần mở rộng xác thực MN-FA trong thông điệp yêu cầu đăng ký. Khi yêu cầu đăng ký chứa mở rộng Challenge MN-FA, quá trình xác thực MN-FA phải tiếp sau mở rộng Challenge trong yêu cầu đăng ký.
c) Cơ chế FA xử lý các yêu cầu đăng ký
Khi nhận được yêu cầu đăng ký, nếu FA đã gửi đi một Challenge trong thông điệp quảng bá Agent; FA cũng chưa có một thiết lập bảo mật với MN, FA sẽ
phải kiểm tra để đảm bảo rằng mở rộng Challenge MN-FA tồn tại, và giá trị
Challenge đó chưa được dùng bởi MN. Nguyên tắc này để tránh MN sử dụng replay với một thông điệp quảng bá và xác thực trước đó.
d) Cơ chế FA xử lý các trả lời đăng ký
FA có thể gửi một Challenge mới trong các trả lời đăng ký, cho dù đăng ký
đã thành công hoặc chưa. Nếu FA gửi mở rộng Challenge trong trả lời đăng ký thành công, mở rộng Challenge nên được đặt trước mở rộng xác thực MN-FA.
Nếu trả lời đăng ký có chứa một mở rộng Challenge từ HA, và FA cũng muốn gửi một mở rộng Challenge cùng với trả lời đăng ký cho MN. Trong trường hợp này, FA phải xóa mở rộng Challenge từ HA trong trả lời đăng ký, cùng với mọi mở rộng xác thực giữa FA-HA trước khi FA thêm vào các mở rộng Challenge mới.
e) Cơ chế xử lý mở rộng Challenge của HA
Nếu HA nhận được một yêu cầu đăng ký với mở rộng Challenge MN-FA, HA phải gửi một mở rộng Challenge trong trả lời đăng ký. Mở rộng Challenge của HA phải đặt sau mở rộng xác thực MN-HA.
f) Cấu trúc mở rộng Challenge MN-FA
Mở rộng Challenge đưa vào thông điệp yêu cầu đăng ký được dùng để chỉ (adsbygoogle = window.adsbygoogle || []).push({});
Hình 34 Mở rộng Challenge MN-FA
Trong đó:
- Type: nhận giá trị 132
- Length: độ dài giá trị Challenge
- Challenge: giá trị Challenge được copy từ trường Challenge của thông
điệp quảng bá Agent.