Subject: [MSEC] gkmarch-03: host computer block diagram unclear

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 4 Nov 2002 19:24:32 +0100

Folks,

Figure 2 shows a block diagram for a host computer. To me, this figure is
pretty confusing for the following reasons:

- Actually, I'm assuming that the figure shows two host computers: one host
computer for the GCKS and another one for the group member.
- The figure shows various arrows; some appear labelled as group key
management protocols (Reg, Rek), while many others are unlabeled. I'm
assuming that the latter ones be just internal communication
interfaces/APIs?
- It is very confusing to see a box "security protocol" within the host of
the member, but similar box is found missing in the GCKS host. What is the
function of the box "security protocol"? Is it a parsing function of the
group key management protocols? Or is this the "Data Security Protocol"
function, which I understood not part of the group key management
architecture directly?
- Shouldn't GCKS host computer provide a "security protocol" box and
attached SAD/SPD too?
In this case, hardly any difference would remain between the GCKS and the
member functional components and the entire figure might be simplified.
- What is the function of "GKM"?
- What is the work split between "GKM", "Security Protocol"  and "CONTROL"
box? How do these boxes interact in terms during the procession of the group
key management protocols?
- The member host shows SAD and SPD attached to the "GKM" and to the
"Security Protocol" box. It is intentional that these be separate stores?
- Figure 1 shows also interaction with external components such as
policy/authorization infrastructure. It is not shown in Figure 2 how such
external components interface with the building blocks.
- CONTROL on one hand is described as a function which is fine but on the
other hand as a telephony signalling protocol (SIP) which sounds strange. I
would roughly understand this intuitively something as "SIP signalling
protocol being terminated by a CONTROL function". Is that the intention? If
that is the case, then there should be CONTROL <-- SIP --> CONTROL
communication too, although such communication arcs would leave/enter the
outer dashed box.

Some other observations:

Figure 1 is subtitled " Group Security Association Model", yet the figure
actually shows only protocols but not any SAs. Thus, I would subtitle the
figure more as "Group Security Protocol Architecture".
I could imagine a similar different figure that shows a mapping of the
various SAs to the security protocols.

While the GKMA document focuses on the protocol view with the registration
and re-key protocol, I would like to see some considerations given how
typical multicast applications can make use of these atomic protocols for
performing tasks like
- GCKS adds/removes one or more group member(s),
- Join/leave of a member.
- Are there other typical "higher-layer" operations (which?) that could be
realized through the GKM protocols (how?) ?

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 04 Nov 2002 14:06:06 -0500

Hi,

I will try and answer some of your questions below.

> function, which I understood not part of the group key management

It is data security protocol.  We will make the correction in the next 
version.  Thanks.

> "Security Protocol" box. It is intentional that these be separate stores?

I believe they are logical function blocks.  We are not (cannot) 
dictating how to implement them in real systems.

> various SAs to the security protocols.

Agreed.  We will make this change as well.

> - Join/leave of a member.

The short answer is that we intentionally left these parts out of the 
I-D (please see the discussion on deregistration in the mailing list's 
archive :-)).

best,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Mon, 04 Nov 2002 16:14:40 -0800

At 02:06 PM 11/4/2002 -0500, Lakshminath Dondeti wrote:
>I believe they are logical function blocks.  We are not (cannot) dictating 
>how to implement them in real systems.
>

I think this is explained in that there is a security association that 
protects each of the three protocols.

>The short answer is that we intentionally left these parts out of the I-D 
>(please see the discussion on deregistration in the mailing list's archive 
>:-)).
>
>best,
>Lakshminath
>

It's just key management.

regards, Mark