Subject: Standards and APIs (C LDAP API: security considerations)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 17 Nov 1999 11:35:51 -0500

We disgress, so I changed the subject line...

At 02:17 17.11.99 -0800, Paul Leach (Exchange) wrote:

> > -----Original Message-----
> > From: Harald Tveit Alvestrand 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Wednesday, November 17, 1999 5:23 AM
>
> >
> > <SPAN MODE="IETF Policy">
> > IMNSHO, this is exactly the wrong thing to have happen in the
> > *standard*
> > LDAP API. Policy engines cannot be standardized at the
> > present stage of our
> > ignorance; a standard API should (IMNSHO) be no more than a means of
> > creating protocol elements on the wire and state in the state
> > machines on
> > each end.
> >
> > It is then up to the vendor (hi vendor!) to provide extended
> > APIs that
> > build upon the standard LDAP API to encapsulate policy
> > decisions by the
> > site admin.
> > But this functionality SHOULD NOT be standardized and MUST
> > NOT be mandatory.
> > </SPAN>
>
>I respectfully submit that this is not why most people want a standardized 
>API. What you propose means that the LDAP API becomes an interface for 
>vendors to use to build the _actual_ API layer that applications call. 
>That layer would not be a standard. What people want is a standard API for 
>applications to use, not vendors.

One man's application is another man's vendor.

The classical reason for standard APIs is so that you can have one 
application running on multiple platforms, or multiple OS versions, and 
have the results of that application be the same.

If you create a situation where the PDUs being put on the wire are 
different (for example having different authentication data) from the 
*same* application  written on 2 different platforms to the *same* API, and 
this is not visible to the application, I would claim that you don't have 
interoperability at the API level.

>I do not believe that it is necessary to have a standardized policy engine 
>to say that an API is supposed to enforce policy (whatever it is). That's 
>different than saying the API must enforce some particular policy.

I do not believe that it is possible for the IETF to have a standard that 
says "this is the API, this is the protocol - in between them something may 
happen that causes behaviour to vary, sometimes rendering applications 
noninteroperable, but how this happens is outside the scope of the standard".

This line of reasoning is (I think) what led to the original policy of all 
APIs being Informational rather than standards-track.

BTW, the term "API is supposed to enforce policy" seems strange to me - I 
think you mean "the implementation of an API is supposed to enforce policy"?
I disagree with both statements, but the second one is clearer :-)

                             Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 02:53:04 -0800

> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 8:36 AM
> To: Paul Leach (Exchange); [email-masked]
> Subject: Standards and APIs (C LDAP API: security considerations)
> 
> >

I don't disagree as far as it goes -- I'm just adding "results of that
application be the same when the configured policies are the same".

> interoperability at the API level.

Sure you can -- it just means that there is state under the API that affects
the PDU. Such as, which authentication protocols are configured.

> noninteroperable, but how this happens is outside the scope 

The whole intent of policy to to say, in some cases, "thou shalt not
interoperate here". I.e., there is a distinction between "interoperable" --
capable of interoperation -- and actual interoperation in partucular cases.
A strict reading of your paragraph above might imply that a connection could
never be refused due to an authentication failure.

I don't think that the whole utility or interoperability of a standard API
would be destroyed if there were a status code for each function that said
"denied by policy settings". Any more than there is by the ones that
probably exist already that say "authentication failure" or "access denied".

> I disagree with both statements, but the second one is clearer :-)

Yes. The first one is just less to type.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 11:14:59 -0800

> From: Graham Klyne [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 5:12 AM

> Without this, 
> applications that
> wish to depend on some particular (policy-definied) behaviour 
> are left out
> in the cold;  or, they use an API subset for which full semantics are
> defined, which brings us back to Harald's position.

Applications shouldn't need to depend on certain policies being configured.
"Policy" is not the same as configuration "options". 
What applications will have to do is to be able to cope with being told an
action is denied by policy. Just like they have to cope with authentication
failures or "access denied".

Paul

---

From: Graham Klyne <[email-masked]>
Date: Thu, 18 Nov 1999 13:06:59 +0000

Paul,

If you are talking about policies whose effect is to allow/disallow an
action, then I agree.

OTOH, policies that result in different behaviours for a given operation
(which I understood --maybe incorrectly-- to be the case with referrals),
then I think that is a different kind of consideration.

#g
--

>failures or "access denied".

------------
Graham Klyne
([email-masked])