[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: The X.509 SASL document

To: Steve Kille <S.Kille@isode.com>
Subject: Re: The X.509 SASL document
From: Chris Newman <Chris.Newman@innosoft.com>
Date: Wed, 01 Jul 1998 11:26:46 -0700 (PDT)
Cc: IETF LDAP Extensions WG <ietf-ldapext@netscape.com>
Delivered-to: ldapext-archive@critical-angle.com
In-reply-to: <1071.899277840@isode.com>
Resent-date: Wed, 1 Jul 1998 11:26:44 -0700 (PDT)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"za2Q4.0.wC5.Rzdcr"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com

A few comments:

On Wed, 1 Jul 1998, Steve Kille wrote:
> This mechanism is given three  SASL keys for different variants:
> 
> -    "X509-CLIENT-<algorithm>" for client authentication only.
> 
> -    "X509-SERVER-<algorithm>" for sever authentication only.

What is the purpose of server-only authentication here?  What does an LDAP
bind or IMAP AUTHENTICATE mean if it doesn't authenticate the client? 

While SASL doesn't forbid doing server-only authentication, I don't think
it fits the use of SASL in current protocols very well.  I'd be happier if
this feature was dropped from the spec. 

> -    "X509-BOTH-<algorithm>" for client and server authentication.  In
>      this case client authentication is done prior to server authentica-
>      tion.

I'm curious why the client goes first rather than the server in this case.
I'd normally want the server to go first so the client doesn't leak
information until it knows it's talking to an acceptable site.

> Each SASL key may be used with a list of algorithms.  Supported algo-
> rithms in this version are "DSS", "RSA", and "X-<private>".

I'd prefer if you just dropped "X-<private>" from this list.  There's
already a SASL mechanism IANA registry which doesn't require a standards
track specification, so it's easy to add new mechanisms as necessary.

> SASLStrongCredentials ::= SET {
>     certification-path [0] CertificationPath OPTIONAL,
>     bind-token         [1] SASLToken,
>     name               [2] DistinguishedName OPTIONAL}
> 
> SASLToken ::= SIGNED { SEQUENCE {
>     algorithm          [0] AlgorithmIdentifier,
>     name               [1] DistinguishedName,
>     time               [2] UTCTime,
>     random             [3] BITSTRING,
>     response           [4] BITSTRING OPTIONAL,
>     generation-time    [20] UTCTime OPTIONAL,
>     subject-name       [21] GeneralName OPTIONAL}}
> 
> GeneralName ::= CHOICE {
>     otherName          [0] OtherName,
>     rfc822Name         [1] IA5String,
>     dNSName            [2] IA5String,
>     x400Address        [3] ORAddress,
>     directoryName      [4] Name,
>     edipartyname       [5] EDIPartyName,
>     uniformresouceidentifier [6] IA5String,
>     iPAddress          [7] OCTET STRING,
>     registeredID       [8] OBEJCT IDENTIFIER }
                               ^^
                              typo

I gather this is the heart of the spec.  I'll admit that I haven't read
the X.509/X.511 specs, but I hope you'll find the things I misunderstand
helpful to clarify the spec regardless.  I'll consider "it's in the
X.509/X.511 spec" a fair answer to most of the questions below: 

> certification-path:
>      This provides a mechanism for exchange of certificates, which may
>      help the recipient to verify the credentials.

Can a compliant implementation ignore this field when it's present?

> name:This is the name of the signer of the token.  For client authenti-
>      cation, this will need to be included unless the information is
>      carried in another protocol element of the exchange.  For server
>      authentication, this will not normally be needed.

So if I have a user "fred" on my IMAP server, what do I put here?  Is
UTF-8 permitted?

> algorithm:
>      This is the algorithm used to sign the token.

Isn't this redundant with the mechanism name?  Does the verifier simply
make sure this matches the algorithm in the SASL mechanism name and fail
otherwise?

Or is this the cryptographic hash function used, and the output is then
run through the algorithm in the SASL mechanism name?  In which case,
which cryptographic hash functions are mandatory to implement?

> name:This is the name of the object that is verifying the token.   For
>      client authentication, this will be the name of the server.

What name formats are mandatory to accept here?  The "DC=..." format only?

> random:
>      This is a random number, which should be unique for the target over
>      the valid life of the token.    This is included to prevent replay
>      attack.

So client A and client B are using the same cert to authenticate to server
X.  Does this mean client A and client B have to make sure they use 
different values in this field somehow?

> response:
>      This is used to carry a number derived from random if challenge
>      response of authentication is required.  This shall be used in the
>      client phase of X509-BOTH and in no other circumstances.

I don't understand.  When the client includes this, what does the server
do with it?

> generation-time:
>      This is the time that the token was generated.  It may be generated
>      by the client.  It may be used by the entity verifying the token to
>      not accept the token prior to its exiry time.

Is "exiry" a typo?  Does this mean you wouldn't accept credentials if the
generation-time is in the future?  Or is there something more going on
here?

> subject-name:
>      This is a very general definition of a name, taken from X.509(v3).
>      This definition is being used by ongoing work on PKI.  This enables
>      authentication identifiers other than distinguished names to be
>      used.

So using the terminology from SASL, this is the "authorization identity"
(user to login as) and the name field above is the "authentication
identity" (user to whom the credentials belong).  If I'm correct, I'd like
you to state this explicitly for people who are more familiar with SASL
than with X.509 stuff.

> Note that this description is for tutorial purposes only, and the formal
> definition is taken from X.511.

The X.* serious have a real problem with permitting lots of variations and
not saying which ones are mandtory to support.  Although I haven't read
all the relevant material I get a gut feel that you need to do some more
profiling before an implementor know exactly what he can skip and what he
has to support.

> The following algorithms are recognised for use with this mechanism:
> 
> 1.   DSS.  (X509-CLIENT-DSS, X509-SERVER-DSS, X509-BOTH-DSS).
> 
> 2.   RSA.  (X509-CLIENT-RSA, X509-SERVER-RSA, X509-BOTH-RSA).
> 
> The set of supported algorithms is handled by the SASL negotiation. Sup-
> port of the DSS algorithm is recommended for use with this mechanism.

It'd be quite convenient if you included the appropriate values for the
"algorithmidentifier" for these algorithms.

> illustrate the protocol interaction and does not provide valid encoding
> examples.
> 
> S: * OK IMAP4 server ready
> C: AOO1 CAPABILITY
> S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=X509-CLIENT-RSA AUTH=X509-CLIENT-DSS
> S: A001 OK done
> C: AOO2 AUTHENTICATE X509-CLIENT-DSS
> S: +
> C: AE31FF05.......==
> S: + 13c3FF44.......==
> S: AOO3 OK Welcome, authenticated user: CN=Joe Bloggs,O=Widget,C=GB

I don't suppose you could give a real example, including the
public/private keys used and preferably the output from an ASN.1
decompiler?  Something with the level of detail in the example in
draft-newman-sasl-passdss-01.txt.

		- Chris

References:
- The X.509 SASL document
  - From: Steve Kille <S.Kille@isode.com>

Prev by Date: The X.509 SASL document
Next by Date: Re: Updated version of "X.509 Authentication SASL Mechanism
Index(es):
- Chronological
- Thread