Subject: RE: Confirm decision on identity handling.

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 15 May 2003 01:01:18 -0700

Paul is totally right on this one. From experience with Project Dploy, where
we tried to get better interop between IPsec vendors and PKI vendors after
talking to many customers about actual usage issues, this is what we found:
It is a daunting task for the deployers to get the cert contents to match
exactly what the VPN application needs. This is true for a variety of
reasons, many of which Paul noted below. The biggest is that often the VPN
deployer has little or zero impact/control/say in how the CA builds certs.
It's just not reality to expect that the VPN can dictate or ensure some
field in the Cert will contain what they need.

This is why many of us have been pushing for disassociating the two.

... [sarcasm ahead] or maybe we can just forget the whole issue because, in
reality, so few deployers even care to try to make certs work with VPNs
anymore because we have screwed it up so badly for them for so long ...

> So, yes you can make this work, but the likelihood of 
> interoperability quickly approaches zero. 

And there is a big difference between being able to be configured to be
interoperable, and being practically *usable*. Matching ID to something in
the cert CAN be done successfully, but actual deployment experience has
proven it almost impossible. Just ask the support teams from the major IPsec
vendors.

Lets try to build something people can actually USE this time, eh?

I vote for disassociating ID from cert contents. (BUT, I proposed text that
would allow for those who desired/required to be able to match if they
wanted to).

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 4:30 PM
> To: Scott G. Kelly; [email-masked]
> Subject: Re: Confirm decision on identity handling.
> 
> 
> At 3:18 PM -0700 5/13/03, Scott G. Kelly wrote:
> >Basically, every example given so far uses an ID value which can be
> >verified against the cert. Can anyone give a realistic 
> example of a case
> >where we would *not* want the ID to match something in the cert?
> 
> The ID can always match something in the cert. The question is 
> really, can we force the specific ID to match something in the 
> specific cert. In order to do so:
> 
> - The VPN administrator has to control the CA that issues the certs 
> so that he/she can get the right value into the right slot of the 
> certs. Sometimes this is easy, sometimes this is impossible (such as 
> when some other person in IT controls the CA and as a "better idea" 
> for how the identities in the certs should look, or when the company 
> has chosen an inflexible CA product).
> 
> - The user has to know which identities are in their cert.
> 
> - The UI for the user's VPN system (often client software) has to be 
> flexible enough to handle the different types of identities.
> 
> Even if those three requirements are met, the receiving software has 
> to know where in the cert to look for the identity. Email addresses 
> and FQDNs can be in either the Subject or SubjectAltName. And I've 
> even see IP addresses in the Subject, as the CommonName.
> 
> So, yes you can make this work, but the likelihood of 
> interoperability quickly approaches zero. Even if we said "the cert 
> must have the identities here", there is lots of CA software out 
> there that will ignore that new rule. Further, since lots of IKEv1 
> software will expect the certs to look differently, boxes that want 
> to speak both IKEv1 and IKEv2 may need (at least) two certificates 
> for the same identity. The admin interface for that situation will be 
> ugly, to say the least.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Eric Rescorla <[email-masked]>
Date: 15 May 2003 06:00:13 -0700

> would allow for those who desired/required to be able to match if they
The problem, then, of course, is that you've just made it near
impossible to make a system which works in the generic 
"I want to establish an SA with some I've never heard
of before" mode.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Eric Rescorla <[email-masked]>
Date: 15 May 2003 08:08:35 -0700

Paul Hoffman / VPNC <[email-masked]> writes:

> At 6:00 AM -0700 5/15/03, Eric Rescorla wrote:
> Could you explain why? For this scenario, how is binding an ID to the
> cert any different than ignoring the ID and getting an identity out of
> the cert?

Hmm... I see your point. I was speculating that this would mean
that you didn't much care what was in the certificate.

What would be the point of using an ID payload if you didn't
care what was in it?

-Ekr

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 May 2003 16:13:04 +0200

In your previous mail you wrote:

=> note this was the main argument against the full IPsec security
solution of Mobile IPv6...

Regards

