Subject: [Dime] integrity protection of CER exchanges

From: Stefan Winter <[email-masked]>
Date: Tue, 04 Nov 2008 09:08:21 +0100

Hello,

while going through 3588, I tried to find out how to use TLS instead of
IPSec to secure communication between two Diameter peers. From what I
can see, the possibility of using TLS is negotiated in a CER/CEA message
exchange pair.
So, CER and CEA have to be exchanged before the TLS session is established.
As far as I can see, the Diameter messages themselves are not
integrity-protected during this exchange.
As a consequence, the capabilities exchange between two peers is
happening unauthenticated if TLS is to be used. An attacker might then
use the opportunity to alter packet contents to its liking. Including,
but not limited to tweaking election results or disabling TLS
negotiation altogether.

Then again, the protocol states that Diameter messages MUST NOT be sent
unencrypted. The only consequence I can think of is that in order to use
TLS, you have to use IPSec first to encrypt this one message exchange.

I'm assuming I got something deeply wrong here, since the above
conclusion would be so very impratical. Could someone enlighten me?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 4 Nov 2008 09:30:10 +0100 (CET)

>but not limited to tweaking election results or disabling TLS

If the attacker disables TLS negotiation, then the client will see
that the TLS handshake it requested did not complete and will enter
the Closed state, as per section 5.6 page 70.

>conclusion would be so very impratical. Could someone enlighten me?

Looks the same to me. SMTP for example requires that after STARTTLS,
the entire introduction (e.g. EHLO and perhaps some other things) is
to be re-issued. Maybe Diameter should do the same -- sending another
CER (after TLS is successful). The protocol certainly allows it;
merely matching the two CERs together would be an
implementation-specific behavior at this point.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Stefan Winter <[email-masked]>
Date: Tue, 04 Nov 2008 09:43:31 +0100

Hi,

thanks for the fast reply!

> the Closed state, as per section 5.6 page 70.

That's a bit tricky: I don't think a peer can *request* TLS.
Inband-Security-Id AVP reads "is used in order to advertise support".
All Diameter peers have by definition support for IPSec. If the attacker
modifies the packet from both sides by removing the Inband-Security-Id,
it will default to no inband security. I could imagine an ill-advised
implementation to then try to use IPsec instead - which has a whiff of
down-bidding from the attacker's point of view. If the Diameter peer has
no means of verifying that an IPSec session is established (it's a layer
below anyway) and simply *assumes* it is IPSec protected, it might end
up sending messages in the clear.

Note that 5.6 sends a peer to Closed if the TLS handshake fails. In the
scenario above, the TLS handshake will never be initiated in the first
place. So I don't think 5.6 does a lot of good here.

> implementation-specific behavior at this point.

That sounds reasonable, and should go into 3588bis IMHO.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 12 Nov 2008 07:59:57 +0100

Hi,

the thread so far has three findings:

- to be conformant with the spec, you need to use IPSec to protect the
inband security handshake, even if IPsec is not to be used for the
remainder of the peer session
- failure to do so may enable an attacker to change the encryption used
during the entire peer session. It may also enable an attacker to tweak
other parameters in the CER.
- this might (still unsure about that) be mitigated by repeating the CER
immediately after establishing a secure link.

These look like some severe implications of the protocol. I suggest to
give that a mention in 3588bis's security considerations section. If
that is seen as a good thing to do, I volunteer for the text.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: "Thomas Lindgren" <[email-masked]>
Date: Wed, 12 Nov 2008 10:49:32 +0100

> that is seen as a good thing to do, I volunteer for the text.

It seems to me that an option of just running Diameter over TLS would be
simpler as well as more secure than the 3588 negotiation method. Are there
any compelling advantages to using the current negotiation approach?

Best,
Thomas
-- 
Thomas Lindgren, Millpond Services Ltd
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Stefan Winter <[email-masked]>
Date: Wed, 12 Nov 2008 13:15:14 +0100

Hi,

> It seems to me that an option of just running Diameter over TLS would
> be simpler as well as more secure than the 3588 negotiation method.
> Are there any compelling advantages to using the current negotiation
> approach?

Well, the current approach in 3588 and bis is the only one specified.
And being specified in the the IETF is kind of a compelling advantage
:-)  I'm perfectly with you though that it would likely be simpler to
allocate a different port for Diameter over TLS and just skip the CER
inband security negotiation, and replace it by commencing with a TLS
handshake prior to the Diameter CER PDU being exchanged. That's a
substantial change in protocol operations though, much more than a
"handle with care" advice on the current model. I wonder how much
current deployments would be affected by this. Is deploying Diamter over
TLS a common deployment method? [BTW, for RADIUS over TLS a different
TCP port was chosen, and that seems to work nicely.]

