Subject: [MSEC] GSAKMP to Informational RFC (resend)

From: Thomas Hardjono <[email-masked]>
Date: Wed, 07 Aug 2002 16:45:22 -0400

(Resend: I posted this yesterday, but it never showed-up on the list.)

Folks,

After some discussion with the authors of GSAKMP, we have decided
to direct the GSAKMP draft to Informational RFC status.

The original GSAKMP document was one of the earliest submissions to SMuG,
and was submitted also to MSEC.  The MSEC version on the IETF site has expired
but the same document can be found here:
http://www.securemulticast.org/draft-irtf-smug-gsakmp-02.txt

If anyone has any comments/issues/complaints regarding moving
the original GSAKMP document to Informational RFC, please send them to
this mailing list within the next couple of weeks.

Regards,

Ran/Thomas

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 12 Aug 2002 14:46:32 -0700

Thomas,
   I don't see the point of taking GSAKMP to Informational RFC while taking 
GSAKMP-lite to standards track.  I'd chose one or the other.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 13 Aug 2002 09:03:25 -0400

Mark,

Perhaps my earlier email needs some clarification.  We are talking about 
two documents: GSAKMP-Light  and the original GSAKMP (ie. what I call
"GSAKMP-Original", which is the version proposed since the SMuG days).

The plan is indeed to advance GSAKMP-Light to Standards Track.  Thus, the
question pertains instead to GSAKMP-Original.

I think for anyone reading the GSAKMP-Light documents, it would be
useful to provide them with background information (ie. the original
GSAKMP documents). Thus, there is some benefit in keeping around
the GSAKMP-Original documents, rather than seeing them expire and disappear.

Hence my suggestion that GSAKMP-Original be put into Informational while
advancing GSAKMP-Light to Standards Track.

thomas
------

At 8/12/2002||02:46 PM, Mark Baugher wrote:
>Thomas,
>   I don't see the point of taking GSAKMP to Informational RFC while 
> taking GSAKMP-lite to standards track.  I'd chose one or the other.
>
>Mark

---

From: Haitham Cruickshank <[email-masked]>
Date: Wed, 14 Aug 2002 16:47:34 +0100

Dear Thomas and Hugh,

I think Thomas's idea is good to keep both GSAKMP and GSAKMP-Lite
documentation.  This is important for us (University of Surrey, UK) where we are
planning to implement GSAKMP-Lite.

Since there is  a plan to progress toward RFCs, then I think there are two
issues should be addressed in the GSAKMP-Lite (and/or GSAKMP) drafts:

* DoS attacks (especially on the GSAKM-Lite Server) are not addressed in the
draft.  The people who follow the ipsec mailing list know that IKEv2 is in a
very good shape, and in combinations with some features of JFK, could be adopted
as the SOI.  I just wanted to draw attention to the use of stateless cookies in
phase1 of IKEv2 messages, if the Responder feels it is under DoS attack.  Can
the authors of GSAKM-Lite document address this issue and possibly  adopt the
IKEv2 techniques (possible software reuse).  This means that normal  Light Group
Establishment messages are 3 and if DoS is detected then 5 messages will be
exchanged.

* The second issue is interworking with ipsec and passing the GSAKM-Lite keys to
the ipsec engine:  I appreciate that GSAKM architecture is application level and
independent of ipsec, however I think that many multicast applications with
GSAKM-Lite want to use ipsec for subsequent multicast security services
(privacy, integrity, etc.).  Is it possible for the GSAKM-Lite authors to
include some guidelines for interworking with ipsec (general or more specific
such as how to populate the SPD and SAD in ipsec engine with GSAKM-Lite keys,
etc.)

Haitham

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

---

From: Mark Baugher <[email-masked]>
Date: Wed, 14 Aug 2002 09:57:02 -0700

Haitham,

>planning to implement GSAKMP-Lite.

If there's something in GSAKMP that you need for GSAKMP-lite, I would 
expect that to be in GSAKMP-lite.