[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 15 May 2003 08:29:35 -0700

Paul Hoffman / VPNC <[email-masked]> writes:

> At 8:08 AM -0700 5/15/03, Eric Rescorla wrote:
> You could have a security policy that ignored the identity in the cert
> ("allow an SA with these restrictions to anyone who has a cert from
> XYZRoot"), or one that was identity-based ("let [email-masked] make
> an SA").
But you would presumably want to have some restrictions
on the IP addresses they were allowed to front for, right?

-Ekr

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 15 May 2003 07:59:24 -0700

Could you explain why? For this scenario, how is binding an ID to the 
cert any different than ignoring the ID and getting an identity out 
of the cert?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 15 May 2003 08:43:06 -0700

>on the IP addresses they were allowed to front for, right?

Sure.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 15 May 2003 08:13:26 -0700

>that you didn't much care what was in the certificate.

You could have a security policy that ignored the identity in the 
cert ("allow an SA with these restrictions to anyone who has a cert 
from XYZRoot"), or one that was identity-based ("let 
[email-masked] make an SA").

>What would be the point of using an ID payload if you didn't

There isn't one.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 May 2003 14:30:14 -0700 (PDT)

> on the IP addresses they were allowed to front for, right?

Why? Are you thinking of this only in terms of
tunnels?

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 15 May 2003 14:43:29 -0700

> Why? Are you thinking of this only in terms of
No.

Many of the same considerations apply for machine to machine SAs.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 May 2003 14:48:42 -0700 (PDT)

> Many of the same considerations apply for machine to machine SAs.

Well, I don't see it. The desire to restrict or
permit based on header classification seems
completely orthogonal to the policy decision of
what constitutes "authenticated enough". Why
should a policy of "[email-masked]" have to be further
qualified with "from 1.2.3.0/24" as well? You
might want to do that, but then again you might
not. The former may be perfectly adequate
securitywise.

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 15 May 2003 15:14:14 -0700

Michael Thomas <[email-masked]> writes:

> what constitutes "authenticated enough".
Huh? Because I want to be able to have applications make security
decisions based on the IP address of the peer and that means that
the certificate has to be bound to the IP address.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 May 2003 15:22:19 -0700 (PDT)

> the certificate has to be bound to the IP address.

But that doesn't imply that has to be done in
every scenario. Suppose I set up a service at to
view pictures on a protected web site. I issue
certificates to my friends which allows them past
the IPsec barrier on my web server host. I don't
care who they are -- just that it's somebody who I
issued a cert to -- and most especially don't care
where they happen to have internet connectivity at
the time.

Are you saying this is an illegitimate use of
IPsec/IKE?

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 15 May 2003 21:06:52 -0700

> Are you saying this is an illegitimate use of
No, but I'd like to see the more complete case specified
and the case you're describing as a less complete variation
rather than simply ignoring the complete case as people
seem wont to do.

-Ekr

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 16 May 2003 10:28:26 -0400

> the certificate has to be bound to the IP address.

I jumped in late, so probably missed some important parts of this
conversation. But binding certificates to IP addresses doesn't
seem like a good idea at all, because of how short IP address
lifespan may be.

AFTER the authentication it may be reasonable to "fix" the IP
address to the just-established SA and dance from there for
the SA's duration... But that has little to do with certs.

If I really didn't get it, feel free to clue me in.

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 07:40:15 -0700

> seem like a good idea at all, because of how short IP address
Given the kind of information the stack has, there are many
cases where this is the only reasonable thing they might be 
bound to.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 08:09:13 -0700

Uri Blumenthal <[email-masked]> writes:

> > cases where this is the only reasonable thing they might be bound to.
> 
> 
> The only information - perhaps. That still doesn't make it
> reasonable. For example, (I know you anticipate this :-)
> think DHCP.
Think DHCP certificates :)

-Ekr

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 16 May 2003 10:53:18 -0400

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 May 2003 08:24:48 -0700 (PDT)

> cases where this is the only reasonable thing they might be 

Ok, I'll bite: what are some of those cases? It
can't be the actual IPsec SA since that's fully
described by the SPI (excepting multicast). And a
CA which issues a cert for [email-masked] is a
fully unique identifier, so I don't need
additional information in the form of the routing
tag to disambiguate the identity. So what
information is it that the stack is lacking that
would *require* use of an IP address in the
credential itself?

I'm with Uri. Binding IP addresses to certs sucks.
Think mobile IP.

	     Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 08:44:36 -0700

> would *require* use of an IP address in the
Huh? The user asks you to initiate a TCP connection to
1.2.3.4. How else do you propose to ensure that you've
done that other than by checking the certificate at
SA establishment time?

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 May 2003 08:54:54 -0700 (PDT)

> done that other than by checking the certificate at

You didn't answer my question. And I hardly know
where to start on the identity/routing tag
conflation you seem to be making. There isn't a
binding in IPsec between TCP connection -- or any
sort of transport connection -- and the SA
establishment, so your question is a non-sequitur.

IP addresses can be used as identities, but so can
RFC 822 addresses, etc. And IP addresses have huge
downsides, especially for mobility, unlike RFC 822
addresses. Any desire to use IP addresses as
identities should be considered harmful.

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 09:23:28 -0700

Michael Thomas <[email-masked]> writes:
> You didn't answer my question.
Obviously I didn't understand it, then. Try rephrasing it.

> And I hardly know
I'm afraid it's not. One of the major arguments in favor of
IPsec is that it allows security-oblivious applications to
be secured by enhancing the kernel. The only information
that the kernel has about the desired peer endpoint when
an application tries to transmit data is the IP address.
Therefore it's the only information on which the decision
can be made.

Yes, I'm perfectly aware that the SAs aren't bound to TCP
connections, but they can be bound to IP addresses and in
this case the difference is a red herring.

> addresses.
RFC822 addresses have the disadvantage that the kernel
doesn't know anything about them when you're trying to
transmit packets.

> Any desire to use IP addresses as
That's just, like, your opinion, man.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 10:09:23 -0700

Michael Thomas <[email-masked]> writes:
> Eric Rescorla writes:
> I think that what you're confusing here is the
> identity used to establish an SA and the general
> filtering mechanism that IPsec provides. It may
> be perfectly reasonable to have a policy which
> states:
> 
> "For all transport mode connections, the filters
>  should discard any source IP addresses != the IP
>  address used in the IKE session."
>
> Or something like this. Note that this doesn't
> have anything to do with the *IKE* identity, it's
> completely a property of the SA and its filters
> that were derived from the policy which matched
> for the mode and identity. It does, however,
> enforce the property that you desired above,
> especially when combined with the fact that you
> need several round trips which establish that that
> entity is, in fact, reachable at the outgoing
> address.
You must be joking.

What, you've never heard of active attacks? IP spoofing?

Much of the purpose of the exercise is to protect ourselves
from people who can arbitrarily manipulate the IP packet
delivery service.

> Again, you seem to be conflating the IKE session
> identity and the packet filtering mechanism of
> IPsec. 
It's not that I'm conflating them but rather that they're
bound by the logic of the desired security service. 

> Well, mine and a lot of other people's I'd say.
That's fine, but you haven't convinced me and it doesn't really
follow from anything you've said.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 May 2003 09:55:45 -0700 (PDT)

Mike

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 May 2003 14:05:54 -0400

Folks,

I've been listening to the discussion about whether there ought to be 
a requirement to match an asserted ID payload to any field in a cert 
that was passed in IKE, or maybe pre-configured into the SPD, etc.

I certainly can't dispute the bad experiences that Paul and Gregory 
have reported. But, I think we ought to back up from the mechanistic 
discussion (the "how") and try to figure out what problem we are 
solving (the "why") to see if we are heading down the right path.

One can imagine several models for what we want to accomplish by 
using certs for initial authentication in IPsec. I believe that we 
perform this authentication in order to make an access control 
decision. This assumes that we are generally NOT prepared to 
communicate with arbitrary peers. At a minimum we need to be able to 
determine their identity, and then use that to decide if we wish to 
communicate and if so, with what constraints. (This may be in 
conflict with the opportunistic encryption model of operation. If so, 
that may be a source of confusion, i.e., we don't agree on the 
problem we are trying to solve.  However, I don't know if this is an 
issue yet and I'll defer to Mike to say what he thinks on this topic, 
relative to my notes below.)

Note that there is a difference between not wanting to make an access 
control decision based on an authenticated identity, and wanting to 
make such a decision but not knowing the identity of specific peers 
in advance. The latter goal is easily accommodated using PKI 
technology, for example. The former is not well aligned with the 
overall thrust of IPsec, since IPsec is an IP layer security protocol 
in which access control is a fundamental service, not just an IP 
layer confidentiality or integrity protocol.

So, we need to explore the ways in which an ID established by a cert, 
with or without an ID payload, might be used in access control 
decisions. In IPsec, these decisions are centralized in the SPDs. 
But, what is the type, granularity, and scope of the cert-based 
authentication, i.e., what type and range of identities does the cert 
serve to verify, and to what SPD entries does it apply?

There has been discussion about the utility of different types of 
IDs, e.g., IP addresses, FQDNs, etc.  I don't want to add to that 
debate, since I believe that there are contexts on which each of 
these ID types is useful. So let's assume that we are dealing with 
any of these ID types in the following discussion, and focus instead 
on scope.

One might adopt a various models. In the examples below, when I say 
"valid cert" I mean an X.509 cert that can be validated relative to 
one or more pre-configured trust anchors in the responder. Recall 
that a trust anchor is a (CA) public key  and associated data that is 
used for cert path validation. (It need not be a self-signed cert, 
although that may be a convenient format.) When I say "assert an ID" 
I mean send an ID payload in IKE.

	1. when a peer presents a valid cert, one could allow the 
peer assert any ID and then compare it against any SPD entry. This is 
probably a bad idea in general, as it allows any configured TA to 
assert any identity without constraints. However, if you configure 
only one TA, and that TA is managed by the folks responsible for 
securing your environment, then even this simple case may be OK. It 
has moved all responsibility to that TA (CA) to ensure that the 
entities to which/whom certs are issued will only do "good" things. 
it really means trusting all these entities to not abuse the certs 
they have. Nonetheless, this does not strike me as a good approach 
for more general authorization requirements.

	2. when a peer presents a valid cert, one could allow the 
peer to assert any ID against any SPD entry that is linked to the 
cert. the linkage could be direct, e.g., a pointer to the cert in 
each SPD entry to which the cert applies, or it might be indirect, 
e.g., a pointer to a trust anchor from each SPD entry to which ... 
This model constrains the scope of the authenticated peer, allowing 
different certs or TAs to be applied to different SPD entries.  If 
the cert/SPD entry binding is 1-1, then there may be no security 
concerns here because the asserted ID may be irrelevant. If multiple 
SPD entries link to the cert, then the implications of the asserted 
ID may still be quite limited, based on which SPD entries are links 
to which certs. When a cert can apply to multiple SPD entries, then 
there is an opportunity to make use of an ID payload to match against 
a subset of these entries. For example, a TA might represent Company 
A, which issues certs to all its employees. When a company a employee 
tries to establish an SA to the Company B IPsec SG, the intent is to 
limit the access to that accorded to those employees.  But, within 
that context, different employees may have different permissions and 
thus have different SPD entries. The danger here is that an error in 
managing the cert/SPD entry table could allow one of these certs to 
be applied to other SPD entries that should be out of scope relative 
to the intended access control policy. if the goal is to allow 
assertion of different IDs for different authorizations relative to 
the Company A context, one could achieve the same goal by binding the 
certs for the individuals to the relevant SPD entries, but this would 
require much more management overhead. So, in this example, it does 
seem that there is benefit to asserting an ID separate from the ID(s) 
in the cert used in establishing the IKE SA. However, one might 
prefer to limit the range of IDs that might be asserted, e.g., by 
requiring the equivalent of name constraints to be applied to the 
asserted ID.

	3. when a peer presents a valid cert, and asserts an ID, one 
could require that the ID be matched to the Subject DN or to a 
Subject AltName. If we did this we would need to know how to map the 
asserted ID to the cert, i.e., which fields to compare and with which 
"matching rules." And, we still have to address the question of the 
scope of the cert validation. is it global, i.e., applies to all SPD 
entries, or is it linked to specific SPD entries? the latter case 
looks like #2 above, in terms of linkage options, but this time we 
apply some rules for matching. This is where #2 ended, discussing not 
direct matches but rather looking at matching rules like the name 
constraints extension. if the scope is global, then the cert may be 
implicitly linked to SPD entries, depending on the type of ID 
asserted. For example, a FQDN, 822Address, or DN would match only 
those SPD entries that used symbolic names for the IP address 
selector fields. If one used the name constraints extension in the 
configured trust anchors, this might be a fairly safe scope. But, 
without name constraints, any trust anchor could, in principle, issue 
a cert with any ID type and value and the resulting scope might not 
be any better than in #1 above.

I don't claim that this brief analysis resolves the question, but at 
least it may provide a context on which to clarify the discussions.

It seems that there are situations in which being able to assert an 
ID distinct from the cert used in the IKE exchange is valuable. So, I 
don't believe we ought to consider deleting that facility.

Rather, the problems seem to be how we describe the use of certs 
relative to SPD entries (something 2401 did not address), and what 
sort of matching rules we use
to decide if an asserted ID is valid relative to a provided cert. 
The problem I hear from Paul et al. is that often it is not possible 
for the administrators of IPsec systems to specify the data that CAs 
put into the certs that are exchanged (different unions?). if so, 
then it will be hard to take advantage of that data to constrain 
asserted IDs, and we need to make other provisions for achieving 
similar or equivalent scoping.  However, we might want to specify 
mechanisms for how to match ID against cert data, in a standard (vs. 
purely local) fashion, to facilitate interoperability and make this 
all more understandable when it is possible to take advantage of 
certs in a more sophisticated fashion.  We could make the former 
capabilities (for mapping certs to SPD entries) a MUST, as they will 
work in all cases, and the latter capability (matching rules for 
asserted IDs relative to certs) a SHOULD or MAY.

Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 May 2003 11:03:06 -0700 (PDT)

Eric Rescorla writes:
 > > Yeah, yeah, and the application starting the TCP
 > > connection got that IP address from DNS which
 > > isn't secure either.
 > What, you've never heard of DNSSEC?

Ah, I see we're in the land of pixies and unicorns.

Glad we've cleared that up.

	   Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 11:15:52 -0700

> Glad we've cleared that up.
Given that you're the one suggesting that we ought to ignore
known possible active attacks, the appropriate response seems
to be:

Pot. Kettle. Black.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 May 2003 10:54:10 -0700 (PDT)

Yeah, yeah, and the application starting the TCP
connection got that IP address from DNS which
isn't secure either. Them's the breaks when you
don't have tight binding between application layer
logic and the security layer. Is it better than
nothing? I'd say so. Thus we've already made our
peace with various active attacks and all kinds of
other insecure things that apps do in the global
scheme of things.

 > from people who can arbitrarily manipulate the IP packet

IPsec is an authenticated ACL traversal mechanism
not a miracle worker. It raises the bar
substantially, but there's a security/convenience
tradeoff that needs to be allowed. Tying
identities to routing tags has a substantial
number of drawbacks and leads us down some rather
unfortunate paths taken to its logical ends. Like,
oh say, ICAAN doling out IP address ownership
certificates. Ick. We also need to account for
deployability and unintended consequences.

 > bound by the logic of the desired security service. 

You're not acknowledging the engineering tradeoffs
that need to be accounted for. Very secure but
undeployable isn't a solution. More secure and
deployable often is, depending on the risks. Note
that there are other routes that can be taken to
shore up the security while using IPsec. An API
down to the kernel IPsec as well as keying layer
that apps could use would be an even larger
improvement on the security front than IP
addresses being used as identifiers. Regardless of
what layer crypto is being done at, this is what
is ultimately needed (and one thing that TLS has a
large advantage over IPsec, IMO).

	Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 11:02:45 -0700

> deployability and unintended consequences.
Strangely enough, this has worked just fine for TLS.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 May 2003 11:22:07 -0700 (PDT)

Eric Rescorla writes:
 > known possible active attacks [...]

Live With != Ignore. I'm interested in raising the
bar for security, not boiling the ocean. This
entire exchange is pretty much illustrative of why
security protocols are deployed so few and far
between.

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: 16 May 2003 11:36:10 -0700

Michael Thomas <[email-masked]> writes:

> bar for security, not boiling the ocean.
The belief that active attacks are important is part of the IPsec
threat model. IPsec is riddled with features that assume it to be the
case. If we were going to design a system that doesn't provide
protection against those attacks, we'd design an entirely different
system.

> This
And yet, strangely, the most widely deployed security protocol
in the world depends entirely on a universal PKI. 

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 May 2003 15:41:08 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
    Stephen> communicate and if so, with what constraints. (This may be in 
    Stephen> conflict with the opportunistic encryption model of
    Stephen> operation. If so,  
    Stephen> that may be a source of confusion, i.e., we don't agree on the 
    Stephen> problem we are trying to solve.  However, I don't know if this
    Stephen> is an  
    Stephen> issue yet and I'll defer to Mike to say what he thinks on this
    Stephen> topic,  
    Stephen> relative to my notes below.)

  We have specifically avoided PKIX certificates, preferring raw keys
in DNS reverse map, authenticated with SIG records for *precisely* the
problems that have come up. Solveable in theory, a disaster in practice.

    Stephen> "valid cert" I mean an X.509 cert that can be validated relative
    Stephen> to one or more pre-configured trust anchors in the
    Stephen> responder. Recall  
  
  One major deployment issue in IKEv1 with certificates is that numerous
vendors making configuring these "trust anchors" essentially impossible 
for the admin who owns the box, and they have very poorly documented what
they expect to be in the certificate.

    Stephen> 	2. when a peer presents a valid cert, one could allow the 
    Stephen> peer to assert any ID against any SPD entry that is linked to the 
    Stephen> cert. the linkage could be direct, e.g., a pointer to the cert in 
    Stephen> each SPD entry to which the cert applies, or it might be indirect, 
  This has always seemed like the best way to me.
  How do you link to the cert is a question, but there are many different
ways. I still think that this has the same problem that #3 has - it is
just now under the control of the gateway administrator.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: [email-masked]
Date: Mon, 19 May 2003 11:32:01 -0400

> "I want to establish an SA with some I've never heard

Many conventions need to be established to be able to establish SAs with 
someone you've never heard of before.

The easiest would be opportunistic encryption, where both ends would 
ignore both the ID fields and the cert contents (if any). There is no 
authentication. You have no idea who you're talking to. But you're 
protected from passive eavesdroppers.

To replace what SSL/TLS does, you would need a convention at least on the 
responder end as to what goes in IDs and/or certs. My recommendation for a 
convention would be that IDr is ignored, the responder's cert must pass 
whatever rules it must pass in SSL/TLS. I don't know whether those rules 
are spelled out in the spec, but I believe the convention is that the cert 
must have a CN= the DNS name the initiator was looking up. This is very 
un-IPsec like, because IPsec likes to pretend that DNS names are 
irrelevant. But I think it's what's most appropriate in this scenario. For 
initiator certs, I'd use the same rules as SSL/TLS. Except I don't know if 
there are any rules in the spec and in practice no one uses client certs 
with SSL/TLS other than in very specific (and probably non-interoperable) 
ways.

It's hard to use IPsec between gateways that have never heard of each 
other. The only access control they enforce is who can talk to who, and if 
they will allow parties they have never heard of to talk, it seems 
unlikely they are protecting against much.

        --Charlie

---

From: Paul Koning <[email-masked]>
Date: Mon, 19 May 2003 13:55:29 -0400

>>>>> "Charlie" == Charlie Kaufman <[email-masked]> writes:

 Charlie> ...To replace what SSL/TLS does, you would need a convention at
 Charlie> least on the responder end as to what goes in IDs and/or
 Charlie> certs.

Cynically... to replace what SSL does, you also have to build into the
product a set of certs that you've decided to use, and count on
customers not to be aware of this or worried by it.  :-)

	  paul

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 May 2003 23:19:45 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "VPNC" == VPNC  <Paul> writes:
    >> that you didn't much care what was in the certificate.

    VPNC> You could have a security policy that ignored the identity in the 
    VPNC> cert ("allow an SA with these restrictions to anyone who has a cert 
    VPNC> from XYZRoot"), or one that was identity-based ("let 
    VPNC> [email-masked] make an SA").

    >> What would be the point of using an ID payload if you didn't

    VPNC> There isn't one.

  The parties involved are not the same. You guys keep flipping between
"VPN" and "two random parties" in your discussion. 

  a) If the initiator doesn't know who it is talking to, then it can't 
     know if the responder will look at the ID payload or the CERT,
     so it should include both.

  b) if the initiator *does* know who it is talking to (it is
     pre-configured to talk to it), then the ID payload is probably more
     useful than the certificate, since they two parties have probably
     spoken before!

  Consider SSH-style leap-of-faith security with parties that are on the
