Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-10

From: Olle E. Johansson <[email-masked]>
Date: Mon, 18 Jul 2016 14:47:31 +0200

Hi!
I’ve been reading this draft and have a few nits and some general comments below.

(and yes, I’ve double-checked and it’s the WG adopted draft I read as opposed to what
I emailed earlier. Some notes added in this e-mail).

Section 3
- Maybe add subparagraphs for SIP URI’s and telephone numbers. It’s a very long section.
- section 3, page 5
“The authentication service then computes a signature over
  those JSON object in a manner following PASSporT.”

s/those/that/

- “In  these cases, implementation the authentication service at an
  intermediary may be more practical.”
s/implementation/implementing/

Section 5.1
- “The procedures below define the steps that must be taken when each an
  header is added.”
s/an //

Section 5.1 step 4
	- “Subsequently, the authentication service MUST form a PASSporT object
  and add a corresponding an Identity header to the request containing
  this signature.”
s/an Identity/Identity/

Section 5.1 step 5
	- “Finally, the authentication service MUST forward the message
  normally.”
What is normal?

Section 5.2:
	- “If the verifier does not support
  an Identity header present in a request due to the presence of an
  unsupported "ppt" parameter, or if no Identity header is present, and
  the presence of an Identity header is required by local policy (for
  example, based on a per-sending-domain policy, or a per-sending-user
  policy), then a 428 'Use Identity Header' response MUST be sent in
  the backwards direction. “

It seems that the reason text used here doesn’t match the problem.
If there is an identity header with an unsupported parameter - should
this message not be conveyed back either in the response code or
in an additional header, like a warning code saying “unsupported ppt param”.

Section 5.2 Step 1:
	- “The verifier MUST inspect any optional "ppt" parameter appearing the
  Identity request.”
s/appearing/appearing in /

Step 4:
- Does not describe actions to take if the date is outside of the accepted range.

Step 5:
- “The handling of the message after the
  verification process depends on how the implementation service is
  implemented and on local policy.”
Do you really mean “implementation service”? Maybe “verification service” ?

Section 5.2.1:
- “If the optional "canon" parameter of the Identity header is present,
  it contains a base64 encoding of the header and claim component of
  the PASSporT object constructed by the authentication service, and
  this it conveys any canonical telephone number formats created by the
  authentication service (see Section 7.2), as well as an "iat" claim
  corresponding to the Date header that the authentication service
  used.”
The phrase “this it” seems wrong to me, maybe you mean “thus it”.
The sentence is awfully long and complex.

Section 6.2:
- “Provided that the credential used to sign a
  message is not previously known to the verifier, SIP entities SHOULD
  discover this credential by dereferencing the "info" parameter,
  unless they have some more other implementation-specific way of
  acquiring the needed keying material, such as an offline store of
  periodically-updated credentials.”
“some more other” seems like you have one word too many. 

Section 6.3
- “For example,
  imagine a case where a domain implements the authentication service
  role for a range of telephone and a user agent belonging to Alice has
  acquired a credential for a single telephone number within that
  range. “
Range of telephone WHAT? Numbers?

Section 7:
- “Ultimately, in any case where local policy canonicalizes the idenity” ..
- s/idenity/identity/

Section 7.3
- “domain signature” is not explained
- I don’t really like the last paragraph. In RFC 5922 SIP Domain Certificates wildcard certificates are banned, which is not the case in RFC 2818. 5922 seems to me a better reference, especially if we want to be able to use the same certificate and keys. RFC 6125 section 6.4. is also a bit more up to date on verification of domain names in certs.

Section 7.4
- s/ayntax/syntax/
- I would add a notice that the username part is case-sensitive and should not be normalised, which is not the case with domains in the SIP uri. A not about internationalised domain names would also be good for implementers since you mention international environments (even though there’s a reference already, but helping implementors is always a good thing).

Section 11:
- “Similar practices could be used to support opportunistic
  signing of SIP requests for UA-integrated authentications services
  with self-signed certificates, though that is outside the scope of
  this specification and is left as a matter for future investigation.”
s/authentications/authentication/
- The first reference to RFC3325 seems to lack a link in the HTML version: “[RFC3325] defines the "id" priv-value token, which is specific to the  P-Asserted-Identity header.”

Section 12.4:
- In a scenario with Outbound Edge proxies - would the requirement of a direct TLS connection in 12.4 require that the authentication service is placed on the edge proxies? I would say it is natural to place it in the registrar/auth service beyond the edge proxies, but then this requirement fails. SIP Outbound is an update to RFC 3261 and can not be
ignored in this work in my opinion.

Section 12.5
- The first paragraph claims it is RECOMMENDED to employ strong authentication practises. Section 5 claims it is a MUST.

Some general comments
- I think the document would benefit from a few definitions of terms used in the beginning, as it suffers from a chicken and egg problem. A lot of terms is used before they are explained.

- It is unclear how identity headers should be handled by a b2bua, especially when media keying is included in the signature… That may be for discussion somewhere else, but is something I expect will come up. b2bua’s may be able to forward Identity headers but typically wants to anchor media streams. It is has been discussed that discussion is not documented in the document. I don’t believe this work can ignore the existence of B2Bua’s, nor hand the problem
over to another wg (like straw) to solve.

- Can we do this without referring to the SIPS: uri scheme? I am not happy seeing this uri scheme turn up in new documents.

/Olle

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir