RE: Comments on the ACL Model draft

[Ryan Moats <jayhawk@att.com>]

| >| >Page 16:
| >| >
| >| >TECHNICAL:
| >| >
| >| >              Precedence of Privilege Attribute dnTypes within a scope
| >| >              (highest to lowest):
| >| >
| >| >                 - ipAddress
| >| >                   ^^^^^^^^^
| >| >
| >| >                 - access-id, kerberosID (both same precedence)
| >| >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| >| >
| >| >                 - group
| >| >
| >| >                 - role
| >| >
| >| >                 - subtree
| >| >
| >| >Requirement S6 of the requirements draft states:
| >| >
| >| >              S6.  Access policy SHOULD NOT be expressed in terms of
| >| >              attributes which are easily forged (e.g. IP addresses).
| >| >              There may be valid reasons for enabling access based on
| >| >              attributes that are easily forged and the
| >| >              behavior/implications of doing that should be
documented.
| >| >
| >| >Isn't use of ipAddress flaunting this?
| >|
| >| (EJS)  Not really.  The requirements document was put in place to serve
| >| as a guideline for writing the model draft, not as an explicit
| >| 'must follow' for writing the draft.  So some things in the
requirements
| >| are not in the draft and vice-versa.  This was explained at previous
| >| ldapext meeting.  Just because ipAddress is in the draft and an
| >| implementation provides it, doesn't mean that the deployment of the
| >| server needs to use it.
| >
| >Hang on.  I don't buy this (and I don't remember that particular LDAPEXT
| >meeting, but I might have been someplace else).  As I read SHOULD NOT, we
| >need a good reason for using ipAddress.  I don't see any documentation
| >of why ipAddress is supported in this draft.  At a bare minimum,
| >we should document (a) why ipAddress is being proposed and (b) make
| >a specific "Security Consideration" note about ipAddress being easily
| > forgable. I'd really like for support of ipAddress to be a MAY (with
| everything else in the list a MUST), since this document is standards
| >track.
| >
| >Ryan
|
| (EJS) OK, let's step back for moment and start this discussion again.
| So far, I think we've all agreed that the supported dnTypes are access-id,
| group, and role.  As for the addition of kerberosID, I haven't heard any
| violent objections - only that we should look at generalizing it and
| bringing it in line with the authmeth doc - and I'm looking into that.
|
| Now for other dnTypes such as ipAddress.  I agree that we should include
| a note in the Security Considerations section about it being
| easily forged. ipAddress is useful when all directory updates are forced
| from a given machine or network domain.  Given that this is an easily
| forged type, it's reasonable to ask the mailing list whether this type
| should be a MUST, SHOULD, or MAY, or perhaps remove it.  So I'd like to
| hear opinions ipAddress so we can reach consensus.

Seems fair to me (and you already have my opinion :-).

Ryan