Hi, Jensen:
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jensen Zhang
发送时间: 2022年12月13日 18:16
收件人: IETF ALTO <alto@ietf.org>
抄送: draft-ietf-alto-oam-y...@ietf.org
主题: [alto] Open discussion on providing resource-level access control in ALTO
O&M
Hi ALTOers,
From the discussion about the ALTO O&M draft last week, we find there is
another open issue that we should solve before we request YANG doctor reviews:
According to Section 16.2.4 of RFC7285 and Requirement R5-3 of the ALTO O&M
draft, the data model should support configuration for access control at the
information resource level. In other words, the data model should configure:
1. How an ALTO server identifies an ALTO client?
2. Which ALTO clients can access a given information resource?
[Qin Wu] if we consider SSH as transport of ALTO message, I think we should
assume both client and server needs to be mutually authenticated.
Futher if we consider service authorization, I think we need to consider AAA
service in place or oauth, openID like service in place.
To realize them, we consider two design options:
---
Option 1: authentication and authorization based approach
- To realize the first one, conceptually, we should provide data model to
configure authentication and authorization for each client. It can be simply
based on username and password, or delegated to other more complex
authentication systems like openID and LDAP.
- To realize the second one, a simple approach is to use a role-based solution.
Every authenticated client can be assigned to multiple roles. And each
information resource can configure to be accessible by given roles.
The YANG module can be like the following:
+--rw alto!
+--rw alto-server
...
+--rw auth-client* [username]
| +--rw username string
| +--rw (auth-config)
| +--:(basic-auth)
| | +--rw username string
| | +--rw password string
| ...
| +--rw role* role-name
+--rw resource* [resource-id]
...
+-- rw accepted-role* role-name
...
[Qin Wu] One thing I feel confused, is username appeared twice at different
level, one is at the auth-client level, the other is at the auth-config.
The choice auth-config can be augmented for different authentication protocols.
We can reference or even reuse the openconfig-aaa data mode [1].
[1]
https://github.com/openconfig/public/blob/master/release/models/system/openconfig-aaa.yang
[Qin Wu] I suggest you refer to RFC7317 section 3.5 user authentication model
if you want to take this path
+--rw system
+--rw authentication
+--rw user-authentication-order* identityref
+--rw user* [name]
+--rw name string
+--rw password? ianach:crypt-hash
+--rw authorized-key* [name]
+--rw name string
+--rw algorithm string
+--rw key-data binary
Look at the model design in RFC7317, username only appear once.
---
Option 2: ACL based approach
This approach only requires the server to configure an ACL. We can reuse the
YANG data model defined by RFC8519 [2]. It only filters the traffic by the
packet attributes, not the application-level authentication. Compared with
option 1, it may lose some fine-grained control. But for some simple use cases
like CDN or cloud networks, it may be good enough.
[2]: https://datatracker.ietf.org/doc/html/rfc8519
[Qin Wu] Amazon S3 provide ACL like functionality,
https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html#sample-acl
But I feel it is more like user privilege authorization rather than traffic
filtering, e.g., allow user to write or read on some resource.
---
We are looking forward to seeing comments or suggestions on this open issue
from the WG.
Best regards,
Jensen on behalf of coauthers of ALTO O&M draft
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
