3.1.5.1 Overview of Authentication Protocol Elements
The server issues an authentication challenge by using either a 401 or 407 response to a SIP request. The client SHOULD be capable of processing either response. The server uses the following SIP headers as part of this authentication scheme.
|
SIP header |
Purpose |
Where used |
|---|---|---|
|
Date |
Indicates current server time. Used by the client to detect clock skew, which can cause authentication to fail. Client and server clocks must be synchronized to within 15 minutes for the NTLM Authentication Protocol and to within 5 minutes for Kerberos. |
401 or 407 response |
|
Proxy-Authenticate |
Carries the challenge issued by a proxy. One for each authentication scheme (NTLM and Kerberos) that the proxy supports. |
407 response |
|
Proxy-Authentication-Info |
Carries the proxy signature for a message. |
Authenticated SIP message |
|
Proxy-Authorization |
Allows the client to identify itself (or its user) to a proxy that requires authentication. Carries the client response to challenge as well as the signature for the message. |
|
|
WWW-Authenticate |
Carries the challenge issued by a server. One for each authentication scheme (NTLM and Kerberos) that the server supports. |
401 response |
|
Authentication-Info |
Carries the server signature for a message. |
Authenticated SIP message |
|
Authorization |
Allows the client to identify itself (or its user) to a server that requires authentication. Carries the client response to challenge as well as the signature for the message. One for each SA that the client has established with the server. |
SIP message |
The protocol information that is used during the SA establishment phase differs from the information that is used after an SA is established. During the establishment phase, the gssapi-data parameter carries the bulk of the credential information. The realm parameter provides additional context information.
After an SA is established, the srand, crand, cnum, snum, and opaque parameters are used in the signing of requests and responses. Those signatures are carried in the response and rspauth parameters. Parameter values are never escaped, and parameter names are case-insensitive. The order of parameters in a header is not significant.
The following table gives an overview of the parameters used in Proxy-Authenticate, Proxy-Authorization, and Proxy-Authentication-Info headers in the SIP messages. The "When" column indicates the phase in which the parameter is used: Establishment or Signing.
|
Parameter |
Where |
Creator |
When |
Used for |
|---|---|---|---|---|
|
realm |
Authenticate Authorization Auth Info |
Server |
ES |
Identifies which set of credentials the user supplies. Also used by the client to determine which SA is used to sign a message. The realm value is case-sensitive. The default value is "SIP Communications Service". |
|
epid |
From |
Client |
ES |
Identifies a unique endpoint for the user. Used by the server to determine the correct SA to use for signing an outgoing response. An epid MUST be present. |
|
epid |
To |
Server |
ES |
Identifies a unique endpoint for the user. Used by the server to determine the correct SA to use for signing an outgoing request. An epid MUST be present. |
|
targetname |
Authenticate Authorization Auth Info |
Server |
ES |
Identifies the server for this SA. Contains the FQDN of the server for NTLM and the service principal name (SPN) of the server for Kerberos. |
|
opaque |
Authenticate Authorization Auth Info |
Server |
ES |
Identifies the SA on the server. |
|
qop |
Authenticate Authorization Auth Info |
Client Server |
ES |
Quality of Protection (auth only, no integrity protection). |
|
crand |
Authorization |
Client |
S |
Identifies the salt that is used in the signature. An 8-character hexadecimal digit string. |
|
crum |
Authorization |
Client |
S |
Identifies the sequence number that is used in the signature for replay protection. A 32-bit unsigned value that starts at 1. |
|
srand |
Auth Info |
Server |
S |
Identifies the salt that is used in the signature. An 8-character hexadecimal digit string. |
|
snum |
Auth Info |
Server |
S |
Identifies the sequence number that is used in the signature for replay protection. A 32-bit unsigned number that starts at 1. |
|
gssapi-data |
Authenticate Authorization |
Client Server |
E |
Exchanges credential information for establishing an SA. |
|
response |
Authorization |
Client |
S |
Carries the client signature. |
|
rspauth |
Auth Info |
Server |
S |
Carries the server signature. |
For each SA, the client MUST keep track of the snum values that are used by the server when signing messages with this SA. The client also tracks the last snum value that is received for this SA. The client MUST maintain a sliding window to track the snum values that are used by the server for this SA. The initial range of this window is 1 to 256, and is adjusted as messages are received. (The size of this window is 256.) This means that the server can issue as many as 256 simultaneous requests before waiting for a response from the client. The purpose of maintaining this sliding window is to provide replay protection while allowing pipelining of requests for performance reasons.
When a signed message arrives at the client, the client MUST validate the signature and extract the snum value:
If the snum value is higher than the last snum received, the client shifts the window up so that the window now spans from [snum – 256 to snum]. The client also marks this snum as having been used.
If the snum value is lower than the last snum received and is within the active window, the client checks whether this value has been seen before. Previously seen values are rejected as a replay. Replayed requests and responses are dropped. New values are marked as having been used.
If the snum value is lower than the last snum received and is outside the active window, the client MUST drop the message.