DataPower Security Details: Crypto Objects and AAA DataPower Appliances Business Unit, AIM/SWG DataPower Security Details: Crypto Objects and AAA Jonathan Wenocur Confidential | June 20, 2006

Crypto Objects The main objects: Less used objects: Crypto Key (“key”) Crypto Certificate (“cert”) Crypto Identification Credentials (“identcred”, “idcred”) Crypto Validation Credentials (“valcred”) Crypto Profile SSL Proxy Profile Less used objects: Crypto Shared Secret Key (“sskey”) Crypto Firewall Credentials (“fwcred”)

Crypto Objects: Crypto Key A private key Configured from file on the flash PEM : password possible DER PKCS#8 : for private keys; password possible PKCS#12 : key and cert; contains PKCS#7 and PKCS#8; password possible Located in cert:, sharedcert: Protected directories: writable, not readable HSM key: located on HSM Virtual location “hsm:” Password-map : CLI only keygen

Crypto Objects: Crypto Certificate A public key Configured from file PEM DER PKCS#7 PKCS#12 : password possible (contains keys and certs) Located in cert:, sharedcert: Protected directories: writable, not readable File may contain private keys too so that’s why protected pubcert: Publicly available CA certificates Ignore Expiration dates Useful with large valcreds so valcred object stays “up”

Crypto Objects: Crypto Identification Credentials Matching keypair: key + cert == private key + public key Verified at configuration time SSL “identity” sent to peer CA list Starting to use for other crypto operations (sign, encrypt)

Crypto Objects: Crypto Validation Credentials Set of certificates for validating another certificate Validation modes: “Match exact or immediate issuer” “Full certificate chain checking (PKIX)” : SSL only Use Certificate Revocation List (CRL) or not Used anywhere a certificate is received and trust must be checked SSL Digitial signature verification AAA

Crypto Objects: Crypto Profile Describes SSL configuration for one side of the connection (server or client) Identity to use (idcred) valcred for validating peer’s identity Ciphersuite Send peer client CA list Other options, such as SSL version Send Client CA list: for mutual authentication Reusable (though no one seems to do this)

Crypto Objects: SSL Proxy Profile “Top-level” crypto object Describes overall SSL connection Reverse  server Forward  client Two-way  client and server SSL session caching controls Server is a pool Client only needs to be on/off since 1:1 with destinations

Crypto Objects: Basic Object Hierarchy

Crypto Objects: Crypto Shared Secret Key Symmetric crypto key Configured from file on the flash String: 0xABCD1234… Justabunchoftext… Located in cert:, sharedcert: Protected directories: writable, not readable Not used much

Crypto Objects: Crypto Firewall Credentials Limits which keys, certs, and sskeys an xmlfirewall uses List of keys List of certs List of sskeys Less important now that there are configuration domains

Crypto Objects: Where Objects are Used SSL, obviously Sign Key : used for signature generation Cert : part of message so receiver can verify the signature Verify Cert : if a cert isn’t specified in the message Valcred : validate the signer’s certificate Encrypt Cert : used for encryption of ephemeral key, and placed in message Decrypt Key : used for decrypting ephemeral key, looked up by matching cert in message to cert in idcred and using corresponding key, or specifying directly AAA : validating signers’ certs, signing SAML Assertions, etc

AAA: The 7 Stages AU Cache Extract Identity (EI) Authenticate (AU) Map Credentials (MC) Authorize (AZ) Audit/Post- Processing (PP) Extract Resource (ER) Map Resource (MR) AZ Cache

AAA: Data Passed Between Stages Input and output XML nodesets XML API for each stage Allows custom processing stylesheets Custom-AAA-Processing.pdf Viewable in Probe Example EI from Probe: <identity> <entry type="http-basic-auth"> <username>fred</username> <password sanitize="true">fred</password> <configured-realm>login</configured-realm> </entry> </identity>

AAA: Writing Custom Stylesheets Use “API” of input and output nodesets Example custom EI stylesheet: <?xml version="1.0"?> <xsl:stylesheet version="1.0“ xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="text"/> <xsl:template match='/'> <xsl:if test="count(//fred/flintstone) > 0"> <username>fred</username> <password>flintstone</password> </xsl:if> </xsl:template> </xsl:stylesheet>

AAA: Extension Functions Some DataPower XSLT extensions which may be useful when writing custom stylesheets: dp:auth-info() dp:get-cert-details() dp:get-cert-issuer() dp:get-cert-serial() dp:get-cert-subject() dp:ldap-authen() And many more!

AAA: AU and AZ caching By default AU and AZ results are cached Cache key based on entire aaapolicy plus relevant data Sometimes tricky to avoid false hits Same underlying caching mechanism as document cache

AAA: Benchmarking Currently have no benchmarks Answer the question: “What is the pure overhead of running AAA?” Compare 2 scenarios: 1) unprocessed tiny message in loopback using persistent connections should get 20,000 transactions/sec 2) preprocessed tiny message with minimal AAA Other interesting scenarios: On-box (local AAAInfo file) vs off-box (LDAP, TAM, etc) AU and AZ Caching on/off

AAA: Examples Token translation: BasicAuth  UsernameToken EI: BasicAuth AU: AAAInfo file MC: none ER: URL MR: none AZ: anyauthenticated PP: generate UsernameToken