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