Last Call Review of draft-ietf-sipping-update-pai-
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This document extends the applicability of the SIP P-Asserted-ID header
(PAID in brief) to include origination by other SIP entities and use in
other SIP methods than were specified in RFC 3325. It also provides
recommendations for processing of P-Asserted-ID to require recipients to
be more generous in what they receive as syntactically valid.
(I'm actually not clear on why this document is really necessary, since
as I read it, RFC 3325 doesn't actually forbid the use of PAID in the
cases addressed by this document except informally in the table rows in
Sections 9.1 and 9.2. But if the WG feels this document provides
important clarifications, I don't see this redundancy as a problem.)
The document does not raise significant security issues, largely because
it is specified to be used only within a Trust Domain (as specified in
RFC 3324), which provides many assumptions about the security of the
underlying environment in which this header is used. The document
clearly states this requirement (use within a Trust Domain), so there is
little risk that the document will be understood to be applicable in the
Several comments related to some ambiguities and inconsistencies in the
General: The problems that this document raises with authentication seem
kind of irrelevant, in that requirements for authentication are subject
to any given domain's Spec(T). For example, Spec(T) may say that it's
sufficient a UAC or UAS can send PAID if they've joined the trust domain
by establishing an authenticated TLS connection to their next-hop proxy.
The document seems to neglect entirely the possibility that the UAS is
part of the trust domain (which might be facilitated, e.g., by
sip-outbound), in which case it seems sensible to allow PAID in
responses. In any case, the first reverse hop can delete PAID from the
response if it doesn't regard the UAS as trusted, e.g., if the UAS
hasn't previously authenticated (this is the analogue of the comment
paragraph in Section 4.2).
So I don't really see a need to exclude PAID from ACK and CANCEL request
and from responses based on them not being challenge-able. Suggest
changing the relevant paragraphs in the Introduction and Security
Considerations to say something like "If the authentication provisions
in your Spec(T) rely on Digest authentication, then you should forbid
PAID in ACK, CANCEL, and responses".
General: This seems to be all about PAID. Don't some of the
considerations also apply to PPID? PPID is already specified to be
inserted by the UAC, but it seems like the addition of other request
methods and considerations about multiple URIs and other schemes could
In Section 4.3: "... the registrar MAY use this as evidence that the
registering UA has been authenticated ..."
This statement seems kind of weird in the case where the 'node' is the
UAC. First, there's an unstated assumption that there's a requirement
in Spec(T) that UACs authenticate before becoming part of the domain, or
otherwise before using PAID. Second, assuming that's the case, the
logic here seems either circular or incomplete, depending on who the UAC
authenticated to. If the UAC authenticated to the registrar, then
there's no need for further proof. If the UAC authenticated to someone
else, then the registrar has no idea whether the node is in the trust
domain or not, so it has to disregard the PAID -- that is, the registrar
needs some other channel to determine whether the UAC is within the
Suggest adding a clarification here:
"However, if the node transmitting a P-Asserted-ID header to a registrar
is the registering UAC itself, the registrar MUST NOT regard the
P-Asserted-ID itself as evidence that the UAC has authenticated (some
other authentication technique must be used, such as SIP Identity or
As an aside, the phrase "the registering UA ... represents the identity
asserted" seems awkward. Suggest s/represents/is represented by/
In Section 4.5:
This section uses the word[s] "[un]expected" a lot without defining what
they mean. Is this about adherence to RFC 3325? Implementation design
decisions? Part of Spec(T)?
All of the "unless Spec(T)" caveats here imply that implementations
SHOULD allow all of these things, if it's possible that they could be
specified by some users' Spec(T).
Section 6: "When receiving a response from a node outside the Trust
Domain, a proxy has no standardised SIP means to authenticate the node."
This paragraph seems unnecessary. It seems like the message should be
"When receiving any message from a node outside the Trust Domain, a
proxy MUST remove any P-Asserted-ID information from the message".
(Isn't this the definition of "within a trust domain"?) Perhaps this
language should be added to section 4.2, but this all seems covered
under the Proxy rules in Section 5 of RFC 3325. See also general
comment about authentication and responses.
Section 6: "When receiving a REGISTER request containing a
P-Asserted-Identity header field ..."
What's the point of this paragraph? This is again a restatement of
"within a trust domain". Either delete or make it a MUST and put it in
secdir mailing list
secdir at mit.edu