Subject: [MSEC] Réf. : Reliability & Secure Multicast

From: [email-masked]
Date: Wed, 2 Jul 2003 15:06:22 +0200

Hi Gavin,

>We're running a project which has produced a GSAKMP/LKH implementation for
>use over satellite networks. We have been running the system using a
>satellite link simulator with an error rate of 10-3 and a delay of 0.25s and
>it works great!

Your results seems very interesting, we would be very interested in reading more
about them. Do you have some public reports or publications available ?
We just have one question about your error rate of 10-3. Is it the bit error
rate after decoding or the packet error rate at MAC or network level ( at key
exchange level)?
Besides, concerning your delay of 0.25 s, does it not seem to be a little bit
short? Are you targeting one-way broadcast only satellite systems ? Indeed, with
DAMA algorithms for the return link (user terminal to hub), for sporadic low bit
rate, the delay can be between 0.25 and 2 s.

However we don?t totally agree with you about the need of reliability mechanisms
in group key management protocols for satellite systems.
The "world of satellite systems" is composed of two main system types : Fixe
broadband systems ( i.e. TV broadcasting) and Mobile systems.
Three optimized retransmissions of all re-key messages seem to fulfill the needs
of fixe broadcast systems without return link, that have an overprovisionned and
stable link budget. However, in mobile systems or versatile systems (fast
network inputs/outputs) , or heterogeneous systems, even with three
retransmissions, it is not certain at all that each group member receives all
re-keying messages. Reliability mechanisms ( based on Nack/ack) would be needed.
Finally, it seems easier and more optimized to add some reliability mechanisms
to Group Key Management protocols (such as GSAKMP) compared to the use of  a
reliable multicast transport protocol which shall also be secured (signature of
the Acks/Nacks) (Nowadays attacks are successfully launched on TCP exchanges).
Indeed, as adding lightweight reliability features in GSAKMP optimised for our
needs can be done for a very low cost, we don't see the need to use an external
multicast reliable protocol with its own additional signaling and byte overhead
for authentication and integrity check...

>   Finally, I don't see any difference between your Phase 3 and the MSEC
>Rekey protocol (called "groupkey push" in GDOI).  Are there significant
>differences?

Sorry for my slow response to Mark's question (from the mail below).
Indeed FMKE Phase 3 and GDOI "group key push" are similar. The only difference
is ... the use of reliability mechanisms (i.e. the use of Nacks and messages
from the GCKS indicating the last used sequence number).

Best regards,

Laurence

ALCATEL SPACE
RT/ST
Research Department / Advanced Telecom Satellite Systems
Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
E-Mail : [email-masked]

>Hi, Just to add my 2p worth.

>We're running a project which has produced a GSAKMP/LKH implementation for
>use over satellite networks. We have been running the system using a
>satellite link simulator with an error rate of 10-3 and a delay of 0.25s and
>it works great!

>All we did was to have all re-key messages repeated three times, one after
>another.

>Considering that most modern sat systems say they can give you an error rate
>of approx 10-7 or better, I don't think reliability is much of an issue in
>real world applications. I appreciate it is nice to close the loop, as it
>were, but I think the downside of using up valuable bandwidth and time (in a
>long transmission delay environment) with acks and nacks is hard to justify.

>I would vote on keeping reliability in a separate layer as multicast is
>great for satellite transmission but a constant return path is not always
>available.

>regards

>Gavin

>-----Original Message-----
>From: Mark Baugher [mailto:[email-masked]]
>Sent: 27 June 2003 16:14
>To: [email-masked]
>Cc: Brian Weis; [email-masked]; Lakshminath Dondeti;
>[email-masked]
>Subject: [MSEC] Re: [MSEC] Réf. : Re: [MSEC] Réf. : Re: [ MSEC] R éf. :
>[MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt]

>Laurence,
>   We discussed putting reliability mechanisms into GDOI about three years
>ago.  The decision of the secure multicast research group (SMuG) at that
>time was to use the mechanisms that are being developed by another group,
>the reliable multicast group, rather than develop our own.  MSEC has also
>taken this approach.

>   So, before we incorporate reliable multicast into an MSEC key management
>protocol, we need to revisit this decision and discuss the pro's and con's
>of having an ACK or NAK mechanism built into key management versus using a
>separate layer.  The advantage that I see of using a separate layer is what
>one generally gets from design modularity:  We can choose among the best
>mechanisms for a particular application.  As new reliable multicast
>protocols and algorithms are developed, these can be used by the key
>management protocol without the need to change the specification of the key
>management protocol.

>   Now, what are the advantages to mixing up reliable multicast with key
>establishment?

