draft-ietf-pkix-proxy-03.txt

PKIX的RFC英文文档

          2.2 Background 
              
             Computational and Data "Grids" have emerged as a common 
             approach to constructing dynamic, inter-domain, 
             distributed computing environments.  As explained in [6], 
             large research and development efforts starting around 
             1995 have focused on the question of what protocols, 
             services, and APIs are required for effective, coordinated 
             use of resources in these Grid environments. 
              
             In 1997, the Globus Project (www.globus.org) introduced 
             the Grid Security Infrastructure (GSI) [5].  This library 
             provides for public key based authentication and message 
             protection, based on standard X.509 certificates and 
             public key infrastructure, the SSL/TLS protocol [3], and 
             delegation using proxy certificates similar to those 
             profiled in this document.  GSI has been used, in turn, to 
             build numerous middleware libraries and applications, 
             which have been deployed in large-scale production and 
             experimental Grids [2].  GSI has emerged as the dominant 
             security solution used by Grid efforts worldwide. 
              
             This experience with GSI has proven the viability of 
             restricted impersonation as a basis for authentication and 
             authorization within Grids, and has further proven the 
             viability of using X.509 Proxy Certificates, as defined in 
             this document, as the basis for that impersonation.  This 
             document is one part of an effort to migrate this 
             experience with GSI into standards, and in the process 
             clean up the approach and better reconcile it with 
             existing and recent standards. 
              
              
              
              
          2.3 Motivation for Impersonation 
              
             A motivating example will assist in understanding the role 
             impersonation can play in building Internet based 
             applications. 
              


           
          [e-mail]                                           6 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

             Steve is an engineer who wants to use a reliable file 
             transfer service to manage the movement of a number of 
             large files around between various hosts on his company's 
             Intranet-based Grid. From his laptop he wants to submit a 
             number of transfer requests to the service and have the 
             files transferred while he is doing other things, 
             including being offline. The transfer service may queue 
             the requests for some time (e.g. until after hours or a 
             period of low resource usage) before initiating the 
             transfers. The transfer service will then, for each file, 
             connect to each of the source and destination hosts, and 
             instruct them initiate a data connection directly from the 
             source to the destination in order to transfer the file. 
             Steve will leave an agent running on his laptop that will 
             periodically check on progress of the transfer by contacts 
             the transfer service. Of course, he wants all of this to 
             happen securely on his company's resources, which requires 
             that he initiate all of this using his PKI smartcard. 
              
             This scenario requires authentication and delegation in a 
             variety of places: 
              
             *  Steve needs to be able to mutually authenticate with 
                the remote file transfer service to submit the transfer 
                request. 
                 
             *  Since the storage hosts know nothing about the file 
                transfer service, the file transfer service needs to be 
                delegated the rights to mutually authenticate with the 
                various storage hosts involved directly in the file 
                transfer, in order to initiate the file transfer.  
                 
             *  The source and destination hosts of a particular 
                transfer must be able to mutual authenticate with each 
                other, to ensure the file is being transferred to and 
                from the proper parties. 
                 
             *  The agent running on Steve's laptop must mutually 
                authenticate with the file transfer service in order to 
                check the result of the transfers. 
              
             Impersonation is a viable approach to solving two 
             (related) problems in this scenario: 


           
          [e-mail]                                           7 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

              
             *  Single sign-on: Steve wants to enter his smartcard 
                password (or pin) once, and then run a program that 
                will submit all the file transfer requests to the 
                transfer service, and then periodically check on the 
                status of the transfer.  This program needs to be given 
                the rights to be able to perform all of these 
                operations securely, without requiring repeated access 
                to the smartcard or Steve's password. 
                 
             *  Delegation: Various remote processes in this scenario 
                need to perform secure operations on Steve's behalf, 
                and therefore must be delegated the necessary rights.  
                For example, the file transfer service needs to be able 
                to authenticate on Steve's behalf with the source and 
                destination hosts, and must in turn delegate rights to 
                those hosts so that they can authenticate with each 
                other. 
              
             Impersonation can be used to secure all of these 
             interactions: 
              
             *  Impersonation allows for the private key stored on the 
                smartcard to be accessed just once, in order to create 
                the necessary impersonation credential, which allows 
                the client/agent program to impersonate Steve (that is, 
                authenticate as Steve) when submitting the requests to 
                the transfer service.  Access to the smartcard and 
                Steve's password is not required after the initial 
                creation of the impersonation credential.  
                 
             *  The client program on the laptop can delegate to the 
                file transfer service the right to impersonate Steve.  
                This, in turn, allows the service to authenticate to 
                the storage hosts as if it were Steve in order to start 
                the file transfers. 
                 
             *  When the transfer service authenticates to hosts to 
                start the file transfer, the service can delegate to 
                the hosts the right to impersonate Steve so that each 
                pair of hosts involved in a file transfer can mutually 
                authenticate to ensure the file is securely 
                transferred. 


           
          [e-mail]                                           8 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

           
             *  When the agent on the laptop reconnects to the file 
                transfer service to check on the status of the 
                transfer, it can perform mutual authentication. The 
                laptop may use a newly generated impersonation 
                credential, which is just created anew using the 
                smartcard. 
              
             This scenario, and others similar to it, is being built 
             today within the Grid community.  The Grid Security 
             Infrastructure's single sign-on and delegation 
             capabilities, built on X.509 Proxy Certificates, are being 
             employed to provide authentication services to these 
             applications. 
              
          2.4 Motivation for Restricted Proxies 
              
             One concern that arises is what happens if a machine that 
             has been delegated the right to impersonate Steve has been 
             compromised?  For example, in the above scenario, what if 
             the machine running the file transfer service is 
             compromised, such that the attacker can gain access to the 
             credential that Steve delegated to that service?  Can the 
             attacker now do everything that Steve is allowed to do? 
              
             A solution to this problem is to allow for restrictions to 
             be placed on the impersonation by means of policies on the 
             proxy certificates.  For example, the machine running the 
             reliable file transfer service in the above example might 
             only be given the right to impersonate Steve for the 
             purpose of reading the source files and writing the 
             destination files.  Therefore, if that file transfer 
             service is compromised, the attacker cannot modify source 
             files, cannot create or modify other files to which Steve 
             has access, cannot start jobs on behalf of Steve, etc.  
             All that an attacker would be able to do is read the 
             specific files to which the file transfer service has been 
             delegated read access, and write bogus files in place of 
             those that the file transfer service has been delegated 
             write access.  Further, by limiting the lifetime of the 
             credential that is delegated to the file transfer service, 
             the effects of a compromise can be further mitigated. 
              


           
          [e-mail]                                           9 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

             Other potential uses for restricted proxy credentials are 
             discussed in [10]. 
           
          2.5 Motivation for Unique Proxy Name 
              
             The dynamic creation of entities (e.g. processes and 
             services) is an essential part of Grid computing. These 
             entities will require rights in order to securely perform 
             their function. While it is possible to obtain rights 
             solely through impersonation as described in previous 
             sections, this has limitations. For example what if an 
             entity should have rights that are granted not just from 
             the proxy issuer but from a third party as well? While it 
             is possible in this case for the entity to obtain and hold 
             two proxy certifications, in practice it is simpler for 
             subsequent credentials to take the form of attribute 
             certificates. 
              
             It is also desirable for these entities to have a unique 
             identity so that they can be explicitly discussed in 
             policy statements. For example, a user initiating a third-
             party FTP transfer could grant each FTP server a PC with a 
             unique identity and inform each server of the identity of 
             the other, then when the two servers connected they could 
             authenticate themselves and know they are connected to the 
             proper party. 
              
             In order for a party to have rights of it's own it 
             requires a unique identity. Possible options for obtaining 
             an unique identity are: 
              
             1) Obtain an identity from a traditional Certification 
               Authority (CA).  
                
             2) Obtain a new identity independently - for example by 
               using the generated public key. 
                
             3) Derive the new identity from an existing identity.  
              
             In this document we use method #3, because: 
              
             *  It is reasonably light-weight, as it can be done 
                without interacting with a third party.  This is 


           
          [e-mail]                                          10 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                important when creating identities dynamically. 
                 
             *  As described in the previous section, a common use for 
                PCs is for restricted impersonation, so deriving their 
                identity from the identity of the EEC makes this 
                straightforward.  Nonetheless there are circumstances 
                where the creator does not wish to delegate all or any 
                of its rights to a new entity.  Since the name is 
                unique, this is easily accomplished by #3 as well, by