Hi all,
We are faced with an interpretation problem regarding support of the
"Authentication-Info" header for subsequent SIP authorization (using
"nextnonce", as specified in 3261/2617). We would appreciate any
support you can provide.
Use case is as follows:
- SIP client registers and
authenticates against a SIP service. As an example, HTTP-Digest
authentication is used for such purpose.
- The Proxy/Registrar/Server, in
order to proactively authenticate future requests provides an
"Authentication-Info" header in each successful response. Such header
provides authentication information such as "nextnonce" and so on. This
way, if the user maps info received in the last "Authentication-Info"
header towards a "Proxy-Authorization" header in the next SIP request,
sever-issued credentials are used, and the Server does not need to
re-challenge the client.
- The client starts a session
and maps info received in the last "Authentication-Info" header (200 OK
response to REGISTER request) into the corresponding
"Proxy-Authorization" header of the SIP INVITE request
- The call is eventually
connected and a 200 OK response is received for the INVITE request. The
response contains an "Authentication-Info" header to be used for the
next SIP request.
Now the issue comes here: obviously,
the next SIP request after INVITE-200 OK is an *ACK* request to
complete dialog establishment. Since ACK messages are *special* and
response-less, the problem is: how should the client fill-up the "Proxy-Authorization"
header for the ACK and subsequent requests?
a) Should the
"Proxy-Authorization"
header of the ACK message be populated with the same information as
used for the INVITE request?, OR:
b) Should the ACK request sent
without any "Proxy-Authorization" header?
c) Should it use the information
received in the last 200 OK response? In such case, synchronization is
lost, because the next SIP request will suffer an extra RTT delay (the
client runs out of "nextnonce" information, since the ACK reused the
last "nextnonce" received in the 200 OK for the INVITE request), OR:
The issue raises because ACK is a
special response-less request, which impacts the chain received
"Authentication-Info" header --> next "Proxy-Authorization" header.
I am sure the answer may be obvious (I tend to believe in a) or b)),
but browsed through 3261, 2616 and 2617 and found no light about this.
Any feedback will be more than welcome.
Thanks indeed for your support!
Kind Regards,
David
|
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
