Subject: [AAA-WG]: Issue 191: How to know when to use TLS

From: Pat Calhoun <[email-masked]>
Date: Mon, 1 Oct 2001 04:30:23 -0700

The proposed resolution is to look at the URI to determine whether TLS
should be used to connect to the peer. 

One way to look at this is that section 2.2 states that all servers must
support TLS, so it would probably be safe to connect to the TLS port if
IPSec is not locally used. However, if a server was to connect to a client,
TLS is not guaranteed.

So, we have the following options:
1. rely on the URI
2. state that the TLS port is used if IPSec is not used

my preference is #2.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 1 Oct 2001 15:12:55 +0200

>2. state that the TLS port is used if IPSec is not used

TLS port?!? I guess you mean to use TLS on diameter default port TBD
(or other configured port).
How can the diameter application determine if IPsec is used?

/Fredrik

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 1 Oct 2001 07:15:36 -0700

> (or other configured port).

draft-ietf-aaa-diameter-08.txt, section 2.1:

"  The base Diameter protocol is run on port TBD of both TCP [27] and
   SCTP [26] transport protocols (for interoperability test purposes
   port 1812 will be used until IANA assigns a port to the protocol).
   When used with TLS [38], The Diameter protocol is run on port TBD of
   both TCP and SCTP."

There are two ports allocated for the protocol, one where TLS is used and the
other one.

> How can the diameter application determine if IPsec is used?

That's unfortunately an implementation detail. If the OS you are on doesn't allow
you to view the local security policies, then you can always attempt TLS.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 1 Oct 2001 07:57:09 -0700

> Has this been decided?  I believe IETF/IANA does not want to issue
> parallel "secure" port numbers, see e.g. RFC 2817 (I can't find a
> better reference, sorry):
> 
>    At the Washington DC IETF meeting in December 1997, the Applications
>    Area Directors and the IESG reaffirmed that the practice of issuing
>    parallel "secure" port numbers should be deprecated.
> 
hmmm... this creates some serious challenges at the app layer.

> The other alternative, using the URI to find out security status, has
> the same problem -- it requires one URI format for the raw protocol
> and one URI format for the TLS-wrapped protocol.
> 
> I believe the right thing to do is to support negotiation of these
> parameters within the protocol -- something like SASL's "EXTERNAL" may
> be used if implementation uses IPSEC or TLS to protect the
> communication.

so perhaps two ways:
1. static configuration - we don't care about this case
2. add info in URI

This would allow for a single port to be used.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 1 Oct 2001 08:21:55 -0700

On Mon, Oct 01, 2001 at 05:32:30PM +0200, Simon Josefsson wrote:
> Pat Calhoun <[email-masked]> writes:
> 
> I think that was the point -- application protocols should be designed
> with security in mind.
> 
> Of course, the decision is intended to help rather than to annoy you,
> if the application protocol is not designed for this, that design will
> cause problems for you later when something other than TLS or IPSEC
> comes around.  Most "old" protocols, SMTP, HTTP etc has showed this to
> be enough of a problem to motivate the above practice, I believe.

not annoyed

The challenge here is how does one know whether to invoke the TLS library
to connect to a peer or not. The above assumes that TLS is native in the app,
so it can detect whether a peer wishes to do TLS negotiation.

> Does this mean that it is too late to add the proper security
> negotiation mechanisms in the Diameter protocol?  (Similar to the
> security negotiation phases that has been added to SMTP, HTTP and
> other protocols not designed for security from the beginning.)
> 
> I'm sorry, I do not know enough about Diameter to tell.

Well, protocol fixes are allowed, new features aren't. I guess the challenge here
is to determine which category this falls under.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Oct 2001 08:54:49 -0700

Or we could just use CMS for both hop-by-hop and e2e security...

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 2 Oct 2001 09:17:07 +0200

>There are two ports allocated for the protocol, one where TLS is

That's ok as long as you run over the default port, so I guess it has to be
configurable on each node. Then I suggest adding a new result code saying

DIAMETER_TLS_REQUIRED
A connection request was received without using TLS, but the receiving peer
is configured to run TLS.

/Fredrik

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Oct 2001 08:00:30 -0700

great suggestion, but in light of the use one port for both statement from
someone on the list, this may possibly not work. I need to check with IESG on
the current trends.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Oct 2001 08:18:46 -0700

> Or we could just use CMS for both hop-by-hop and e2e security...

Interesting idea. That did come up some time ago when the kerb folks were
proposing their solution. Essentially, they were stating that there was no
reason no require two different security schemes, and one would be sufficient.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 2 Oct 2001 17:39:03 +0200

I saw the mail about one port to late :-)
guess we'll have to wait to see what IESG has to say about it.

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Pat Calhoun
>Sent: den 2 oktober 2001 17:01
>To: Fredrik Johansson
>Cc: Pat Calhoun; [email-masked]
>Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS
>
>

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 2 Oct 2001 18:50:25 +0300

I'm not sure I like the CMS-only approach. Seems like the only security
scheme we'd be left with would be mandatorily based on public keys
(e.g. ipsec from a NAS could be configured with manual keys and
without IKE). Current devices are also likely to support Ipsec/Tls.

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 2 Oct 2001 09:36:07 -0700

> without IKE). Current devices are also likely to support Ipsec/Tls.

Is there some inherent technical reason that CMS cannot work w/symmetric
keys?