Securely Available Credentials (SACRED)

1. Securely Available Credentials(SACRED) Protocol Framework, Draft Specification Securely Available Credentails (SACRED) - Framework Draft

2. Context Dear All, This is the proposed agenda for SACRED in San Diego. ------------------------------------------------------------ 1. Introduction, Agenda walkthrough and Working Group Status (5 min) WG Chairs 2. Requirements Draft discussion (35 min) A. Arsenault 3. Framework Draft discussion (30 min) D. Gustafson 4. Desirable properties for strong password-based credentials download protocols (15 min) R. Perlman 5. Authentication methods, actual protocol and credential formats - proposals and discussion (30 min) All - led by chairs 6. Wrap up (5 min) WG Chairs Documents which will be discussed under agenda item 2 and 3 are: draft-ietf-sacred-reqs-00.txt draft-ietf-sacred-framework-00.txt For agenda item 4 and 5, attendees are recommended to read RFC 2945. Welcome to - what we believe will be - a productive meeting in San Diego! -- Magnus Magnus Nyström RSA Security Securely Available Credentails (SACRED) - Framework Draft

3. Outline • Introduction • Network Architectures • Client/Server Protocol Exchanges • GET, PUT, DELETE • Credential Formats • PKCS#12, PKCS#15, … • Authentication • Server Authentication • Client Authentication (controlling access to the credential) • Credential User Authentication (eg., decrypting and using the credential) • Open Issues, Framework Draft Securely Available Credentails (SACRED) - Framework Draft

4. Introduction The SACRED Framework provides a high level description of the architectures and protocols used to exchange credentials: • Credentials may be used with, shared among a variety of Internet clients • Desktop / laptop PCs • PDAs • Mobile Phones • Two distinct network architectures for credential exchange: • Client / server • Peer-to-Peer • Open credential format (public/private key pairs, secret keys, x.509 ID certificates, attribute certificates, data) • Intent is to support several authentication methods with one method specified as mandatory. Securely Available Credentails (SACRED) - Framework Draft

5. Network Architecture: Client / Server Credential Storage • PKI Servers • - CA • - Directory • - Cert. Status • Timestamp Certification Authority / Directory Server Credential Server Internet Credential Users Server Administrators Securely Available Credentails (SACRED) - Framework Draft

6. Client/Server Protocol • The client/server protocol defines three basic operations (GET, PUT, DELETE) which can be used to perform the essential management operations: - create a new credential on the server - update an existing credential - delete an existing credential - change password (controls who can update / download a given credential) • Each security credential is an opaque (encrypted) data object with user specified format. Section 5 of the Framework draft describes several useful credential formats. One of these will be mandatory – all clients must support the manadatory format. No credential format is excluded. • There is no restriction on the data that may be included within a user credential or the credential storage format seen by the credential server. • There is no requirement that the server or server administrators be able to decrypt a user’s security credential. Securely Available Credentails (SACRED) - Framework Draft

7. Client/Server Protocol client server ------- -------- connect --> 1) physical connect --------------------------------------------------------------------- <-- < s_auth-0 > 2) server authentication < s_auth-1 > --> <-- < s_auth-2 > --------------------------------------------------------------------- < c_auth-0 > --> 3) client authentication <-- < c_auth-1 > < c_auth-2 > --> ... <-- < c_auth-n > --------------------------------------------------------------------- < cred-1 > --> 4) data exchange <-- < cred-1 URL, ID > < cred-2 > --> <-- < cred-2 URL, ID > ... --------------------------------------------------------------------- < done > --> <-- OK (+ connection dropped) 5) disconnect Securely Available Credentails (SACRED) - Framework Draft

8. Client/Server Protocol - GET client server ------- -------- connect --> ... < auth-0 > --> <-- < auth-1 > < auth-2 > --> ... <-- < auth-n > < cred-1 > --> <-- < cred-1 URL, ID > < cred-2 > --> <-- < cred-2 URL, ID > ... < done > --> <-- OK (+ connection dropped) Where, { auth-0 ... auth-x } is the method-dependent user authentication sequence. Cred-x URL is a locator that can be used to access the credential for download. Cred-x ID is an indicator that may be used for conditional download (e.g. http/1.1 "if modified-since") Securely Available Credentails (SACRED) - Framework Draft

