Digest in LDAP and in HTTP/SIP

[Avshalom Houri <AVSHALOM@il.ibm.com>]

Following is a question between digest
authentication in LDAP and in HTTP/SIP. They seem not to
work very well together.

In RCF 2829: "Authentication method
for LDAP"
        section
6.1: it say: 
         
      " The client will send a bind request
with a distinct message id, in
                
which the version number is 3, the authentication choice is sasl, the
                
sasl mechanism name is "DIGEST-MD5", and the credentials contain
the
                
string defined by "digest-response" in section 2.1.2 of [4].
 The
                
serv-type is "ldap"."

In RFC 2831 "Using Digest  authentication
as SASL Mechanism"
        2.1.2
: 
         
   digest-uri       = "digest-uri"
"=" <"> digest-uri-value <">
       digest-uri-value  = serv-type "/"
host [ "/" serv-name ]
       serv-type        = 1*ALPHA
       host             =
1*( ALPHA | DIGIT | "-" | "." )
       serv-name        = host


In RFC 2617: HTTP Authentication: Basic
and Digest Access Authentication
        3.2.2
The Authorization Request Header
         
     digest-uri       = "uri" "="
digest-uri-value
       digest-uri-value = request-uri   ; As specified
by HTTP/1.1

       
In all the above cases the digest  "response"
is calculated as:
         
       request-digest  = <">
< KD ( H(A1),     unq(nonce-value)
                    
                     ":"
nc-value
                    
                     ":"
unq(cnonce-value)
                    
                     ":"
unq(qop-value)
                    
                     ":"
H(A2)
                    
             ) <">
         
        A2       = Method ":"
digest-uri-value

Note that in RFC 2617 the digest URI
is the http request URI and in sip it will be the sip
request URI.

Some LDAP servers that we have tried
require ldap as the serv-type. So when a SIP client needs to
authenticate it has to know that it
works with LDAP server and use ldap as the serv-type.
The SIP server can not intervene and
modify the string since it is encrypted.

Is is the way that is should be?

Avshalom