auth Minor update to docs, spelling errors

modules/auth/README

@@ -171,17 +171,17 @@ Chapter 1. Admin Guide
 
    These three module parameters control which optional integrity checks
    will be performed on the SIP message carrying digest response during
-   digest authentication. auth_check_register controls integrity checks to
-   be performed on REGISTER messages, auth_checks_no_dlg controls which
-   optional integrity checks will be performed on SIP requests that have
-   no To header field or no To tag (in other words the requests either
-   establishing or outside dialogs). auth_checks_in_dlg controls which
-   integrity checks will be performed on SIP requests within dialogs, such
-   as BYE or re-INVITE. The default value for all three parameters is 0
-   (old behaviour, no extra checks). The set of integrity checks that can
-   be performed on REGISTERs is typically different from sets of integrity
-   checks that can be performed for other SIP request types, hence we have
-   three independent module parameters.
+   SIP MD5 digest authentication. auth_check_register controls integrity
+   checks to be performed on REGISTER messages, auth_checks_no_dlg
+   controls which optional integrity checks will be performed on SIP
+   requests that have no To header field or no To tag (in other words the
+   requests either establishing or outside dialogs). auth_checks_in_dlg
+   controls which integrity checks will be performed on SIP requests
+   within dialogs, such as BYE or re-INVITE. The default value for all
+   three parameters is 0 (old behaviour, no extra checks). The set of
+   integrity checks that can be performed on REGISTERs is typically
+   different from sets of integrity checks that can be performed for other
+   SIP request types, hence we have three independent module parameters.
 
    Without the extra checks the nonce will protect only against expired
    values. Some reply attacks are still possible in the expire "window". A
@@ -194,24 +194,24 @@ Chapter 1. Admin Guide
    (see nonce_expire) and an MD5 over it and some secret (the MD5 is used
    to make sure that nobody tampers with the nonce expire time).
 
-   When the extra checks are enabled, the nonce will include and extra MD5
+   When the extra checks are enabled, the nonce will include an extra MD5
    over the selected part/parts of the message (see below) and some other
    secret. This will be used to check if the selected part of the message
    is the same when an UA tries to reuse the nonce, thus protecting or
    severely limiting reply attacks.
 
    The possible flag values for all three parameters are:
-     * 1 for checking if the message uri changed (uses the whole uri)
+     * 1 for checking if the message URI changed (uses the whole URI)
      * 2 for checking the callid
-     * 4 for checking the from tag
-     * 8 for checking the source ip (see nonce.h).
+     * 4 for checking the From tag
+     * 8 for checking the source IP address (see nonce.h).
 
-   For example setting auth_checks_register to 3 would check if the callid
-   or the request uri changed from the REGISTER message for which the
-   original nonce was generated (this would allow nonce reuse only within
-   the same UA and for the expire time). Note that enabling the extra
-   checks will limit nonce caching by UAs, requiring extra challenges and
-   roundtrips, but will provide much better protection.
+   As an example setting auth_checks_register to 3 would check if the
+   callid or the request uri changed from the REGISTER message for which
+   the original nonce was generated (this would allow nonce reuse only
+   within the same UA and for the expire time). Note that enabling the
+   extra checks will limit nonce caching by UAs, requiring extra
+   challenges and roundtrips, but will provide much better protection.
 
 Warning
 
@@ -599,7 +599,7 @@ modparam("auth", "nonce_auth_max_drift", 1)   # set max drift to 1 s
    If set to 1, www_challenge() and proxy_challenge() functions send reply
    statelessly no matter if transaction exists or not. If set to 0
    (default), reply is sent statefully if transaction exists and
-   stelelessly otherwise.
+   statelessly otherwise.
 
    Example 1.13. force_stateless_reply example
 ...
@@ -608,12 +608,12 @@ modparam("auth", "force_stateless_reply", 1)
 
 3.16. realm_prefix (string)
 
-   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 .
+   Prefix to be automatically stripped from the 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.example.com will be equivalent to example.com .
 
    Default value is empty string.
 

modules/auth/doc/auth_params.xml

@@ -24,28 +24,28 @@
 		<title><varname>auth_checks_in_dlg</varname> (flags)</title>
 	<para>
 		These three module parameters control which optional integrity
-        checks will be performed on the SIP message carrying digest response
-        during digest authentication. <varname>auth_check_register</varname>
-        controls integrity checks to be performed on REGISTER messages,
-        <varname>auth_checks_no_dlg</varname> controls which optional
-        integrity checks will be performed on SIP requests that have no To
-        header field or no To tag (in other words the requests either
-        establishing or outside
-        dialogs). <varname>auth_checks_in_dlg</varname> controls which
-        integrity checks will be performed on SIP requests within dialogs,
-        such as BYE or re-INVITE. The default value for all three parameters
-        is 0 (old behaviour, no extra checks). The set of integrity checks
-        that can be performed on REGISTERs is typically different from sets of
-        integrity checks that can be performed for other SIP request types,
-        hence we have three independent module parameters.
+        	checks will be performed on the SIP message carrying digest response
+        	during SIP MD5 digest authentication. <varname>auth_check_register</varname>
+        	controls integrity checks to be performed on REGISTER messages,
+        	<varname>auth_checks_no_dlg</varname> controls which optional
+        	integrity checks will be performed on SIP requests that have no To
+        	header field or no To tag (in other words the requests either
+        	establishing or outside dialogs).
+		<varname>auth_checks_in_dlg</varname> controls which
+        	integrity checks will be performed on SIP requests within dialogs,
+        	such as BYE or re-INVITE. The default value for all three parameters
+        	is 0 (old behaviour, no extra checks). The set of integrity checks
+        	that can be performed on REGISTERs is typically different from sets of
+        	integrity checks that can be performed for other SIP request types,
+        	hence we have three independent module parameters.
 	</para>
 	<para>
 		Without the extra checks the nonce will protect only against expired
 		values. Some reply attacks are still possible in the expire "window".
