3 .7An ninh trong G UMTS R5
3.7.2 An ninh IMS
3.7.2.1 Giao thức khởi tạo phiên SIP
SIP làm việc như sau: một người sử dụng hoặc một tác nhân người sử dụng (UA) gửi một bản tin lời mời “INVITE” đến một người sử dụng khác để bắt đầu phiên họp nơi mà dữ liệu đa phương tiện được trao đổi. SIP ủy thác giúp người sử dụng thực hiện nhiệm vụ này. UA này cũng gửi bản tin đăng ký “REGISTER” tới các Server SIP, cái mà được gọi là “các hộ tịch viên”. Việc đăng ký của UA này giúp cho các UA khác có thể tìm được nó. UA được mời sẽ gửi trở lại UA mời một bản tin OK nếu quyết đinh chấp nhận phiên họp. Trong tải của các bản tin SIP, các phiên truyền thông sử dụng giao thức miêu tả phiên (SDP). Các đặc tính này bao gồm tên và thời gian của phiên, kiểu và dạng của chuỗi truyền thông, các địa chỉ và cổng của nơi nhận. Người sử dụng có thể kết thúc các phiên này bằng việc gửi bản tin “BYE”.
SIP dựa trên cách thức hỏi và trả lời, tương tự như HTTP. Mỗi bản tin SIP là một yêu cầu được gửi từ một Client tới một Server hoặc một trả lời được gửi ngược trở lại. Chú ý rằng UA bao gồm cả hai Server (UAS) và Client (UAC).
Có 6 kiểu yêu cầu cơ bản, được gọi là các phương thức trong SIP: “REGISTER” sử dụng cho việc đăng ký thông tin cho một người sử dụng; “INVITE”; “ACK” và “CANCEL” để thiết lập các phiên; “BYE” để kết thúc các phiên; “OPTION” để tìm ra các khả năng của Server. Ngồi ra cịn có “INFO” để truyền các thơng tin báo hiệu phiên trung bình và “MESSAGE” cho các bản tin gấp.
Các trả lời bao gồm một mã tình trạng tạo thành từ ba số nguyên. Số đầu tiên cho biết kiểu của trả lời trong các dạng dưới đây:
+ 1xx là trả lời cá nhân, được thiết lập trong quá trình xử lý kết quả; + 2xx biểu thị yêu cầu được chấp nhận;
+ 3xx biểu thị gián tiếp;
+ 4xx biểu thị lỗi Client, bằng cách nào đó một yêu cầu trở nên xấu hoặc gửi nhầm Server;
+ 5xx biểu thị lỗi Server (ví dụ yêu cầu hợp lệ nhưng Server khơng thực hiện nó);
+ 6xx là lỗi cục bộ, yêu cầu không thể được thực hiện bởi tất cả các Server. Một giao dịch bao gồm yêu cầu được gửi đi bằng một Client và tất cả trả lời cho các yêu cầu đó được gửi lại bởi một Server. Lớp giao dịch SIP chịu trách nhiệm truyền lại các yêu cầu và trả lời, làm khớp các trả lời cho đúng với các yêu cầu và khơng tính thời gian.
u cầu INVITE thiết lập một hộp thoại: một mối quan hệ SIP ngang hàng, tồn tại một thời gian và bao gồm vài giao dịch. Hộp thoại cũng làm cho việc sắp xếp dễ dàng hơn và việc định tuyến các bản tin SIP giữa các UA chính xác hơn.
Ngồi ra, các bản tin SIP còn bao gồm các trường tiêu đề và nội dung bản tin. Dưới đây là ví dụ về các kiểu tiều đề:
+ Via: bao gồm địa chỉ để được trả lời;
+ To: ghi rõ một cách logic theo yêu cầu của người nhận; + From: chỉ thị khởi đầu của một yêu cầu;
+ Call-ID: nhận dạng duy nhât một phiên của một người dùng cụ thể;
+ Contact: hướng tới một nhận dạng tài nguyên đồng dạng (URI) và ý nghĩa của chúng phụ thuộc vào kiểu yêu cầu;
+ Content-Type: biểu thị kiểu thông tin được truyền trong nội dung bản tin; + Authentication-Info: được sử dụng để nhận thực qua lại bởi cơ chế tóm tắt HTTP;
+ Authorization: bao gồm các giấy chứng nhận của UA cần cho việc nhận thực;
+ Priority: biểu thị sự khẩn cấp của yêu cầu;
+ Record-Router: được thêm vào bởi sự ủy thác cho các yêu cầu trong tương lai để định tuyến thông qua cùng một sự ủy thác;
+ Subject: biểu thị đặc tính/bản chất của cuộc gọi.
3.7.2.2 Kiến trúc an ninh IMS
Trong miền PS, dịch vụ chỉ được cung cấp khi đã thiết lập một liên kết an ninh giữa thiết bị di động và mạng. IMS về bản chất là một hệ thống xếp chồng liên miền. Vì thế cần có một liên kết an ninh riêng giữa Client đa phương tiện và IMS, trước khi cho phép truy nhập các dịch vụ đa phương tiện. Kiến trúc an ninh IMS
được cho ở hình 3.14.
Các khóa nhận thực IMS và các hàm tại phía người sử dụng được lưu tại UICC. Các khóa và các hàm này có thể độc lập logic với các khóa và các hàm sử dụng để nhận thực cho miền. Tuy nhiên, điều này không cản trở việc sử dụng các khóa nhận thực và các hàm chung cho việc nhận thực cả miền IMS lẫn miền PS.