Le 26/05/16 à 04:17, Richard Feezel a écrit :
> Kai,
>
> I recall that the Kerberos specifications indicate that empty lists
> (sequences) should not be included in the ASN.1 encoded byte stream. Thus
> the correct representation of items that are empty in object space is with
> NULL, not with a tagged field with no elements.
That's the same thing, IMO :
"The Kerberos protocol does
not semantically distinguish between an absent optional SEQUENCE OF
type and a present optional but empty SEQUENCE OF type."
Usinhg Null or an empty list should result in the same behavior, when
generating the ASN.1 stream.
In ApacheDS Kerbeors implementation, we schoose to create an empty list instead
of seting the padata field to null if we have no padata. What is important is
not to transmit the emtpy list in teh ASN.1 stream :
// The PD-DATA if any -------------------------------------------------
if ( paData.size() > 0 )
{
// The tag
buffer.put( ( byte ) KerberosConstants.KDC_REQ_PA_DATA_TAG );
buffer.put( TLV.getBytes( paDataLength ) );
// The sequence
buffer.put( UniversalTag.SEQUENCE.getValue() );
buffer.put( TLV.getBytes( paDataSeqLength ) );
// The values
for ( PaData paDataElem : paData )
{
paDataElem.encode( buffer );
}
}
The key here was to avoid NPE. Now, you can perfectly avoid to create such an
empty list, and to check for null when accessing the padata field.
> We didn't run into very
> many cases, though when we did we fixed them by adding the necessary IF
> test in the patch.
> But these were found based on running tests and seeing
> NPE's thrown at run time, not on a survey of the code to try to identify
> all the possible failure points. We didn't feel competent to make such a
> survey given our limited familiarity with the code structure. I believe the
> correct way to conduct such a survey would be to go to the IETF
> specifications and identify all optional fields, then search the code for
> all references to the objects corresponding to these fields.
There are 3 use cases in the Kerberos RFC :
KDC_REQ padata
KDC-REQ-BODY additional-tickets
KDC-REP padata
>
> Regarding authorization data: given the open architecture, and
> vendor-proprietary nature, of authorization data I believe you would have a
> very difficult time trying to think of all the different back end data
> elements to include in the principal identity object. I suppose you could
> include a Map type structure of name value pairs, but I'd be concerned
> about the amount of effort expended to construct that data in the back end,
> only to have the majority of it be ignored by the authorization data
> plugins.
>
> I'm afraid the relationship between back end implementations and
> authorization data implementations is too close to develop an efficient
> generalized API between them that would meet the needs of all vendors. I
> believe any generalized API between back end implementations and
> authorization data handlers MUST support arbitrary and proprietary
> communications between these two elements.
Agreed.
