Subject: Re: Confirm decision on identity handling.

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 12 May 2003 17:55:40 -0400

>Can you give a real-world example of the process you describe below?
>That is, what sort of ID payload would be sent, what might it contain,
>and how would the policies look against which this compared?

Sorry for the late reply (I wasn't following the list last week). Anyway, I 
think we sometimes get too hung up on defining scenarios, rather than 
providing a framework for interoperability and allowing vendors to choose 
their own problem spaces. But nonetheless, I can give you a few scenarios:

1. A customer decides to consolidate its VPNs. Previously, there were 3 
different VPNs at various branch offices and the policies were not 
homogenous. Some of the policies are expressed in terms of USER_FQDNs, 
others by IP address and still others by distinguished name. The id payload 
provides a key into the policy database and allows a single search pass 
instead of 3.

2. For remote access, it is common to use some kind of XAuth-like process 
where the true identity of the user is not authenticated by IKE itsself. For 
IKEv2, the decision on whether to authenticate the user with EAP may depend 
on the contents of the id payload. Imagine that the phase 1 authentication 
is performed with a machine certificate and the user's id is completely 
divorced from the certificate.

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

>From: "Scott G. Kelly" <[email-masked]>
>To: Andrew Krywaniuk <[email-masked]>
>CC: [email-masked]
>Subject: Re: Confirm decision on identity handling.
>Date: Thu, 01 May 2003 09:10:05 -0700
>
>Hi Andrew,
>

>
>Thanks,
>
>Scott
>
>Andrew Krywaniuk wrote:
> >
> > >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
> > --------------------------------------
> > The odd thing about fairness is when
> > we strive so hard to be equitable
> > that we forget to be correct.
> >
> > _________________________________________________________________
> > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > http://join.msn.com/?page=features/junkmail

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 13 May 2003 15:18:21 -0700

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?

Scott

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 13 May 2003 16:30:03 -0700

>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: [email-masked]
Date: Mon, 19 May 2003 11:32:01 -0400

> where we would *not* want the ID to match something in the cert?

Realistic is in the eye of the beholder, but here is an example that
works for me.

Today, lots of mobile laptop to corporate firewall systems use
static keys because certificates are simply too painful. Suppose
I want to use public keys while making the smallest possible
investment in PKI. So at the corporate firewall, instead of
storing a username and password, I store a username and
certificate. The certificate might be one I got for some other
purpose and it contains - say - my email address. I put my
username in the IDi field. It is what the firewall wants to use to
look up my authentication information. For some users, it has
static keys. But for me, it has a certificate.

In this case, the ID and the cert must match in the sense that
the cert has to be stored by the firewall associated with my ID.
But there is no relationship between the names that could be
pinned down in the spec.

A foolish use of technology? Well, yes. But likely better
security than with the static shared keys (since the firewall's
database is no longer so sensitive to disclosure), and a
useful transition step.

        --Charlie

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 19 May 2003 09:38:43 -0700

Hi Charlie,

Thanks for commenting on this. I've seen some other comments that lead
me to see that this is indeed useful under some circumstances. I guess
my objections would be overcome if we implemented what I think was one
of Steve Kent's suggestions, i.e. if we specify (somewhere) how an ID
which does not match the cert in some way is bound to the cert (and the
policy rule) in the SPD. I think mcr's and Jim Knowles' suggestions for
see-the-cert-dummy ID payload type would be useful as well.

Scott

---

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

> But there is no relationship between the names that could be

It's transitional cases like this that I always
wonder why people don't just use a hash of the
public key as the "password" instead. Since it's a
baby step as you state, it *does* eliminate the
(manfiestly) daunting task of issuing
certificates, and still gets rid of static keys
and all of their downsides.

Has a BCP ever been written about all of this? My
sense is that confusion and timidity is one of the
larger problems here since it's about "security"
and thus frightening. There seems to be a pretty
large gap with people's professed desires (certs)
and its mismatch with reality (ie, legacy
creds...), helping the transition to public key
based authentication would be a generally Good
Thing, I'd think -- even if it doesn't make it to
the PKI promised land.

		Mike

---

From: Greg Troxel <[email-masked]>
Date: 19 May 2003 14:08:45 -0400

Perhaps this is far afield, but consider Kerberos usage.  A user has a
principal, which is akin to a certificate with a name (different
namespaces and way of proving identity, but conceptually similar).
Many protocols using Kerberos enable one to say 'log in to the remote
machine as user foo', and the normal ACL check looks at ~foo/.klogin
and sees if the Kerberos principal that authenticated the request is
on the list.

So, I might have a certificate with a name, and want to use that to
prove identity but select different roles on the remote system by use
of the ID field.  The question then becomes if the proved ID is
authorized access under the requested ID.

Given that IPsec currently has no way to link the proved/requested ID
in the IKE negotiation to the application that gets packets over an
SA, this is not yet very relevant.  And, one could claim that this ID
mapping should be done closer to the application.  But, the
'{[k]r,s}login hostname -l username' usage was and is useful.

        Greg Troxel <[email-masked]>