Skip to main content

Authenticated Identity Management in the Session Initiation Protocol (SIP)
draft-ietf-stir-rfc4474bis-16

Yes

(Alissa Cooper)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Spencer Dawkins)
(Stephen Farrell)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 15 and is now closed.

Alissa Cooper Former IESG member
Yes
Yes (for -15) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2016-11-02 for -15) Unknown
Thanks for this work. I'm balloting  yes, but have a few minor comments and questions:

Substantive:

- 6.2, step 4:  This says that if the full form of passport is included, and the Date header and iat do not match, use iat if it is fresh. I'm curious why not just use iat in the first place? What should one do if Date is fresh, but iat is not?

-6.2.2: This section recommends specific result code reason phrases for a couple of circumstances. I assume the idea is that one should use a "helpful" reason phrase, and these are examples of phrases helpful for the circumstances. But it reads as if you mean to standardize those specific reason phrases.  If the intent is really to offer examples, please clarify. I'd hate to see us back in the days of commonly seeing SIP code break due to unexpected reason phrases.

- 7.2: The first sentence says verifiers must have a way to acquire and _retain_ certificates. Why must they have a way to retain them? The last paragraph in the section says they might wish to have a way to retain certs, but doesn't seem to require it.

-- Is there any concern that the requirement to be able to dereference effectively arbitrary URLs in "info" parameters could become a DOS attack vector? E.g. info parameters that point to HTTP URIs that never respond, respond very slowly, or return huge and/or corrupt certs?

-13.1 and 13.2: Is there a reason not to retarget the references in the IANA entries for the Identity header field and for the error codes from 4474 to [RFCThis]?

Editorial:

- 4.1.1, example: I assume the backslashes indicate line folding for documentation purposes only. It might be worth mentioning that.

- 6.1, step 4, last paragraph: Is the reference to section 9 mean that section of _this_ document, or that section of stir-passport?

- 7.1, 2nd paragraph: It seems odd to use 2119 MUSTs in examples of policies that authenticator services might have.

-8.1, third paragraph: s/exampple/example
Alexey Melnikov Former IESG member
No Objection
No Objection (2016-11-02 for -15) Unknown
This is a well written document (despite giving too many deployment choices in some areas). I have a short list of small issues/nits:

In Section 4: ABNF for the signed-identity-digest allows empty string? Is this intentional? If not, maybe use "1*" in front?

In Section 5.1: are you missing an empty line between the header and the SDP payload?

In Section 6.2.2: is it customary in SIP to use the human readable portion of error responses?

In Section 7.4: HTTP URIs need a reference.

In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case as well?
Alia Atlas Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2016-11-03 for -15) Unknown
Upcoming (minor) comments from Vijay's Gen-ART review may be interesting to look at by the authors. The comments are about to arrive.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-11-02 for -15) Unknown
Thanks for a well written document.  Just one comment, I would have liked to have seen section 10 much sooner in the document, maybe in the introduction as changes are usually up front.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-11-01 for -15) Unknown
One minor comment:
Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for?

(Added later)

Now I have read draft-ietf-stir-passport. So it clear why this method is used. Didn't realize that the following sentence means 'please check PASSporT for further questions...': "this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT." Maybe just give a more specific reference including the section refernce.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (for -15) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -15) Unknown