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

Mon Jan 22 10:27:45 MST 2018

Thanks Doug.  I think you're right that it would be best to figure out this
static/dynamic problem as part of the effort to improve IP validation
requirements.  We want to be pro-active about making sure the methods we
approve actually have the appropriate level of security.

One of the partial solutions I've been thinking about is having some way for
the owner of an IP block to indicate whether control over a particular IP in
that block is sufficient to establish control going forward, or not.  IP
certificates are rare, and it would seem like for most of the use cases
where people want IP certificates, it would be ok to require the
organization to "opt-in" to IP certificates for a particular IP range.

As one example use case, it is not uncommon in payment networks for
retailers to avoid DNS attacks and vulnerabilities in DNS server software by
not using DNS, and just using static IPs for everything.  This often also
leads to easier to analyze firewall rules.  Using TLS in such an environment
requires IP certificates, but it would easy to declare that x.y.0.0/16 is a
block that uses static IPs and IP certificates are appropriate.

The biggest problem with this sort of solution is that the opt-in
information cannot be obtained from the IP being validated, as that IP is
(potentially) temporarily under the control of whoever is interested in
obtain an IP certificate for a dynamic IP they don't own.

I haven't thought about it much, but there should be a way to solve the
problem using reverse lookup.  The problem is finding something that will
work well with existing DNS servers and reverse lookup configurations, but
in theory, you can look at the entry for 34.12.y.x.in-addr.arpa and see if
there is a resource record that allows IP issuance.  However I believe
dangling non-PTR resource records on IP DNS entries is not common and may
not be well supported.

Following the PTR record, and doing a CAA climb to look for issueip tags
might work.

E.g.

x.y.12.34 -- reverse lookup on 34.12.y.x.in-addr.arpa -->
12.34.static.example.com

CAA lookup @ 12.34.static.example.com -> no records

CAA lookup @ 34.static.example.com -> no records

CAA lookup @ static.example.com -> 128 CAA ipallowed

We globally require this sort of checking as part of methods like 3.2.2.5 #1
which rely only on information obtained from the IP itself.

However, this is basically half-way to turning method #1 into method #3.  In
fact, if you then finish method #1, it *is* method #3.  In fact it's a more
secure version of #3 since the owner has explicitly opted in for IP
certificate issuance.

Just some ideas to think about.

-Tim

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Doug
Beattie via Validation
Sent: Monday, January 22, 2018 8:45 AM
To: validation (validation at cabforum.org) <validation at cabforum.org>
Subject: [cabf_validation] BR section 3.2.2.5: Authentication for an IP
address

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>  

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.globalsign.com_&d=
AwMFAg&c=qRq7a-87GiVVW7v8KD1gdQ&r=yL2kJgSsccUq5VcaUHiaiErHSMoqqBV4kmZtle8pI0
U&m=7LSnl4Q_Qu_BEe5I_P8WSvWs0evmNYHNhThvhJlrvzE&s=8HjQZHbWrcD_ik5cm6C2gK7iPz
U_KT9tF7RSZfrF1c0&e=> www.globalsign.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180122/a3e75dfa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180122/a3e75dfa/attachment-0001.p7s>