December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 1 Securely Available Credentials (SACRED) Protocol Framework, Draft Specification

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 2 Context Dear All, This is the proposed agenda for SACRED in San Diego 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 Welcome to - what we believe will be - a productive meeting in San Diego! -- Magnus Magnus Nyström RSA Security

December 14, 2000Securely 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

December 14, 2000Securely 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.

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

December 14, 2000Securely 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.

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 7 Client/Server Protocol client server connect --> 1) physical connect ) server authentication --> > 3) client authentication --> > 4) data exchange --> > <-- OK (+ connection dropped) 5) disconnect

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 8 Client/Server Protocol - GET client server connect -->... --> -->... --> -->... --> <-- 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")

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 9 Client/Server Protocol - PUT client server connect -->... --> -->... < GET cred-1 URL [Fingerprint]> --> < GET cred-2 URL [Fingerprint] > -->... --> <-- 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.

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 10 Client/Server Protocol - DELETE client server connect -->... --> -->... --> -->... --> <-- 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.

December 14, 2000Securely 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

December 14, 2000Securely 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 ?

December 14, 2000Securely 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 adequate for now? Credential Format(s) Authentication Method(s) –User Authentication –Server Authentication Other ?

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 14 Contact Information Dale Gustafson Future Foundation, Inc. tel: Magnus Nystrom RSA Security, Inc. tel:

December 14, 2000Securely 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.

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 16 Strong Password Authentication Secure Remote Password Protocol

December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 17 Strong Password Authentication 1.Client sends Server her username, (e.g. carol). 2.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. 3.Client generates a random number a, 1 < a < n, computes her ephemeral public key A = g^a, and sends it to Server. 4.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. 5.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. 6.Both sides hash the exponential S into a cryptographically strong session key. 7.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. 8.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.