Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-15: (with DISCUSS and COMMENT)
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
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
Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-15: (with DISCUSS and COMMENT)
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.
>
> ** 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$
$$$
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
[alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-15: (with DISCUSS and COMMENT)
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.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
