SIP Authentication for Linux

SIP Authentication for Linux

linux sip client digest authentication used to authenticate clients.  Digest authentication is a simple authentication mechanism originally developed for HTTP (often called HTTP digest).  The authentication mechanism is very simple, is based on cryptographic hashes that keep sending the users password in clear text.

 Digest authentication verifies that the two communicating parties know a shared secret, which is the password.  When a server wants to authenticate a user, generates a digest challenge and sends it to the user.  An example of a challenge can be:
  Digest realm = "iptel.org", qop = "auth, auth-int"
  nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque = "", algorithm = MD5

 Is a series of parameters that are sent to the user.  The user then uses the parameters to generate a proper digest response and send to the server.  Digest challenge parameters are:
1. realm: This is a required parameter and must be present in all challenges.  Its purpose is to identify credentials within a SIP message.  This is usually the domain from which the SIP proxy server is responsible.
2. nonce: a string of data generated only every time a server generates a digest challenge.  It is constructed from MD5 hash of some data.  This information usually includes a time stamp and the passphrase (password) that has the server.  This ensures that each nonce has a limited lifetime (which can not be used again later) and is also unique (no other server will be able to generate the same nonce).  Customers digest response generated from the nonce and the server will receive the contents of the digest nonce in a response.  Typically verifies the validity of the nonce before it checks the rest of the digest response.  So, the nonce is a type of identifier that ensures that received digest credentials have actually been generated for a particular digest challenge, and also limits the lifetime of the response digest, avoiding the re-launch attacks the future.
3. opaque: it is a string of data that is sent to you in the challenge.  You will pass the string data back to the server in response digest.  This allows servers do not maintain state information.  If any state they need to maintain between challenge and response, can pass it to the client using this parameter and read it again later when the digest response comes.
4. algorithm: the algorithm used to calculate hashes.  Only MD5 is supported.
5. qop: the protection of quality.  Specifies which supports protection schemes server.  The client will choose an option from the list.  The value "auth" indicates authentication only, the value "auth-int" indicates authentication with integrity protection.

 After receiving the digest challenge, a user agent will ask the user for username and password (if not preconfgurado) will generate the digest response and send to the server.  A digest response could be:
  Digest username = "jan", realm = "iptel.org"
  nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", uri = "sip: iptel.org"
  qop = auth, nc = 00000001, cnonce = "0a4f113b"
  response = "6629fae49393a05397450978507c4ef1", opaque = ""

 As we can see, the answer is similar to desadío digest digest.  Matching parameters have the same meaning as in the digest challenge.  We will briefly describe only the following parameters:
 uri: uri contains the client wants to access.
 qop: the level of protection chosen by the customer.
 nc: nonce counter, the counter value is the hexadecimal number of requests (including the current request) that the client has sent with the nonce in its request.  For example, in the first request sent in response to a given nonce, the client sends "nc = 00000001".  The purpose of this directive is to allow the server to detect replay requests for maintaining its own copy of this counter.
 cnonce: the value is a string provided by the client and used by both the client and the server to avoid chosen plaintext attacks, to provide mutual authentication and integrity protection of the message.
 response: a string generated by the user agent (client) that proves the user knows the password.

 Since receiving a digest response, the server recalculates the value of the response to compare, using the attributes that gives the client and the password stored on the server.  If the result is identical to the response received from the client then the client is authenticated.

 When a SIP server receives a SIP request and want to verify the authenticity of the user before processing the requests, checks if the request contains digest credentials.  If no credentials in the SIP request will generate a negative final response and include digest challenge in the response.

 When the client receives the response containing the digest challenge, you must calculate the proper digest response and send the request again, this time including the digest credentials.  The server then verifies the digest response and processes the request was successful.  SIP user agents use the answer "401 Unauthorized" to include the digest challenge.