Subject: Re: [MSEC] GSAKMP issue 02: security assumptions discussion

From: Uri Meth <[email-masked]>
Date: Tue, 9 Sep 2003 11:15:32 -0400

See inline comments.

On Fri, Aug 08, 2003 at 03:24:39PM -0400, George Gross wrote:
> 
> GSAKMP issue 02
> 
> Section and relevant text passage:
> 
> section 3 "Security Assumptions"
> 
> Comment/issue description:
> 
> This section needs to add some text explaining its assumption wrt/ the 
> multicast routing protocols, 

We make no assumption wrt multicast routing issues.
What you you mean, wrt security?  This point appears to be an
infrastucture issue.

> NAT,

As I understand it, NAT is a sender network issue, again not a security
issue.  If a site is using NAT, by the time it hits the outside world
and the GCKS, it is working with a real IP address, and that is what we 
deal with, we don't even know NATting is going on (just like no one else will).

Please explain your thoughts here wrt security.

> GSAKMP protocol version mismatch between GCKS and GM, 

This point will affect the specification in sections 4.2.1.1 through
4.2.1.3.  We will scrub these sections wrt error handling and state
specifically the error handling for each processed error, including
protocol number mismatch.

> and the reliable multicast transport protocols.

Again, we assume that no Reliable Multicast Protocol (RMP) is available.
Since by definition UDP is unreliable, the protocol allows for multiple send
of rekey message in the absence of a reliable network to increase the
chances that all members receive this message.

But again, I fail to see what this has to do wrt the security of the
protocol?  I must be missing something here, please expound.

> It also should make an explicit statement about whether the trust model 
> for "Security Suite 1" assumes
> that active attackers might compromise a Group Member(s) and whether 
> the group can recover from such a compromise.

I don't follow what you are getting at here.  Everyone knows the
configuration of Security Suite 1 (SS1), it is published in the standard.  So
what is there to compromise?  What  SS1 provides is a capability for the
GM and GCKS to converse using a short lived D-H exchange.  Are you
asking that this short lived exchange is compromised and what happens in
that instance, or are you asking something else in a broader context?
Please clarify.

> 
> Suggested issue resolution:
> 
> The above topics each deserve their own sub-section 3.x.
> 
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec

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

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

---

From: George Gross <[email-masked]>
Date: Tue, 9 Sep 2003 14:17:33 -0400 (EDT)

Hi Uri,

> What you you mean, wrt security?  This point appears to be an

This comment reflects discussion on this list in June of this year, wrt/
the MSEC architecture doc and whether the IGMP/MLD messages sent to
multicast routers should have some form of membership authentication and
authorization mechanisms. The conclusion was that is not a current IETF
work item, but that a discussion of the potential DoS attack should be
included in the respective MSEC key management protocol specs in the
security consideration sections. See Brian's post for a good summary:

http://www.pairlist.net/pipermail/msec/2003-June/000793.html

> Please explain your thoughts here wrt security.

there are several issues here:

1. The GSAKMP policy token embeds IP-v4 addresses within the Security
Association payload within section 2.4.1.3.1.2.

2. The group identifier in GSAKMP policy token section 2.1.1.4 is an IP-v4
address.

3. The GSAKMP header defined in section 6.1 of the GSAKMP protocol spec
uses a group ID that is an IP-v4 address.

In each of these cases, when the GSAKMP message traverses NAT, the IP-v4
addresses may be encrypted and/or authenticated and can not be altered by
NAT.

The GSAKMP specification has to discuss a solution for detecting the
presense of NAT, and how NAT gateways can (or can not) alter the GSAKMP
packet. For an example of how the protocol designers decided to handle NAT
wrt/ IKE-v2, see section 2.23 in the draft ipsec-ikev2-10.txt.

