Subject: Re: [MSEC] A few questions on GSAKMP (long)

From: Andrea Colegrove <[email-masked]>
Date: Tue, 01 Jul 2003 13:06:43 -0400

Hi, Lakshminath,
    Hugh is away for a couple of weeks, so I will try to answer the 
questions that you posed to him.

Lakshminath Dondeti wrote:

> Hi Hugh,
>
> I have some questions GSAKMP (draft-ietf-msec-gsakmp-sec-01.txt, Feb 
> 2003).
>
> Sec 4.2.3 on notification messages says:
>
> "The GCKS receives the signed notification and will verify the 
> signature on the message to ensure its authenticity and the nonce 
> value.  If the message signature or nonce does not verify, the session 
> MUST be terminated.  GSAKMP sends a properly authenticated message 
> with a Notification Payload of type NACK to indicate termination. "
>
> What happens if this message is lost or has never been sent.  The 
> member has no way of knowing whether the message has been delivered or 
> not (at least not in the first case :-) ).  In either case, it can go 
> on to install the data security SA and listen in on secure group 
> communications.  What is the GCKS expected to do?
>
> It sounds counter-intuitive to do nonceC checking after keys have been 
> distributed.  Is this to finish in three messages?
>
> What does session termination mean in the context of 4.2.3?   Does the 
> GCKS terminate/update the Registration SA, Rekey SA or the Data 
> Security SA, or all?  If it is Registration SA, it does not affect the 
> member, does it? 

Without the use of a synchronized timestamp, we need a minimum of three 
messages to complete the authentication including freshness.  If the 
authentication fails for any reason (e.g., replay, lost messages) then 
the GCKS needs to respond in a policy-appropriate manner.  In most 
cases, this will involving keying the failed potential member out 
through an update of the Rekey SA.  Once again, whether this occurs 
immediately or whether some buffering of updates to the Rekey SA occurs 
is a matter of policy.

>
>
> In Table 4 of Section 4.3.2, is the Rekey Array same as the Key 
> Download payload?  Also, I was wondering if the Rekey message should 
> be HMAC'ed to avoid a simple DoS attack.  Why not encrypt the Rekey 
> Array to avoid exposing portions of that payload (e.g., length) to 
> eavesdroppers? There is also no SEQ number in that message.  How would 
> the members distinguish a legitimate Rekey message from a replayed 
> one?  Am I misreading the spec here?

The GSAKMP header has a sequence number, plus, the rekey array itself 
(for the LKH case) has a time/date stamp.  Because of the relative 
infrequency of rekey messages, the group can tolerate a loose 
synchronization or even use the stamp in more of a sequence number type 
of check where the stamp only needs to be greater than the stamp last 
seen.  In general, though, it is probably just easier to always use the 
GSAKMP header sequence number because it will always be available even 
if, say, an OFC scheme were used that didn't contain a timestamp in its 
syntax.

The message is signed, so any change to the message (truncation, etc.) 
will be detected.  Even with a keyed hash, any change in the array by an 
adversary will cause denial of service, but perhaps I am 
misunderstanding your DoS attack?

The rekey array should be sent under the protection of the Data Security 
SA, so it is encrypted.  The keys are, of course, encrypted with the 
tree scheme as well.

The rekey array is a piece of the key download, but in not identical.

>
>
> In "{}SigX      :Indicates minimum fields used in Signature," I don't 
> understand the reference to minimum fields.

The terminology is a little confusing, I agree.  I believe it is a bit 
of a legacy from the original ISAKMP model, where additional payloads 
could be added to any message.  The brackets indicate what fields are 
expected under the signature, which does beg the question, "why the 
square brackets, then?"

>
> Finally, it may be useful to tailor some of the terminology in this 
> document along the lines of GKM architecture document.  Furthermore, 
> it will be easier for folks planning to analyze the protocol to have 
> all the definitions (e.g., NonceC = ..., ACK construction) in the 
> running text, not in payload definitions.
>
> May I suggest replacing Key Creation payload with Key Exchange payload? 

