Subject: [AAA-WG]: Supporting TLS?

From: David Frascone <[email-masked]>
Date: Tue, 29 Jan 2002 10:12:15 -0600

I'm putting together the test specification for Connectathon 2002, and I've
got a couple of questions about implementing TLS (I apologize in advance
for the ignorance of these questions):

   o	It looks like OpenSSL and similar crypographic libraries that 
	implement TLS always implement SSL on top of it.  Am I correct
	in assuming that SSLv3 == TLSv1?  So, setting up a SSL connection
	via OpenSSL or cryptlib would be an acceptable test/implementation
	of Diameter over TLS?

   o	If the above is *not* true, is there an EASY way to implement
	TLS for testing, without implementing the entire TLS RFC.  I don't
	think any vendor will be able to do that before the Connectathon.

   o	No centralized certificate signing authority has been defined for
	Diameter.  I'm assuming that if you have prior knowledge of a peer
	you're connecting to, you would have it's self signed certificate
	for identification.  And, if you have no prior knowledge of the
	peer, then you would be susceptable to man-in-the-middle attacks,
	since you would have no way to authenticate the peer.
	Are these assumptions correct?

Thanks in advance,

Dave

P.S.  At least ipsec is easy :)

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jan 2002 08:08:58 -0800 (PST)

> 	via OpenSSL or cryptlib would be an acceptable test/implementation

No, there are some changes between SSLv3 and TLS. I'd suggest testing both
SSLv3 and TLS. 

> 	think any vendor will be able to do that before the Connectathon.

As with any RFC, there are MUSTs, SHOULDs and MAYs. So there are levels of
compliance. 

> 	Are these assumptions correct?

A Diameter peer can have a set of root CAs that it trusts. This is one of
the areas where the spec is currently not very informative. Self-signed
certs can be made secure on all but the first exchange -- so you have to
assume that there is no man-in-the-middle operating during that first
exchange, so the self-signed cert can be retrieved (and presumably,
cached). A self-signed cert tells you "you've conected to the same entity
that you spoke with the first time you obtained this cert". It doesn't
tell you who that entity is -- typically this requires faith in DNS, IP
addresses or other spoofable mechanisms. 

So using self-signed certs might be a decent way to test things at
Connectathon, but we should discuss the circumstances under which this
would provide acceptable security. 

>At least IPsec is easy 

You'll have the same issues come up if you support certificates with
IPsec. I gather you were using pre-shared keys :)

---

From: Don Zick <[email-masked]>
Date: Tue, 29 Jan 2002 11:31:05 -0500

Dave,

TLS is an IETF standard protocol based on SSLv3.  It is not exactly the same
as SSLv3.

Toolkits such as OpenSSL can be used to set up either SSL or TLS connections.

Certificates used by TLS should be signed by a certificate authority (CA).
You can use a utility such as openssl to create CA certificates for an
enterprise or you can obtain CA certificates from an existing Certificate
Authority.

Don

---

From: David Frascone <[email-masked]>
Date: Tue, 29 Jan 2002 10:39:43 -0600

> No, there are some changes between SSLv3 and TLS. I'd suggest testing both

Ok.  I'll read sparse OpenSSL documents more closely.

> IPsec. I gather you were using pre-shared keys :)

True, the architectural problems are still there, but at least the 
diameter implementation itself does not need to be modified.  Which means,
vendors attending Connectathon might be able to implement it in time.

-Dave