The GSS-API [20, 21] offers security services indepen- dent of underlying mechanisms. A possible GSS-mechanism is the Simple Public Key Mechanism (SPKM) specified in . In this paper we will focus on the credential manage- ment for SPKM. If more than one connection is needed, the standard credential management requires either to cache the secret keys in insecure storage or to make the user en- tering a password to access the long term secret keys for every new GSS-connection. For environments in which nei- ther one is acceptable we propose a Secure Single Login (SSLogin) variant which works with temporary asymmetric keys and combines security and user comfort.
The GSS-API [20, 21] ”offers security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portabiltiy of applications to different environments”. Possible GSS mechanisms are e.g. the well known Kerberos V5 [18, 22] based on symmetric cryptography, the Simple Public Key Mechanism  or SECUDE [7, 9]. The latter may be viewed as an SPKM variant tailormade for the SAP R/3 environment.
To set up a secure (i.e. authentic, integer, confidential and non-repudiable) communication the initiator (client) and the target (server) have to establish a GSS-context, like discussed in section 2 more detailed. Note, that non- repudiation requires the application of digital signatures, i.e. public key algorithms. During context establishment the communication partners verify the peer’s identity and au- thorization and agree on a common session key, which can be used for confidentiality and integrity purposes during the actual communication. To proof the identity one has to ac- quire credentials. In Kerberos these credentials are so called ickets with limited lifetime. In public-key based mecha- nisms like SPKM, which is discussed in section 3 more de- tailed, and SECUDE the credentials are the secret keys and certificates for the public keys. The secret keys are stored in a personal security environment (PSE), which is ’opened’, i.e. made accessible, by entering a password. In practice the PSE usually is a smartcard or a PKCS#5 (see ) en- crypted file. This credentials have to be available whenever a new GSS-connection is requested, i.e. a GSS-context is to be established. This means, that either the PSE has to be open for a long time or the user has to enter the password everytime a new connection is set up. If this no problem, this is the most obvious way to provide access to the secret keys and, while not specified in , X.509 v3 / PKIX certifi- cation for the related public keys, which is briefly discussed in section 4.
However if keeping the PSE open for a long time bears se- curity problems or multiple entering of the password is not possible for usability reasons the proposed SSLogin variant, as discussed in section 5, is preferable. To implement this SSLogin we need to specify a slightly different credential management (see section 6), which allows the end user to certify its own temporary keys. In section 7 we will com- pare the discussed variants in terms of security, usabilty and performance.