<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Denis and all,<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 15 May 2015, at 18:34, denis <<a href="mailto:ripedenis@yahoo.co.uk" class="">ripedenis@yahoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    <font size="+1" class=""><tt class="">Hi Tim and All<br class="">
        <br class="">
        Personalised authorisation is an idea I developed over the last
        few years. I talked to many people in the community about it at
        various RIPE meetings and started to build up support for my
        ideas. </tt></font></div></div></blockquote><div><br class=""></div><div><div class="">I believe that the WG appreciates your efforts on this, and remembers your presentation at RIPE 68:</div><div class=""><a href="https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pdf" class="">https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pdf</a></div><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><font size="+1" class=""><tt class="">The basic idea was to allow authorisation tokens in
        PERSON objects,</tt></font></div></div></blockquote><div><br class=""></div><div>Yes, the important point here is that the credentials are on PERSONs, rather than in one anonymous blob that is today's MNTNER.</div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><font size="+1" class=""><tt class=""> group these into ROLE objects and use the ROLE
        'instead of' a MNTNER. This is much more intuitive and better
        reflects real life business operations. The MNTNER object is an
        abstract construct that many people simply don't understand. The
        long term goal was to (possibly) eventually deprecate MNTNER
        objects.</tt></font></div></div></blockquote><div><br class=""></div><div><div class="">There are different opinions on how to refer to authorised persons.</div><div class=""><br class=""></div><div class="">The idea to use ROLEs instead of MNTNERs was presented again at RIPE 69, along side with the idea of just allowing to refer to PERSONs from MNTNERs: <a href="https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf" class="">https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf</a></div><div class=""><br class=""></div><div class="">There was no support from the room, nor in informal discussions with working group members, for the option of using ROLEs instead of MNTNERs. While the basic idea sounds attractive there are a lot of problems on closer inspection. MNTNER objects differ from ROLEs in a number of ways that make this, and the ultimate deprecation of MNTNERs difficult. Slides 13 lists what is missing from ROLEs, and would be needed to use them in an mnt-* context. Slide 14 lists what is missing from MNTNERs that would have to be made up, or made optional possibly with business rules enforcing behaviour (e.g. address may still be needed for a *-c referenced role), if remaining MNTNERs were to be converted into ROLEs. And if the latter isn't done, then we would have to live with mnt-* being allowed to refer to either a MNTNER or a ROLE (with special attributes turned on), for a long time, and this is hardly intuitive.</div><div class=""><br class=""></div><div class="">There was however support for the basic concept of extending MNTNERs with personalised organisation in a backward compatible way that requires no action from any of the over 50,000 maintainers in the database. The RIPE NCC was tasked with working out and presenting a new plan based on this resulting in the presentation given at RIPE70: <a href="https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf" class="">https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf</a></div><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><font size="+1" class=""><tt class=""> Trying to feed personalised auth into objects via
        MNTNERs, even worse through ROLEs and MNTNERs, is not only
        adding extra, unnecessary, layers of abstraction but making it
        even less intuitive and totally unrelated to real life
        situations.<br class=""></tt></font></div></div></blockquote><div><br class=""></div><div><div class=""><div class="">In this proposal MNTNER objects remain the specialised security objects that they are today, including features lacking from the normal contact-oriented ROLE object, but personalised authorisation is added with minimal changes to the schema to allow those users that want to make use of this to do so, without forcing any existing maintainer to be modified.</div><div class=""><br class=""></div><div class="">This is low hanging fruit.</div><div class=""><br class=""></div></div><div class="">Referring from an object to a MNTNER, and from that MNTNER to a number of authorised PERSONs does not add any layers compared to using a ROLE there instead of the MNTNER. And note that I did not favour using ROLEs in between MNTNERs and authorised PERSONs for this very reason, in response to your comment through chat during the WG session that this should be allowed.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><font size="+1" class=""><tt class="">
        <br class="">
        My original idea was to simplify the auth model and bring it
        closer to reality, adding extra, beneficial features, without
        losing any of the operational features currently available
        through MNTNERs....but without the need to use MNTNERs.
        Everything can be done with PERSON and ROLE objects...which
        people understand.<br class=""></tt></font></div></div></blockquote><div><br class=""></div><div><div class="">I honestly believe that the now proposed model does all this, the one thing people need to understand is that a MNTNER despite the name 'maintainer' being singular would be allowed to make explicit references to different PERSONs who do the actual maintaining.</div><div class=""><br class=""></div><div class=""><div class="">The MNTNER is like a ROLE for security context.</div></div><div class=""><br class=""></div><div class="">The MNTNER has extra things important to security like:</div><div class=""> - where do the alerts go?</div><div class=""> - where do the notifications go?</div><div class=""><br class=""></div><div class="">And it's lacking other things relevant to people looking to contact a group of people, but irrelevant when authorising a group of people. Such as: address, email, phone and fax.</div></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><font size="+1" class=""><tt class="">
        
        I had this all worked out in my head how to achieve all this,
        which is not technically very difficult to implement and not
        hard to understand and can be done in parallel with current
        MNTNER operation (so no one has to change if they don't want to).
        But I never wrote any of this down or presented any detail to
        anyone. So I would like to present an alternative option to the
        community, along the lines I was thinking and had discussed
        briefly with many people. It may take me a week or so to write
        it all out and present it as a RIPE Labs article.<br class="">
        <br class="">
        cheers<br class="">
        Denis Walker<br class="">
        Independent Netizen<br class="">
      </tt></font><br class="">
    <div class="moz-cite-prefix">On 15/05/2015 10:27, Tim Bruijnzeels
      wrote:<br class="">
    </div>
    <blockquote cite="mid:66A34212-F666-4C9A-8C3E-546032855D7A@ripe.net" type="cite" class="">
      <meta http-equiv="Context-Type" content="text/html;
        charset=us-ascii" class="">
      Dear working group,
      <div class=""><br class="">
      </div>
      <div class="">Yesterday during the WG session we presented a
        proposal for implementing personalised authorisation:</div>
      <div class=""><a moz-do-not-send="true" href="https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf" class="">https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf</a></div>
      <div class=""><a moz-do-not-send="true" href="https://ripe70.ripe.net/archives/video/123" class="">https://ripe70.ripe.net/archives/video/123</a></div>
      <div class=""><br class="">
      </div>
      <div class="">As recorded in the first cut of the minutes:</div>
      <blockquote type="cite" class="">
        <div class="">
          <div class="">D. Personalised authentication (Tim Bruijnzeels,
            RIPE NCC)</div>
          <div class="">  (See presentation)</div>
          <div class="">  This will allow one click creation of person
            objects</div>
          <div class="">  Maintain credentials in one place.</div>
          <div class="">  Allow better auditing.</div>
          <div class="">  Done by extending person object to have
            multiple optional auth: attribute</div>
          <div class="">  This will ultimately allow existing auth: sso
            references to be cleaned up</div>
          <div class="">  Last auth: attribute should not be removed
            from a person object that is used in an authorisation
            context.</div>
        </div>
      </blockquote>
      <div class=""><br class="">
      </div>
      <div class="">Apart from questions about possible additions below,
        there seemed to be general approval for the above as an addition
        to the existing maintainer mechanism.</div>
      <div class=""><br class="">
      </div>
      <div class="">We would very much like to implement this soon. We
        are already working on improving the way users can log in and
        use the web updates, and manage maintainers (and who is
        authorised for them), so having this would be extremely useful
        for that effort.</div>
      <div class=""><br class="">
      </div>
      <div class="">Technically I don't think the above has to depend on
        further extensions below. Roles can be added at any time that we
        consensus on them, and showing audit logs is a separate effort -
        building on this.</div>
      <br class="">
      <blockquote type="cite" class="">
        <div class="">
          <div class="">  Should this be extended to the role object as
            well? This would involve additional business rules but is
            technically possible.</div>
        </div>
      </blockquote>
      <div class=""><br class="">
      </div>
      <div class="">
        <div class="">I understand and fully agree that there is a need
          to maintain a list of authorised persons centrally. But in
          effect a maintainer can be used for this purpose. Multiple
          objects can be maintained by the same maintainer, and the list
          of persons authorised can then be managed on this single
          maintainer:</div>
        <div class=""><br class="">
        </div>
        <div class="">obj1    ---\</div>
        <div class="">            ---> mnt1  --->  pers1</div>
        <div class="">obj2    ---/           \-->  pers2</div>
        <div class=""> </div>
        <div class=""><br class="">
        </div>
        <div class="">In other words, just like role objects can group
          persons in a 'contact' context, 'maintainers' could group
          persons in a 'authorisation' context, where also other things
          such as "upd-to:" etc can find a home.</div>
        <div class=""><br class="">
        </div>
        <div class="">So, technically I don't think there is a need to
          have another role object here:</div>
        <div class=""><br class="">
        </div>
        <div class="">
          <div class="">obj1    ---\</div>
          <div class="">            ---> mnt1  --->  role1
             ---> pers1</div>
          <div class="">obj2    ---/                        \-->
            pers2</div>
        </div>
        <div class=""><br class="">
        </div>
        <div class="">Conceptually this can work of course, but it adds
          some complexity, and things to resolve:</div>
        <div class=""><br class="">
        </div>
        <div class="">a) referencing roles from maintainers, and
          authorised persons from roles</div>
        <div class=""><br class="">
        </div>
        <div class="">The proposal was to refer to authorised persons
          from maintainers like this:   auth:  person-<nichandle></div>
        <div class=""><br class="">
        </div>
        <div class="">Can we resolve this by allowing:</div>
        <div class="">  = auth:  role-<nichdl> on maintainers</div>
        <div class="">  = auth:  person-<nichdl> on roles </div>
        <div class=""><br class="">
        </div>
        <div class="">But no other auth: flavours for now.</div>
        <div class=""><br class="">
        </div>
        <div class="">Also note that this person is not necessarily an
          authorisation *contact* for others. If we follow current
          practice consistently we would filter this value for security
          purpose.</div>
        <div class=""><br class="">
        </div>
        <div class="">b) business rules regarding auth->role</div>
        <div class=""><br class="">
        </div>
        <div class="">Suggestion:</div>
        <div class="">- A role can only be added to a maintainer as
          "auth: role-<nichdl>" if it has at least one "auth:
          person-<nichdl>"</div>
        <div class="">- The last "auth: person" can not be removed from
          a role if it's referenced anywhere as "auth: role-"</div>
        <div class="">
          <div class="">- As before: "auth: person-<nichl>" can
            only be added if the person has at least one "auth:
            <something>"</div>
          <div class="">- As before: the last "auth:" can not be removed
            from a person if it's referenced anywhere as "auth: person-"</div>
        </div>
      </div>
      <div class=""><br class="">
      </div>
      <blockquote type="cite" class="">
        <div class="">
          <div class="">  It would be useful to record what credential
            (maintainer) was used to make a particular change to an
            object and this change</div>
          <div class="">  would facilitate this. RV was asked to raise
            this on the mailing list.</div>
        </div>
      </blockquote>
      <div class=""><br class="">
      </div>
      <div class="">Currently we do know internally which maintainer was
        used to submit a successful update, but not which credential.
        Technically this could be added of course. And in case of SSO or
        PGP people can get some idea of which user did the update. But
        showing which password hash was used for an update may not be
        best security practice.</div>
      <div class=""><br class="">
      </div>
      <div class="">With authorisation delegated to persons (possibly
        through roles) we will be able to give a much more better
        output. We can refer to the name of the person, rather than a
        credential that should be private to that person.</div>
      <div class=""><br class="">
      </div>
      <div class="">Also note that for any of this we will also need to
        be sure that the user viewing this information is authorised to
        see this. So what we had in mind here is to show this only on
        the web interface for logged in users authorised for at least
        one mnt-by of the object they are looking at.</div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
    </blockquote>
    <br class="">
  </div>

</div></blockquote></div><br class=""></div></body></html>