1.10 Bảo Mật Truy Cậ p IPsec Sas
1.10.3 Xử Lý Nhiều Bộ SA Trong Trường Hợp Xác Thực Lại
Bây giờ chúng ta đã thấy cách thiết lập tập hợp SA đầu tiên trong quá trình đăng ký ban đầu. Như việc thiết lập một tập hợp các SA dựa trên dữ liệu xác thực được gửi từ S-CSCF trong phản hồi 401 (Unauthorzed), mỗi lần xác thực lại sẽ tạo ra một tập hợp các SA giữa UE và P-CSCF. Quy trình xác thực lại được mô tả trong Phần 11.14. Sau khi xác thực lại thành cơng, UE và P-CSCF sẽ duy trì hai bộ SA (Hình 11.6):
• tập hợp các SA đã được thiết lập và sử dụng trước khi đăng ký lại đã diễn ra, mà bây giờ được gọi là 'tập hợp các SA cũ'
• một tập hợp SA mới được thiết lập dựa trên xác thực lại, hiện được gọi là 'tập hợp SA mới'.
Sự phức tạp chính trong tình huống này là P-CSCF không thể chắc chắn liệu 200 (OK) phản hồi cho yêu cầu RGISTER thứ hai đã được UE của Tobias nhận được, vì SIP xác định khơng có cơ chế xác nhận cho các phản hồi đã nhận cho bất kỳ u cầu nào ngồi một MỜI. Nếu UE khơng nhận được phản hồi 200 (OK) trong giây
REGISTER, sau đó nó sẽ khơng đưa bộ SA mới vào sử dụng. Do đó, nó phải chờ cho đến khi UE gửi một yêu cầu mới về tập hợp các SA mới trước khi có thể đưa chúng vào sử dụng. Điều này có nghĩa là, miễn là P-CSCF khơng nhận được yêu cầu từ UE về bộ SA mới, nó sẽ:
• gửi các yêu cầu đến UE qua tập hợp các SA cũ (tức là từ ứng dụng khách được bảo vệ của nó cổng pc1 đến cổng máy chủ được bảo vệ của UE us1)
• giữ cho cả hai bộ SA hoạt động cho đến khi một hoặc cả hai bộ này hết hạn hoặc có yêu cầu mới từ UE được nhận.
Trong ví dụ, giả định rằng UE đã nhận được 200 (OK) cho yêu cầu REGISTER thứ hai và do đó, biết rằng thủ tục xác thực đã thành cơng và bộ SA mới có thể được sử dụng. Thật khơng may, P-CSCF không biết điều này và sẽ gửi các yêu cầu đến UE qua tập hợp các SA cũ; do đó, UE cũng cần duy trì cả hai bộ SA.
Khi UE cần gửi yêu cầu mới, UE sẽ gửi yêu cầu đó bằng bộ mới của SA, điều này sẽ xác nhận với P-CSCF rằng bộ SA mới có thể được sử dụng đầy đủ sử dụng (Hình 11.7). Hơn nữa, tại thời điểm này, tập hợp các SA cũ sẽ không ngay lập tức rớt xuống, vì UE có thể đã nhận hoặc gửi một yêu cầu qua nó, điều này vẫn chưa trả lời. Do đó,
tập hợp SA cũ được giữ trong 64 3 T1 giây nữa (thường là 128 giây trong mơi trường IMS), trước khi nó bị bỏ.
Cũng lưu ý rằng UE không thể sử dụng bộ SA mới bằng cách gửi phản hồi -ví dụ: phản hồi 200 (OK) - cho một yêu cầu - ví dụ: một yêu cầu MESSAGE - đã được nhận qua tập hợp các SA cũ. UE bị buộc bởi tiêu đề Qua của P-CSCF hoặc do tới một kết nối TCP để gửi phản hồi đến cùng một cổng và qua cùng một tập hợp các SA như yêu cầu đã được nhận.
Hình 1.6 Hai bộ SA trong quá trình xác thực lại
Bất cứ khi nào một tập hợp các SA tạm thời được thiết lập, UE sẽ loại bỏ tất cả các SA khác, so với cái mà nó đã gửi yêu cầu REGISTER cuối cùng. Do đó, UE khơng bao giờ cần xử lý nhiều hơn hai tập hợp SA cùng một lúc.
Trong quá trình xác thực liên tục, thời gian tồn tại của một tập hợp SA tạm thời là
giới hạn trong 4 phút. Điều này đảm bảo rằng thủ tục xác thực có thể được hồn tất. Sau khi xác thực thành công, thời gian tồn tại của bộ SA mới được đặt thành:
• Thời gian hết hạn của đăng ký đã kết thúc cộng thêm 30 giây. Hết hạn thời gian đăng ký được chỉ ra trong tham số hết hạn được trả về trong Tiêu đề liên hệ của phản hồi 200 (OK) cho REGISTER
• Hoặc, nếu một tập hợp SA khác đã tồn tại, đến thời gian tồn tại của tập hợp đã tồn tại đó trong số SA miễn là thời gian tồn tại của nó dài hơn thời gian hết hạn của đăng ký cộng thêm 30 giây.
Hình 1.7 Đưa một nhóm SA mới vào sử dụng và loại bỏ một nhóm SA cũ
Bất cứ khi nào đăng ký lại diễn ra và thành cơng, P-CSCF và UE có để cập nhật thời gian tồn tại của tất cả các SA hiện có với thời gian hết hạn của lần đăng ký lại đã kết thúc cộng thêm 30 giây, nếu giá trị đó lớn hơn thời gian tồn tại đã được chỉ định của SA.
Do đó, SA giữa UE và P-CSCF sẽ được giữ lâu hơn 30 giây hơn Tobias được đăng ký vào mạng IMS. Khi P-CSCF nhận thấy rằng Tobias khơng cịn được đăng ký (ví dụ: bằng cách nhận THƠNG BÁO với thơng tin trạng thái đăng ký của Tobias cho biết
do mạng khởi tạo hủy đăng ký - xem Phần 11.15.3), P-CSCF sẽ loại bỏ tất cả SA về phía UE sau 64 * T1 giây.
1.10.5: Thiết lập cổng và định tuyến
Cần đặc biệt chú ý khi nói đến việc sử dụng các cổng SA, vì chúng ảnh hưởng rất nhiều đến việc định tuyến giữa P-CSCF và UE. Như trong Hình 11.6,
UE của Tobias:
• sẽ gửi tất cả các yêu cầu từ cổng khách hàng được bảo vệ của nó (2468);
• mong đợi tất cả các phản hồi sẽ được nhận trên cổng máy chủ được bảo vệ của nó (1357);
• mong đợi tất cả các yêu cầu sẽ được nhận tại cổng máy chủ được bảo vệ của nó (1357);
• sẽ gửi tất cả các phản hồi cho các yêu cầu nhận được từ cổng khách hàng được bảo vệ của nó (2468).
Mặt khác, P-CSCF:
• sẽ gửi tất cả các yêu cầu tới UE từ cổng khách hàng được bảo vệ của nó (8642); • mong đợi nhận được tất cả các phản hồi từ UE tại cổng máy chủ được bảo vệ của nó (7531);
• mong đợi nhận được tất cả các yêu cầu từ UE tại cổng máy chủ được bảo vệ của nó (7531); và
• sẽ gửi tất cả các phản hồi tới UE từ cổng máy khách được bảo vệ của nó (8642). Để đảm bảo rằng tất cả các yêu cầu đều được gửi qua IPsec SAs:
• UE sẽ đặt cổng máy chủ được bảo vệ như một phần của địa chỉ:
◦ trong tiêu đề Liên hệ của mọi yêu cầu (bao gồm tất cả các yêu cầu REGISTER) ◦ trong tiêu đề Qua của mọi yêu cầu, bên cạnh REGISTER ban đầu.
• UE sẽ đặt cổng máy chủ được bảo vệ của P-CSCF như một phần của proxy gửi đi (tức là P-CSCF) địa chỉ trong tiêu đề Lộ trình của mọi u cầu ban đầu mà nó gửi. • P-CSCF sẽ đặt cổng máy chủ được bảo vệ như một phần của địa chỉ:
◦ trong tiêu đề Record-Route của mọi phản hồi mang P-CSCF’s Mục nhập Record-Route về phía UE (để cài đặt chi tiết số cổng trong Tiêu đề Record-Route xem Phần 12.3.4.3).
1.10.5.1:Thiết lập cổng trong khi đăng ký
Ví dụ: UE của Tobias đăng ký ban đầu với thông tin sau:
REGISTER sip:home1.fr SIP/2.0
Via: sip:[5555:1:2:3:4]:1357;branch=0uetb Route: <sip:[5555::a:b:c:d];lr>
Security-Client: digest, IPsec-3gpp; alg=hmac-sha-1-96 ;spi-c=23456789 ;spi-s=12345678
;port-c=2468; port-s=1357
Contact: "Mobile Phone – Tobias" sip:[5555::1:2:3:4]:1357 Điều này có nghĩa là UE:
• Sẽ thiết lập IPsec SA với:
◦ cổng 2468 làm cổng máy khách được bảo vệ (thông số cổng-c của Máy khách-Bảo mật tiêu đề);
◦ cổng 1357 làm cổng máy chủ được bảo vệ (tham số cổng của Máy khách bảo mật đầu trang).
• Mong đợi tất cả các yêu cầu đến được chuyển đến cổng máy chủ được bảo vệ của nó (giá trị cổng trong tiêu đề Liên hệ);
• Sẽ gửi yêu cầu REGISTER ban đầu này tới cổng 5060 không được bảo vệ của P CSCF, vì khơng có giá trị cổng nào được đưa ra trong tiêu đề Tuyến đường; • Sẽ chờ tất cả các phản hồi cho yêu cầu REGISTER ban đầu này trên cổng 5060 không được bảo vệ, như khơng có giá trị cổng nào được đưa ra trong tiêu đề Via. Phản hồi 401 (Không được phép) mà UE nhận được sau đó sẽ có dạng như thế này: SIP/2.0 401 Unauthorized
Via: sip:[5555:1:2:3:4]:1357;branch=0uetb
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
Điều này có nghĩa là P-CSCF sẽ thiết lập IPsec SA với:
• cổng 8642 làm cổng máy khách được bảo vệ (tham số cổng-c của tiêu đề Máy chủ- Bảo mật)
• cổng 7531 làm cổng máy chủ được bảo vệ (tham số cổng của tiêu đề Máy chủ-Bảo mật).
Sau cuộc trao đổi này, UE và P-CSCF sẽ thiết lập bộ SA tạm thời và UE sau đó sẽ gửi yêu cầu REGISTER thứ hai đã được bảo vệ, sau đó sẽ trơng giống như:
REGISTER sip:home1.fr SIP/2.0
Via: sip:[5555:1:2:3:4]:1357;branch=1uetb Route: <sip:[5555::a:b:c:d]:7531;lr>
Contact: "Mobile Phone – Tobias" sip:[5555::1:2:3:4]:1357
Lưu ý rằng các tiêu đề Security-Client và Security-Verify cũng được bao gồm trong yêu cầu này (xem Phần 1.8), nhưng vì chúng khơng cịn ảnh hưởng đến việc thiết lập SA và định tuyến, chúng khơng được hiển thị ở đây. Điều này có nghĩa là UE: mong đợi tất cả các yêu cầu ban đầu đến sẽ được chuyển đến cổng máy chủ được bảo vệ của nó (giá trị cổng trong tiêu đề Liên hệ);
• gửi yêu cầu REGISTER này đã qua IPsec SA tạm thời (tức là cho người được bảo vệ cổng máy chủ của P-CSCF - giá trị cổng trong tiêu đề Tuyến đường); và
• Mong đợi tất cả các phản hồi cho yêu cầu REGISTER này sẽ được gửi qua IPsec SA tạm thời (nghĩa là trên cổng máy chủ được bảo vệ 1357 - giá trị cổng trong tiêu đề Via).
1.10.5.2:Thiết lập cổng trong khi xác thực lại
Như đã nói trước đây, mỗi lần xác thực lại sẽ tạo ra một cặp IPsec SA mới. Khi nào trao đổi chỉ mục tham số bảo mật và số cổng được bảo vệ cho tập hợp mới của SA theo Thỏa thuận Cơ chế An ninh SIP, chỉ P-CSCF và UE thay đổi các cổng máy khách được bảo vệ của họ:
• UE nhận được yêu cầu và phản hồi cho cả hai tập hợp SA thông qua máy chủ được bảo vệ của nó cổng (us1);
• P-CSCF nhận các yêu cầu và phản hồi cho cả hai nhóm SA thơng qua máy chủ được bảo vệ của nó cổng (ps1);
• P-CSCF cũng sử dụng một cổng máy khách được bảo vệ mới (pc2) để gửi các yêu cầu và phản hồi của UE đối với tập hợp các SA mới. Điều này là do thực tế là hai bộ SA không được sử dụng các tham số cổng giống nhau. Hơn nữa, nếu các cổng máy chủ được bảo vệ thay đổi, điều này sẽ gây ra các vấn đề lớn và có nghĩa là:
• UE sẽ cần thực hiện đăng ký lại, vì địa chỉ liên hệ đã đăng ký của nó bao gồm cổng máy chủ được bảo vệ;
• UE sẽ cần gửi lại INVITE trên tất cả các phiên đã thiết lập, vì thơng tin liên hệ của nó được gửi đến đầu cuối từ xa bao gồm cổng máy chủ được bảo vệ;
• P-CSCF sẽ nhận từ UE tất cả các yêu cầu tiếp theo đối với mọi hộp thoại lished đã được thiết lập (bao gồm tất cả các đăng ký của UE) trên P-CSCF cũ, được bảo vệ cổng máy chủ, vì trong SIP khơng có khả năng thay đổi thông tin tuyến đường cho một hộp thoại đã được thiết lập. Danh sách này khơng đầy đủ, nhưng nó cho thấy rằng việc thay đổi cổng máy chủ được bảo vệ sẽ gây ra rất nhiều vấn đề cho định tuyến SIP. Do đó, điều cốt yếu là giá trị này khơng đã thay đổi miễn là người dùng vẫn đăng ký.
1.10.5.3: Cài đặt cổng cho các yêu cầu SIP ngoài REGISTER
Việc thiết lập các cổng được bảo vệ trong các yêu cầu không REGISTER được mô tả chi tiết hơn trong Phần 3.7.
Hình 1.8 Định tuyến yêu cầu và phản hồi giữa UE và P-CSCF qua TCP 1.10.5.4: Sử dụng các cổng với UDP và TCP
Các phần trước đã cho thấy cách các yêu cầu và phản hồi được chuyển qua một hoặc nhiều tập hợp các SA. Trong ví dụ đã chọn, chỉ UDP được sử dụng làm giao thức truyền tải. Đối với TCP, tuy nhiên, có một chút khác biệt trong các thủ tục này. Khi một yêu cầu được gửi qua UDP (Hình 11.8), tiêu đề Via cho biết địa chỉ IP và số cổng mà tất cả các phản hồi liên quan sẽ được chuyển đến. Khi TCP được sử dụng để gửi u cầu (Hình 11.9) thơng tin trong tiêu đề Via bị ghi đè và phản hồi được chuyển trở lại cùng một địa chỉ và cổng mà yêu cầu đã được nhận. Điều này rút ra chú ý đến bản chất của TCP như một giao thức truyền tải hướng kết nối. Bằng cách áp dụng quy tắc này được đảm bảo rằng không cần mở thêm kết nối TCP nào để gửi phản hồi cho một yêu cầu đã được nhận qua TCP. Điều này gây ra việc định tuyến các bản tin SIP giữa P-CSCF và UE để hoạt động khác nhau. UE sẽ đặt máy chủ được bảo vệ của nó cổng (us1) trong tiêu đề Via của mọi yêu cầu mà nó gửi đi, bất kể UDP có hoặc TCP được sử dụng. Tất cả các yêu cầu sẽ bắt nguồn từ cổng máy khách được bảo vệ của UE (uc1). Trong trường hợp của UDP, các phản hồi cho một yêu cầu như vậy sẽ được gửi đến UE được bảo vệ cổng máy chủ (us1), như được chỉ ra trong tiêu đề Qua. Trong trường hợp TCP, các phản hồi cho một yêu cầu như vậy sẽ được gửi đến UE được bảo vệ cổng máy khách (uc1), vì u cầu bắt nguồn từ đó. Điều này cũng đúng trong cái khác (nghĩa là đối với các yêu cầu được gửi từ P-CSCF tới UE và phản hồi của họ).
1.10.6: Các tiêu chuẩn liên quan
Các thông số kỹ thuật liên quan đến Mục 1.10 là: 3GPP TS 33.102 Kiến trúc bảo mật.
3GPP TS 33.203 Bảo mật truy cập cho các
dịch vụ dựa trên IP.Bảo mật miền mạng 3GPP TS 33.210 (NDS) Bảo mật lớp mạng IP.
RFC2401 Giao thức Internet.
RFC2403 Việc sử dụng HMAC-MD5-96 trong ESP và AH. RFC2404 Việc sử dụng HMAC-SHA-1-96 trong ESP và AH. RFC2451 Các thuật toán mật mã chế độ ESP CBC.
1.11 Đàm phán nén 1.11.1 Tổng quan 1.11.1 Tổng quan
Khả năng nén các bản tin SIP qua giao diện khơng khí là điều cần thiết đối với IMS. Thế nào hoạt động của Nén tín hiệu (SigComp) được mô tả trong Phần 3.18 Phần này cho thấy cách UE và P-CSCF chỉ ra rằng họ hỗ trợ SigComp và cả hai đều sẵn sàng sử dụng nó. P-CSCF và IMS UE phải hỗ trợ SIP SigComp, nhưng chúng khơng bắt buộc để dùng nó. Do đó, họ cần một cơ chế để thể hiện liệu họ có sẵn sàng áp dụng
SigComp. [RFC3486] xác định tham số URI mới ‘comp’, có thể được đặt thành ‘comp = Sig Comp’ bởi UE hoặc proxy SIP (trong trường hợp IMS, điều này chỉ áp dụng cho P-CSCF) để bày tỏ sự sẵn sàng gửi hoặc nhận các thông điệp SIP nhất định bị nén. Tobias’s UE sẽ bày tỏ sự sẵn lòng sử dụng SigComp với P-CSCF đã trong yêu cầu REGISTER ban đầu. P-CSCF sẽ đưa ra một chỉ báo tương tự trong 401 Phản hồi (trái phép). Khi hai bản tin SIP này được gửi đi mà khơng có bất kỳ biện pháp bảo vệ nào, P-CSCF và UE sẽ không tạo trạng thái (ngăn) cho SigComp tại thời điểm này trong thời gian; điều này là để đảm bảo rằng người dùng độc hại - người muốn bắt đầu từ chối dịch vụ (DOS) tấn công chống lại P-CSCF - không thể làm quá tải P-CSCF bằng cách buộc nó phải dự trữ bộ nhớ cho một số lượng lớn các ngăn SigComp không cần