Subject: [Rum] Benjamin Kaduk's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 15 Dec 2021 13:22:04 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-rum-rue-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for writing this document; it's an important topic and I look
forward to seeing interoperability in this space.

However, I don't think this document is quite ready for publication yet,
as it has a number of internal inconsistencies (and at least one
external inconsistency with IETF procedures) that would get in the way
of interoperable implementation.

(1) The procedure for substituting an entryPoint from the provider list into
the OpenAPI interface description for obtaining configuration data
appears to be incompatible with BCP 190.  Though there's not quite
enough detail for me to be able to tell exactly what behavior is
intended, the procedure of "replace localhost in the template with the
value from provider discovery" seems like it implies that the value from
provider discovery is just a hostname, and that we are requiring the RUM
services to be accessible via HTTP at path /rum/v1 on that machine.  The
URI path namespace is under control of the owner of the host, and we
cannot assert that we will occupy that portion of the namespace.  The
current version of BCP 190, RFC 8820, does allow us to say (effectively)
"delegate a subtree of the path namespace to the protocol" by letting
the owner of the host pick what base path to use for the protocol (even
that would not have been allowed by its predecessor, RFC 7320), but we
do need to let that host-specific path prefix be indicated somehow,
whether by URL template or allowing a base path to be indicated in the
provider discovery process.

(2) There are a lot of inconsistencies about the parameters and data
format of the various API responses as specified in prose, OpenAPI
description, and examples.  In particular, we also fail to make a clear
statement about whether the prose or the OpenAPI description is
normative and takes precedence in case of disagreement.

I'll list a bunch of things here; I made a fairly careful reading but am
not willing to assert that this is a comprehensive listing.  (A number
of them also get comments in the section-by-section comments; sorry
about that duplication.)

Sections 9.2.1 and 9.2.2 list configuration data items in the
"configuration data for new user sign up and dial around" and
"configuration data for the RUE" configuration retrieval APIs, and per
the note at the end of §9.2 they include the REQUIRED data items.
However, there are a couple data items that are mentioned elsewhere in
the document as if they are always going to be present, but are not
present in these lists of required configuration parameters.  In
particular we talk about the "provider-domain" as coming from the
configuration, and it appears in examples, but is not mentioned in the
prose or OpenAPI format description.

The prose (and some examples) refer to an "outbound-proxies" RUE
configuration element, but §9.2.2 and the OpenAPI description list the
singular "outbound-proxy" (and with the corresponding difference in
format/structure).

The prose mentions "credentials" from the configuration, but no
parameter of that name appears (there is some mention of password under
"carddav" but that seems insufficiently generic to match all instances;
sip-password also exists).

"display-name" appears in the example in Figure 5 but is not listed in
§9.2.2

The prose for the provider configuration resource indicates that the
dialAround property is mandatory (it is not marked as "(OPTIONAL)"), but
the OpenAPI specification does not list this property as required.

The prose for the provider configuration's "signup" property says that
it is an array of JSON objects, but the OpenAPI description says that it
is just a single object (not an array).  Likewise for "dialAround" and
"helpDesk".

The prose for "phone-number" specifies E.164 format, but the OpenAPI
description does not.

"carddav" is triply inconsistent: the prose says username, password, and
domain name are separated by "@" (presumably, in a single string), but
the example only shows username and domain name in user@domain form, and
the OpenAPI description says it should be an object with separate
properties for username/password/domain, as well as an additional
"sendLocationWithRegistration" property that is probably not supposed to
be a child of "carddav".

(repeating from the previous), the "sendLocationWithRegistration"
property is listed as belonging to the "carddav" object in the OpenAPI
description, though the prose and example indicate it should be a
property of the toplevel configuration object.

