Subject: RE: Confirm decision on identity handling.

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 15 May 2003 09:58:53 -0700

> 
> At 8:29 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?
> 
> Sure.

you could, but there are plenty of cases (the roaming user) where there is
no need. Those of us advocating the disassociation are not saying 100%
disassociate. We are saying make the base-line MUST disassociation, but
allow the user's the ability in configuration to associate and look for ID
in a certain place in the cert IF THEY WANT. That way, the 10% of the cert
users that want to associate will get what they need, and the rest of the
90% will have something that works easily. 

This is the basic convenience vs. security continuum. Our job as protocol
designers is to give the people something they can use. 20% want it super
secure at the cost of convenience. 80% want it secure, but convenient, and
are willing to make the trade-off from the super-secure. The text I proposed
tried to reach this goal.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 15 May 2003 13:35:04 -0700

Hi Gregory,

Gregory Lebovitz wrote:
<trimmed...> 
> tried to reach this goal.

In terms of convenience, I can't think of a more convenient way to
configure a cert-authenticated tunnel for an ipsec client than by saying
"use this cert" and leaving it at that. Having to select a cert *and* an
ID is not simpler than just selecting a cert. This may be slightly less
convenient for the one who codes the receiver (since the receiver now
has to extract an ID from the cert prior to doing a policy lookup), but
forcing the client configuration to contain an ID acceptable to the sgw
is not, but any stretch, more convenient than this. And leaving off the
ID config is more secure in some cases as well.

Scott

---

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

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

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> In terms of convenience, I can't think of a more convenient way to
    Scott> configure a cert-authenticated tunnel for an ipsec client than by
    Scott> saying "use this cert" and leaving it at that. Having to select a
    Scott> cert *and* an 

  I agree with you here.
  But, I think that you still want to drop the IDi payload here.
 
  Can we add something like the hash of the public key (or cert) here as the
ID? 

  That can be derived automatically by the client, and it provides a hook
by which a server might be able to lookup the right key, should it find the
certificate itself not to its liking.

  I really do not want to make the IDi optional.

]       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: Ravi <[email-masked]>
Date: Fri, 16 May 2003 11:24:40 +0530

Hi,

I am trying to understand the issues. Some time back, there was
rough consensus that 'Matching ID payload data with certificate
Identification' is local matter as a receiver. As a sender,
implementation need to make sure to send ID payload data same as
Certificate ID as the receiver may be checking for equality of both IDs.
If the sender knows that receiver does not check for the equality, then
the sender can send different IDs between ID payload from certificate
ID.

Some implementations already do this for supporting remote access.
In remote access, road warriors are initiators and Corporate SG is
typically configured in 'Responder' only mode. One IKE policy is
created with
           - Wild card domain name as peer ID.
             For example, *.abc.com can be give as Peer ID.
             Then all remote access users whose IDs are ending with 

             abc.com will be authenticating using this IKE policy.

          -  Accept any whose signing CA is 'DN of CA'.
             This is typically useful when corporate office has their own
             CA and anybody got certificate from this CA is authenticated
             using this policy.

In above examples, really there is no check between ID payload and
Certificate in verbatim. It is local decision.

Can't we leave the decision of IDs check as local decision? What type of
additional simplification are we trying to make it for easy deployment?
Thanks and regards
Ravi

-- 

The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 16 May 2003 11:34:17 -0700

Ravi wrote:

<trimmed...> 

> Certificate in verbatim. It is local decision.

No, in this case which policy is used is the sender's decision. If
you'll accept any cert from your CA, and you have one policy for abc.com
and another for def.com, what assurance do you have that the presenter
is who he claims to be?

The point is that for remote access, the IP address is not known a
priori, so the only way to configure a policy for a remote access user
at the recipient (i.e. SGW) end is in terms of a "name" of some sort. If
this is to be meaningful from a security perspective, there must be a
cryptographically sound way to bind this name to the user presenting it.
If you are using certs, it makes sense to use an identifier which is
contained within (or otherwise verifiable using) the cert, to ensure
cryptographic binding.

What is being suggested by some is that we decouple the name used to
select the policy from the authenticator which, in my view, makes little
sense from a security perspective. It opens the door to
misconfigurations in which the same cert may be acceptable for more than
one policy rule, where the selected rule is controlled by the sender of
the ID payload - not exactly secure from the perspective of the SGW. It
is also argued (correctly, I think) that the lack of standard cert
profile for ipsec makes it practically impossible to specify universally
which cert field(s) will be presented by the sender, and
configured/accepted by the receiver, in an interoperable way.

This leads to my suggestion that the would-be-interoperable sender not
bother trying to guess what should be in the ID payload, since he cannot
be sure of doing so correctly, and for the receiver to have the option
of ignoring any ID sent along with a cert, and to have the ability to
select the correct policy with or without the ID payload, gleaning
whatever is needed from the cert. Clearly, this applies to certs only,
and not to raw rsa/dsa keys. This allows folks who are using the ID
payload as a convenient policy key for cert-based policies to continue
to do so, while ensuring that they will interoperate with someone who
doesn't send a particular ID, and vice versa. 

Of course, we assume that those using the unbound ID for convenience
actually do some additional policy verification from a security
perspective, although I suspect that in some cases this is not the case
- and such behavior should not be standardized by a security area
working group.

Scott