Subject: [AAA-WG]: Issue 235 - seperation of CMS from base

From: <[email-masked]>
Date: Tue, 7 May 2002 03:02:46 +0300

Hi all,

There have been some discussions on how to remove the CMS dependencies from
the Base draft.  Some suggestions included having a session-id, event-timestamp
and/or nonce to protect against various things, including replay attacks.

Rough definitions are:

Session ID

Session-ID is globally and temporally unique, as well as monotically increasing, 
it can serve as a liveness check.

Event-Timestamp
 
The Event-Timestamp is of type Time, and MAY be included to record the time that 
this event occurred, in seconds since January 1, 1970 00:00 UTC.

Nonce

The Nonce is of type OctetString. It is RECOMMENDED 
that it contains a psuedo-random value of at least 128 bits, meeting 
criteria detailed in "Randomness Recommendations for Security" RFC 1750.

====

I think that a Nonce is not needed, if the session-id & event-timestamp
are used (and have been defined rigourously).  Additional text needed 
would be:

 Diameter messages are subject to various deliberate and accidental
 threats, in particular messages may be replayed and if a replayed
 message is processed a number of times that might cause harm. In 
 order to assist Diameter nodes in detecting replay the Session-ID and
 Event-Timestamp AVPs are defined in section X.X.X.X and these AVPs
 SHOULD be included in all messages where replay can cause harm.
 Note however, that without additional protection, these AVPs are 
 subject to (accidental or deliberate) modification by any Diameter 
 node. For this reason replay detection is only really effective where 
 an end-to-end security mechanism (like [CMS]) is used to provide 
 data integrity over those AVPs."

I think I need to check on which messages these need to be included
on, most likely at least some of the accounting messages.  

Can anyone comment on what additionally is needed to finish this
issue?

John

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 May 2002 17:51:11 -0700 (PDT)

> Can anyone comment on what additionally is needed to finish this

The text seems to imply that there is a vulnerability to replay on a
hop-by-hop basis if these AVPs are not included. Since both IPsec and TLS
provide replay protection, that really isn't the issue. The issue is
replay of CMS objects -- cutting and pasting a CMS object from one
Diameter message to another. 

I think this implies that the individual CMS objects need to include
replay protection.