Authentication & Authorization
Shane Kerr
kerr at arin.net
Mon Mar 13 16:08:16 EST 2000
We've had some preliminary discussions about how we want authentication
and authorization implemented in the new ARIN database interface.
Attached please find a draft document discribing a proposal for this.
As well as general comments from this group, there are several specific
questions that need to be answered:
1. How should password recovery work?
As planned, access via the WWW will use SSL encrypted login & password.
There needs to be some sort of key recovery for this. This can be the
"mail me my password" model, the "mail me a hint" model, or the "you're
hosed, call support" model. We would very much prefer one of the first
two, to minimize the busy work our registration services group has to
do. Which would the community prefer?
2. Do we need to support encrypted e-mail?
The new system will support authenticated e-mail, but need not
necessarily support encrypted e-mail. This may be a requirement,
especially as people mail us what is effectively part of their business
plans, but it would be nice not to have to include this.
3. Is there a way to handle the Main POC leaving an organization?
Sed quis custodiet ipsos custodes? (Who watches the watchmen?) Is
there a way to handle the problem created when a trusted user is no
longer trusted?
Thanks for your feedback, comments, and suggestions!
--
Shane Kerr <kerr at arin.net>
Senior Software Engineer
American Registry for Internet Numbers
+1 703-227-9877
-------------- next part --------------
$Id: auth.txt,v 1.2 2000/03/13 20:56:05 kerr Exp $
External Authentication & Authorization in ARIN's New System
---[ Introduction ]-------------------------------------------------------
This document is an introduction to a discussion on how ARIN's new
interface will authenticate and authorize (A&A) Internet users.
Definitions, in the context of ARIN's database:
Authentication; the process where a user proves that they are
who they claim to be (e.g. proving that e-mail
is actually authored by the From person by
checking a PGP signature)
Authorization; the process where a user is granted permission to
see or modify information in the database
RIPE-NCC's has a simple model (see Appendix A), but there are
shortcomings for this system:
- It is based on an e-mail model
- It is very general purpose, so adding specific authorizations
is not possible
---[ Authentication ]-----------------------------------------------------
I propose our A&A system ties authentication to Point Of Contact (POC).
The following authentication methods may be supported:
Mailfrom; check From field, and if From matches the entry for
that user in the database, authenticate (e-mail only)
PGP; check PGP signature, and if signature can be verified using
the PGP public key in our database, authenticate (e-mail only)
SSL password; use a login/password screen, where the user
types in a password in a form which is ten sent
to a server over a secure HTTP connection (web only)
Authentication problems:
- "Mailfrom" is insecure, anyone with a telnet client can forge
this in almost any degree of untraceablity
- "PGP" is difficult, and non-free (requires RSA software, currently
patented in the USA for another year)
- "SSL password" requires users either update browsers or support
mere 56-bit encryption (I recommend we allow weak encryption),
requires ARIN to purchase SSL certificates, and is web-only
Authentication key recovery:
All secure methods require some sort of disaster recovery, in case
the secret key is lost somehow (hardware error, employee leaves,
etc.). For "PGP" we will have no way to do this, other than
installing a new public key. For "SSL password" we can use a
system where we e-mail either a "hint" to the user or the actual
password. In any case, we should provide a mechanism where ARIN
can "reset" a POC to having either no authentication or a known
authentication.
Authentication Questions:
- Do we care about encryption for e-mail (i.e. do we need to
accept encrypted e-mail, or is signed e-mail good enough)
---[ Authorization ]------------------------------------------------------
I propose our A&A system grants authorization based on an assigned role a
POC is fulfulling (i.e. billing-poc, technical-poc). The following roles
should be included. Unless otherwise specified, there may be multiple
POC's fulfilling the same role, and all roles are required to have at
least one POC (for a given object, these can all be the same POC).
POC roles:
A POC has the ability to change information about itself. This
includes contact as well as authentication information.
Note that a POC may assign any other POC to any role for records
they have authorization to modify. The assigned POC will be notified.
The potential to have POC's assigned without their prior approval is
considered preferrable to making the POC model more complicated.
Organization roles:
Main POC: The Main POC can change all information about the organization,
as well as any records owned by the organization. There is
only one Main POC per organization.
Membership POC: The Membership POC cannot make any changes. This is
strictly for ARIN's benefit.
Billing POC: The Billing POC cannot make any changes. A billing POC
should have the ability to review invoices, and make any
on-line payments that we allow. There is only one
Billing POC per organization.
There should be some means of handling the case where the Main POC leaves
the organization that they represent, possibly a "Fallback POC". There
doesn't appear to be any elegant way to support this (e.g. Who creates
the Fallback POC? How does it get changed? What happens when the
Fallback POC leaves?), but it should be considered.
Roles for other records (networks, AS numbers, DNS servers, etc.):
Technical POC: The administration POC can change the information in
the record, e.g. other POC's, address information. It
is also displayed in WHOIS.
Abuse POC: A contact for spam complaints, denial-of-service attack
reports, and so on, meant to be viewed in WHOIS. This is
an optional role.
A possible role for hierarchical records (IPv4 and IPv6 networks):
Reassign POC: The POC that can SWIP from a record. This is an
optional role (to reallocate a network, SWIP, then add a
Reassign POC to the new network; to reassign, just SWIP).
For heirarchical records, the administrator for the parent (either
the Technical POC or Reassign POC) can delete exising children,
regardless of the administrator of the children. The administrator of
the children (and their descendants) will be notified of the deletion.
---[ Other Details ]-------------------------------------------------------
Notification:
We can add a seperate notification mechanism, but should probably not
bother. I suggest that when any change is made on a record that a POC
is capable of making, that that POC be sent an e-mail notification.
This means that if I have multiple administrative POC's for a record
and one of the POC's makes an adminstrative change to the record, all
administrative POC's are sent e-mail notification. A Main POC will
be notified on the change of any Technical POC for records belonging
to the Organization for which it is Main POC.
Audit trails:
The new system will include a complete audit trail for the lifetime
of each record. This will record the time, user, authentication method
used, and nature of each change to the record. There should be no way
to ever delete this information.
POC deletion:
A POC need never be deleted. A POC not associated with any other
record should not be viewable in WHOIS or any other external mechanism.
It may be important not to delete these to prevent malicious users from
covering an audit trail by deleting their user record.
---[ Interface ]----------------------------------------------------------
Most user interaction will occur from the web. A user wishing to
administer or review information in our database will log in, either with
their e-mail address or their login name. (It is possible to have more
than a one login for a single e-mail address. In this case, the user
will be presented with a list of logins that match the e-mail.) If the
password is entered correctly, then they are presented with a list of
the records they can administer, grouped by type: Organization, IPv4,
IPv6, ASN, DNS server, RWhois server, and POC. All operations are then
taken based on the type of record they are modifying.
---[ Appendix A, RIPE-NCC's A&A Model ]-----------------------------------
This is a distillation and interpretation of the RIPE-120 document,
http://www.ripe.net/ripe/docs/ripe-120.html
Authentication has four methods for authentication, all based on
e-mail:
None; no authentication is required (always believe a template
which has a user listed as the sender comes from that
user)
Mailfrom; check From field, and if the From matches the
entry for that user in the database, authenticate
Crypt-PW; send password plain text, encrypt it on the server, and
if it matches the encrypted password for that user in
the database, authenticate
PGP; use a PGP signature, and if signature can be verified using
the PGP public key in the database, authenticate
Authorization is accomplished by tags on objects in the database;
Notify; if an object with a notify tag is changed, the user
is sent e-mail
Maint-by; if an object has a maint-by tag, the template that
is changing it must be from one of the maint-by
users
A maint-by user can do *anything* to the object. If an object has
no maint-by, anyone can do anything to the object. Any authenticated
user can make themself the maint-by for an object, and thereafter
only they can modify the object.
More information about the Dbwg
mailing list