Subject: Re: Confirm decision on identity handling.

From: "Andrew Krywaniuk" <[email-masked]>
Date: Wed, 09 Apr 2003 21:52:20 -0400

I wasn't at the San Francisco meeting, but I will add my voice to the 
consensus (thus slightly reducing its roughness).

I would argue that the identity payload has never been authoritative, and it 
has always functioned as a policy hint, even in shared secret mode. (It is 
theoretically possible to have more than one user sharing the same secret, 
or - in the case of the initiator - multiple users with different secrets 
sharing the same id. I have heard that this has even been attempted on the 
responder as well.) Anyway, I digress.

The receiver is authenticating the sender, so the receiver gets to choose 
which field in the certificate is authoritative. However, there may be cases 
where a user could match more than one policy rule (where the level of 
authorization is different). The receiver can use the sender's id to ensure 
that he agrees that the sender is who he thinks he is. The name I coined for 
this feature was the "gratuitous id check" (mostly because it tends to annoy 
people who don't care that their policy is incorrect as long as they can 
still set up a tunnel).

E.g. A gateway has a number of policy rules for static peers (servers, 
gateways, etc) and a fall-through rule for remote access users. The static 
peers have different levels of authorization. Due to an ambiguity in 
configuration, one of the servers is granted basic access but not the 
extended privileges. The gratuitous id check detects this and fails the 
connection (or does something else of your choosing).

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 17:58:11 -0700

I am pretty darn close to agreeing with this text. I agree completely with
the intent. I would just like to see it word-smithed to be a bit clearer, in
order to attain "predictable interoperability," as Steve would say. Let's
make it very explicit.

My proposal below attempts to say:
- the base interoperable way is DO NOT CHECK ID matches cert
- implementations MUST be able to handle IDs that do not match cert contents
- to allow for local security policy decisions, implementations MAY be
configured to match.
- Matching will only interoperate if both sides support the feature and have
matching turned on.

Proposed Text:
The Identification Payload, denoted ID in this memo, allows peers to
assert an identify to one another. The receiver will interpret the identity
payload as a unique identity string for policy lookup in its SPD.
Implementations MUST NOT mandate a check that the ID match anything in the
certificate presented, and therefore MUST be able to accept the case where
the identity presented does NOT match the certificate contents. 

To allow for more stringent local security policy, implementations MAY offer
a configuration option to check that the idenity presented in the identity
payload matches the equivalent identity type in the presented certificate.
In such a case, interoperability will only be achieved by two consenting
parties who both have such configuration options available on their
respective gateways and who both enable the option. 

Gregory.

> -----Original Message-----
> From: Theodore Ts'o [mailto:[email-masked]]
> Sent: Friday, April 11, 2003 12:26 PM
> To: Paul Hoffman / VPNC
> Cc: [email-masked]
> Subject: Re: Confirm decision on identity handling.
> 
> 
> On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote:
> > 
> > We are better off with just the first sentence and a 
> revision of the 
> > one proposed here by Ted:
> > 
> >    The Identification Payload, denoted ID in this memo, 
> allows peers to
> >    assert an identify to one another. This identity may be 
> used for policy
> >    lookup, but does not necessarily have to match anything 
> in the CERT
> >    payload; both fields may be used by an implementation to perform
> >    access control decisions.
> 
> Paul's proposed revision seems clearer and reflects the discussion in
> San Francisco.  Does anybody have any problems with this text, or
> should we just go with it?
> 
> 							- Ted
>

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 21 Apr 2003 17:05:57 -0400

> > >To allow for more stringent local security policy,
> > implementations MAY
> > >offer
> > I guess my main question would be, in what way does this
> > allow for a "more
> > stringent local security policy"?
>
>If alice and amy are both users with valid certs, amy cannot connect to bob
>using her own cert, but using alice's identity in the identity payload.
>
>I personally don't think it is a big deal, but Steve Kent has said he 
>thinks
>it is, and I can see higher security organizations wanting it.

This is what I described a few days ago as the "gratuitous id check". 
However, I don't see how this is providing a more stringent security policy. 
If Amy is not allowed to talk to Bob, then the authentication should fail 
regardless of what she puts in her id payload, since the data in the 
certificate is authoritative.

In its modern incarnation, the id payload is supposed to be a key for policy 
lookups. Once you finish the policy lookup, you should then be able to 
ignore the id and base all further decisions on the data in the certificate.

Andrew

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

---

From: [email-masked]
Date: Wed, 23 Apr 2003 15:55:21 -0700

Hi Paul,

Right, but 2407 says:

"When an IKE exchange is authenticated using certificates
(of any format), any ID's used for input to local policy
decisions SHOULD be contained in the certifcate used in
the authentication of the exchange."

So, we've got a relationship betweed ID payload, cert,
and policy.  Maybe I've overextended that relationship.

Regards,

Jim

