[ppml] Policy Proposal 2007-1 - Last Call

[Sandy Murphy]

A long response illicited by Ed Lewis's comment:

>Let's say I get someone to sign a key for me with an identity of Owen 
>DeLong.  If ARIN accepts that someone as a trusted introducer, then 
>how can ARIN distinguish between templates submitted by me signed 
>with my Owen key and templates Owen genuinely submits?


Summary: among the hardest parts of security, as the "recognized
security experts" Michael Dillon likes to point to <just how does one
recognize security experts, anyway - beanies? bowties?  But I
digress.> would probably tell you, are the trust model and key
management.

All of the following is based only on reviewing the ARIN documents
I've been seen on the web site; i.e., no actual experience.

Currently, the steps to getting and managing resources are:

(1) Establish POC
    - Send in a POC template
    - ARIN reviews this.  [1]
    - A response is sent.  [2]  Presumably the response includes the POC 
        handle, which uniquely identifies the POC.
(2) Establish an OrgID
    - Send in the Org template, which points to the POC handle
    - ARIN ensures that the requestor works for the organization [3][4][5]
(3) Request/Reallocate/Return/etc resources
    - Send in template, which points to POC handle
    - ARIN looks up POC Handle to see authentication type.  If authentication
        type is MAIL-FROM, ARIN checks the email message header From field,
        which must match the (or any) email address associated with the
        POC handle.

Note that what is being authenticated in Step 3 is the POC Handle, not
the identity.

Spoofable?  Certainly in Step (3).  Step (1), maybe, depending on what
ARIN does at this step.  The legal entity part of the verification of Step 2
is a matter of staff process (one presumes they are doing a great job) and
verification of the tie from Org to POC is hinted at in the text, but no
verification of the tie from POC to Org is mentioned.

     Caveats/Questionable parts:
            [1] It is unclear is ARIN does any identity verification
            at this point - I've heard people say No, but hearsay is 
            ... unreliable.
            [2] Oddly, the web site says "will notify the organization, via
            e-mail to the individual who submitted the request", although 
            there's not necessarily an organization tied to the POC.  Anyway,
            it's not clear if that email goes to the email address in the POC 
            template or to the email address from which the request came.
            [3] ARIN "requires written proof that the individual making the 
            request either works for the organization or has been authorized 
            to make the request."  But it doesn't say that the individual 
            making the request must be one of the POCs listed in the template.
            [4] ARIN "will notify the organization, via e-mail to the 
            individual who  submitted the request," which depending on the
            answer to the previous question may or may not be one of the
            POCs listed.  I'm not guessing that it is *all* of them.
            [5] Any verification that the Admin/Tech/Abuse POCs all agree 
            that they work for the organization?  Might be nifty to claim that 
            some well known person had agreed to serve in a role in my new 
            organization - say, an AC or BoT member.  Or someone I dislike.


When PGP is implemented:

(1) Establish POC
    - Send in POC template
    - Associate a PGP key with the POC template
        This will be a matter of staff determined process, and presumably
        will involve proof of knowledge of the private key.  
    - ARIN will check its trust in the key, hence the identity [6], by
        checking the signatures on the key and the length of the chain to 
        one of the introducers they trust.  Many times, there is also phone 
        contact to read off key footprint (additional proof of identity).
(2) Establish OrgID
    - Same as above
    - Note that, *IF* the Org request has to come from one of the POCs, 
        there is an opportunity here to get the request signed by one of the
        POCs.  Not all of them, of course, so there's still an issue
        of verifying the ties from POC to Org and from Org to POC.
(3) Request/Reallocate/Return/etc
    - Send in signed template, which points to POC Handle
    - ARIN looks up POC Handle, sees PGP as authentication type, gets the
        associated key and checks the signature.

      Caveats/Questionable parts:
             [6] Why does ARIN care about the identity?  I'm not positive,
             especially if ARIN does not currently verify identity on POC 
             template submission.  But if the Org request review involves 
             checking that all POC names actually work for the organization, 
             being careful about the identity makes sense.]


Note that what is being authenticated in Step 3 is still the POC Handle, not
the identity.

Spoofable?  Not easily in Step 3.  Even if Ed Lewis gets Careless Trusted
Introducer (oxymoron?) to sign a key saying he is Owen DeLong, and sends in a
template requesting some action for a resource for which Owen is the POC, the
signature won't check against Owen's POC Handle's stored key.  If Owen
loses his private key, though, all bets are off.

But it is spoofable in Step 1.  First, if ARIN has been sadly deceived in the
trust they place in one of their Trusted Introducers, there can be a problem
of accepting POC templates that refer to bogus identities.  Note that doesn't
create spoofing problems with existing POCs.  Secondly, if ARIN accepts
requests for rekeying (hey, ARIN, I lost the private key for my PGP key -
here is another PGP key identifying me as Owen DeLong which you should store
for POC Handle "Owen-Handle") without sufficient checking, then Step 3 ends
up being spoofable also.

So.  Trust model (who your trusted introducers are) and key management
(intial keying and rekeying) are places to be careful.

--Sandy