Subject: [MSEC] Session ID and Group ID

From: Thomas Hardjono <[email-masked]>
Date: Thu, 29 Mar 2001 16:14:33 -0500

Recently we had a discussion with some folks who wanted to
do group key management in wireless, and a number of questions arose
regarding the GSA Model and Definition, and in particular
about the notion of Group IDs (GID).

So we all know that we need some way to identify a group
other than using the (S, G) pair.  GSAKMP uses the notion
of a Group ID (GID) which can identify a group a high level
and which is included in all the GSAKMP messages/headers.
In GSAKMP the GID is a 32-bit number (though I think we may
need a bigger number).

This notion of a GID is also being carried-over into the GDOI work
(at least implicitly).

So here is the scenario:  there is one control channel (Cat-2)
and there is multiple data channel (Cat-3), say one for audio and
one for video.

The question is, if I was a Receiver and was in the process of
receiving a key-update (rekey pack) through the push/control SA,
how do I identify which key-packs are to be applied to the
2 data channels?  In GDOI the update will consist of 2 KEK SAs,
but the question still arises: how do I know how to match the KEKs
to the multiple Cat-3 SAs.

One answer is using a Session-ID (SID) in conjunction with the GID.
Thus, each KEK and TEK would need to identify the GID & SID
to which the KEK/TEK applies.

Would it be possible, say, to have a 32-bit GID and a 32-bit SID,
(assuming that 32-bits of GID is enough)?  If a 32-bit GID is too much,
perhaps we can re-use some of the bits (least significant 8 bit)
for the SID?

Does this whole SID thing make any sense?

thomas
------

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Brian Weis <[email-masked]>
Date: Thu, 29 Mar 2001 06:34:10 -0800

Hi Thomas,

> to the multiple Cat-3 SAs.

I followed you up until the last paragraph. In the scenario you mention,
there could be one KEK SA (not two as you say in this paragraph), and
two TEK SAs. Maybe you meant that the "update will consist of 2 TEK
SAs"?

In GDOI, the push message includes an SA payload containing the policy
for the two data channels, and the KD payload contains the new keys for
the two channels. The SA payload identifies the (S,G) of the data
channel along with a new SPI (assuming IPSec encapsulation). The KD
payload includes the new SPI and the new key. It will be obvious which
key is associated with which data channel.

Or, if you really considering confusion between the two KEKs, the only
confusion between would be between the current KEK and a new one sent
down in the push message.
However, the new one replaces the current KEK after the push message
processing has completed -- only one should be active at a time per
group.

> to which the KEK/TEK applies.

The GDOI, there is already a unique value associated with each KEK. The
cookie-pair in the IKE header is used as the "SPI" for the KEK. If a new
KEK is sent in a push message, the SA payload sends a new cookie-pair
for the new KEK.

I don't see where a SID is needed for either a TEK or KEK.

Brian Weis
[email-masked]

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Thu, 29 Mar 2001 18:20:46 -0500

Brian,

I am not getting into this SID discussion at this time.  

But, I am concerned about having a single "active" TEK.  I believe
in reality a member needs to maintain a list of TEKs.  Consider
data going over a reliable multicast channel.  It is plausible 
that a member receives two (e.g.) versions of TEKs before she 
receives any encrypted data.  When the data eventually arrives,
the first few packets could be encrypted with TEK 1.0 and the rest
with TEK 2.0, or vice versa.  

I propose that both key and data packets should have "version" and
"revision" tags.  The terminology and idea comes from the VersaKey 
paper in JSAC 1999/2000 by M. Waldvogel, G. Caronni, B. Plattner and 
others.  As I recall each time a new key is generated, the version 
number is increased, and when a one-way function is used on the current 
TEK/KEK for rekeying (ala LKH+), the revision number is increased.

best regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Fri, 30 Mar 2001 05:28:12 -0800

Thomas,

>to the multiple Cat-3 SAs.

I don't think there's any problem to solve here.  There is only one
SA KEK in your description because there is only one category-2
SA.  The GCKS keys category-3 SAs with SA TEK payloads.
There is a security protocol that requests, receives, and
manages the category-3 SA data.  Each security protocol may
have its own way of uniquely identifying a category-3 SA (as
well as how to form SPIs and other security-protocol specific
parameters).  It could be a number, like a session number,
if that's what the particular security protocol uses.  If the
security protocol is ESP, the security protocol could use a
<transport address, protocol> pair - or any other identification
data specified by RFC 2407 and supported by IKE.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Fri, 30 Mar 2001 05:31:28 -0800

Lakshminath,

>with TEK 2.0, or vice versa.

We use an SPI for this purpose.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 30 Mar 2001 10:33:51 -0500

Hi,

Thanks Brian for the correction.  (2 TEK SAs).

Rethinking this question again, perhaps I'm asking the question at
the wrong layer.

We know we need some way to announce a "Group" (in a broad sense) which
in the scenario uses 1 control channel (IP multicast address) and
2 data channels (2 separate IP multicast addresses).

We need some way to identify this "Group", which is where the GID
comes into play.  Thus, perhaps the GID is an Application layer
identification method.  If an application uses GDOI, then it must
link the GID with the appropriate SPIs of each channel at layer 3.

In other words, perhaps the question of GID is irrelevant in GDOI
at layer 3 since the GID is an application layer identification method.
On the other hand, in GSAKMP the GID makes sense since it must be used
to identify Groups in the Request to join (flow-1) and the Invitation
message (flow-2) of the GSAKMP exchanges.

