Subject: [MSEC] Re: GSAKMP Protocol comments

From: Haitham Cruickshank <[email-masked]>
Date: Mon, 10 Mar 2003 17:47:01 +0000

Hi Peter,

Further to your email below, we would like to discuss the issue of
Failure Notification between GSAKMP Servers and clients and its relation
to DoS attacks.  Our thought at University of Surrey and Logica are as
follows:

We should separate authentication from authorisation issues between the
server and clients.  Authentication procedures with the GSAKMP client
sending Request To Join (RTJ) to the GSAKMP Server is just
authenticating the RTJ message and can be open to DoS attacks.  However
the GSAMKP Server might be connected to an AAA Server to check of  that
the "well known user" is authorised to join the group.

Here is our idea and it is open for discussions:  Is it possible to have
an OPTIONAL Failure Notification messages that sent by the GSAKMP server
only if the user is "well known" but the authorisation procedure has
failed (e.g. the user did not pay his bills).  In this way, we minimize
the DoS attack possibilities.  Of course if the RTJ authentication
fails, the GSAKMP server does NOTHING.

The alternative is to have a seperate unicast channel for the failure
notifications, outside the GSAKMP system.

Regards
Haitham

Peter Lough wrote:

> Gavin, There is currently work underway here at SPARTA to finalize the
> current revision of the GSAKMP document.  As I understand, there has
> been some comments, from you and others working with you at Logica and
> University of Surrey, regarding the inclusion of cookies as an
> anti-clogging mechanism as well as the inclusion of additional failure
> notification during the group creation phase of the GSAKMP
> exchange. We would like to be responsive to these issues in the
> current revision and would like you to refresh us on you concerns with
> these or any other issues that have arisen.  We think the majority of
> these discussions will be material to the MSEC community at large and
> to that end would like to handle them via those channels.  If you
> would like to format a response to this and simply send it to MSEC as
> well, that might be most useful.  We will angle our discussions
> through the community as well.  Of course we can have any necessary
> sidebar discussion. Thanks, Peter LoughSPARTA, Inc.

--
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: Hugh Harney <[email-masked]>
Date: Tue, 11 Mar 2003 11:01:18 -0500

Haitham,

I see your point in desiring a separation between authentication and 
authorization. It may be useful to send a management message to a user 
that has passed all the security relevant steps in the GSAKMP RTJ 
processing, but has not passed a purely administrative step.

Your idea of sending an Optional failure notification is interesting. 
Perhaps we may want to expand this idea to a set of generic management 
messages. We could use a management message for failure to pay bills, 
requests for de-registration, audit, or expanded error notifications.

Do you have a concept in mind for the structure of these messages?

Hugh

On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank wrote:

> Failure Notification between GSAKMP Servers and clients and its 
> relation to DoS attacks.  Our thought at University of Surrey and 
> Logica are as follows:
>
> We should separate authentication from authorization issues between 
> the server and clients.  Authentication procedures with the GSAKMP 
> client sending Request To Join (RTJ) to the GSAKMP Server is just 
> authenticating the RTJ message and can be open to DoS attacks.  
> However the GSAMKP Server might be connected to an AAA Server to check 
> of  that the "well known user" is authorised to join the group.
>
> Here is our idea and it is open for discussions:  Is it possible to 
> have an OPTIONAL Failure Notification messages that sent by the GSAKMP 
> server only if the user is "well known" but the authorisation 
> procedure has failed (e.g. the user did not pay his bills).  In this 
> way, we minimize the DoS attack possibilities.  Of course if the RTJ 
> authentication fails, the GSAKMP server does NOTHING.
>
>  Gavin, There is currently work underway here at SPARTA to finalize 
> the current revision of the GSAKMP document.  As I understand, there 
> has been some comments, from you and others working with you at Logica 
> and University of Surrey, regarding the inclusion of cookies as an 
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: Haitham Cruickshank <[email-masked]>
Date: Tue, 11 Mar 2003 16:59:16 +0000

Hi Hugh,

Hugh Harney wrote:

> Haitham,
>
> I see your point in desiring a separation between authentication and authorization. It may be useful to send a management message to a user that has passed all the security relevant steps in the GSAKMP RTJ processing, but has not passed a purely administrative step.
>
> Your idea of sending an Optional failure notification is interesting. Perhaps we may want to expand this idea to a set of generic management messages. We could use a management message for failure to pay bills, requests for de-registration, audit, or expanded error notifications.
>

In GSAKMP- Light draft and within the notification payload, there is a field for Notify Message Type and one of the values is:

Unauthorised Request = 19

This can be used by the GSAKMP Server as an OPTIONAL Failure Notification.

Is that OK.

Haitham & Sunny

