Subject: [AAA-WG]: Issue 335: CMS Security does not protect against replay

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Apr 2002 07:37:42 -0700 (PDT)

Issue 335: CMS Security does not protect against session-key replay
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: April 16, 2002
Reference: http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt
Document: MIP, NASREQ, CMS
Comment type: T
Priority: S
Section: 
Rationale/Explanation of issue:

CMS wrapping of session keys does not explicitly protect the 
key distribution from replay. 
Thus, although the NAS itself can assume a CMS-wrapped key is genuine 
and issued from the AAA server, the NAS cannot determine that the AVP 
it receives has not been issued already for some prior session. 
Instead, the NAS must assume that the AAA server is playing by the 
rules and issuing only fresh keys, and that there is no man-in-the-
middle replacing AVPs before or after they are unwrapped by a lower-
layer security mechanism. Many session establishment handshakes do 
not define adequate key confirmation handshakes, so the NAS could end 
up sending new data encrypted under already-used keys and IVs before 
the problem can be detected, potentially compromising previously sent 
data. Relying on TLS or IPsec does not solve 
the problem, because the replay protection afforded by such low-level 
mechanisms is not adequately bound to the AVP to prevent a Trojan 
horse from substituting an old AVP for the new one without detection.

Proposed change:

What is needed to defeat this kind of attack is to require the 
AAA server to incorporate a challenge from the NAS (and/or the NAS 
client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a 
timestamp into the AVP is another option, but maintaining 
synchronized time in many of the environments served by an AAA server 
introduces its own problems.)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Apr 2002 16:38:43 +0100

As far as I can see, that proposed change doesn't impact on the CMS 
document. Is there a suggestion that replay protection should be
done by CMS wrapping? I'd hope not, in which case this issue doesn't
affect CMS (the document, it does affect how CMS is used).

Is it true that replay protection is required for various AVPs? If so, 
a case could be made for a generic approach to replay protection and 
not just for session key AVPs.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Apr 2002 09:13:31 -0700 (PDT)

> affect CMS (the document, it does affect how CMS is used).

I think you are correct. This is not a CMS issue per se. I will remove the
issue from the CMS list. However, it does seem to be an issue for Base,
MIP and NASREQ and so I have added it to those lists.

> not just for session key AVPs.

I think a case can be made that replay protection is required for Diameter
PDUs. I also think that a proxy should not be able to replace a
CMS-protected object with another object that it got from a previous PDU,
without being detected. So protection against "cut and paste" attacks
seems like an important issue.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Apr 2002 18:10:28 +0100

Bernard,

> PDUs. 

Fair enough. So maybe some sort of "freshness" AVP perhaps with a time and
nonce and rules (TBD) for replay detection that don't require, but do work
nicely with, synchronized clocks.

Some questions: 

Replay detection (I think) always requires a replay cache of some sort or 
else state-maintenance. For the former case, are there nodes that can't 
afford any such storage? For the latter, I assume we do need to allow
some stateless interactions?

Are there nodes that'd have a hard time generating random nonces? What
about nodes with no real time clock, or with a high probability of a 
wildly inaccurate clock?

> I also think that a proxy should not be able to replace a

Is that really a requirement? Perhaps not all cut&paste operations are 
actually attacks! My preference would be that we define freshness as a
Diameter concept and then say for each message whether the freshness 
stuff has the "P" bit set or not (or some such). Maybe even say that 
if CMS is used, then the freshness AVP MUST be signed/encrpyted, but 
I don't want us to require CMS just to get fresh.

Stephen.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Apr 2002 09:35:51 -0700 (PDT)

> nicely with, synchronized clocks.

Ironically, RADIUS already has some of these mechanisms, such as the
Event-Timestamp AVP, and the Request-Authenticator. There has already been
an issue raised as to whether this level of "liveness" is supported within
Diameter. 

> some stateless interactions?

Logically, the NAS is the entity with the least resources, so it would be
the entity that might not be able to implement a replay
cache. However, I think what is being proposed here is a NAS-generated
challenge (perhaps in the Request) that would be incorporated in the CMS
encapsulation, so I'm not clear that a cache would be required. 

> about nodes with no real time clock, or with a high probability of a 

I have been told that there are NASes that boot with very little
randomness (as little as 4 bits). However, I suspect that Diameter agents
can be assumed to support cryptographic quality random number generation. 

> actually attacks! 

So you're saying that a Proxy might replace a CMS-object with another one,
and have that be a valid operation? Can you give an example of a situation
in which this might be acceptable? My brain just blew a fuse :)

> My preference would be that we define freshness as a

I think that makes sense.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Apr 2002 18:25:45 +0100

> in which this might be acceptable? My brain just blew a fuse :)

No idea if its a real requirement but at least in principle:

Alice->Proxy: fresh1+stuff+CMS-Enc(Bob,AVPs)
Proxy->Bob-host1: fresh2+stuff+more-stuff+CMS-Enc(Bob,AVPs)
Proxy->Bob-host2: fresh3+stuff+even-more-stuff+CMS-Enc(Bob,AVPs)

Could happen for some accounting reason maybe?

Ignore me if its nonsense.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Apr 2002 18:29:01 +0100

> encapsulation, so I'm not clear that a cache would be required.

Ok, so we can use state-maintenance schemes sometimes. Are there times
when we can't?

> can be assumed to support cryptographic quality random number generation.

Ok, so we make that a MUST then I guess. What about the clocks - are there 
nodes with no clock or do they all have one? (I like the idea of being able
to use the time when its available!)

Stephen.