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

[Jensen Zhang <[e-mail]>]

Hi Roman,

Sorry for the delay. We just uploaded the revision -16 to resolve your
comments: https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-16

We put detailed responses inline below. Please let us know if more is
needed.

Thanks,
Jensen


On Thu, Oct 26, 2023 at 7:31 PM Jensen Zhang <[e-mail]>
wrote:

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

In the new revision, we added TLS-related configuration for the
'auth-client/https-auth-client'. It will allow to use EE/CA certificates or
public keys to identify the HTTPS clients.


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