>   Finally, I don't see any difference between your Phase 3 and the MSEC
>Rekey protocol (called "groupkey push" in GDOI).  Are there significant
>differences?  I think the similarities in the protocols favor Ran's
>suggestion of including this work with the GDOIv2 effort that MSEC is
>likely to begin.

>Mark

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

>This e-mail and any attachment is for authorised use by the intended
recipient(s) only.  It may contain proprietary >material, confidential
information and/or be subject to legal privilege.  It should not be copied,
disclosed to, >retained or used by, any other party.  If you are not an intended
recipient then please promptly delete this e-mail >and any attachment and all
copies and inform the sender.  Thank you.

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 03 Jul 2003 08:27:35 -0700

Laurence,

At 03:06 PM 7/2/2003 +0200, [email-masked] wrote:
<...>

>the Acks/Nacks) (Nowadays attacks are successfully launched on TCP exchanges).

I don't think this makes the case why msec should build a reliable 
multicast protocol into its key management.  The arguments for using a 
reliable multicast protocol rather than incorporating one probably include 
the following.

1. allows us to select the best protocol for a particular application 
environment
2. allows us to introduce better protocols when they are developed
3. reduces the functionality and the complexity of the key management protocol

Are there others?

Probably the best (maybe the only) argument for including it in the key 
management is security.  We need to answer the following questions.

1. How can the security of the key management protocol be successfully 
undermined by attacking the reliable multicast protocol and is this true 
for all interesting reliable-multicast protocols.
2. How can incorporation of the reliable multicast protocol into the key 
management protocol protect against these attacks?
3. Is it possible to protect against these attacks without putting the 
reliable multicast protocol into the key management protocol.

Are there others?

It's good that you raise this issue now in msec because the previous 
discussion we had was some time ago in msec's predecessor group, IRTF SMuG.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 24 Jul 2003 08:07:45 -0700

Hi,
  We are working on the Last Call draft of the Group Key Management 
Architecture (gkmarch) I-D and need one final point on reliability for the 
re-key class of protocols.  Recall from gkmarch that re-key messages may 
may use multicast delivery.  Our unstated assumption has been that the key 
management protocol would use whatever reliable multicast mechanism that 
was considered to be applicable for a given application environment.  We 
want to use the protocols that come out of the reliable multicast transport 
(RMT) working group in the IETF.  RMT has not produced any standards-track 
documents, however, only experimental and informational standards have come 
from RMT to date.  I have reviewed the security considerations of these 
documents (briefly) and see no reason to incorporate one or more RMT 
building blocks into gkmarch protocols.

   MSEC group key management protocols assume that the network is under 
control of an attacker who can delay, reorder, alter, cut and paste, 
replay, and perform other mischief to key management messages.  ISAKMP 
protocols (I include GSAKMP, GDOI and MIKEY in this class) are designed to 
operate securely over insecure networks.  IKE builds reliability into its 
protocol although in principle, it could run over TCP.  One problem with 
securing TCP payloads but not TCP headers, however, is that an attacker 
could alter or forge a packet with a sequence number that forces the TCP 
window to be wrongly advanced but the forgery won't be detected until after 
the update to the TCP window.  This would cause a later, valid message to 
be rejected at the TCP layer.

   This might suggest that msec should incorporate reliable multicast 
mechanisms into its re-key message.  But it is simple to retransmit and IKE 
message until N timeouts or a re-key message M times to accommodate network 
loss.  It is not simple to incorporate an ACK, NACK, TRACK or some other 
reliable multicast protocol into the key management protocol.  Unless we 
can find a single reliable multicast protocol that will suit all purposes, 
moreover, we will have to incorporate a multiplicity of such protocols and 
this is a great complication.  We shouldn't do this.

   I think we should consider an alternative approach and that is to 
bootstrap the security for the reliable multicast protocol (RMP) at the 
time the msec registration protocol is run.  The RMP that key management 
uses needs to be in accordance with the policy of the key management 
system; that policy is implemented in the registration exchange.  Once the 
underlying reliable multicast connection is installed, the msec re-key 
message can use it and benefit from its DoS protections as well 
reliable-multicast service.

Mark

---

From: George Gross <[email-masked]>
Date: Thu, 24 Jul 2003 13:00:47 -0400 (EDT)

Hi Mark,
	inline....

br,
	George

On Thu, 24 Jul 2003, Mark Baugher wrote:

<snip...>

> this is a great complication.  We shouldn't do this.

OTOH, we do have an obligation to create an interoperable standard. It
should be possible for Vendor A to be the GCKS, and the group members to
be an arbitary mixture of Vendors B, C, D,...

Consider that in the absence of a mandatory to implement error recovery
mechanism, the implementations at a inter-op testfest would all
potentially bring their favorite (yet non-interoperable) RMT protocol to
the testfest. As you point out below, the selection of the RMT protocol is
a group policy decision, and therefore the policy token (or the key
management spec) will have a protocol field(s) whose values identifies the
RMT du jour mechanisms and parameters.

	Therefore, it is incumbent on the GKM-arch spec to define that
mandatory to implement mechanism. In other words, I think you probably are
forced into saying what a GCKS and a member must do to recover from an
error when RMT is not available, since there is no RMT standard to point
at. At the moment, GSAKMP doesn't say anything about this, nor does GDOI.
I would think we'd want _one_ rudimentary mechanism/strategy articulated
that is part of the MSEC proposed standards. Your pick whether it is in
the key management protocol specs in multiple places, or you elect to spec
it once in GKM-arch.  IKE handled this by defining a timeout and retry
policy. Seems to me that at the least that what we need here. In addition,
some verbage should explain how a member detects that it lost a rekey
message and how it should recover synchronization....

	This is tricky, since if the policy is to do a "leave group"
message followed by re-registration, there is a potential for
overwhelming/DoS the GCKS if large numbers of members trigger the same
error response at the same time. So the policy should have some ditter in
the timing constant. I know you expressed the view not to do this, but a
member->GCKS "notify" payload would avoid alot of the dropped data and
delay here...

> reliable-multicast service.

Ok, as long as it accomodates the above requirement wrt/ a mandatory to
implement RMP or a default error recovery policy when there is no RMP,
we're set.

A snapshot of the policy token spec should be frozen with this capability
in its v1 profile before GSAKMP can move forward to PS.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 28 Jul 2003 11:09:50 -0700

hello George,

>be an arbitary mixture of Vendors B, C, D,...

Good point.  This follows from the existence of interoperable reliable 
multicast protocols.  There are several candidate products and 
standards.  I'd like for msec group key management architecture to be able 
to use any of them that have good data security definitions for denial of 
service protection.  One might also want to use multicast source 
authentication (TESLA is mentioned as a requirement for RMT protocols, I 
think) from the underlying reliable multicast transport.

>the testfest.

So what?  They might also bring their own favorite (yet non-interoperable) 
authorization to the plugfest as well.  But I would not attempt to 
incorporate an authorization system in the group key management protocol in 
order to avoid this problem.

Here's what I think the msec group key management protocol should offer as 
a baseline:  A protected re-key message with sequence counter.  As a matter 
of local policy, a GCKS sender or a re-key message can send a re-key 
message as many times at whatever time intervals it chooses. When we have 
reliable multicast standards that are more than Experimental, the GCKS 
sender only needs to send out the message once - as a matter of local 
policy.  The group member will reject duplicates based on the sequence 
number in the authenticated message.

>As you point out below, the selection of the RMT protocol is

Unfortunately, I don't think we want to reference Experimental RFCs in a 
Standards-track specification.  Frankly, I'm not happy with where we are at 
with RMT.

>at. At the moment, GSAKMP doesn't say anything about this, nor does GDOI.

ftp://ftp.rfc-editor.org/in-notes/rfc3547.txt uses SEQ to order re-key 
messages (groupkey-push messages in GDOI parlance) so a receiver can detect 
a duplicate and discover one or more missed sequence numbers.  In the 
latter circumstance, the receiver has no other recourse than to run the 
groupkey-pull protocol and re-synchronize with the GCKS.

>that is part of the MSEC proposed standards.

I agree that the groupkey management architecture should address this topic 
(and this is why I am engaging you and others on this topic).  I think we 
should say that the rudimentary strategy is to use sequencing of re-key 
messages to allow (1) a sender to send multiple re-key messages, and (2) a 
receiver should discard duplicate re-key messages and respond to missed 
re-key messages.  (Note that in the latter case, re-ordered messages need 
to be taken into account).  One response is to re-synchronize with the 
GCKS.  This can have very bad ramifications when a lot of members 
synchronously contact the GCKS.  This and the concomitant DoS attacks need 
to be considered in the gkmarch as well.

>Your pick whether it is in

Well, we have that in GDOI.  It needs to be articulated in gkmarch.

>member->GCKS "notify" payload would avoid alot of the dropped data and

Perhaps so.

>implement RMP or a default error recovery policy when there is no RMP,

As I explained above, we don't have a standard RMP.  I don't think we need 
one so badly either.  I think the rudimentary approach will work well.  The 
alternative is to standardize an RMP in msec.  I don't think that should 
happen.

>in its v1 profile before GSAKMP can move forward to PS.

Thomas?  Ran?  What do you think?

Mark