Subject: [AAA-WG]: [issue] Usage of TLS and IPsec

From: <[email-masked]>
Date: Tue, 19 Feb 2002 06:12:10 +0200

Hi all,

We've recieved some comments from the IESG, so I am filling the comments 
as issues.

Description of issue: Usage of TLS and IPsec needs more detail
Submitter name: John Loughney	
Submitter email address: [email-masked]	
Date first submitted: 18 Feb 2002
Reference: 
Document: Base 
Comment type: T 
Priority: 1
Section: 2.2
Rationale/Explanation of issue: 

 	Usage of TLS and IPsec. Aside from more detail on how to use TLS and
 	IPsec, it was noted that the drafts do not say that IPsec is for
 	Intra-domain use and TLS for inter-domain. In practice, IKE isn't very
 	interoperable when used with certs, and can't support the required cert
 	policies very well. TLS has this nailed. Should we say
 	that IPsec is primarily for use with pre-shared keys and only
 	intra-domain, and TLS is for cert usage and inter-domain? Should we
 	adjust the language (TLS as MUST on client, too?) Issue to be filed and
 	raised on the mailing list.

Requested change: 
Proposal 

Add the following text:

  Diameter clients, such as Network Access Servers (NASes) and Mobility
  Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. 
  Diameter servers MUST support TLS and IPSec. Operating the Diameter 
  protocol without any security mechanism is not recommended.
  It is suggested that IPsec is primarily for use with pre-shared keys 
  and to protect intra-domain traffic.  TLS is for certificate usage and 
  to project inter-domain traffic.

John

---

From: David Frascone <[email-masked]>
Date: Tue, 19 Feb 2002 00:06:25 -0600

I know that this is obviously what the IESG wants, but I don't think
it's a very good idea.

The beauty of RADIUS was that it was light weight.  Forcing all Diameter
clients to support IPSEC just isn't going to happen.  Low end devices
probably won't even have the CPU to implement it.

I think adding this paragraph is going to keep all embedded systems from
implementing Diameter.  They'll just stick with RADIUS, and force all 
Diameter servers to implement the RADIUS gateways.

IMHO, this is a VERY VERY bad "recommendation"

-Dave

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Feb 2002 22:05:20 -0800 (PST)

> probably won't even have the CPU to implement it.

What is your proposal for Diameter security,
then? TLS? CMS-Sec? Nothing?

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 19 Feb 2002 08:54:27 +0200

1) I'm not sure I agree with IESG on their understanding of cert
    policies etc. I know products that implement the cert processing
    of IKE and TLS using same code, for instance. Also, are they
    sure they have not confused the ease of server-side cert usage
    in TLS with the ease of certs in TLS in general? I've heard the
    same IESG story elsewhere on inter and intra but I find it hard
    to see why I can't install Verisign as my IPsec root, or Ericsson CA
    as my web TLS root.

2) Regardless of the above... what John is proposing not not
    unreasonable. The two things that do worry me are the
    only-recommendation on no security, and the MAY upgrade
    to SHOULD... but on the other hand it still isn't a MUST so
    the implementors still have a way out. Let me propose
   alternative text:

  Diameter clients, such as Network Access Servers (NASes) and Mobility
  Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. 
  Diameter servers MUST support TLS and IPSec. The Diameter 
  protocol MUST NOT be operated without any security mechanism.

Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 19 Feb 2002 09:28:01 +0200

One more thing. Thinking about this some more, while I
do not necessarily agree with the IESG suggestion on
intra and inter, this happens to coincide with what I think
has been the intent (if not the letter) of the current spec.
That is, you run IPsec, perhaps shared-secret keyed
(if not even manually but here I think Bernard and I had
a disagreement) on the edges, and then servers mainly
communicate with each other using TLS. So could
state something like this at the end of my suggested
note below:

  It is suggested that IPsec can be used primarily at the
  edges and in intra-domain traffic, such as using pre-shared
  keys between a NAS a local AAA proxy. This also eases
  the requirements on the NAS to support certificates. It is
  also suggested that inter-domain traffic would primarily use
  TLS.

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Feb 2002 22:57:04 -0800 (PST)

>     to see why I can't install Verisign as my IPsec root, or Ericsson CA

Since TLS runs over TCP, cert chains (or even long certs) are not an
issue. With IPsec, the result is IKE fragmentation, and since
NATs/filtering routers typically drop fragments, connectivity can often
not be established. We are seeing this problem arise more and more in real
situations. That's the main "inter-domain" issue that I see with IPsec. 

"Diameter Agents MUST support IP Security [SEC ARCH], and SHOULD
support TLS [TLS]. Diameter servers MUST support TLS and IPSec. The Diameter 
protocol MUST NOT be operated without any security mechanism."

This seems fine to me -- but out of curiousity, what are implementations
actually using?

---

From: David Frascone <[email-masked]>
Date: Tue, 19 Feb 2002 07:52:24 -0600

SHOULDS, across the board.  Security is something that's great to have, but
I think having MUSTs will kill the protocol for small devices.

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 19 Feb 2002 17:06:26 +0200

> > then? TLS? CMS-Sec? Nothing? 

We need to have security. Even RADIUS had mandatory security.
This time we are moving the mandatory security out of the protocol
itself to another layer (ip or transport), because in many cases support
on those layers already exists, and is far better than what e.g. RADIUS
had. I don't think leaving security to a SHOULD across the board
is acceptable.

Jari