Subject: [midcom] Comments on Midcom Framework Draft (00)

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 17 May 2001 13:48:28 -0700

This comment is in regards to draft-ietf-midcom-framework-00.txt.

I value the different perspective on the midcom protocol framework
which the authors have taken in this draft vis-à-vis my own assumptions. 
I find that much of their approach is satisfying, particularly the novel 
(to me anyway) idea of having proxies and application layer gateways be the
primary elements to use the midcom protocol in order to establish "holes" 
through middleboxes. This idea differs from the model I had always assumed in
which the end hosts themselves would be the primary entity doing midcom
communications. This difference in orientation also translates into a very 
different idea between the authors and me as to the role of the policy server 
in the two approaches and the nature of the "hole" being established through 
the middleboxes themselves.

Despite my appreciation of aspects of the authors' approach, I nevertheless 
am left believing that the ultimate result of their approach is to
undermine the purposes for which we have deployed middleboxes in the first place, 
particularly firewalls. I realize that this is a complex topic and that this initial
posting may not adequately convey the nature of my concerns, but I nevertheless request 
that you please consider my points.

Section 5 of the draft is concerned with the authentication of MIDCOM agents to
the middlebox, possibility including mutual authentication. Then, in the
penultimate paragraph of this section (within Section 5.2), the authors write a very
important sentence that says: "When Middlebox notices an incoming midcom connection, the 
middlebox will consult its policy server for authenticity, authorization, and trust
guidelines for the connection." This sentence is important in several dimensions including:

* It is true both for the authors' model and my model -- therefore I agree with it

* This is the only point in which the authors explain how the authorization capabilities
  of the Policy Server, previously mentioned in Section 2.8, are explained.

What is critical about this section is that it begs the question as to how such authorization 
can be accomplished. That is, Section 5 is solely concerned with authenticating MIDCOM agents. 
At no point does the document deal with authenticating users. However, the authorization for
applications to access internal applications/services is a function of rights and permissions
ascribed to the authenticated user. Certainly this is true for our firewalls and I believe that
it is similarly true for yours. [In our case, the importance of this fact is perhaps elevated due to 
our requirements to establish Role Based Access Control (RBAC) constraints due to governmental regulations
and eBusiness-based process evolution.] In any case, the whole goal of the firewall is to keep the 
bad guys out. Firewalls are concerned therefore with USER access: the authorization of a connection 
through a firewall is a function of the rights and permissions ascribed to the USER, as determined by
local policy. This is orthogonal to the identity of the proxy or intermediate agent which the 
user may optionally use, which is the only entity being authenticated by this current draft. And 
that is why this approach undermines the utility of firewalls.

If the authors wish to preserve their current model (i.e., if they still don't want to adopt my
model), their model needs to be modified by having the midcom protocol convey the user's 
identity to the middlebox so that the middlebox can forward it to the Policy Server if the Policy 
Server is going to be able to authenticate and authorize that user's access into the corporation.

Some readers doubtlessly will want to object to this assertion of mine by an argument similar to the 
following: The authors indeed intended to only authenticate the MIDCOM agent because that agent is
an adjunct to the middlebox. It is solely that adjunct's responsibility to authenticate the user and, 
only if the user passes that authentication/authorization scrutiny, will the agent undertake to 
represent that user to the middlebox. Thus, only the agent needs to be authenticated to the middlebox
and not the user, since the agent is the agent of the user. Similarly, the "authorization" spoken of 
in the draft is an authorization for the MIDCOM agent, since the agent is representing the user to 
the middlebox and only it needs to be authorized.

There are several problems with this counter-argument. I will mention only two:

1) This approach opens a security loophole. A problem with this argument and approach is that there
is no guarantee being provided that the MIDCOM agent will indeed authenticate (and authorize) the 
user, or that even if it does, it will use the same policies or authentication/authorization
system (e.g., same directory) as the firewall would have done, which is necessary if that agent 
is to operate as an adjunct to the firewall. Worse, there is no assurance that it could do so. 
Unless this "hole" is satisfactorily addressed, this whole model is broken from a security 
standpoint, since the foundation of our firewall is based upon user authentication and access 
control, which can not be guaranteed to happen nor guaranteed to happen in a compatible way to the
firewall. [Note: any argument that your firewalls may be based more on packet filtering upon IP 
address and Port addresses than upon user-based access control will nevertheless not deprecate 
the fact that ours increasingly is -- and is increasingly based upon RBAC. Certainly we all 
can agree that to be valid, the framework must address all existing firewall deployments, 
not only a few of them.]

