Subject: Question: SEND deployment scenarios with certificates

From: Pekka Nikander <[email-masked]>
Date: Tue, 22 Apr 2003 12:39:53 +0300

This is a question from the Design Team to the Working
Group.  We solicit input for the design task.

The current SEND design is primarily based on the idea
of using CGA to authorize hosts to use their IP addresses.
While CGA requires no configuration and scales well,
we understand that some people want to use certificates
to authorize hosts.

The purpose of this message is to solicit discussion and
information on deployment scenarios.  The goal is to help
us to really understand how host certifactes would be used
and what information  they shoud contain.  To structure
the discussion, I've included a number of questions,
based on my strawman  analysis of the situation.  The
questions can be found below, after the brief explanation
of the current situation.

Current thinking at the design team
-----------------------------------

The design team has tentatively decided to use RFC 3281
authorization certitifates as the mandatory mechanism
for certifying routers.  For SEND purposes, there would be
a new extension, enumerating the prefixes that the router
is authorized to advertise.  In the case that the issuer of
a certificate does not want to specify prefixes but just
indicate that the node in question is a SEND router, the
prefix of ::/0 is used.  In effect, that indicates that
a router is authorized to advertise any prefixes, and
therefore it is a router and not just a host.  The usual
mechanisms for checking authorization chains are planned
to be used.

The question now raises how to certify hosts.  While
routers are implicitly assumed to be trustworthy enough
to select their own addresses, hosts cannot be.  (This
follows the assumptions of the second trust model in the
psreq draft.)  Thus, a host certificate apparently should
include information that allows other hosts to decide
whether a given host is authorized to use a certain
address or not.

The limitation of requiring the certificates to contain
information about addresses seem to enforce us to a
situation where certificates would only be used in static
high security environments.  However, it is unclear if there
is any real need to use certificates in other environements,
and if so, what are the tradeoffs.

 From a strawman economic analysis point of view, issuing
host specific authorization certificates is fairly expensive
in terms of required administrative effort.  Thus, it seems
plausible to assume that in most cases they would not be used
in typical commercial environments.  But is it so?  What
kind of deployment scenarios can people see?  What do the
economic factors play in these scenarios?  (See below for
the concrete questions.)

Questions
---------

[In a way, the questions below are presented in a "reverse"
  order, starting from the technically most specific and
  going towards more generic questions concerning deployment.
  If you have a specific deployment scenario in mind, it may
  make sense to process the questions in reverse order.]

1. Certificate format and representing addresses in certificates

The current design team thinking leans towards using
RFC3281 as the mandatory mechanism, and specifying hosts
using the same extension as routers, but requiring that
the prefix contained is an address, i.e., that the prefix
is exactly 128 bits long.

This would allow the routers, or some other authorized
party holding such an certificate, to issue certificates
to hosts as a part of an automatic process.  It also follows
the idea that a certificate gives a node an authority to
assign addresses within the scope of the specified prefix.

There remains the problem of link local addresses, though.
It looks like only a local router can issue certificates
for link local addresses.  There cannot be any specific
authorization for link local addresses for any link, since
the prefix is always the same.  Thus, anyone certified as
a router can, in principle, further delegate the right to
use link local addresses.  On the other hand, is there any
benefit from using certificates for link local addresses?
Would it be better to use always use CGA for link local
addresses?

1.1) Would RFC3281 be OK for host certificates?
1.2) Is the idea for using /128 bit prefixes for hosts OK?
1.3) How should link local addresses be certified, or
      would CGA be enough for them?
1.4) Is it necessary to certify the whole address (as we
      currently assume), or would it be enough to certify
      just an interface ID?

2. Precedence between CGA and certificates

When both CGA and certificates are used, it is possible
(but very unlikely) that there would be a collision.
The easy approach is to require the CGA host to generate
a new address.  However, this leads to a variant of the
DAD denial-of-service attack.  That is, an attacker can
simply create certificates for each address that the CGA
host generates, and claim to be using them already.  If
the CGA host simply accepts the certificates without
checking that the certificates are signed by a properly
authorized key, the attacker could deny access to the CGA
host.  On the other hand, if the CGA host does check the
certificate chain to see that it is properly rooted, an
attacker can create very long certificate chains and
thereby force the CGA host to spend large amounts of
CPU cycles to check the chains.

2.1) How should collisions between CGA and certificates
      to be handled?

3. Issuing of certificates

In a typical case, the hosts are configured to trust
a number of root keys to authorize routers and hosts.
The authority to act as a router or to use a certain
address is then delegated from these keys, typically
via intermediaries.

Now, depending on the deployment scenario, it may make
sense to use different kinds of delegations.  Certifying
static hosts, such as servers with static IP addresses,
seems easy enough.  However, there is the problem of
handling mobile hosts and address renumbering.

3.1) Who (what node) would issue hosts certificates?
3.2) What kind of authority should that node have?
3.3) How to handle renumbering?
3.4) How to handle mobile hosts?

4. Deployment scenarios

All of the questions above really corner around the
question of what is the deployment scenario.  We
(or at least I) can easily understand how to handle
the case of static hosts with static addresses and
just a few prefixes.  In that case, the hosts would be
configured with a single certificate authority, and
all hosts would be issued with a direct certificate,
explicitly enumerating their addresses, the link local
address included.  Alternatively, instead of having
direct certificates, there might be a short certificate
chain, consisting of maybe 1 or 2 intermediary CAs.

However, what I don't understand, and what we would
like to understand better are alternative scenarios.
How people would actually use host certificates in SEND.
Here we are open to suggestions, and I haven't written
down any specific questions.

--Pekka Nikander
   on the behalf of the DT

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Apr 2003 14:32:06 +0300 (EEST)

> Group.  We solicit input for the design task.

IMO, it's too early to answer most questions.

Please work on resolving the IPR issue with Microsoft first and/or declare 
attempts unsuccesful.

Thanks.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 22 Apr 2003 16:43:14 +0300

Pekka Savola wrote:

> Please work on resolving the IPR issue with Microsoft first and/or
> declare attempts unsuccesful.

IMHO this is mostly independent on the IPR issues.

Or at least one way to restate the question is that
how would *you* use host certificates even if you
can use CGA without IPR worries.  That is, if you
have administrative reasons that mandate you to use
certificates, what would those be?

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Apr 2003 11:15:06 -0700

Hi Pekka,

Though I can't claim to have any large deployment insight, I don't see
host certs, other than the self-signed certs that Tumos specifies for
CGA, as playing a large role in the near future. The "end host cert
provisioning problem" (often subsumed under the name "global PKI") is
a major bottleneck right now for reliable, end to end security, and I
don't see much on the horizon that could help resolve it.

For initial deployments of SEND, I see routers being provisioned with
certs and hosts being provisioned with root CA certs, which they then
use to validate the routers. This is isomorphic to the "host with
collection of root CA certs authenticates server" model that has
proven deployable in the Web. CGA is important because it provides
security on ND when this model is used for RD, thus avoiding the need
for end host certs.

This doesn't mean that the SEND spec should ignore end host certs, but
I believe the assumptions it makes about them should be fairly
conservative, to avoid locking something in that might not be
deployed.

Further down the road, if the end host cert provisioning problem is
solved, certs for end hosts might become more deployable. One possible
step in that direction is some design work getting started in 3GPP to
use their SIM-based AAA to deploy end host cert distribution. This
might help to bootstrap end host PKI.

            jak