phone with each other. 

  You initiator with some ID, along with a CERT payload. Responder records
them both - perhaps, because it is signed by a CA that the responder knows
and trusts, only the DN (WHATEVER it might be). The responder then stores
enough info, and the admin of the responder then adds some policy to it.

  Is this realistic? I've watched the SSH IPsec products do exactly this.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 20 May 2003 08:19:31 -0400

>"VPN" and "two random parties" in your discussion.

Sorry, but that's not true at all. I have consistently been talking 
about VPNs. (No surprise there.) In this thread, it seems like you're 
the one who is consistently speaking about "two random parties". (No 
surprise there, either.)

As shown above, a VPN with certificates where the receiving party 
doesn't know or care about the specific identity of the sending party 
can still let the sending be part of a VPN on the receiving party's 
system. These are not random parties.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 15:01:17 -0400

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> At 11:19 PM -0400 5/18/03, Michael Richardson wrote:
    VPNC> There isn't one.
    >> "VPN" and "two random parties" in your discussion.

    VPNC> Sorry, but that's not true at all. I have consistently been talking 
    VPNC> about VPNs. (No surprise there.) In this thread, it seems like
    VPNC> you're  

  I've barely commented :-)

  What I do hear is that the VPN has to work for two parties who have
picked random CAs, and can't control what goes into the certificate. That 
sure sounds like "rwo random parties" to me.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 20 May 2003 15:40:31 -0400

