[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

SIP Working Group                                              L. Veltri
Internet-Draft                                            Univ. of Parma
Intended status: Informational                                S. Salsano
Expires: October 29, 2008                                    A. Polidoro
                                               Univ. of Rome Tor Vergata
                                                          April 27, 2008


  HTTP digest authentication using alternate password storage schemes
                      draft-veltri-sip-alt-auth-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 29, 2008.
















Veltri, et al.          Expires October 29, 2008                [Page 1]


Internet-Draft      SIP auth. using alternate schemes         April 2008


Abstract

   This document proposes to extend the HTTP Digest Authentication by
   adding a set new algorithms.  These algorithms use different hash
   functions and combination of various information such as user name,
   realm, password, salt, and/or other data, in order to achieve
   compatibility with existing mechanisms used to store user credentials
   in various authentication/autorization servers.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  HTTP Digest Authentication for SIP . . . . . . . . . . . . . .  4

   3.  New extensible authentication scheme . . . . . . . . . . . . .  8
     3.1.  First solution . . . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Second solution  . . . . . . . . . . . . . . . . . . . . . 13

   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 17

   5.  Informative References . . . . . . . . . . . . . . . . . . . . 18

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

























Veltri, et al.          Expires October 29, 2008                [Page 2]


Internet-Draft      SIP auth. using alternate schemes         April 2008


1.  Introduction

   According to the current SIP specification [RFC3261], the SIP
   protocol uses the HTTP Digest Authentication defined in [RFC2617] as
   default mechanism for authenticating and authorizing User Agent
   Clients (UACs) against remote User Agent Servers (UASs) or
   intermediate proxys.  HTTP Digest Authentication is a challenge-
   response authentication method and requires that both the supplicant
   (i.e. the UAC) and the authenticator (i.e. the UAS or the proxy)
   access the clear-text user password or a non-revertible function
   (hash-derived) of the password and other information.  The HTTP
   Digest Authentication [RFC2617] specifically define also an
   authentication scheme named MD5 that requires the UAs and proxys to
   compute or retrive from a database the MD5 digest of a concatenation
   (colon-separated) of username, realm, and password.  Unfortunately
   other user authentication/authorization mechanisms use different and
   non compatible mechanisms to store non-revertible hashes of
   passwords.  This prevents using an existing database of user
   credentials to offer SIP based services requiring authentication.
   This document tries to extend the stantard SIP/HTTP Digest
   Authentication mechanism in order to consider other password-storing
   schemes that do not naturally cooperate with the current HTTP Digest
   Authentication scheme.  Examples of such password-storing schemes are
   those generally used in LDAP servers, Unix shadow/password files,
   Apache's htpasswd file, or SQL-based storage systems used by other
   specific applications.

























Veltri, et al.          Expires October 29, 2008                [Page 3]


Internet-Draft      SIP auth. using alternate schemes         April 2008


2.  HTTP Digest Authentication for SIP

   HTTP Digest Authentication [RFC2617] is a general challenge-response
   mechanism in which a UAS authenticates a UAC based on a shared
   secret.  The challenge response is computed through the use of a one-
   way function based on various user's credentials.  The standard also
   specifies the use of a particular function (in turn based on the MD5
   hash function) that requires that both the client and server knows
   the user secret (normally a password) or, at least, the hash of the
   concatenation of the user name, the realm, and the password.

   When the HTTP Digest Authentication [RFC2617] is used in SIP, an UAS
   that receives a SIP request (example a REGISTER) may challenge the
   UAC by sending a 401 "Unauthorized" error response (or 407 "Proxy
   Authentication Required" for proxy authentication) containing a fresh
   random nonce value as challenge.  Both the UAC and the UAS share a
   secret (usually a password) and they use this secret, together with
   the nonce value, realm, and other information, respectively to
   compute the challenge response (the UAC) and to verify such the
   response (the UAS).  The UAS sends the challenge in the 401
   "Unauthorized" SIP response within a WWW-Authenticate header field
   (Proxy-Authenticate header for proxy authentication), then the UAC
   sends the challenge response in a new request message within a
   Authorization header field (Proxy-Authorization header for proxy
   authentication), and finally the UAS sends the authentication and
   authorization result with a new response message (2xx if it
   successed).

   According to [RFC2617] the challenge response is computed as:

   response = KD(H(A1), nonce:nc:cnonce:qop:H(method:uri))

   where KD(secret,data) is a general two-parameters digest algorithm
   applied to "data" with secret "secret", while H(data) is a digest
   algorithm applied to "data", and A1 is a quantity that should take
   into account user credentials.

   As specified in [RFC2617], by default or in case of "algorithm=MD5,
   the KD(,) H(), and A1 are respectively:

   KD(secret, data) = MD5(secret:data)

   H(data) = MD5(data)

   A1 = username:realm:passwd

   Particularly, the first term of KD(,) (indicated as "secret") and
   computed as H(A1) becomes:



Veltri, et al.          Expires October 29, 2008                [Page 4]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   secret = H(A1) = MD5(username:realm:passwd)

   Note that both the requestor (the UAC) and the auhenticator (the UAS)
   do not need to know the user password (eventually retrieved from a
   local archive), but rather this "secret" i.e. a digest function of
   username, realm and password itself.

   Unfortunately, current user's credential databases or storage systems
   often protect user's password by implementing one-way cryptographic
   algorithms different from the MD5 hashing mechanism specified for the
   HTTP Digest Authentication.

   For example, in LDAP (Lightweight Directory Access Protocol) servers,
   password values can be stored as plaintext or as one of a variety of
   hashes.  [RFC3112] specifically describes the "MD5" and "SHA1"
   schemes for a LDAP directory.  The MD5 scheme computes the hashed-
   protected password as the base64 encoding of an MD5 [RFC1321] digest
   of the concatenation the user password and salt that must be at least
   64 bit long.  The SHA1 scheme computes the hashed-protected password
   in the same way, by using SHA1 [RFC3174] hash function instead of
   MD5.

   These two hash-protected password schemes are also referred as:

   o  SSHA - Salted SHA-1 based hash

   o  SMD5 - Salted MD5 based hash

   Other hash-protected password schemes normally supported by an LDAP
   server are:

   o  SHA - SHA-1 based hash.

   o  MD5 - MD5 based hash.

   o  CRYPT - Unix crypt() hash, based on DES, also referred as UNIX;
      see later.

   Note that these three schemes are weaker than the previous two, due
   to the absence of a security salt value.  In some lucky cases a LDAP
   server may also support other schemes that use pre-calculated hash
   values compatible with HTTP Digest Authentication.

   An other example is the Unix system in which passwords are usually
   stored in the "/etc/shadow" file or, in older Unix versions, in the
   "/etc/password" file.  In both cases, passwords are normally stored
   encrypted (actually hashed) with a one-way algorithm generally
   referred as "crypt", together with a salt value and an indication of



Veltri, et al.          Expires October 29, 2008                [Page 5]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   the used algorithm.  The traditional crypt algorithm implementation
   uses a modified form of the DES algorithm that performs 25 DES passes
   to encrypt an all-bits-zero block using with a 56-bit key formed by
   the first 7 password characters.  A 12-bit salt is used to perturb
   the original DES algorithm.  The salt and the final ciphertext are
   base64-encoded into a printable string stored in the password or
   shadow file.  Other more robust crypt functions have been defined
   based on other cryptographic or hash algorithms such as MD5,
   blowfish, or SHA-1.  Such functions generally allow users to have any
   length password (> 8bytes), and do not limit the password to ASCII
   (7-bit) text.  Currently, the most common crypt function used by
   Unix/Linux systems supports both the original DES-based and the MD5-
   based (MD5-crypt) algorithms.  The MD5-crypt function is really not a
   straight implementation of MD5: first the password and salt are MD5
   hashed together in a first digest, then 1000 iteration loops
   continuously remix the password, salt and intermediate digest values;
   the output of the last of these rounds is the resulting hash.  A
   typical output of the stored password together with username, salt,
   and other information is:

   alice:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj:12747:0:99999:7:::

   where $1$ indicates the use of MD5-crypt, while BZftq3sP is the
   base-64 encoding of the salt and xEeZmr2fGEnKjVAxzjQo68 is the
   password hash.

   Other applications also store user's credentials in local files or
   database, that have they own format but that re-use similar hashing
   algorithms.  For example the Apache's htpasswd tool supports four
   different methods:

      PLAINTEXT: passwords are stored without any encryption mechanism.
      In this case in the file will contain lines of the form: user:
      passwd

      CRYPT: passwords are stored encrypted using the traditional Unix
      crypt function described in the previous section.

      SHA1: passwords are stored by base64-encoding the SHA-1 digest of
      the password.  The corresponding htpasswd file has lines that look
      like:

         alice:{SHA1}VBPuJHI7uixaa6LQGWx4s+5GKNE=

         where VBPuJHI7uixaa6LQGWx4s+5GKNE= is the base-64 hash of the
         password.





Veltri, et al.          Expires October 29, 2008                [Page 6]


Internet-Draft      SIP auth. using alternate schemes         April 2008


      MD5: passwords are stored encrypted through the MD5-crypt function
      described in the previous section using an Apache-modified version
      of MD5.  An example of a corresponding htpasswd line is:

         alice:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/

         where $apr1$ indicates the use of the Apache's MD5-crypt
         function, followed by the salt and the effective password hash.











































Veltri, et al.          Expires October 29, 2008                [Page 7]


Internet-Draft      SIP auth. using alternate schemes         April 2008


3.  New extensible authentication scheme

   The HTTP Digest Authentication [RFC2617] requires that the response
   to the challenge, regardless of the selected algorithm, is in the
   form of:

   response = KD(H(A1),nonce:nc:cnonce:qop:H(method:uri))

   In case of "algorithm=MD5", KD(secret,data) is MD5(secret:data),
   H(data) is MD5(data), while the H(A1) becomes MD5(username:realm:
   passwd).

   Assuming for the moment that we have no interest in changing the KD
   function, we can envisage two possible solutions:

   a.  we can define a different A1 and H(A1) function compatible with
       the specific authentication system (A1 is a formatted set of
       parameters that are taken into account by the H() function).  For
       example A1 could be the concatenation passwd:salt and H(A1) could
       become: H(A1) = MD5(passwd:salt)

   b.  we can reuse the definition of H(A1) and only replace the
       password parameter with a new derived pseudo-password A3 defined
       as A3=KP(password,other-params).  In this case we are introducing
       a new function KP() with a new set of parameters that includes
       the user password.  The value A1 becomes: A1=username:realm:A3.

   For example, if we chose KP() as MD5(passwd:salt) the value H(A1)
   becomes:

   H(A1) = MD5(username:realm:A3), i.e.:

   H(A1) = MD5(username:realm:MD5(passwd:salt))

   The first solution (a) has the advantage that it may save some
   computation of crypto functions.  The second option (b) has the
   advantage that it inherits all the security properties of the current
   MD5 solution.  Moreover one could store in the client the derived
   password (i.e. the A3 value) instead of the password and maintain a
   compatibility with existing clients.  We are here referring to the
   approach of several SIP user agents to store the SIP user password
   rather then requesting it to the user each time.  During this "one-
   time" password storing operation, the A3 value could be computed
   externally and then manually stored in the SIP client.  Of course
   this is not our suggested solution, i.e. we believe that SIP stacks
   should be enhanced with the proposed solution so that SIP UA can
   natively support the new authentication method, anyway it was worth
   mentioning this possibility to reuse legacy clients in the short



Veltri, et al.          Expires October 29, 2008                [Page 8]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   term.

   Once that we have chosen which solution for the algorithm, we should
   discuss:

   1.  how to introduce the indication of this different authentication
       algorithms within SIP signaling;

   2.  how to convey the parameters that are needed by the new
       authentication algorithms.

   Again, we introduce two different options concerning issue 1):

   i   introduce new algorithms specified as parameter "algorithm"
       within authentication headers.  We could have for example
       algorithm=md5-ldap-sha1, algorithm=md5-crypt-des and so on.

   ii  introduce a new authentication parameter called "pwd-algo" in
       order to indicate the chosen algorithm used to compute only the
       derived-passwd A3.

   These two choices are not completely independent from the choice of
   the algorithm definition, as shown in the following table.

  |----------------------|----------------------|----------------------|
  |                      |i)introduce new values|ii)introduce a new    |
  |                      | for the algorithm    | pwd-algo parameter   |
  |                      | parameter            |                      |
  |----------------------|----------------------|----------------------|
  |a)definition of a     |                      |                      |
  | new A1 and H(A1)     |         Yes          |         No           |
  |                      |                      |                      |
  |----------------------|----------------------|----------------------|
  |b)reuse H(A1) and     |                      |                      |
  | include a new        |                      |                      |
  | A3=KP(pwd,params) in |       Possible       |      Suggested       |
  | place of the passwd  |                      |                      |
  | value                |                      |                      |
  |----------------------|----------------------|----------------------|

                          Figure 1: Alternatives

   If we define new A1 and H(A1) this should be signaled by introducing
   new values for the algorithm parameter.  At the contrary, if we reuse
   H(A1) and introduce A3=KP() in place of the clear password, both
   options for the signaling are feasible, but we think that keeping the
   algorithm parameter unchanged (that specify A1, H(), and KD()) and
   introducing a new pwd-algo is preferable.



