IBM Notes and Domino Security

Strategy

Advisory Software Engineer/Chen Jing

Agenda

Strategic Themes

Tactical Results – Leveraging SAML

Tactical Results – Cryptographic Modernization and

Standards Support

Strategic Themes

Tactical Results:

Leveraging SAML

Domino web server accepting SAML

assertions

Domino web server configured for SAML authentication Internet site document or server document specifies SAML and the

type of session cookie to be used

– Single server session cookie (default)

– Web SSO Configuration: LTPA session cookie

Domino IdP catalog (idpcat.nsf)

Special database containing trusted identity providers and their

certificates

Should have very restrictive ACLs to prevent tampering

– That's why this information isn't in the directory!

idpcat configuration may override server configuration

Using SAML for Web SSO is just the beginning!

Now that Domino can be a SAML Service Provider (SP), what else

can we do?

SAML authentication to the Notes ID vault opens up new doors

Configuring the Notes ID vault to use SAML

The Notes ID vault administrator decides whether SAML

authentication to the vault is allowed.

– Edits the vault control document to name the approved idpcat configuration

database

iNotes mail server using Web Federated Login

iNotes web server authenticates the user via SAML

Secure email operations (decryption, signing, etc) requires the

user's Notes ID file

– This used to require a prompt for the user's Notes password...

– … except in IBM SmartCloud™ Notes, where we integrated more deeply

with the Notes ID vault

Download Notes ID file from the Notes ID vault using that same

SAML assertion

Notes Federated Login

Notes client uses SAML to fetch the user's ID file from the vault

ID file is stored in memory instead of being written to disk

The only “Notes password” is the IdP's password

– And SPNEGO/Kerberos to Microsoft® 's ADFS can eliminate that prompt as well

Works on Citrix® , Linux® , and Mac® as well as Windows®

– Removes most of the restrictions of NSLv3

– Requires Notes Standard client

Notes Federated Login is enabled for users via

security policy

Admin can also specify notifications for end users

Using SAML in the Notes Standard client

Notes Federated Login

SAML SSO across IBM

SmartCloud for Social Business

Sidebar plugin SSO

Embedded or launched browser

SSO

Controlled via accounts

– Can be managed centrally by

adminstrators

Tactical Results:

Cryptographic Modernization

and

Standards Support

What is FIPS 140-2?

Federal Information Processing Standard 140-2

US Federal standard for certification of cryptographic libraries

The most boring slide in this presentation

Is FIPS 140-2 necessary for good security?

FIPS 140-2 is not a guarantee of good security

– FIPS 140-2 only certifies cryptographic libraries

– Applications using FIPS 140-2 certified cryptographic libraries can still make

mistakes

It's hard to follow a specification that you predate!

– The techniques used by Notes/Domino were visionary in their time

– No known weaknesses in the encryption algorithms used by “classic”

Notes/Domino

– Started phasing in support for larger key sizes and newer algorithms in ND6

Added support for IBM Crypto for C (ICC) in 8.0.1

Upgrading from ICC to GSKit-Crypto 8.0 in 9.0

The FIPS 140-2 certified cryptographic library is used for AES, SHA,

and 1024+ bit RSA

– The “legacy” RSADSI library is used for most other algorithms, and for all

algorithms on platforms without a newer library

Platform Support – IBM Crypto for C (ICC)

Platform Support – IBM Crypto for C (ICC)

Platform Support – GSKit-Crypto 8.0

Protocol Support Continues

Upgrading protocols to use cryptographic algorithms approved by

FIPS 140-2

– AES, 1024+ bit RSA, SHA-1, and SHA-2

Old News

– User and Server Key Rollover (7.0)

– Certifier Key Rollover (8.0)

– AES for document and mail encryption (8.0.1)

– AES and SHA-1 for ID file encryption (8.0.1)

– SHA-1 for http password hashing with AtPassword3 (8.0.1)

– LtpaToken2 (8.0)

– Notes ID vault (8.5)

What's coming in 9.0?

– SHA-2 for ID file encryption

– AES and SHA-2 for S/MIME and X.509 certificates

– Accept SHA-2 for http password hashing (backwards compatibility)

– Credential Store (credstore.nsf)

– TLS

Notes ID File encryption upgrades

1.0

– 64 bit RC2 with MD(*)

6.0

– 128 bit RC2 with salted MD(*)

8.0.1

– 128 bit AES with iterated salted SHA-1

– 256 bit AES with iterated salted SHA-1

9.0

– 128 bit AES with iterated salted SHA-256

– 256 bit AES with iterated salted SHA-512

Admins can easily make ID files more secure

“Mandated encryption standard”

silently upgrades user ID files

“Allowed encryption standards”

limits options in the Change

Password dialog

Using SHA-2 based X.509 certificates

Import, manage, and use normally

Also supported on smartcards

Using SHA-2 and AES with S/MIME

Configuring Notes to use SHA-2 for S/MIME

signing

The following Notes.ini must be present - SMIME_CAPABILITIES_SEND

– Possible hash values: SHA_256, SHA_384, or SHA_512

– Example: SMIME_CAPABILITIES_SEND=SHA_256

– Admins can create desktop policies to set Notes.ini variables on client

systems

– With that Notes.ini set, the sender's default SMIME signing algorithm is

whatever flavor of SHA-2 in the .ini.

• In the example above SHA-256 would be used

– Release 9.0 will need this Notes.ini set to default to sending SHA-2 digested

signed SMIME.

Configuring Notes to use AES for S/MIME

encryption

The following Notes.ini must be present - SMIME_CAPABILITIES_SEND

– Possible encryption values: AES_128, AES_192, or AES_256

– Example: SMIME_CAPABILITIES_SEND=AES_128

– Admins can create desktop policies to set Notes.ini variables on client

systems

– With that Notes.ini set, the sender's default SMIME encryption algorithm is

whatever flavor of AES in the .ini.

• In the example above 128 bit AES would be used

– Release 9.0 will need this Notes.ini set to default encryption algorithm for

sending encrypted S/MIME.

– When configuring both SHA-2 and AES use a semicolon separator:

• SMIME_CAPABILITIES_SEND=AES_128;SHA_256

HTTP password hashing with @Password3

If you need to store passwords in names.nsf instead of using SAML,

Directory Assistance (DA), or SPNEGO/Kerberos...

– @Password introduced in v4.5

• Obsolete, deprecated.

– @Password2 introduced in v4.6

• Significantly enhanced security

– @Password3 introduced in 8.0.1 / 8.5

• Uses iterated salted SHA-1

• Much slower by design; test in your own environment before deploying

• New in 9.0: latent support for iterated salted SHA-2.

TLS support via IBM HTTP Server (IHS)

TLS support available via an install-time option that configures Domino

to use IBM HTTP Server to service HTTP and HTTPS traffic

Encrypted Credential Store (credstore.nsf)

A new database for storing sensitive information

– Scoped to a single Domino cluster

ACL access to the database does not expose the encrypted data

– Data encrypted using a shared symmetric key (NEK) stored in the server ID file

– Only the programatic APIs can be used to access the plaintext data

New server console commands added to manage database and NEKs

OAuth

Additional Resources

http://www-10.lotus.com/ldd/dominowiki.nsf/dx/deploying-fips-140-2-

certified-id-and-document-encryption