RE: PKIX Part 2 Questions - Authenticated & Signed LDAP response ?

[Sharon Boeyen <[e-mail]>]

Mack, thanks for the observations and comments.

As a general comment - PKIX Part 2, for its use of LDAP, is currently
based on LDAP v2 not v3. When LDAP v3 reaches a more stable state we do
intend to look at it and may move from LDAP v2 to v3 in PKIX.

Below are my initial comments on the PKIX part 2 issues.  

Tim - can you comment on the current LDAP v3 spec and how it handles the
issues raised by Mack?

Mike can you add some insight to the OCSP issues Mack raises?

As agreed in Memphis, we will also be adding to PKIX part 2 the LDAP
operations profile required for the CA to add/delete certificate and crl
information for the repository. I also have other comments received on
the document and hope to have an update available sometime in May
(always an optimist!)



------------------
Sharon Boeyen                 
Entrust Technologies
mailto:[e-mail]       Tel: [phone]
http://www.entrust.com          Fax: [phone]

         Orchestrating Enterprise Security


>----------
>From: 	G. Mack Hicks, VP Bank of America[SMTP:[e-mail]]
>Sent: 	April 16, 1997 8:37 PM
>To: 	[e-mail]
>Cc: 	[e-mail]; [e-mail]
>Subject: 	PKIX Part 2 Questions - Authenticated & Signed LDAP response ?
>
>
>For IETF PKIX Mailing list
>
>RE: PKIX Part 2 - <draft-ietf-pkix-ipki2opp-00.txt>
>
>Questions
>
>2.1.1.1 Bind Request
>
>"simpleauth ... MUST accept NULL simple"
>
>Pardon please my lack of understanding of this line.
>The implication is that LDAP authentication is not allowed?
>Or that a null password must be allowed -- a strange concept?
>If authentication is allowed, may the other authentication
>methods of LDAPv3 be used (specifically SASL)?
>
>LDAPv3 does allow for session based queries to use session level
>authentication like SSLv3. May a PKIX Part 2 compliant directory use
>SSLv3 client authentication?
>
>"A LDAP repository read service SHOULD implement some level of anonymous
>search access."

On the authentication issue, to clarify:

Both anonymous and simple password based authentication are included in
PKIX part 2. From an implementation standpoint, anonymous binds should
be supported and authenticated binds may also be supported.

Remember that implementation and deployment are different. What this
means to an entity deploying a service is that any product conforming to
this aspect of PKIX Part 2 should be able to support the anonymous bind
but not all will necessarily support the simple bind.  When deploying a
service, you set your own requirements and not all products may suit
your needs.

>
>May a PKIX Part 2 compliant directory reply with "unwillingToPerform"
>for unauthenticated LDAP queries?

YES - and you may also choose not to accept anonymous binds and respond
with the "inappropriateAuthentication" error in the bindResponse (see
2.1.1.2)

>"A Public-Key Search service MAY implement authenticated search access."
>
>Did the authors have other ideas about how LDAPv3 authentication can be
>achieved other than session level (SSL) and SASL? Simple passwords are
>being discouraged on open networks.

Nothing specific defined at this time. LDAP v3 will have some additional
authentication support that we will look at (including those you mention
as well asanother InternetDraft on X.509 based strong authentication for
LDAP also) but until the LDAP v3 is solid (and I confess I had to leave
Memphis before the asid meeting, so I don't know what happened there -
Tim?)
 
>2.1.2.2 SearchResponse
>
>"An application providing LDAP repository read service over LDAPv2 MUST
>implement the full SearchResponse."
>
>If an entry has multiple certificates, does the quoted statement mean
>that ALL certificates for the entry have to be returned upon any query?
>I did not see any granularity in the LDAPv3 spec that would allow for
>specification within a query of a particular certificate--say by serial
>number, CA, validity period, public key usage.

I think the feature you are looking for is the extensible match filter
in the 93 X.511. LDAP v2 does not include this - Tim can you comment on
the LDAP v3 spec with respect to extensible match? X.509 (1997) includes
a detailed set of matching rules for both certificates and crls that can
be used in the extensible match filter.

Tim does the current LDAP v3 include extensible match?
>
>2.3 Transport
>
>"An ... LDAP repository ... service MUST support LDAPv2 transport
>over TCP ... "
>
>Does this statement prohibit the use of UDP (since it is unreliable)?
>Does this statement prohibit the use of SSLv3 with client authentication?

