Subject: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301?

From: Liu Ya <[email-masked]>
Date: Fri, 13 Oct 2006 14:35:15 +0800

Hi all,

I have a question about GSAKMP. In the MSEC architecture defined in RFC4301 and draft-ietf-msec-ipsec-extensions-01, ESP/AH can be used for data security protocols. GDOI and GKDP serve group keying. Can GSAKMP be used here for group keying?  I find no GSAKMP payloads that can deliver SPI (Security Parameters Index) information from GC/KS to group members. Please tell me whether the combination of MSEC_Architecture+ESP/AH+GSAKMP is feasible?

Thanks,
Liu Ya

_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec

---

From: Liu Ya <[email-masked]>
Date: Sat, 14 Oct 2006 10:07:47 +0800

Hi George,

Thanks for your answer. 
 
> Transitioning the above extensions from private implementations into the
> IETF is an area for future standardization. Of course, that activity will
> depend on industry interest.

I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned.
 
Best regards,
Liu Ya

---

From: Liu Ya <[email-masked]>
Date: Sat, 14 Oct 2006 10:07:47 +0800

Hi George,

Thanks for your answer. 

 
Best regards,
Liu Ya

---

From: [email-masked]
Date: Fri, 13 Oct 2006 23:41:24 -0400

Hi Liu, 

I can see how applying MSEC IPsec to OSPF security would be a good fit for 
its trust model. GSAKMP has a rich feature set, and in particular its 
concept of autonomous distributed operations with sub-groups could map 
easily onto OSPF areas. 

In another e-mail that you sent to MSEC, you proposed a set of GDOI 
extensions that apparently handle the reliability and reachability issues 
found in a group of OSPF routers. Your Internet Draft seems to have some 
unstated OSPF requirements about why these GDOI extensions are needed. I 
would welcome hearing from you some more background about why you suggest 
that GDOI needs reliability mechanisms. In group key management protocols 
developed so far, reliability mechanisms are largely delegated to a separate 
protocol layer. 

br,
  George

---

From: [email-masked]
Date: Fri, 13 Oct 2006 23:41:24 -0400

Hi Liu, 

br,
  George

---

From: Liu Ya <[email-masked]>
Date: Sat, 14 Oct 2006 15:01:58 +0800

Hi George,

Thanks for your commenting quickly. My answer is inline.

> concept of autonomous distributed operations with sub-groups could map 

GSAKMP would be more fit than GDOI. But extensions must be defined before GSAKMP can be used here. 
 
> developed so far, reliability mechanisms are largely delegated to a separate 

For existing reliable rekeying methods, e.g., reliable multicast protocol, FEC encoding scheme, etc., high efficiency can be achieved when they are implemented with IP multicast. But IP multicast service is not always available in some scenarios like OSPFv3 groups. And unicast is not fit for those methods. A multicast-undependent way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to fulfil that requirement. For simplicity, it is not achieved in a separate reliable protocol layer.

Best regards,
Liu Ya

---

From: Liu Ya <[email-masked]>
Date: Sat, 14 Oct 2006 15:01:58 +0800

Hi George,

 

Best regards,
Liu Ya

---

From: George Gross <[email-masked]>
Date: Fri, 13 Oct 2006 08:27:27 -0400 (EDT)

Hi Liu,

On Fri, 13 Oct 2006, Liu Ya wrote:

> Hi all,
>
> I have a question about GSAKMP. In the MSEC architecture defined in
> RFC4301 and draft-ietf-msec-ipsec-extensions-01, ESP/AH can be used
> for data security protocols. GDOI and GKDP serve group keying. Can
> GSAKMP be used here for group keying?

Yes, GSAKMP can handle that type of group keying. Of course, RFC4534 and
RFC4535 only define an extensible framework from which one derives
application-specific instances. IPsec is an example of such an extension.

>  I find no GSAKMP payloads that
> can deliver SPI (Security Parameters Index) information from GC/KS to
> group members. Please tell me whether the combination of
> MSEC_Architecture+ESP/AH+GSAKMP is feasible?

Extending GSAKMP to do IPsec group key management involves several
extensions:

1) An IPsec group security policy information model. The Group Owner uses
this information model to encode a given group's IPsec security policies
in the policy token. This policy includes IPsec PAD, SPD, and SAD
descriptors for attributes such as the encryption transform,
authentication transform, SPI, key identifiers, group speaker
authorization, etc. The policy token is distributed to the group
membership in a Policy Token payload, either via a Re-Key Event message
multicast or at registration time within a Key Download message.

2) Group keying material for the IPsec SA is distributed in the Key
Download payload. For each IPsec SA, there would be a separate key for the
encryption transform, group authentication transform, and optionally a
digital signature public key. The key identifiers would refer to IPsec SA
descriptors within the policy token.

3) Developing a profile on the many options and features within the base
GSAKMP protocol.

hth,
    George

---

From: George Gross <[email-masked]>
Date: Fri, 13 Oct 2006 08:27:27 -0400 (EDT)

Hi Liu,

hth,
    George