Bottom line: to traverse NAT, GSAKMP will require the specification of a
negotiation of UDP encapsulation similar as has been defined for IKE-v2.
It also will need to decide how embedded IP addresses within GSAKMP are
handled by NAT. BTW, there may be IPR on the ESP over UDP negotiation, so
I would advise taking a look at the IPR notices to the IETF. Much as one
might like, we can not ignore interactions with NAT :o(

Q: when an IP address is being used as the GSAKMP Group ID, is it a
multicast address? or an anycast address? or a vanilla unicast address?
Please specify in the document.

> protocol number mismatch.

Okay.

> protocol?  I must be missing something here, please expound.

An active attacker could intercept and drop a rekey event multicast
message, and trigger a DoS attack. A RMP would detect the dropped
delivery. Since you don't mandate a RMP, you need to specify the detection
and recovery mechanism. i.e. timers and maximum number of retries for the
various GSAKMP messages as part of the policy token and the specification.
It should say when to give up and do a re-registration.  Discussion on
this list (most recently in mid-August)  has also mentioned other error
recovery strategies, such as explicit request for resend from the GCKS,
and posting the rekey message in a well known directory/web site. Since
GSAKMP embodies a concept of multiple GCKS, that redundancy could be used
in the recovery process, if only it was specified.

> that instance, or are you asking something else in a broader context?

There are a variety of things that merit discussion:

1) This section should say something about GSAKMP being secure against
passive adversaries outside of the group membership, but it is vulnerable
to active attacks if a GM is compromised by an adversary. In other words,
since GSAKMP does not mandate a multicast source authentication mechanism,
a compromised GM could impersonate a peer. The compromised GM could not
impersonate a GCKS rekey because such messages are signed. You should
indicate the benefit of forward secrecy using LKH or other algorithm to
recover from this situation.

2) The GSAKMP protocol assumes that all GM and GCKS belong to a common PKI
or else have a certificate path to a common root CA. The spec should
indicate that the GO, GCKS, and GM all use a common configuration
mechanisms to setup their one or more trusted root CA keys. This mechanism
should be specified at a level that avoids inter-operability issues
between vendors.

3) The GSAKMP header contains a sequence number that is assumed to be
stored in non-volatile memory across GCKS reboots (or is it?, section 6.1
should discuss this).

4) If GSAKMP has any kind of dependency on timestamps or synchronization
of time across its endpoints, that should be stated (or if it does not,
say that). discuss "rollover" time during rekey.

5) You are not defining the use of TESLA or any other multicast source
authentication, correct? this section needs to say that.

6) Does the GSAKMP protocol assume that the data SA has only a single
multicast speaker? If not, then you should indicate that the receivers
need to keep per multicast source SA state for sequence numbers and SA
lifetime calculation.

7) what is the sliding window for acceptable sequence numbers in a rekey
message?

George

---

From: Hugh Harney <[email-masked]>
Date: Wed, 10 Sep 2003 11:32:56 -0400

George,

I see your issue with our use of IPv4 as a group ID field.

I think it best to remove the IPv4 reference in the Group ID field 
altogether. This is particularly true because we have seen that most 
groups do not have a tight coupling with an IP address anyway. This 
will be corrected in future PT releases.

The group ID must uniquely identify the cryptographic group, but it 
does not need to identify the IP address of the data stream.

> in the recovery process, if only it was specified.

I'm not sure I agree here. The key management protocol has to remain in 
a secure state. I think this is divorced from the reliable transport 
mechanism.

I agree that the km protocol has to specify detection and recovery 
mechanisms. I think this is best done wrt the keys and the successful 
rekey events. I think the keys must have a lifespan, and there has to 
be a local definition of mandatory rekey periods. Both of these events 
are within the domain of key management. I'm uneasy specifying security 
functionallity to non-security protocols.

I agree that we need to include mention of redundant error recovery 
strategies in the spec. I think these things help system architects use 
GSAKMP in a system, but the security mechanisms that can be relied on 
are the timers inside of GSAKMP.

> recover from this situation.

Yes this should be explained.
> should be specified at a level that avoids inter-operability issues

