Authentication for referencing of person and role objects Abstract -------- This is a proposal regarding authentication of references to person and role objects. * Authentication for referencing of person and role objects o Abstract o Intended Audience o Introduction o Background o Details o Implementation o How to implement this in a large company or organisation. o For internal reference (not part of proposal) + Possible extension to the proposal Introduction ------------ There is currently no requirement to authenticate a reference to any person or role object in the database. This can lead to hijacking and the accidental or deliberate misrepresentation of responsibility for data. The database software already includes a mechanism for this type of authentication. References to organisation and irt objects must be authenticated. We propose to extend this list to include person and role objects. Background ---------- There are two ways a reference to the wrong person object can be made - accidental and deliberate. Accidental references can be made by mistyping. Maybe xy58-ripe instead of xy85-ripe. Even though it is accidental it can still cause confusion to anyone wanting to contact the responsible people for some data. Deliberate references to the wrong person may be made to avoid responsibility for use of address space. If someone is doing something nasty on the internet they have three options to try to avoid responsibility for a while. 1. Reference a person object with obviously stupid data in it. But anyone seeing a person object for Donald Duck will waste no more time looking further. 2. Reference a person object with false, but sensible looking data in it. But if a law enforcement agency is looking to make contact with the responsible party they will quickly find out if London Road in Southend has a number 147. If the address does not exist or the phone number does not match the address they will again quickly dismiss this false data. 3. Reference an existing, valid person object belonging to someone else. If a spammer references my person object, the police will come knocking on my door. I will say it has nothing to do with me, which of course I would say if I was the spammer. The police will then waste time investigating me while I try to prove my innocence. This wastes time as well as causing me problems. The RIPE NCC occasionally receives requests from LEAs for information about the responsible persons for address space. So this data is used in investigations. This proposal prevents any deliberate attempt to divert attention as well as avoiding mistakes. Details ------- The proposal is to add an "mnt-ref:" attribute to person and role objects. person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] org: [optional] [multiple] nic-hdl: [mandatory] [single] mnt-ref: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] abuse-mailbox: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] This attribute will specify mntner objects that can authorise a reference to this person/role object. This will only be required when a reference is added to an object. The "mnt-ref:" attribute is optional. The functionality will default to the "mnt-by:" when this new attribute is not present, or if authentication is not passed by any mntners in the "mnt-ref:" attributes. To add a reference to a person object as "admin-c:" of say an inetnum object, authentication will be required from a mntner listed in the "mnt-by:" of the inetnum object, as is the case now. In addition to this, authentication will also be required from a mntner listed in the "mnt-ref:" of the person object, if this attribute is present. If this attribute is not present, or non of the authentications passed, the mntner in the "mnt-by:" of the person object will need to authorise the reference. Implementation -------------- * All new person or role objects can be created with an optional "mnt-ref:" attribute. * Any person or role object can be modified to add an "mnt-ref:" attribute. After an agreed flag date, adding references to person or role objects will require the authentication of the person/role object. How to implement this in a large company or organisation. --------------------------------------------------------- Many organisations have several staff who make changes to their data in the RIPE Database. Their data may also reference many person objects of their customers. If these have been generated by the company on behalf of their customers and all have the same mntner as "mnt-by:", it is a simple matter to add the authentication for this mntner to all updates where a new reference is created. If the person objects have different mntners or are maintained by the customers themselves it requires a little bit more work to set up. One way to accommodate this is to create one new mntner object. Add a pgp key for each staff member to this mntner. Put this mntner in all the referenced person objects as the "mnt-ref:". Or ask all the customers to add this mntner for you. All these staff can now authorise references to all the person objects. If a staff member leaves simply remove their pgp key from the mntner. If a person does not want to be referenced they can either remove or not add this mntner to their person object.