Sesame Authentication protocol 1. Abstract This document defines the Sesame authentication protocol and the extensions required to the Kerberos Authentication protocol (RFC 1510). This document specifies the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to pass the Sesame authentication information. 2. Introduction Sesame is an authentication and access control protocol, that also supports communication confidentiality and integrity. It provides public key based authentication along with the Kerberos style authentication, that uses symmetric key cryptography. Sesame supports the Kerberos protocol and adds some security extensions like public key based authentication and an ECMA-style Privilege Attribute Service. The complete Sesame protocol is a two step process. In the first step, the client successfully authenticates itself to the Authentication Server and obtains a ticket that can be presented to the Privilege Attribute Server. In the second step, the initiator obtains proof of his access rights in the form of Privilege Attributes Certificate (PAC). The PAC is a specific form of Access Control Certificate as defined in the ECMA-219 document. This document describes the extensions to Kerberos for public key based authentication as adopted in Sesame. 3. Limitations of Kerberos Kerberos, as defined in RFC1510 uses symmetric key cryptography and requires shared secrets between realms. This limits the extent to which Kerberos can be used realistically, since it raises scalability issues. Kerberos is vulnerable to password-guessing attacks, and Kerberos depends on the security of the client workstation. Kerberos does not support access control. A client can be authenticated to the server but that server needs to be preconfigured with the privilege attributes of the client. In some sense, Kerberos provides an identity based control. 4. The Basic Mechanism in Sesame for strong authentication The basic mechanism is as follows: The user sends a request to the KDC as in Kerberos, except that if for public key cryptography based authentication his certificate and a signature accompany the are passed to the server through the preauthentication fields. Upon receipt of this request, the KDC verifies the certificate and issues a ticket granting ticket (TGT) as in Kerberos. This section describes extensions to Kerberos for supporting the use of public key cryptography in the initial request for a ticket granting ticket (TGT). * Users may authenticate using either a public key pair or a conventional (symmetric) key. If public key cryptography is used, public key data is transported in preauthentication data fields to help establish identity. 4.1. Definitions The extensions involve new messages that basically have new preauthentication fields; Sesame introduces 6 new messages that are described below. KRB_STRONG_BIND_REQ 25 StrongBind AS request to server KRB-STRONG-BIND-REPLY 26 StrongBind AS response to server KRB_UNWRAP_REQ 23 Unwrap BKP request KRB_UNWRAP_REP 24 Unwrap BKP response KRB_PAS_REQ 27 PAC request to server KRB_PAS_REP 28 PAC response from server Out of these, the KRB_STRONG_BIND_REQ and KRB_STRONG_BIND_REP are used for the strong authentication. The extensions also involve a new padata(preauthentication) type for Sesame: KRB_PADATA_SESAME 7 Sesame project and a new authorization data type : KRB_AUTHDATA_SESAME 65 The method of authentication is specified in the client request for authentication. The method can be one of KRB5_PASSWORD, STRONG_BIND_USER, KRB5_KEY. The STRONG_BIND_USER is the case of public key authentication, which is described below. 4.2. Public Key Authentication It is assumed that all public keys are signed by some certification authority (CA). The initial authentication request, KRB_STRONG_BIND_REQ, is sent to the Authentication Server. The KRB_STRONG_BIND_REQ has a bindRequest token containing public key data in the preauthentication field, of a KRB_AS_REQ. The structure of the KRB_STRONG_BIND_REQ is exactly same as KRB_AS_REQ, as defined in RFC1510 - The Kerberos Authentication Service, except for the PreAuthenticationdata (padata) field, which carries extra data. KRB_STRONG_BIND-REQ ::= [APPLICATION 25] KDC-REQ KDC-REQ ::= SEQUENCE { pvno[1] INTEGER, -- KRB_V5 msg-type[2] INTEGER, -- KRB_STRONG_BIND_REQ padata[3] SEQUENCE OF PA-DATA OPTIONAL, -- KRB_SESAME_PADATA req-body[4] KDC-REQ-BODY } PA-DATA ::= SEQUENCE { padata-type[1] INTEGER, padata-value[2] OCTET STRING, } KDC-REQ-BODY ::= SEQUENCE { kdc-options[0] KDCOptions, cname[1] PrincipalName OPTIONAL, realm[2] Realm, -- Server's realm sname[3] PrincipalName OPTIONAL, from[4] KerberosTime OPTIONAL, till[5] KerberosTime, rtime[6] KerberosTime OPTIONAL, nonce[7] INTEGER, etype[8] SEQUENCE OF INTEGER, -- EncryptionType, -- in preference order addresses[9] HostAddresses OPTIONAL, enc-authorization-data[10] EncryptedData OPTIONAL, -- Encrypted AuthorizationData encoding additional-tickets[11] SEQUENCE OF Ticket OPTIONAL } pvno This field is included in each message, and specifies the protocol version number. This document specifies protocol version 5. msg-type This field indicates the type of a protocol message. For the KDC-REQ message, this type will be KRB_AS_REQ, KRB_STRONG_BIND_REQ or KRB_TGS_REQ. padata The padata (pre-authentication data) field contains authentication information which may be needed before credentials can be issued or decrypted. The padata field is an array of elements, each having a type and value. In the case of the Sesame public key authentication, the padata field contians information to verify the identity of the client using public key cryptography. The padata field contains the BindRequest token, for strong bind authentication request and is filled with BindReply token as reply to BindRequest. req-body This field is a placeholder delimiting the extent of the remaining fields. If a checksum is to be calculated over the request, it is calculated over an encoding of the KDC- REQ-BODY sequence which is enclosed within the req-body field. kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the KDC and indicates the flags that the client wants set on the tickets as well as other information that is to modify the behavior of the KDC. All the fields in the KDC-REQ-BODY are as defined in RFC1510. The type KRB-PADATA-SESAME (value 7) in the padata-type indicates that the preauthentication data is specific to Sesame. The actual token type should be determined from the msg-type field. If the padata-type is KRB-PADATA-SESAME, and the msg-type is KRB-STRONG-BIND-REQ, then the padata will contain BindRequest as one of its elements. BindRequest ::= SEQUENCE { type [0] INTEGER, credentials [1] StrongCredentials } StrongCredentials ::= SEQUENCE { certification_path [1] CertificatePath OPTIONAL, bind_token [2] Token, name [3] DistinguishedName OPTIONAL -- subject name } CertificationPath ::= SEQUENCE { userCertificate Certificate -- certificate of the user theCACertificates SEQUENCE OF CertificationPath OP TIONAL -- the CA certificate with the chain of certification paths } Token ::= SEQUENCE { tokenSignedPart TokenSignedPart signingAlg AlgorithmIdentifier -- the name of the algorithm used to sign the tokenSignedPart signature BIT STRING -- the signature of tokenSignedPart } TokenSignedPart ::= SEQUENCE { algorithm AlgorithmIdentifier, -- Sesame uses a private algorithm name DistinguishedName, -- AS name time UTCTime, -- current time random BIT STRING -- a random number } The definition of Certificate, AlgorithmIdentifier, UTCTime can all be found in the ISO/IEC 9594 document or in the "ASN.1 definitions for the PreAuthenticationData used in Sesame". Usage of TokenSignedPart: - The TokenSignedPart consists of data to protect from replay attack on the ticket and its signature is stored in the Token. - The AlgorithmIdentfier field specifies the name of the algorithm used to sign the TokenSignedPart. Any algorithm can be specified in the AlgorithmIdentifier field : RSA, DES, DES-MD5, etc. - The name consists of the Authentication Server's name - The time is the timestamp when the request was generated - The random field contains a random number to verify freshness - The token consist of the signature of the TokenSignedPart ,the identifier of the algorithm used to sign the TokenSignedPart and the TokenSignedPart itself. - The certification Path consists of the user certificate and the chain of CA certificates. Upon receipt of the KRB_STRONG_BIND_REQ with KRB_SESAME_PADATA pre-authentication type, the AS should verify the user's certificate. It extracts the public key of the user from the certificate in the request. It computes the signature of the TokenSignedPart and compares it with the signature in the Token. This enables integrity protection for the TokenSignedPart. The AS also checks that the principal name exists and the timestamp in the TokenSignedPart is within the allowable window. If the local (server) time and the client time in the TokenSignedPart differ by more than the allowable clock skew, then it is an error. The AS then checks the freshness of the request, by comparing it with the random numbers from TokenSignedParts in the strong bind requests received in the last two minutes. If the request is fresh then the AS will send an appropriate strong bind reply. The KDC encrypts the reply with a random key generated only for this particular response. This random key is sealed in the preauthentication field: KRB-STRONG-BIND-REQ::= [APPLICATION 26] KDC-REP KDC-REP ::= SEQUENCE { pvno [0] INTEGER, -- KRB_V5 msg-type [1] INTEGER, -- KRB-STRONG-BiND-REP padata [2] SEQUENCE OF PA-DATA OPTIONAL, crealm [3] Realm, cname [4] PrincipalName, -- initiator's name and realm ticket [5] Ticket, enc-part [6] EncryptedASReplyPart } For a KRB_STRONG_BIND_REP, the one of the elements of the padata array will be a BindReply token, and the padata-type for that token will be KRB-PADATA-SESAME. The structure of the BindReply token is as follows : PreAuthentication Data: BindRep ------------------------------- BindRep ::= { credsAndSessionKey CredsAndSessionKey } CredsAndSessionKey ::= SEQUENCE { respCredentials StrongCredentials, -- the credentials of the AS encryptedKey BIT STRING -- session key for next step PAS } StrongCredentials ::= SEQUENCE { certification_path [1] CertificatePath OPTIONAL, bind_token [2] Token, name [3] DistinguishedName OPTIONAL -- initiator's name } CertificationPath ::= SEQUENCE { userCertificate Certificate, -- certificate of the AS theCACertificates SEQUENCE OF CertificationPath OP TIONAL -- the CA certificate with the chain of certification paths } Token ::= SEQUENCE { tokenSignedPart TokenSignedPart signingAlg AlgorithmIdentifier -- the name of the algorithm used to sign the tokenSignedPart signature BIT STRING -- the signature of tokenSignedPart } TokenSignedPart ::= SEQUENCE { algorithm AlgorithmIdentifier, -- Sesame uses a private algorithm name DistinguishedName, -- AS name time UTCTime, -- current time random BIT STRING -- random number from the Bind Request } Usage of TokenSignedPart: - The TokenSignedPart field consists of a data to protect replay of the ticket, and is signed by the AS's private key. - The AlgorithmIdentfier field specifies the name of the algorithm used to sign the TokenSignedPart. - The encryptedKey consists of the session key generated by the AS to talk to the TGS/PAS and it follows the format of the PlainKey structure below : PlainKey ::= SEQUENCE { plainKey EncryptionKey random BitString -- binds response to the request same random number as in KRB-STRONG-BIND-REQ } The format of the EncryptionKey is defined in the 'ASN.1 definitions for the PreAuthenticationData used in Sesame' on this web page. The plainkey consists of a DES session key and the random field is filled with the random number from the KRB_STRONG_BIND_REQ. The encrypted session key is put in the BindReply token, encrypted in the public key of the client. The AS also sends a ticket (TGT. in Kerberos) and an authenticator back to the intiator. The ticket has the following structure : Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER, realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedTicketPart } EncryptedTicketPart ::= [APPLICATION 3] SEQUENCE { flags [0] TicketFlags, key [1] EncryptionKey, crealm [2] Realm, cname [3] PrincipalName, transited [4] TransitedEncoding authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, caddr [9] HostAddresses OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL } AuthorizationData ::= SEQUENCE OF SEQUENCE { ad-type[0] INTEGER, ad-data[1] OCTET STRING } The AuthorizationData is a sequence of elements, each element containing the following fields. ad-type This field specifies the format for the ad-data subfield. All negative values are reserved for local use. Non-negative values are reserved for registered use. ad-data This field contains authorization data to be interpreted according to the value of the corresponding ad-type field. - The tkt-vno is KRB5_PVNO - The realm and sname are filled with the server's realm and principal name from the request body's realm and name. - The enc-part is used to transmit the session key and the PPID. - The session key is put into the key, encrypted. - The authorization-data consists of one element filled with the PPID. The PPID is the Primary Principal Identifier, which is a Security Attribute defined in the ECMA document TR/46, or can be found on our web page. For the KRB-STRONG-BIND-REP, the ad-type is KRB_AUTHDATA_SESAME, and the ad-value is PPID, which is of type SecurityAttribute. The PPID is the serial number of the certificate in the public key case, else it is a random number, that uniquely distinguishes a client. - The authtime and starttime consist of the time at which the reply is generated. - The other fields are not used. Thus, the session key, the PPID and the server's credentials are sent to the initiator. ------------------------------------------------- Software Research Group, Univ. of Illinois - Urbana Champaign If you have any comments, feel free to write to : Monika Chandak (mchandak@uiuc.edu)