Thanks, Steve. That does clarify things.
So impersonation certificates are not intended to be used for delegating signature authority from one human being to another?
Regards,
Carlin
_____________________________________________ - Carlin Covey Cylink Corporation
-----Original Message----- From: Steve Tuecke [mailto:tuecke@xxxxxxxxxxx] Sent: Friday, March 09, 2001 1:23 PM To: Carlin Covey Cc: ietf-pkix@xxxxxxx Subject: Re: Impersonation Certificates - proofing IC requesters
Carlin,
Some examples of when ICs are generally created (in our experience with GSI) might help answer your questions:
1) Creation of a local IC for single sign-on purposes: In this case, the creation of the IC is driven entirely by the holder of the EEC. So there is no requester of the IC. Or I suppose you could say that the requester is already holding the EEC and its private key, so proofing is not an issue.
2) Delegation of an IC to a remote party, for example when starting a remote process: This is usually done over a mutually authenticated channel with, for example, the remote process starter service, so the issuer knows the identity of the starter to whom it is delegating the IC. In this case, the issuer will be checking the identity of the party to whom it is issuing the IC for reasons aside from (or in addition to) proofing the IC requester. In addition, the IC delegation is usually done as one step of some well defined exchange between the parties, so the issuer knows in advance that it wants to issue the IC, and it just need to make sure that it is issuing it to the right party. In other words, the issuance of the IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of an existing IC), and as part of a larger protocol exchange between the parties. So proofing the IC is really just a matter of checking the identity coming from the authentication (which you would do anyway), and verifying that the IC request does not have anything unexpected in it. Standard message integrity checking on the mutually authenticated channel between the parties will prevent man-in-the-middle attacks.
3) Certificate repository: Suppose that the EEC and its private key are held in some sort of certificate/key repository, which will issue an IC upon request from a client. So the questions are, how does the client authenticate with the repository, what authorization checks does the repository perform before issuing the IC, and how is a man-in-the-middle attack prevented? Client authentication may be handled in a variety of ways. For example, the client can connect to the server and perform server only authentication (i.e. it knows the identity of the repository in advance). It can then provide a name/password, one-time-password, or something else over the confidential channel. This password is used to authorize the IC issuance, and the IC is delegated back to the client over the integrity checked channel to avoid man-in-the-middle.
So I think the answer to your question is that unlike a traditional CA, in the situations where we have used ICs effectively, previously issued EECs provide for the automatic authentication necessary to allow for automatic proofing of the request.
-Steve
At 05:54 PM 3/8/2001 Thursday, Carlin Covey wrote: >Gentlepersons, > >draft-ietf-pkix-impersonation-00.txt describes a mechanism for >delegating authority from entity A (who is not a CA) to entity B >by issuing an "Impersonation Certificate" (IC) to entity B that >is signed using entity A's PKC. > >Below step 5 of section 2.4. the following text appears: > > "The process of creating an IC is as follows: > > 1. A new public and private key pair is generated. > > 2. An unsigned IC request is created, conforming to the profile > described in this document. > > 3. The IC request is signed by the private key of the EEC, or by > another IC. During this process, the unsigned IC is verified to > ensure that it is valid (e.g. it is not an EEC, the IC fields are > appropriately set, etc). > > When an IC is created as part of a delegation from entity A to > entity B, this process is modified by performing steps #1 and #2 > within entity B, then passing the IC request from entity B to entity > A over an integrity checked channel, then entity A performs step #3. " > >[Carlin's comments/questions]: >I'm trying to understand some of the security aspects. >I don't see any discussion of proofing the IC requester. How >does the EE authenticate the identity of the IC requester? >A CA or RA normally has some sort of proofing facilities >available that are used to authenticate the identity of a >human being (e.g. a database of employee information, some >expertise in recognizing legitimate paper identity documents, >etc.) An EE is probably not well-equipped to do this sort >of human identity proofing. Moreover, in the example in >section 2.3 the IC requester appears to be some automated >process. How does the EE authenticate the identity of this >process? Even if the EE can authenticate the source of the >IC request, how are man-in-the-middle attacks prevented >during the IC request process? > >- Carlin Covey > Cylink Corporation