Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port

From: <[email-masked]>
Date: Tue, 16 Apr 2002 11:01:40 +0300

> Section 5.6
> 
> Can someone help me here?  Do we really want to complicate the state machine by 
> adding all the "If both ends support it, we do TLS now" states, or should we
> just add a section 5.6.5 describing that a TLS handshake will begin when
>  both ends are in the open state, and all further messages will be sent via TLS?

Is something like this sufficient:

 For TLS usage, a TLS handshake will begin when both ends are in the open state.
 If the TLS handshake is successful, all further messages will be sent via TLS.
 If the handshake fails, both ends move to the closed state.

John

---

From: David Frascone <[email-masked]>
Date: Tue, 16 Apr 2002 07:32:42 -0500

I've been thinking about this a bit more.  The TLS handshake will fail if
the nodes have no prior knowledge of each other, or use a common CA, since
site certificates must be validated.

So, in that case, if a diameter peer is found by peer discovery, and both 
peers happen to do TLS, then by this paragraph they can never communicate,
right?

So, back to that old TLS certificates must be validated thingie:  Can we state
that TLS certificates MUST be validated, but MAY be self signed (you can also
put in that self signed certificates are completely useless when it comes
to determining identity, and are susceptable to man in the middle attacks)?

-Dave

-- 
David Frascone

  Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER

---

From: David Frascone <[email-masked]>
Date: Tue, 16 Apr 2002 07:33:10 -0500

Works for me.

-- 
David Frascone

     After a number of decimal places, nobody gives a damn.

---

From: David Frascone <[email-masked]>
Date: Tue, 16 Apr 2002 08:32:47 -0500

Ok, I'm not sure that the below paragraphs are actually english, so I'm
restating them, and changing the subject.

First, let's take an example w/o TLS.  A diameter server at aaa.somewhere.net
tries to find a Diameter server for the realm frascone.com, and ends up with
aaa.frascone.com, after checking for DNS SRV records.  Since neither peer
supports TLS (or only one supports TLS) they connect and communicate 
happily.

But, let's suppose that they *both* have support for TLS.  Since they have
no prior knowledge of each other, and since there are no CA's defined *today*,
they can not interoperate, since they can't validate the certificates.  I
think this is not acceptable.  Security is now keeping us from interoperating.

I think that if peers have no prior knowledge of each other, and both happen
to support TLS, then a self signed certificate should be acceptable.  I admit
that there is no guarantee of identity here, but there wasn't any guarantee
before, without the TLS.  Or, as in my previous e-mails, they should be
allowed to fall back to an insecure connection.  (Remember, this is not for
all secure connections, just for ones where the servers have no prior knowledge
or shared CA with each other)

Just my $.02 worth,

Dave

-- 
David Frascone

   Catatonic (n.) - Italian beverage most preferred by cats.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Apr 2002 14:54:01 +0100

Dave,

I don't like this approach. Presumably someone added/turned-on the
TLS support for some reason, accepting self-signed things like this
simply allows a DNS poisoning and spoofing attack to work straight
away.

Where's the use case for peer discovery and *in*-security? If there
really is one, then I'd suggest allowing anonymous ciphersuites in
that case rather than pretend certificates. If there is no such
use case (as I believe) then we just have to accept that having
reasonable security requires some co-ordination (in this case 
the TLS peers being able to validate one another's certificates).

Finally, and somewhat tangentally (since its no basis on which to
argue here), its entirely spurious to say there aren't CAs today - there 
are *plenty* of places to get real TLS certificates (with some policy
backing them) today and there's also sufficient free technology 
available that'd allow anyone to establish their own free CA if 
they wanted. The fact is that this is one of the few times that I
get to say that what's not deployed is Diameter, rather than 
TLS-capable PKI:-)

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: Tue, 16 Apr 2002 06:17:50 -0700 (PDT)

> supports TLS (or only one supports TLS) they connect and communicate 

Presumably there is reason for somewhere.net to believe that as a result
of letting [email-masked] on the network, they will be paid for the
usage. That indicates that business relationships exist along the "roaming
relationship path". 

> think this is not acceptable.  Security is now keeping us from interoperating.

So you're saying that the "business relationships" exist, but not the
certificates corresponding to them. For example, frascone.com's
certificate has not been signed by bigroamingconsortia.com with whom
somewhere.net has a business relationship. And perhaps
bigroamingconsortia.com's certificate has not been signed by one of
somewhere.net's trusted roots. 

> to support TLS, then a self signed certificate should be acceptable.  

I could see pre-configuring a Diameter agent with a set of "trusted
peers" which might have self-signed certificates. As long as the
certificates are cached, the risk will only exist on the first
contact. For example, somewhere.net might create a business relationship
with bigroamingconsortia.com and then cache its self-signed cert.

Similarly, bigroamingconsortia.com might cache the self-signed cert of
frascone.com after creating a business relationship with that
organization.

---

From: David Frascone <[email-masked]>
Date: Tue, 16 Apr 2002 09:21:21 -0500

A couple more rants inline :)

> peers" which might have self-signed certificates. As long as the

That whole pre-configuring thing goes completely against the "no prior
knowledge" that I was talking about.  

Remember, this is functionality that existed *before* TLS handshaking.  This
is not something new that I'm trying to be a zealot about.  

If everyone thinks that it's ok to loose this functionality, fine.  But,
I really don't see why we spent so much time defining DNS SRV records and 
other forms of peer disovery, if they are useless without CAs or prior
knowledge of the host.  (And, with prior knowledge, peer discovery is not
needed)

-- 
David Frascone

           Artist seeks Boss with vision impairment.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Apr 2002 15:23:39 +0100

Dave,

The prior knowledge is not of the host, but of the CA concerned, which
can be a 1,000,000:1 difference!

Stephen.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Apr 2002 07:33:46 -0700 (PDT)

> knowledge of the host.  (And, with prior knowledge, peer discovery is not

DNS SRV, NAPSTR, etc. can solve the problem where there is a prior
relationship with a Diameter server within the realm, but help is needed
to find the server. 

This kind of situation isn't very compatible with IPsec w/pre-shared keys,
since if the name of the peer isn't known beforehand, the pre-shared key
can't be known either.