So, would you prefer to deprecate CER inband security negotiation in
favour of a more straightforward port-based approach in 3588bis?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Jan Engelhardt <[email-masked]>
Date: Wed, 12 Nov 2008 14:03:45 +0100 (CET)

On Wednesday 2008-11-12 13:15, Stefan Winter wrote:
>inband security negotiation [...]

But it would impose an unnecessary performance hit for networks
that have established an IPsec-based solution.

>favour of a more straightforward port-based approach in 3588bis?

Like, unencrypted on port 3868, and implicit TLS on 3869?
Then again tell me why STARTTLS in SMTP and IMAP are (I claim)
more beautiful than implicit TLS for smtps and imaps.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Stefan Winter <[email-masked]>
Date: Wed, 12 Nov 2008 14:11:02 +0100

Hi,

> more beautiful than implicit TLS for smtps and imaps.

Oh, I didn't intend to step on your feet regarding STARTTLS, sorry. I
don't dare judge over the beautiness of STARTTLS vs. TCP port numbers
and didn't mean to imply anything in that direction. The main (of course
overcomable) problem i see is that the state machine in Diameter expects
a Diameter PDU after TCP session establishment. It would need to be
non-trivially modified to include a STARTTLS mechanism. I'm also unsure
whether implementations would become easier if they have to expect
*either* a Diameter PDU *or* a ASCII "STARTTLS" word. Text-based
protocols like SMTP have an easier time here because they do a plain
ASCII capabilities exchange in any case.

So, let me rephrase my original question: "would you prefer to deprecate
CER inband security negotiation in favour of a more commonly used and
well-understood  TLS handshake approach in 3588bis?"

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Jan Engelhardt <[email-masked]>
Date: Wed, 12 Nov 2008 14:23:02 +0100 (CET)

On Wednesday 2008-11-12 14:11, Stefan Winter wrote:
>*either* a Diameter PDU *or* a ASCII "STARTTLS" word.

Even the STARTTLS commands of SMTP and IMAP are in line with the
respective protocols, it's not just the bland 8-char ASCII string. As
previously mentioned, the mere presence of Security-Inband-Id=TLS
could be our starttls trigger.

Or maybe Diameter should move to ASCII (perhaps XML because of its
good nesting possibilities) too - that would also alleviate trying to
figure out an AVP's specific encoding (developer's ever-reoccuring
question "is that number now sent as a uint32 or as a human-readable
string?").

---

From: Stefan Winter <[email-masked]>
Date: Wed, 12 Nov 2008 14:30:46 +0100

Hi,

> could be our starttls trigger.

It might... it needs a semantics change for Inband-Security AVP though:
it would not be a statement of *support* for TLS, but an annoucement of
*starting* TLS.

> question "is that number now sent as a uint32 or as a human-readable
Huh. You are about to invent a new AAA protocol which has next to nothing in common with Diameter, you know?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Jan Engelhardt <[email-masked]>
Date: Wed, 12 Nov 2008 15:41:23 +0100 (CET)

>it would not be a statement of *support* for TLS, but an annoucement of

Yeah, another of these strange design decisions.
Why would you announce TLS support if you ain't gonna use it!

>common with Diameter, you know?

What, merely throwing the binary packed format overboard gets
me rid of all the Diameter nasties? Wow, I must be dTRT.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Stefan Winter <[email-masked]>
Date: Wed, 12 Nov 2008 16:04:27 +0100

Hi,

> Why would you announce TLS support if you ain't gonna use it!

Since I wasn't involved in the Diameter spec, this is no more than
speculation for me, but: CER and CEA are, as I see it, supposed to tell
the two peers about the supported options. The approach we sketched
above of "blindly" stating that the originating peer is going to do TLS
now means that no security capability negotiation can take place.
Consequently, it may be that a peer tries to speak TLS to another which
doesn't support it. There is no way to know for the originating peer
that TLS is not supported, prior to falling onto its nose with a failed
handshake.
The idea with CER and CEA was obviously meant to prevent such TLS
handshake failures by first negotiating whether or not TLS is okay,
prior to starting the actual handshake. Which is, in principle, a nice
idea. Except that it doesn't work quite as intended.

> me rid of all the Diameter nasties? Wow, I must be dTRT.

dTRT = doing the right thing?

