1.8 Thỏa Thuận Cơ Chế Bảo Mật SIP
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
;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ẽ luôn 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
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ó yê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
Ngoà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 đó.
T 7
Hình 1.3 Sip-Sec-Agree trong quá 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
2 9
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); • mã xác thực mạng (AUTN); • Khóa toàn vẹn (IK)
3 0
• Khóa mật mã (CK)
Để xác thực, S-CSCF từ chối yêu cầu REGISTER ban đầu từ người dùng có phản hồi 401 (Unauthorized), bao gồm (trong số các tham số khác) RAND, AUTN, IK và CK.
P-CSCF, khi nhận được phản hồi 401 (Unauthirized), loại bỏ IK và CK từ phản hồi trước khi gửi đến UE. IK là cơ sở cho các SA nhận được được thiết lập giữa P-CSCF và UE ngay sau đó (xem Phần 11.7).
Sau khi nhận được phản hồi, UE chuyển giao các tham số nhận được cho ISIM ứng dụng, mà:
• Xác minh AUTN dựa trên bí mật được chia sẻ và SQN - khi xác minh AUTN thành công mạng được xác thực (tức là, UE có thể chắc chắn rằng xác thực dữ liệu đã được nhận từ mạng của nhà điều hành gia đình);
• Tính toán kết quả (RES) dựa trên bí mật được chia sẻ và RAND nhận được;
• Tính toán IK, sau đó được chia sẻ giữa P-CSCF và UE và sẽ phân phát làm cơ sở cho SA
Sau đó, UE gửi phản hồi thử thách xác thực (RES) trong giây REGISTER yêu cầu trở lại S-CSCF, so sánh nó với XRES đã nhận được trong AV từ HSS. Nếu xác minh thành công, S-CSCF sẽ xử lý người dùng được xác thực và sẽ thực hiện các thủ tục đăng ký SIP (xem Phần 11.5.6). Bất cứ khi nào UE gửi một yêu cầu REGISTER khác (tức là do hủy đăng ký), nó sẽ luôn bao gồm các thông số xác thực giống như được bao gồm trong yêu cầu REGISTER thứ hai, cho đến khi S-CSCF xác thực lại UE.
1.9.2: Thông báo HTTP và 3GPP AKA
Thông báo về Giao thức truyền siêu văn bản (HTTP) được chỉ định trong [RFC2617] và cách nó được sử dụng với SIP được mô tả trong [RFC3261]. Ngược lại, IMS là một phần của Dự án Đối tác Thế hệ Thứ ba / Hệ thống Viễn thông Di động Toàn cầu Kiến trúc (3GPP / UMTS), sử dụng Thỏa thuận khóa và xác thực 3GPP (AKA) cơ chế xác thực.
Để đạt được xác thực dựa trên 3GPP AKA trong IMS, [RFC3310] xác định cách các thông số 3GPP AKA (như mô tả ở trên) có thể được ánh xạ tới xác thực thông báo HTTP. Do đó, các phần tử báo hiệu (tiêu đề SIP và các tham số) được sử dụng để vận chuyển Thông tin 3GPP AKA giống với thông tin được sử dụng cho thông báo HTTP. Tuy nhiên, ý nghĩa của chúng (nghĩa là cách diễn giải của chúng tại UE, P-CSCF và S- CSCF) là khác nhau. Để phân biệt cơ chế xác thực 3GPP AKA với các HTTP khác cơ chế thông báo (ví dụ: MD5), nó đã được cấp một giá trị thuật toán mới: “AKAv1- MD5”.
3 1
1.9.3: Thông tin xác thực trong yêu cầu REGISTER ban đầu
Trong yêu cầu REGISTER ban đầu, UE của Tobias sử dụng tiêu đề Ủy quyền thông báo HTTP để vận chuyển danh tính người dùng riêng tư của Tobias. Để hoàn thành thông báo HTTP yêu cầu, UE bao gồm các trường sau trong tiêu đề Ủy quyền:
• Lược đồ xác thực - được đặt thành giá trị "Digest", vì 3GPP AKA được ánh xạ tới cơ chế thông báo HTTP;
• Trường tên người dùng - được đặt thành danh tính người dùng riêng tư của Tobias, sẽ được sử dụng bởi S-CSCF và HSS để xác định người dùng và tìm AV tương ứng; • Các lĩnh vực và trường URI - được đặt thành miền chính của Tobias;
• Trường phản hồi và trường nonce - được để trống. Các trường này được ủy quyền bởi thông báo HTTP, nhưng không được sử dụng trong yêu cầu REGISTER ban đầu. REGISTER bây giờ trông giống như:
REGISTER sip:home1.fr SIP/2.0
Authorization: Digest username="tobias private@home1.fr", realm="home1.fr",
nonce="",
uri="sip:home1.fr", response=""
Vì UE và P-CSCF không thiết lập bất kỳ loại cơ chế bảo mật lẫn nhau nào tại mức báo hiệu SIP, P-CSCF không thể đảm bảo rằng yêu cầu REGISTER thực sự bắt nguồn từ Tobias: ví dụ: một người dùng độc hại có thể đã xây dựng yêu cầu và gửi nó đến P- CSCF mà P-CSCF không biết. Do đó, P-CSCF thêm trường được bảo vệ toàn vẹn với giá trị "no" vào tiêu đề Ủy quyền, trước đó gửi yêu cầu tới mạng gia đình của Tobias:
REGISTER sip:home1.fr SIP/2.0
Authorization: Digest username="tobiasprivate@home1.fr", realm="home1.fr", nonce="", uri="sip:home1.fr", response="", integrity-protected= "no" 1.9.4: S-CSCF thử thách UE
Dựa trên dữ liệu trong AV, nó trả về tiêu đề WWW-Authenticate trong phản hồi 401 (Unauthorized) và điền vào các trường của nó như sau:
3 2
• Trong trường nonce, nó có các tham số RAND và AUTN, có trong SlP-Xác thực AVP trong MAA. Cả hai giá trị đều dài 32 byte và được mã hóa cơ sở 64 (trường nonce có thể bao gồm dữ liệu bổ sung dành riêng cho máy chủ);
• Trong trường thuật toán, nó có giá trị ‘AKAv1-MD5’, vì nó đã có trong SIP - Authentication-Scheme AVP trong MAA và xác định cơ chế 3GPP AKA
• Trong các trường mở rộng IK và CK, nó có các khóa toàn vẹn và mật mã, như chúng đã từng trình bày trong AVP Khóa bảo mật và Khóa toàn vẹn-Khóa trong MAA. Lưu ý rằng những hai trường không phải là một phần của định nghĩa ban đầu của tiêu đề WWW-Authenticate, được định nghĩa trong [RFC3261]. Các trường này được định nghĩa trong [3GPP TS 24.229].
Các trường WWW-Authenticate có dạng như sau:
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="home1.fr",
nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAv1-MD5, ik="0123456789abcdeedcba9876543210",
ck="9876543210abcdeedcba0123456789 "
Sau khi nhận được phản hồi 401 (UNAUTHORIZED), P-CSCF phải xóa và lưu trữ các trường IK và CK từ tiêu đề WWW-Authenticate, trước khi gửi phản hồi tới UE:
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="home1.fr",
nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAv1-MD5
1.9.5: Phản ứng của UE đối với thách thức
Từ thông số AUTN đã nhận, ứng dụng ISIM trong UE của Tobias giờ đây phát hiện ra rằng chính mạng nhà điều hành gia đình của Tobias đã gửi số 401 (Unauthorized) phản ứng. Nó cũng có thể xuất phát từ AUTN mà SQN (số thứ tự) vẫn ở trong đồng bộ giữa HSS và ISIM. Các tham số nhận được cũng như bí mật được chia sẻ cho phép ISIM tạo ra các giá trị cho phản hồi và chuyển giao chúng cho UE. UE thêm tiêu đề Ủy quyền vào yêu cầu REGISTER thứ hai, bao gồm (trong số các yêu cầu khác) sau lĩnh vực:
• Trường tên người dùng - bao gồm danh tính người dùng riêng tư của Tobias; • Trường nonce - được trả về cùng giá trị với giá trị đã được nhận trong WWW-Tiêu đề xác thực của phản hồi 401 (Không được phép);
• Trường phản hồi - bao gồm RES thử thách xác thực được tạo ra bởi ISIM từ RAND đã nhận và bí mật được chia sẻ.
3 3
ISIM cũng sẽ tính toán IK, còn được gọi là P-CSCF. Dựa vào cái này khóa (và thông tin khác - xem Phần 11.7) UE và P-CSCF thiết lập Ipsec SAs, qua đó UE gửi yêu cầu REGISTER thứ hai:
REGISTER sip: home1.fr SIP / 2.0
Ủy quyền: Digest username = "user1 private@home1.fr", Realm = "home1.fr",
nonce = A34Cm + Fva37UYWpGNB34JP, thuật toán = AKAv1-MD5, uri = "sip: home1.fr",
response = "6629fae49393a05397450978507c4ef1"
1.9.6: Bảo vệ tính toàn vẹn và xác thực thành công
P-CSCF hiện đang ở vị trí để khám phá xem liệu yêu cầu REGISTER đã nhận được hay không đã được sửa đổi trên đường từ UE sang P-CSCF, vì giờ đây nó có thể kiểm tra tính toàn vẹn của nó. Nếu kiểm tra này thành công, P-CSCF sẽ thêm trường 'được bảo vệ toàn vẹn' với giá trị "Có" đối với tiêu đề Ủy quyền và gửi yêu cầu REGISTER đến nhà của Tobias mạng:
REGISTER sip: home1.fr SIP / 2.0
Ủy quyền: Digest username = "user1 private@home1.fr", realm = "home1.fr",
nonce = A34Cm + Fva37UYWpGNB34JP, thuật toán = AKAv1-MD5, uri = "sip: home1.fr",
response = "6629fae49393a05397450978507c4ef1", integrity-protected= "yes
S-CSCF hiện so sánh RES nhận được từ UE và XRES đã bao gồm trong AVP cấp phép SIP của AV đã nhận được trong MAA từ HSS. Nếu hai tham số này giống hệt nhau thì S-CSCF đã xác thực thành công người dùng. Chỉ sau đó, nó sẽ tiến hành các thủ tục đăng ký SIP bình thường.
1.9.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.9 là: 3GPP TS 33.102 Kiến trúc bảo mật.
3 4
3GPP TS 33.203 Bảo mật truy cập cho các dịch vụ dựa trên IP.