Subject: RE: IP Address in the ACM (Was: Comments on Access Control Model - BNF)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 13:09:42 -0700

At 10:59 AM 4/4/01 -0700, Paul Leach wrote:
>I hope that IP addresses as subjects are OPTIONAL, and that the security
>considerations section is appropriately negative on their security.
>
>In fact, I believe they should be a SHOULD NOT in the spec -- i.e., you
>must have good reason to believe that they are secure before you use
>them.

I concur.

I also note that DNS names have all the security concerns of
the IP Addresses they are derived from and the DNS system
used to generate them.

---

From: robert byrne <[email-masked]>
Date: Thu, 05 Apr 2001 16:17:57 +0200

I don't think we should put optional things in the spec--it will create
interoperability problems.

I don't see why you are particularly down on ip address subjects, but a
subject with simple authentication doesn't seem to bother you.  I mean,
in practice I would say there is not much difference in the risk
involved in granting rights based on ip addresses and granting rights to
a subject with an authentication level of "simple".

The point is that, depending on the environment, these might well be
useful and acceptable ways of granting rights.  As such I think we
should keep the ip address subject, with the kind of warnings you
suggest.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Apr 2001 08:13:20 -0700

>interoperability problems.

Interoperability at what level?  There is nothing in this
specification or LDAP that requires two independently
developed implementations to act in the same manner given the
same data.  All that LDAP provides is that the client and
server understand what each said; that is "protocol
interoperbility" not "application interoperbility."  LDAP
does not require for implementations to be equally capable.

A case in point is that user "foo" in realm "EXAMPLE"
(via SASL/DIGEST-MD5) might have the implicit authzid
of "u:foo" on one server and "dn:uid=foo,dc=example,dc=com"
on one server (even though both hold the copies of the same
naming contexts and share the same REALM information).
There are obviously significant implications to this at
the application level, but not at the protocol level.

Please note there are very few MUSTs (or SHALLs) in the
ACM technical specification.

>I don't see why you are particularly down on ip address subjects,
>but a subject with simple authentication doesn't seem to bother you.

All of the current authnLevel stuff concerns me greatly.  I
have posted on this separately.
        Kurt

---

From: robert byrne <[email-masked]>
Date: Thu, 05 Apr 2001 17:30:18 +0200

> the application level, but not at the protocol level.

Well, there is certainly lots of stuff that we have not pinned down in
this draft.  I hope that that is because they are hard or beyond the
scope of the draft.  However, not specifying something as optional is
definitely within our control and will avoid the situation where one
server implements the ip subject and another server does not--simple as
that.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Apr 2001 09:12:50 -0700

At 05:30 PM 4/5/01 +0200, robert byrne wrote:
>However, not specifying something as optional is

All that is necessary for protocol interoperability is for
implementations to recognize the complete syntax.

We've training our users not to expect insecure features
in our software.  We are slowly eliminating these features
WITH the support of our user community.  Progressing a
Standard Track ACM which would require us to add back in
features, or preclude us from eliminating them, is a Bad
Thing.

Kurt

---

From: robert byrne <[email-masked]>
Date: Fri, 06 Apr 2001 15:22:44 +0200

> implementations to recognize the complete syntax.

So, why don't we just specify the BNF and stop there ?

The reason is that the semantic content is important too--and we should
be defining this semantics as precisely as we can, in order to arrive
with implementations that, all else being equal, are interoperable.

> features, or preclude us from eliminating them, is a Bad

Mmmm...will the next version of your product not allow the ability to
grant public access, becuase that's "insecure" ?  I suspect not--because
in some situations that's a useful policy, explicitly set by the
administrator.  It seems to me that the same is probably true of an
ip-address subject and simple authentication.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 07:30:41 -0700

At 03:22 PM 4/6/01 +0200, robert byrne wrote:
>grant public access, becuase that's "insecure" ?

With "public", we're going to disable it by default and require
the administrator take action to enable it when desired.

>I suspect not--because
>administrator.

If explicitly set by the administrator, yes.

>It seems to me that the same is probably true of an

If you are not on the Internet, maybe.  But on the
Internet, use of simple or IP-addressed authentication
is not appropriate and we should require implementations
to such and, in fact, we should recommend against (i.e. with
a SHOULD NOT) support such in our security considerations.

Kurt

---

From: robert byrne <[email-masked]>
Date: Fri, 06 Apr 2001 17:02:14 +0200

> the administrator take action to enable it when desired.

Do you mean that this action is external to your ACM...ie. it's not that
he just has to create an aci granting public access but rather he has to
turn on the ability to create such acis, external to the aci system ?

> a SHOULD NOT) support such in our security considerations.

Well depends what you mean by "the Internet"--is my corporate intranet
part of the Internet ?  There's a boundary there, but they are connected
and they all use IP.  The intranet though is generally a less hostile
place then the external Internet.  LDAP directories are fairly popularly
deployed in intranets and it seems to me that if one ACM can accomodate
both intranets and the Internet at large then that's a good thing. 
Developing a different ACM for every type of environment you can think
of doesn't sound like a great plan to me.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 18:42:41 -0700

Robert,

Given that the document allows additional subjects, there are
already interoperability issues of the nature you seem to be
concerned with.  If someone specified a "foo" subject to a
server that doesn't support the "foo" subject, an error should
be returned.  That ensures the client understands this server
doesn't support the "foo" subject.  How is that different for
the server returning a error for the IP-Address subject?

Kurt

---

From: robert byrne <[email-masked]>
Date: Mon, 09 Apr 2001 10:55:37 +0200

Kurt,

True.  The difference to me though is that "ipaddress" is a perfectly
well defined thing and so there is no a priori reason to make it
optional.  
This is not true of all subjects.  For example a "role" is still
undefined, so it is natural that some servers might not support it. 
Similarly for the case of SASL mechanisms--some implementations might
not have gotten around to implementing some of the mechanisms.  In these
cases there is nothing we can do.  However, by not making ipaddress
optional we are ensuring that we do not add, unecessarily, to these kind
of grey areas of the model.

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 09 Apr 2001 10:21:41 -0700

Robert,

I think we're going to have to agree to disagree on this one.

To ensure that is no confusion as to my position, I'll
reiterate it.

I object to a MUST (or SHOULD) for the ipAddress and DNS name
based subjects as I believe it inappropriate to mandate
(or recommend) the implementation of easily spoofed subjects.
It my opinion that these subjects should either be completely
removed (my preference) or made OPTIONAL. If made OPTIONAL,
the document should contain a detailed explanation of the
security considerations associated with the use of these
subject.

Kurt