Copyright © 2002, 2003 FhG FOKUS
Copyright © 2005 voice-system.ro
| Revision History | |
|---|---|
| Revision $Revision: 4594 $ | $Date: 2008-08-06 12:08:33 +0200 (Wed, 06 Aug 2008) $ |
Table of Contents
List of Examples
username_spec parameter usagepassword_spec parameter usagecalculate_ha1 parameter usagenonce_reuse parameter usagepv_www_authorize
usageThis is a module that provides common functions that are needed by other authentication related modules. Also, it can perform authentication taking username and password from pseudo-variables.
The authentication mechanism offers protection against sniffing intrusion. The module generates and verifies the nonces so that they can be used only once (in an auth response). This is done by having a lifetime value and an index associated with every nonce. Using only an expiration value is not good enough because,as this value has to be of few tens of seconds, it is possible for someone to sniff on the network, get the credentials and then reuse them in another packet with which to register a different contact or make calls using the others's account. The index ensures that this will never be possible since it is generated as unique through the lifetime of the nonce.
The default limit for the requests that can be authenticated is 100000 in 30 seconds. If you wish to adjust this you can decrease the lifetime of a nonce( how much time to wait for a reply to a challenge). However, be aware not to set it to a too small value.
The module depends on the following modules (in the other words the listed modules must be loaded before this module):
sl -- Stateless replies
pv -- Pseudo-variables
Secret phrase used to calculate the nonce value.
The default is to use a random value generated from the random source in the core.
If you use multiple servers in your installation, and would like to authenticate on the second server against the nonce generated at the first one its necessary to explicitly set the secret to the same value on all servers. However, the use of a shared (and fixed) secret as nonce is insecure, much better is to stay with the default. Any clients should send the reply to the server that issued the request.
Nonces have limited lifetime. After a given period of time nonces
will be considered invalid. This is to protect replay attacks.
Credentials containing a stale nonce will be not authorized, but the
user agent will be challenged again. This time the challenge will
contain stale parameter which will indicate to the
client that it doesn't have to disturb user by asking for username
and password, it can recalculate credentials using existing username
and password.
The value is in seconds and default value is 30 seconds.
Example 1.2. nonce_expire parameter example
modparam("auth", "nonce_expire", 15) # Set nonce_expire to 15s
Prefix to be added to Remote-Party-ID header field just before the URI returned from either radius or database.
Default value is “”.
Suffix to be added to Remote-Party-ID header field after the URI returned from either radius or database.
Default value is “;party=calling;id-type=subscriber;screen=yes”.
Prefix to be automatically strip from realm. As an alternative to SRV records (not all SIP clients support SRV lookup), a subdomain of the master domain can be defined for SIP purposes (like sip.mydomain.net pointing to same IP address as the SRV record for mydomain.net). By ignoring the realm_prefix “sip.”, at authentication, sip.mydomain.net will be equivalent to mydomain.net .
Default value is empty string.
Full AVP specification for the AVP which stores the RPID value. It used to transport the RPID value from authentication backend modules (auth_db or auth_radius) or from script to the auth function append_rpid_hf and is_rpid_user_e164.
If defined to NULL string, all RPID functions will fail at runtime.
Default value is “$avp(s:rpid)”.
This name of the pseudo-variable that will hold the username.
Default value is “NULL”.
This name of the pseudo-variable that will hold the password.
Default value is “NULL”.
This parameter tells the server whether it should expect plaintext passwords in the pseudo-variable or a pre-calculated HA1 string.
If the parameter is set to 1 then the server will assume that the “password_spec” pseudo-variable contains plaintext passwords and it will calculate HA1 strings on the fly. If the parameter is set to 0 then the server assumes the pseudo-variable contains the HA1 strings directly and will not calculate them.
Default value of this parameter is 0.
Since version 1.4.0, the module checks if the nonce value is re-used, enhancing security protection against reply and man in the middle attacks. This check is done by default.
If the parameter is set to 1 then the nonce reuse checking is disabled, offering compatibility with previous behavior. Not recommended though, this functionality is still good in some scenarios, specially when registration time is very low to deal with NAT traversal.
Default value of this parameter is 0 (protect against nonce reuse).
The function challenges a user agent. It will generate a WWW-Authorize header field containing a digest challenge, it will put the header field into a response generated from the request the server is processing and send the reply. Upon reception of such a reply the user agent should compute credentials and retry the request. For more information regarding digest authentication see RFC2617.
In case the reply cannot be sent, this method returns "-1"; in case a reply was sent, it just terminates further script processing.
Meaning of the parameters is as follows:
realm - Realm is a opaque string that the user agent should present to the user so he can decide what username and password to use. Usually this is domain of the host the server is running on.
If an empty string “” is used then the server will generate it from the request. In case of REGISTER requests To header field domain will be used (because this header field represents a user being registered), for all other messages From header field domain will be used.
The string may contain pseudo variables.
qop - Value of this parameter can be either “1” or “0”. When set to 1 then the server will put a qop parameter in the challenge. When set to 0 then the server will not put the qop parameter in the challenge. It is recommended to use the qop parameter, however there are still some user agents that cannot handle qop properly so we made this optional. On the other hand there are still some user agents that cannot handle request without a qop parameter too.
Enabling this parameter don't improve the security at the moment, because the sequence number is not stored and therefore could not be checked. Actually there is no information kept by the module during the challenge and response requests.
This function can be used from REQUEST_ROUTE.
Example 1.11. www_challenge usage
...
if (!www_authorize("siphub.net", "subscriber")) {
www_challenge("siphub.net", "1");
};
...
The function challenges a user agent. It will generate a Proxy-Authorize header field containing a digest challenge, it will put the header field into a response generated from the request the server is processing and send the reply. Upon reception of such a reply the user agent should compute credentials and retry the request. For more information regarding digest authentication see RFC2617.
In case the reply cannot be sent, this method returns "-1"; in case a reply was sent, it just terminates further script processing.
Meaning of the parameters is as follows:
realm - Realm is a opaque string that the user agent should present to the user so he can decide what username and password to use. Usually this is domain of the host the server is running on.
If an empty string “” is used then the server will generate it from the request. From header field domain will be used as realm.
The string may contain pseudo variables.
qop - Value of this parameter can be either “1” or “0”. When set to 1 then the server will put a qop parameter in the challenge. When set to 0 then the server will not put the qop parameter in the challenge. It is recommended to use the qop parameter, however there are still some user agents that cannot handle qop properly so we made this optional. On the other hand there are still some user agents that cannot handle request without a qop parameter too.
Enabling this parameter don't improve the security at the moment, because the sequence number is not stored and therefore could not be checked. Actually there is no information kept by the module during the challenge and response requests.
This function can be used from REQUEST_ROUTE.
Example 1.12. proxy_challenge usage
...
if (!proxy_authorize("", "subscriber)) {
proxy_challenge("", "1"); # Realm will be autogenerated
};
...
This function removes previously authorized credentials from the
message being processed by the server. That means that the downstream
message will not contain credentials there were used by this server.
This ensures that the proxy will not reveal information about
credentials used to downstream elements and also the message will be
a little bit shorter. The function must be called after
www_authorize or
proxy_authorize.
This function can be used from REQUEST_ROUTE.
Example 1.13. consume_credentials example
...
if (www_authorize("", "subscriber)) {
consume_credentials();
};
...
The function checks if the SIP URI received from the database or radius server and will potentially be used in Remote-Party-ID header field contains an E164 number (+followed by up to 15 decimal digits) in its user part. Check fails, if no such SIP URI exists (i.e. radius server or database didn't provide this information).
This function can be used from REQUEST_ROUTE.
Appends to the message a Remote-Party-ID header that contains header 'Remote-Party-ID: ' followed by the saved value of the SIP URI received from the database or radius server followed by the value of module parameter radius_rpid_suffix. The function does nothing if no saved SIP URI exists.
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
This function is the same as
Section 1.5.5, “
append_rpid_hf()”. The only difference is
that it accepts two parameters--prefix and suffix to be added to
Remote-Party-ID header field. This function ignores rpid_prefix and
rpid_suffix parameters, instead of that allows to set them in every
call.
Meaning of the parameters is as follows:
prefix - Prefix of the Remote-Party-ID URI. The string will be added at the begining of body of the header field, just before the URI.
suffix - Suffix of the Remote-Party-ID header field. The string will be appended at the end of the header field. It can be used to set various URI parameters, for example.
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
Example 1.16. append_rpid_hf(prefix, suffix) usage
...
# Append Remote-Party-ID header field
append_rpid_hf("", ";party=calling;id-type=subscriber;screen=yes");
...
The function verifies credentials according to
RFC2617. If the
credentials are verified successfully then the function will succeed
and mark the credentials as authorized (marked credentials can be later
used by some other functions). If the function was unable to verify the
credentials for some reason then it will fail and the script should
call www_challenge which will
challenge the user again.
Negative codes may be interpreted as follows:
-5 (generic error) - some generic error occurred and no reply was sent out;
-4 (no credentials) - credentials were not found in request;
-3 (stale nonce) - stale nonce;
-2 (invalid password) - valid user, but wrong password;
-1 (invalid user) - authentication user does not exist.
Meaning of the parameters is as follows:
realm - Realm is a opaque string that the user agent should present to the user so he can decide what username and password to use. Usually this is domain of the host the server is running on.
If an empty string “” is used then the server will generate it from the request. In case of REGISTER requests To header field domain will be used (because this header field represents a user being registered), for all other messages From header field domain will be used.
The string may contain pseudo variables.
This function can be used from REQUEST_ROUTE.
Example 1.17. pv_www_authorize
usage
...
$var(username)="abc";
$avp(s:password)="xyz";
if (!pv_www_authorize("kamailio.org")) {
www_challenge("kamailio.org", "1");
};
...
The function verifies credentials according to
RFC2617. If
the credentials are verified successfully then the function will
succeed and mark the credentials as authorized (marked credentials can
be later used by some other functions). If the function was unable to
verify the credentials for some reason then it will fail and
the script should call
proxy_challenge which will
challenge the user again. For more about the negative return codes,
see the above function.
Meaning of the parameters is as follows:
realm - Realm is a opaque string that the user agent should present to the user so he can decide what username and password to use. Usually this is domain of the host the server is running on.
If an empty string “” is used then the server will generate it from the request. From header field domain will be used as realm.
The string may contain pseudo variables.
This function can be used from REQUEST_ROUTE.
Example 1.18. pv_proxy_authorize usage
...
$var(username)="abc";
$avp(s:password)="xyz";
if (!pv_proxy_authorize("")) {
proxy_challenge("", "1"); # Realm will be autogenerated
};
...