>
>
> thanks,
> Lakshminath
>
> PS:  The I-D lacks a security considerations section.  You might have 
> included one in the latest version. 

Yes, it was made available to the list this morning.

Thanks for your comments.

--- Andrea

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

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Jul 2003 16:05:27 -0400

Thanks Andrea.  I did address them for Hugh, but the questions are for 
GSAKMP authors/editor(s).

Before, we get to the current thread, can I ask why we cannot use IKEv2 
model of 4/6 messages instead of the 3/5 messages in the current I-D? 
At that point we can call it GDOIv2 and be done with protocols in this 
group once and for all (I see *5* different IETF protocols for group key 
management so far, viz., GKMP, tGSAKMP, GDOI, GSAKMP, GDOIv2) !  Any 
opinions on this?

Thanks for the clarification on SEQ numbers; however my point about 
specifying the protocol processing in the description section (Sec 4) 
rather than in payloads section (Sec 6) still stands.

Is the SEQ number usage in GSAKMP different than message-IDs in IKEv2? 
A section about the Seq ID works during Registration and the Rekey, in 
the GCKS and in the SGCKSs would be necessary for the spec to be complete.

Section 3 should probably be renamed as "Basis of security" or something 
like that, and there should be a security considerations at the end 
discussing what GSAKMP covers and what is out of scope (security wise). 
  Or just move Section 3 to the end.

Additional comments inline:

> immediately or whether some buffering of updates to the Rekey SA occurs 

This text should be in the I-D.

This to me is a big disadvantage of the 3 message protocol.  The 
rationale I recall is that the final message allows the 
accounting/auditing/billing systems to kick in.  However, if that 
message is lost in transit, the GCKS might end up rekeying the whole 
group.  This is inefficient in that an unsuccessful registration may end 
up affecting all members.  If rekeying is done via unicast, this problem 
ends up requiring several messages.

If the policy to avoid this problem is to periodically rekey the group, 
the rationale for the 3 message (as opposed to 4 message version) 
exchange falls apart; members can then gain access to a secure group, 
albeit for a relatively short while, subverting the accounting/auditing 
processes.

> misunderstanding your DoS attack?

If a member could verify the keyed hash before trying to verify the 
signature, we can avoid the DoS attack of an adversary sending bogus 
rekey messages (a simple replay succeeds as a DoS attack on the members' 
computational resources).

> SA, so it is encrypted.  The keys are, of course, encrypted with the 

Is the rekey message sent via the data security protocol (e.g., IPsec), 
not a separate rekey protocol?   In either case, you might specify that 
clearly in Sec 4.3.

Thanks again Andrea!

best,
Lakshminath

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 01 Jul 2003 17:51:20 -0400

Lakshminath,

Lakshminath Dondeti wrote:

> Before, we get to the current thread, can I ask why we cannot use 
> IKEv2 model of 4/6 messages instead of the 3/5 messages in the current 
> I-D? At that point we can call it GDOIv2 and be done with protocols in 
> this group once and for all (I see *5* different IETF protocols for 
> group key management so far, viz., GKMP, tGSAKMP, GDOI, GSAKMP, 
> GDOIv2) !  Any opinions on this? 

Hmm.  I believe that tGSAKMP and GKMP are both considered historical. 
 GDOI, I have always believed, is somewhat more streamlined to IPsec. 
 The differences between GDOI and GSAKMP have been debated before.  I am 
not familiar with GDOIv2.

IKEv2 is a pairwise SA that protects identities somewhat.  Four messages 
are needed to do this.  I don't think that the concept of a GCKS maps to 
that of a peer very well, so I do not really see the urgency of going to 
the four/six model.  Perhaps there are other reasons, I haven't given it 
much more thought.  IKEv2 was not around at the beginning of GSAKMP 's 
three message rebirth.

> the GCKS and in the SGCKSs would be necessary for the spec to be 

Not different.  I agree that this discussion should be included.

>
>
> Section 3 should probably be renamed as "Basis of security" or 
> something like that, and there should be a security considerations at 
> the end discussing what GSAKMP covers and what is out of scope 
> (security wise).  Or just move Section 3 to the end. 

