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

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Jul 2016 13:49:56 +0200

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

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

s/those/that/
- “That signature is   then placed in a SIP Identity header.  “
	I assume both signature and JSON object?

- “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 4:
 - “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”

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

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.

- 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Jul 2016 19:35:56 -0400

Did you mean draft-ietf-stir-rfc4474bis-10?

On Jul 14, 2016, at 7:49 AM, Olle E. Johansson <[email-masked]> wrote:

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 Jul 2016 00:11:20 +0000

Hey Olle,

Thanks for the nits, you have some good catches there, I'll implement them
if I'm not commenting otherwise below. On the substantive points here:

>
>s/those/that/
>- ³That signature is   then placed in a SIP Identity header.  ³

Usually not, no. As I just said in a mail to Christer, think about it like
the SIP Identity header carries some information that the verification
service can use to construct a JWS object, not the object itself - as the
data that constitutes the bulk of that JWS object is necessarily already
carried elsewhere in SIP.

Hearing this for the second time, perhaps we should take the hint that
this requires some motivational text.

>
>Section 5.1 step 5
>	- ³Finally, the authentication service MUST forward the message
>   normally.²
>What is normal?

We've been using that phrase for many years - basically, it means
forwarding in accordance with the Request-URI, through whatever your
normal routing procedure is (RFC3263, your Route set, outbounding,
whatevs). 

>
>Section 5.2:
>	- ³If the verifier does not support
>   the backwards direction. ³
>
>It seems that the reason text used here doesn¹t match the problem.
>in an additional header, like a warning code saying ³unsupported ppt
>param².

Yeah, you clipped the part there where it refers you to 13.3, and 13.3
does say you use a different reason phrase for this case ('Unsupported
PASSporT Format"). I'd rather not have to write that in two places, and
that sentence is already pretty long...

> - Does not describe actions to take if the date is outside of the

It's true, we never defined a "stale Date" response code for this. We
could. I'll bring this up at the WG.

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

I'd be okay with that reference change.

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

This is brand new text, so I'm glad to have some eyes on it.

But is that actually what we should do? I know RFC3261 19.1.4 says that
the user part is case sensitive. I fear that entities handling these
messages in transit don't agree.

>A not about internationalised domain names would also be good for
>implementers since you mention international environments.

I would think the ref to IRI is sufficient, as that in turn references IDN.

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

Direct TLS is a SHOULD in 12.4, right? I get that there are environments
where that recommendation will not be upheld. 12.4 even says that in some
environments it will not be viable.

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

Moreover, "strong authentication practices" is not sufficiently specific;
we say something actually implementable. Any ideas?

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

I could see adding a terminology section. I'll talk about that at the WG.

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

This document was designed to be as conciliatory as possible to the needs
of B2BUAs. But following PERPASS, we took a consensus call on this subject
in the working group, and if B2BUAs do not allow media keying, we want
this mechanism to fail (when media keys are in an offer).

This spills over a bit to SIPBRANDY as well, where that property is quite
crucial.

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

That's a separate thread we'll need to pick up elsewhere.

Thanks, this is helpful, just the kind of review we need now.

Jon Peterson
Neustar, Inc.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 15 Jul 2016 10:18:35 +0200

> On 15 Jul 2016, at 01:35, Russ Housley <[email-masked]> wrote:
> 
That’s a good question, I had many tabs open. Will check.
Sorry.
/O