Re: [alto] Open discussion on providing resource-level access control in ALTO O
Hi, Luis: 发件人: LUIS MIGUEL CONTRERAS MURILLO [mailto:luismiguel.contrerasmuri...@telefonica.com] 发送时间: 2022年12月20日 17:54 收件人: Qin Wu ; Jensen Zhang ; IETF ALTO 抄送: draft-ietf-alto-oam-y...@ietf.org 主题: RE: [alto] Open discussion on providing resource-level access control in ALTO O Hi Qin, It is not yet clear to me if the access control should have the granularity of resource-id or resource-type (there could be different resources of the same type being consumed by the client, in principle, so N:1 relationship). [Qin Wu] Good question, I am not sure access control is the right term, how it is different from ACL which is used to filter the traffic. I think the work flow should start from server discovery, and then establish secure channel with the server, and then get access to information such as various different resource, to allow access to information, HTTP authorization might be also required (e.g., https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization). The second question I made about the resource type is orthogonal to the access control topic, but probably interesting to discuss as well, maybe as a separate thread. [Qin Wu] Yes, I think network map, cost map and property map are three basic resource, it might be in the future, we can have hybrid map which mix several existing basic resource, I am not sure we have already one new resource in mind, A clear use case is required. Bets regards Luis De: Qin Wu mailto:bill...@huawei.com>> Enviado el: martes, 20 de diciembre de 2022 10:26 Para: LUIS MIGUEL CONTRERAS MURILLO mailto:luismiguel.contrerasmuri...@telefonica.com>>; Jensen Zhang mailto:jingxuan.n.zh...@gmail.com>>; IETF ALTO mailto:alto@ietf.org>> CC: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org> Asunto: RE: [alto] Open discussion on providing resource-level access control in ALTO O Jensen, Luis and all: I quote access control related requirements in RFC7285: “ An ALTO server requires at least the following logical inputs: o Security policies mapping potential clients to the information that they have privilege to access. The ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency. “ We need to make sure our designed solution meet the basic requirements in RFC7285. 发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO 发送时间: 2022年12月18日 5:36 收件人: Jensen Zhang mailto:jingxuan.n.zh...@gmail.com>>; IETF ALTO mailto:alto@ietf.org>> 抄送: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org> 主题: Re: [alto] Open discussion on providing resource-level access control in ALTO O HI Jensen, all, Regarding the access to information resources a couple of questions come to my mind. · What would be the roles you consider for accessing the info? In your proposed piece of model the role is assigned by resource-id, but maybe it could make sense to apply that also (or alternatively) per resource-type · Related to resource-type. The model defined three types so far: network-map, cost-map and property-map. I wonder if a kind of registry should be defined for that allowing a more generic definition of the resource types thinking on future extensions of ALTO where new types could be defined. What do you think? Best regards Luis De: alto mailto:alto-boun...@ietf.org>> En nombre de Jensen Zhang Enviado el: martes, 13 de diciembre de 2022 11:16 Para: IETF ALTO mailto:alto@ietf.org>> CC: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org> Asunto: [alto] Open discussion on providing resource-level access control in ALTO O Hi ALTOers, From the discussion about the ALTO O 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 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? 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
Re: [alto] Open discussion on providing resource-level access control in ALTO O
Hi Qin, It is not yet clear to me if the access control should have the granularity of resource-id or resource-type (there could be different resources of the same type being consumed by the client, in principle, so N:1 relationship). The second question I made about the resource type is orthogonal to the access control topic, but probably interesting to discuss as well, maybe as a separate thread. Bets regards Luis De: Qin Wu Enviado el: martes, 20 de diciembre de 2022 10:26 Para: LUIS MIGUEL CONTRERAS MURILLO ; Jensen Zhang ; IETF ALTO CC: draft-ietf-alto-oam-y...@ietf.org Asunto: RE: [alto] Open discussion on providing resource-level access control in ALTO O Jensen, Luis and all: I quote access control related requirements in RFC7285: “ An ALTO server requires at least the following logical inputs: o Security policies mapping potential clients to the information that they have privilege to access. The ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency. “ We need to make sure our designed solution meet the basic requirements in RFC7285. 发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO 发送时间: 2022年12月18日 5:36 收件人: Jensen Zhang mailto:jingxuan.n.zh...@gmail.com>>; IETF ALTO mailto:alto@ietf.org>> 抄送: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org> 主题: Re: [alto] Open discussion on providing resource-level access control in ALTO O HI Jensen, all, Regarding the access to information resources a couple of questions come to my mind. · What would be the roles you consider for accessing the info? In your proposed piece of model the role is assigned by resource-id, but maybe it could make sense to apply that also (or alternatively) per resource-type · Related to resource-type. The model defined three types so far: network-map, cost-map and property-map. I wonder if a kind of registry should be defined for that allowing a more generic definition of the resource types thinking on future extensions of ALTO where new types could be defined. What do you think? Best regards Luis De: alto mailto:alto-boun...@ietf.org>> En nombre de Jensen Zhang Enviado el: martes, 13 de diciembre de 2022 11:16 Para: IETF ALTO mailto:alto@ietf.org>> CC: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org> Asunto: [alto] Open discussion on providing resource-level access control in ALTO O Hi ALTOers, From the discussion about the ALTO O 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 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? 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 ... 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 --- 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 --- We are looking forward to seeing commen
Re: [alto] Open discussion on providing resource-level access control in ALTO O
Jensen, Luis and all: I quote access control related requirements in RFC7285: “ An ALTO server requires at least the following logical inputs: o Security policies mapping potential clients to the information that they have privilege to access. The ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency. “ We need to make sure our designed solution meet the basic requirements in RFC7285. 发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO 发送时间: 2022年12月18日 5:36 收件人: Jensen Zhang ; IETF ALTO 抄送: draft-ietf-alto-oam-y...@ietf.org 主题: Re: [alto] Open discussion on providing resource-level access control in ALTO O HI Jensen, all, Regarding the access to information resources a couple of questions come to my mind. · What would be the roles you consider for accessing the info? In your proposed piece of model the role is assigned by resource-id, but maybe it could make sense to apply that also (or alternatively) per resource-type · Related to resource-type. The model defined three types so far: network-map, cost-map and property-map. I wonder if a kind of registry should be defined for that allowing a more generic definition of the resource types thinking on future extensions of ALTO where new types could be defined. What do you think? Best regards Luis De: alto mailto:alto-boun...@ietf.org>> En nombre de Jensen Zhang Enviado el: martes, 13 de diciembre de 2022 11:16 Para: IETF ALTO mailto:alto@ietf.org>> CC: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org> Asunto: [alto] Open discussion on providing resource-level access control in ALTO O Hi ALTOers, From the discussion about the ALTO O 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 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? 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 ... 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 --- 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 --- 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 draft Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individu
Re: [alto] Open discussion on providing resource-level access control in ALTO O
ntp-service acl is used to configure the right for peer devices to access the
IPv4 NTP services on the local device.
See NTP ACL documentation example below:
https://techhub.hpe.com/eginfolib/networking/docs/switches/5710/5200-4997_nmm_cr/content/517710203.htm
My impression is both NTP client and NTP server are router or switch. ACL
provide network level access control for NTP peer.
Not sure it can be applied to ALTO case.
-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2022年12月14日 14:50
收件人: Jensen Zhang
抄送: IETF ALTO ; draft-ietf-alto-oam-y...@ietf.org
主题: Re: [alto] Open discussion on providing resource-level access control in
ALTO O
Hi Jensen,
For what it's worth, rfc 9249 (NTP Yang, which I am a co-author of..) uses ACL
for similar access control.
module: ietf-ntp
+--rw ntp!
+--rw port?inet:port-number {ntp-port}?
+--rw refclock-master!
| +--rw master-stratum? ntp-stratum
+--rw authentication {authentication}?
| +--rw auth-enabled? boolean
| +--rw authentication-keys* [keyid]
| +--rw keyid uint32
| +--rw algorithm? identityref
| +--rw key
| | +--rw (key-string-style)?
| | +--:(keystring)
| | | +--rw keystring?string {deprecated}?
| | +--:(hexadecimal) {hex-key-string}?
| |+--rw hexadecimal-string? yang:hex-string
| +--rw istrusted? boolean
+--rw access-rules {access-rules}?
| +--rw access-rule* [access-mode]
| +--rw access-modeidentityref
| +--rw acl? -> /acl:acls/acl/name
+--ro clock-state
Thanks!
Dhruv
On Tue, Dec 13, 2022 at 3:46 PM Jensen Zhang
mailto:jingxuan.n.zh...@gmail.com>> wrote:
Hi ALTOers,
From the discussion about the ALTO O 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
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?
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
...
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
---
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
---
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 draft
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Open discussion on providing resource-level access control in ALTO O
Hi, Jensen: 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jensen Zhang 发送时间: 2022年12月13日 18:16 收件人: IETF ALTO 抄送: draft-ietf-alto-oam-y...@ietf.org 主题: [alto] Open discussion on providing resource-level access control in ALTO O Hi ALTOers, From the discussion about the ALTO O 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 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 namestring +--rw password? ianach:crypt-hash +--rw authorized-key* [name] +--rw name string +--rw algorithmstring +--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 draft ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Open discussion on providing resource-level access control in ALTO O
HI Jensen, all, Regarding the access to information resources a couple of questions come to my mind. * What would be the roles you consider for accessing the info? In your proposed piece of model the role is assigned by resource-id, but maybe it could make sense to apply that also (or alternatively) per resource-type * Related to resource-type. The model defined three types so far: network-map, cost-map and property-map. I wonder if a kind of registry should be defined for that allowing a more generic definition of the resource types thinking on future extensions of ALTO where new types could be defined. What do you think? Best regards Luis De: alto En nombre de Jensen Zhang Enviado el: martes, 13 de diciembre de 2022 11:16 Para: IETF ALTO CC: draft-ietf-alto-oam-y...@ietf.org Asunto: [alto] Open discussion on providing resource-level access control in ALTO O Hi ALTOers, From the discussion about the ALTO O 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 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? 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 ... 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 --- 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 --- 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 draft Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Open discussion on providing resource-level access control in ALTO O
Hi Jensen,
For what it's worth, rfc 9249 (NTP Yang, which I am a co-author of..) uses
ACL for similar access control.
module: ietf-ntp
+--rw ntp!
+--rw port?inet:port-number {ntp-port}?
+--rw refclock-master!
| +--rw master-stratum? ntp-stratum
+--rw authentication {authentication}?
| +--rw auth-enabled? boolean
| +--rw authentication-keys* [keyid]
| +--rw keyid uint32
| +--rw algorithm? identityref
| +--rw key
| | +--rw (key-string-style)?
| | +--:(keystring)
| | | +--rw keystring?string {deprecated}?
| | +--:(hexadecimal) {hex-key-string}?
| |+--rw hexadecimal-string? yang:hex-string
| +--rw istrusted? boolean
+--rw access-rules {access-rules}?
| +--rw access-rule* [access-mode]
| +--rw access-modeidentityref
| +--rw acl? -> /acl:acls/acl/name
+--ro clock-state
Thanks!
Dhruv
On Tue, Dec 13, 2022 at 3:46 PM Jensen Zhang
wrote:
> Hi ALTOers,
>
> From the discussion about the ALTO O 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 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?
>
> 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
> ...
>
> 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
>
> ---
>
> 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
>
> ---
>
> 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 draft
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
[alto] Open discussion on providing resource-level access control in ALTO O
Hi ALTOers, >From the discussion about the ALTO O 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 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? 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 ... 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 --- 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 --- 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 draft ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