> From: Paul Hoffman / VPNC [mailto:[email-masked]]
> Sent: Wednesday, April 23, 2003 3:30 PM
> To: Jim Knowles; [email-masked]; [email-masked]
> Subject: RE: Confirm decision on identity handling.
> 
> 
> At 11:47 AM -0700 4/23/03, [email-masked] wrote:
> >I think the purpose of the ID payload when using
> >certs is (was) to specify which of several possible IDs
> >contained in the cert should be used for policy
> >lookup.
> 
> There is nothing in the IKEv2 spec that says this, and there is 
> nothing in RFC 2409 that says this. Hence, the desire for more 
> specificity in IKEv2.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: [email-masked]
Date: Wed, 23 Apr 2003 16:35:50 -0700

Hi Scott,

Sure it could, with prior agreement of the ID
to send.  This sort of prior agreement does
happen, at least sometimes, and may then be useful.

Regards,

Jim

> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Wednesday, April 23, 2003 3:35 PM
> To: Paul Hoffman / VPNC
> Cc: Jim Knowles; [email-masked]
> Paul Hoffman / VPNC wrote:
> > 
> And since the decision as to which ID will be used for this purpose is
> left to the receiver, it is not clear that the ID payload 
> could ever be
> reliably used this way...
> 
> Scott
>

---

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 29 Apr 2003 17:13:18 -0700

> I can't believe that after so many years, we are still 
> paralyzed w.r.t.
> this topic. What a farce. For the last several weeks, I've been trying
> to get several ostensibly mature implementations to interoperate using
> certs, and I've not had much success. How sad.
> 
> Scott
>

Scott, you are not alone. Just ask both the ICSA and VPNC. They are both
having a terrible time trying to get to interoperability using Certs. 

So I'm in agreement; whatever we decide MUST BE EXPLICIT.

---

From: David Wierbowski <[email-masked]>
Date: Wed, 30 Apr 2003 17:39:46 -0400

I agree.  I  think it is safer to trust an identify contained within a
certificate than it is to trust an identity sent in a payload.

If I understand this thread correctly the expectation is that I should make
a policy decision based solely on an identify payload and I should use the
certificate as a credential only.  What ties the identify to the
credential?  Do I have to now configure a mapping of acceptable policies to
identities and a list of credentials that I trust to send me a valid
identity payload?

I do not understand what interoperability issues result by requiring the
identity to be contained within the cert.  Isn't the verification of one's
identity a reason for using certificates in general?

Dave Wierbowski

"Scott G. Kelly" <[email-masked]>@lists.tislabs.com on 04/30/2003
04:48:28 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked], [email-masked],
       [email-masked]
Subject:    Re: Confirm decision on identity handling.

Hi Jim,

I trimmed most of this in order to focus on one point:

[email-masked] wrote:
>
> Then we could say there is no other IKEv2-defined relationship
> between ID and CERT and that implementations MAY define such
> relationships locally at their own extreme interoperable peril.

I must be missing something really obvious here. If we don't assume
anything about the initiator (e.g. that it can be trusted to put an
"appropriate" policy selector in the ID payload), then I think there
must be security issues with blindly using whatever is passed as a
policy selector, with no defined verification mechanism. As an aside,
exactly what does your client put into the ID payload?

It still sounds to me like we're trying to standardize proprietary
behavior here. What am I missing?

 Scott

---

From: [email-masked]
Date: Wed, 30 Apr 2003 16:23:35 -0700

Hi David,

comments inline...

> From: David Wierbowski [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 2:40 PM
> To: [email-masked]

The identity payload is authenticated via the cert
in the case we were discussing.  How is this unsafe?

> certificate as a credential only.  

What I proposed was that the a new ID payload could explicitly
state that the identity is in the cert, so it would not be solely
used as a credential.

> What ties the identify to the
> credential?

The auth payload.

> Do I have to now configure a mapping of 
> acceptable policies to

You may.  If you are mapping all credentials that you trust to
a single policy, you can ignore the identities.  Your choice.
In any case, you configure your trust of credentials in some way.

> identity to be contained within the cert.

None that I can see.  Current (v1) interoperability issues
are mainly from the ID-to-cert mapping.

> Isn't the 
> verification of one's

Regards,

Jim

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Wed, 30 Apr 2003 19:09:19 -0400

>And what is the point of this? It seems to make the policy lookup
>slightly simpler, since you can get the ID payload from the packet
>instead of parsing the cert. But this is only on the front end, because
>you still have to parse the cert, and you have the added step of
>verifying that the ID matches something in the cert (if you care about
>security).

Some people have been referring to the id as a "key for policy lookup". The 
idea is that if you have a decorrelated database (or an ordered database 
where more specific rules serve only to grant privileges and not to take 
them away), a unique id can allow a very fast policy lookup.

However, once this lookup is complete, you can throw the id away. It is not 
necessary to check the id against a field in the certificate. You only have 
to check the certificate against the policy (and the signature against the 
public key and the validity of the cert chain).

I wish people would stop saying thing like "you can check the id against the 
certificate if you require a more stringent policy check."

Andrew

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=features/junkmail