Subject: [SIP] Digest Authentication

From: Mark Wisdom <[email-masked]>
Date: Thu, 19 Oct 2000 21:19:19 -0700 (PDT)

I need some clarification on, and help with, digest authentication.

rfc2617, section 3.2.1 states:

> A nonce might, for example, be constructed as the base 64
> encoding of
>
>     time-stamp H(time-stamp ":" ETag ":" private-key)

Then in section 4.5 it states:

> The server created "nonce" value is implementation dependent,
> but if it contains a digest of the client IP, a time-stamp,
> the resource ETag, and a private server key (as recommended
> above) then a replay attack is not simple.

rfc2543bis-02, section 14.3 states:

> 4. The example procedure for choosing a nonce based on Etag
>    does not work for SIP.

It would be nice if rfc2543 provided an alternate example for
creating a nonce. Can this be added to the rfc2543?

Does anyone have any guidelines on creating a nonce for use
with digest authentication?

rfc2543bis-02, section 14.3 also states:

> 5. The Authentication-Info and Proxy-Authentication-Info
>    fields are not used in SIP.

If I understand correctly, not allowing the Authentication-Info
header eliminates support for mutual authenication (i.e.
allowing the server to also authenticate itself to the client
by proving to the client that it knows the client's secret).

Does SIP allow for mutual authentication when using digest
authentication?

If not, can we modify rfc2543 so that mutual authentication is
possible?

Thanks,
Mark Wisdom

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Sunitha Kumar <[email-masked]>
Date: Fri, 20 Oct 2000 10:54:24 -0700

Mark:

With respect to your question about mutual authentication, maybe PGP
could be considered as the way to go.
Using PGP, the server can authenticate the client, and the client could
verify that this is the server.

Using Digest for mutual authentication may require 2 independent msgs to
go from the server to client and client to server,
each sending each other their generated nonces, and the other forming
the digest with that nonce.

Just my 2c.

sunitha

--
Sunitha Kumar
http://www.vovida.com

---

From: Mark Wisdom <[email-masked]>
Date: Fri, 20 Oct 2000 15:13:14 -0700 (PDT)

On Fri, 20 Oct 2000, Sunitha Kumar wrote:
> With respect to your question about mutual authentication, maybe
> PGP could be considered as the way to go.
> Using PGP, the server can authenticate the client, and the client
> could verify that this is the server.

I think that PGP authentication is great. However I am not aware
that it simplifies mutual authentication. From my understanding,
in order to accomplish mutual authentication with PGP, the server
would need to know the client's public PGP key, and the client
would need to know the server's PGP key. Having said this, I am
not aware of a standardized mechanism within SIP to authenicate
the server to the client using PGP.

> Using Digest for mutual authentication may require 2 independent
> msgs to go from the server to client and client to server, each
> sending each other their generated nonces, and the other forming

*If* SIP allows for mutual authentication using digest, then the
number of messages needed to be exchanged to accomplish mutual
authenication would be no different than the number of messages
needed to accomplish only client authentication to the server.

Here is the message flow:

  Client           Server

     INVITE
     ---------------->
 
     401 Unauthorized (includes WWW-Authenticate header with a nonce field)
     <----------------
 
     ACK
     ---------------->
 
     INVITE (includes Authorization header with a cnonce field)
     ---------------->
 
     200 OK (includes Authentication-Info header a rspauth field)
     <----------------
 
     ACK (includes Authorization header)
     ---------------->

Currently SIP does not allow for the Authentication-Info header
(see rfc2543bis-02, section 14.3, bullet 5) thus the above example
is not possible (at least as I understand it), but that is how I
envision that it would be done.

In the above example the server would compute the rspauth digest
value using the client's secret and the client supplied nonce
(cnonce), thus proving to the client that it knows its secret.

Mark Wisdom