2) This approach makes enterprise management much more difficult. One of the difficulties
we face, when we try to protect our enterprises, is ensuring consistent policy and enforcement approaches 
system-wide. This approach introduces a firewall adjunct (i.e., a MIDCOM Agent), that has undefined 
mechanisms by which it conducts basic user authentication/authorization functions. It provides no assurances
that these functions can be integrated into the current enforcement practices of the corporation. 
No tools are being proposed to help us to smoothly integrate this adjunct into our systems, or to ensure
that the resulting system maintains the end-to-end security profile that the firewall is designed to
provide. It is quite probable that you will claim that these issues are out-of-scope (i.e.,
not directly relevant to the midcom protocol itself). I counter that claim by saying that it 
implies a far-too-limited scope, since a fundamental requirement is that the midcom protocol not BREAK
current firewalls. Regardless, this approach may make our jobs harder by adding more non-integrated 
elements into our system and by therefore introducing more opportunities for us to make 
mistakes. The approach appears to be introducing vulnerabilities into our system with no provision 
to patch them. Therefore, this framework is not viable from a system perspective. What we need 
is to simplify our environment, not make it monotonically more complex. 

The importance to authenticate/authorize the user within the midcom protocol is my major point 
above. I have a few minor points that I'd also like to make:

* There needs to optionally be constraints upon the "hole" which can be opened through the 
middlebox. Duration and number of sessions constraints need to be able to be imposed.

* The concept of "trust level" introduced in Section 5 (e.g., see section 5.2) is inherently 
problematic. This is a very fuzzy concept which is directly relevant to particular implementation
approaches (and non-relevant to others). Please either abandon it or make it concrete. (I'd be 
interested in whether you can make it concrete without addressing my major point above.)

* The midcom protocol needs provisions to reduce its ability to be used as a vehicle for Denial of 
Service attacks.

* Establishing paths such that the same packet needs to traverse the same firewall two or more times,
as is discussed in Section 6.3, is a VERY BAD idea. This should be explicitly avoided and protected
against. Please re-think this point.

--Eric

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 17 May 2001 21:30:10 -0700 (PDT)

Eric - You might refer the newer rev (-01( of the draft, released just 
this morning and see if some of your questions are answered there.

Also, your e-mail is extremely difficult to read with long sentences
wrapping around. Anyways, see my comments below.

cheers,
suresh

> different idea between the authors and me as to the role of the policy server

Why would the role of policy server change, whether an agent is run
on a proxy or an end-host?

> the middleboxes themselves.

Once again, what does it matter where the agent is - Why would the
nature of the hole change?

> that you please consider my points.

Fair enough.

> can be accomplished. 

From the policy server.

>                      That is, Section 5 is solely concerned with
> authenticating MIDCOM agents. 

Isnt this covered under the section titled - "Registration and 
Deregistration with a middlebox"?  Authorization is covered under 
section 5.0 and 5.2, not under "Authentication" section.

Anyways, would appreciate of you could refer the newer rev of the 
drfat and let me know what you think. Thanks.

> user may optionally use, which is the only entity being authenticated by this
> current draft. 

If the user(end-host) is not running the agent, then the user doest know
about the agent.

>                And 

Sorry, dont follow your logic here.

> Server is going to be able to authenticate and authorize that user's access
I think, you have this all wrong. User has nothing to do with the MIDCOM,
if the user is not running the agent. The domain administrator 
determines where to run the agent, how to authenticate the agent to 
middlebox etc..

> the middlebox and only it needs to be authorized.

More or less .. this is what the assertion is.

> user, or that even if it does, it will use the same policies or

MIDCOM agent doesnt  authenticate the user.

> authentication/authorization

Sorry - I dont understand the logic. You are assuming stuff that is not
stated in the document.
  
> is to simplify our environment, not make it monotonically more complex. 

This is a framework document. 

> * The midcom protocol needs provisions to reduce its ability to be used as a
What DOS attacks are you refering to?

> against. Please re-think this point.

Please review the newer rev draft. That has a detailed illustration 
on this subject.

> --Eric

Thanks.

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 18 May 2001 08:36:44 -0400

> ascribed to the authenticated user. 

This is an important point - we are chartered with 
describing the requirements and framework for an 
interface between the middlebox and a policy server, 
as well, and to date those have received relatively little 
attention.  Those who are so moved are encouraged to 
contribute text.

Melinda

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 18 May 2001 08:43:47 -0400

> If the user(end-host) is not running the agent, then the user doest know

Doesn't matter - if the organization's security policy
includes restricting access on the basis of user identity, 
that identity must be communicated to the firewall so that 
it can be fed into the policy component as one of the 
parameters for an authorization decision.  Note that 
network access policies may be different from application
access policies (see my draft on application issues).

Melinda