Veltri, et al.          Expires October 29, 2008                [Page 9]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   Now we finally need to discuss how to convey the additional parameter
   that may be needed by the different authentication mechanisms.  We
   think that three options are possible:

   1.  introduce new parameters with specific names for each
       authentication algorithm;

   2.  introduce a generic parameter named pwd-param to carry algorithm
       specific parameters;

   3.  carry the new parameters added inside the nonce parameter.  This
       is the approach that has been followed for example in the
       specification of the AKA authentication mechanism.

   We believe that 1) is the worst solution as it may lead to add
   several new parameters. 2) and 3) are both feasible, where 2) is a
   "cleaner" approach that requires the definition of an additional
   parameter, while 3) has the advantage that does not require any new
   parameter.  Considering the various discussed options, we believe
   that a first possible solution is based on:

   a.  reuse of H(A1) with a modified version of A1 in which the
       password value is simply replaced by A3 = KP(password,other-
       params)

   b.  introduction of new "pwd-algo" parameter

   c.  introduction of a new generic "pwd-param" parameter

   Examples of the new pwd-algo parameter are:

      pwd-algo= ssha

      pwd-algo= crypt-md5

      pwd-algo= crypt-apache

   A second possible solution, more conservative from the point of view
   of SIP signaling is the use of A3 = KP(password,other-params) as
   above, but specifying the chosen algorithm in the existing
   "algorithm" parameter and carrying the algorithm specific parameters
   within the "nonce" parameter.  Examples of the "algorithm" parameter
   are:

      algorithm=md5-pwd-hashed

      algorithm=sha1-pwd-salt-hashed