>sure sounds like "rwo random parties" to me.

We hear differently. No one creating a VPN (as compared to 
opportunistic encryption) can pick random CAs. For VPNs, there is a 
shared trusted CA.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 16:48:16 -0400

VPNC> At 3:01 PM -0400 5/20/03, Michael Richardson wrote:
    >> picked random CAs, and can't control what goes into the
    >> certificate. That sure sounds like "rwo random parties" to me.

    VPNC> We hear differently. No one creating a VPN (as compared to 
    VPNC> opportunistic encryption) can pick random CAs. For VPNs, there is a 
    VPNC> shared trusted CA.

  So, why is there a problem with telling the CA what needs to go into the
certificate?

---

From: "D. K. Smetters" <[email-masked]>
Date: Tue, 20 May 2003 16:05:21 PDT

Michael Richardson wrote:
>     VPNC> shared trusted CA
You might not control the CA you are using.  Even if you do, you might have
some constraints on what goes in the certificate imposed by some other piece of
(frequently broken) software that you also use that certificate with.  Or what
you put in the certificates to work with your previous VPN software might not 
work with your shiny new VPN software, and you might not want to reissue all 
your certs that still have a certain amount of time left on them.  Or you might 
not want to put ugly things into your current certificates to cope with the 
vagaries of the software you currently use with them, in the hopes you'll be 
able to get better software later. (Horror stories deleted in the interests of 
space.)