Well, just changing the encoding is only a first step. You could go on
by thinking along the lines of: now that we have all Diameter content in
an XML file, we could transport it over HTTP. Oh, wait, we could use
URIs to indicate that TLS is desirable, by transmitting the XML file
over HTTP or HTTPS or HTTP with STARTTLS, respectively. Then you could
lift all AVP size restrictions, because XML can handle tags of arbitrary
lengths. You'd end up at almost-SAML, probably.

I am going to stop here, because this is getting off-topic. And I don't
really plan to generate yet another AAA protocol. Right now, I'll just
stick with RADIUS ;-)

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 12 Nov 2008 11:16:47 -0600

Stefan Winter

> give that a mention in 3588bis's security considerations section. 

Noting the problem is a good idea, but I think that a better one would be to
fix it :-).  IIRC, the "negotiation" of TLS usage w/i Diameter was a part of
a fad to avoid the usage of special ports for secured vs. non-secured ports
for e.g. HTTP.  As you have noted, it just doesn't work for Diameter, so I
suggest that we either a) define new "secured" ports for TLS-protected
Diameter traffic or better (since I think that we are deprecating the use of
IPsec), simply redefine the existing ports as secured & possibly remove the
security-related stuff from the CER/CEA exchange.

> If that is seen as a good thing to do, I volunteer for the text.
> 
> Greetings,
> 
> Stefan Winter
> 
> --
> Stefan WINTER
> Ingenieur de Recherche

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 12 Nov 2008 11:27:14 -0600

...

> could be our starttls trigger.

Doesn't this have the same problem (lack of data authentication/integrity
protection) as the existing method.

> question "is that number now sent as a uint32 or as a human-readable

Been there, discussed that (at interminable length), don't go there again.

---

From: Jan Engelhardt <[email-masked]>
Date: Wed, 12 Nov 2008 19:10:42 +0100 (CET)

>protection) as the existing method.

I am sure the smtp/imap Working Groups can convince us that the approach 
they took is good enough.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 12 Nov 2008 14:11:39 -0600

...

> they took is good enough.

Indeed it is, if it is implemented in a command by itself.

---

From: Jan Nordqvist <[email-masked]>
Date: Wed, 12 Nov 2008 13:07:30 -0800

A few things to note in regards to this discussion about security:

The typical start TLS mechanism, as used in several protocols,
assumes a client server relationship as opposed to a peer to peer one,
and applied in its most simplistic approach could lead to unnecessary
"cross-handshaking" between peers during race conditions. Perhaps not a
critical issue, but one that a preceding capabilities exchange would
alleviate by deciding who is the client and who is the server, thus
avoiding an unnecessary and relatively costly TLS key exchange in the
cases where session resumption is not possible.

The choice whether to use security or not can and should be a
site policy decision and not driven by dynamic parameters in the
protocol. From my point of view the Inband-Security-Id AVP is only
there to indicate a capability and if the capability doesn't meet local
security policy, communication cannot commence.

Sending the full CER/CEA in the clear certainly exposes some
information to a potential attacker and also makes its content
vulnerable to alteration by a man in the middle attack and could
potentially allow communication interruptions. In an appropriately
configured network with an established PKI infrastructure it *should
not* affect the trust relationship between peers in any way once TLS
has been established since mutual certificate authentication is assumed
which will establish the remote identity to each peer.

It appears to me that in environments where security is a concern, a
minimal CER/CEA exchange should take place to establish client server
roles and share peer identities that each peer can use as a basis for
determining whether or not to engage in a subsequent TLS handshake.
Once the TLS tunnel is negotiated and the appropriate trust
relationship is determined, another CER/CEA exchange can follow inside
of it to share more detailed capabilities. Unfortunately the state
transitions for [IR]-Rcv-CE[RA] in the peer state machine description
in the original RFC-3588 are lacking from 3588bis-13, perhaps these
were put in with this very purpose in mind?

Just my two cents.

Jan Nordqvist,

Alcatel-Lucent 8950/AAA product group.

Jan Engelhardt wrote:

---

From: Stefan Winter <[email-masked]>
Date: Thu, 13 Nov 2008 08:17:21 +0100

Hi,

> fix it :-).

Nah, you're overdoing it. :-)

>   IIRC, the "negotiation" of TLS usage w/i Diameter was a part of

I hate to bring up the term "backwards compatibility", but... redefining
the port to be secure from day x onwards would make 3588 (non-bis)
implementations somewhat confused. A new port sounds like a better idea
to me.

I suggest discussing possible ways out in the meeting. There's a 15 min
slot for 3588bis already (15 min seems not a lot though, so we have to
talk fast).

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473