Veltri, et al.          Expires October 29, 2008               [Page 10]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   When we need to specify variants of the algorithm we think that a
   simple and efficient solution is to carry the name of the variant
   into the eventual pwd-param or as part of the nonce value.

3.1.  First solution

   In the first solution we define two new parameters as follows:

      pwd-algo = "pwd-algo" "=" ( "plain" | token )

      pwd-param = "pwd-param" "=" quoted-string

   where "pwd-algo" specifies the function KP() used to compute the
   derived-password A3, while "pwd-param" has a completely opaque value,
   depending on the particular selected function KP, indicating the
   values of the (eventual) parameters used in KP() computation.  A
   "pwd-algo=plain" value should indicate that none algorithm has to be
   used, and hence A3=password.  This corresponds to the case in which
   no pwd-algo parameter is present, as in case of standard MD5-based
   Digest Authentication.  Examples of such parameters are:

      pwd-algo=crypt-des, pwd-param="fzwhEV6E"

      pwd-algo=alternative, pwd-param="12"

      pwd-algo=plain

   Particularly, in order to support current LDAP, Unix-based, and other
   storing mechanisms, the following new values are defined:

      pwd-algo = "pwd-algo" "=" ( "plain" | "ssha" | "smd5" | "sha" |
      "md5" | crypt-algo | token )

      crypt-algo = "crypt-" crypt-hash

      crypt-hash = "des" | "md5" | "blowfish" | "apache" | token

      pwd-param = "pwd-param" "=" LDQUOT salt-value RDQUOT

      salt-value = <base-64 encoding of the salt value>

   In case of ssha or smd5 or crypt-XXX, the A3 value is computed as
   follows:

   A3 = KP(password,salt) = H(password||salt)

   where H() is respectively SHA1, MD5, or the the Unix crypt function.




