[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Proposed text for update-pai concerning response identity (was RE: Further proceeding with draft-ietf-sipping-update-pai--05)
Elwell, John wrote:
Although there have been very few opinions expressed, those that have
been expressed seem to be roughly along the lines of my earlier
option 4 ("Go ahead with the present update-pai draft, leaving it
open how to achieve authentication of a response.
John: I went back and re-read the thread. By and large, I would
also put myself in the camp of option 4. But more inline.
The present example of how to do this (towards the end of section
3.3) is broken, so would have to be removed, or at least qualified.")
In draft-05, section 3.3 states: " <t>Section 5 of RFC 3325
requires a proxy to authenticate the originator of a message before
adding a P-Asserted-Identity header field to the forwarded message.
In practice there is no SIP means to authenticate the sender of a SIP
response message. However, authentication may be possible by other
means. For example, if the proxy has TLS connectivity with the
originator of the response and has previously authenticated the
connected entity (e.g., using SIP digest authentication at
registration time), then the originator of the response can be
considered to be authenticated. In such circumstances it is
permissible for a proxy to insert a P-Asserted-Identity header field
in a SIP response.</t>"
I would propose to change this to: " <t>Section 5 of RFC 3325
requires a proxy to authenticate the originator of a message before
adding a P-Asserted-Identity header field to the forwarded message.
How this is achieved is outside the scope of this document.</t>"
S3.3 is about inclusion of PAI and PPI in responses. With your
suggested change, it still remains unclear on whether you are
referring to a request or response when you write "Section 5 of
RFC3325 requires a proxy to authenticate the originator of
a message ..."
You then go on to say that a UAS can insert a PAI/PPI in
responses, so I assume that the gist of the problem we
are grappling with whether or not a proxy can insert PAI/PPI?
To that extent, I think it will be much cleaner if you
completely took out the paragraph "Section 5 of RFC 3325 ... in
a SIP response", and instead, defer the discussion of a proxy
inserting PAI/PPI responses in S4.2.2 where it really belongs.
If you have to insert some text about proxies inserting PAI/PPI
headers in response in S3.3, say something along these lines:
This section explores the inclusion of a PAI/PPI header
in a response by a UAS; the analogous discussion on whether
or not a proxy can include such headers in a response is
in S4.2.2.
And then in 4.2.2 it states: " <t>The proxy behaviour
specified in RFC 3325 is applicable to responses with the following
qualifications. A proxy that receives a response from a node outside
the Trust Domain cannot directly authenticate the UAS by SIP means.
Therefore it MUST NOT include a P-Asserted-Identity header field when
forwarding the response unless it has authenticated the UAS by other
means.</t> <t><list> <t>One possible circumstance in which a proxy
can include a P-Asserted-Identity header field when forwarding a
response from a node outside the Trust Domain is when the proxy has
direct TLS connectivity with the UAS and has authenticated the UA by
some other means (e.g., SIP digest authentication) during that same
TLS session.</t> </list></t>"
I would propose to change this to: " <t>The proxy behaviour
specified in RFC 3325 is applicable to responses with the following
qualifications. A proxy MUST NOT include a P-Asserted-Identity header
field when forwarding the response unless it has authenticated the
UAS by some means. The means to authenticate the UAS is outside the
scope of this document.</t>
I would suggest something along these lines, including Francois'
comments:
<t>Section 5 of RFC 3325 requires a proxy to authenticate the
originator of a message before adding a P-Asserted-Identity
header field to the forwarded message. While this works for
requests, it does not for responses since unlike requests,
responses are not challenged by a proxy, nor is the authenticity
of the sender of the response established. In practice, there
is no authoritative manner by which a SIP proxy can authenticate
the originator of the response. Therefore, a proxy MUST NOT
include a P-Asserted-Identity header field when forwarding the
response unless it has authenticated the UAS by some means.
The means to authenticate the UAS is currently outside the
scope of this document; however future documents may further
define techniques for response authentication.</t>
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP