Subject: [MSEC] Addition to GSAKMP-Lite

From: "Kenny, Gavin (Space)" <[email-masked]>
Date: Wed, 24 Jul 2002 15:22:23 +0100

Hi,

I am looking at using GSAKMP-Lite to secure multicast
transmissions over satellite and from going through
the RFC, there does not seem to be any rejection
notification sent to the client should it's request to
join be turned down. I appreciate that in some
circumstances you don't want to give away any more
information than you have to, but for my application
where messages may get lost or corrupted due to the
transmission medium it would be nice to have a
mechanism that supplied positive feedback. 

Such feedback could also be used to encourage the client to
pay for a service. i.e. "You are rejected", the client
would know this is because it hasn't paid a membership
fee, it could then initiate a payment mechanism and
reapply to join.

I recognise that GSAKMP supplies such a mechanism via
the notification payload (e.g. unauthorized request),
but I couldn't see this in GSAKMP-Lite, which would be
better for satellite use, due to the reduced number of
exchanges. I was wondering what the views of the list
were on this. 

regards,

Gavin

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: Uri Meth <[email-masked]>
Date: Wed, 24 Jul 2002 14:15:15 -0400

Gavin,

You raise 2 issues in your post:
  a) The ID does not discuss if and when a rejection notification is
     sent.
  b) Should a rejection notification be sent if the request to join
     is turned down.

In response to (a) that the ID does not discuss if and when to send a
rejection notification, it is correct that this discussion was left
out.  Please refer to draft-ietf-msec-gsakmp-sec-01.txt, the RFC for
GSAKMP (not GSAKMP-Lite), in sections 3.1 Group Establishment and 3.2
Group Maintenance where this discussion can be found.  It seems from
the question, that a similar discussion detailing the exchange would be
beneficial in the GSAKMP-Lite document as well.  

As we are gearing up to update the GSAKMP-Lite document, input from the 
list on the inclusion of a similar type discussion would be greatly
appreciated.

In reference to point (b) concerning sending a rejection notification if
the request to join is turned down, the above referenced discussion
stated that no rejection would be sent.  The only time rejection
notification was sent is if the mutually suspicious exchange had already
been initiated and an incorrect message was received, then the NACK
would be sent.  From the GSAKMP-Lite perspective, the only time a NACK
should/would be sent is for rejected messages starting with the
Light-Key-Download.  The concern was that if rejection notifications
were sent for a rejected request to join, this could potentially be a
Denial of Service attack against the host containing the Group
Controller in that in addition to processing the message, the Group
Controller would also be required to respond to the message.  Also, if
the initial request to join had been built with incorrect information as
to the identification of the sender, the Group Controller host would be
sending the rejection notification back to an unsuspecting host draining
it's resources.
Can it be shown that this would not be a DoS attack?  If so, then a
rejection notification can be sent back upon rejection of the request to
join without affecting performance.

UM

>Date: Wed, 24 Jul 2002 15:22:23 +0100
>
>Hi,
>
>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.
>

-- 
Uri Meth                            (410) 381 - 9400 x233 (voice)
SPARTA, Inc.                        (410) 381 - 5559      (fax)
9861 Broken Land Parkway, Suite 300 [email-masked]
Columbia, MD  21046