Subject: [AAA-WG]: RE: A question about security consideration in RFC3539

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 28 Jun 2004 01:04:00 -0400

Bernard,
Thanks!. 
 
I think this is a good idea especially when the client does not know the
other end support for IPSec.
Reading RFC3588 Base Diameter, It made it a must on Diameter servers and
clients to support IPSec. 
I assume they have to support IKE to establish IPSec.
 
The other thing which attracted my attention is that RFC2409 mandates ONLY
pre-shared secret key authentication for phase 1 negotiation. Also, RFC3588
mandates the use of pre-shared secret-key and optional digital signature.
In that case; should not the client knows ahead of time the server
capabilities with respect to IKE?
 
Regards, 
Ahmad 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, June 25, 2004 9:53 PM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; [email-masked];
[email-masked]
Subject: RE: A question about security consideration in RFC3539

The issue is that if the responder doesn't support IKE the result is a
timeout, since most initiators drop incoming ICMP port unreachable messages.
So the question is how to determine if the responder doesn't support IKE in
a more timely way. 

For some protocols (e.g. TCP or SCTP) the "send cleartext, respond back with
IKE) approach is tempting, because no data is sent in the initial packet (a
SYN) so that there is not much security exposure, assuming that the
initiator can determine whether IPsec has been negotiated before sending any
data.

However, with Diameter the only alternative if IKE negotiation fails is to
try to bring up a non-IPsec protected TCP connection and then switch the
connection over to TLS.  There is no application-specific security available
to serve as a safety net.

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Fri 6/25/2004 6:22 PM
To: Bernard Aboba; [email-masked]'
Subject: A question about security consideration in RFC3539

Hello Bernard/Jonathan

I would appreciate it much if you comment on the following paragraph under
section 4.
In particular the following sentence:

"
   ........................................................In order to
   enable a AAA client to determine what security mechanisms are in use
   on an agent or server without prior knowledge, it may be tempting to
   initiate a connection in the clear, and then to have the AAA agent
   respond with IKE [RFC2409].
"

Excerpt
Under section 4.0 it reads:

   Where IPsec [RFC2401] is used to provide security, it is important
   that IPsec policy require IPsec on incoming packets.  In order to
   enable a AAA client to determine what security mechanisms are in use
   on an agent or server without prior knowledge, it may be tempting to
   initiate a connection in the clear, and then to have the AAA agent
   respond with IKE [RFC2409].  While this approach minimizes required
   client configuration, it increases the vulnerability to denial of
   service attack, since a connection request can now not only tie up
   transport resources, but also resources within the IKE
   implementation.

Thanks!

Regards,
Ahmad

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Jun 2004 22:41:30 -0700 (PDT)

> capabilities with respect to IKE?

For IKE to work, it is always necessary to pre-provision some credentials.
Assuming that the Diameter client and server are provisioned with
compatible credentials, they can use the IKE negotiation to negotiate the
use of them.

I'd note that an implementation of IKE with only pre-shared keys is
considerably smaller than one supporting certificate exchanges (only 200
KB or so, see RFC 3723 for details).  So if resource availability is an
issue, then this is an economical way to secure Diameter
(and RADIUS too, see RFC 3579).