1.8 Thỏa Thuận Cơ Chế Bảo Mật SIP
1.8.1 Tại Sao Cần Có Thỏa Thuận Cơ Chế Bảo Mật SIP
IMS trong 3GPP phiên bản 5 và 6 sử dụng IPsec làm cơ chế bảo mật giữa P-CSCF và UE. IPsec chỉ là một trong số các cơ chế bảo mật khả thi. IMS được thiết kế để cho phép các cơ chế bảo mật thay thế trên giao diện Gm. Việc cho phép mở như vậy thường tạo ra các vấn đề tương thích ngược bởi vì, ví dụ: một UE tuân thủ Bản phát hành 6 sẽ không thể hiểu bất kỳ sự thay thế nào cơ chế bảo mật, mặc dù nó có thể được gắn với P-CSCF của phiên bản cao hơn sẽ đã hỗ trợ các lựa chọn thay thế cho IPsec. Do đó, Thỏa thuận Cơ chế Bảo mật SIP (Sip-Sec-Agree) đã được đưa ra để cho phép UE và P-CSCF thương lượng một cơ chế bảo mật chung để sử dụng giữa họ. Đối với các bản phát hành hiện tại, cơ chế bảo mật duy nhất là IPsec; tuy nhiên, trong Rel-
8 TLS và HTTP Digest cũng sẽ được giới thiệu.
1.8.2 Tổng quan
Để làm cho ví dụ khơng q đơn giản và nhàm chán, chúng tôi giả định rằng UE hỗ trợ IPsec và thông báo HTTP và P-CSCF hỗ trợ IPsec và Bảo mật lớp truyền tải (TLS), với ưu tiên đối với TLS. Người đọc chương này khơng cần thiết phải có bất kỳ kiến thức nào về bất kỳ cơ chế nào trong số này.
Như chúng ta đã thấy, yêu cầu REGISTER ban đầu được gửi mà khơng có bất kỳ sự bảo vệ nào từ UE tới P-CSCF. Để đảm bảo rằng một cơ chế bảo mật chung có thể được thiết lập, UE của Tobias quảng cáo các cơ chế mà nó hỗ trợ trong yêu cầu ĐĂNG KÝ ban đầu này trong tiêu đề Security-Client, bao gồm danh sách các cơ chế được hỗ trợ. P-CSCF gửi lại tiêu đề Máy chủ-Bảo mật trong phản hồi 401 (Không được phép). Tiêu đề bao gồm danh sách các cơ chế được hỗ trợ từ đầu P-CSCF. Hơn nữa, P-CSCF thêm một ưu tiên (q-value) cho mỗi cơ chế.
Dựa trên thông tin này, cả hai đầu giờ đều biết cơ chế chung nào được UE và P-CSCF chuyển đến. Nếu có nhiều hơn một cơ chế chung, cơ chế được P-CSCF ưu tiên cao nhất sẽ được chọn và được áp dụng. Để đảm bảo rằng cơ chế này có thể được thiết lập ngay lập tức, P-CSCF sẽ gửi thêm thông tin trong phản hồi 401 (Không được phép) để cho phép UE để thiết lập cơ chế: ví dụ: trong một mơi trường khơng phải IMS, nó có thể gửi một tiêu đề Proxy-Authenticate khi thông báo HTTP là cơ chế được chọn.
Như chúng ta đã thấy trong Phần 11.7, UE và P-CSCF sau đó sẽ thiết lập bảo mật , trong trường hợp của chúng tơi là dựa trên IPsec SAs. Sau đó, tất cả các tin nhắn giữa hai thực thể sẽ được bảo vệ qua các SA này. Tuy nhiên, yêu cầu ĐĂNG KÝ ban đầu và phản hồi của nó vẫn khơng được bảo vệ.
Có một chút khả năng là một người dùng độc hại đã giả mạo các tin nhắn hoặc điều đó đã xảy ra lỗi trên giao diện khơng khí dễ bị tổn thương. Như đã trình bày trong các chương trước, yêu cầu ĐĂNG KÝ thứ hai từ UE lặp lại tất cả thông tin cần thiết để xác thực và đăng ký, cả hai đều được thực hiện với S-CSCF. Để đảm bảo rằng thông tin liên quan đến Sip-Sec-Agree không cũng đã được thay đổi, UE:
•Lặp lại tiêu đề Security-Client mà nó đã gửi trong lần REGISTER ban đầu trong giây Yêu cầu REGISTER là tốt
•Sao chép nội dung của tiêu đề Máy chủ-Bảo mật đã nhận được trong phản hồi 401 (Unau thorized) từ P-CSCF vào tiêu đề Bảo mật-Xác minh và gửi nó cùng với cả yêu cầu REGISTER thứ hai.
Miễn là Hiệp hội Bảo mật đã thành lập được sử dụng, UE sẽ luôn lặp lại cùng tiêu đề Bảo mật-Xác minh trong mọi yêu cầu mà nó gửi đến P-CSCF. Trong q trình trao đổi giữa Security-Client (từ UE) và Security-Server (từ tiêu đề P-CSCF), hai đầu cũng đồng ý về một số tham số cho IPsec SAs: nghĩa là, chúng chỉ ra cho nhau các cổng máy khách và máy chủ được bảo vệ (cổng c và cổng-s) cũng như các chỉ số tham số bảo mật (SPI: spi-c và spi-s).
1.8.3 Tiêu đề liên quan đến Sip-Sec-Agree trong Yêu cầu REGISTER Ban đầu
Để kích hoạt thỏa thuận về cơ chế bảo mật, UE bao gồm thông tin hạ thấp của mọi người trong yêu cầu REGISTER ban đầu:
REGISTER sip:home1.fr SIP/2.0 Require: sec-agree
Proxy-Require: sec-agree
Security-Client: digest, IPsec-3gpp ;alg=hmac-sha-1-96 ;spi-c=23456789 ;spi-s=12345678
;port-c=2468 ;port-s=1357
Tiêu đề Yêu cầu proxy bao gồm thẻ tùy chọn ‘sec-agree’; điều này chỉ ra rằng tiếp theo proxy hop, trong trường hợp này là P-CSCF, phải hỗ trợ các thủ tục cho Sip-Sec-Agree trong để xử lý yêu cầu thêm. Nếu proxy bước tiếp theo không hỗ trợ Sip-Sec-Agree thủ tục, nó sẽ - dựa trên việc xử lý tiêu đề Yêu cầu proxy, được xác định trong [RFC3261] - gửi lại phản hồi 420 (Tiện ích mở rộng không hợp lệ), bao gồm cả một phản hồi Khơng được hỗ trợ tiêu đề có thẻ tùy chọn ‘sec-agree’. Vì P-CSCF trong ví
23
dụ của chúng tơi là IMS đầy đủ Phiên bản tuân thủ 5 và 6, tất nhiên nó hỗ trợ các thủ tục SIP SA và sẽ khơng gửi phản hồi này cho UE.
Ngồi ra, tiêu đề Yêu cầu được bao gồm, cho biết thẻ tùy chọn đồng ý giây. Điều này là bắt buộc được bao gồm bởi [RFC3329], xác định Sip-Sec-Agree. Tiêu đề Yêu cầu là được sử dụng theo cách tương tự như tiêu đề Proxy-Request nhưng được sử dụng bởi UE từ xa (khơng phải proxy). Nó chỉ trong trường hợp một yêu cầu (trong trường hợp này là yêu cầu REGISTER) được gửi trực tiếp từ UE gửi đến đích cuối cùng (S- CSCF), nơi sẽ khơng nhìn vào tiêu đề Proxy-Request ở tất cả; điều này có nghĩa là khơng có thương lượng về bảo mật cơ chế sẽ diễn ra. Tiêu đề Yêu cầu buộc đầu nhận thực hiện thủ tục thỏa thuận giây.
Vì P-CSCF có thể thực hiện các thủ tục Sip-Sec-Agree, nó sẽ loại bỏ sec-thỏa thuận các thẻ tùy chọn từ các tiêu đề Yêu cầu và Yêu cầu proxy trước khi gửi yêu cầu tới Mạng điều hành gia đình của Tobias. UE của Tobias gửi danh sách các cơ chế bảo mật được hỗ trợ tới P-CSCF trong tiêu đề Máy khách-Bảo mật. P-CSCF sẽ phát hiện ra, dựa trên thông tin được cung cấp trong tiêu đề này, UE của Tobias hỗ trợ hai cơ chế bảo mật: một là thơng báo HTTP (‘Thơng báo’) và cái cịn lại là IPsec như được 3GPP sử dụng (‘IPsec-3gpp’). Hai cơ chế này được phân tách bằng dấu phẩy trong tiêu đề. Danh sách các tham số (được phân tách bằng dấu ‘;’) cho sau bao gồm:
•Thuật tốn (tham số alg) - được sử dụng để mã hóa và bảo vệ IPsec (trong trường hợp này đó là thuật tốn HMAC SHA 1-96, được định nghĩa trong [RFC2404])
•Cổng máy khách được bảo vệ (cổng-c) và cổng máy chủ được bảo vệ (cổng-s) - được sử dụng từ UE là kết thúc cho IPsec SAs; và
•SPI - được sử dụng cho IPsec SA cũng liên quan đến cổng máy khách được bảo vệ (spi-c) như SPI được sử dụng cho IPsec SA liên quan đến cổng máy chủ được bảo vệ (spi-s). P-CSCF cũng sẽ xóa tiêu đề Máy khách-Bảo mật trước khi gửi REGISTER yêu cầu thêm. Lưu ý rằng cơ chế bảo mật IPsec-3gpp chỉ phù hợp với IMS. Ví dụ đưa ra ở đây sử dụng thơng báo và TLS có thể có các cơ chế bảo mật bổ sung trong các tiêu đề liên quan đến Sip-Sec Agree. Điều này chỉ được thực hiện để giải thích các thủ tục đằng sau cuộc đàm phán tiến trình.
1.8.4 Tiêu đề máy chủ bảo mật trong phản hồi 401 (Chưa Xác Thực)
Khi nhận được phản hồi 401 (Trái phép) từ S-CSCF cho một REGISTER yêu cầu, P- CSCF bao gồm danh sách các cơ chế bảo mật được hỗ trợ trong Máy chủ-Bảo mật tiêu đề trong phản hồi:
SIP/2.0 401 Unauthorized
Security-Server: tls ;q=0.2, IPsec-3gpp; q=0.1 ;alg=hmac-sha-1-96
;spi-c=98765432 ;spi-s=87654321 ;port-c=8642 ;port-s=7531
Trong ví dụ này, P-CSCF hỗ trợ hai cơ chế bảo mật: IPsec và TLS. Nó thậm chí cịn mang lại ưu tiên cao hơn cho TLS: nếu UE cũng hỗ trợ TLS, điều này sẽ được chọn để bảo vệ các thông báo giữa UE và P-CSCF. Hơn nữa, P-CSCF gửi thông tin liên quan đến IPsec về SPI và được bảo vệ cổng máy khách và máy chủ theo cùng một cách với UE. Tại thời điểm gửi phản hồi 401 (Chưa xác thực) tới UE, P-CSCF đã biết rằng IPsec sẽ được sử dụng làm cơ chế bảo mật, vì nó biết rằng đây là cơ chế duy nhất được hỗ trợ bởi cả UE và chính nó.
1.8.5 Tiêu đề Sip-Sec-Agree trong REGISTER Thứ hai
Sau khi nhận được phản hồi 401 (Chưa xác thực), UE có thể thiết lập IPsec SA. Khi nào điều này đã được thực hiện, nó có thể sử dụng các SA này để gửi yêu cầu REGISTER thứ hai qua nó. Trong yêu cầu ĐĂNG KÝ này bây giờ nó bao gồm các thơng tin liên quan sau:
REGISTER sip:home1.fr SIP/2.0 Require: sec-agree Proxy-Require: sec-agree Security-Verify: tls ;q=0.2, IPsec-3gpp ;q=0.1 ;alg=hmac-sha-1-96 ;spi-c=98765432 ;spi-s=87654321 ;port-c=8642 ;port-s=7531
Security-Client: digest, IPsec-3gpp ;alg=hmac-sha-1-96 ;spi-c=23456789 ;spi-s=12345678
;port-c=2468 ;port-s=1357
Một lần nữa, các tiêu đề Yêu cầu và Yêu cầu proxy với thẻ tùy chọn đồng ý giây là ở đó. Chúng phục vụ cùng mục đích như trong REGISTER ban đầu (xem Phần 1.8.3) và sẽ được lặp lại trong mọi yêu cầu REGISTER được gửi từ UE. P-CSCF sẽ ln xóa chúng trước khi gửi yêu cầu vào, giống như cách đã làm đối với yêu cầu REGISTER ban đầu. Nếu tiêu đề Yêu cầu proxy hoặc Yêu cầu (hoặc cả hai) được tìm thấy trống sau khi thẻ tùy chọn đồng ý giây đã bị xóa, P-CSCF cũng sẽ loại bỏ cái này hoặc
25
những cái tiêu đề trống này. Tiêu đề Bảo mật-Xác minh bao gồm một bản sao của tiêu đề Máy chủ-Bảo mật đã nhận. Các Tiêu đề Security-Client chỉ được gửi lại như trong yêu cầu REGISTER ban đầu. P-CSCF sẽ so sánh hai tiêu đề Security-Client đã nhận được trong ban đầu và yêu cầu REGISTER thứ hai này và xem liệu chúng có khớp hay khơng. Nó cũng sẽ so sánh nội dung của tiêu đề Máy chủ-Bảo mật mà nó đã gửi trong
401(Khơng được phép) phản hồi và với nội dung của tiêu đề Bảo mật-Xác minh mà nó nhận được trong giây này REGISTER yêu cầu. Trước khi gửi thêm yêu cầu REGISTER, P-CSCF sẽ xóa Các tiêu đề Security-Client và Security-Server từ nó.
1.8.6 Sip-Sec-Agree và Đăng ký lại
S-CSCF có thể quyết định xác thực lại UE trong bất kỳ thủ tục đăng ký lại nào, và bằng cách đó, nó sẽ buộc UE và P-CSCF thiết lập một tập hợp IPsec SA mới, vì các SA IPsec này dựa trên IK, thay đổi trong mỗi lần xác thực lại. Thiết lập một tập hợp IPsec SA mới cũng có nghĩa là bộ spis mới và các cổng máy khách và máy chủ được bảo vệ mới được thương lượng. Khi gửi yêu cầu REGISTER mới để đăng ký lại, UE không thể chắc chắn liệu S-CSCF có u cầu xác thực lại hay khơng. Do đó, nó sẽ thêm vào mỗi REGISTER yêu cầu tiêu đề Máy khách-Bảo mật mới với các giá trị mới cho spis và các cổng máy khách và máy chủ được bảo vệ: REGISTER sip:home1.fr SIP/2.0
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: tls ;q=0.2, IPsec-3gpp ;q=0.1 ;alg=hmac-sha-1-96 ;spi-c=98765432 ;spi-s=87654321
;port-c=8642 ;port-s=7531
Security-Client: digest, IPsec-3gpp ;alg=hmac-sha-1-96 ;spi-c=23456790 ;spi-s=12345679
;port-c=2470 ;port-s=1357
Lưu ý rằng các giá trị cho spis và số cổng máy khách được bảo vệ đã thay đổi trong tiêu đề Security-Client, để cho phép thiết lập một tập hợp SA mới, phải S-CSCF xác thực lại UE. Cổng máy chủ được bảo vệ của UE không thay đổi và sẽ được lưu giữ trong suốt quá trình đăng ký của người dùng (xem Phần 1.10.5). Nội dung của tiêu đề Bảo mật-Xác minh được gửi khơng thay đổi, vì nó là bản sao của tiêu đề mới nhất đã nhận được tiêu đề Máy chủ-Bảo mật. Cả P-CSCF và UE sẽ biết, tại thời điểm nhận được phản hồi về yêu cầu REGISTER này từ S-CSCF, liệu các IPsec SA mới có phải được thiết lập khơng: nghĩa là, có nhận được phản hồi 401 (Trái phép) hay khơng hoặc
200(OK) phản hồi được nhận. Khi nhận được phản hồi 401 (Không được phép) từ S- CSCF, P-CSCF sẽ thêm tiêu đề Máy chủ-Bảo mật mới vào phản hồi, cung cấp các giá trị mới cho nó được bảo vệ cổng và spis mới:
SIP/2.0 401 Unauthorized
Security-Server: tls ;q=0.2, IPsec-3gpp ;q=0.1 ;alg=hmac-sha-1-96 ;spi-c=98765434 ;spi-s=87654322
;port-c=8644 ;port-s=7531
Ngồi ra, P-CSCF sẽ khơng thay đổi giá trị của cổng máy chủ được bảo vệ của nó (7531). Do đó, UE và P-CSCF bây giờ sẽ thiết lập một nhóm SA tạm thời mới (xem Mục 11.7.3). Yêu cầu REGISTER, bao gồm phản hồi đối với thử thách xác thực lại xác thực (xem Phần 11.6), sẽ được gửi qua bộ SA mới, tạm thời này và sẽ bao gồm các tiêu đề sau:
REGISTER sip:home1.fr SIP/2.0 Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: tls ;q=0.2, IPsec-3gpp ;q=0.1 ;alg=hmac-sha-1-96 ;spi-c=98765434 ;spi-s=87654322
;port-c=8644 ;port-s=7531
Security-Client: digest, IPsec-3gpp ;alg=hmac-sha-1-96 ;spi-c=23456790 ;spi-s=12345679
;port-c=2470 ;port-s=1359
Một lần nữa, như trong thủ tục đăng ký ban đầu (Hình 11.10), yêu cầu REG ISTER thứ hai lặp lại tiêu đề Security-Client đã được gửi trong REGISTER mới nhất yêu cầu (với các giá trị mới) và sao chép trong tiêu đề Bảo mật-Xác minh các giá trị của Tiêu đề Máy chủ-Bảo mật đã nhận được trong phản hồi 401 (Không được phép) gần đây nhất. Cái này yêu cầu REGISTER thứ hai trong thủ tục đăng ký lại khơng cịn mang bất kỳ thông tin liên quan đến bất kỳ bộ SA nào đã được thiết lập trước đó.
27
Hình 1.3 Sip-Sec-Agree trong q trình đăng ký ban đầu 1.8.7 Các tiêu chuẩn liên quan
Các thông số kỹ thuật liên quan đến Mục 1.8 là:
3GPP TS 33.203 Bảo mật truy cập cho các dịch vụ dựa trên IP.
RFC2246 Giao thức TLS Phiên bản 1.0.
HTTP RFC2617: Xác thực truy cập thông báo và cơ bản.
Thỏa thuận Cơ chế Bảo mật RFC3329 cho Khởi tạo Phiên
1.9: Xác thực1.9.1: Tổng quan 1.9.1: Tổng quan
IMS dựa trên một số quan hệ bảo mật. Hai trong chúng - xác thực giữa người dùng và mạng và SA giữa UE và P-CSCF - có ảnh hưởng đến báo hiệu SIP (Hình 11.4). Xác thực và SA các thủ tục thành lập trong IMS được kết hợp trực tiếp với các thủ tục đăng ký SIP.
Trong ví dụ này, giả định rằng 3GPP AKA được sử dụng để xác thực người sử dụng. Trong Phần 11.16, một ví dụ về xác thực gói GPRS-IMS (GIBA) sẽ là được
cho. Xác thực IMS dựa trên bí mật được chia sẻ và số thứ tự (SQN), chỉ khả dụng trong ứng dụng HSS và ISIM trên mạch tích hợp đa năng Thẻ (UICC) trong UE của Tobias. Vì HSS khơng bao giờ trao đổi trực tiếp với UE, S-CSCF thực hiện các thủ tục xác thực và tất cả các tham số liên quan đến bảo mật mà S-CSCF cần. Cái gọi là Vectơ xác thực (AV) được tải xuống bởi S-CSCF từ HSS trong quá trình đăng ký.
Để xác thực, Tobias gửi danh tính người dùng riêng tư của mình (trong ví dụ là tobias private@home1.fr) trong yêu cầu REGISTER ban đầu. Danh tính người dùng riêng tư này được lưu trữ trong ứng dụng ISIM và chỉ được sử dụng để xác thực và đăng ký các thủ tục.
Hình 1.4 Luồng thơng tin xác thực trong quá trình đăng ký IMS
Khi nhận được yêu cầu ĐĂNG KÝ này, S-CSCF tải AV từ HSS. AV khơng bao gồm bí mật được chia sẻ và bản thân SQN, nhưng bao gồm (trong số các thông số khác):
• một thử thách ngẫu nhiên (RAND);
• kết quả mong đợi (XRES);