Re: [Sip] Question regarding draft-dotson-sip-mutual-auth-03

["Sumanth Channabasappa" <sumanth at cablelabs.com>]

Nils,

In the case you describe, the UAC cannot trust the response. So it can
take actions similar to when it does not receive a valid response: e.g.,
it can reasonably retry, log the error, and/or any other appropriate
behavior specified by the architecture. 

RFC3261 supports the Authentication-Info header (used in registration)
and not the Proxy-Authentication-Info header; which is why this I-D was
authored in the first place. The reference was to ensure that the
behavior is kept consistent, and available irrespective of registration
and non-registration messages. 

In any case, please refer to the following small thread (3 emails) for
the feedback I received during offline discussions at the last IETF:

http://www.ietf.org/mail-archive/web/sip/current/msg25882.html

	
- S

-----Original Message-----
From: Nils Ohlmeier [mailto:lists at ohlmeier.org] 
Sent: Thursday, March 12, 2009 12:50 PM
To: sip at ietf.org
Cc: steve.dotson at cox.com; Stuart Hoggan; Sumanth Channabasappa
Subject: Question regarding draft-dotson-sip-mutual-auth-03

Hello,

after reading the mutual auth draft:

http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt

I have an open question:
what should the client do if the server send authentication informations
in a Proxy-Authentication-Info header back in a let say 200 response,
but
when the client computes response it comes to a different result (e.g.
because man in the middle changed something in the messages)?

In chapter 5 of your draft you are simply referring to RFC3261 for more
details regarding the implementation of the UAC. But I failed to find
any
information about the UAC handling of this header in 3261. Even RFC2617
gives no hints, at least I did not found any, what a client should do
when
the server authentication fails.
So it is probably not your fault, but still an interesting question I
think. Especially because the client has already send its credentials
when
the check of the server authentication fails.

Best regards
  Nils Ohlmeier