1. SACRED REQUIREMENTS DOCUMENT Stephen Farrell, Baltimore Alfred Arsenault, Diversinet

2. GOALS OF THE SACRED WORKING GROUP Develop one or more solutions that allow for the secure transfer of credentials from one device to another. –Credentials can include: Private keys Trusted root keys etc.

3. GOALS (cont.) All solutions must fit a defined protocol framework All solutions and the framework must meet a common set of requirements agreed to by the WG SO AT THIS POINT WE NEED MORE PEOPLE TO REVIEW THE DOCUMENTS AND HELP PRODUCE AGREEMENT!

4. WHY ARE WE DOING THIS? “Making credentials securely available (in an interoperable fashion) will provide substantial value to network owners, administrators, and end users.” We expect SACRED solutions to be deployed to support the needs of these users, and of other working groups.

5. SACRED REQUIREMENTS TREE TBS by Al A.

6. SACRED DOCUMENT TREE REQUIREMENTS FRAMEWORK Potential solution 1 Potential solution n...

7. SACRED REQUIREMENTS DOCUMENT Available as draft-ietf-sacred-reqs-00.txt from the usual places Intended to specify the overall requirements for any/all SACRED solutions Two classes of possible solutions: –Use credentials server –Direct transfer

8. CREDENTIALS SERVER SOLUTIONS Credentials server: –sits in front of a repository where credentials can be securely stored for later retrieval –actively participates in transfer protocol Transfer is a two-step approach: –Device A to credentials server; followed by –Credentials server to Device B

9. ADVANTAGES & DISADVANTAGES OF CREDENTIALS SERVER APPROACH Advantages: –Conceptually simple solution –Provides secure storage for credentials –Can enforce uniform security policy Disadvantages: –Server might be expensive to maintain –Introduces a new point of vulnerability into system Credentials server must be trusted

10. DIRECT TRANSFER SOLUTIONS Credentials are transferred from one device to another without any intermediate device processing credentials –To intermediate devices, it’s “a blob of bits” to be transferred

11. ADVANTAGES & DISADVANTAGES OF DIRECT TRANSFER APPROACH Advantage: –Doesn’t require credentials server Disadvantages –Possibly more complex due to wide variety of devices & capabilities –Possibly more complex because devices may have to act like both clients and servers

12. THE CURRENT PROPOSED REQUIREMENTS Now we’ll go over the proposed requirements currently listed in the draft Note: you, the audience, are supposed to give feedback on these Proposed wording posted to the mailing list is the best kind of feedback But we’ll take any reasonable feedback we can get!

13. PROPOSED REQUIREMENTS ON THE FRAMEWORK F1. The framework MUST support both "credential server" and "direct" solutions. F2. The "credential server" and "direct" solutions SHOULD use the same technology as far as possible. F3. The framework MUST allow for protocols which support different user authentication schemes

14. PROPOSED FRAMEWORK REQUIREMENTS (cont.) F4. The details of the actual credential type or format MUST be opaque, that is, the protocol MUST NOT depend on the internal structure of any credential type or format F5. The framework MUST allow use of different transports.

15. PROPOSED REQUIREMENTS ON PROTOCOLS Vulnerabilities list –List of some of the vulnerabilities that a secure credential-transfer system should protect against –Should it stay in the draft? Should more be added General protocol requirements Credential-server protocol requirements Direct-transfer requirements

16. GENERAL PROTOCOL REQUIREMENTS G1. Credential transfer both to and from a device MUST be supported. G2. Credentials MUST never be present in cleartext at any device other than the end user's. G3. All transferred credentials SHOULD be authenticated in some way (e.g., digitally signed or MAC-ed). G4. All transferred credentials MUST be integrity protected in some way (e.g., digitally signed or MAC-ed).

17. GENERAL REQUIREMENTS (cont.) G5. The protocol MUST support a range of cryptographic algorithms, including: – symmetric and asymmetric algorithms – hash algorithms – MAC algorithms. G6. The protocol MUST support the use of various credential types and formats (e.g., X.509, PGP, PKCS12,...).

18. GENERAL REQUIREMENTS (cont.) G7. One mandatory to support credential format MUST be defined. G8. One mandatory to support user authentication scheme MUST be defined. G9. Credentials MAY be labelled with a text handle to allow the end user to select amongst a set of credentials or to name a particular credential. G10. Full I18N support is REQUIRED (via UTF8 support).

19. GENERAL REQUIREMENTS (cont.) G11. The protocol MUST be able to support privacy, that is, anonymity for the client. G12. Transferred credentials MAY incorporate timing information, for example a "time to live" value determining the maximum time for which the credential is to be usable following transfer/download.

20. CREDENTIAL-SERVER PROTOCOL REQUIREMENTS S1. Credential downloads (to an end user) and upload (to the credential server) MUST be supported. S2. Credentials MUST only be downloadable following user authentication. S3. It MUST be possible to ensure the authenticity of a credential during upload.

21. C-S REQUIREMENTS (cont.) S4. Different end user devices MAY be used to download/upload/manage the same set of credentials. S5. The credential server MUST NOT have easy access to the cleartext credentials. S6. Credential servers MUST be authenticated to the user for all operations except (possibly) download.

22. C-S REQUIREMENTS (cont.) S7. It MUST be possible to authenticate the credential server to the user prior to download (if the user is able to verify the authentication). S8. The user SHOULD only have to enter a single secret value in order to download and use a credential. S9. Sharing of secrets across multiple servers MUST be possible, so that penetration of some servers does not expose the private parts of a credential ("m-from-n" operation).

23. C-S REQUIREMENTS (cont.) S10. The protocol MUST support "away-from- home" operation, where the user enters both a name and a domain (e.g. RoamingStephen@ baltimore.ie) and the domain can be used in order to locate the user's credential server. S11. Users MUST be able to manage their credentials stored on the credential server. S12. The user MUST be able to retrieve a list of their credentials stored on a server; add credentials to the server; delete credentials from the server.

24. C-S REQUIREMENTS (cont.) S13. Client-initiated authentication information (e.g. password) change MUST be supported. S14. The user SHOULD be able to retrieve a list of accesses/changes to their credentials. S15. The credential server protocol MUST support user self-enrollment. –E.g., where a previously unknown user uploads his credential without requiring manual operator intervention. S16. The credential server protocol MUST NOT prevent bulk initializing of a credential server's repository.

25. DIRECT-TRANSFER PROTOCOL REQUIREMENTS D1. It SHOULD be possible for the receiving device to authenticate that the credential package indeed came from the purported sending device. D2. In order for a sender to know that a credential has been received by a recipient, it SHOULD be possible for the receiving device to send an acknowledgment of credential receipt back to the sending device, and for the sending device to authenticate this acknowledgment.

26. OPEN ISSUES Vulnerabilities Robustness Performance Bootstrapping Separation or not of : –user authentication –credential protection –specific credential formats

27. FUTURE PLANS Another draft (real soon now) based on feedback from the WG!