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

[Jensen Zhang <[e-mail]>]

Hi Roman,

Many thanks for all the comments. Please see my responses inline below.

Thanks,
Jensen


On Wed, Oct 25, 2023 at 12:23 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

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

Good point. The intention of alto-server/auth-client is to identify the
configured HTTP clients. There can be multiple authentication approaches
beyond HTTP Basic and TLS, like OAuth. This document only focuses on the
basic structure. Thus, initially, only the HTTP Basic authentication is
defined. Appendix A.2 gives an example to augment the
alto-server/auth-client section.

But I agree that TLS is required by RFC7285. If you think it is necessary
for the initial data model, we can add the related data nodes to this
section.


>
> ** 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?
>

In this case, the security will rely on the external TLS handler.


>
> ** 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)?
>

Yes, some groupings in alto-server/listen are also sensitive. But they are
defined in other RFCs, thus the security considerations in those RFCs also
apply to them.


>
> ** 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)?
>

Yes, see above.


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

In practice, the server only needs to identify the authorized users. The
server doesn't need to read all the sensitive configurations of those 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.
>

Yes, the password is supposed to be hashed. Just to make it readable in the
example, we use "$0$" type to show the clear text password. Refer to
[e-mail]:

          A value of this type matches one of the forms:

            $0$<clear text password>
            $<id>$<salt>$<password hash>
            $<id>$<parameter>$<salt>$<password hash>

          The '$0$' prefix signals that the value is clear text.

 Of course, it is not recommended in practice.