9. Client/Server Protocol - PUT client server ------- -------- connect --> ... < auth-0 > --> <-- < auth-1 > < auth-2 > --> ... <-- < auth-n > < GET cred-1 URL [Fingerprint]> --> <-- < GET response 1 (credential-1) > < GET cred-2 URL [Fingerprint] > --> <-- < GET response 2 (credential-2) > ... < done > --> <-- OK (+ connection dropped) where, { auth-0 ... auth-x } is a method-dependent user authentication sequence. cred-x URL is a locator for a specific credential. Each download request may be conditional. Securely Available Credentails (SACRED) - Framework Draft

10. Client/Server Protocol - DELETE client server ------- -------- connect --> ... < auth-0 > --> <-- < auth-1 > < auth-2 > --> ... <-- < auth-n > < DEL cred-1 URL > --> <-- < cred-1 deleted > < DEL cred-2 URL > --> <-- < cred-2 deleted > ... < done > --> <-- OK (+ connection dropped) where, { auth-0 ... auth-n } is a method-dependent user authentication sequence. cred-x URL is a locator for a specific credential to be deleted. Securely Available Credentails (SACRED) - Framework Draft

11. Credential Formats The Framework Specification describes two existing, standardized credential formats: • PKCS#12 • Contains public/private key pairs, x.509 certificates, and arbitrary secrets • ASN.1 encoding • Several encryption methods (password-based, other) • PKCS#15 • Public/private key pairs, secret keys, certificates, attribute certificates, other data • ASN.1 encoding • Password-based encryption method Securely Available Credentails (SACRED) - Framework Draft

12. Authentication Methods Intent is to support several different user and server authentication methods (at least one authentication method will be mandatory): • User name and password • One-time password (OTP) • Strong password • HTTP over TLS • server authentication • remote client authentication • Other ? Securely Available Credentails (SACRED) - Framework Draft

13. Open Issues • Peer-to-Peer protocol • Should { User Authentication Method + Data } be linked to: • a specific credential • a specific user • Is the triplet <PUT, GET, DELETE> adequate for now? • Credential Format(s) • Authentication Method(s) • User Authentication • Server Authentication • Other ? Securely Available Credentails (SACRED) - Framework Draft

14. Contact Information Dale Gustafson Future Foundation, Inc. tel: +1 651-452-8369 email: dale.gustafson@bpsi.net Magnus Nystrom RSA Security, Inc. tel: +46 8 725 0900 email: magnus@rsasecurity.com Securely Available Credentails (SACRED) - Framework Draft

15. Example: Strong Password Authentication using SRP There are numerous strong-password algorithms that could be used. The description below is an excerpt from the SRP home page, one of several candidate methods. --------------------------------------------------------------------------------------------------------------------------------------------- SRP is a secure password authentication protocol. It solves the problem of authenticating clients to servers securely, in cases where the client must memorize a small secret (like a password) and carries no other secret information, and where the server carries a verifier which allows it to authenticate the client but which, if compromised, would not allow someone to impersonate the client. Many password authentication solutions claim to solve this exact problem, and new ones are constantly being proposed. Although one can claim security by devising a protocol that avoids sending the plaintext password unencrypted, it is much more difficult to devise a protocol that remains secure when: • Attackers have complete knowledge of the protocol. • Attackers have access to a large dictionary of commonly used passwords. • Attackers can eavesdrop on all communications between client and server. • Attackers can intercept, modify, and forge arbitrary messages between client and server. • A mutually trusted third party is not available. Securely Available Credentails (SACRED) - Framework Draft

16. Strong Password Authentication Secure Remote Password Protocol Securely Available Credentails (SACRED) - Framework Draft

17. Strong Password Authentication • Client sends Server her username, (e.g. carol). • Server looks up Client's matching password entry and fetches her password verifier v and her salt s. Server sends s to Client. Client computes her long-term private key x using s and her real password P. • Client generates a random number a, 1 < a < n, computes her ephemeral public key A = g^a, and sends it to Server. • Server generates his own random number b, 1 < b < n, computes his ephemeral public key B = v + g^b, and sends it back to Client, along with the randomly generated parameter u. • Client and Server compute the common exponential value S = g^(ab + bux) using the values available to each of them. If Client's password P, entered in Step 2, matches the one she originally used to generate v, then both values of S will match. • Both sides hash the exponential S into a cryptographically strong session key. • Client sends Server M[1] as evidence that she has the correct session key. Server computes M[1] himself and verifies that it matches what Client sent him. • Server sends Client M[2] as evidence that he also has the correct session key. Client also verifies M[2] herself, accepting only if it matches Server's value. Securely Available Credentails (SACRED) - Framework Draft