Re: Comments on X.509 SASL Authentication Mechanism

[Steve Kille <S.Kille@isode.com>]

Sean,

Thanks for this input.

I'll take a black mark for starting with X.500(93) and not checking
X.500(97).   I'll update the spec to be fully 97 compatible.    

 - The GeneralizedTime stuff is "belt and braces", but I guess
   sensible, given the current y2k paranoia
 - I assume that the random element is needed because of a weakness
   exposed in the earlier version.

I added in the "generation time", because X.509 notes the possible use
of two times, whereas X.511 only gives the option to use one (the
expiry time).  It seemed to me that this gives a useful flexibility for
the recipient of the token.    I'd be quite happy to be explained why
this extra field will never be needed.

In passing, I have received few responses of the form:

1) This spec is a waste of time - throw it in the bit bucket.

2) We need this spec, it is important (and it should be progressed in
the XXXX WG.)

I've had a few positive and no negative reactions.  It would be useful
to me and I suspect to the area directors to see how people feel about
this work.


Steve 


 >From:  Sean Turner <turners@ieca.com>
 >To:    Steve Kille <S.Kille@isode.com>
 >Subject: Comments on X.509 SASL Authentication Mechanism
 >Date:  Fri, 17 Apr 1998 12:10:10 -0400

 >Steve,
 >
 >Hi!
 >
 >Finally got around to reviewing your draft.  All of my comment are on the SASLBindToken format (section 5).
 >
 >The first sentence says that the format is based on the X.511 syntax so why is it different?  Do the tags need to be the same for interoperability?
 >
 >If you're not some much worried about having the same syntax then I'd suggest the following changes:
 >
 >1.  Can we change time to be either GeneralizedTime or Time, where Time (from X.509) is:
 >     Time ::= CHOICE {
 >       utcTime         UTCTime,
 >       generalizedTime GeneralizedTime }
 >
 >2.  Can we add a specific field for a random response?  If we add the separate field then we don't have to specify special handling procedures for concatenation of the response random with the request random.  Syntax as follows:
 >
 >   response    [5]  BIT STRING OPTIONAL, 
 >
 >If you don't add the response field I'd suggest adding text to describe the concatenation:
 >
 >   a. As initiator (or invoker), encode the initiator/invoker-supplied random number rA (a BIT STRING) in the form of a BIT STRING containing the value rA, encoded most significant bit first, potentially with leading 0's (i.e. it is legitimate to round off the bits to 8-bit boundaries).
 >
 >   b. As responder (or performer), encode the random number rB (a BIT STRING) in the form of a BIT STRING containing the simple concatenation of rA and rB. For example, if rA is 1A3C5016 and rB is 03E66016, then the resulting bitstring is the 1A3C5003E66016, again with most significant bit first; rA being retained as is, and rB potentially having leading 0's.
 >
 >   c. As initiator (or invoker), declare the returned credentials as invalid if the returning random1 or random bitstring is not the same as the outgoing bitstring with additional bits concatenated.
 >
 >3.  Do we need the generation-time field or is the time field understood to be the initiator's clock plus some value?
 >
 >4.  If we keep generation-time and subject-name can we re-tag them as [10] and [11], respectively?  The '97 Token from X.511 already has tags numbered 5-9.  Note the field tagged [5] is a random response field.
 >
 >Cheers,
 >
 >-- 
 >Sean Turner - IECA, Inc.