The prose and OpenAPI description indicate that "ice-servers" is an
array of strings, but the example has an array of objects that use the
dictionary key to indicate whether each URI is a TURN or STUN server.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There are a number of references to "the configuration" in the body text
prior to §9.2 where the configuration service is discussed.  E.g., the
first paragraph of §5.1 gives a hard requirement for registration and
then makes a conditional reference to "the configuration" without any
prose discussing how configuration retrieval interacts with
registration.  it may be useful to have a brief introductory mention of
the data flow involving registration and configuration retrieval and how
the two initialization processes (don't) interact.

I have a high-level comment or two about password usage in this
document.  I recognize that we're constrained in practice by the current
state of SIP specification and the deployed ecosystem, but while
username/password may currently be the lowest common denominator for
authentication, it's far from best current practice.  In a scenario
like the one here, where the RUE is a dedicated (often hardware)
product talking over a fixed protocol to a nearly fixed small set of
providers, there's plenty of scope for using strong cryptography to
authenticate the RUE, including public-key cryptography where the
verifier does not need to store any per-user secret information.  At
present, Digest seems to be the strongest mechanism in the registry for
usage with SIP, but I would advise assuming that that will change in the
future and writing the spec and implementation in a way that is
compatible with stronger authentication schemes.

Furthermore, this document in several places (I note a few in the
per-secton comments) recommends or even requires the reuse of a
username/password pair across multiple services.  Best practices are to
use any given password at exactly one service.  In this regard one can
roughly model the password as analogous to a pre-shared key -- it is
useful for authenticating a peer in the sense that if the value is known
only to two entities, and the party you're communicating with proves
that they know the value, they must be the only other party that knows
the secret value.  But once you reuse the password at multiple services,
that logic falls apart, as the party you're communicating with could be
the user, or it could be another service that shares the secret.
Granted, when used with digest the password itself is not sent to the
server for every authentication, but the server typically has access to
it at some point, and even possession of the password hash in a
verification database allows for offline brute-force attack, which has
become comparatively cheap in recent years and even the availability of
dedicated hardware for password cracking.

In particular, SHA-512 is not considered to be a best-practice hash
function for password hashing, since it is highly parallelizable and not
"memory-hard".  RFC 9106 specifies Argon2 (via the IRTF CFRG), the
winner of the password hashing competition; it is the state of the art
for password hashing, and even prior to that publication we had scrypt
available in RFC 7914 that is a significant improvement on the SHA-2
family of functions.  That said, it's not currently listed in the IANA
registry for hash algorithms for HTTP (and SIP) digest authentication,
so I am not sure that we can usefully advocate for its usage at the
present time.

Section 4

Thanks for mandating RFC 7525 compliance.  I note that
draft-ietf-uta-rfc7525bis is in progress in the UTA WG.  Though it will
probably be published after this document, it may be a useful
informative reference with forward-looking guidance on how to best
secure TLS.

   All text data payloads not otherwise constrained by a specification
   in another standards document MUST be encoded as Unicode UTF-8.

I think we'd typically reference RFC 8259 here.

Section 5.1

   The registrar MAY authenticate using SIP digest authentication.  The
   credentials to be used (username and password) MUST be supplied
   within the credentials section of the configuration and identified by
   the realm the registrar uses in a digest challenge.  This username/

Which entity is authenticating to which other entity here?  The phrasing
"<X> MAY authenticate" implies that it is X that is authenticating to
some other entity, but that does not seem to correspond to my model of
the flow here, where the RUE is authenticating to the registrar.  If the
flow is to be the other way, we would say "the registrar MAY
authenticate the RUE using SIP digest authentication".

Also, I note that (HTTP) SCRAM authentication has superior security
properties to Digest, but unfortunately I don't see any evidence that
its use for SIP is defined yet.

Section 5.2.1

   The SIP URIs in the To field and the Request-URI MUST be formatted as
   specified in subsection Section 5.4 using the destination phone
   number, or as SIP URIs, as provided in the configuration
   (Section 9.2).  [...]

I'm not sure that I'm unpacking this properly.  (The construction "the
SIP URIs MUST be formatted as [...], or as SIP URIs", makes me wonder
if there are somehow non-SIP URIs involved even though we start off with
"the SIP URIs".)  Is the idea that I either take the URI directly from
the configuration ("as-is") or I format it as per §5.4 but not anything
else?

Section 5.2.2

   party telephone number.  In two-stage dial-around, the To URI is the
   front door URI (see Section 9.2) of the dial-around provider and the
   domain of the URI is the provider domain from the configuration.  The

Is "the URI" in "the domain of the URI" referring to "the To URI", or
some other URI (the Request-URI, perhaps)?

The prose lists the call originator as (VRS user) +1-555-222-0001, but
the URIs in Figure 1 that are not the call recipient appear as
+18135551212; are those numbers supposed to be different like that?

Section 5.2.3

   owner".  The URI MAY be an HTTPS URI or Content-Indirect URL.  The
   latter is defined by [RFC2392] to locate message body parts.  This

RFC 2392 seems to define a "Content-ID" URI (with "cid" scheme) but not
a "Content-Indirect" URL.

Section 5.2.5

   Implementations MUST implement Additional Data, [RFC7852].  RUE
   devices MUST implement Data Provider, Device Implementation and
   Owner/Subscriber Information blocks.

The string "Device Implementation" does not seem to appear in RFC 7852,
though "Device Information" does.

Section 7.1

   of an email address.  If the request triggers a challenge for digest
   authentication credentials, the RUE MUST continue using matching
   "credentials" from the configuration.  If no matching credentials are
   configured, the RUE MUST use the SIP credentials from the
   configuration.  [...]

Do we really want a MUST-level requirement to reuse the SIP credentials?
Best practices for credentials are to have a 1:1 relationship between
credentials and where they are used and this sort of reuse is basically
the polar opposite.

Section 9.1

   non-mandatory-to use functions and SHALL NOT delete any objects,
   members of objects or functions.  This means an implementation of a
   specific major version and minor version is backwards compatible with
   all minor versions of the major version.  [...]

(This might all be covered by Rob's discuss point; I will read the
replies on that thread and you don't need to duplicate content here for
my benefit.)
This statement doesn't seem to contain enough information to be useful.
I think that a statement about backwards (or forwards) compatibility
should be specific about whether it applies to the implementation of the
client or the web service, and that backwards compatibility would
require that the implementation in question interoperate with a peer at
any same or previous minor version.  Just saying "compatible with all
minor versions of the major version" would also make a statement about
forward compatibility, which I think is allowable under these rules for
what is allowed to change in minor versions, and it would be useful to
make a statement about forward compatibility.

Section 9.2

   The interface to obtain configuration data is described by an OpenAPI
   [OpenAPI] interface description.  In that interface description, the
   "servers" component is specified as "localhost".  The entry point
   obtained from the provider list (Section 9.1) is substituted for
   "localhost" to obtain the server prefix of the interface.  [...]

I note that the OpenAPI description for /Versions has an override for
"servers", and the value listed there does not include the string
"localhost".  Some clarity that it is also expected to be affected by
this kind of substitution seems in order.

   In both the queries, an optional parameter may be provided to the
   interface which is an API Key.  The implementation MAY have an API
   Key obtained from the provider and specific to the implementation.
   The method the API Key is obtained is not specified in this document.
   The provider MAY refuse to provide service to an implementation
   presenting an API Key it does not recognize.

I note that the IETF does have a standard for conveying authorization
information on the web -- OAuth 2.0.  It may not be a direct "drop-in"
fit here, due to the need for a preexisting relationship with an
authorization server, but perhaps it is worth mentioning as an option
in addition to this provider-specific "API key" protocol?

   Also in both queries, the RUE device provides a required parameter
   which contains an instance identifier.  This parameter MUST be the
   same value each time this instance (same implementation on same
   device) queries the interface.  This MAY be used by the provider, for
   example, to associate a location with the instance for emergency
   calls.

Is there any cryptography to provide assurance that the instance
identifier is indeed always used only by the one single instance?  The
description here sounds roughly like a bearer token, which is far from
best practice for this sort of thing.  Indeed, in other contexts a given
instance is often identified solely by its public key, and must
authenticate with the corresponding private key in order to act as the
identified instance.

   The configuration API also provides the same version mechanism as
   specified above in Section 9.1.  The version of the configuration
   service MAY be different than the version of the provider list
   service.

Not only that, but the services are expected to be versioned
independently, so there is no particular relationship between version
X.Y of the one and version X.Y of the other...right?

Actually, having gone and looked further, the OpenAPI document seems
to indicate that there's a single /Versions resource common across the
/Providers, /ProviderConfig, and /RueConfig APIs, which makes me
confused as to how the versions of the two services might actually be
different (let alone versioned independently).

Section 9.2.1

      -  uri: a URI to the website for creating a new account in the
         supported language.  The new user signup URI may only initiate
         creation of a new account.  Various vetting, approval and other
         processes may be needed, which could take time, before the
         account is established.  The result of creating a new account
         would be a username and password, which would be manually

I strongly suggest using a more generic phrasing (e.g., "would be
account credentials (e.g., username and password)") to allow for
seamless transition to stronger authentication technologies without
specification change.

Section 9.2.2

   *  lifetime: (optional) Specifies how long (in seconds) the RUE MAY
      cache the configuration values.  Values may not be valid when
      lifetime expires.  If the RUE caches configuration values, it MUST
      cryptographically protect them.  [...]

In other contexts, "cryptographically protect" would mean to encrypt,
cryptographically sign, or compute a keyed MAC over the data.  If the
intent here is just to record a cryptographic checksum of the data,
that's probably better stated in terms of a checksum.

In particular, this current text gives no indication of what threat the
cryptography is supposed to protect against, so implementations are
unlikely actually provide uniform protection against the intended
threat.

   *  sip-password: (optional) a password used for SIP, STUN and TURN
      authentication.  The RUE device retains this data, which must be
      stored securely.  [...]

Akin to the above, this doesn't indicate what threat "stored securely"
is intended to protect against.  While I would *hope* that "protect
passwords" is instinctive to developers, I wouldn't want to rely on it.

      password MUST be used.  If it was never supplied, the password
      used to authenticate to the configuration service is used for SIP,
      STUN and TURN.

In the general case, this directive is a gaping security hole (exposing
the RUE's SIP credentials to arbitrary external STUN/TURN servers, for
example).  I think we must qualify that the reuse of credentials is only
for the servers listed in the "ice-servers" configuration directive.
(And ideally we would not encourage reuse of credentials at all.)

   *  carddav: (optional) A username, password and domain name
      (separated by ""@"") identifying a "CardDAV" server and account
      that can be used to synchronize the RUE's contact list with the
      contact list managed by the provider.  If username or password are
      not supplied, the main account credentials are used.

There are three data items but only one separator listed.  Is this
really to be "username@password@domain"?
It would be great if we could make ourselves more generic than
username+password as credentials, and (as mentioned previously) avoid
reuse of credentials.

   *  ice-servers: (optional) An array of URLs identifying STUN and TURN
      servers available for use by the RUE for establishing media
      streams in calls via the provider.

Is any given entry required to offer both STUN and TURN services, or can
a server provide just one or the other?  Both this text and my
understanding of the OpenAPI description seem to indicate that this is a
flat list intermingling STUN and TURN servers, but the example in Figure
5 seems to show each element of the array being a JSON object that
contains one or more of the keys "stun" and "turn".  The structure in
that example would obviate any confusion about which services are
offered, and is probably preferred.

Section 9.2.3

       "contacts": "https://red.example.net:443/contacts/1dess45awd",

I suggest putting a bit more entropy in the URL, in the vein of
https://www.w3.org/2001/tag/doc/capability-urls/ (even if this resource
is likely to require the username+password authentication discussed
earlier).

       "carddav": "[email-masked]" ,

The prose indicates this should contain a password as well as the
username and domain name that are present.  How is the password
specified?

Section 9.3

Given the "are formally specified" language, I expect that the intent is
for the OpenAPI description to be normative and take precedence in case
of conflict with the prose/examples.  It's probably worth stating that
explicitly.

          - in: query
            name: instanceId
            schema:
              type: string
            required: true
            description: Unique string for this implementation
                         on this device

Is this self-assigned by the client or assigned by some external
authority?  The allocation procedure is important for ensuring that the
instance IDs are actually globally unique (with high probability).
(Note that this parameter is used in both /ProviderConfig and
/RueConfig.)

Section 10.2

The rest of the document does not appear to contain any text covering
the usage of the "rue-owner" purpose value.  Should we say something
about when it's used and what semantics it conveys?

Section 11

I think we should make some statement that incorporates by reference the
security considerations of the protocols being profiled.  There are
perhaps too many to list individually, so something like "this document
requires implementation and use of a number of other specifications in
order to fulfil the RUE profile; the security considerations described
in those documents apply accordingly to the RUE interactions" would
probably work.

It is perhaps obvious, but when a CA participates in a conversation they
have access to the content of the conversation even though it is
nominally a conversation between the two endpoints.  I think we should
still state this explicitly, and perhaps note that there is an
expectation that the CA will keep the communication contents in
confidence, often backed by contractual or legal requirements.

There's probably also something useful to say to compare the privacy
properties of one-stage vs two-stage dial-around, in terms of which
entities have access to information about the communicating endpoints.

I am not entirely sure if the referenced documents already cover this,
but having the provider maintain the user's contacts database means that
there is increased risk surface for unauthorized disclosure of that
information (compared to it being maintained locally).

Since different providers (within a given country) may have different
policies, we might want to caution RUE implementations to have a user
interaction step before proceeding to actually register with any given
provider.

NITS

No need to reply to any of these; if you disagree, that's fine.

Section 5.2.1

   Negotiated media MUST follow the guidelines specified in Section 6 of
   this document.

If they MUST be followed, are they really guidelines, or requirements?

Section 5.2.3

   To identify the owner of a RUE, the initial INVITE for a call from a
   RUE, or the 200 OK accepting a call by a RUE, identifies the owner by

I think s/the 200 OK accepting a call by a RUE/the 200 OK a RUE uses to
accept a call/ would avoid ambiguity about whether this binds as
(accepting a (call by a RUE)) vs ((accepting [of] a call) by a RUE).

Section 9.1

   provider names for a country code suitable for display, with a
   corresponding a entry point to obtain information about that
   provider.

s/corresponding a/corresponding/

Section 9.2

   HTTPs web service.  There are two entry points.  One is used without
   user credentials or parameters, the response includes configuration
   data for new user sign up and dial around.  The other uses the

Comma splice.

Section 9.2.2

   *  videomail: (optional) An SIP or HTTPS URI that can be called to
      retrieve video mail messages.

Can an HTTPS URI really "be called"?  (This text also appears in §9.3.)

---

From: Brian Rosen <[email-masked]>
Date: Fri, 24 Dec 2021 15:58:21 -0500

Benjamin

Thanks for the close read of this document.  Comments inline

> On Dec 16, 2021, at 2:52 AM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
There is no restriction that the provider discovery returns a host name.  It’s string substitution that will be used for the entry points of the interface.  It could be "interface.external.example.com/rum/rue/opemapi/generic <http://interface.external.example.com/rum/rue/opemapi/generic>”.  Whatever the string is, it’s substituted for “localhost” and that is used to find the server and define the entry points.  After that string substitution, the path will end in, for example, “../rum/v1/ProviderConfig”.  I think that should be 8820 compatible.  I edited the descriptions of the mechanism to describe the parameters as strings to make it obvious that it is string substitution.  

I hope that’s enough to address the concern.

> of them also get comments in the section-by-section comments; sorry
I am sorry we made these many uncaught mistakes.  I’m having someone else go through and see if we can find more of them.
> prose or OpenAPI format description.
This is an error.  It appears to be the result of several changes to the interface that resulted in the OpenAPI localhost substitution discussed above.  
Somehow, we deleted provider-domain.
I replaced it in both the description and the OpenAPI yaml.

> singular "outbound-proxy" (and with the corresponding difference in
Fixed.  It should be proxies plural throughout now.

> sip-password also exists).
The first instance of credentials said:
       The registrar MAY authenticate using SIP digest authentication. The credentials to be used (username and password) MUST be supplied within the credentials
This is standard sip terminology.  The configuration has the username (constructed from the phone number and the provider-domain) and the sip-password (or as described in the sip-password description) are the credentials. 

It does occur to me, although no one raised in in reviews, that sometimes there is an actual username that is used, instead of the phone number.  I added that as optional (use the phone number if it’s not present), and reworded the text.
> "display-name" appears in the example in Figure 5 but is not listed in
Fixed
> the OpenAPI specification does not list this property as required.
Fixed.
> "helpDesk”.
Fixed.  Should have been arrays
> The prose for "phone-number" specifies E.164 format, but the OpenAPI
Fixed

> be a child of "carddav”.
Fixed
> property of the toplevel configuration object.
Fixed
> dictionary key to indicate whether each URI is a TURN or STUN server.
Fixed
I added some text in the top of the SIP Signaling section.

> compatible with stronger authentication schemes.
We had a big discussion on the use of OAuth, which is specified for use in SIP.  While there were strong proponents of supporting OAuth, it failed to gain consensus.  It’s just not how SIP is deployed.
I could rename the username/password things to try to anticipate some more robust mechanism, but the text has to change anyway and it didn’t seem worth it.  A really, really important characteristic of a device like this is if power fails, and is restored, calls can arrive.  This means you cannot require any user interaction on a power start.  This really is at odds with how a lot of mechanisms work.  We thought about installing certs and using mutual auth.  Again NO sip systems we know do that.  Installing certs securely with no user interaction is hard.  There was no consensus to try to do that here.  I personally don’t like the security situation we have, but we don’t have any alternatives we could realistically deploy.

> dedicated hardware for password cracking.
We could force the secondary services to have separate passwords.  Since they all come from the same config, they are all supplied by the default provider, and they all identify the same user, albeit on different service deployments, we didn’t think there really was much difference.  The one place I would be very reluctant to force separate credentials is stun/turn, were it’s just too common to use the same credentials.  There is no value in protecting, say the configuration service independently of the sip service or the turn service.  It really doesn’t matter at all.  

> so I am not sure that we can usefully advocate for its usage at the
We only very recently deprecated RC4, and I’d bet 99,99% of sip services deployed still use it.  I was able to make this spec use SHA-512, but that’s the very best we can do in a profile.  We could try to get some of the SIP guys to put through an RFC to support Argon2, but that would have to happen before this doc could use it.

> informative reference with forward-looking guidance on how to best
I’ll try to remember that for when this doc gets an update.

> I think we'd typically reference RFC 8259 here.
I’m worried that there might be some incompatibility between 8259 and OpenAPI.  OpenAPI references 
https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00 <https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00>!!!!
The text is specific to string content and not JSON format.

> authenticate the RUE using SIP digest authentication”.
I'll make that change.  The registrar authenticates the RUE
> its use for SIP is defined yet.
Yeah, yet another weakness.

> the configuration ("as-is") or I format it as per §5.4 but not anything
There are two ways you specify the From and To header fields in SIP when you are using telephone numbers and not usernames.  
One is a SIP URI sip:[email-masked];user=phone.  
The other is a TEL URI: tel:2025551212. 
Phone number and domain come from the configuration.  Does that help?

> some other URI (the Request-URI, perhaps)?
Yeah, that’s pretty awkward.  I shortened it to:
In two-stage dial-around, the To URI is the front door URI (see Section 9.2) of the dial-around provider.
> +18135551212; are those numbers supposed to be different like that?
I fixed the telephone numbers being wrong.  The deletion of the dashes follows text in 5.4
> a "Content-Indirect" URL.
Fixed.  I can’t tell you how many times I have made that mistake.

> though "Device Information" does.
Fixed

> credentials and where they are used and this sort of reuse is basically
See above.

> make a statement about forward compatibility.
I added: "Either may have any higher or lower minor revision and interoperate with its counterpart with the same major version."  
after "Backwards compatibility applies to both the server and the client."

I think that avoids having to talk about forwards compatibility.  
>   obtained from the provider list (Section 9.1) is sutituted for
That’s an error.  Changed the server override in Versions to:
      - url: https://localhost/rum

> in addition to this provider-specific "API key" protocol?
This isn’t a user authorization.  It’s a developer authorization.
OAuth can’t be used, because the developer can’t provide credentials when the device connects.

> authenticate with the corresponding private key in order to act as the
No, and I don’t think it’s needed,  A typical use case here is a device in your home and one on your phone that has the same credentials and phone number.  We just need to differentiate them. It’s not a security property.
The consequences of confusion is fairly low.  As stated above, we did go through some discussions of provisioning private keys to each device and gave up due to the complexity vs the sophistication of the user.  There really isn’t any reasonable plug and play mechanism here.  We can’t use anything like Acme.  

> X.Y of the one and version X.Y of the other…right?
That’s correct
> different (let alone versioned independently).
There are two services (the provider list service and the configuration service).
The former has one entry point, the latter has two: the provider config and the device config.

The two services have different versions.  The two entry points in the configuration service have the same version.
The way this mechanism is designed, you can make an implementation that works on several (or all) major versions and any minor version of each major version.
For server implementation, if it support multiple versions, each one has a separate URI (the version is in the URI).  The client composes the URI it wishes to use by looking at the Versions entry point for the service to find a compatible version and uses that and uses the version to choose an Open API yaml (and the code the yaml generates).

> seamless transition to stronger authentication technologies without
Done

> unlikely actually provide uniform protection against the intended
I added some text so it now reads:
it MUST cryptographically protect them against unauthorized disclosure (e.g. by other applications on the platform the RUE is built on). 
> passwords" is instinctive to developers, I wouldn't want to rely on it.
I added the same text to that.

> (And ideally we would not encourage reuse of credentials at all.)
Edited to say “is used for SIP, as well as STUN and TURN servers mentioned in this configuration."
> username+password as credentials, and (as mentioned previously) avoid
I fixed this to have separate fields in an object in the config.
I don’t know any other usable authentication mechanism for cardav in this environment, but I’m far from an expert.

> offered, and is probably preferred.
I fixed the OpenApi to use the strings (“stun” and “turn”).

> is likely to require the username+password authentication discussed
Made it a V4 UUID (3617b719-2c3a-46f4-9c13-538f7efd0b21)
> username and domain name that are present.  How is the password
This is fixed to have separate fields for domain, username and password
> of conflict with the prose/examples.  It's probably worth stating that
Done.

> (Note that this parameter is used in both /ProviderConfig and
Self assigned by the client.  There is no dependence on this for Provider config.

I’ll suggest it be something like a UUID.
> about when it's used and what semantics it conveys?
See Section 5.2.3. I added a cross reference.

> in those documents apply accordingly to the RUE interactions" would
Done

> confidence, often backed by contractual or legal requirements.
Done

> entities have access to information about the communicating endpoints.
Well the only difference is the CA has access to the called party number, but they usually have access to that anyway because of how dropped calls are handled.

> information (compared to it being maintained locally).
Yeah, but:
Locally maintained contacts are really hard to handle when you change devices
Locally maintained contacts don’t sync across devices.
I’ll put something here if you really think we need it, but getting the providers to manage contacts was a very hard fight that only recently became common (the US regulator now requires it).  Before, it was a vendor lock in.

> interaction step before proceeding to actually register with any given
Done

> If they MUST be followed, are they really guidelines, or requirements?
Changed to requirements

> (accepting a (call by a RUE)) vs ((accepting [of] a call) by a RUE).
Done

> s/corresponding a/corresponding/
Fixed

>   data for new user sign up and dial around.  The other uses the
Did something, but maybe not what you wanted

> Can an HTTPS URI really "be called"?  (This text also appears in §9.3.)
Changed to “used"

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Dec 2021 18:22:38 -0800

Hi Brian,

Also inline

> I hope that’s enough to address the concern.

Yes, that should work; thanks for the clarification.

> I am sorry we made these many uncaught mistakes.  I’m having someone else go through and see if we can find more of them.

Thanks.  (In reading the other ADs' reviews, I see that my list was
definitely not comprehensive, since I missed the case mismatch on "v1" vs
"V1" :)

> This is standard sip terminology.  The configuration has the username (constructed from the phone number and the provider-domain) and the sip-password (or as described in the sip-password descripti…

Okay, we can keep with the standard terminology.  I would suggest, then,
that all instances of "credentials" (with quotes, usually as '''matching
"credentials" from the configuration''') be modified to use an unquoted
word, so as to avoid implying that there is a JSON element by that name.

> I could rename the username/password things to try to anticipate some more robust mechanism, but the text has to change anyway and it didn’t seem worth it.  A really, really important characteristi…

Indeed, compatibility with the deployed reality trumps ideological purity
(though that doesn't keep us from documenting the weaknesses of what's
deployed).  Thanks for confirming.

> We could force the secondary services to have separate passwords.  Since they all come from the same config, they are all supplied by the default provider, and they all identify the same user, albe…

The main value in separate passwords for the secondary services would be
that compromise of one such service does not imply full compromise of the
"account".  As above, though, what people are willing to deploy is the main
consideration for me -- I don't feel a need to "require" something with an
RFC 6919 "MUST (BUT WE KNOW YOU WON'T)".

> We only very recently deprecated RC4, and I’d bet 99,99% of sip services deployed still use it.  I was able to make this spec use SHA-512, but that’s the very best we can do in a profile.  We could…

Agreed.

> The text is specific to string content and not JSON format.

It seems likely that I got my RFC numbers confused here and I meant to say
3629 for UTF-8 itself.  Sorry about that.

The 8259 reference might still be relevant, as JSON Schema still uses JSON
(but, predating 8259, it references 7159 instead), but I didn't look for an
appropriate place to put it.

> Phone number and domain come from the configuration.  Does that help?

Uh...maybe.
Do we need to s/or as SIP URIs/or as TEL URIs/?  I don't see how the
current text allows the TEL version that you describe.

I'd also consider making the "as provided in the configuration" clause a
separate sentence, like "the phone number and domain (if applicable) are
provided in the configuration (Section 9.2)".

> I fixed the telephone numbers being wrong.  The deletion of the dashes follows text in 5.4

Right, I just meant the actual numbers.  Thanks.

> OAuth can’t be used, because the developer can’t provide credentials when the device connects.

Oh, that kind of API key.  Then we get to pull in the security
considerations for attempting to keep secret a value that's shipped in the
software binary and sent on the wire (something that repeatedly doesn't
happen for the official mobile apps for popular services)...

> The consequences of confusion is fairly low.  As stated above, we did go through some discussions of provisioning private keys to each device and gave up due to the complexity vs the sophistication…

Thanks for the background; I don't see a need to re-hash that.

Though the description above makes me wonder if the instance ID is scoped
to a given user/credentials?  That would be better in some ways, I think.

> The two services have different versions.  The two entry points in the configuration service have the same version.

That looks like the key insight that I was missing.  Any chance we could
get that sentiment expressed in the document?

> it MUST cryptographically protect them against unauthorized disclosure (e.g. by other applications on the platform the RUE is built on). 

Thanks!

> Edited to say “is used for SIP, as well as STUN and TURN servers mentioned in this configuration."

Thanks.

> I don’t know any other usable authentication mechanism for cardav in this environment, but I’m far from an expert.

I suspect that I'm even farther from expert than you are...

> Well the only difference is the CA has access to the called party number, but they usually have access to that anyway because of how dropped calls are handled.

Okay.

> I’ll put something here if you really think we need it, but getting the providers to manage contacts was a very hard fight that only recently became common (the US regulator now requires it).  Befo…

I'll defer to your domain expertise.

Thanks for all the other good stuff (above and below) that I didn't reply
on.  I look forward to the -10 (in the new year, presumably).

-Ben