>      Further to your email below, we would like to discuss the issue of Failure Notification between GSAKMP Servers and clients and its relation to DoS attacks.  Our thought at University of Surrey and Logica are as follows:
>
>      We should separate authentication from authorization issues between the server and clients.  Authentication procedures with the GSAKMP client sending Request To Join (RTJ) to the GSAKMP Server is just authenticating the RTJ message and can be open to DoS attacks.  However the GSAMKP Server might be connected to an AAA Server to check of  that the "well known user" is authorised to join the group.
>
>      Here is our idea and it is open for discussions:  Is it possible to have an OPTIONAL Failure Notification messages that sent by the GSAKMP server only if the user is "well known" but the authorisation procedure has failed (e.g. the user did not pay his bills).  In this way, we minimize the DoS attack possibilities.  Of course if the RTJ authentication fails, the GSAKMP server does NOTHING.
>
>      The alternative is to have a seperate unicast channel for the failure notifications, outside the GSAKMP system.
>
>      Regards
>      Haitham
>
>      Peter Lough wrote:
>
>      Gavin, There is currently work underway here at SPARTA to finalize the current revision of the GSAKMP document.  As I understand, there has been some comments, from you and others working with you at Logica and University of Surrey, regarding the inclusion of cookies as an anti-clogging mechanism as well as the inclusion of additional failure notification during the group creation phase of the GSAKMP exchange. We would like to be responsive to these issues in the current revision and would like you to refresh us on you concerns with these or any other issues that have arisen.  We think the majority of these discussions will be material to the MSEC community at large and to that end would like to handle them via those channels.  If you would like to format a response to this and simply send it to MSEC as well, that might be most useful.  We will angle our discussions through the community as well.  Of course we can have any necessary sidebar discussion. Thanks, Peter
>      LoughSPARTA, Inc.
>
>      --

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

---

From: "Peter Lough" <[email-masked]>
Date: Tue, 11 Mar 2003 12:10:15 -0500

I think using the existing Notification payload and extending the types so
that additional information can be passed is useful.  In addition to:

Unauthorized Request = 19

the table might be expanded for example to include:

Account Delinquent = 129

or Unauthorized Request could be extended to have an application specific
value added.  However, as this is used for more detailed information, I
think the protocol should allow for that information to be encrypted via the
DH exchange that is begun in preparation for the key download.  There may be
cases where you don't want others with access to that data channel to know
that a particular account is delinquent or other specific information about
the reason for failure.  Encrypting it between the two entities would solve
that issue.

To do this, the protocol could simply allow a message back from the server
with a Key Creation Payload and a Notification Payload encrypted in the
resultant KEK.

Pete
----- Original Message -----
From: "Haitham Cruickshank" <[email-masked]>
To: "Hugh Harney" <[email-masked]>
Cc: <[email-masked]>; "Sunil Iyengar"
<[email-masked]>; "Peter Lough" <[email-masked]>
Sent: Tuesday, March 11, 2003 11:59 AM
Subject: Re: [MSEC] Re: GSAKMP Protocol comments

> > I see your point in desiring a separation between authentication and
authorization. It may be useful to send a management message to a user that
has passed all the security relevant steps in the GSAKMP RTJ processing, but
has not passed a purely administrative step.
> In GSAKMP- Light draft and within the notification payload, there is a
> >      Further to your email below, we would like to discuss the issue of
Failure Notification between GSAKMP Servers and clients and its relation to
> >      We should separate authentication from authorization issues between
the server and clients.  Authentication procedures with the GSAKMP client
sending Request To Join (RTJ) to the GSAKMP Server is just authenticating
the RTJ message and can be open to DoS attacks.  However the GSAMKP Server
might be connected to an AAA Server to check of  that the "well known user"
is authorised to join the group.
have an OPTIONAL Failure Notification messages that sent by the GSAKMP
server only if the user is "well known" but the authorisation procedure has
failed (e.g. the user did not pay his bills).  In this way, we minimize the
DoS attack possibilities.  Of course if the RTJ authentication fails, the
GSAKMP server does NOTHING.
> >
> >      The alternative is to have a seperate unicast channel for the
failure notifications, outside the GSAKMP system.
> >      Gavin, There is currently work underway here at SPARTA to finalize
the current revision of the GSAKMP document.  As I understand, there has
been some comments, from you and others working with you at Logica and
University of Surrey, regarding the inclusion of cookies as an anti-clogging
mechanism as well as the inclusion of additional failure notification during
the group creation phase of the GSAKMP exchange. We would like to be
responsive to these issues in the current revision and would like you to
refresh us on you concerns with these or any other issues that have arisen.
We think the majority of these discussions will be material to the MSEC
community at large and to that end would like to handle them via those
channels.  If you would like to format a response to this and simply send it
to MSEC as well, that might be most useful.  We will angle our discussions
through the community as well.  Of course we can have any necessary sidebar
discussion. Thanks, Peter

---

From: Hugh Harney <[email-masked]>
Date: Wed, 12 Mar 2003 10:44:47 -0500

Pete and Haitham,

I agree the notification payload could be used to send some management 
information back to a member trying to join a group. I think that the 
payload should be put into a new class of message. This is a management 
information class of message.

The reason I advocate moving this function to another message class is 
that it doesn't directly impact the creation of the cryptographic 
group. We need to keep the key exchange protocol simple, easy to 
evaluate. The management messages are critical but not 
cryptographically important. So, let's put them in their own message 
and give us flexibility in how to use those messages.

The management information message could be used to notify a joining 
member of their state, or it could be used to send group management 
information between group entities - GC to Subordinate GC, GC to GO. 
These messages could make use of existing pairwise keys to protect the 
transmission or they could be sent in the clear or they could be sent 
using a pairwise secure association.

I think this management issue is larger than just the notification to 
the GM from the GC. I'd like to capture this in the spec in a way that 
would allow future developers flexibility to use the management message 
structure.

Hugh

On Tuesday, Mar 11, 2003, at 12:10 US/Eastern, Peter Lough wrote:

> that
> relation to
> client
> authenticating
> procedure has
> has
> anti-clogging
> sidebar
Hugh Harney							Sparta, Inc.

---

From: Haitham Cruickshank <[email-masked]>
Date: Wed, 12 Mar 2003 15:58:47 +0000

Hi Hugh again,

I fully agree with your proposal.

Haitham