Veltri, et al.          Expires October 29, 2008               [Page 11]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   Instead, in the remaining cases:

   A3 = KP(password) = H(password)

   In case of ssha or smd5 or crypt-XXX, the pwd-param will contain the
   base-64 encoding of the salt value.

   Examples of use of such parameters within a SIP transaction are:

   INVITE sip:bob@neverland.net SIP/2.0

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   [...]

   SIP/2.0 401 Unauthorized

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   WWW-Authenticate: Digest realm="example.com",

   nonce="cc5a61b2954e03541847f227102f",

   qop="auth", algorithm="MD5", pwd-algo="crypt-md5",

   pwd-param="fzwhEV6E"

   [...]

   INVITE sip:bob@neverland.net SIP/2.0

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   Authorization: Digest username="alice", realm="example.com",

   nonce="cc5a61b2954e03541847f227102f",

   pwd-algo="crypt-md5", pwd-param="MD5-fzwhEV6E"

   response="587410ee2dc5edd9bbe9370ddc1fA3a1",

   uri="sip:bob@neverland.net", qop="auth", nc="00000001"



Veltri, et al.          Expires October 29, 2008               [Page 12]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   cnonce="226827CAD1C949A18B17FD71EC68"

   [...]

   SIP/2.0 200 OK

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   [...]

