Full HTML for

Basic foilset Security Overview of MiddleWare(WebFlow) for Gateway

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

Table of Contents for full HTML of Security Overview of MiddleWare(WebFlow) for Gateway

Denote Foils where Image Critical
Denote Foils where Image has important information
Denote Foils where HTML is sufficient

1 Basic Security Concepts
2 Cryptographic Messages (as defined by PKCS#7)
3 Data
4 Encrypted data
5 Digested data
6 Signed data
7 Enveloped data
8 Signed-and-Enveloped data
9 Signed-and-Enveloped ...
10 Signed-and-Enveloped ...
11 Signer public key
12 Keberos
13 Keberos: Secret Keys
14 TGT: Ticket-Granting Ticket
15 Service Ticket
16 Service Request
17 Server Side Processing
18 Mutual Authentication
19 Transaction
20 GSS-API Generic Security Service Application Program Interface
21 Goals
22 Four Stages to Using the GSSAPI
23 Credentials
24 Security Context
25 Per-message services
26 GSSAPI calls
27 Language bindings
28 Mechanisms
29 Simple Public-Key GASS-API Mechanism (SPKM)
30 CORBA Security Service
31 Distributed Objects are less secure
32 Summary of Key Security Features
33 Conformance to CORBA Security
34 Security Policies
35 Security Reference Model
36 Meta-policy
37 CORBA security is built into ORB
38 Authentication
39 Privilege Delegation
40 CORBA access model
41 More ...
42 Orbacus implementation

Outside Index Summary of Material



HTML version of Basic Foils prepared January 31 1999

Foil 1 Basic Security Concepts

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Tom Haupt NPAC

HTML version of Basic Foils prepared January 31 1999

Foil 2 Cryptographic Messages (as defined by PKCS#7)

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Data
Encrypted data
Digested data
Signed data
Enveloped data
Signed-and-enveloped data

HTML version of Basic Foils prepared January 31 1999

Foil 3 Data

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
arbitrary octet string, such as ASCII text file
structured or unstructured
interpretation is left to the application

HTML version of Basic Foils prepared January 31 1999

Foil 4 Encrypted data

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Encrypted data of any type
No keys are provided
Keys are assumed to be managed by other means

HTML version of Basic Foils prepared January 31 1999

Foil 5 Digested data

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Consists of
  • content of any type
  • a message digest of the content
  • digest algorithm used
A recipient verifies the message by comparing the message digest to an independently computed message digest

HTML version of Basic Foils prepared January 31 1999

Foil 6 Signed data

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
The encrypted digest for a signer is a digital signature on the content for that signer.
Signed data:
  • content of any type
  • message digest encrypted with the signer private key
  • digest algorithm used
Verification:
  • decrypt the digest using the signer public key (authentication)
  • generate new message digest
  • compare the two versions (integrity)

HTML version of Basic Foils prepared January 31 1999

Foil 7 Enveloped data

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Construction
  • generate at random a new key
  • encrypt the data (of any type) using this key
  • encrypt the key with the recipient public key
Verification
  • decrypt the key using the private key (authentication)
  • decrypt the contents using the recovered key (privacy)

HTML version of Basic Foils prepared January 31 1999

Foil 8 Signed-and-Enveloped data

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Construction:
  • generate at random a content-encryption key
  • encrypt the key with the recipient public key
  • compute message digest
  • encrypt the digest with the signer's private key
  • encrypt the result with the content-encryption key
  • encrypt the content with the content-encryption key
  • add digest algorithm info

HTML version of Basic Foils prepared January 31 1999

Foil 9 Signed-and-Enveloped ...

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
As the result the message consists of
  • encrypted content
  • encrypted content-encryption key
  • double encrypted message digest
  • digest algorithm used

HTML version of Basic Foils prepared January 31 1999

Foil 10 Signed-and-Enveloped ...

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Verification
  • using her private key the recipient recovers the content-encryption key (recipient authentication)
  • using the recovered key she decrypts the message (privacy) and the message digest
  • she decrypts the message digest again using the signer public key (signer authentication)
  • she generates a new message digest and compare it with the decrypted one (integrity)

HTML version of Basic Foils prepared January 31 1999

Foil 11 Signer public key

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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,...)

HTML version of Basic Foils prepared January 31 1999

Foil 12 Keberos

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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).

HTML version of Basic Foils prepared January 31 1999

Foil 13 Keberos: Secret Keys

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
mail
print
ftp
rlogin
Client Side
Server Side
User
Keberized
applications

HTML version of Basic Foils prepared January 31 1999

Foil 14 TGT: Ticket-Granting Ticket

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 15 Service Ticket

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
TGT
Client Side
Service
Request
service ticket
encrypted with
the service password
Authentication:
TGC must decrypt TGT

HTML version of Basic Foils prepared January 31 1999

