Hi Jeffrey,
Thank you for your feed back. We considered them - with all other feed
backs we received. We believe the new version address all of them. Feel
free to let us know if we missed something. Here is a small recap of the
modifications performed to address your comments.
BR,
The co-authors
I have some contrary thoughts on the AAA section of this document.
MGLT: The AAA section has completely be re-written.
Section 4.1 tries to describe requirements wherein the I2RS Clients may
request for subsets of AAA policy to be exported to the Client so that the
client may enforce them. While this seems like a nice way to scale the
operations, in some cases disclosing those policies (even if we find a good
way to encode the AAA validation in a generic enough way to distribute) may
accidentally disclose information that is otherwise intended to be secure.
MGLT: Thanks for pointing out this issue. Information leakage has been
added in the document as something to balance with a distributed access
control system.
I would seek comment from the security directorate, but I suspect we don't
want to do this.
But in section 4.4, we try to discuss availability. The first sentence
immediately says "enforcement should not remain local", while one way to
enable security in some environments is to distribute and synchronize
policy to be enforced locally.
It then goes on to talk about general availability mechanisms and then we
further dive into security against DoS.
MGLT: I agree with the comment. The section 4.4 has been removed and all
DoS specific consideration has been keept in a specific section to make the
document more coherent.
4.4. I2RS AAA Security Domain . . . . . . . . . . . . . . . . 12
4.4.1. Available I2RS Communication Channel . . . . . . . . 12
4.4.2. Trusted I2RS Communications Channel . . . . . . . . . 14
Have been removed.
I believe we may be boiling the ocean a bit to try to go into too many
details about the design of secure AAA systems. It seems a bit out of
scope for I2RS to do such work; we should defer to work done elsewhere on
the topic, if it exists. If it doesn't exist, I'm not sure we should do it.
What is right for us to point out is, "If we use a remote AAA mechanism, it
must be robust in hostile environments". Expand that as you will, but
being too proscriptive is not our job.
MGLT: I agree with the comment. I hope the new version of the section
address your comment.
On Thu, Aug 27, 2015 at 5:33 PM, Jeffrey Haas <[email protected]> wrote:
> I have some contrary thoughts on the AAA section of this document.
>
> Section 4.1 tries to describe requirements wherein the I2RS Clients may
> request for subsets of AAA policy to be exported to the Client so that the
> client may enforce them. While this seems like a nice way to scale the
> operations, in some cases disclosing those policies (even if we find a good
> way to encode the AAA validation in a generic enough way to distribute) may
> accidentally disclose information that is otherwise intended to be secure.
>
> I would seek comment from the security directorate, but I suspect we don't
> want to do this.
>
> But in section 4.4, we try to discuss availability. The first sentence
> immediately says "enforcement should not remain local", while one way to
> enable security in some environments is to distribute and synchronize
> policy
> to be enforced locally.
>
> It then goes on to talk about general availability mechanisms and then we
> further dive into security against DoS.
>
> I believe we may be boiling the ocean a bit to try to go into too many
> details about the design of secure AAA systems. It seems a bit out of
> scope
> for I2RS to do such work; we should defer to work done elsewhere on the
> topic, if it exists. If it doesn't exist, I'm not sure we should do it.
>
> What is right for us to point out is, "If we use a remote AAA mechanism, it
> must be robust in hostile environments". Expand that as you will, but
> being
> too proscriptive is not our job.
>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