-		A possible workaround is to always force qop 
-		 authentication and always check the uri from the authorization
-		 header, but this would not work if an upstream proxy rewrites the uri
-		 and it will also not work with a lot of UA implementations.
+		A possible workaround is to always force qop authentication and 
+		always check the uri from the authorization header, but this would
+		not work if an upstream proxy rewrites the uri
+		and it will also not work with a lot of UA implementations.
 	</para>
 	<para>
 		In this case the nonce value will be used only to hold
@@ -54,7 +54,7 @@
 		tampers with the nonce expire time).
 	</para>
 	<para>
-		When the extra checks are enabled, the nonce will include and extra
+		When the extra checks are enabled, the nonce will include an extra
 		MD5 over the selected part/parts of the message (see below) and some 
 		other secret. This will be used to check if the selected part of 
 		the message is the same when an UA tries to reuse the nonce, thus 
@@ -65,28 +65,27 @@
 		<itemizedlist>
 			<listitem><para>
 				<emphasis>1</emphasis> for checking if the message
-				uri changed (uses the whole uri)
+				URI changed (uses the whole URI)
 			</para></listitem>
 			<listitem><para>
 				<emphasis>2</emphasis> for checking the callid
 			</para></listitem>
 			<listitem><para>
-				<emphasis>4</emphasis> for checking the from tag
+				<emphasis>4</emphasis> for checking the From tag
 			</para></listitem>
 			<listitem><para>
-				<emphasis>8</emphasis> for checking the source ip
+				<emphasis>8</emphasis> for checking the source IP address
 				(see nonce.h).
 			</para></listitem>
 		</itemizedlist>
 	</para>
 	<para>
-		For example setting
-		 <varname>auth_checks_register</varname> to 3 would check if the
-		 callid or the request uri changed from the REGISTER message for which
-		 the original nonce was generated (this would allow nonce reuse only
-		 within the same UA and for the expire time).  Note that enabling
-		 the extra checks will limit nonce caching by UAs, requiring extra
-		 challenges and roundtrips, but will provide much better protection.
+		As an example setting <varname>auth_checks_register</varname> to 3
+		would check if the callid or the request uri changed from the REGISTER
+		message for which the original nonce was generated (this would allow nonce reuse only
+		within the same UA and for the expire time).  Note that enabling
+		the extra checks will limit nonce caching by UAs, requiring extra
+		challenges and roundtrips, but will provide much better protection.
 	</para>
 	<warning><para>
 		Do not enable the from tag check (4) for REGISTERs
@@ -155,7 +154,7 @@ modparam("auth", "auth_checks_in_dlg", 15)
 		The possible values are: "auth", "auth-int" and "" (unset).
 	</para>
 	<para>
-	    The default value is not-set ("").
+		The default value is not-set ("").
 	</para>
 	<para>
 		See also:
@@ -231,12 +230,12 @@ modparam("auth", "qop", "auth")   # set qop=auth
 	</para>
 	<para>
 		See also: 
-					<varname>qop</varname>,
-					<varname>nc_array_size</varname>,
-					<varname>nc_array_order</varname>,
-					<varname>nid_pool_no</varname>,
-					<varname>nonce_expire</varname>.
-					<varname>one_time_nonce</varname>.
+			<varname>qop</varname>,
+			<varname>nc_array_size</varname>,
+			<varname>nc_array_order</varname>,
+			<varname>nid_pool_no</varname>,
+			<varname>nonce_expire</varname>.
+			<varname>one_time_nonce</varname>.
 	</para>
 	<example>
 	    <title>nonce_count example</title>
@@ -302,8 +301,8 @@ route{
 		in the first reponse to a challenge. All the messages will be 
 		challenged, even retransmissions. Stateful mode should be used, to
 		catch retransmissions before the authentication checks (using
-		 <function>t_newtran()</function> before the authentication checks
-		 and sending all the replies with <function>t_reply()</function>).
+		<function>t_newtran()</function> before the authentication checks
+		and sending all the replies with <function>t_reply()</function>).
 	</para>
 	<para>
 		<varname>one_time_nonce</varname> provides enhanced replay protections
@@ -342,7 +341,7 @@ route{
 		<varname>one_time_nonce</varname> checks should work flawlessly.
 	</para>
 	<para>
-	    The default value is 0 (off).
+		The default value is 0 (off).
 	</para>
 	<para>
 		See also:
@@ -645,7 +644,7 @@ modparam("auth", "nonce_auth_max_drift", 1)   # set max drift to 1 s
 		<function>proxy_challenge()</function>
 		functions send reply statelessly no matter if transaction
                 exists or not.  If set to 0 (default), reply is sent statefully
-		if transaction exists and stelelessly otherwise.
+		if transaction exists and statelessly otherwise.
 	</para>
 	<example>
 	    <title>force_stateless_reply example</title>
@@ -660,13 +659,13 @@ modparam("auth", "force_stateless_reply", 1)
 	<section id="auth.p.realm_prefix">
 		<title><varname>realm_prefix</varname> (string)</title>
 		<para>
-			Prefix to be automatically strip from realm. As an alternative to
+			Prefix to be automatically stripped from the 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 
-			<quote>sip.</quote>, at authentication, sip.mydomain.net will be
-			equivalent to mydomain.net .
+			<quote>sip.</quote>, at authentication, sip.example.com will be
+			equivalent to example.com .
 		</para>
 		<para>
 		Default value is empty string.