Given by Tom Haupt at ASC Gateway Project Dayton Ohio on January 7 1999. Foils prepared January 31 1999
Outside Index
Summary of Material
This is one of a set of presentations for a meeting at Dayton for ASC MSRC on Seamless Interface or Gateway Project |
This was a two day meeting truncated to the first day due to bad weather |
This talk gives security background for NPAC Middleware WebFlow activity |
Outside Index Summary of Material
Tom Haupt NPAC |
Data |
Encrypted data |
Digested data |
Signed data |
Enveloped data |
Signed-and-enveloped data |
arbitrary octet string, such as ASCII text file |
structured or unstructured |
interpretation is left to the application |
Encrypted data of any type |
No keys are provided |
Keys are assumed to be managed by other means |
Consists of
|
A recipient verifies the message by comparing the message digest to an independently computed message digest |
The encrypted digest for a signer is a digital signature on the content for that signer. |
Signed data:
|
Verification:
|
Construction
|
Verification
|
Construction:
|
As the result the message consists of
|
Verification
|
Is included in the signer certificate attached to the message (as a part of the signer info) |
Can be obtained from CA |
Sometimes it is posted (Web site, LDAP server,...) |
Kerberos is an authentication service developed at MIT. It's purpose is to allow users and services to authenticate themselves to each other. That is, it allows them to demonstrate their identity to each other, unequivocally (it is hoped). |
ftp |
rlogin |
Client Side |
Server Side |
User |
Keberized |
applications |
kinit |
userid |
session key encrypted |
with the user's password |
and |
ticket-granting ticket |
encrypted with |
KDC password |
Authentication: |
user must decrypt |
the session key |
The ticket includes: |
- session key |
- user name |
- IP address |
- service name |
- lifespan |
- timestamp |
and is encrypted with |
the service password |
TGT |
Client Side |
Service |
Request |
service ticket |
encrypted with |
the service password |
Authentication: |
TGC must decrypt TGT |
Session Key |
Client Side |
Service Ticket |
TGT |
Service Ticket |
and |
Authenticator |
one-time usable username & address |
encrypted with the session key |
Note: |
another copy of the session key is inside the encrypted ticket |
Ticket |
Authenticator |
Authentication: |
- the server decrypts the ticket |
- using recovered session key |
the server decrypts authenticator |
- username:address must match |
- the server checks expiration date |
Acknowledgment |
encrypted with |
the session key |
Authentication: |
The server knows the password, since it is capable to recover the session key from my ticket |
Encrypted |
data |
RFC 1508 RFC 2087 |
Provides security services to calling applications |
It allows communicating applications:
|
Is implemented atop alternative underlying cryptographic mechanisms. |
The application acquires a set of credentials |
A pair of communicating applications establish a joint security context using their credentials |
Per-message services are invoked to apply either:
|
At the completion of a communication session the peer application delete the security context |
The application's credentials vouch for its global identity, which may or may not be related to the local username under which it is running |
The security context is a pair of GASSAPI data structures that contain shared state information, which is required in order that per-message security services may be provided. |
The context initiator is authenticated to the responded, and may require that the responder is authenticated in turn. |
The initiator may optionally give the responder the right to initiate further security context (delegation). |
To establish and maintain the security context, some GSSAPI calls return a token data structure, which is a cryptographically protected opaque data type. The caller is responsible for transferring the token to the peer application, which should then pass it to a corresponding GSSAPI routine which will decode it and extract the information. |
The application transmitting a message calls a GSSAPI routine (sign or seal) to apply protection and send the result to the receiving application. |
The receiver will pass it to a corresponding GSSAPI routine (verify or unseal) to remove the protection and validate the data. |
CREDENTIAL MANAGEMENT |
GSS_Acquire_cred |
GSS_Release_cred |
GSS_Inquire_cred |
CONTEXT-LEVEL CALLS |
GSS_Init_sec_context |
GSS_Accept_sec_context |
GSS_Delete_sec_context |
GSS_Process_context_token |
GSS_Context_time |
PER-MESSAGE CALLS |
GSS_Sign |
GSS_Verify |
GSS_Seal |
GSS_Unseal |
SUPPORT CALLS |
GSS_Display_status |
GSS_Indicate_mechs |
GSS_Compare_name |
GSS_Display_name |
GSS_Import_name |
GSS_Release_name |
GSS_Release_buffer |
GSS_Release_oid_st |
Need to be updated for GASSAPI v2 |
Prepare slide with explanations |
RFC 1509 defines C bindings |
draft-ietf-cat-gssv2-javabind-00.txt defines Java bindings |
RFC1961: GSS-API Authentication Method for SOCKS Version 5 |
RFC1964: GSSAPI Keberos V5 mechanism augmented by draft-ietf-cat-krb5gss-mech2-02.txt: The Keberos Version 5 GSSAPI Mechanism |
RFC2025: The Simple Public-Key GSS-API Mechanism (SPKM) |
Globus SSLeay-GSSAPI |
Define tokens formats, encoding, error codes mappings, etc and occasionally semantics |
The SPKM allows both unilateral and mutual authentication to be accomplished without the use of secure timestamps |
The SPKM uses Algorithm Identifiers to specify various algorithms to be used by the communicating peers |
The SPKM allows the option of a true, asymmetric algorithm-based, digital signatures, rather than an integrity checksum based on a MAC computed with a symmetric algorithm (e.g., DES) |
SPKM data formats and procedures are designed to be as similar to those of the Keberos mechanism as is practical. This is done for ease of implementation in those environments where Keberos has already been implemented. |
(Simplified) |
can play both client and server
|
evolve continually
|
interaction are not well defined
|
are polymorphic (ideal for Trojan horses!) |
can scale without limit
|
are very dynamic |
Identification and authentication |
Authorization and access control |
Security auditing |
Security of communications
|
Non-repudiation
|
Administration |
Main security functionality
|
Security Functionality Options
|
Security Replaceability
|
Secure Interoperability
|
Security policies define:
|
A reference model describes how and where a secure system enforces security policies |
A security model normally defines a specific set of security policies (too restrictive!) |
The security reference model is a meta-policy because it is intended to encompass all possible security policies supported by the OMA (Object Management Architecture) |
The meta-policy defines abstract interfaces that are provided by the security architecture defined in CORBA security service. |
The model enumerates the security functions that a defined as well as the information available. |
The meta-policy provides guidance on the permitted flexibility of the policy definition. |
This is why the spec is so difficult to comprehend |
Secure Communications |
Authentication |
Client |
User |
Encryption |
Audit |
Authorization |
Server |
Encryption |
Credentials |
Object |
Adapter |
A principal is authenticated once by ORB and given a set of credentials, including one or more roles, privileges, and an authenticated ID. |
An authenticated ID is automatically propagated by a secure ORB; it's part of the caller context |
Principal |
Credentials |
Current |
Client |
Server |
set_credentials |
get_attributes |
authenticate |
No delegation
|
Simple delegation
|
Composite delegation
|
Client |
Target |
Client |
Target |
Client |
Target |
Client |
Target |
Object |
IIOP |
Based on a trusted ORB model: you must trust that your ORB will enforce the access policy on the server resource |
The ORB determines: if this client on - behalf of this principal - can do this operation on this object |
Server uses Access Control Lists (ACL) to control user access |
Principal |
Role |
Rights |
Operation |
Audit |
Non-Repudiation |
Encryption |
Security Domains |
Managing Security Policies |
Server Side
|
Client Side
|