Subject: Security proposals for Interim meeting, Feburary 7, 2001

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Jan 2001 09:53:51 -0800

So that we can be prepared for our interim meeting on
February 7, 2001, I'd like to ask for volunteers to
present security proposals. These proposals should be
complete in the sense that they describe everything 
that is required to solve the security issues that 
we face. 

The goal of the exercise will be to convince the
WG that one or more of the proposals are viable in
the real world.

Here's a first cut at what is needed for the various
proposals:

1. CMS. I'd like to see a proposal on how CMS can be
used for both e2e and hop-by-hop security. Also, given
this I'd like to understand whether password hiding is
still necessary, and if so, why. The proposal should
be clear about:
	a. Whether PKI is required or not, and exactly
         what infrastructure is needed (CRL servers, 
         offline/online CAs, etc.)
      b. Efficiency issues (key reuse)
      c. Code size and implementation availability
        (can this be implemented on a NAS?)

2. GSS_API. I'd like to see a proposal describing
the deployment scenarios in more detail. 
Issues to discuss further include:
	a. GSS_API methods that could be supported
         within the 1 round trip framework (is this
         only Kerberos V?)
      b. Proposed mandatory to implement method
      c. Code size and availability
      d. Deployment implications
           1. Kerberos KDC on the Internet? 
           2. IAKERB proxies? 
           3. DNS support for KDC location?
           4. Authorization issues

3. IPSEC. 
Issues to discuss further include:
	a. Can use of ESP with non-null transform 
         eliminate need for password hiding?
      b. Can IKE MM cert policy validate biz relationships or
         is this asking too much?
      c. Security implications of referral
		1. Firewall hole for IPSEC/IKE from any source to
               AAA server
            2. AAA server does packet filtering not firewall
            3. Implications for NAS vulnerabilities

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Jan 2001 10:00:48 -0800 (PST)

Bernard,

Should I assume from your e-mail that hop-by-hop is out in the base spec? I
think discounting hop security is a mistake. Should I bring a contribution
detailing this method?

PatC

---

From: Barney Wolff <[email-masked]>
Date: Thu, 11 Jan 2001 13:14:13 -0500

It may have been pointed out already, but referral imho does
not imply that the target is the ultimate server that must
itself contain the sensitive user database.  The target
will be whatever the home domain says is its public face -
which if the administrators have any sense, will be a proxy.

Even if you attempt to mandate true "end-ness" such that the
home server is not a proxy, how could anybody outside the
home domain detect a violation?  We would be foolish to
attempt to legislate against things that cannot be detected
or forcibly suppressed.

A proxy makes a much better AAA firewall than any general-purpose
firewall could ever hope to be.

Re IKE-from-anywhere, how does a roaming VPN setup work, if not that?
I too wish that IKE were less DoSable, though.

Barney

On Thu, Jan 11, 2001 at 09:53:51AM -0800, Bernard Aboba wrote:
 ...

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Jan 2001 14:53:02 -0800

I wouldn't assume that anything is out. We're just asking
people to justify whatever they want to put in :)

Contributions welcome. 

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:01 AM
To: Bernard Aboba
Cc: Aaa-Wg@Merit. Edu
Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001

Bernard,

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Jan 2001 14:57:29 -0800

>I too wish that IKE were less DoSable, though.

Indeed, a VPN taking connections from anywhere would indeed work like
this in terms of the firewall filters. However, we don't see that many
people installing servers as VPN termination devices; most seem to use
embedded VPN devices, partly due to security concerns.

Also in the VPN case, you can assume that the users would have certs from
the
enterprise that you're offering access to. In the AAA case, the roaming
associations are the trusted root CAs. That's very tricky to pull off.