Subject: [IPsec] [ipsecme] #217: Temporary credentials

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Mar 2012 21:36:42 -0400

Another issue to comment on.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 7:01 PM
To: [email-masked]; [email-masked]
Subject: [ipsecme] #217: Temporary credentials

#217: Temporary credentials

 Endpoints may require temporary credentials in order to establish a secure
 connection to another endpoint.

 Suggested Resolution: Put this in the requirements section.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…          |  problem@…
     Type:  defect       |     Status:  new
 Priority:  normal       |  Milestone:
Component:  p2p-vpn-     |   Severity:  -
  problem                |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/217>
ipsecme <http://tools.ietf.org/ipsecme/>

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 21 Mar 2012 12:24:08 -0700

Hi Steve,

I think this is an important requirement for sure.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna <[email-masked]> wrote:

> To: [email-masked];
> [email-masked]

---

From: Geoffrey Huang <[email-masked]>
Date: Wed, 21 Mar 2012 13:43:16 -0700

I don't understand what "temporary credentials" means.  If the intent is to have some transitive authentication (or redirection of trust hierarchy, at least) between a gateway and two spoke devices, which are trying to establish an ad-hoc connection, then I agree this would be important to have.

-geoff

From: Vishwas Manral <[email-masked]<mailto:[email-masked]>>
Date: Wed, 21 Mar 2012 12:24:08 -0700
To: Steve Hanna <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials

Hi Steve,

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna <[email-masked]<mailto:[email-masked]>> wrote:
Another issue to comment on.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 20, 2012 7:01 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [ipsecme] #217: Temporary credentials

--

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 21 Mar 2012 23:24:45 +0200

The point of "temporary credentials" is that if these spokes normally 
use EAP or PSK to authenticate to the gateway, they cannot use these 
same credentials to auth to one another (because that would expose each 
spoke to impersonation by the other one). So to support this scenario we 
must have some other means of authentication.

This raises an interesting question: if the spokes are authenticating 
with certificates, they could in principle use the same credentials to 
authenticate to one another. So the "temporary credentials" now become 
*authorization* tokens, basically conveying to gateway's policy. Do we 
really want to go down this path?

Thanks,
	Yaron