This statement doesn't prohibit anything. It only says what MUST be
supported. 
>
>2.4 Security Considerations
>
>" <snip>
>  ... CAs should bind to the repository with a minimum of
>  simple authentication."
>
>Simple authentication is password based.
>Will the CA be expected to provide a password to each subscriber or user?

No, the intent of this statement is that when a CA is accessing the
repository it should be using simple authentication, whereas end user
searching is generally ok anonymously.
>
>Section 4 - Online Certificate Status Protocol (OCSP)
>
>Comment
>
>This is a good first effort to a difficult subject.  The problem
>I see is that implementations of browsers, emailers, and other
>certificate aware applications will not present to the end user
>a certificate in a way that would allow the end user (recipient)
>to utilize a browser based function.
>
>Most appliations will have already written an LDAP enabled environment.
>Augmenting the LDAP response to include OCSP response in an LDAPv3
>extension would be suitable. Applications that would like to keep the
>signed validity response could do so -- those that are not capable of
>supporting the response would ignore the field (a non-critical extension
>to LDAPv3). LDAP repositories that did not support the extension would
>not be penalized since unrecognized extensions must be ignored.

One of the environments where OCSP is expected to fit is that where
directory protocols are not implemented. Are you proposing adding a
second protocol for OCSP (in addition to HTTP) or replacing the HTTP
version with an LDAP one?
I prefer not to see a lot of different ways standardized for
accomplishing the same task because that inevitably result in
interoperability issues further down the road.

> 
>
>4.1.2 Response
>
>"authenticated with the responding CA's digital signature."
>
>The may be a problem for the CA since the signature for a certificate
>requires the use of the CA private key which would likely be strongly
>protected.

OCSP is currently defined as a protocol between an application
(generally a certificate using system or relying party) and the
certificate issuer or CA - the repository, as a separate entity isn't
really addressed in this protocol. However, the issue of signatures (how
many and which ones) probably needs to be addressed for processing
certificate chains and dealing with scalability issues for these
services. Mike?

>I suggest: Signing by the repository.
>           I realize that the user would need the repository's
>           certificate.  LDAP could be used to get the key.
>           The repository could return a certificate signed by
>           the CA in question.  This CA public key would already
>           by in the certificate in question.
>
>4.2.1 Definition of Services
>
>"... 1) certificate path validation ..."
>
>I think I know what this means: A request to validate each step in the
>queried certificate chain. But I can find no reference in the PKIX
>literature. (Sorry if I missed it.)

Thanks for finding this. I'll do a search on the other docs too and if
there isn't a definition, we can add one.
>
>4.2.2 Error Response
>
>4th paragraph "... response as described in Section 2.1.2"
>
>(I think this has already been mentioned in the list - pardon me.)
>2.1.2 should read 2.1.1.2 IMHO.
>
>"The means by which a CA signals to a relying party which
>error behavior is offered should be through certificate contents."
>
>I would like a reference to PKIX Part 1 to the appropriate extension and
>to the PKIX Part 3 to the appropriate section. I may have missed this
>one in my readings.
>
>4.3.1.1 Query Syntax
>
>"OSCP_query        :    url request version cert_id"
>
>I cannot find "version" defined. (Again likely to have already been
>mentioned.)
>
>==============================
>
>In short, can an online authenticated query using LDAP have a returned
>response (OSCP) in an LDAPv3 extension?

Not currently. The two services are totally different. The LDAP service
is for retrieving information from a repository. The OCSP is for
contacting a CA to get confirmation directly from the CA. Can you
elaborate on what the specific requirement is and what sort of
environment you're addressing?  Are you looking for authentication on
LDAP services, in a CRL environment where the relying party identity is
required by the repository provider, or for an LDAP protocol
implmentation of a yes/no certificate status check? A fundamental
difference between these two services is where the decision on validity
actually takes place. In LDAP the decision is made by the relying party,
after retrieving all the relevant information, crls arls etc, while in
OCSP, the decision on the validity is made by the CA and the relying
party should receive enough information to assure itself that the
decision is correct (e.g. that the response is for the same certificate
as the request was, that the responder has the authority to make that
statement, etc). If dealing with a certificate chain, either the relying
party needs to get these assurances from each CA in the chain or have
the "trust" in the CA that provides the total service to them.  Mike
anything to add?

>If so, would this be part of the Section 4 - OSCP or part of Section 2 -
>LDAP?
>
>===============================================================
>Mack Hicks [phone]  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[e-mail]>
>