Subject: [MSEC] registration protocol PT omissions?

From: George Gross <[email-masked]>
Date: Wed, 15 Jun 2005 23:30:39 -0400 (EDT)

Hi Andrea,

	Perhaps this was overlooked because they are optional, but should
not the ASN.1 GSAKMPv1RegistrationSA definition have a BOOLEAN flag to
indicate whether cookies are required by the GO policy in the registration
exchange? also, whether the GO requires that the registration exchange
will occur in terse/verbose mode? a similar mode flag also would be
required in the definition of GSAKMPv1DeRegistrationSA.

br,
	George

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

---

From: Andrea Colegrove <[email-masked]>
Date: Thu, 16 Jun 2005 11:02:09 -0400

George,
    The ability to turn cookies on/off is a dynamic local capability of 
the (S/)GCKSs, which is signalled inband based upon network conditions 
-- so this should not be set in the PT.

    Terse/verbose is indicated in the OpInfo structure.

Thanks,

Andrea

---

From: George Gross <[email-masked]>
Date: Thu, 16 Jun 2005 08:11:29 -0400 (EDT)

Hi Andrea,

> -- so this should not be set in the PT.

But we've made cookies support optional in GSAKMP section 5.2.2. So how
does a GC/KS know whether a candidate group member even supports the
cookies exchange? It would be reasonable policy for the GO to specify that
cookies are *not* to be used, because the GO knows that some subset of the
legitimate group member endpoints do not support cookies. Conversely, the
GO may require that all candidate GM support cookies as a matter of
policy.

>     Terse/verbose is indicated in the OpInfo structure.

Apparently a minor typo got into the spec's OpInfo declaration on page 21,
which is mis-declared as follows:

OpInfo ::= SEQUENCE {
  timeOut LifeDate
}

whereas the descriptive text on page 17 has it correctly stated (and which
I missed because I was only looking at my compiled ASN.1 source).

hth,
	George

---

From: Andrea Colegrove <[email-masked]>
Date: Thu, 16 Jun 2005 14:01:25 -0400

Hi George,

>GO may require that all candidate GM support cookies as a matter of
I do understand your concern, but DoS protections are for the benefit of 
the servers not the clients.  To tell a server that they cannot use 
cookies would impose policy on them from the GO.  A GCKS should only 
accept a policy if it doesn't violate local policy.  Furthermore, keep 
in mind that clients "MUST" respond with a cookie -- the cookie state is 
really optional for servers.

>I missed because I was only looking at my compiled ASN.1 source).
My error.  I will add this to the typo fixes.  Thanks for catching it.

--- Andrea