Policy Proposal 2007-1 - Staff Assessment

[Member Services]

Policy Proposal 2007-1
Reinstatement of PGP Authentication Method

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.	Proposal

   Policy Proposal 2007-1 is available as Annex A below and at:
   http://www.arin.net/policy/proposals/2007_1.html

II.	Understanding of the proposal

   ARIN staff understands this proposal would support PGP authentication.

III.	Issues and concerns

   A.	ARIN Staff

     1.	We recommend that a new NRPM section be created, "12.
Communications", and that 12.1 be "Authentication". The subsequent
numbering would change appropriately.

     2.	The proposal uses the term "crypt-auth" as a notation to be
affixed to POC records. Such notation is not technically necessary for
ARIN systems to discern authentication methods, because mere existence
of a stronger-authentication method than mail-from can (and currently
does) automatically disable mail-from authentication.

     3.	Staff believes that there was a formatting problem with the
policy submission. It appears that the authors inadvertently
incorporated procedural text under the headings "UPDATES TO TEMPLATES",
"UPDATES TO DOCUMENTATION", and "KEY USE IN COMMUNICATION" under the
policy text labeled "12.3 X.509: This section intentionally left blank.”
If passed without edit, such procedural text could be incorporated into
the NRPM. Staff suspects this was not the author's intent, as these
headings and their subsequent text are not numbered.

     4.	In the section "KEY USE IN COMMUNICATION", the proposal requires
validation of "a chain of trust not longer than five steps" between the
signing key and ARIN's hostmaster role key, without regard to whether
such intermediary signers are ARIN POCs, or are even known to ARIN.
Without direct binding of the PGP key to an ARIN POC record, such
anonymity in the chain of trust raises serious questions about how ARIN
staff will know and evaluate that an e-mail from a signer is
authentically from the ARIN POC that the sender claims to be.

     5.	A PGP-key for hostmaster at arin.net exists on pgp.mit.edu as well
as other well-known PGP-key repositories.  This key was set up during
the early days of ARIN, and the passphrase for the key is, as of this
writing, MIA.  This prevents ARIN from using the key to sign anything,
and furthermore prevents ARIN from removing the key from the key
repositories mentioned above.  Although ARIN could proceed by generating
a new PGP-key, we would need to use a limited distribution mechanism
that excludes well-known servers, since more than one key for the same
e-mail address cannot exist in the key servers.  Such distribution might
occur at key-signing parties at ARIN meetings, et.al. so that persons
wanting to rely upon PGP-signed communications from ARIN can validate
using the proper key.  However, those individuals inadvertently using
the well-known repositories for ARIN's "old" PGP-key to encrypt their
communication with ARIN will likely get an "invalid signature" type of
response f rom ARIN since they have used a key that we cannot decrypt
(because the passphrase is MIA).   It is noted that all of these issues
regarding the lost passphrase can be overcome (and, is overcome in
generally accepted practice) by changing the e-mail address in question
that's bound to the PGP-key.  The difficulties introduced by changing
the well-known e-mail address of hostmaster at arin.net to some other
address makes such a change an unattractive option.

     6.	Currently ARIN uses two e-mail addresses, hostmaster at arin.net
and reassign at arin.net, to accept e-mail. The purpose for the
differentiation is primarily workflow-related: submissions to hostmaster
are generally handled manually while submissions to reassign are
generally able to be handled by automated software.  PGP-key best
practice dictates that each e-mail address have a separate key, and we
would implement according to this practice.  Staff notes that having two
keys, and two addresses, may create opportunities for confusion or
inadvertent misapplication of the wrong key to e-mails during functions
like verification or encryption (i.e. use hostmaster's key to encrypt a
submission to reassign).  The concern is partially ameliorated by the
fact that many MUAs will automatically select the proper key for
encryption or verification based upon the e-mail address, but staff is
aware that significant amounts of e-mail communication takes place
outside of typical MUAs (e.g., c  ustom scripts, etc.), leaving some
degree of concern.

     7.	The proposal text "ARIN shall PGP-sign all outgoing hostmaster
