From kerr at arin.net  Tue Mar  7 10:51:34 2000
From: kerr at arin.net (Shane Kerr)
Date: Tue, 07 Mar 2000 10:51:34 -0500
Subject: [Fwd: RWhois mailing list scour results]
Message-ID: <38C52586.18C3BA28@arin.net>

Here's an e-mail I put together for our internal use last month, about
RWhois.

-------- Original Message --------
Subject: RWhois mailing list scour results
Date: Mon, 07 Feb 2000 13:55:58 -0500
From: Shane Kerr <kerr at arin.net>
Organization: American Registry for Internet Numbers
Newsgroups: arin.eng

I did a pretty thorough scouring of the RWhois mailing list archive held
on http://www.rwhois.net - not a recommended way to spend time.  :( 
Anyway, here's a rough outline of what goes on there:


o What info needs to be in the RWhois server?

People just don't know what information ARIN needs from them!  It's a
reoccurring theme.  This *really* needs to be documented.  People have
asked for a schema file, people have commented that ARIN doesn't know
what it wants!


o Why doesn't the server forward queries?

This doesn't work, and never has.  Apparently some people think that
*we're* going to be fixing this (joke's on them).  The IPv6 folks may
have a patch that not only adds IPv6, but also forwarding.

http://www.isi.edu/~sekiya/rwhois/rwhoisd-1.5.3-ipv6-1.diff.gz


o Does registering your RWhois server at ARIN do anything for you?

People want us to update our WHOIS output and IN-ADDR.ARPA based on the
contents of their RWhois servers.  In my mind, DNS should be delegated
at the lowest level possible, not the highest (ARIN).  I suppose we
could look at consolidating our RWhois and WHOIS information, though.


o Does APNIC or RIPE-NCC accept RWhois for reassignment information?

APNIC does not.  The RIPE response is a bit of a jab:

"the RIPE NCC doesn't use rwhois either. For much the same reasons as
APNIC and also the fact that no-one here seems to be interested in it
(our current system works)."

Ouch!


o How do I designate private information in my RWhois database?

There's a long, complicated answer to this that should be documented on
ARIN's site.


o Where do I register my RWhois server?

Need to document this, and probably how the forwarding of e-mails
actually works.  Also, the e-mail in our documentation
"rwhoisreg at internic.net" does not exist anymore.


o How does ARIN use the RWhois information?

Need to document the actual process of using RWhois to verify space
utilization for the customer, unless this is some secret.



Other stuff:

There is a Perl module for RWhois, written by David Blaka over at NSI:

ftp://ftp.rwhois.net/pub/Net-Rwhois-0.04.tar.gz

There is constant wondering why RWhois is used, and not something more
widely accepted (LDAP, whatever).  

Personally, I think using standard HTTP/CGI/HTML as a protocol/output
and standardizing the schema to be used by such would be a better
approach.  Look ma, no client!


--
Shane Kerr <kerr at arin.net>
Senior Software Engineer
American Registry for Internet Numbers
+1 703-227-9877


From dploher at level3.net  Tue Mar 14 11:18:10 2000
From: dploher at level3.net (Darren Loher)
Date: Tue, 14 Mar 2000 16:18:10 +0000
Subject: Authentication & Authorization
In-Reply-To: <Pine.LNX.4.10.10003131557270.23311-200000@localhost.localdomain>; from kerr@arin.net on Mon, Mar 13, 2000 at 04:08:16PM -0500
References: <Pine.LNX.4.10.10003131557270.23311-200000@localhost.localdomain>
Message-ID: <20000314161810.D16021@zed.eng.level3.com>

On Mon, Mar 13, 2000 at 04:08:16PM -0500, Shane Kerr wrote:
> 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?


I vote for the mail me a hint model.  


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

I believe that ARIN should make their public PGP key available on the 
pgpkeys.mit.edu keyserver as well as on their web page.  This will allow 
ARIN customers to send you encrypted mail if they are so inclined.  This
would be very good when IP Justifications are sent in.  I would really
like to see ARIN accept encrypted mail like this.

However, I don't believe there's nearly as much a need for ARIN to be able
to send customers encrypted mail.  I do not believe encrypted email is 
required for normal correspondence, such as updating the ARIN whois
database and so on.


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


This issue could be helped if there was more than one point of contact
for a netblock.  Something like an abuse contact and a ip-administration
contact would be great.  

This would give us ISP's a better way to direct abuse/security related mail 
and IP Administration mail.  The great side effect of this is with two 
contacts, if one leaves, the other contact could still be authorized to 
update their record(s).  



-- 
Darren Loher                 Level 3 Communications
dploher at level3.net           Global Data Engineering
720-888-2847 (office)


From kerr at arin.net  Mon Mar 13 16:08:16 2000
From: kerr at arin.net (Shane Kerr)
Date: Mon, 13 Mar 2000 16:08:16 -0500 (EST)
Subject: Authentication & Authorization
Message-ID: <Pine.LNX.4.10.10003131557270.23311-200000@localhost.localdomain>

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.