I'd like to know if/why the GSAKMP authors think that an Informational RFC 
is the best way to document work that has been eclipsed by GSAKMP-lite even 
before GSAKMP is published.

This is not a big issue apart from the fact that people often expect that 
it's worthwhile to implement protocols and algorithms that are 
Informational RFCs.  There is no "obsoleted by" clause for Informational 
RFCs, is there?  So, this strikes me as potentially confusing to the 
industry.  Another issue is that we may need to assure the RFC editor that 
we are not treating the Informational RFC process as a vanity press.  So, 
what's in GSAKMP but not in GSAKMP-lite that needs to be document by an 
Informational RFC as opposed to other means?

Mark

---

From: Hugh Harney <[email-masked]>
Date: Mon, 19 Aug 2002 10:36:10 -0400

Mark,

I suggested that GSAKMP heavy be moved to informational status because it 
is a viable protocol for multicast keying. It documents how one could use a 
pairwise SA to protect a key exchange. While you are correct that GSAKMP 
Lite will need to contain everything necessary to implement it. I thought 
it may be helpful to the community to document the group keying under an SA 
approach.

I'm very willing to include all the relevant pieces of GSAKMP heavy into 
the GSAKMP-Lite document. So that means the GSAKMP-Lite document will 
continue to be a living document. However, GSAKMP-heavy contains some ideas 
and mechanisms that Lite will not contain.

It wasn't my intention to use any process as a vanity press. It was my 
intention to provide documentation of an alternative method for group key 
management. Also, GSAKMP (heavy) has helped several people design key and 
security management protocols (judging from the number of e-mails I've 
received). It certainly contributed to the creation of (GSAKMP-Lite and 
GDOI). My thinking was that this document should be available as a 
reference. I thought that it would best be documented as an Informational RFC.

Would it be better to continue to submit GSAKMP-heavy and GSAKMP-Lite as 
Internt Dafts?

Hugh

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

---

From: Hugh Harney <[email-masked]>
Date: Mon, 19 Aug 2002 10:52:42 -0400

Haitham,

>Establishment messages are 3 and if DoS is detected then 5 messages will be

I understand your reasoning for wanting stateless cookies. I try to use 
good protocol design techniques, and steal any good ideas I find, so I'll 
add this to the next revision of GSAKMP-Lite.

>such as how to populate the SPD and SAD in ipsec engine with GSAKM-Lite keys,

I think that the IPSec SPD and SAD would benefit from a standard API. I 
don't think one is in the works. The closest I've seen is documented in an 
Informational RFC 2367 (PF_KEY Key Management API, Version 2). I think 
there is some code available that implements this API, with modification it 
should suit our purposes. At least using the approach outlined in this 
Informational RFC, we will not have to reinvent the wheel.

Hugh

---

From: Mark Baugher <[email-masked]>
Date: Mon, 26 Aug 2002 17:52:21 -0700

Hugh

At 10:36 AM 8/19/2002 -0400, Hugh Harney wrote:
>is a viable protocol for multicast keying. It documents how one could use 
>a pairwise SA to protect a key exchange. While you are correct that GSAKMP 
>it may be helpful to the community to document the group keying under an 
>SA approach.

So you expect that some will want to implement GSAKMP and other GSAKMP-lite?

>continue to be a living document. However, GSAKMP-heavy contains some 
>ideas and mechanisms that Lite will not contain.

Ok.  It might be useful to identify those when the document is taken 
forward to Informational RFC.  Up to this point, no one has listed the 
things in GSAKMP that are not in GSAKMP-lite and which should be preserved 
in an informational RFC.  Also, no one has stated that different 
communities may be interested in both.  It seems to be a bit much to take 
two variants of the protocol to standards track, I agree.

>Would it be better to continue to submit GSAKMP-heavy and GSAKMP-Lite as 

I guess that they both need to be current I-Ds if they are both going to be 
taken to RFC status.

regards, Mark