On 03/21/2012 10:43 PM, Geoffrey Huang wrote:
> From: Vishwas Manral<[email-masked]<mailto:[email-masked]>>
> To: Steve Hanna<[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna<[email-masked]<mailto:[email-masked]>>  wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Wed, 21 Mar 2012 14:30:37 -0700

Yes. If certificate based authentication was used in the network, there is
no need of new credentials. But if pre-shared key based was used, then we
need this "temporary credentials". Also, it is required to define the
lifetime of this "temporary credentials". For example, if tunnel between
spokes are stays beyond lifetime of SA, then can the same "temporary
credentials" can be used for rekey? Or new "temporary credentials" should
be received from Hub?

Thanks,
Praveen

On 3/21/12 2:24 PM, "Yaron Sheffer" <[email-masked]> wrote:

Thanks,
    Yaron

On 03/21/2012 10:43 PM, Geoffrey Huang wrote:
> I don't understand what "temporary credentials" means.  If the intent is
>to have some transitive authentication (or redirection of trust
>hierarchy, at least) between a gateway and two spoke devices, which are
>trying to establish an ad-hoc connection, then I agree this would be
>important to have.
>
> -geoff
>
> From: Vishwas 
>Manral<[email-masked]<mailto:[email-masked]>>
> Cc: 
>"[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]
>rg>>
> On Tue, Mar 20, 2012 at 6:36 PM, Stephen
>Hanna<[email-masked]<mailto:[email-masked]>>  wrote:
> From: ipsecme issue tracker
>[mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:draft-ietf-ipsecm
>[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Mar 2012 23:48:09 +0200

I don't think there need to be authorization tokens, as authorization can be left to local policy.

But there always needs to be some kind of "introduction" process, and it can take many forms:
 - Yaron, Yoav is at 192.168.1.3. Use c80273f0f7dd5bdc10c38234616fde22 as PSK
 - Yaron, Yoav is at 192.168.1.3. His certificate has DN: "CN=ynir,OU=something"

In the first case, the "system" actually invented the credential, while in the second case it just tells you about it. So temporary credentials are not strictly necessary, but previous attempts to rely on pure PKI have been less than successful.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 22 Mar 2012 00:26:02 +0200

Hi Yoav,

When you say "local policy" you assume that spokes are smart enough (or 
well enough provisioned) to have such policy. My assumption OTOH was 
that the gateway is smarter, e.g. it knows what spokes are allowed to 
communicate directly or what kind of traffic is allowed to flow directly 
between spokes.

It may just be a semantic discussion, but the second bullet of your 
"introduction" is to me indistinguishable from authorization.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 24 Mar 2012 12:04:47 +0200

> credentials" can be used for rekey? Or new "temporary credentials" should

That starts to sound like certificates... One of the ways to do this
is to always use certificates in the on-demand direct vpn connections.
I.e if the peer A normally authenticates itself with PSK to the hub,
it would then create private key, give it to the hub, which would sign
it with hub-only configuration trust anchor, and then other peers
could use that key.

Or another way would be to use raw public keys, but then we do not
have the things like validity periods etc.

As X.509 certificate authentication support is already MANDATORY to
support in all implementations, that could be the easiest way forward. 
-- 
[email-masked]

---

From: Geoffrey Huang <[email-masked]>
Date: Sat, 24 Mar 2012 09:34:56 -0700

My initial inclination is to say that won't fly: that many deployments still require preshared key authentication.  Rather, they would object to certificates because of perceived complexity. That said, I could see arguments that what we're discussing are already fairly sophisticated topologies, so perhaps the certificate allergy doesn't hold?

-Geoff

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 24 Mar 2012 18:47:48 +0200

Geoffrey Huang writes:
> My initial inclination is to say that won't fly: that many
> deployments still require preshared key authentication.  Rather,
> they would object to certificates because of perceived complexity.
> That said, I could see arguments that what we're discussing are
> already fairly sophisticated topologies, so perhaps the certificate
> allergy doesn't hold? 

As we are talking about temporary certificates enrolled by the local
trust anchor most of the issues people have with certificates do not
apply. Adminstrators etc will never even see those certificates. The
vendor implementing this needs to implement fetching the temporary
credentials, but that code needs to be written anyways regardless
whether we use pre-shared keys or certificates.

I would actually except that most of this kind of setups already use
certificates as their credentials as if we are talking big networks
with possibly "hundreds of thousands of gateways", I do not think
anybody even thinks of deploying such networks with pre-shared keys
even with hub and spoke model... 
-- 
[email-masked]

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Sun, 25 Mar 2012 15:10:17 -0700

This works if there is only one Hub in the network. Scenario where multiple hubs in hierarchy or multiple Hub's that don't have hierarchical relation, this will not work.
 
-- Praveen
________________________________________
From: Tero Kivinen [[email-masked]]
Sent: Saturday, March 24, 2012 3:04 AM
To: Praveen Sathyanarayan
Cc: Yaron Sheffer; Geoffrey Huang; [email-masked]; Stephen Hanna
Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 09:52:27 +0200

>>>>> "Geoffrey" == Geoffrey Huang <[email-masked]> writes:
    Geoffrey> My initial inclination is to say that won't fly: that many
    Geoffrey> deployments still require preshared key authentication.
    Geoffrey> Rather, they would object to certificates because of
    Geoffrey> perceived complexity. That said, I could see arguments
    Geoffrey> that what we're discussing are already fairly
    Geoffrey> sophisticated topologies, so perhaps the certificate
    Geoffrey> allergy doesn't hold? 

Tero isn't proposing using certificates.

Tero is proposing that the gateway/hub provides each leaf node with a
gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs
of identity.  It would be used only for the leaf to leaf connection.  
It would be retained for a convenient period of time and then destroyed.

End users and leaf systems would continue to "authenticate" to the
gateway using the insecure legacy mechanisms that CTOs seem to prefer.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2012 11:02:41 +0300

Praveen Sathyanarayan writes:
> This works if there is only one Hub in the network. Scenario where
> multiple hubs in hierarchy or multiple Hub's that don't have
> hierarchical relation, this will not work.

I see no problems even if there is multiple hubs. There are lots of
different ways to do things, and we do not need to go to solution
space yet (one trust anchor per hub, sub-ca per hub, shared trust
anchor between the hubs etc).

On the other hand all of the solutions needs to take account the fact
that if there are multiple hubs. All depends also what kind of trust
relationship the hubs have etc.

With certificates there is a way to setup system so that hubs do not
need real time policy communications between them. With shared keys
the hubs needs to have real time policy communication, as the
temporary shared key generated by one hub, needs to be distributed to
other hubs needing it. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Mar 2012 10:07:57 +0200

> It would be retained for a convenient period of time and then destroyed.

Not just leaf-to-leaf, but also leaf to any other node, even if it's not a real leaf.

This is beginning to look a lot like Kerberos, no?

Yoav

---

From: Geoffrey Huang <[email-masked]>
Date: Mon, 26 Mar 2012 11:21:21 -0700

It's starting to sound like existing methods, to be sure.  I'm skeptical
of introducing yet another form of authentication.  This would add to the
complexity of the overall system.  To frame it in terms of a requirement,
I propose that any leaf-to-leaf communication has to be done with existing
(already defined) authentication methods: for instance, either
certificates or pre shared key.

-geoff

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2012 23:24:37 +0300

> certificates or pre shared key.

Yes, we do want to use existing authentication methods. The question
is can we use existing credentials. We cannot securely reuse existing
pre-shared keys, as that would require sharing keys between peers who
normally do not share keys. We cannot easily reuse EAP crendentials,
as most of the leafs (especially the road warrior cases) do not have
trust relationship with the EAP server, so they cannot verify other
ends EAP credentials.

We can reuse existing certificates and public/private key pairs, but
if any other authentication methods are needed, we need to provide
solution how peers can get some kind of temporary credentials they can
use with the existing authentication methods to authenticate them to
another peer. For that the private/public key pair (with or without
certificates) is the most convinient one.
-- 
[email-masked]