[Ietf-not43] issues and questions on FIRS

[Peter Gietz]

Some comments on #2, #3, and #4:

Andrew Newton wrote:

> I have a couple of questions regarding FIRS, some of them being 
> complaince issues.
> So that the lines between these issues do not blur, I've broken them out:
> 
> 1) Naming Syntax of inetDnsDomainSyntax (Section 3 in 
> draft-ietf-crisp-firs-dns).
> 2) The implementation of 3.1.8.
> 3) The implementation of 3.2.8.
> 4) Enumeration of error codes.
> 
> If I have simply overlooked something, I apologize.  Please hit me over 
> the head with the pointers.
> 
[...]
> 
> #2 - The implementation of 3.1.8.
> 
> There was mention of 3.1.8 in the meeting by Peter, but I do not see it 
> addressed in the drafts.  Looking through the jabber logs, Peter 
> proposed various methods to do this.  These were defined as: using the 
> bind operation, special policy entries, and server-side extended 
> operations.
> 

The first proposed solution (I):
> The use of the bind operation would be overloading of LDAP's 
> authentication mechanism and would likely cause confusion.  

This would be a control to the bind operation, which could do FIRS 
version negotiation and be used for the server to tell the client what 
kind of data it can expect to retrieve.

> Plus I do 
> not see how it would be tied to a query. 

Yes right, this would be more general information, not information about 
a special query. But to be honest, I don't understand this requirement 
in this caser. What is the difference between the two following client 
server dialogues?

1.) Without feature 3.1.8:
client binds to server
client makes request
server sends back I won't answer you this request

2.) With feature:
client binds to server
client asks server: will you answer this request
server answers no

The only difference IMO is that in cas 1 you don't need an additional 
circle in the case the server wants to answer the request. Thus I think 
for per request you don't need to check acls.

What makes more sence is to generaly ask "will you provide me with this 
sort of data?" and this could be checked inside an additional control to 
the bindrequest and response.

The second proposed solution (II):
 > The second option of
> special-purpose policy entries would probably work, but I think the 
> convention for doing it would be hard to coordinate.  

Again this solution would only give back general rules about which 
client can expect which kind of data. Such policy could of course be 
places at many places in the Directory Information Tree using the 
concept of subtree subentry and thus be less general than solution I.

The client could check e.g. the policy of a subtree of the whole tree 
the server has as naming context, and evaluate itself if it can expect 
to retrieve data or not. I once wrote a schema for LDAP-crawler policy 
and would be willing to write something similiar for FIRS.

Solution III:
 > The third option
> of an extended server-side operation I do not understand.
There are two similiar LDAP protocol extension mechanisms, one is the 
control, which enhances existing operations, like the control defined 
for enhancing the search operation with the relay bag feature.

The second LDAP protocol extension mechanisms is called extended 
operation, which is a total new operation with request and response 
defintions. Since check-ACLs would be a new operation I think, it is 
better to have an extended operation instead of another search control.

extended operations have to be understood by client and server. I am not 
sure how the "server-side" came into the jabber logs.
> 
> It would seem that this would be easily done with another control.  As 
> in, the control for "only check permissions" is set and then the query 
> is issued.  The control is then "released" after the answer.  I don't 
> know.  This is just me theorizing.

are you talking about a search extending controll here?

> 
> Because LDAP supports a generic query syntax and because service 
> providers are likely to deny all queries not explicitly allowed to 
> prevent data mining, this requirement seems more important for the FIRS 
> proposal.

I still think that a per request granular implementation of this feature 
is rather useless (see my remarks to solution I)

> 
> #3 - The implementation of 3.2.8.
> 
> Looking at the jabber logs, there is also discussion of this item with 
> theorizing about how it might be done but no mention of it in the 
> drafts.  Nor can I find it.  I think the conversation in the jabber logs 
> is correct with regard to this only needing to be done on the LDAP 
> attribute level and not the LDAP value level, which Peter seemed to 
> think would be harder to do.  However, either the control or the 
> reserved values (or whatever) do need to be specified.

Isn't this addressed in section 5.1.4. of 
http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-02.txt,
where three standard LDAP error codes are used, as proposed by me in the 
  meeting?

> 
> #4 - Enumeration of error codes.
> 
> Given the recent discussion on error codes and the mention of these in 
> the jabber logs, I think it is necessary to fully enumerate them so that 
> we can better understand what needs further clarification.  Some of the 
> error codes would naturally map to existing LDAP error codes, but as we 
> discussed with the bags, some will not.  This will help with listing 
> which new codes needed to be defined.

My current understanding is that we only need new error codes for the 
relay bag stuff. All other FIRS errors can be mapped by standard LDAP 
error codes. That is what Eric said and I have no objections to this.

Of course it may be a good thing to have an appendix in firs-core ore 
firs-arch listing all error codes used in FIRS, but this will produce 
dependencies with the relay bag draft...


Cheers,

Peter

> 
> -andy
> 
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43 at lists.verisignlabs.com
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: peter.gietz at daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________