2.6.10 Securely Available Credentials (sacred)

Last Modifield: 08/02/2002

Chair(s):

Security Area Director(s):

Security Area Advisor:

Mailing Lists:

Description of Working Group:

Application specific stores also mean that users cannot easily use the same credential in multiple applications or on multiple devices. In effect, today, credentials aren't portable. PKIs that use hardware tokens (e.g., smart cards, PCMCIA cards) do allow for portability of the user's credentials, however, most systems do not use hardware tokens, but would benefit if similar portability features were available. Ideally, users would be able to use a common set of credentials with their desktop and laptop PCs, PDAs, cell phones, and other Internet-ready devices. Even where hardware tokens are used, there may also be substantial benefit derived from using credential portability protocols in support of management functions such as, for example, installation, token recovery (e.g. locked PIN), or token replacement.

There are at least two possible solutions for providing credential portability. The first involves the use of a "credential server". Credentials are uploaded to the server by one device (e.g., a desktop computer); they can be stored there and downloaded when needed by the same or a different device (e.g., a mobile phone, PDA, or laptop computer).

A second solution involves the "direct" transfer of credentials from one device to another (e.g., from a mobile phone to a PDA). Although there may be servers involved in the transfer, in security terms the transfer is direct - that is, there is no "credential server" that takes an active part in securing the exchanges.

While it might be possible that a single protocol can be developed for both types of solution, two different protocols may be needed: one for interacting with a "credential server"; and the other to facilitate the "direct" transfer of credentials.

Security is at a premium for this working group; only authorized clients should be allowed to download credentials; credentials must be protected against eavesdropping and active attacks; attackers must not be able to successfully replace an entity's credentials at a credential server; etc. In general, the security provided by such systems will be less than is provided in systems using hardware tokens, as the hardware tokens tend to be more resistant to improper inspection and modification. However, in many environments, the security offered will be sufficient.

Availability is also at a premium. Credentials must be available to many different types of client with different characteristics in terms of processing power, storage and network connectivity.

The working group will produce:

1) An informational document(s) describing and identifying the detailed requirements for any protocol in this area, along with an architectural view of any such protocol.

2) A standards-track document(s) describing the details of the adopted or developed protocol.

The WG will specifically take into account the requirements of the IPSRA WG, and the protocols selected by this WG should provide a solution for a subset of those requirements.

Goals and Milestones:

Internet-Drafts:

Request For Comments:

SACRED - 55th IETF, ATLANTA

Meeting Chairs:  Magnus Nyström, RSA Security, and Stephen Farrell, 
Baltimore.

INTRODUCTION

Magnus started the meeting by reviewing the objectives of this working 
group, and the objectives of this session.  He then summarized the 
agenda, which was as follows:

-Introduction, agenda walkthrough, WG status - Magnus Nyström
-Protocol draft - Stephen Farrell
-Timeline
-Any Other Business

Since there were no objections to the proposed agenda, Magnus started with 
the WG status:

-The Framework ID is now at the IESG. Final issues were resolved earlier 
this fall and the document was submitted to the IESG on September 30.

-The Protocol ID is in its 5th iteration, and with the exception of one 
recently discovered issue, only minor editorial matters remain.

PROTOCOL ID: (S. Farrell)

-Issues remaining: edits rejected on the mailing list, some 
clarifications, and binding of separate authentications.

-Upload response: Agreement not to make use of an UploadResponse 
message, but retain current text requiring clients to download (to ensure a 
fresh copy) before modifying.

-Bob Morgan to add text on the SASL authorization ID issue (needed for 
conformance with RFC 2222).

-Compound authentication issue (see
 draft-puthenkulam-eap-binding-00.txt): Farrell: If the same 
digest-md5 password is used both for sacred and non-TLS HTTP, you have 
problems, the problem is that the web server can be spoofed by the 
attacker, and digest-md5 is a shared secret approach
  Larry Greenfield: Is there even a need to consider this? You should not 
reuse credentials. If the client is going to use the same password with 
multiple servers, then it has to take the same precautions with the 
server and the certificate server. 
  Farrell: Ok, not really a man-in-the-middle attack, but still a 
potential problem. We have a couple of options to address this. let's 
discuss after the meeting.

-Timeline: Will try to issue -05 later this week

-Marshall Rose: Did Manning ever come back with the exact issue he had with 
regards to the BEEP tuning? Farrell: no.

CONCLUDING

-Magnus: Suggested schedule: Framework already submitted to IESG, right 
after this meeting, produce -05 and do WG last-call. We plan on going to 
IESG at year's end. After that, let's talk about 
implementation/interop testing. Unless we hear otherwise, this group will 
therefore become dormant until there's time to move the protocol 
document to Draft Standard (after interop testing). Straw poll: How many 
intend or plan to implement the SACRED protocol? 3-4 hands shown.

-Magnus: We also have the Peer-to-Peer use case in our charter, but no work 
has been done on it due to lack of interest. Farrell: If anyone would like to 
do the peer-to-peer use case, or a transport other than beep, speak up now! 
Jeff: I'm hoping that the p2p case will become more interesting to the 
IETF, e.g., for jxta soon. Bob Morgan: We can of course always use the 
mailing list to discuss new work? Magnus: Of course.

ADJOURN.

-- 

• Presentation 0
• Mangus Nystrom
• Stephen Farrell

• Presentation 1
• Stephen Farrell