Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D

From: Petra Barzin <[email-masked]>
Date: Sun, 03 Mar 2002 21:48:03 +0100

Denis,

I will discuss the different issues in separate mails and change the
subject of the mails accordingly.

- Petra

Denis Pinkas schrieb:

> Petra and Peter,
>
> Please find below responses to your comments.
>
> COMMENTS FROM PETRA BARZIN
>
> I would like to propose some more requirements to be included
> in the DPV/DPD requirements draft:
>
> [COMMENT 1]
>
> - a hash of the request MUST be included in the response.
> This may allow the client to check if his request was maliciously
> modified (if the response is signed) and helps to associate the
> response with his request when using connectionless protocols.
>
> [Answer 1] The requirements are different whether the requester simply wants
> an authenticated response or a signed response. For a signed response the
> inclusion of the important elements from the request is needed, so that a
> response can be individually tested against what has been requested. For an
> authenticated response, the hash of the request is sufficient. To summarize:
>
> - for signed responses, the important elements from the request
>   must be present.
>
> - for authenticated responses, either the hash of the request or the
>   important elements from the request must be present.
>
> [COMMENT 2]
>
> - a random number MAY be included in the request.
> This allows replay protection when the client has no clock.
> The random number doesn't have to be repeated in the response
> if the response contains a hash of the request.
>
> [Answer 2] Replay protection is so obvious that it has been omitted. We
> could certainly add some text. The nonce cryptographically binds a request
> and a response to prevent replay attacks. However when you say: "The random
> number doesn't have to be repeated in the response *if* the response
> contains a hash of the request". This sentence is in contradiction with your
> first comment where you say: "a hash of the request MUST be included in the
> response". A choice needs to me made.  :-)
>
> I believe that the nonce should be in the response as well, just because it
> is easier for the client to compute the hash over all the fields from the
> response instead of saying: "after the item X, I need to copy the nonce from
> the request".
>
> [COMMENT 3]
>
> - add one more component to a validation policy: algorithm requirements
> They identify the minimum key length of the signature key or
> untrusted hash- and signature algorithms.
>
> [Answer 3] I guess that you mean requirements only for the public key
> contained in the end-entity certificate to be validated. I am not sure that
> this is relevant. If you trust the certificate policy under which the
> end-entity certificate has been issued, then you trust the CA to certify
> public keys that have the right algorithm and key length. So I believe that
> your concern is already solved by specifying certificate policies.
>
> [COMMENT 4]
>
> - add another request/response pair to obtain the definition of a
> specific, the default or all validation policies defined on the server.
> So far only the references of a validation policies can be returned.
> But it might be necessary to retrieve the definition of a validation policy,
> too (e.g. for archiving).
>
> [Answer 4] You did not say where you wanted this addition. The server may
> support validation policies that have been locally set up, so there may not
> be a formal definition that matches the policy. So at least for these one,
> this will be impossible. I would like the current request/response pair to
> be usable,
> without the need to support the request/response pair allowing a remote
> definition of the policy. So I would keep the section 6 unchanged.
>
> However, supporting this as part of section 7 - PDP (Policy Definition
> Protocol) can certainly be considered.
>
> COMMENTS FROM PETER SYLVESTER
>
> There are some comments for DPV that have been ignored.
>
> The last three blocks in chapter 4 talk about security
> requirements, but the following two are not mentioned
> (unless I miss something).
>
> - Security requirements
>
> [COMMENT 5]
>
> - a method to authenticate a server before sending any request
>    (for example this can be achieved by SSL).
>    (Another example would be using encryption.)
>
> [Answer 5]. This is covered under the following wording: "In order to be
> able to be confident that the validation of the certificate has correctly
> been done, the client only requires an authenticated response". No change is
> necessary.
>
> [COMMENT 6]
>
> - a method to ensure confidentiality of the transport.
>
> [Answer 6] There is nothing here in that protocol that mandates
> confidentiality like protecting the value of a private key or a secret key.
> The transport can provide confidentiality in support of environments that do
> not wish to reveal requests or responses contents, e.g. using TLS or S/MIME.
> No change is necessary.
>
> [COMMENT 7]
>
> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'
>
> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.
>
> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows
> the server to authenticate the client, and this authentication allows the
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.
>
> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.
>
> [COMMENT 8]
>
> One may resume the relaying requirements into one:
>
> - The protocol MUST provide a means to allow (visible) relaying
>    of requests and responses.
>
> - Relaying requirements:
>
> - depending on policy, a server may just impersonate another
>    server, i.e., take the responses of another server, and create
>    its own response out of them.
>
> - a server should be able to include the response of a relayed
>    server into his response.
>
> - a server should be able to simple add another authentication
>    scheme to a response from another server (for example by
>    using a second signature or a counter signature.)
>
> - a server that acts as a relay should be able to tell to the
>    next server that it is acting on behalf of a end user, and
>    the final server should be able to note this in the response.
>
> - For relaying, the protocol MUST provide an efficient means
>    to detect loops.
>
> [Answer 8] Clients trust some dedicated servers. They don't care how the
> information that is provided has been established: there is a single server
> that is responsible: the one which provides the answer. If the response is
> signed by the expected private key, then it is acceptable, otherwise it is
> not. There are not requirements for chaining or referral services. Relaying
> between
> servers is not the topic of this document. No change is necessary.
>
> [COMMENT 9]
>
> - Requirements for incomplete answers:
>
> - a server may indicate an incomplete response,
>    and provide a method to update the response later.
>
> [Answer 9] This would create the maintenance of state information which
> should be avoided. There has been plenty of discussion on the list regarding
> the number of states.  People clearly want the fewest possible number. The
> client may query again later on. No change is necessary.
>
> Regards,
>
> Denis

---

From: Petra Barzin <[email-masked]>
Date: Sun, 03 Mar 2002 22:06:58 +0100

Denis,

yes, indeed. There is a contradiction. My last sentence should be:
The random number doesn't have to be repeated in the response
*because* the response contains a hash of the request.

I don't understand your last comment. The client does not compute
the hash over all the fields from the response but from his request!

- Petra

---

From: Petra Barzin <[email-masked]>
Date: Sun, 03 Mar 2002 22:14:46 +0100

Denis,

I've been thinking of signature validation when I required the algorithm
component of a validation policy. But this is the requirement document
of DPV/DPD. So please ignore it for this document but consider it for
the DSV requirements!

- Petra

the algorithm requirements are not restricted to the public key contained
in the end-entity certificate

---

From: Petra Barzin <[email-masked]>
Date: Sun, 03 Mar 2002 23:01:49 +0100

Denis,

I would propose the following:

- add one more sentence to section 6:

The protocol SHALL allow clients to obtain the identifier and
definition of a specific, the default or all of the policies supported
by the server by using another additional request/response pair.

- and add another section after the PDP requirements:

Policy Retrieval Protocol (PRP) requirements
In order to archive the validation result of a certificate, it MAY be
necessary to combine it with the used validation policy. In some
cases the client MAY want to get an overview of all validation
policies supported by the server. Both reasons result in the following
requirements for the Policy Retrieval Protocol :
* return a specific validation policy definition
* return the default validation policy definition incl. its identifier
* return all validation policy definitions incl. their identifiers
* return max. number of validation policy definitions incl. their identifiers
* return max. number of validation policy identifiers

The last two requirements are especially usefull for thin clients with
small display facilities

- Petra