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 secdir at mit.edu https://mailman.mit.edu/mailman/listinfo/secdir