We did not assume this. The access control and authorisation rules have 
two parts. Rule and verification mechanism. The rule is specifically 
designed to match a particular verification mechanism. So rule 1 can be 
for PKI 1, rule 2 can be for PKI 2, rule 3 can relate to some database 
someone has.
> stored in non-volatile memory across GCKS reboots (or is it?, section 
OK
> say that). discuss "rollover" time during rekey.

So your saying it is unclear if there is a dependancy in our timers? We 
should state when the timer only need to reference the local clock.
> authentication, correct? this section needs to say that.
OK
> need to keep per multicast source SA state for sequence numbers and SA

Actually, GSAKMP makes no assumptions about the data layer security 
protocols. I think this is an issue for multicast IPSec. If the GSAKMP 
PT is supporting multicast IPSec then this is a field that can be 
added, but GSAKMP will  not be a consumer of this field. It will be 
passed through GSAKMP to the IPSec application.
> 7) what is the sliding window for acceptable sequence numbers in a 

This can be an added field to help specify the rekey mechanisms in the 
PT. Is this adiquate?

>>> The above topics each deserve their own sub-section 3.x.

In some cases the topic is best included to clarify existing text.

Hugh

---

From: George Gross <[email-masked]>
Date: Wed, 10 Sep 2003 13:12:20 -0400 (EDT)

Hugh,

Your reply dropped the following text from my e-mail and you did not
respond to it:

> handled by NAT. BTW, there may be IPR on the ESP over UDP negotiation,
> so I would advise taking a look at the IPR notices to the IETF. Much as
> one might like, we can not ignore interactions with NAT :o(

Please indicate how you are handling NAT detection and negotiation of ESP
over UDP.

other comments inline...

> does not need to identify the IP address of the data stream.

Ok, so then the IP address of the data stream get specified in the policy
token, right? I think this needs to be an authenticated quantity specified
by the GO. OTOH, this gets clobbered by NAT ;o( sigh. perhaps a domain
name for the group?

> a secure state. I think this is divorced from the reliable transport

So do I hear you saying that even though GSAKMP may have multiple GCKS,
there is no mechanism specified to recover from a lost rekey other than
re-registration? e.g. the existing registration SA is not used to recover?

> are the timers inside of GSAKMP.

The GSAKMP spec and/or PT will need to specify minimum, maximum, and
default values for these timers to assure inter-operability.

> for PKI 1, rule 2 can be for PKI 2, rule 3 can relate to some database

Ok, then please clarify the text to explain this usage, perhaps an example
would help. The GSAKMP spec or the PT spec should indicate the minimum
number of PKI that an implementation must support. I infer that a value of
1, while valid, misses the point that any realistic deployment will need
the ability to handle multiple PKI.

> should state when the timer only need to reference the local clock.

Yes, the use of a local clock should be highlighted.

Now that I'm looking at it, I am also wondering if the local key lifetime
clock gets "restarted" at the arrival time of a rekey event message,
and whether one partition of the group may get "out of sync" with another
partition of the group if each successive rekey message to the first group
partition got delayed by an adversary. The cumulative clock skew, when
viewed across the whole group, may exceed the rollover time. In that
scenario, could a group partition get stranded from the rest of the group
because it is using an obsolete (i.e. expired) group key? just wondering
out loud....

BTW, is the purpose of the PT "time issued" field defined in section
2.1.1.2 used to specify an expiration interval? if not, should not such a
mechanism get added?

would this be best expressed as an authenticated timestamp issued by a
timestamp notary?

> passed through GSAKMP to the IPSec application.

So you will be modifying the text in section 2.4.1.3.1 to indicate that
multiple multicast speakers can be declared and how to do that? i.e.
separate SPI per speaker.

Q: Is there a separate group key per speaker? the text should say that

Q: how does the "SA lifetime" expressed in traffic volume units interact
with the "key lifetime" found in section 2.4.1.1?

> This can be an added field to help specify the rekey mechanisms in the

Yes.

> In some cases the topic is best included to clarify existing text.

No doubt, the next rev of GSAKMP will have oodles of changes, perhaps an
appendix annotating the changes would be a good idea?

George