[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft charter - is it ok?
Stephen, et alia:
The new draft charter is acceptable to me. We could nit-pick things to
death, but I'm suggesting we don't. To me, this is fine as it is -
let's go with it.
Stephen Farrell wrote:
> I've tried to put together the comments on the draft charter and
> done a bit more editing. The quicker we get this agreed, (on the
> list, then with the ADs and IESG) the quicker we get to become
> a WG.
> If its fine as is, (which I hope will be the case), then we can have
> a very short charter discussion next week and use the time to get on
> with work (discussing requirements). I realise that we're very close
> to the meeting so we will have to at least have a short discussion
> over this, even if its perfect.
> Meanwhile, could those who are still on email and can live with
> the attached say so on the list, or suggest alternative text if
> they feel a real need for substantive changes.
> Securely Available Credentials (sacred)
> Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>
> Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>
> Security Area Director(s):
> Jeffrey Schiller <jis@xxxxxxx>
> Marcus Leech <mleech@xxxxxxxxxxxxxxxxxx>
> Security Area Advisor:
> Mailing Lists:
> General Discussion: ietf-sacred@xxxxxxx
> To Subscribe: ietf-sacred-request@xxxxxxx
> In Body: subscribe (In Body)
> Archive: http://www.imc.org/ietf-sacred/mail-archive/
> Web site: http://www.imc.org/ietf-sacred/
> Description of Working Group:
> PKI credentials typically consist of a public/private key pair
> and a corresponding certificate or certificate chain. They are
> stored on a desktop or laptop system as part of an application
> specific store. In general, support for credential export/import
> is uneven and end users need to get too involved with the mechanics
> of creating and maintaining their security profiles. Application
> specific stores also mean that user's cannot easily use the same
> credential in multiple applications on multiple devices, that is,
> today, credentials typically aren't portable.
> PKIs that use hardware tokens (e.g., smart cards, PCMCIA cards) do
> allow for portability of the user's credentials. However, many PKI
> systems use only software solutions, but would like to provide similar
> portability by making use of "soft tokens", or software files containing
> the information normally contained in hardware tokens. Ideally, users
> would be able to use a common set of security credentials with their
> desktop and laptop PCs, PDAs, cell phones, and other Internet-ready
> Even where real hardware tokens are used, there may also be substantial
> benefit derived from using soft token protocols in support of credential
> management functions such as, for example, installation, token (locked
> PIN) recovery, or token replacement.
> There are at least two possible solutions for providing credential
> mobility. The first solution 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
> A second solution involves the "direct" transfer of credentials from
> one device to another (e.g., from a mobile phone to a PDA). While
> 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 is possible that a single protocol can be developed for both types
> of solution, it is possible that two different protocols will 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 cut & paste attacks; attackers
> must not be able to successfully replace an entity's credentials at a
> credential server; etc. In general, the security provided by systems
> using soft tokens will be less than is provided in systems using actual
> hardware tokens, as the hardware tokens tend to be more resistant to
> improper inspection and modification. However, in many environments,
> the security offered by soft token protocols will be sufficient.
> Availability is also at a premium. Soft tokens must be available
> to many different types of client with different characteristics in
> terms of processing power, storage and network connectivity.
> The purpose of this working group is therefore to gather requirements
> for a solution or set of solutions beneficial to the Internet community,
> establish a framework for these, and to develop, adapt, or adopt the
> required protocols and credential formats necessary to achieve
> Goals & Milestone:
> Oct 00 Submit first draft of Requirements document
> Nov 00 Submit first draft of Frameworks document
> Dec 00 Submit second draft of Requirements document
> Submit second draft of Frameworks document
> Submit first draft of Protocol document (incl. PDU syntax)
> Mar 01 Requirements document to Informational RFC
> Frameworks document to Informational RFC
> Submit second draft of Protocol document
> Jun 01 Protocol document to Proposed Standard
> Stephen Farrell
> Baltimore Technologies, tel: (direct line) +353 1 647 7406
> 61 Fitzwilliam Lane, fax: +353 1 647 7499
> Dublin 2. mailto:stephen.farrell@xxxxxxxxxxxx
> Ireland http://www.baltimore.com