Subject: [MSEC] Experimental/Standards track for IPsec mapping for GSAKMP I-D

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Wed, 04 Aug 2004 14:05:27 -0400

Hi,

I was looking at the meeting summary that notes that the IPsec mapping 
for GSAKMP I-D is going forward as a standards track document.  As I 
recall, Hugh's point was that this is just one way of IPsec SA 
establishment in GSAKMP.  I think I was agnostic :-).

So, I was wondering - since the draft only talks about one of the 
several ways of doing IPsec with GSAKMP (does GSAKMP specify one 
already?) - whether it makes sense to use the experimental track for this.

regards,
Lakshminath
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Hugh Harney <[email-masked]>
Date: Thu, 5 Aug 2004 10:45:29 -0400

Lakshminath,

GSAKMP does not specify how to do IPSec for group communications. It 
does offer a policy token that can be extended to provide policy 
information to support IPSec. GSAKMP is agnostic wrt the data layer 
protocol it is supporting.

Hugh

> already?) - whether it makes sense to use the experimental track for 
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: canetti <[email-masked]>
Date: Thu, 5 Aug 2004 12:24:11 -0400 (EDT)

Hugh an all,

Can GSAKMP handle setting up the parameters for TESLA? or if not, can it
be easily extended to do so?

The parameters needed by a TESLA are described in the TESLA-SRTP draft and
the TESLA-intro draft. (The upcoming TESLA-ESP has similar requirements.)

The only potentially tricky parameter is the value D_t, which is the bound
on  the time difference between the member and the sender. To setup that
value correctly, there should be an authenticated member->gcks flow,
followed by an authenticated gcks->member flow. The member should re
cord the time of the outgoing message. the center should record the
time of receipt of the message, and send it over in the return message.

In addition, a sender and the gcks will do the same but in the reverse
direction (ie, a gcks->sender flow, followed by a sender->gcks flow). the
value D_t of each member with respect to a given sender will be the sum
of the sender->gcks delay and the gcks->member delay.

I'm sure GSAKMP can handle this in principle. But is there today
provisioning on how to do this? If not, may be useful to add it.

Best,

Ran

---

From: Hugh Harney <[email-masked]>
Date: Thu, 5 Aug 2004 13:37:03 -0400

Ran,

GSAKMP passes a policy token during the registration exchange. The core 
GSAKMP Policy Token has a "hook" for Data Layer policy specifications. 
I believe TESLA would be a data layer application in this context.

Our Internet Draft for this Policy Token is written in ASN.1. ASN.1 
provides a model where a core specification provides easy reference 
points for other ASN.1 specifications. So, in this case, we have 
provided a reference for data layer protocols. TESLA is clearly a data 
layer protocol. TESLA should write a TESLA specific I-D describing the 
configuration/policy information needed. This I-D would link to the 
core policy token specification and you have a well defined mechanism 
for providing TESLA policy via the Policy Token.

Because the Policy Token specification already describes how this is 
works, the TESLA I-D for the Policy Token can be very short. We 
included a data layer policy example in the submitted draft. We used 
SRTP as the example. If TESLA does something similar an ASN.1 compiler 
would be able to create a Policy Token with TESLA policy incorporated 
into it.

One of the reasons we believe the Policy Token should be written in 
ASN.1 is the to chain specifications together. The potential protocols 
supported an continue to grow even after the core Policy Token is an 
RFC. It becomes infinitely extensible.

In short, I'd suggest that TESLA write a short I-D describing the 
policy it needs to be passed in the Policy Token. If this is done in 
ASN.1 you automatically can be linked to any Policy Token. I believe it 
is better to have an I-D for each data layer protocol supported by the 
PT because we can then create simple policy building blocks that can be 
used in ways that we don't envision today. For example, If GDOI version 
(x) decides to incorporate a Policy Token it could reference the TESLA 
ASN.1 RFC and use it.

Hugh

Hugh Harney							Sparta, Inc.

---

From: George Gross <[email-masked]>
Date: Thu, 5 Aug 2004 12:18:28 -0400 (EDT)

Hi,
	I concur with Hugh's assessment of adding TESLA to GSAKMP. It can
be done as a policy token extension, in combination with piggyback'ing
TESLA specific payloads on the RTJ, KDL, and KDL-ACK messages. The TESLA
payloads could be defined as Notification payloads, or for the GSAKMP
IPsec application, it could be sub-payloads within Security Association
Configuration payload.

	that said, I am not clear how one could accurately measure the
network delay parameter on which TESLA depends. The GC/KS<->GM
registration exchange is a snapshot of that delay at particular
communication path at a particular time. The delay between the Group
Speaker and a Group Receiver may be a different value, depending on
the respective location and time of those two endpoints.

	Ran, how did you envision tracking and adjusting the network delay
in a secure way after a Group Speaker's registration phase completes?
would an active attacker who altered the perceived packet delivery delay
of a sub-group make life difficult for TESLA?

	If you composed a TESLA GSAKMP ID along the lines suggested by
Hugh, it would probably need to talk about how to handle these issues...

	George

---

From: canetti <[email-masked]>
Date: Thu, 5 Aug 2004 15:24:40 -0400 (EDT)

Hugh, George,

I dont think there is need in another draft:
The current TESLA-SRTP draft already specified exactly what it needs from
the key management protocol (be it GSAKMP or otherwise). It is not written
in ASN.1 language, but this can be added if necessary. Do you think it is?

Also, if we want things to work then there probably should be an appendix
in GSAKMP that re-iterates these parameters and describes how they are
computed. (Most of these parameters are just downloaded rfrom the GCKS.
as said, the only tricky one is the time difference D_t.) George's
suggestion on how to piggyback the timing info on the GSAKMP messages
looks reasonable to me; it just needs to be written down.

Thanks,

Ran

See below on George's question:

> of a sub-group make life difficult for TESLA?

The purpose of the timing payloads in GSAKMP (or any other session setup
protocol) is NOT to estimate the network delay. Rather, the goal is to
compute a bound on the time difference between the local clocks at the
sender and the receiver. Assuming that clocks do not drift too much,
the "snapshot" at registration is good enough.

Estimating the network delay is a different issue, which should be
taken care of by the sender independnetly. Indeed, this task is
quite application-specific and is thus left outside our stnadard.
(A reminder: getting a good estimate on the network delay is not a
security issue. TESLA is secure even if this estimate is totally off.
If the estimate is too pessimistic then packets will be buffered for
longer than necessary. If it is too optimistic then too many packets will
arrive "too late" and will be dropped.)