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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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) [phone], but
the URIs in Figure 1 that are not the call recipient appear as
[phone]; 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": "[e-mail]" ,

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