Một User truy nhập mạng IMS cần phải được nhận thực và trao quyền trước khi dùng một dịch vụ IMS nào. Khi User được trao quyền, chúng bảo vệ lưu lượng SIP giữa UE và P-CSCF nhờ cơ chế kết hợp bảo mật IPsec.
Sự nhận thực, trao quyền và kết hợp bảo mật IPsec được thực hiện trong giao dịch REGISTER.
Ở mục 2.2.2 đã xét về sự nhận thực và trao quyền đối với UE dùng ISIM (Subscriber Identity Module) . Đến đây ta sẽ xét thêm trường hợp nhận thực và trao quyền đối với UE dùng USIM (UMTS Subscriber Identity Module) (ISIM và USIM là ứng dụng chứa trong UICC - Universal Integrated Circuit Card – một UE muốn dùng trong IMS cần có UICC chưa ISIM hoặc USIM). Vì USIM chứa IMSI (liên quan đến Private User Identity) nên đầu cuối IMS có thể xây dựng một Private User Identity tạm thời, một Public User Identity và một URI miền mạng thường trú dựa trên nội dung của IMSI (ví dụ IMSI là 2483235551234 sẽ xác đinh được MCC là 248, MNC là 323 và MSIN là 5551234 thì Private User Identity tạm thời là sip: 2483235551234@323.248. imsi. 3gppnetwork. org và Public User Identity tạm thời là sip : 2483235551234@3323.248. imsi . 3gppnetwork. org và URI miền thường trú là sip:323.248.imsi.3gppnetwork.org). Những nhận dạng này có tác dụng cho việc tạo yêu cầu REGISTER theo đúng định dạng, đồng thời cho phép định tuyến và S-CSCF tìm AV trong HSS. Ngoài những nhận dạng có thể xây dựng được dựa trên IMSI, USIM chứa long-term secret dùng cho nhận thực trong các mạng PS và CS. Các thủ
tục thực hiện sự nhận thực và trao quyền giống như với trường hợp UE chỉ có ISIM.
Sự thiết lập kết hợp bảo mật: P-CSCF và đầu cuối thiết lập hai kết hợp bảo mật IPsec. Thực hiện hai sự kết hợp này cho phép các đầu cuối P-CSCF dùng UDP để
nhận các phản hồi cho một yêu cầu (số hiệu port nằm trong mà đầu Via của yêu cầu) trên một port khác với port được dùng cho việc gửi yêu cầu (do có hai port nên cần hai sự kết hợp bảo mật). Hoặc theo cách khác, P-CSCF dùng cùng một kết nối TCP để gửi và nhận yêu cầu và phản hồi. Trong cả hai trường hợp, sự kết hợp bảo mật được thiết lập từ port client-protected của đầu cuối đến port server-protected của P-CSCF và ngược lại, sự kết hợp bảo mật này sẽ hỗ trợ bảo mật cho lưu lượng theo cả hai hướng.
Luận văn thạc sĩ kỹ thuật 65
Hình 2-20: Sự kết hợp bảo mật dùng trên UDP
Hình 2-21: Sự kết hợp bảo mật dùng trên TCP
Đầu cuối UE sẽ thêm vào mào đầu Security-Client vào yêu cầu REGISTER sơ cấp rồi gửi đến P-CSCF.
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96; spi-c=23456789; spi-s=12345678;
port-c=2468; port-s=1357
Mào đầu này chứa cơ chế ipsec-3gpp và thuật toán hmac-sha-1-96 mà đầu cuối có hỗ
trợ, và các địa chỉ cổng bảo mật. Sau khi yêu cầu sơ cấp lên tới S-CSCF để thực hiện việc nhận thực, S-CSCF sẽ gửi lại phản hồi 401 Unauthorized (chứa các tham số cần thiết cho sự kiểm tra nhận thực như IK, CK, AUTN và RAND) lại phía UE.
P-CSCF nhận được 401 nó sẽ loc IK và CK (để kết hợp với thuật toán bảo mật, bảo vệ
dữ liệu) rồi gửi 401 đã lọc đến UE sau khi đã chèn thêm mào đầu Security-Server vào 401 Unauthorized
Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321;
port-c=8642; port-s=7531
Tham số q chỉđịnh cho sựưu tiên (tham số này chỉ có nghĩa khi có nhiều cơ chế bảo mật được dùng, giá trị q càng lớn max là 1 thì độưu tiên càng cao).
Để phản hồi lại, UE sẽ chèn mào đầu Security-Verify vào yêu cầu REGISTE thứ cấp
để gửi lên P-CSCF:
Luận văn thạc sĩ kỹ thuật 66
spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Chú ý, nếu một hacker nghe trộm và thay đổi Security-Verify thì User sẽ không thể đăng ký được do P-CSCF sẽ từ chối yêu cầu từ UE, đây là khâu yếu nhất của sự bảo mật. Hiện tại P-CSCF chỉ hỗ trợ ipsec-3gpp, tương lai nó có thể hỗ trợ bằng nhiều cơ
chế bảo mật khác.
2.2.2.2 Bảo mật mạng
Bảo mật mạng được dùng cho việc bảo mật lưu lượng giữa các miền mạng khác nhau. Tất cả lưu lượng tới hoặc đi khỏi miền bảo mật đều phải qua cổng bảo mật SEG (Security Gateway). Lưu lượng từ một miền mạng đến một miền mạng khác phải qua hai SEG (hình 2-22).
Hình 2-22: Lưu lượng qua hai cổng bảo mật
Lưu lượng giữa các SEG được bảo vệ bằng việc dùng IPsec ESP (Encapsulated Security Payload định nghĩa trong RFC 2406 [149]) hoạt động ở chếđộ ngầm. Sự kết hợp bảo mật giữa các SEG được thiết lập và được duy trì nhờ dùng IKE (Internet Key Exchange định nghĩa trong RFC 2409 [118]).
Có hai loại giao diện giữa các SEG: giao diện Za giữa các SEG thực hiện truyền lưu lượng giữa các miền mạng khác nhau, và Zb giữa các SEG nội miền (hình 2-23).
Luận văn thạc sĩ kỹ thuật 67
2.2.2.3 Một số khái niệm chi tiết liên quan đến bảo mật
2.2.2.3.1 HTTP Digest
Khi Server nhận được một yêu cầu từ Client, nó sẽ mời Client cung cấp các khả năng của Client trong miền mạng (Client sẽ cung cấp tên và các chứng thực rằng Client cũng đã biết Share Sceret – như password chẳng hạn). Chính vì thế cần mật mã các thông tin này khi truyền giữa Client và Server. Client dùng digest có thể chứng thực các thông tin bí mật đó mà không cần gửi qua mạng. Digest dùng thuật toán hash và nonce (là giá trị ngẫu nhiên làm một đầu vào cho bộ tạo mã theo thuật toán hash) cho mục đích này. Thuật toán hash hay được dùng phổ biến là MD5; với đầu vào là chuỗi ký tự nonce, và khoá mật mã ki, đầu ra luôn là một dãy 32 ký tự hexa (RFC 1321). Hình 2-24 sẽ chỉ ra cách digest được dùng:
Hình 2-24: Sự vận hành Digest
Tham số realm chỉ ra miền chứa proxy server, Client sẽ biết cần phải dùng password nào. Tham số qop (quality of protection) chỉ ra rằng server có hỗ trợ bảo vệ cho dòng hay cho cả dòng và toàn bộ thân của yêu cầu (auth hoặc auth-int). Khi nhận được qop có giá trị auth-int, client biết rằng thân yêu cầu được thực hiện hash. Client sẽ thực hiện hash đối với nonce và gửi lại kết quảở mào đầu response cho Server.
Luận văn thạc sĩ kỹ thuật 68 2.2.2.3.2 TLS - bảo mật lớp truyền tải
TLS (Transport Layer Security, định nghĩa trong RFC 2246 [82]) dựa trên SSL (Secure Socket Layer). SSL được thiết kế cho việc bảo vệ thông tin web và được triển khai trong hầu hết các trình duyệt Internet. TLS tổng quát hơn SSL, nó có thể được dùng để bảo vệ bất cứ loại kết nối nào. Vì thế TLS được dùng để bảo vệ lưu lượng SIP.
TLS có hai lớp: lớp TLS handshake và lớp TLS record. TLS handshake thực hiện nhận thực các thực thể ngang hàng, nó dùng các khóa công cộng và các chứng chỉ
(Certifỉcate - hay khoá để hiểu TLS và S/MINE), thuật toán đê tạo mã bảo mật truyền dữ liệu, hay còn gọi là khoá bảo mật. TLS record thực hiện mã hóa dữ liệu. Nó dùng thuật toán mã hóa đối xứng có khóa được tạo từ giá trịđược lớp handshake cung cấp.
Hình 2-25: Thiết lập kết nối TLS
2.2.2.3.3 S/MINE
Khi UE muốn chuyển các thông tin mà proxy không thể truy nhập (ví dụ như nội dung của luồng audio hay video giữa hai user), thì SIP cần dùng giải pháp bảo mật end-to- end hay dùng S/MINE (Secure/Multipurpose Internet Mail Extension). Thường thì thân của bản tin sẽ được dùng với S/MINE, đôi khi nó cũng được dùng để mật mã hoặc mã hoá các mào đầu có mang thông tin nhậy cảm.
Hình 2-26 sau là một ví dụ cho bản tin có dùng S/MINE với sơđồ khối mã hoá và giải mã ở hình 2-27 và 2-28
Luận văn thạc sĩ kỹ thuật 69
Via: SIP/2.0/UDP
wsl.domain2.com:5060;branch=z9hG4bK74gh5 Max-Forwards: 70
From: Bob <sip:Bob.Brown@domain2.com>;tag=9hx34576s1 To: Alice <sip:Alice.Smith@domain.com>
Call-ID:63287762982201885110192.0.100.2 Cseq: 1 INVITE
Contact: <sip:bob<@192.0.100.2> Content-Length: 197
Content-Type: application/pkcs7-mine; smine-type=enveloped- data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.7pm; Handing=required
Rfvbnj756bBkoqim
Hình 2-26: Thân của bản tin đã được mật mã nhờ dùng S/MINE
Luận văn thạc sĩ kỹ thuật 70
Message Encrypted
Message
Content Encryption Key Encryption Content
Encryption Key
Recipient’s Public Key
Hình 2-28: Sơđồ dùng S/MINE giải mã thân bản tin
Khi UE muốn bảo mật cho mào đầu (ví dụởđây là mào đầu From, To và Contact), nó sẽ copy và đặt các mào đầu này vào toàn bộ thân bản tin cần được dùng S/MINE để
bảo mật (thực hiện điều này sẽ tránh được việc bị thay đổi thông tin của mào đầu). Mào đầu Content-Type: message/sigfrag sẽ chỉ ra bản tin có dùng S/MINE cho bảo mật mào đầu:
INVITE sip:Alice.Smith@domain.com SIP/2.0
Via: SIP/2.0/UDP wsl.domain2.com:5060;branch=z9hG4bK74gh5 Max-Forwards: 70
From: Bob <sip:Bob.Brown@domain2.com>;tag=9hx34576s1 To: Alice <sip:Alice.Smith@domain.com>
Call-ID: 6328776298220188110192.0.100.2 Cseq: 1 INVITE
Contact: <sip:bob@192.0.100.2> Content-Type: application/sdp v=0
o=bob 2890844526 2890844526 IN IP4 ws1.domain2.com s=-
c-IN IP4 192.0.100.2 t=00
m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Luận văn thạc sĩ kỹ thuật 71 -unique-boundary-1 Content-Type: multipart/signed; protocol=”application/pkcs7-signature”; micalg=shal; boundary=boundary2 -boundary2 Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional From: Bob <sip:Bob.Brown@domain2.com> Call-ID: 6328772982201885110192.0.100.2 Cseq: 1 INVITE
Contact: <sip:bob@192.0.100.2> Date: Thu, 9 Oct 2003 10:21:03 GMT -boundary2
Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s; handling=required
ghyHhHujhjKH77n88 -boundary2-
Hình 2-29: Bảo mật cho trường mào đầu 2.2.3 Nghiên cứu vấn đề quản lý chính sách trong IMS
IMS dùng giao thức COPS (Common Open Policy Service) để truyền các thông tin liên quan đến chính sách (ví dụđối với các thủ tục SIP, đối với việc trao quyền truyền thông). Giao thức COPS dùng giữa Proxy SIP và các Route, hay giữa điểm quyết định chính sách (PDP) và điểm thực hiện chính sách (PEP), ởđây Proxy là PDP còn Route là PEP.
2.2.3.1 Đối với các thủ tục SIP
Có hai loại giới hạn đối với phiên mà một đầu cuối có thể thiết lập qua mạng IMS đó là: những giới hạn đối với user riêng biệt; và những chính sách mạng nói chung.
Luận văn thạc sĩ kỹ thuật 72
Giới hạn đối với từng user có thể là thuê bao đăng ký sử dụng dịch vụ audio, thì user sẽ không được trao quyền để thiết lập các luồng liên quan đến video chẳng hạn. Các chính sách mạng chung không áp dụng đối với từng user mà nó áp dụng đối với toàn bộ user trong mạng (như trường hợp mạng không cho phép dùng phương pháp mã hóa thoại G.711).
Việc trao đổi các offer/answer của thiết bị đầu cuối phải tính đến các giới hạn liên quan tới mạng. Ví dụ nếu đầu cuối không được cho phép thiết lập luồng video thì nó không được thực hiện offer/answer exchange chứa luồng video. P-CSCF thực hiện các chính sách mạng chung, trong khi đó S-CSCF xử lý cả chính sách mạng chung và chính sách đặc trưng cho thuê bao.
Cả P-CSCF và S-CSCF cùng dùng cơ chế xác định được các offer/answer không được trao quyền từ phía UA (user agent, hay UE) nhờ việc truy nhập đến thân của mô tả
phiên SDP. Nếu một đề nghị chứa thông tin ngược với chính sách (vị dụ như chứa mã hóa không hợp lệ) thì CSCF trả lại một đáp ứng 488 (Not Acceptable Here) trong thân SDP có mô tả chính sách hay tập các tham số cho phép (các chính sách). Hình 2-30 là một ví dụ. S-CSCF nhận được yêu cầu INVITE (2) có các mô tả phiên được chỉ ra ở
hình 2-31, chứa một luồng video và một luồng audio. S-SCCF trả lại đáp ứng 488 (3) chứa những mô tả phiên chỉ ra rằng nó chỉ cho phép luồng audio. Mô tả phiên này cho thấy S-CSCF chỉ cho phép thiết lập luồng audio mà không cho thiết lập luồng video.
Hình 2-30: S-CSCF không chấp nhận INVITE của đầu cuối.
v=0
o-2790844676 2867892807 IN IP6 1080::8:800:200C:417A s=-
Luận văn thạc sĩ kỹ thuật 73
t=00
m=audio 20000 RTP/AVP 97 96 b=AS:25.4
a=curr:qos local none a=curr:qos remote none
a=des:qos mandatory local sendrecv a=rtpmap:97 AVR
a=fmtp:97 mode-set=0,2,5,7; maxirames=2 a=rtpmap:96 telephone-event
m=video 20002 RTP/AVP 31
Hình 2-31: SDP trong yêu cầu INVITE.
2.2.3.2 Đối với sự trao quyền phương tiện truyền thông
Khi hai user agent thực hiện offer/answer exchange đều được P-CSCF và S-CSCF chấp thuận thì chúng sẽ được phép truyền thông. Mạng cần chỉ dẫn GGSN (đối với 3 GPP) để trao quyền cho lưu lượng truyền thông của user tuân theo offer/answer exchange đã được trao quyền trước đó (hai user agent thực hiện offer/answer exchange
để thiết lập luồng audio, không được trao quyền truyền lưu lương video).
Hình 2-33 chỉ ra cách thẻ trao quyền được trao đổi trong một phiên outgoing (thẻ trao quyền được chuyển trên một bản tin SIP gửi bởi user agent nhưở hình 2-33 và hình 2- 32). P-CSCF không tạo ra một bản tin riêng để chuyển các thẻ, nó lợi dụng các bản tin SIP để chuyển thẻ này giữa các điểm kết cuối trong suốt khi thiết lập phiên.
Luận văn thạc sĩ kỹ thuật 74 (4 ) REQ (t oken) (5 ) DEG (QoS Info)
Hình 2-32: Thẻ trao quyền được chuyển trong yêu cầu INVITE
Hình 2-33: Thẻ trao quyền được chuyển ở một bản tin phản hồi SIP
Thẻ trao quyền được tạo bởi PDF chứa thông tin rằng buộc nhận dạng cho SIP dialog và địa chỉ của PDF đã tạo ra nó (thẻ trao quyền). Ví dụ thẻ trao quyền được chứa tại mào đầu P-Media-Authorization:
P-Media-Authorization: 0020000100100101706466322 e76697369746564322e6e6574000c020139425633303732
Luận văn thạc sĩ kỹ thuật 75
Khi GGSN nhận được thẻ này, (3) trong hình 2-32 và (5) trong hình 2-33, nó sẽ lấy ra
địa chỉ của PDF và gửi thông điệp COPS REQ đến địa chỉ này. GGSN sẽ dán thẻ này (gép các thông tin của thẻ) và thông tin nhận được từ user agent vào bản tin REG. PDF lấy các thông tin này ra từ bản tin REG đó và dùng để nhận dạng SIP dialog (toàn bộ
text của sip từ khi khởi tạo đăng ký đến kết thục bằng BYE), rồi gửi trở lại bản tin COPS DEC chứa QoS đã trao quyền cho phiên.
2.2.3.3 Đối với Proxy truy nhập đến các thân SDP
Tất cả các cơ chế chính sách IMS mà chúng ta mô tả đều giả thiết là P-CSCF và S- CSCF đã truy nhập đến các thân SDP của các bản tin SIP. Do đó, cơ chế bảo mật đầu cuối đến đầu cuối như S/MINE sẽ không được phép sử dụng. Hơn nữa, user agent buộc phải dùng SDP theo định dạng mô tả phiên của nó. Ngoài ra, các CSCF sẽ không biết loại phiên nào đang được thiết lập.
2.2.3.4 Thủ tục khởi tạo
Thủ tục khởi tạo giữa GGSN (đảm nhận vai trò PEP) và PEF (đảm nhận vai trò PDP)
được dựa trên 3 GPP Go PIB (định nghĩa ở 3 GPP TS 29.207). GGSN dùng 3 GPP Go PIB mã hóa các khả năng của nó và gửi đến PDF trong bản tin COPS REQ. PDF phản hồi bằng bản tìn COPS DEC, và cả hai sẵn sàng thông tin.
2.2.4 Nghiên cứu vấn đề chất lượng dịch vụ trong IMS
IMS hỗ trợ các chếđộ QoS end-to-end (được mô tảở 3 GPP TS 23.207 [13]): Các đầu cuối có thể trực tiếp dùng các giao thức dành riêng cho tài nguyên lớp liên kết, RSVP (Resource ReSerVation Protocol), hoặc cấu trúc Diffserv (*).
2.2.4.1 Giới thiệu
Các đầu cuối cần ánh xạ các luồng truyền thông của một phiên vào các luồng dành cho tài nguyên (Resource Reservation). Một đầu cuối thiết lập một luồng audio và một luồng video có thể yêu cầu một luồng Reservation đơn (cho cả audio và video) hoặc yêu cầu hai luồng Reservation (một cho audio, một cho video). Việc yêu cầu đó có thể
gồm việc tạo ra một context PDP thứ cấp hoặc việc gửi những gói PATH RSVP. P-CSCF hướng dẫn đầu cuối thực hiện Resource Reservation bằng cách dùng các SRF (Single Reservation Flow) của SDP Grouping Framwork.
SDP Grouping Framework (RFC 3388) cho phép nhóm các luồng truyền thông và mô tả ngữ nghĩa của nhóm. Ví dụ, LS (Lip Synchronization) chỉ ra rằng play-out của các luồng truyền thông cần phải được đồng bộ. LS được dùng để nhóm một luồng audio và một luồng video (hình 2-34). Dòng a=group mang mô tả nhóm (ởđây là LS) và mạng các nhận dạng của luồng tin.
Luận văn thạc sĩ kỹ thuật 76
v=0
o=- 289083124 289083124 IN IP6 1080::8:800:200C:417A c=IN IP6 1080::800:200C:417A
a=group:LS 1 2 m=audio 20000 RTP/AVP 0 a=mid:1 m=video 20002 RTP/AVP 31 a=mid:2 Hình 2-34: LS semantic.
SRF Semantic chỉ ra rằng tất cả các luồng trong nhóm nên dùng cùng luồng Resource