--Diana

====================================
D. K. Smetters
Member of the Research Staff
Palo Alto Research Center

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 19:38:57 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "D" == D K Smetters <[email-masked]> writes:
    >> So, why is there a problem with telling the CA what needs to go into the

    D> You might not control the CA you are using.  Even if you do, you might have
    D> some constraints on what goes in the certificate imposed by some other piece of
    D> (frequently broken) software that you also use that certificate with.

  Okay, so we have to do silly things with IKE*v2* so that a piece of
software, installed in only one place, for which there are multiple
commercial and open-source implementations does not have to be replaced.

---

From: "D. K. Smetters" <[email-masked]>
Date: Wed, 21 May 2003 18:55:08 PDT

> commercial and open-source implementations does not have to be replaced.

I don't see that "leave the final decision about whether the ID has to exactly 
match something in the certificate up to local policy" would be a horrible 
option for IKEv2 (or better, making such a match a suggested, but not required 
option).  It still lets correct software continue doing exactly what it's doing 
now, it just makes things a little more flexible to allow people to handle 
situations they might not have forseen when they issued their certs.
There are good arguments for both sides of this question (which have already 
appeared in this thread), but to rephrase a bit the argument for allowing a 
flexible mapping: Certificates are fairly long-lived objects, and whether they 
ought to be or not, they can be difficult to issue, or reissue if wrong (if 
nothing else, you have to touch all the clients).  And once they're issued, they 
can't be altered.  This means that the decisions I made for what to put into my 
certificates can have long-lasting repercussions, and may have to survive 
several changes of underlying software.  And even though there are pieces of 
software out there that do handle certificates correctly, there are even more 
that make incorrect assumptions about what certificates look like, that put 
constraints on what certificates you can use -- it's not just one piece of 
software installed in one place, unfortunately. (e.g. I'd love to have a quarter 
for every piece of software that assumes a cert can contain only one 
subjectAltName.).  And often people have a wide variety of constraints 
controlling their choice of software, well beyond its certificate handling 
capabilities -- they may be stuck with some piece of silly code for very good 
reasons. (Not to mention the fact that you may not find out the particular ways 
a piece of cert-handling code is broken until you've already gone fairly far 
along in dealing with it.) What seems to happen in practice is that facing these 
choices, they prefer to give up certificates than to give up the software that 
won't work with them.

--D