[secdir] SECDIR review of draft-ietf-sipping-update-pai-09

[Richard Barnes <[e-mail]>]

Hi all,

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 
general Internet.

Several comments related to some ambiguities and inconsistencies in the 
document follow.

--Richard


-----
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 
be useful.

-----
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 
trust domain.

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 
Digest Authentication)."

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 
section 4.3.


_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir