[Ietf-not43] First draft on Relay bags in FIRS

[Steven Legg]

Peter,

Peter Gietz wrote:
> Andrew Newton wrote:
>
> > Peter Gietz wrote:
> >>> Finally, a question.  Is this one bag per referral or one bag per
> >>> response/result set?
> >>
> >>
> >>
> >>
> >> No, and this has implications for the relay bag: The
> searchresponse
> >> can include an unlimited number of referrals but only one
> >> controlValue. That is why I sort of asumed that the Relay
> Bag contains
> >> only general information about the referring server and about what
> >> that server has to say about the client (authentication
> status, etc.).
> >>
> >> If the Relay bag has also to contain information about the
> referred to
> >> server, we would have a problem here.
> >
> >
> > Perhaps creating a syntax for the controlValue that
> partitions the value
> > as Strings of octets (or however it was defined) per
> referral, with each
> > related to the referral either by key or index.
>
> I call this Solution I here:
>
> I though of that, but then refrained from it because the requirements
> doc says in 3.1.13.1:
>
> > The protocol MUST NOT make any assumptions regarding the contents of
> > the relay bag
>
> This solution would anyway force the client to look into the
> relay bag,
> we would need the referral stored there too to have a clear
> attribution
> between referral and relay bag.

I think you are getting hung up on your own assumptions here.
Suppose that the format of the controlValue in a response were
something like this:

SEQUENCE OF SEQUENCE {
    ldapurl    [0] LDAPURL,
    relayBag   [1] OCTET STRING
}

The referral URL is clearly associated with the relay bag and the relay bag
is still opaque. Anything else that's needed can be added to the SEQUENCE.
The ldapurl field duplicates information in the SearchResultReference,
but we can deal with that in the definition of the control by saying
that any URL included in the controlValue is omitted from the
SearchResultReference.

RFC 2251 does not allow SearchResultReference to be empty but I don't
see any interoperability problems from explicitly allowing that constraint
to be violated since the response is never unsolicited (as far as I know)
The LDAPbis working group might also be willing to drop the constraint.

Regards,
Steven

>
>
> Now comes Solution II:
>
> The alternative, Eric is proposing, is to use the extension
> mechanism in
> the LDAP URL, which is specified in RFC 2255 (text in [[ ]] are my
> comments):
>
> >        extensions = extension *("," extension)
> >        extension  = ["!"] extype ["=" exvalue]
> >        extype     = token / xtoken
> >        exvalue    = LDAPString from section 4.1.2 of [RFC
> 2251] [[basically an OCTET STRING]]]
> >        token      = oid from section 4.1 of [RFC2252] [[an
> oid either numeric or as object descriptor]]
> >        xtoken     = ("X-" / "x-") token
> > The extensions construct provides the LDAP URL with an extensibility
> > mechanism, allowing the capabilities of the URL to be
> extended in the
> > future. Extensions are a simple comma-separated list of type=value
> > pairs, where the =value portion MAY be omitted for options not
> > requiring it. Each type=value pair is a separate extension. These
> > LDAP URL extensions are not necessarily related to any of the LDAPv3
> > extension mechanisms. Extensions may be supported or unsupported by
> > the client resolving the URL. [...]
>
> There are pros and cons here:
>
> Pro:
> - This solves our problem.
> - for every referral we have a Relay Bag
>
> Cons:
> - There is a "media change". Since clients usually don't communicate
> with servers via LDAP URLs, the client has to convert this
> information
> into the search control as specified in the new draft. Not
> too complex
> though:
>    * the token (provided the numeric od form is used) can be
> the same as
>      the controlType
>    * the criticality sign ('!') or its absebse can be stored in the
>      criticality field
>    * the exvalue is the controlValue (might need reencoding
> though, see
>      next bullet)
>
> - the exvalue has to be URLencoded, in the words of 2255:
> > Note that any URL-illegal characters (e.g., spaces), URL special
> > characters (as defined in section 2.2 of RFC 1738) and the reserved
> > character '?' (ASCII 63) occurring inside a dn, filter, or other
> > element of an LDAP URL MUST be escaped using the % method described
> > in RFC 1738 [5]. If a comma character ',' occurs inside an extension
> > value, the character MUST also be escaped using the % method.
>
> - The URL might not be a very good vehicle to transport
> greater amounts
> of data, which might restrict the usage of relay bags. I think it is
> doable though and I don't know of any length restrictions for URLS
> (hasn't there been a data field extensions for http urls as well?
>
> - we loose the symmetry between request extension and response
> extension, which would have made the implementation fairly easy, the
> client had only to take the whole control construct and add it to its
> next request
>
> Solution III:
> Another very easy solution would be to always give back only one
> referral to the client, but that might not be what we want either.
> If the Relay Bag is to store information about the referring
> server and
> about the client, we would not need more than one relay bag. But this
> would make it impossible, e.g. to encrypt the relay bag information
> with the public key of the server referred to, and we might
> want to have
> that.
>
>
> You see I am biased and none of the solutions looks very
> promissing to
> me. But I think we have to choose between Solution I and II.
>
>
> Peter
>
> >
> > -andy
> >
>
> --
> ______________________________________________________________
> _________
>
> 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
> ______________________________________________________________
> _________
>
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43 at lists.verisignlabs.com
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
>