HTTP Authentication SIP provides a stateless, trial-and-error mechanism for the authentication system. This mechanism is based on HTTP authentication. At any time, the proxy server or UA receives a request (except in section 22.1), which attempts to check the identity confirmation provided by the request initiator. When the sender confirms the identity, the request recipient should confirm whether the user has been authenticated. In this document, it is not recommended or discussed about the authentication system. The "Digest" authentication mechanism described in this section only provides message authentication and review protection, and does not provide message integrity or confidentiality assurance. The preceding protection level and digest-based protection can prevent sip attackers from modifying SIP requests and responses. Note that due to this fragile security, we do not agree with the "Basic" authentication method. The server must not receive trust books of the "Basic" type in the authentication method, and the server must reject the "Basic" type ". This is a change with rfc2543. The framework for SIP authentication is very similar to HTTP (rfc2617 [17]). In particular, Auth-scheme's BNF paradigm, Auth-Param, challenge, realm, realm-value, and trust books are the same (although the "Basic" authentication scheme is not allowed ). In sip, UAS uses the 401 (unauthorized) Response to reject the UAC identity (or test the UAC identity, if it fails, it is 401 ). In addition, on the registration server, the forwarding server can use 401 (unauthorized) to respond to identity authentication, but the proxy must not use 401, and can only use 407 (proxy authentication required) to respond. Proxy-authroization, www-authenticate, and authorization are the same in different messages, as described in rfc2617 [17. Because SIP does not have a standard root URL concept, the concepts of the space to be protected are also explained in SIP. The realm string separately defines the protected region. This is a change with rfc2543. In 2543, request-Uri and realm define protected areas. This previously defined protected region back causes a certain degree of confusion, because the request-Uri is sent by UAC and the authentication server that receives the request-URI may be different, in addition, the real final request-Uri format may not be known to UAC. Similarly, earlier definitions depend on the sip uri in a request-Uri, and it seems that other URI schemes (such as Tel URL) are not allowed) the UA user or proxy server that needs to identify the received request must follow the instructions below to create a realm string for their server. The O realm string must be globally unique. We stress that this realm string must contain a host name or domain name. The recommended o realm string following section 3.2.1 or rfc2617 [17] should be a readable string that can be displayed to the user. Example: Invite SIP: bob@biloxi.com Sip/2.0 authorization: Digest realm = "biloxi.com", <…> Generally, SIP authentication is meaningful for a specific realm (a protected area. Therefore, for digest authentication, each similar protection area has its own user name and password set. If the server does not require authentication for a specific request, it can receive the default username "anonymous", and this username does not have a password (the password is ""). Similarly, the UAC that represents multiple users, such as the PSTN gateway, can have their own device-related user names and passwords, rather than each user name and one user name and password (that is, such as the gateway, there is a gateway user and password, rather than every actual user and password through the gateway ). When the server can correctly process the vast majority of SIP requests, this document stipulates that two types of requests require special authentication processing: ACK and cancel. In a certain authentication scheme, and this authentication scheme uses the response to place the calculation nonces (such as Digest), problems may occur in some situations where no response is received, such as ack. Therefore, for this reason, a server must also receive the corresponding ack trust book to accept the trust book in the invite request. UAC creates an ACK message by assigning the authorization and proxy-Authorization header values in all invite requests. The server must receive this ack request. Although the cancel method has a response (2XX), the server must not reject cancel requests because these requests cannot be resubmitted. Generally, if the cancel request and the cancel request come from the same node (assuming a communication protocol or the network layer has a security relationship described in section 26.2.1), the server should receive the cancel request. When the UAC receives a verification rejection and the UAC device does not know the specific cause of the Realm verification failure, it must be displayed to the user, the content of the "Realm" parameter that fails verification (either in the WWW-Authenticate header domain or the proxy-Authenticate header domain ). For a trusted UA service provider configured in advance for realm, you should note that when a device with a trusted configuration is rejected, users will not have the opportunity to show their trust in this realm. Finally, even if a UAC can locate a trust book that matches the relevant realm, the trust book may not be valid, or why a server does not accept this trust book (especially when a "anonymous" user without a password is provided ). In this case, the server may continue to reject the request or return a 403 Forbidden error. UAC must not try again using the rejected trust book (if the current environment has not changed, the request can be tried again ). User-to-user authentication. When a UAS receives a request initiated by a UAC, the UAS performs identity authentication before the request is processed. If the request does not contain a trust book (in the Authorization Header domain), UAS can use 401 (unauthorized) to reject authentication and ask the client to provide a certificate. The WWW-authenticate Response Header must appear in the 401 (unauthorized) Response Message. This header field value contains at least one reason for rejecting the authentication method and applicable realm parameters. Example of WWW-Authenticate header domain in 401: www-Authenticate: Digest, realm = "biloxi.com", qop = "auth, Auth-int", Nonce = "signature ", opaque = "5ccc069c403ebaf9f0171e9517f40e41" when the original request UAC receives the 401 (unauthorized) response, if possible, it should re-organize the request and fill in the correct trust book. Before proceeding, the UAC may require the original user to enter the trust book. Once the trust book (whether user input or internal key) is provided, UA should cache the trust book for the specific to header domain and "Realm" field, for use in the next request to this address. UA can cache this trust book in any way. If the trust book corresponding to realm is not found, UAC should try the request again with the user "anonymous" and an empty password. Once a trust book is found, the UA should require that you authenticate yourself on the UAS or registration server. This is a common situation, but it is not necessarily required that you receive a 401 (unauthorized) certificate) after the response-you can add an Authorization Header domain in the request and then authenticate it. The Authorization header field contains the trust of the Realm (region) in which the UA to the requested resource is located, the required authentication supported parameters, and the reproduction protected parameters. Authorization Header example: Authorization: Digest username = "Bob", realm = "biloxi.com", Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", uri = "SIP: bob@biloxi.com", qop =, auth, NC = 00000001, cnonce = "0a4f113b", response = "canonical", opaque = "canonical" when the UAC receives a 401 (unauthorized) or 407 (proxyauthenticationrequired) response, re-use its trust book to submit a request. It must increase the value of the CSeq Header domain, just like sending a normal new request. Similar to user authentication, when UAC sends a request to the proxy server, the proxy server can verify the authentication of the original request before processing the request. If the request does not contain a trust book (in the proxy-Authorization Header domain), the proxy can use 407 (proxy authentication required) to reject the original request and require the client to provide the appropriate trust book. The proxy must add a proxy-Authenticate header field in the 407 (proxyauthenticationrequired) response and provide the authentication resources suitable for this proxy in this header domain. Proxy-Authenticate and proxy-authorization are described in [17]. The two are different. The proxy cannot add value in the proxy-Authorization header. All 407 (proxyauthenticationrequired) responses must be forwarded to the uplink queue and sent to UAC following the send response steps. UAC is responsible for adding the realm trust book that applies to the proxy that requires authentication in the proxy-Authorization header field value. If the proxy requires UAC to add the proxy-Authorization Header domain in the request and resubmit the request, UAC should increase the value of the CSeq Header domain, just like a new request. However, the UAC that submits the original request needs to ignore the UAS response, because the CSeq value may be different. When the UAC of the original request receives a 407 (proxy authentication required), if possible, it should re-organize the request using the correct trust book. It should display and process the "Realm" parameter like the processing steps for the 401 response described in the front. If the corresponding realm trust book is not found, UAC should try again with the user "anonymous" and empty password. UAC should also cache this trust book in the resend request. We recommend that you use the following steps to cache a proxy trust book: If the UA receives a proxy-Authenticate header field in the 401/407 response to a request for a specific call-ID, it should combine the trust books on the realm and send the trust books for future requests with the same call-id. These trust books must be cached in the dialog; however, if the UA is configured with its own local external proxy, if authentication is required, the UA should cache the trust books for cross-conversation. Note: this means that a request in a dialog can contain a trust book that is not required by the proxy in the Route Header domain. Any UA that you want to authenticate on the proxy server-typically, but not necessarily, in receiving 407 (proxy authentication required) after the response-you can add a proxy-Authorization header in the request and try again. The proxy-authorization request header allows the client to prove its identity (or user) Like a proxy. The proxy-Authorization header contains a trust book that UA provides to the proxy and/or the realm identity authentication information of the requested resource source. A proxy-Authorization header field value is only provided to the specified proxy for verification, the realm of this proxy is specified in the "Realm" parameter (this proxy can request Authentication through the proxy-authenticat header domain in advance ). When multiple proxies form a link, if the proxy's realm does not match the "Realm" parameter of the proxy-Authorization header in the request, therefore, this proxy cannot use the proxy-Authorization Header Domain value for verification. NOTE: If an authentication mechanism does not support realm of the proxy-Authorization Header domain, the porxy server must analyze all the proxy-Authorization Header domain values to determine whether one of them has a trusted book that the proxy deems appropriate. Because this method takes a lot of time on a large network, the proxy server should use a realm authentication solution that supports the proxy-Authorization Header domain. If a request is distributed (see section 16.7), the same UAC may have different proxy servers and/or UA requests for authentication. In this case, the proxy server of the branch has the responsibility to combine the rejected authentication into a response. The WWW-Authenticate and proxy-Authenticate header domain values received by each branch request must be placed by this branch proxy in the same response and sent to the UA; the order of these header domain values does not affect. When the proxy server sends a denial of authentication response to a request, the request will not be forwarded until the UAC re-sends the request with the correct trust book. The branch proxy can forward requests to multiple proxy servers that require authentication at the same time. Each proxy will not forward this request before it receives the UAC authentication of their respective realm. If the UAC does not provide trust books for these failed verifications, the proxies that refuse to pass the authentication will not forward the request to the target user of the UA. Therefore, branch has fewer advantages. When you reply to a resubmit request for 401 (unauthorized) or 407 (proxy authentication required) that contains multiple denied authentication, UAC shall provide a letter for each www-Authenticate and proxy-Authorization header value. According to the preceding description, multiple authentication certificates in a request must be separated by the "Realm" parameter. However, in the same 401 (unauthorized) or 407 (proxy authentication required) response, it may contain multiple verification denied for the same realm. For example, when multiple proxies in the same domain use a common realm and receive a request from a branch, and the authentication is rejected, this is the case. When UAC tries this request again, UAC will provide multiple authorization or proxy-Authorization header fields, including the same "Realm" parameter. And the same realm should have the same trust book. The Digest authentication solution describes how to modify and simplify the HTTP digest authentication scheme. SIP uses almost the same solution as HTTP [17. Because RFC 2543 is based on the HTTP digest defined in rfc2069 [39], SIP servers supporting rfc2617 must also be compatible with rfc2069. Rfc2617 defines steps to ensure compatibility. Note: The SIP server must not receive or send basic authentication requests. The Digest authentication rules are defined in [17]. They only use "Sip/2.0" to replace "HTTP/1.1", and the following differences exist: 1. Uri has the following BNF: uri = SIP-URI/SIPS-URI2, In the RFC 2617 definition, there is an error with the HTTP digest-certified Authorization header field "Uri" parameter, which is an error Without parentheses pairing. (The example in section 3.5 of rfc2617 is correct ). For sip, The 'uri 'parameter must be enclosed in quotation marks. 3. The BNF of digest-Uri-value is: Digest-Uri-value = request-Uri; defined in section 25. 4. For sip, The etag-based nonce step examples are not applicable. 5. For sip, rfc2617 [17] does not apply to chache operations. 6. rfc2617 [17] requires the server to check the URI of the request line, and the URI in the Authorization Header domain must point to the same resource. In sip, these two Uris can be directed to different users because they are forwarded by the same proxy. Therefore, in SIP, a server should check whether the request-URI in the Authorization header value is consistent with the user who wants to receive the request, but if the two are inconsistent, there is no need to display the error. 7. In the digest authentication scheme, a clarification on calculating the A2 value of message integrity assurance should be made to assume that when the package body is empty (that is, when the SIP message does not contain a packet body, an m5hash empty string should be generated for the hash value of the packet body, or: H (entity-body) = MD5 ("") = "d41d8cd98f00b204e9800998ecf8427e" 8. rfc2617 indicates that the cnonce value cannot appear in the authorization (and extended proxy-authorization) header domain without the qop parameter. Therefore, any computation based on cnonce (including the "MD5-Sess") requires that the qop index be sent first. The "qop" parameter in rfc2617 is optional to be backward compatible with rfc2069. Because rfc2543 is based on rfc2069, the "qop" parameter must still exist as an optional parameter by the customer and server. However, the server must always transmit the "qop" parameter in the WWW-Authentication and proxy-Authenticate header values. If a client receives a "qop" parameter in a denial of authentication response, it must put this "qop" parameter in the subsequent Authentication Header domain.
RFC 2543 does not allow the use of the authentication-Info header field (used in rfc2069 ). However, we are now allowed to use this header field because it provides packet body Integrity Detection and mutual authentication. Rfc2617 [17] defines the backward compatible mechanism for using the qop attribute in requests. These mechanisms must be used on the server to check whether the customer supports rfc2617. The new mechanism is not defined in rfc2069.
