[cabf_validation] BR section 3.2.2.5: Authentication for an IP address

[Doug Beattie]

I was thinking of sending this to the public list, but figured I should start here first.  Any comments or input?

===================

The Validation WG has been discussing changes to section 3.2.2.5 to remove the "any other method" for the validating of IP addresses in section 3.2.2.5.  Initially I was thinking that we should use the approved method in 3.2.2.4 and apply them to 3.2.2.5 and remove the any other method; however, after the discussions regarding .9 and .10, I'm starting to have concerns about identifying secure IP address validation methods.

When IP addresses can be assigned dynamically, for example by ISPs, you can demonstrate technical control over an IP address today, but that doesn't mean you will have it tomorrow.  Does that bother anyone else?

While technical controls for domain validation are very good and the manual methods under question, it seems like quite the opposite for IP addresses.  If an organization has an IP address block assigned to them for their exclusive use, then it seems better to consult IANA or Regional Internet Registry to verify assignment than to permit something like "agreed-upon change to web site" which demonstrates they have control now, but not necessarily in the future.  Perhaps we should tend to favor methods 1, 2 and 3 over the others?


Here's a quick summary of how I can see those methods in 3.2.2.4 applying to 3.2.2.5:

To start with, define a new term:

-          IP Address Authority: An entity that provides documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).


3.2.2.4.1  Validating the Applicant as a Domain Contact

-          We could use an IP Address Authority to verify the Applicant owns these IP addresses, similar to how we use Who-is for domains.  Has the same issues as those being discussed on the list now, but if method 1 remains in some form, then the same approach could be used for IP addresses.
3.2.2.4.2  Email, Fax, SMS, or Postal Mail to Domain Contact

-          We use IP Address Authority and then email the registered IP address "owner".  This seems like a good option.
3.2.2.4.3 Phone Contact with Domain Contact

-          We use IP Address Authority and then call the IP address "owner".  This also seems like a good option.
3.2.2.4.4  Constructed Email to Domain Contact

-          Not applicable for IP addresses
3.2.2.4.5 Domain Authorization Document

-          Since this is being removed from the BRs, let's not contemplate it.
3.2.2.4.6 Agreed-Upon Change to Website

-          This could work the same way as domain validation
3.2.2.4.7 DNS Change

-          Not applicable for IP addresses
3.2.2.4.8 IP Address

-          Do a reverse IP address look-up and then validate that domain using a method in 3.2.2.4
3.2.2.4.9 Test Certificate

-          Confirm presence of a Test Certificate on the IP address.  Since we take SNI out of the equation, is this sufficiently secure?
3.2.2.4.10. TLS Using a Random Number

-          Same question as 9.

Methods 4-10 have the underlying issue that the entity demonstrating technical control over the IP address today may not have it tomorrow.  While methods 1-3 can be subject to the same issue if IP address blocks change ownership, it might not be as bad.

Comments?

Doug Beattie
Vice President of Product Management
GlobalSign
Two International Drive | Suite 150 | Portsmouth, NH 03801
Email: doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>
www.globalsign.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.globalsign.com_&d=AwMFAg&c=qRq7a-87GiVVW7v8KD1gdQ&r=yL2kJgSsccUq5VcaUHiaiErHSMoqqBV4kmZtle8pI0U&m=7LSnl4Q_Qu_BEe5I_P8WSvWs0evmNYHNhThvhJlrvzE&s=8HjQZHbWrcD_ik5cm6C2gK7iPzU_KT9tF7RSZfrF1c0&e=>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 27617 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180122/285755af/attachment-0001.bin>