| >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