On Sun, 2005-05-29 at 16:48 +0900, kojiishi wrote:
> Hello experts,
> 
> I'm implementing digest authentication for a client sip stack, and have some
> difficulty to understand how authentication states are stored and used. Here
> are some assumptions I have made from reading RFC 3261 and 2617. Could
> someone please verify/correct these?
> 
> * Userid & password are stored per from-uri and realm as the key, since
> request-uri could be different when routing information are different. Is
> this correct?

You could choose to associate them with an origin address, but all they
are really bound to is the service protection space, which is to say the
realm value.

> * nc (nonce-count) is the count of server nonce, not cnonce. Is this
> correct?

Yes, it is the number of times the client has used the server nonce.

> * The nc counter must be kept in the client. It's stored per from-uri and
> realm as the key. The nc is kept and incremented as long as the user is
> logged on, and nonce are the same. Once the UAC received different nonce for
> the same from-uri/realm pair, the counter is reset.

All it really needs to be associated with is the nonce; the nonce is in
turn associated with the server that issued it (which dialogs it is
acceptable on with that server and for how long is entirely up to the
server).

> * When UAC got 401/407 which includes multiple
> WWW-Authenticate/Proxy-Authenticate headers, UAC will include
> Authorize/Proxy-Authorize if it could generate at least one of them. Since
> single server could generate multiple these headers so that client can
> choose, say, algorithm, not all authenticate headers are necessarily
> responded.

The client should include Authorization-Info for any challenges that it
can.   Multiple challenges may be a result of a chain of servers, in
which case all the authorization information would be needed, or could
result from a fork, so even if you can only provide credentials for one
challenge you should try (one fork is authorized and succeeds, any
others fail, but you don't care).

-- 
Scott Lawrence, Consulting Engineer
Pingtel Corp.  http://www.pingtel.com/
+1.781.938.5306 x162 or sip:[EMAIL PROTECTED]

_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to