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 <jingxuan.n.zh...@gmail.com> 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 < > nore...@ietf.org> 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 > iana-crypt-h...@2014-08-06.yang: > > 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. >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
