Re: Comments on X.509 SASL Authentication Mechanism

["Ed Reed" <ED_REED@novell.com>]

Steve - 

I wonder if this is the time to suggest a slight modification to the client authentication mechanism
described...  your text reads...

For Client Authentication:

1.  The client generates the credentials using local information, and signs the enclosed token with its own private key.

Now...what I'm aiming for here is to allow the use of derived credentials in lieu of the long-term private key of the user.  For instance, Digital had a mechanism which had the user generate a temporary, limited-life-time public/private key pair and sign a certificate of the limited use public key with the users long term private key.  Subsequent authentication bindings, within the lifetime of the temporary key pair, then used the temporary key pair to sign the local information for each new binding.  One mechanism that used this approach was called DASS [RFC 1507), and it's Delegation Key Pair.  Another is NDS's use of a Guillou-Quisquater identification scheme to produce zero-information proofs of identity as digital signatures over the local information.  Both mechanisms prove the identity of the user using the long-term public key of the user - DASS via a signed subordinate certificate of the Delegation Key Pair public key, and NDS via the GQ proof that depends on the users long-term public key.

So, my proposal is that the SASL mechanism uses, for the client authentication, [...] and signs the enclosed token with its own private key, or derivative thereof.  For DASS, the signature would be with the Delegation Key private key, who's public key is signed by the client's long-term private key (ie, the certificate chain for the credential is one certificate longer than for the long-term identity certificate of the user).  For NDS/GQ, the signature algorithm identifier could then indicate that the signature is via NDS/GQ instead of via RSA, DSA, or something else.

Would that work?

Ed

If the SASL mechanism you propose

-------------------
Ed Reed, Technologist
Group Technology Office
Novell, Inc.
+1 801 861 3320

>>> Steve Kille <S.Kille@isode.com> 04/18/1998 00:19:42 >>>
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.