Skip to main content

Telechat Review of draft-ietf-asap-sip-auto-peer-21
review-ietf-asap-sip-auto-peer-21-artart-telechat-alvestrand-2025-03-03-00

Request Review of draft-ietf-asap-sip-auto-peer
Requested revision No specific revision (document currently at 41)
Type Telechat Review
Team ART Area Review Team (artart)
Deadline 2025-03-04
Requested 2025-01-31
Authors Kaustubh Inamdar , Sreekanth Narayanan , Cullen Fluffy Jennings
I-D last updated 2026-08-03 (Latest revision 2026-01-20)
Completed reviews Tsvart Telechat review of -20 by Joerg Ott (diff)
Secdir Telechat review of -16 by Dan Harkins (diff)
Artart Telechat review of -21 by Harald T. Alvestrand (diff)
Genart IETF Last Call review of -18 by Joel M. Halpern (diff)
Yangdoctors Telechat review of -23 by Ebben Aries (diff)
Artart Telechat review of -23 by Harald T. Alvestrand (diff)
Yangdoctors IETF Last Call review of -30 by Ebben Aries (diff)
Opsdir IETF Last Call review of -32 by Jen Linkova (diff)
Assignment Reviewer Harald T. Alvestrand
State Completed
Request Telechat review on draft-ietf-asap-sip-auto-peer by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/cFuLKybWc-3swU-XG1i4PLqclxc
Reviewed revision 21 (document currently at 41)
Result Ready w/issues
Completed 2025-03-03
review-ietf-asap-sip-auto-peer-21-artart-telechat-alvestrand-2025-03-03-00
This document is describing a format for automatically configuring SIP systems
- including telephone and VC systems. As such, it seems well structured and
reasonably complete.

My big worry about the document is its security posture.
It makes the recommended and only described method OAUTH2 with Resource Owner
Password Credentials - in other words, cleartext passwords protected in transit
with HTTPS, but no protection at endpoints (such as two factor or passkey).
This seems very much at odds with good security practice - the statement that
"an SBC that is configured and managed through a CLI and that does not have the
ability to launch a web-browser wouldn't be able to obtain an authorisation
code and subsequently an access token" is patently false for CLI accessed via
terminal emulators - copy/paste of tokens is widely deployed and used in
practice.

Apart from that, mostly nits:
- The "reference architecture" has the HTTPS connection with a two headed arrow
- this is a client/server relationship, unlike the others, so should probably
be a directed arrow, not a bidirectional one. - 4.2 says "MUST support the use
of the HTTP URI scheme" - this should be HTTPS to be consistent with the rest
of the document and reasonable security practices - Resource Owner Password
Credentials is referenced without a link to RFC 6749 section 1.3.3 - There's no
example of a config document and a real-life configuration that could be
derived from it; such an example would be very useful in understanding the
point of the document, and would aid anyone attempting to evaluate it for
completeness of info (something I have not done), and would make section 9.2
less of a skeleton.