email with the hostmaster role key, and staff members may optionally
also sign mail with their own individual keys" implies that staff may
sign with arbitrarily-sourced individual keys.  We intend that if such
keys are generated, they would be signed with ARIN's hostmaster key and
controlled procedurally to maintain communication integrity between ARIN
and its customers, including publication of those keys in widely-known
repositories.

   B.	ARIN General Counsel

   Counsel has some concerns regarding liability that might be imposed
on ARIN to by proposed policy 2007-1. These concerns may be resolved
by 	explanation to cure my ignorance, or by editing if the concern
exists. My most specific concern is that ARIN 'validate a chain of trust
not longer than 5 steps"....I am concerned about fraud that may occur
somewhere in the 5 steps that is not detected by ARIN. I have been told
by techies that such an undetected fraud could easily occur. Does this
policy leave ARIN responsible for damages to third parties, including
our members, if it does not detect such fraud? It seems to me that
establishment of an overall ARIN policy of cooperating in using PGP does
not create this concern, but this specific language does. Is the
additional language integral to PGP and hence unusual and
unobjectionable? I apologize in advance if this is an instance where my
lack of technical knowledge creates confusion.

IV.	Resource Impact - Significant

The resource impact of implementing this policy is significant. Barring
any unforeseen resource requirements, this policy could be implemented
within 4-12 months from the date of the ratification of the policy by
the ARIN Board of Trustees. Implementation would not require the
acquisition of staff personnel or equipment. It will require the following:

- Template change
- Revision to Registration Software
- Revision to Directory Services
- Revisions to registration guidelines
- Staff training

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-1
Reinstatement of PGP Authentication Method

Proposal type: New

Policy term: Permanent

Policy statement:

ADDITION TO NRPM

12 Authentication Methods

12.1 Mail-From
This section intentionally left blank.

12.2 PGP
ARIN accepts PGP-signed email as authentic communication from authorized
Points of Contact. POCs may denote their records "crypt-auth,"
subsequent to which unsigned communications shall not be deemed
authentic with regard to those records.

12.3 X.509
This section intentionally left blank.

UPDATES TO TEMPLATES

ARIN shall update templates as necessary to identify and distinguish
between mail-from, PGP, and X.509 authentication methods.

UPDATES TO DOCUMENTATION

ARIN shall update documentation as appropriate to explain the
differences between mail-from, PGP, and X.509 authentication methods.

KEY USE IN COMMUNICATION:

ARIN shall accept PGP-signed communications, validate that a chain of
trust not longer than five steps exists between the signing key and the
ARIN hostmaster role key, compare the signing key to the identity of the
authorized POCs for records referenced in the correspondence, and act
appropriately based upon the validity or invalidity of the signature.

ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster
role key, and staff members may optionally also sign mail with their own
individual keys.

ARIN shall accept PGP-encrypted communications which are encrypted using
ARIN's hostmaster public key.

ARIN shall not encrypt any outgoing communications except at the prior
request of the recipient.
Policy Rationale

Rationale:

Globally, PGP is the most commonly used cryptographic authentication
method between RIRs and resource recipients who wish to protect their
resource registration records against unauthorized modification. The
PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC,
LACNIC supports an equivalent mechanism, and PGP was historically
supported by the InterNIC prior to ARIN's formation. By contrast,
current ARIN resource recipients have only two options: "mail-from,"
which is trivially spoofed and should not be relied upon to protect
important database objects, and X.509, which involves a rigorous and
lengthy proof-of-identity process and compels use of a compatible MUA, a
combination which has dissuaded essentially all of ARIN's constituents.
Additionally, X.509's centralized failure mode is technically and
ideologically repugnant to some members of the community, who should not
be forced to choose between two evils.

There isn't a lot of work to do here, and certainly nothing tricky. PGP
is simple code, which was supported by the InterNIC, and which the other
RIRs deployed without a second thought or complaint. If RIPE and APNIC
have always done this, the InterNIC did it before ARIN was formed, and
LACNIC and AfriNIC took the need for cryptographic security for granted
as a part of their startup process, we see no reason why ARIN should be
the only RIR to not offer this most basic of protections to its members.

We need to get PGP support reinstated, so that our records can be
protected against hijacking and vandalism, and so we won't look like
idiots as the only one of the five regions that can't figure this stuff out.

Timetable for implementation: Immediate