Interesting section title ;-)

>>> value.  If the message signature or nonce does not verify, the 
>>> session MUST be terminated.  GSAKMP sends a properly authenticated 
>>> message with a Notification Payload of type NACK to indicate 
>>> termination. "
>>>
>>> member has no way of knowing whether the message has been delivered 
>>> or not (at least not in the first case :-) ).  In either case, it 
>>> can go on to install the data security SA and listen in on secure 
>>> group communications.  What is the GCKS expected to do?
>>>
>>> It sounds counter-intuitive to do nonceC checking after keys have 
>>> been distributed.  Is this to finish in three messages?
>>>
>>> What does session termination mean in the context of 4.2.3?   Does 
>>> the GCKS terminate/update the Registration SA, Rekey SA or the Data 
>>> Security SA, or all?  If it is Registration SA, it does not affect 
>>> the member, does it? 
>>
>>
>>
>> Without the use of a synchronized timestamp, we need a minimum of 
>> three messages to complete the authentication including freshness.  
>> If the authentication fails for any reason (e.g., replay, lost 
>> messages) then the GCKS needs to respond in a policy-appropriate 
>> manner.  In most cases, this will involving keying the failed 
>> potential member out through an update of the Rekey SA.  Once again, 
>> whether this occurs immediately or whether some buffering of updates 
>> to the Rekey SA occurs is a matter of policy.
>
>
> group.  This is inefficient in that an unsuccessful registration may 
> end up affecting all members.  If rekeying is done via unicast, this 
> problem ends up requiring several messages.
>
> If the policy to avoid this problem is to periodically rekey the 
> group, the rationale for the 3 message (as opposed to 4 message 
> version) exchange falls apart; members can then gain access to a 
> secure group, albeit for a relatively short while, subverting the 
> accounting/auditing processes.

The key exchange components are sent in signed messages, therefore, 
although it may potentially be a replay, it is still source authentic in 
that the D-H publics are still bound to the signature of the original 
source. This will not result in inappropriate disclosure of data in most 
groups as most groups will likely only provide the key if the member is 
authorized in the first place.

The lack of an ACK (poetry here) resulting in a rekey is only necessary 
for certain types of groups (e.g., fee for service arrangements).  It is 
related to the issue of being able to force acknowledgement of receipt 
of key.  The amount of disclosure can be limited by rekeying prior to 
actual service start or by timing rekeys to occur periodically.  Sort of 
like watching the first few minutes of pay per view for free :-)  Again, 
this is really just for the few groups that are set up this way, most 
groups won't care if the ACK is lost.   If rekey really needs to be 
limited, another option is to use tcp as that would limit the dropped 
ACKs to deliberate cases.