3.2.  Second solution

   The second solution does not require any new authentication
   parameters since both the selected function KP() (used to generate
   the new "password" value A3 used in A1) and the eventual parameters
   of KP() are indicated respectively in the standard algorithm and
   nonce authentication parameters.  According with this solution, the
   "algorithm" parameter defined in [RFC3261] can be extended as
   follows:

      algorithm = "algorithm" EQUAL ( algorithm-value | new-algorithm)

      algorithm-value = "MD5" | "MD5-sess" | token

   where "new-algorithm" is a new algorithm name that completely
   specifies the KD(), H(), A1, and KP() functions for the new
   authentication scheme.  For example, in order to support
   authentication against a server with Unix-based password archive, we
   could define:

      new-algorithm = crypt-algorithm

      crypt-algorithm = algorithm-value "-crypt"

   Examples of the use of "algorithm" parameter are:

      algorithm=MD5

      algorithm=MD5-crypt

   In case of KP() function requires additional parameters such as sub-
   algorithm type, salt, etc, their values will be included within the
   nonce parameter, in a form named compound-nonce.  According to
   [RFC3261], the "nonce" parameter can be extended as follows:





Veltri, et al.          Expires October 29, 2008               [Page 13]


Internet-Draft      SIP auth. using alternate schemes         April 2008


      nonce = "nonce" EQUAL (nonce-value | compound-nonce )

      compound-nonce = LDQUOT compound-nonce-value RDQUOT

      compound-nonce-value = algo-param ":" nonce-value

      algo-param = *( unreserved | algo-mark )

      algo-mark = ";" | "/" | "?" | "@" | "&" | "=" | "+" | "$" | ","

   Examples of the use of nonce parameter are:

      nonce="cc5a61b2954e0354184"

      nonce=":cc5a61b2954e0354184"

      nonce="$1$BZftq3sP:cc5a61b2954e0354184"

   Particularly, in order to support current LDAP, Unix-based, and other
   storing mechanisms, the following new values are defined:

      algorithm = "algorithm" EQUAL ( algorithm-value | new-algorithm)

      new-algorithm = algorithm-value ( "-pwd-hashed" | "-pwd-salt-
      hashed" )

   In this case, the nonce parameter will contains indication of both
   password hash algorithm and salt, together with the actual nonce
   value; that is:

      nonce = "nonce" EQUAL (nonce-value | compound-nonce )

      compound-nonce = LDQUOT compound-nonce-value RDQUOT

      compound-nonce-value = ( salted-hash-algo | hash-algo ) ":" nonce-
      value

      compound-nonce-value = ( crypt-algo-nonce ) ":" nonce-value

      hash-algo = "sha" | "md5" | "des" | "blowfish" | "apache" | token

      salted-hash-algo = (hash-algo | crypt-algo) "-" salt-value

      crypt-algo = "crypt-" hash-algo

      salt-value = <base-64 encoding of the salt value>.

   Examples of use of such parameters within a SIP transaction are:



Veltri, et al.          Expires October 29, 2008               [Page 14]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   INVITE sip:bob@neverland.net SIP/2.0

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   [...]

   SIP/2.0 401 Unauthorized

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   WWW-Authenticate: Digest realm="example.com",

   nonce="crypt-des-fzwhEV6E:cc5a61b2954e03541847f2",

   qop="auth", algorithm="MD5-crypt"

   [...]

   INVITE sip:bob@neverland.net SIP/2.0

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   Authorization: Digest username="alice", realm="example.com",

   nonce="crypt-des-fzwhEV6E:cc5a61b2954e03541847f2",

   response="587410ee2dc5edd9bbe9370ddc1fA3a1",

   uri="sip:bob@neverland.net", qop="auth", nc="00000001"

   cnonce="226827CAD1C949A18B17FD71EC68"

   [...]

   SIP/2.0 200 OK

   To: sip:bob@neverland.net

   From: sip:alice@wonderland.net

   [...]




Veltri, et al.          Expires October 29, 2008               [Page 15]


Internet-Draft      SIP auth. using alternate schemes         April 2008


   We believe that this second solution is to be preferred to the one
   presented in the previous sub-section, as it does not require
   addition of new parameters.  This is the same approach that has been
   followed when defining the SIP-AKA authentication mechanism
   [RFC3310].














































Veltri, et al.          Expires October 29, 2008               [Page 16]


Internet-Draft      SIP auth. using alternate schemes         April 2008


4.  Security considerations

   Put security considerations here
















































Veltri, et al.          Expires October 29, 2008               [Page 17]


Internet-Draft      SIP auth. using alternate schemes         April 2008


5.  Informative References

   [RFC3261]  J. Rosenberg et al., "SIP: Session Initiation Protocol",
              RFC 3261, June 2002.

   [RFC2617]  J. Franks et al., "HTTP Authentication: Basic and Digest
              Access Authentication", RFC 2617, June 1999.

   [RFC2401]  "Security Architecture for the Internet Protocol", RFC
              2401, November 1998.

   [RFC3310]  "Hypertext Transfer Protocol (HTTP) Digest Authentication
              Using Authentication and Key Agreement (AKA)", RFC 3310,
              September 2002.

   [RFC3112]  "LDAP Authentication Password Schema", RFC 3112, May 2001.

   [RFC1321]  "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

   [RFC3174]  "US Secure Hash Algorithm 1 (SHA1)", RFC 3174,
              September 2001.






























Veltri, et al.          Expires October 29, 2008               [Page 18]


Internet-Draft      SIP auth. using alternate schemes         April 2008


Authors' Addresses

   Luca Veltri
   DII, University of Parma
   Viale delle Scienze 181/A
   Parma  43100
   Italy

   Phone: +39 0521 90 5768
   Email: luca.veltri@unipr.it
   URI:   http://www.tlc.unipr.it/veltri


   Stefano Salsano
   DIE, University of Rome "TorVergata"
   Via Politecnico, 1
   Rome  00133
   Italy

   Phone: +39 06 7259 7770
   Email: stefano.salsano@uniroma2.it
   URI:   http://netgroup.uniroma2.it/Stefano_Salsano


   Andrea Polidoro
   DIE, University of Rome "TorVergata"
   Via Politecnico, 1
   Rome  00133
   Italy

   Phone: +39 06 7259 7773
   Email: andrea.polidoro@uniroma2.it
   URI:   http://netgroup.uniroma2.it


















Veltri, et al.          Expires October 29, 2008               [Page 19]


Internet-Draft      SIP auth. using alternate schemes         April 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Veltri, et al.          Expires October 29, 2008               [Page 20]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/