What is SESAME?
 Overview of SESAME.
 Walk-through of SESAME.
 SESAME v.s. Kerberos.
 Reference.
 

SESAME stands for "Secure European System for Applications in a Multi-vendor Environment" , it is a European research and development project, partly funded by the Commission of the European Communities (CEC). It is also the name of the technology that came out of that project.

The SESAME technology offers sophisticated single sign-on with added distributed access control features and cryptographic protection of interchanged data.

SESAME is a construction kit. It is a set of security infrastructure components for product developers. It provides the underlying bedrock upon which full managed single sign-on products can be built.

SESAME is similar to Kerberos, but has a lot of extensions to Kerberos. one important extension is it supports role based access control using PAS (Privilege Arribute Server)

• Domain Security Server (DSS) consists of 3 online security servers supported on the same machine.

• Authentication Server (AS)
• Priviledge Arrtibute Server (PAS)
• Key Distribution Server (KDS)

• Public Key Supporting Server.

• Local Registration Authroty (LRA)
• Certificate Authroty Agent (CAA)
• Off-line Certificate Authrotity (CA).

• 3 generic security components:

• Public Key Management (PKM)
• Cryptographic Support Facility (CSF)
• Audit Facility

• Target Components:

• Target Secure Assiciation Control Manager (SACM).  It is the interface with target application and its security servers.
• PAC Validation Facility. It is used by SACM to validate PAC, extract contents and keys.

• Basic Key
• temporary key between initiating machine and target application's PVF.
• for protecting the PAC.
• Dialogue Key
• derive from the basic key
• temporary key between initiator and target SACMs.
• to protect user operation subsequent to PAC transmission.
• have seperate keys for integrity and confidentiality protection.

3. Walk-through of SESAME

Client Machine Interactions:

1. The User Sponsor invokes the APA Client through an authentication API to authenticate the person, who specifies the name of the role he wishes to use. The APA invokes the authentication API which generates a Kerberos conformant authentication request to the AS.
2. The AS builds a PAS ticket and returns it along with control data to the APA Client. For password based authentication this is a pure Kerberos action. The APA client stores the PAS ticket in a cache and returns to the User Sponsor. For private-key based authentication, a message is also returned to authenticate the AS to the user.
3. The APA client requests an initial PAC from the PAS. This is done by invoking the initiator's SACM component through GSS-API. The request message includes username, role name and PAS ticket,
4. The PAS decrypted the PAS ticket to get the key used to protect the dialogue between SACM and the PAS. The PAS reads the user name and the role name and verifies that the user is allowed to exercise that role. If the role name which has been given is not allowed, the system default role is used instead. The role name is used to access the privilege and the target qualifier attributes associated with that role.
5. The PAS then builds a PAC and signs it with  its private key. Also it builds a KDS ticket and encrypts it with a secret key shared with the KDS. The PAS returns to SACM the PAC and the KDS ticket along with one or more optional Control Values (CVs) if the PAC is to be delegatable, and the Kerberos conformant control data accompanying the KDS ticket. This response is protected by the SACM/PAS basic key.
6. The initiator's SACM calls its KDS to request a basic key, BKip, for TA's PVF, using the KDS ticket obtained above. These exchanges are protected by the secret key returned by PAS. and included in KDS packet.
7. There are two cases:
• If TA is in the same domain as the initiator, Initiator SACM and the PVF shared the same KDS, so KDS can access the SMIB to get the name of TA's PVF and the names of the other applications that PVF serves. KDS then builds a services ticket for Initiator SACM to send to the target system. The ticket contains a basic ket BKip for conversing with TA's PVF and the TA's name. KDS accesses the SMIB using the PVF name, to get the PVF secret key to encrypt the ticket.
• If TA is in a different security domain, KDS works out the name of the KDS of TA's domain (KDS2), it then uses local PKM facility to get KDS2's public key which it uses to encrypt a dynamically generated symmetric key (DESK) which in turn is used to encrypt the Ticket for TA's PVF. The Ticket and the encrypted DESK are put into a separate interdomain construct which is signed using the KDS1's private key.
8. KDS return the Keying information and optional list of PVF application to the initiator SACM.
9. Initiator SACM extracts the basic key and encypt any CV's present with that key. SACM also adds a dialogue key package to the basic key package, using which, integrity and confidentiality dialogue keys DKIit and DKCit can be derived from the basic key. It then returns the client application a GSS token comprising PAC, the encrpted CV(s), the basic key package and the dialogue package , along with other administration information.
10. Client application sends GSS token to the target application.

11. The target application passes the received token to Target SACM, Target SACM passed it to its PVF for validation.
12. In the interdomain case, the PVF sends the basic key package to KDS2 for processing, KDS2 validates the signature of KDS1, decrypts the DESK using its private key, decrypts the Ticket and then re-encrypts the Ticket under the long term key it shares with the PVF and returns it to the PVF.
13. The PVF decrypts the Ticket and extracts BKip and TA's name. It checks the integrity of incoming message, checks the PAC is valid for TA. If all checks are successful, Dialogue keys DKIit and DKCit are caculated using BKip and the dialogue key package information. The PVF returns the PAC, the associated CVs, the privilege attributes and the dialogue keys to Target SACM.
14. SACM returns a security context handler to the server application.
15. The client and target application can interact with the dialogue confidential key.

Delegation Control

An initiator may not wish to delegate all his rights, and may also want to restrict the area within which PAC may be used. In SESAME, the CV/PV protection methods allows a PAC to be used by proxy.

• CV/PV pairs are generated by PAS. CV is randomly generated Control Value, PV (Protection Value) is a one-way function of CV.
• PV is stored in a protection method field in the PAC.
• CV is returned to the original initiaor encypted under the initiator/PAS basic key.
• The original initiator, and subsequently its valid delegates must prove knowledge of the CV for a particular PV.
• PAC may contain one or more target or delegate-target application or "Trust Group" names specifying which targets or delegate-targets the PAC is valid for.

• Heterogeneity. Kerberos aims specifically at UNIX system. Privilege Arrtribute Certificate conforms to ECMA and ISO/ITU-T standards which is independent of specific end-system representations but can mapped into them as appropriate in the receiving system.
• Public key support. Kerberos only support secret keys. SESAME support public key for validation and inter-realm security.
• SESAME uses role based distributed access control, with option delegation of access rights.
• SESAME uses the widely accepted Generic Security Service API (GSS-API). It is an Open System Solution.

https://www.cosic.esat.kuleuven.ac.be/sesame/