> rekey messages (a simple replay succeeds as a DoS attack on the 
> members' computational resources).

Since the rekey is sent under the data protection SA, it wouldn't even 
decrypt unless it is from an "insider".  DoS is therefore also limited 
to insiders.

> Is the rekey message sent via the data security protocol (e.g., 
> IPsec), not a separate rekey protocol?   In either case, you might 
> specify that clearly in Sec 4.3. 

Actually, now that you point it out, I believe we decided that it may be 
under the data SA, but wasn't necessarily.  If not, the DoS against a 
member could be an issue.  I wonder though, if it is significant? 
 Sending erred Key Downloads to a member would only be a significant 
resource consumption if the member was expecting a KD and processed 
repeats.  DoS by not letting them in the group on the other hand, could 
be accomplished easily with or without the keyed hash.

Oh, well, regardless, you have a good point that it needs to be 
specified more clearly how the rekeys are sent.  

Thanks again for your very close review of this and for discussing this 
on the list.  Additional comments are always welcomed.

--- Andrea

---

From: George Gross <[email-masked]>
Date: Fri, 4 Jul 2003 20:19:39 -0400 (EDT)

Hi Andrea,

	I have been taking a quick look at GSAKMP v03, and consequently
some of my comments may be off the mark because it was such a quick look.

In several cases, there is an omission of detail in the specification for
some "first mention" passages, albeit later in the spec you add details

For example in section 4.2.1.2, the spec says:

"The Policy Token and Key Download payloads are sent encrypted in the KEK
generated by the Key Creation payload information using the mechanisms
defined in the group announcment."

However, the group announcement is done out of band and it is not defined
within this specification. Yet here it directly impacts what algorithms
and key lengths one would expect to encounter in the Key Download message.
This seems to be a place where you would say something like:

"...using the mechanisms defined in the group announcement, which are
required to be identical to the set defined for IKEv2, or the IANA
registry's current set of algorithms. This includes the same MUST
implement requirements as IKEv2"

or some words to that effect (wordsmithing TBD). Or did you really mean to
say "group policy token" rather than group announcement?

In the Request To Join (RTJ) message, the spec says that the GCKS must
verify each of the fields in that message, including the nonce. However,
there was no mention of any anti-replay mechanism that would have assured
the freshness of that nonce. Does the GCKS implicitly keep a list of
nonces used per GM? If so, this section should say so. I infer that I'm
missing something that was probably not said explicitly in this text
(section 4.2.1.1). In other words, please specify what it means to verify
the nonce field, and for that matter, any of the other fields: e.g. the
group identifier must have some kind of list that the GKCS consults to
know who are possible authorized members.

I would have thought that table 6 should have included a group
identification type definition for IPv6 as well as IPv4. Does GSAKMP work
with IPv6?

Several sections mention the optional use of LKH. Could you please
indicate the intellectual property status of LKH? For that matter, any
other aspects of GSAKMP?

Is there a way to add vendor-specific extensions to the RTJ, Key Download,
Rekey, and other messages? If so, please create a paragraph that discusses
that capability. If not, I'd like to ask that capability be created in the
protocol.

Regretably, I am leaving on vacation tomorrow, and will be offline until
7/16. I apologize for the awkward timing, but I decided that if I didn't
offer comments now, the door might be closed by the time I returned. If it
turns out my quick review was so quick that I overlooked things that
answered my above questions, I'd certainly stand corrected, and will look
more closely once I'm back ;o)

br,
	George Gross

---

From: Mark Baugher <[email-masked]>
Date: Mon, 07 Jul 2003 08:48:53 -0700

At 08:19 PM 7/4/2003 -0400, George Gross wrote:
<...>

>indicate the intellectual property status of LKH? For that matter, any

Regarding LKH, it's in the public domain to my knowledge.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Fri, 18 Jul 2003 14:57:11 -0700

George
   I could not find it on http://www.ietf.org/ipr.html.

Mark
At 03:40 PM 7/18/2003 -0400, George Gross wrote:
>Hi Mark,
>
>         a follow up inline below....
>
>br,
>         George
>
>
>On Mon, 7 Jul 2003, Mark Baugher wrote:
>
>I am not so sure if it is or is not. In my review of multicast IPR, I came
>across patent# 6049878 held by Sun. While I am not a patent attornory,
>from a technical perspective there seems to be alot of resemblance between
>LKH and this patent. The only thing that differs from vanilla LKH from
>what I could see is that sub-group membership assignment was based on 0/1
>state of bit positions in each node's identifier. However, interpreting
>the claims is not in my realm of expertise. Could anyone from Sun (or
>someone familiar with this area) please comment on this? A search of the
>IETF IPR page for "multicast"  as a search keyword did not turn up
>anything about this. I'd like to avoid a silent submarine ;o(

---

From: George Gross <[email-masked]>
Date: Fri, 18 Jul 2003 16:43:40 -0400 (EDT)

Mark,

>    I could not find it on http://www.ietf.org/ipr.html.

That's correct. But if Sun has claim on LKH, Sun could assert that IPR at
_any_ time in the future regardless of not yet posting to the IETF IPR
page as of today.

BTW, I took a quick look at Bradner's ipr-technology-rights-10.txt draft.
Section 8 seems relevant:

  "An IETF consensus has developed that no mandatory-to-implement security
technology can be specified in an IETF specification unless it has no
known IPR claims against it or a royalty-free license is available to
implementers of the specification unless there is a very good reason to do
so.  This limitation does not extend to other security technologies in the
same specification if they are not listed as mandatory-to-implement..."

GSAKMP says that LKH is optional to implement, but I have not heard the
reasons why. Did the MSEC group decide that inter-operable forward secrecy
is optional because of complexity? Or IPR?

---

From: Mark Baugher <[email-masked]>
Date: Fri, 18 Jul 2003 16:24:07 -0700

George

>_any_ time in the future regardless of not yet posting to the IETF IPR

One could assert any patent at any time.  The best we can say is that none 
are being asserted against RFC 2627.  Sun has pressed IPR against other RFCs.

>is optional because of complexity? Or IPR?

No, I don't believe LKH IPR has been a factor in any of our decisions in 
msec.  GDOI has LKH as an optional component simply because many 
implementations don't need it.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Mon, 21 Jul 2003 08:04:47 -0700

Uri Meth sent me a private note that reminded me that LKH is not the only 
solution in this space.  Far from it.  One should also consider McGrew & 
Sherman One-way Function Trees (OFT).  Lakshminath might also agree that 
subset difference is another alternative, and it is one that has RAND 
(reasonable and non-discriminatory) licensing terms.  Ultimately, if you 
want to be lawsuit-proof in your technology choices, then license the 
technology from a company that will accept any expected or surprise 
lawsuits covering that technology.  There are many surprises when it comes 
to IPR encumbrances.

Mark

>--
>Uri Meth                            (410) 872 - 1515 x233 (voice)
>SPARTA, Inc.                        (410) 872 - 8079      (fax)
>7075 Samuel Morse Drive             [email-masked]
>Columbia, MD 21046

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 21 Jul 2003 11:14:38 -0400

We have known about the LKH patent for a while now.  I am not sure 
whether it is applicable to d>2 though.  OFT, as I recall, does not have 
IPR (David McGrew mentioned this at some IETF WG meeting).  I did not 
know that SDR has IPR on it (Did IBM post RAND on it?).

regards,
Lakshminath

Mark Baugher wrote:

> Uri Meth sent me a private note that reminded me that LKH is not the 
> only solution in this space.  Far from it.  One should also consider 
> McGrew & Sherman One-way Function Trees (OFT).  Lakshminath might also 
> agree that subset difference is another alternative, and it is one 
> that has RAND (reasonable and non-discriminatory) licensing terms.  
> Ultimately, if you want to be lawsuit-proof in your technology 
> choices, then license the technology from a company that will accept 
> any expected or surprise lawsuits covering that technology.  There are 
> many surprises when it comes to IPR encumbrances.
>
> Mark
>
>
>> >
>> > George
>> >

---

From: Mark Baugher <[email-masked]>
Date: Mon, 21 Jul 2003 08:40:46 -0700

At 11:14 AM 7/21/2003 -0400, Lakshminath Dondeti wrote:
>We have known about the LKH patent for a while now.  I am not sure whether 
>it is applicable to d>2 though.  OFT, as I recall, does not have IPR 
>(David McGrew mentioned this at some IETF WG meeting).

I would not say that there is no IPR encumbrance on any technology because 
it's too complex a question.  For starters, there are US patents and 
International patents to worry about just in the US.  Then there is the 
applicability of a patent, that can be hard to determine and requires IPR 
expertise.

That being said, I don't know of any IPR claims on OFT, which is not an 
IETF protocol at present.   And I'd expect Sun to have notified the 
Internet community if it intended to press IPR claims on RFC 2627 but could 
not find any such notification in the IETF repository of IPR claims.

Mark

>I did not know that SDR has IPR on it (Did IBM post RAND on it?).
>
>regards,
>Lakshminath
>
>Mark Baugher wrote:
>
>>(reasonable and non-discriminatory) licensing terms.
>>Ultimately, if you want to be lawsuit-proof in your technology choices, 
>>then license the technology from a company that will accept any expected 
>>or surprise lawsuits covering that technology.  There are many surprises 
>>when it comes to IPR encumbrances.
>>
>>Mark
>>
>>
>>> >
>>> > George
>>> >