[alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-15: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-alto-oam-yang-15: 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/about/groups/iesg/statements/handling-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-alto-oam-yang/



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

(There were a number of YANG references to chase down.  Please correct my read
of the YANG model if I have misunderstood.)

** Implementing mutual TLS/client side certificates (per Section 8.3.5 of
RFC7285) appears to need more guidance.   Client EE certificates and client CAs
can be specified by the tls:tls-server-group in
alto/server-listen-stack/https/tls-server-parameters.  However, it appears to
me that there isn’t any way then to later reference them in the
alto-server/auth-client section.  When doing username and password
authentication via http-server-parameters/client-authentication, there is a
common user-id field shared with auth-client/https-auth-client.

** Section 5.4.3.  It appears that there is an http-auth-client for both http
and https.  Is this suggesting that it is possible to have authenticated users
over unencrypted HTTP.  How does that work securely?  Is this related to
Section 8’s “The ietf-alto supports an HTTP listen mode to cover cases where
the ALTO server stack does not handle the TLS termination itself, but is
handled by a separate component.”  If so, what is the residual risk of this
approach?

** Section 8.  Per the guidance on writeable data, aren’t significant parts of
alto-server/listen sensitive as one could alter the stored keys for the server
or client; or the username/password combinations (in http-server-parameters)?

** Section 8.  Per the guidance about readable data:

-- isn’t tls-server-parameters sensitive since it could contain raw private
keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)?

-- Would it be best practice to be able to read all of the authorized users?


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

Thank you to Rich Salz for the SECDIR review.

** Section A.5.  Per the example:
            "client-authentication": {
              "users": {
                "user": [
                  {
                    "user-id": "alice",
                    "basic": {
                      "user-id": "alice",
                      "password": "$0$p8ssw0rd"
                    }

Isn’t the password supposed to be hashed? 
draft-ietf-netconf-http-client-server says password is of type
ianach:crypt-hash.