Foil 16 Service Request

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 17 Server Side Processing

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 18 Mutual Authentication

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Acknowledgment
encrypted with
the session key
Authentication:
The server knows the password, since it is capable to recover the session key from my ticket

HTML version of Basic Foils prepared January 31 1999

Foil 19 Transaction

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Encrypted
data

HTML version of Basic Foils prepared January 31 1999

Foil 20 GSS-API Generic Security Service Application Program Interface

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
RFC 1508 RFC 2087

HTML version of Basic Foils prepared January 31 1999

Foil 21 Goals

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Provides security services to calling applications
It allows communicating applications:
  • to authenticate the user associated with another application
  • to delegate rights to another application
  • to apply security services such as confidentiality and integrity on a per-message basis
Is implemented atop alternative underlying cryptographic mechanisms.

HTML version of Basic Foils prepared January 31 1999

Foil 22 Four Stages to Using the GSSAPI

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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:
  • integrity and data origin authentication, or
  • confidentiality, integrity and data origin authentication
At the completion of a communication session the peer application delete the security context

HTML version of Basic Foils prepared January 31 1999

Foil 23 Credentials

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 24 Security Context

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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.

HTML version of Basic Foils prepared January 31 1999

Foil 25 Per-message services

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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.

HTML version of Basic Foils prepared January 31 1999

Foil 26 GSSAPI calls

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 27 Language bindings

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
RFC 1509 defines C bindings
draft-ietf-cat-gssv2-javabind-00.txt defines Java bindings

HTML version of Basic Foils prepared January 31 1999

Foil 28 Mechanisms

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 29 Simple Public-Key GASS-API Mechanism (SPKM)

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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.

HTML version of Basic Foils prepared January 31 1999

Foil 30 CORBA Security Service

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
(Simplified)

HTML version of Basic Foils prepared January 31 1999

Foil 31 Distributed Objects are less secure

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
can play both client and server
  • in client/server you trust the server, but not clients
evolve continually
  • objects delegate parts of its implementation to the other objects (also dynamically composed at runtime). Because of subclassing, the implementation of an object may change over time
interaction are not well defined
  • because of encapsulation, you cannot understand all the interactions between objects
are polymorphic (ideal for Trojan horses!)
can scale without limit
  • how do you manage access right to millions of servers?
are very dynamic

HTML version of Basic Foils prepared January 31 1999

Foil 32 Summary of Key Security Features

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Identification and authentication
Authorization and access control
Security auditing
Security of communications
  • mutual authentication, integrity and confidentiality
Non-repudiation
  • to protect against attempts to falsely deny the receiving or sending of the data)
Administration

HTML version of Basic Foils prepared January 31 1999

Foil 33 Conformance to CORBA Security

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Main security functionality
  • Level 1: for application unaware of security
  • Level 2: allows applications to control the security provided at object invocation
Security Functionality Options
  • non-repudiation is optional
Security Replaceability
  • ORB does not include security specific code
Secure Interoperability
  • Supports SECIOP (secure GIOP/IIOP)

HTML version of Basic Foils prepared January 31 1999

Foil 34 Security Policies

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Security policies define:
  • Under what conditions active entities may access objects
  • What authentication of users is required to prove who they are, what can they do, and whether they can delegate their rights
  • The security of communications
  • Accountability

HTML version of Basic Foils prepared January 31 1999

Foil 35 Security Reference Model

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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)

HTML version of Basic Foils prepared January 31 1999

Foil 36 Meta-policy

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 37 CORBA security is built into ORB

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Secure Communications
Authentication
Client
User
Encryption
Audit
Authorization
Server
Encryption
Credentials
Object
Adapter

HTML version of Basic Foils prepared January 31 1999

Foil 38 Authentication

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 39 Privilege Delegation

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
No delegation
  • The intermediary uses its own credentials
Simple delegation
  • The intermediary impersonate the client
Composite delegation
  • The intermediary uses both
Client
Target
Client
Target
Client
Target
Client
Target
Object
IIOP

HTML version of Basic Foils prepared January 31 1999

Foil 40 CORBA access model

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
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

HTML version of Basic Foils prepared January 31 1999

Foil 41 More ...

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Audit
Non-Repudiation
Encryption
Security Domains
Managing Security Policies

HTML version of Basic Foils prepared January 31 1999

Foil 42 Orbacus implementation

From Security Overview of MiddleWare(WebFlow) for Gateway ASC Gateway Project Dayton Ohio -- January 7 1999. *
Full HTML Index
Server Side
  • setting certificate
  • defining lists of ciphers
  • determining peer identity (access to Current)
Client Side
  • setting certificate
  • setting policies
  • determining server identity

© Northeast Parallel Architectures Center, Syracuse University, npac@npac.syr.edu

If you have any comments about this server, send e-mail to webmaster@npac.syr.edu.

Page produced by wwwfoil on Sun Jan 31 1999