Does all this make sense?

btw. I still think that a GID-thing will be needed when we start looking at
group announcement methods.  The candidate-member then learns about
the key management protocol and the channels, etc. through the Policy Token
(which carries also the GID number).

cheers,

thomas
------

---

From: Hugh Harney <[email-masked]>
Date: Fri, 30 Mar 2001 10:35:49 -0500

Thomas,

Let me speak for the GSAKMP case.

The GID identifies the abstract group. Many keys maybe associated with an 
abstract group. This abstraction is very important, because all keys being 
used in a group effect the groups overall security. For example, if a group 
is supporting a collaborative environment, then the key and algorithms used 
to protect the audio stream must be as strong as those used to protect the 
video frames.

So in GSAKMP a GID is used to define the abstract group (and keys used to 
management that group). Then the key download payload for that group 
specifies many types of keys. Each of these types can carry management 
information to ensure proper allocation of that individual key. For 
example, rekey is a key download type. The specification for the rekey 
data, includes information about the rekey type (LKH, OFT...), and 
information about where a specific LKH key is located in the key tree.

In your wireless example, a key download payload type may be called 
wireless. Then under that key type the wireless designers can specify a 
management structure that can differentiate between multiple types of data 
channels and multiple TEKs per channel.

In this manner the key download payloads can be used for broad categories 
of keys. The individual key types can be specified as much as desired.

Hugh

>> > Does this whole SID thing make any sense?

________________________________________________________
Hugh Harney		[email-masked]		410-381-9400 x203
________________________________________________________

---

From: Brian Weis <[email-masked]>
Date: Fri, 30 Mar 2001 11:42:02 -0800

Hi Lakshminath,

> with TEK 2.0, or vice versa.

I didn't mean to imply that there was a single "active" TEK. Certainly
there's a  window at the key change time where both an old TEK and a new
TEK are valid. A few more data packets could be encrypted the old key
before the new one is used. As Mark replied, if you're using ESP the SPI
provides a clear definition of which key to use during that period.
(Remember that if there is a key change, there must also be a SPI
change.)

In the KEK case, once a receiver gets a push message with a new KEK the
old KEK is immediately made obsolete -- the GCKS is declaring that it
won't use the old KEK anymore.

> TEK/KEK for rekeying (ala LKH+), the revision number is increased.

The GDOI push message contains a sequence number (in the SEQ payload).
This plays the role of a "version" tag, since it provides a clear
ordering of messages. Any push message containing a KEK supercedes all
push messages with smaller sequence numbers.

I'm not sure about the need of a "revision" flag. If the push message
contains an LKH+ tree update, it seems to me that the sequence number
serves the same role in providing a clear ordering of which set of keys
is most current.

Brian Weis
[email-masked]

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Fri, 30 Mar 2001 13:52:31 -0500

Mark,

Thanks for the explanation.  It makes sense.  I am looking for
opinions on incorporating version and revision numbers with
keys.  Particularly in case of LKH+ and similar key determination
algorithms it makes life easy.  For example, in LKH+, when a join
occurs, the GCKS need not even notify current membership.  When
data comes with a new "revision number", the members "update" the
corresponding SA appropriately.

I am bringing this up so we can discuss and decide whether it is
worthwhile to add this to GDOI I-D key payloads.

best regards,
Lakshminath

PS:  I want to reiterate the disclaimer that this was an idea proposed
in the literature (not by me, see below).

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Fri, 30 Mar 2001 15:44:08 -0500

Brian,

Thanks much for the explanation.  Thomas explained earlier (private
communication) that the SEQ along with the SPI obviates the need
for a version field (although I still believe an explicit version
number makes life easy :-); also, see below).

About revision (and it needs a version number to go with it) numbering,
as I explained earlier in another message, we can use it and not
send a new SA/SPI/notification during join rekeying in LKH+ and similar
algorithms.

Version and revision numbering will make the key payloads a bit bigger 
than they are, but 
  i) makes it easy to maintain and index keys
  ii) allows us not to send join rekeying notifications in LKH+ etc.

Any other pros and cons?

My interest in this is that it is a good technique, that is all!
Thanks much for considering this.

best regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Sat, 31 Mar 2001 03:53:58 -0800

hi Lakshminath
    I think that we need to have a separate draft document
that describes how an LKH security protocol should
operate.  What we have in the GDOI draft is our first
take on what the Security-Association traffic encryption key
(SA TEK) payload needs to be to support an LKH security
protocol.  I would not be surprised if we need to change
this by the time we finish an LKH security protocol
document.  It hope that the security association key
encrypting key (SA KEK) won't need any changes -
if we find that we need to change SA KEK for new
security protocols, then there's something wrong.  The
SA KEK needs to be general wrt security protocols.

best regards, Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Sat, 31 Mar 2001 10:18:52 -0500

I think we did agree somewhere along the line that a draft(s) is needed
to cover the "Group Key Determination Algorithms",
which is my formal way of saying LKH, OFT, OFC, etc. (ie. Key Trees
in general).

Are we limited to simply providing a variable-length payload
for a flattened Key-Tree, or is there sufficient similarity
among the Algorithms that we can provide a finer granularity
standard payload?

Also, is there a "standard" that describes how (say) the LKH algorithm
works (in the same way that there is, say, a DES standard document)?
I know LKH isn't an algorithms in the sense of DES, but really
a standard is this sense is just a step-by-step description of
how to manipulate the bits (be they keys or data).

thomas
------