RE: Comments on the ACL Model draft

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