From owner-ietf-sacred Thu Jul 6 08:05:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23042 for ietf-sacred-bks; Thu, 6 Jul 2000 08:05:59 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23037 for ; Thu, 6 Jul 2000 08:05:57 -0700 (PDT) Received: by balinese.baltimore.ie; id QAA16562; Thu, 6 Jul 2000 16:07:22 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma016392; Thu, 6 Jul 00 16:06:29 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA15011; Thu, 6 Jul 2000 16:06:29 +0100 Message-ID: <3964A078.7B519536@baltimore.ie> Date: Thu, 06 Jul 2000 16:06:32 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: xme , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: Getting started... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All, Paul Hoffman (thanks again for hosting this Paul) tells me that we've now got a reasonable set of people subscribed, so let's start. I guess I'd like to call for a couple of things:- - reaction to/comments on the strawman charter - discussion on requirements - sharing information on relevant technology Specific issues we'd like to encourage discussion about include:- - what are the most important use cases? - how "strong" does the authentication have to be? - what credential formats are most important? - what transport(s) should be used for such a protocol? Right now, our goal should be to get some common understanding of the problem area and some of the existing solutions, and to get as far as we can with the charter before Pittsburgh. So, off we go. Who's on first? Stephen & Magnus. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Jul 10 12:04:42 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA07459 for ietf-sacred-bks; Mon, 10 Jul 2000 12:04:42 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07455 for ; Mon, 10 Jul 2000 12:04:40 -0700 (PDT) Received: from bpsi.net (port423.bpsi.net [209.54.245.223]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id OAA08163; Mon, 10 Jul 2000 14:06:14 -0500 (CDT) Message-ID: <396A1E46.3E60C42A@bpsi.net> Date: Mon, 10 Jul 2000 14:04:38 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Roaming Credentials List CC: stephen.farrell@baltimore.ie Subject: Re: roaming credentials (sacred) References: <3960BAD3.7065EF13@baltimore.ie> Content-Type: multipart/alternative; boundary="------------2AE0302A45106742F667B4C9" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------2AE0302A45106742F667B4C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Some initial comments. When I read Stephen's write-up to the PKIX list I thought that a credential server might be just what is needed to help make existing PKI-based secure applications more "deployable and manageable". This may well be true both for networks or user communities that use software encryption and those that have elected to employ smart cards for optimum security profile portability and signing key protection. A couple of additional comments, inline. Best Regards, Dale Gustafson Stephen Farrell wrote: > Hi All, > > I put up a slide in Adelaide about roaming credentials and it > looks like we're on for a BOF in Pittsburgh (date TBD). The > strawman charter/BOF description is attached. So, if you're > interested then subscribe to the list and let's see how much > progress we can make prior to Pittsburgh. > > Paul Hoffman has kindly agreed to host the mailing list which > he'll open for postings in a day or two, as soon as subscribing > is seen to be working without problems, (but you can subscribe > right now). Paul's also hosting the web site at: > > http://www.imc.org/ietf-sacred > > If you have any questions in the meantime, feel free to > mail Magnus and/or me directly. > > Regards, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com > > Strawman charter for Securely Available Credentials (sacred) WG: > ================================================================ > > Working Group name: Securely Available Credentials (sacred) > > Chairs (suggested): Stephen Farrell, Baltimore Technologies > , and > Magnus Nystrom, RSA Security Inc. > > > Area: Security > > Area Directors: Jeffrey Schiller > Marcus Leech > > Resp. Area Director: TBD > > Mailing list: ietf-sacred@imc.org > > Web Site: http://www.imc.org/ietf-sacred/ > > Descr. of WG: > > A nice feature of smart-card based PKIs, in addition to the security > offered by the cards themselves, is the "free-seating solution," or > the portability of user's credentials. In order to provide a similar > solution or service to environments where security is based on pure > software implementations or so-called "soft tokens" (a.k.a. "virtual > smart cards," software files containing information normally stored > on smart cards) some kind of credential store from which users can > download their soft-tokens, using some specified protocol is > required. This protocol will provide mobility for credentials. User credentials today typically consist of a public/private key pair and a corresponding x.509 certificate or certificate chain. They are stored on a desktop or laptop system as part of the browser's key pair / certificate store (which is optionally password protected). Each key pair / certificate can be backed up to disk within an encrypted PKCS#12 file (e.g., a basic password encrypted file) in support of encryption key recovery, etc. All functions can be made to work but, in general, browser support for credential export/import is uneven and the end user needs to get too involved with the mechanics of creating and maintaining his/her security profile (this is especially true for dual-key browser configurations that use one key for encryption and a second for digital signature operations). Hopefully, roaming credentials will provide a basis for extending existing capabilities such that: - user credentials can be accessed remotely by the authorized user - user credentials can be fully protected from unauthorized disclosure - authorized users can be clearly identified - credentials can be created by end users or by a server - credentials can be securely downloaded to a remote user - updated credentials can be securely uploaded from a remote user - credentials can be packaged (customized) for secure delivery to a specific device such as a physical smart card - credential management is more automated (from the user's perspective) > Such a protocol and specified data format might also allow an > individual user to have the same set of credentials on, e.g., her > mobile phone as in her desktop. Adding an upload protocol to the > solution means that it in principle would be possible to always have > the credential store up-to-date. > > Even in some cases where real smart cards are used, there may > be some benefit to using such a protocol - e.g. when a new card > is received, but "old" credentials should be used. If the cards > offered the appropriate install and delete interfaces, then the > credentials could be (securely) moved between cards. For a variety of very pragmatic reasons, smart cards are expensive to modify and, more importantly, it takes a long time to build and deploy updated cards / firmware. I would suggest we make provision for protocol options whereby individual vendors or vendor groups can add card-specific protocol variations (to credential servers and clients) such that existing and in-process card designs can be used. > Many desktop applications also require mobility of credentials, for > example to support some "kiosk" style operation, when a user > upgrades a PC, or when "hot-desking". It is sometimes required to > integrate such credential mobility with single-sign-on solutions. A > protocol that could be used in the smart card case, can also be > used to solve this case. > > Finally, some applications may benefit from the ability to migrate > credentials from a device to a smart card, in particular where > the smart card using device has limited user interface capabililies, > e.g. a mobile phone. > > Security is at a premium for this working group; only authorized > entities should be allowed to download credentials, credentials must > be protected against eavesdropping and cut & paste attacks; attackers > must not be able to succesfully replace an entities credentials at a > credential server; etc. > > Availability is also at a premium, a credential server must > be reachable from 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 beneficial to the Internet > community, establish a framework for such a solution, and to > develop or adopt the required protocols and credential formats. > > Goals & Milestone: > > (The timeline assumes that the WG is approved just after Pittsburgh.) > > 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 > > Jul 01 WG recharters if appropriate > > Outline BOF Agenda: > > - agenda bashing > - scene setting (some problems that might be solved) > - HTTP/SASL strawman > - > - WG charter discussion --------------2AE0302A45106742F667B4C9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

Some initial comments.  When I read Stephen's write-up to the PKIX list I thought that a credential server might be just what is needed to help make existing PKI-based secure applications more "deployable and manageable".  This may well be true both for networks or user communities that use software encryption and those that have elected to employ smart cards for optimum security profile portability and signing key protection.

A couple of additional comments, inline.

Best Regards,

Dale Gustafson
 

Stephen Farrell wrote:

Hi All,

I put up a slide in Adelaide about roaming credentials and it
looks like we're on for a BOF in Pittsburgh (date TBD). The
strawman charter/BOF description is attached. So, if you're
interested then subscribe to the list and let's see how much
progress we can make prior to Pittsburgh.

Paul Hoffman has kindly agreed to host the mailing list which
he'll open for postings in a day or two, as soon as subscribing
is seen to be working without problems, (but you can subscribe
right now). Paul's also hosting the web site at:

           http://www.imc.org/ietf-sacred

If you have any questions in the meantime, feel free to
mail Magnus and/or me directly.

Regards,
Stephen.

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Strawman charter for Securely Available Credentials (sacred) WG:
================================================================

Working Group name:      Securely Available Credentials (sacred)

Chairs (suggested):      Stephen Farrell, Baltimore Technologies
                         <stephen.farrell@baltimore.ie>, and
                         Magnus Nystrom, RSA Security Inc.
                         <magnus@rsasecurity.com>

Area:                    Security

Area Directors:          Jeffrey Schiller <jis@mit.edu>
                         Marcus Leech <mleech@nortelnetworks.com>

Resp. Area Director:     TBD

Mailing list:            ietf-sacred@imc.org

Web Site:                http://www.imc.org/ietf-sacred/

Descr. of WG:

A nice feature of smart-card based PKIs, in addition to the security
offered by the cards themselves, is the "free-seating solution," or
the portability of user's credentials. In order to provide a similar
solution or service to environments where security is based on pure
software implementations or so-called "soft tokens" (a.k.a. "virtual
smart cards," software files containing information normally stored
on smart cards) some kind of credential store from which users can
download their soft-tokens, using some specified protocol is
required. This protocol will provide mobility for credentials.

User credentials today typically consist of a public/private key pair and a corresponding x.509 certificate or certificate chain.  They are stored on a desktop or laptop system as part of the browser's key pair / certificate store (which is optionally password protected).  Each key pair / certificate can be backed up to disk within an encrypted PKCS#12 file (e.g., a basic password encrypted file) in support of encryption key recovery, etc.  All functions can be made to work but, in general, browser support for credential export/import is uneven and the end user needs to get too involved with the mechanics of creating and maintaining his/her security profile (this is especially true for dual-key browser configurations that use one key for encryption and a second for digital signature operations).

Hopefully, roaming credentials will provide a basis for extending existing capabilities such that:

- user credentials can be accessed remotely by the authorized user
- user credentials can be fully protected from unauthorized disclosure
- authorized users can be clearly identified
- credentials can be created by end users or by a server
- credentials can be securely downloaded to a remote user
- updated credentials can be securely uploaded from a remote user
- credentials can be packaged (customized) for secure delivery to a specific device such as a physical smart card
- credential management is more automated (from the user's perspective)
 

Such a protocol and specified data format might also allow an
individual user to have the same set of credentials on, e.g., her
mobile phone as in her desktop. Adding an upload protocol to the
solution means that it in principle would be possible to always have
the credential store up-to-date.

Even in some cases where real smart cards are used, there may
be some benefit to using such a protocol - e.g. when a new card
is received, but "old" credentials should be used. If the cards
offered the appropriate install and delete interfaces, then the
credentials could be (securely) moved between cards.

For a variety of very pragmatic reasons, smart cards are expensive to modify and, more importantly, it takes a long time to build and deploy updated cards / firmware.  I would suggest we make provision for protocol options whereby individual vendors or vendor groups can add card-specific protocol variations (to credential servers and clients) such that existing and in-process card designs can be used.
 
Many desktop applications also require mobility of credentials, for
example to  support some "kiosk" style operation, when a user
upgrades a PC, or when "hot-desking". It is sometimes required to
integrate such credential mobility with single-sign-on solutions. A
protocol that could be used in the smart card case, can also be
used to solve this case.

Finally, some applications may benefit from the ability to migrate
credentials from a device to a smart card, in particular where
the smart card using device has limited user interface capabililies,
e.g. a mobile phone.

Security is at a premium for this working group; only authorized
entities should be allowed to download credentials, credentials must
be protected against eavesdropping and cut & paste attacks; attackers
must not be able to succesfully replace an entities credentials at a
credential server; etc.

Availability is also at a premium, a credential server must
be reachable from 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 beneficial to the Internet
community, establish a framework for such a solution, and to
develop or adopt the required protocols and credential formats.

Goals & Milestone:

(The timeline assumes that the WG is approved just after Pittsburgh.)

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

Jul 01  WG recharters if appropriate

Outline BOF Agenda:

- agenda bashing
- scene setting (some problems that might be solved)
- HTTP/SASL strawman
- <other proposals>
- WG charter discussion

--------------2AE0302A45106742F667B4C9-- From owner-ietf-sacred Mon Jul 10 13:57:47 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA11116 for ietf-sacred-bks; Mon, 10 Jul 2000 13:57:47 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11112 for ; Mon, 10 Jul 2000 13:57:46 -0700 (PDT) Received: from johnhughes (d2-s53-149-telehouse.mistral.co.uk [195.184.228.149]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYLZ4WD; Mon, 10 Jul 2000 14:06:42 -0700 From: "John Hughes" To: "Ietf-Scared (E-mail)" Subject: Requirements Date: Mon, 10 Jul 2000 22:01:10 +0100 Message-ID: <001501bfeab1$fa34f9b0$1138d90a@johnhughes.cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Having some (limited :-) ) exposure to because of a few of our projects - let me list some of the issues that this WG will have discuss: ** Credential Repository If credentials are to be stored, then what form(s) should that repository be. If its an LDAP server then what object classes and attributes should be defined. ** Key Generation Model What key generation models should be supported: central, client or split key/dual key. Particularly if its a split key scheme how is the client informed of the location of the CA, without the client user having to use browser. Imagine a scenario when a RA created a credential with conf keys/cert generated centrally and then the credential is obtained by a client (for the first time) but a signature key pair/cert is needed. How does the client "know" where the CA is - one possibility is that the credential needs information as to its "local CA" , perhaps via an enhanced PSE. ** Client Pack some applications will require more than a credential in order for a client to be enabled, perhaps even the whole application! How far and how extensible should the standard be in this area. ** Credential Format What format should the credential take, should it be based on PKCS#12 or a PKCS#15 virtual token (or perhaps some other format). ** Credential Access Whether the credential is PKCS#12 or PKCS#15 based a PIN/Passphrase is required - how is this disseminated, perhaps out of band. Are there other techniques? John From owner-ietf-sacred Tue Jul 11 07:52:25 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA12143 for ietf-sacred-bks; Tue, 11 Jul 2000 07:52:25 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12138 for ; Tue, 11 Jul 2000 07:52:23 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA17584; Tue, 11 Jul 2000 15:54:13 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma017442; Tue, 11 Jul 00 15:53:24 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA21554; Tue, 11 Jul 2000 15:53:10 +0100 Message-ID: <396B34E8.7CB2D3C5@baltimore.ie> Date: Tue, 11 Jul 2000 15:53:28 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dale Gustafson CC: Roaming Credentials List , xme Subject: Re: roaming credentials (sacred) References: <3960BAD3.7065EF13@baltimore.ie> <396A1E46.3E60C42A@bpsi.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dale, > User credentials today typically consist of a public/private key pair > and a corresponding x.509 certificate or certificate chain. They are > stored on a desktop or laptop system as part of the browser's key > pair / certificate store (which is optionally password protected). Each > key pair / certificate can be backed up to disk within an encrypted > PKCS#12 file (e.g., a basic password encrypted file) in support of > encryption key recovery, etc. All functions can be made to work > but, in general, browser support for credential export/import is uneven > and the end user needs to get too involved with the mechanics of creating > and maintaining his/her security profile (this is especially true for > dual-key browser configurations that use one key for encryption and a > second for digital signature operations). That looks like useful text to include in the charter, was that what you intended? > > Hopefully, roaming credentials will provide a basis for extending > existing capabilities such that: > > - user credentials can be accessed remotely by the authorized user > - user credentials can be fully protected from unauthorized disclosure > - authorized users can be clearly identified > - credentials can be created by end users or by a server > - credentials can be securely downloaded to a remote user > - updated credentials can be securely uploaded from a remote user > - credentials can be packaged (customized) for secure delivery to a specific device such as a > physical smart card > - credential management is more automated (from the user's perspective) The above probably belongs in a requirements draft. Questions: - what constitutes an "updated credential"? Do we consider that a single credential is a container for say 10 PKCS#12's, or that that should be 10 different credentials? - what does "packaged" mean? If you mean the credential server auomatically changing the credential format then I don't see how that can work. If you mean that the credential server has to be credential-format indpendent then that's something we should discuss. > For a variety of very pragmatic reasons, smart cards are expensive to > modify and, more importantly, it takes a long time to build and deploy > updated cards / firmware. I would suggest we make provision for protocol > options whereby individual vendors or vendor groups can add card-specific > protocol variations (to credential servers and clients) such that existing > and in-process card designs can be used. I'm not clear about what you mean here, but I think I agree - can you give an example? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 07:59:25 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA12407 for ietf-sacred-bks; Tue, 11 Jul 2000 07:59:25 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12403 for ; Tue, 11 Jul 2000 07:59:23 -0700 (PDT) Received: by balinese.baltimore.ie; id QAA18768; Tue, 11 Jul 2000 16:01:13 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma018641; Tue, 11 Jul 00 16:00:14 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA21801; Tue, 11 Jul 2000 16:00:10 +0100 Message-ID: <396B368C.BBE93372@baltimore.ie> Date: Tue, 11 Jul 2000 16:00:28 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hughes CC: "Ietf-Scared (E-mail)" , xme Subject: Re: Requirements References: <001501bfeab1$fa34f9b0$1138d90a@johnhughes.cost.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi John, > ** Credential Repository > If credentials are to be stored, then what form(s) should that repository > be. If its an LDAP server then what object classes and attributes should be > defined. We do need to discuss if this is in scope or not. If we develop a protocol which isn't LDAP, then its not that clear that we need to worry about details of the repository. OTOH, if we use LDAP, then we need object classes etc. Do you think we should explicitly use LDAP? I would tend to think not, but am open to convincing. > ** Key Generation Model > What key generation models should be supported: central, client or split > key/dual key. Particularly if its a split key scheme how is the client > informed of the location of the CA, without the client user having to use > browser. Imagine a scenario when a RA created a credential with conf > keys/cert generated centrally and then the credential is obtained by a > client (for the first time) but a signature key pair/cert is needed. How > does the client "know" where the CA is - one possibility is that the > credential needs information as to its "local CA" , perhaps via an enhanced > PSE. I'd say we need to support both central and client, to the extent that we care. I think this translates to needing an upload and download so we don't explicitly talk about key generation. I'm not clear what you mean by "split" - care to elaborate? > ** Client Pack > some applications will require more than a credential in order for a client > to be enabled, perhaps even the whole application! How far and how > extensible should the standard be in this area. My guess is that we only deal with credentials. However, if the credential format allows you to specify your favorite drink then fine. > ** Credential Format > What format should the credential take, should it be based on PKCS#12 or a > PKCS#15 virtual token (or perhaps some other format). p#12 and p#15 are the obvious candidates for the MUST implement format. Are there additional ones to consider? > ** Credential Access > Whether the credential is PKCS#12 or PKCS#15 based a PIN/Passphrase is > required - how is this disseminated, perhaps out of band. Are there other > techniques? This is the nub of the problem we've to try solve. Be good if folks posted pointers to their favorite schemes. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 08:36:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA14610 for ietf-sacred-bks; Tue, 11 Jul 2000 08:36:32 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14603 for ; Tue, 11 Jul 2000 08:36:29 -0700 (PDT) Received: by balinese.baltimore.ie; id QAA24942; Tue, 11 Jul 2000 16:38:18 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma024924; Tue, 11 Jul 00 16:38:16 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA23397; Tue, 11 Jul 2000 16:38:16 +0100 Message-ID: <396B3F7A.AC204FF1@baltimore.ie> Date: Tue, 11 Jul 2000 16:38:34 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sue A." , ietf-sacred CC: xme Subject: Re: Requirements References: <200007111508.LAA09570@roadblock.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Sandi, > I had understood the concept to allow an application (any?) to retrieve > credentials from a repository, and, that repository would have a set of > security requirements against it. Maybe its time for some ascii-art (hope you're using fixed-width:-) This is how I see what we're up to: +--------+ +------------+ | Client +-----------+ Credential | +--------+ 1. | Server | \ +-----+------+ \ | 3.\ | 2. \ | \ +-----+------+ +-----+ Repository | +------------+ Client: The entity that wants the credential. Credential Server: The server that knows how/who/when to give the credential to the client. Repository: Where the credentials are stored. The repository might have access control features but those aren't sufficient in themselves for protecting credentials. The numbers stand for putative protocols that we might pick/define. Now, my take would be that: - our core work is to specify protocol 1 above - we don't need to specify protocol 2 (but if we did it'd be LDAP) - we might need to specify protocol 3, depending (and if we do, then let's pick LDAP) > Isn't it a bit constraining to discuss LDAP as THE access protocol? Not if its accessing a repository (protocols 2 & 3). If the protocol has to do more (e.g. client authentication combined with clever credential protection) then I don't believe we can use LDAP. Might be nice if we could. > I would > have thought that the ability to bind with some level of cryptographically > strong identity/authentication to access (or store or delete) credential > information could be achieved with at least a few different protocol > choices. See above. I hope we're in agreement. > > However, the usefulness of defining objects and their attributes is, in my > view, almost a necessity. Especially if there are replication/distribution > requirements for availability and recovery. Fair enough, but wouldn't that be a second level priority? I mean the client/cred.server interop comes first in my mind. > Will this group discuss the security requirements levied on the credential > server? Not sure what you mean. We'll certainly need *lots* of security consderations, but in terms of MUSTs & SHOULDs on the implementation of the credential server, I'm not so sure. > If so, will that tie into the emerging access control scheme/model > in the LDAPExt wg? See above. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 08:54:59 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA15488 for ietf-sacred-bks; Tue, 11 Jul 2000 08:54:59 -0700 (PDT) Received: from relay07.indigo.ie (relay07.indigo.ie [194.125.133.231]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA15484 for ; Tue, 11 Jul 2000 08:54:57 -0700 (PDT) Received: (qmail 89368 messnum 1016064 invoked from network[194.125.148.103/ts03-103.dublin.indigo.ie]); 11 Jul 2000 15:56:46 -0000 Received: from ts03-103.dublin.indigo.ie (HELO cb?bridge.CardBase.com) (194.125.148.103) by relay07.indigo.ie (qp 89368) with SMTP; 11 Jul 2000 15:56:46 -0000 Received: by CB_BRIDGE with Internet Mail Service (5.0.1460.8) id <32PLLWT5>; Tue, 11 Jul 2000 16:23:08 +0100 Message-ID: <831D1A07A4B1D31186DA00062950FA572A0FFF@_CB_MAIL> From: Pierre Heuze To: "'stephen.farrell@baltimore.ie'" , Dale Gustafson Cc: Roaming Credentials List Subject: RE: roaming credentials (sacred) Date: Tue, 11 Jul 2000 16:23:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some comments below -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: 11 July 2000 15:53 To: Dale Gustafson Cc: Roaming Credentials List; xme Subject: Re: roaming credentials (sacred) Dale, > User credentials today typically consist of a public/private key pair > and a corresponding x.509 certificate or certificate chain. They are > stored on a desktop or laptop system as part of the browser's key > pair / certificate store (which is optionally password protected). Each > key pair / certificate can be backed up to disk within an encrypted > PKCS#12 file (e.g., a basic password encrypted file) in support of > encryption key recovery, etc. All functions can be made to work > but, in general, browser support for credential export/import is uneven > and the end user needs to get too involved with the mechanics of creating > and maintaining his/her security profile (this is especially true for > dual-key browser configurations that use one key for encryption and a > second for digital signature operations). That looks like useful text to include in the charter, was that what you intended? > > Hopefully, roaming credentials will provide a basis for extending > existing capabilities such that: > > - user credentials can be accessed remotely by the authorized user > - user credentials can be fully protected from unauthorized disclosure > - authorized users can be clearly identified > - credentials can be created by end users or by a server > - credentials can be securely downloaded to a remote user > - updated credentials can be securely uploaded from a remote user > - credentials can be packaged (customized) for secure delivery to a specific device such as a > physical smart card > - credential management is more automated (from the user's perspective) The above probably belongs in a requirements draft. Questions: - what constitutes an "updated credential"? Do we consider that a single credential is a container for say 10 PKCS#12's, or that that should be 10 different credentials? Why not looking at PKCS#15 Soft Token there. This will be a good container for one or more credentials, and it has the ability to tell what is inside the container. Question if a user has access to many PKCS#15, how to we decide which one to use ? Question PKCS#15 and (in most case PKCS#12) are protected by a password. Is that good enough ? Should we use a type of one time password, can we make provision to get those passwords derived from some physical hardware (a chip serial number, a biometrics template,...) ? - what does "packaged" mean? If you mean the credential server auomatically changing the credential format then I don't see how that can work. If you mean that the credential server has to be credential-format indpendent then that's something we should discuss. I would add where to we store those credentials on the server side ? LDAP ? How well LDAP does in the wireless world? > For a variety of very pragmatic reasons, smart cards are expensive to > modify and, more importantly, it takes a long time to build and deploy > updated cards / firmware. I would suggest we make provision for protocol > options whereby individual vendors or vendor groups can add card-specific > protocol variations (to credential servers and clients) such that existing > and in-process card designs can be used. I'm not clear about what you mean here, but I think I agree - can you give an example? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 09:05:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16185 for ietf-sacred-bks; Tue, 11 Jul 2000 09:05:42 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16181 for ; Tue, 11 Jul 2000 09:05:40 -0700 (PDT) Received: by balinese.baltimore.ie; id RAA00677; Tue, 11 Jul 2000 17:07:31 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma000648; Tue, 11 Jul 00 17:07:26 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA24492; Tue, 11 Jul 2000 17:07:26 +0100 Message-ID: <396B464F.B5811054@baltimore.ie> Date: Tue, 11 Jul 2000 17:07:43 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pierre Heuze , Roaming Credentials List CC: xme Subject: Re: roaming credentials (sacred) References: <831D1A07A4B1D31186DA00062950FA572A0FFF@_CB_MAIL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Pierre, > Why not looking at PKCS#15 Soft Token there. This will be a good > container for one or more credentials, and it has the ability to tell what > is inside the container. I'd agree that p#15 should be one of the formats we consider. > Question if a user has access to many PKCS#15, how to we decide > which one to use ? That's something we need to figure out when/if we get to protocol design. > Question PKCS#15 and (in most case PKCS#12) are protected by a > password. Is that good enough ? Nope. If we can't do better than a weak password, then we'd just be making security worse by leaving credentials lying around vulnerable to dictionary attacks (which'd hardly constitute a successful security protocol:-). > Should we use a type of one time password, > can we make provision to get those passwords derived from some physical > hardware (a chip serial number, a biometrics template,...) ? Worked out suggestions are welcome. I do agree that it'd be nice to allow cases where there is h/w on the client, but I don't think we can mandate this (or if we do, no-one will do it!). Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 09:32:55 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18196 for ietf-sacred-bks; Tue, 11 Jul 2000 09:32:55 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18188 for ; Tue, 11 Jul 2000 09:32:54 -0700 (PDT) Received: from bpsi.net (port438.bpsi.net [209.54.245.238]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id LAA03273; Tue, 11 Jul 2000 11:34:39 -0500 (CDT) Message-ID: <396B4C3F.8A8A9E68@bpsi.net> Date: Tue, 11 Jul 2000 11:33:03 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: Roaming Credentials List Subject: Re: roaming credentials (sacred) References: <3960BAD3.7065EF13@baltimore.ie> <396A1E46.3E60C42A@bpsi.net> <396B34E8.7CB2D3C5@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Stephen, Comments inline. Regards, --dg Stephen Farrell wrote: > Dale, > > > User credentials today typically consist of a public/private key pair > > and a corresponding x.509 certificate or certificate chain. They are > > stored on a desktop or laptop system as part of the browser's key > > pair / certificate store (which is optionally password protected). Each > > key pair / certificate can be backed up to disk within an encrypted > > PKCS#12 file (e.g., a basic password encrypted file) in support of > > encryption key recovery, etc. All functions can be made to work > > but, in general, browser support for credential export/import is uneven > > and the end user needs to get too involved with the mechanics of creating > > and maintaining his/her security profile (this is especially true for > > dual-key browser configurations that use one key for encryption and a > > second for digital signature operations). > > That looks like useful text to include in the charter, was that what you > intended? Just summarizing briefly -- feel free to use / modify as needed. > > > > Hopefully, roaming credentials will provide a basis for extending > > existing capabilities such that: > > > > - user credentials can be accessed remotely by the authorized user > > - user credentials can be fully protected from unauthorized disclosure > > - authorized users can be clearly identified > > - credentials can be created by end users or by a server > > - credentials can be securely downloaded to a remote user > > - updated credentials can be securely uploaded from a remote user > > - credentials can be packaged (customized) for secure delivery to a specific device such as a > > physical smart card > > - credential management is more automated (from the user's perspective) > > The above probably belongs in a requirements draft. Sounds good. > > > Questions: > > - what constitutes an "updated credential"? Do we consider > that a single credential is a container for say 10 PKCS#12's, or that that > should be 10 different credentials? Probably TBD during protocol design. > - what does "packaged" mean? If you mean the credential server > auomatically changing the credential format then I don't see > how that can work. If you mean that the credential server has > to be credential-format indpendent then that's something we should > discuss. Wrapped using some form of strong encryption. I'm implying that the basic credential information might be stored in one or more different formats (or reformatted at request time) such that it can be securely delivered to different machine configurations. The basic information (e.g. PKCS#1/ASN.1 encoded key pairs and x.509 v3 signed certificates) need not be altered. > > For a variety of very pragmatic reasons, smart cards are expensive to > > modify and, more importantly, it takes a long time to build and deploy > > updated cards / firmware. I would suggest we make provision for protocol > > options whereby individual vendors or vendor groups can add card-specific > > protocol variations (to credential servers and clients) such that existing > > and in-process card designs can be used. > > I'm not clear about what you mean here, but I think I agree - can you give > an example? When the remote client software requests a credential download it could supply a parameter suggesting which device-specific logic in the server should be used to satisfy the request and / or that a specific variation of the download protocol should be used. For example, the server might be able to provide the information wrapped (encrypted) such that a specific type of device can decrypt the information (e.g. within the device) as it's installed. The intent is to make it relatively easy to have a secure credential download. For secure download, I assume we need to achieve 3DES-112 or stronger encryption levels. > > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 10:00:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA21182 for ietf-sacred-bks; Tue, 11 Jul 2000 10:00:44 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21178 for ; Tue, 11 Jul 2000 10:00:42 -0700 (PDT) Received: by balinese.baltimore.ie; id SAA08476; Tue, 11 Jul 2000 18:02:32 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma008404; Tue, 11 Jul 00 18:01:47 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA26316; Tue, 11 Jul 2000 18:01:47 +0100 Message-ID: <396B530C.67356491@baltimore.ie> Date: Tue, 11 Jul 2000 18:02:04 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dale Gustafson CC: Roaming Credentials List , xme Subject: Re: roaming credentials (sacred) References: <3960BAD3.7065EF13@baltimore.ie> <396A1E46.3E60C42A@bpsi.net> <396B34E8.7CB2D3C5@baltimore.ie> <396B4C3F.8A8A9E68@bpsi.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dale, > Wrapped using some form of strong encryption. I'm implying that > the basic credential information might be stored in one or more > different formats (or reformatted at request time) such that it can > be securely delivered to different machine configurations. The basic > information (e.g. PKCS#1/ASN.1 encoded key pairs and x.509 v3 > signed certificates) need not be altered. I think this is interesting. I can imagine a credential server being given the "same" credential in a few different formats and being told what they are. Where I'd have a problem is if you expect to hand over one format (say pkcs#12) and have the server translate this to another (e.g. PGP private key ring:-). Still, the basic operation is to deal with one credential - if we can get that right then we're in business, if not, not. > For example, the server might be able to provide the information wrapped > (encrypted) such that a specific type of device can decrypt the information > (e.g. within the device) as it's installed. The intent is to make it > relatively easy to have a secure credential download. For secure download, > I assume we need to achieve 3DES-112 or stronger encryption levels. I would tend to consider that a new credential format (e.g. "p#12-wrapped-for- smartcard-x"). Wouldn't that work more simply? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 11 11:02:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24468 for ietf-sacred-bks; Tue, 11 Jul 2000 11:02:18 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24464 for ; Tue, 11 Jul 2000 11:02:16 -0700 (PDT) Received: from bpsi.net (port438.bpsi.net [209.54.245.238]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id NAA08116; Tue, 11 Jul 2000 13:04:03 -0500 (CDT) Message-ID: <396B6133.C5A125CE@bpsi.net> Date: Tue, 11 Jul 2000 13:02:27 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: Roaming Credentials List Subject: Re: roaming credentials (sacred) References: <3960BAD3.7065EF13@baltimore.ie> <396A1E46.3E60C42A@bpsi.net> <396B34E8.7CB2D3C5@baltimore.ie> <396B4C3F.8A8A9E68@bpsi.net> <396B530C.67356491@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen, Stephen Farrell wrote: > Dale, > > > Wrapped using some form of strong encryption. I'm implying that > > the basic credential information might be stored in one or more > > different formats (or reformatted at request time) such that it can > > be securely delivered to different machine configurations. The basic > > information (e.g. PKCS#1/ASN.1 encoded key pairs and x.509 v3 > > signed certificates) need not be altered. > > I think this is interesting. I can imagine a credential server being given > the "same" credential in a few different formats and being told what > they are. Where I'd have a problem is if you expect to hand over one > format (say pkcs#12) and have the server translate this to another > (e.g. PGP private key ring:-). > > Still, the basic operation is to deal with one credential - if we can > get that right then we're in business, if not, not. I agree. Just throwing out suggestions to try to come up with secure and quick to market. I would think that's important. > > For example, the server might be able to provide the information wrapped > > (encrypted) such that a specific type of device can decrypt the information > > (e.g. within the device) as it's installed. The intent is to make it > > relatively easy to have a secure credential download. For secure download, > > I assume we need to achieve 3DES-112 or stronger encryption levels. > > I would tend to consider that a new credential format (e.g. "p#12-wrapped-for- > smartcard-x"). Wouldn't that work more simply? Yes, but intuitively, there is real value in leaving things as open ended as possible in this area. It would be ideal if any device that can perform some type of secure credential download can be accomodated. > > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Wed Jul 12 03:18:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA08567 for ietf-sacred-bks; Wed, 12 Jul 2000 03:18:50 -0700 (PDT) Received: from relay07.indigo.ie (relay07.indigo.ie [194.125.133.231]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA08563 for ; Wed, 12 Jul 2000 03:18:49 -0700 (PDT) Received: (qmail 1273 messnum 1016290 invoked from network[194.125.134.30/ts01-030.dublin.indigo.ie]); 12 Jul 2000 10:20:41 -0000 Received: from ts01-030.dublin.indigo.ie (HELO cb?bridge.CardBase.com) (194.125.134.30) by relay07.indigo.ie (qp 1273) with SMTP; 12 Jul 2000 10:20:41 -0000 Received: by CB_BRIDGE with Internet Mail Service (5.0.1460.8) id <32PLLXF1>; Wed, 12 Jul 2000 11:06:29 +0100 Message-ID: <831D1A07A4B1D31186DA00062950FA572A100A@_CB_MAIL> From: Pierre Heuze To: ietf-sacred Subject: Roaming credentials: how about non-repudiation Date: Wed, 12 Jul 2000 11:06:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: {Stphen Farrell wrote] Specific issues we'd like to encourage discussion about include:- - what are the most important use cases? - how "strong" does the authentication have to be? - what credential formats are most important? - what transport(s) should be used for such a protocol? So far we have started discussion on 1,3,4, not much has been said on the second point. Form the type of use cases already discussed in 1, I imagine we need something "strong", in particular we need to be able to build on top of this some kind of non-repudiation. (Stephen that is one of the reason, I want to allow cases where there is h/w on the client). Does other share that requirement too? What are the ideas on this ? From owner-ietf-sacred Thu Jul 13 01:26:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06923 for ietf-sacred-bks; Thu, 13 Jul 2000 01:26:29 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06917 for ; Thu, 13 Jul 2000 01:26:27 -0700 (PDT) Received: from johnhughes (d231-198.dial.mistral.co.uk [195.184.231.198]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYLZ63L; Thu, 13 Jul 2000 01:35:38 -0700 From: "John Hughes" To: "Ietf-Scared (E-mail)" Subject: LDAP Date: Thu, 13 Jul 2000 09:28:16 +0100 Message-ID: <002901bfeca4$4bf17410$1138d90a@johnhughes.cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If we use LDAP (either a MUST or SHOULD) then we could use LDAP over SSL. This would then give us both authentication to the credential repository plus another layer of protection whilst the credential is being transferred. John From owner-ietf-sacred Thu Jul 13 05:05:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA20620 for ietf-sacred-bks; Thu, 13 Jul 2000 05:05:19 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20616 for ; Thu, 13 Jul 2000 05:05:17 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id HAA23779 for ; Thu, 13 Jul 2000 07:56:39 -0400 (EDT) Message-Id: <200007131156.HAA23774@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'John Hughes'" , "Ietf-Scared (E-mail)" Subject: RE: LDAP Date: Thu, 13 Jul 2000 08:07:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I had believed the LDAP w/TLS was the preferred choice emerging from the wg. However, when looking at all the possible access protocol / network*transport layer confidentiality possibilities, does it make sense to constrain choice to only one? will there be discussion of management transactions (vice retrieval only)? Given the potential sensitivity of the credential server, will there be discussion of intrusion detection notifications above and beyond rudimentary audit logs? regards, Sandi Miklos -----Original Message----- From: John Hughes [mailto:john.hughes@entegrity.com] Sent: Thursday, July 13, 2000 4:28 AM To: Ietf-Scared (E-mail) Subject: LDAP If we use LDAP (either a MUST or SHOULD) then we could use LDAP over SSL. This would then give us both authentication to the credential repository plus another layer of protection whilst the credential is being transferred. John **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From owner-ietf-sacred Thu Jul 13 05:48:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22775 for ietf-sacred-bks; Thu, 13 Jul 2000 05:48:41 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA22771 for ; Thu, 13 Jul 2000 05:48:40 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Jul 2000 12:50:41 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA27421 for ; Thu, 13 Jul 2000 08:49:41 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jul 2000 08:50:40 -0400 Message-ID: From: "Linn, John" To: "'Roaming Credentials List'" Subject: Premise question: serverless models? Date: Thu, 13 Jul 2000 08:50:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Much of the discussion here so far has been emphasizing elements of "upload", "download", and "credential server". Given that a primary use for credential transfer could be to get a user's credentials from one of the user's devices to another of the user's devices, a third-party intermediary server might not always be necessary; if feasible, a direct peer-peer transfer between the user's devices would avoid potential compromise at the intermediary. Should consideration of both server-based and serverless models be identified explicitly in the charter? --jl From owner-ietf-sacred Thu Jul 13 05:51:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23031 for ietf-sacred-bks; Thu, 13 Jul 2000 05:51:22 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23026 for ; Thu, 13 Jul 2000 05:51:21 -0700 (PDT) Received: from johnhughes (d231-205.dial.mistral.co.uk [195.184.231.205]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYLZ7BR; Thu, 13 Jul 2000 06:00:35 -0700 From: "John Hughes" To: "'Miklos, Sue A.'" , "'Ietf-Scared (E-mail)'" Subject: RE: LDAP Date: Thu, 13 Jul 2000 13:53:12 +0100 Message-ID: <000601bfecc9$4e0e87e0$1138d90a@johnhughes.cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200007131156.HAA23775@roadblock.missi.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sandi, I'm not wishing to constrain - but I know that we would prefer LDAP. The mgmt issues are interesting. Image this scenario: - RA creates credential for user and somehow provides PIN to user. Credential then "published" to repositry - user then fetches credential for first time, perhaps changing initial PIN - sometime later user then goes to another location and uses a new w/s at that location to fetch their credential. But the PIN has now changed. This seems to indicate we need a means to write back the credential at the end of the session (perhaps with other state info) John > -----Original Message----- > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > Sent: 13 July 2000 13:07 > To: 'John Hughes'; Ietf-Scared (E-mail) > Subject: RE: LDAP > > > I had believed the LDAP w/TLS was the preferred choice > emerging from the wg. > However, when looking at all the possible access protocol / > network*transport layer confidentiality possibilities, does > it make sense to > constrain choice to only one? > > will there be discussion of management transactions (vice > retrieval only)? > Given the potential sensitivity of the credential server, > will there be > discussion of intrusion detection notifications above and > beyond rudimentary > audit logs? > > regards, > Sandi Miklos > > -----Original Message----- > From: John Hughes [mailto:john.hughes@entegrity.com] > Sent: Thursday, July 13, 2000 4:28 AM > To: Ietf-Scared (E-mail) > Subject: LDAP > > > If we use LDAP (either a MUST or SHOULD) then we could use > LDAP over SSL. > This would then give us both authentication to the credential > repository > plus another layer of protection whilst the credential is > being transferred. > > > John > > > > ************************************************************** > ************** > * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ************************************************************** > ************** > ** > From owner-ietf-sacred Thu Jul 13 05:58:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23320 for ietf-sacred-bks; Thu, 13 Jul 2000 05:58:52 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA23316 for ; Thu, 13 Jul 2000 05:58:51 -0700 (PDT) Received: (qmail 14388 invoked from network); 13 Jul 2000 13:00:51 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 13 Jul 2000 13:00:51 -0000 Received: (qmail 11430 invoked by uid 1183); 13 Jul 2000 13:00:59 -0000 Date: Thu, 13 Jul 2000 15:00:52 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sacred@imc.org Subject: draft-farrell-sacred-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id FAA23317 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, The above mentioned I-D is now available from ietf.org, as an individual submission. Please regard it as a strawman and a basis for discussions more than anything else. Thanks, -- Magnus Magnus Nyström Email: magnus@rsasecurity.com RSA Security From owner-ietf-sacred Thu Jul 13 06:05:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23537 for ietf-sacred-bks; Thu, 13 Jul 2000 06:05:16 -0700 (PDT) Received: from relay07.indigo.ie (relay07.indigo.ie [194.125.133.231]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA23533 for ; Thu, 13 Jul 2000 06:05:14 -0700 (PDT) Received: (qmail 58751 messnum 1016305 invoked from network[194.125.148.229/ts04-102.dublin.indigo.ie]); 13 Jul 2000 13:07:12 -0000 Received: from ts04-102.dublin.indigo.ie (HELO cb?bridge.CardBase.com) (194.125.148.229) by relay07.indigo.ie (qp 58751) with SMTP; 13 Jul 2000 13:07:12 -0000 Received: by CB_BRIDGE with Internet Mail Service (5.0.1460.8) id <32PLLYKX>; Thu, 13 Jul 2000 14:05:38 +0100 Message-ID: <831D1A07A4B1D31186DA00062950FA573BB5D4@_CB_MAIL> From: Pierre Heuze To: "'Miklos, Sue A.'" , "'John Hughes'" , "Ietf-Scared (E-mail)" Subject: RE: LDAP Date: Thu, 13 Jul 2000 14:05:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is really w/TLS what is needed ? Might be okay for Server authentication, but how does the client get authenticated to the credential server ? Or am I missing something ? -----Original Message----- From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] Sent: Thursday, July 13, 2000 1:07 PM To: 'John Hughes'; Ietf-Scared (E-mail) Subject: RE: LDAP I had believed the LDAP w/TLS was the preferred choice emerging from the wg. However, when looking at all the possible access protocol / network*transport layer confidentiality possibilities, does it make sense to constrain choice to only one? will there be discussion of management transactions (vice retrieval only)? Given the potential sensitivity of the credential server, will there be discussion of intrusion detection notifications above and beyond rudimentary audit logs? regards, Sandi Miklos -----Original Message----- From: John Hughes [mailto:john.hughes@entegrity.com] Sent: Thursday, July 13, 2000 4:28 AM To: Ietf-Scared (E-mail) Subject: LDAP If we use LDAP (either a MUST or SHOULD) then we could use LDAP over SSL. This would then give us both authentication to the credential repository plus another layer of protection whilst the credential is being transferred. John **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From owner-ietf-sacred Thu Jul 13 06:14:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23799 for ietf-sacred-bks; Thu, 13 Jul 2000 06:14:18 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23795 for ; Thu, 13 Jul 2000 06:14:17 -0700 (PDT) Received: from johnhughes (d231-95.dial.mistral.co.uk [195.184.231.95]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYLZ71P; Thu, 13 Jul 2000 06:23:30 -0700 From: "John Hughes" To: "'Pierre Heuze'" , "'Miklos, Sue A.'" , "'Ietf-Scared (E-mail)'" Subject: RE: LDAP Date: Thu, 13 Jul 2000 14:16:06 +0100 Message-ID: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <831D1A07A4B1D31186DA00062950FA573BB5D4@_CB_MAIL> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Pierre, no - your are not missing anything. We will have to "bootstrap" the system somehow, whether we use TLS or VPN/network style of security. If we use TLS (as one of the options) then we will have to decide if client authentication is required. If it is - then how do all of the w/s that interact with the credential repository get a client cert/PSE. John > -----Original Message----- > From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] > Sent: 13 July 2000 14:06 > To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) > Subject: RE: LDAP > > > Is really w/TLS what is needed ? Might be okay for Server > authentication, > but how does the client get authenticated to the credential > server ? Or am I > missing something ? > > -----Original Message----- > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > Sent: Thursday, July 13, 2000 1:07 PM > To: 'John Hughes'; Ietf-Scared (E-mail) > Subject: RE: LDAP > > I had believed the LDAP w/TLS was the preferred choice > emerging from the wg. > However, when looking at all the possible > access protocol / > network*transport layer confidentiality > possibilities, does > it make sense to > constrain choice to only one? > > will there be discussion of management > transactions (vice > retrieval only)? > Given the potential sensitivity of the > credential server, > will there be > discussion of intrusion detection notifications > above and > beyond rudimentary > audit logs? > > regards, > Sandi Miklos > > -----Original Message----- > From: John Hughes [mailto:john.hughes@entegrity.com] > Sent: Thursday, July 13, 2000 4:28 AM > To: Ietf-Scared (E-mail) > Subject: LDAP > > > If we use LDAP (either a MUST or SHOULD) then > we could use > LDAP over SSL. > This would then give us both authentication to the > credential repository > plus another layer of protection whilst the > credential is > being transferred. > > > John > > > > > ************************************************************** > ************** > * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > ************************************************************** > ************** > ** > From owner-ietf-sacred Thu Jul 13 06:24:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA24219 for ietf-sacred-bks; Thu, 13 Jul 2000 06:24:12 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24213 for ; Thu, 13 Jul 2000 06:24:11 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA11978 for ; Thu, 13 Jul 2000 09:15:32 -0400 (EDT) Message-Id: <200007131315.JAA11970@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'John Hughes'" , "'Pierre Heuze'" , "'Ietf-Scared (E-mail)'" Subject: RE: LDAP Date: Thu, 13 Jul 2000 09:26:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Initialization / startup with respect to credentials is always a challenge! However, I'm a bit confused by the question of whether or not a client needs to authenticate. Isn't the concept that in order for a credential server to provide a credential, it must know that the correct requestor is generating the credential request? And, isn't one of the means of assuring I&A through the use of 'strong' authentication techniques? To my mind, a 'strong' authentication is the conveyance of some cryptographically bound credential (issued through a rigorously monitored process - not part of this discussion) over a secured 'pipe' between both ends of the connection. Is this consistent with the emerging model? Sandi -----Original Message----- From: John Hughes [mailto:john.hughes@entegrity.com] Sent: Thursday, July 13, 2000 9:16 AM To: 'Pierre Heuze'; Miklos, Sue A.; 'Ietf-Scared (E-mail)' Subject: RE: LDAP Pierre, no - your are not missing anything. We will have to "bootstrap" the system somehow, whether we use TLS or VPN/network style of security. If we use TLS (as one of the options) then we will have to decide if client authentication is required. If it is - then how do all of the w/s that interact with the credential repository get a client cert/PSE. John > -----Original Message----- > From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] > Sent: 13 July 2000 14:06 > To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) > Subject: RE: LDAP > > > Is really w/TLS what is needed ? Might be okay for Server > authentication, > but how does the client get authenticated to the credential > server ? Or am I > missing something ? > > -----Original Message----- > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > Sent: Thursday, July 13, 2000 1:07 PM > To: 'John Hughes'; Ietf-Scared (E-mail) > Subject: RE: LDAP > > I had believed the LDAP w/TLS was the preferred choice > emerging from the wg. > However, when looking at all the possible > access protocol / > network*transport layer confidentiality > possibilities, does > it make sense to > constrain choice to only one? > > will there be discussion of management > transactions (vice > retrieval only)? > Given the potential sensitivity of the > credential server, > will there be > discussion of intrusion detection notifications > above and > beyond rudimentary > audit logs? > > regards, > Sandi Miklos > > -----Original Message----- > From: John Hughes [mailto:john.hughes@entegrity.com] > Sent: Thursday, July 13, 2000 4:28 AM > To: Ietf-Scared (E-mail) > Subject: LDAP > > > If we use LDAP (either a MUST or SHOULD) then > we could use > LDAP over SSL. > This would then give us both authentication to the > credential repository > plus another layer of protection whilst the > credential is > being transferred. > > > John > > > > > ************************************************************** > ************** > * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > ************************************************************** > ************** > ** > From owner-ietf-sacred Thu Jul 13 06:32:52 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA24436 for ietf-sacred-bks; Thu, 13 Jul 2000 06:32:52 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24432 for ; Thu, 13 Jul 2000 06:32:51 -0700 (PDT) Received: from johnhughes (d231-240.dial.mistral.co.uk [195.184.231.240]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYLZ7HK; Thu, 13 Jul 2000 06:42:05 -0700 From: "John Hughes" To: "'Miklos, Sue A.'" , "'Pierre Heuze'" , "'Ietf-Scared (E-mail)'" Subject: RE: LDAP Date: Thu, 13 Jul 2000 14:34:43 +0100 Message-ID: <000c01bfeccf$1b542cf0$1138d90a@johnhughes.cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200007131315.JAA11969@roadblock.missi.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Its true - do we need this? The credential is cryptographically bound entity. John > -----Original Message----- > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > Sent: 13 July 2000 14:26 > To: 'John Hughes'; 'Pierre Heuze'; 'Ietf-Scared (E-mail)' > Subject: RE: LDAP > > > Initialization / startup with respect to credentials is > always a challenge! > > However, I'm a bit confused by the question of whether or not > a client needs > to authenticate. Isn't the concept that in order for a > credential server to > provide a credential, it must know that the correct requestor > is generating > the credential request? And, isn't one of the means of > assuring I&A through > the use of 'strong' authentication techniques? To my mind, a 'strong' > authentication is the conveyance of some cryptographically > bound credential > (issued through a rigorously monitored process - not part of this > discussion) over a secured 'pipe' between both ends of the > connection. Is > this consistent with the emerging model? > > Sandi > > > -----Original Message----- > From: John Hughes [mailto:john.hughes@entegrity.com] > Sent: Thursday, July 13, 2000 9:16 AM > To: 'Pierre Heuze'; Miklos, Sue A.; 'Ietf-Scared (E-mail)' > Subject: RE: LDAP > > > Pierre, > > no - your are not missing anything. We will have to > "bootstrap" the system > somehow, whether we use TLS or VPN/network style of security. > If we use TLS > (as one of the options) then we will have to decide if client > authentication > is required. If it is - then how do all of the w/s that > interact with the > credential repository get a client cert/PSE. > > > John > > > > -----Original Message----- > > From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] > > Sent: 13 July 2000 14:06 > > To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) > > Subject: RE: LDAP > > > > > > Is really w/TLS what is needed ? Might be okay for Server > > authentication, > > but how does the client get authenticated to the credential > > server ? Or am I > > missing something ? > > > > -----Original Message----- > > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > > Sent: Thursday, July 13, 2000 1:07 PM > > To: 'John Hughes'; Ietf-Scared (E-mail) > > Subject: RE: LDAP > > > > I had believed the LDAP w/TLS was the preferred choice > > emerging from the wg. > > However, when looking at all the possible > > access protocol / > > network*transport layer confidentiality > > possibilities, does > > it make sense to > > constrain choice to only one? > > > > will there be discussion of management > > transactions (vice > > retrieval only)? > > Given the potential sensitivity of the > > credential server, > > will there be > > discussion of intrusion detection notifications > > above and > > beyond rudimentary > > audit logs? > > > > regards, > > Sandi Miklos > > > > -----Original Message----- > > From: John Hughes [mailto:john.hughes@entegrity.com] > > Sent: Thursday, July 13, 2000 4:28 AM > > To: Ietf-Scared (E-mail) > > Subject: LDAP > > > > > > If we use LDAP (either a MUST or SHOULD) then > > we could use > > LDAP over SSL. > > This would then give us both authentication to the > > credential repository > > plus another layer of protection whilst the > > credential is > > being transferred. > > > > > > John > > > > > > > > > > ************************************************************** > > ************** > > * > > This confirms that this email message has been swept by > > MIMEsweeper for the presence of computer viruses. > > > > ************************************************************** > > ************** > > ** > > > From owner-ietf-sacred Thu Jul 13 06:31:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA24388 for ietf-sacred-bks; Thu, 13 Jul 2000 06:31:42 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24383 for ; Thu, 13 Jul 2000 06:31:41 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA13805 for ; Thu, 13 Jul 2000 09:23:03 -0400 (EDT) Message-Id: <200007131323.JAA13796@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'John Hughes'" , "'Ietf-Scared (E-mail)'" Subject: RE: LDAP Date: Thu, 13 Jul 2000 09:33:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, If I understand your scenario correctly, it is essentially related to the ability to distribute database information amongst geographically disbursed servers, upon change. Will this group take on that challenge or is the intent to leverage off the work going on in other groups? In certain environments, the ability to exchange database information among servers in the Privilege Management Infrastructure may be effected through any suite of protocols that meet the availability, performance, scalability and recovery requirements. I personally believe that X.500 and the emerging LDAP/LDUP work has or is addressing this problem space. Should our input be focused on the integrity of the transaction and any necessary acknowledgements that transaction has successfully completed? regards, Sandi -----Original Message----- From: John Hughes [mailto:john.hughes@entegrity.com] Sent: Thursday, July 13, 2000 8:53 AM To: Miklos, Sue A.; 'Ietf-Scared (E-mail)' Subject: RE: LDAP Sandi, I'm not wishing to constrain - but I know that we would prefer LDAP. The mgmt issues are interesting. Image this scenario: - RA creates credential for user and somehow provides PIN to user. Credential then "published" to repositry - user then fetches credential for first time, perhaps changing initial PIN - sometime later user then goes to another location and uses a new w/s at that location to fetch their credential. But the PIN has now changed. This seems to indicate we need a means to write back the credential at the end of the session (perhaps with other state info) John > -----Original Message----- > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > Sent: 13 July 2000 13:07 > To: 'John Hughes'; Ietf-Scared (E-mail) > Subject: RE: LDAP > > > I had believed the LDAP w/TLS was the preferred choice > emerging from the wg. > However, when looking at all the possible access protocol / > network*transport layer confidentiality possibilities, does > it make sense to > constrain choice to only one? > > will there be discussion of management transactions (vice > retrieval only)? > Given the potential sensitivity of the credential server, > will there be > discussion of intrusion detection notifications above and > beyond rudimentary > audit logs? > > regards, > Sandi Miklos > > -----Original Message----- > From: John Hughes [mailto:john.hughes@entegrity.com] > Sent: Thursday, July 13, 2000 4:28 AM > To: Ietf-Scared (E-mail) > Subject: LDAP > > > If we use LDAP (either a MUST or SHOULD) then we could use > LDAP over SSL. > This would then give us both authentication to the credential > repository > plus another layer of protection whilst the credential is > being transferred. > > > John > > > > ************************************************************** > ************** > * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ************************************************************** > ************** > ** > From owner-ietf-sacred Thu Jul 13 13:39:48 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08675 for ietf-sacred-bks; Thu, 13 Jul 2000 13:39:48 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08671 for ; Thu, 13 Jul 2000 13:39:46 -0700 (PDT) Received: from bpsi.net (port447.bpsi.net [209.54.245.247]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id PAA24522; Thu, 13 Jul 2000 15:41:27 -0500 (CDT) Message-ID: <396E2917.726F951D@bpsi.net> Date: Thu, 13 Jul 2000 15:39:52 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: John Hughes CC: "'Pierre Heuze'" , "'Miklos, Sue A.'" , "'Ietf-Scared (E-mail)'" Subject: Re: LDAP References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> Content-Type: multipart/alternative; boundary="------------9C2640A3E9A53D4C84E0CC36" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------9C2640A3E9A53D4C84E0CC36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, Pierre, and Sandi, TLS seems like a much better choice than VPN for the protocol between client and the credential server (protocol #1 per Stephen's diagram) which is copied here: ---------------------------------------------------------------------- +--------+ +------------+ | Client +-----------+ Credential | +--------+ 1. | Server | \ +-----+------+ \ | 3.\ | 2. \ | \ +-----+------+ +-----+ Repository | +------------+ Client: The entity that wants the credential. Credential Server: The server that knows how/who/when to give the credential to the client. Repository: Where the credentials are stored. The repository might have access control features but those aren't sufficient in themselves for protecting credentials. ---------------------------------------------------------------------- protocol 1: ----------- In several cases, the client doesn't have any credentials yet .... so TLS remote client authentication is not possible. I've assumed each client would have to be preconfigured in a nearby credential server and a unique password given to the client via some out of band method. At connect time, the client is authenticated to the credential server via user name and a password (one-time password?) that is submitted over the secure channel. The credential server is authenticated via digital signature. Use of the client password can be dropped as soon as the client obtains a credential that is acceptable to the server (credential #1?). Use of SSL/TLS also allows addition of device-specific variations as needed for optimum secure delivery of credentials (without affecting existing functionality). I agree that LDAP does not appear to be a natural fit here. Sandi has asked whether all clients will be able to support SSL/TLS (which is very good question). protocol 3: ----------- Allows direct access between client and repository. Maybe I missed something but the full purpose of this protocol is not obvious to me. The credential server is responsible for insuring that key material is supplied only to the correct / currently authorized end user. Shouldn't the credential server always perform that function? If it's critical user authentication function is compromised all bets are off. Alternatively, protocol 3 could be limited to download of credentials 2-N and upload of updated credentials (e.g. remote client authentication via digital signature always required by repository before client can directly read or write credential info.) via LDAP/TLS. This could be made to work but it seems like an unnecessary complication to overlap the functionality of credential server and repository. In any case, repository servers can be backed up to a vault, meshed as necessary to replicate credential information, etc. Does that satisfy most large network replication needs? Best Regards, Dale Gustafson John Hughes wrote: > Pierre, > > no - your are not missing anything. We will have to "bootstrap" the system > somehow, whether we use TLS or VPN/network style of security. If we use TLS > (as one of the options) then we will have to decide if client authentication > is required. If it is - then how do all of the w/s that interact with the > credential repository get a client cert/PSE. > > John > > > -----Original Message----- > > From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] > > Sent: 13 July 2000 14:06 > > To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) > > Subject: RE: LDAP > > > > > > Is really w/TLS what is needed ? Might be okay for Server > > authentication, > > but how does the client get authenticated to the credential > > server ? Or am I > > missing something ? > > > > -----Original Message----- > > From: Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > > Sent: Thursday, July 13, 2000 1:07 PM > > To: 'John Hughes'; Ietf-Scared (E-mail) > > Subject: RE: LDAP > > > > I had believed the LDAP w/TLS was the preferred choice > > emerging from the wg. > > However, when looking at all the possible > > access protocol / > > network*transport layer confidentiality > > possibilities, does > > it make sense to > > constrain choice to only one? > > > > will there be discussion of management > > transactions (vice > > retrieval only)? > > Given the potential sensitivity of the > > credential server, > > will there be > > discussion of intrusion detection notifications > > above and > > beyond rudimentary > > audit logs? > > > > regards, > > Sandi Miklos > > > > -----Original Message----- > > From: John Hughes [mailto:john.hughes@entegrity.com] > > Sent: Thursday, July 13, 2000 4:28 AM > > To: Ietf-Scared (E-mail) > > Subject: LDAP > > > > > > If we use LDAP (either a MUST or SHOULD) then > > we could use > > LDAP over SSL. > > This would then give us both authentication to the > > credential repository > > plus another layer of protection whilst the > > credential is > > being transferred. > > > > > > John > > > > > > > > > > ************************************************************** > > ************** > > * > > This confirms that this email message has been swept by > > MIMEsweeper for the presence of computer viruses. > > > > ************************************************************** > > ************** > > ** > > --------------9C2640A3E9A53D4C84E0CC36 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, Pierre, and Sandi,

TLS seems like a much better choice than VPN for the protocol between client and the credential server (protocol #1 per Stephen's diagram) which is copied here:

----------------------------------------------------------------------

  +--------+           +------------+
  | Client +-----------+ Credential |
  +--------+     1.    | Server     |
            \          +-----+------+
             \               |
            3.\              | 2.
               \             |
                \      +-----+------+
                 +-----+ Repository |
                       +------------+
 

Client:                The entity that wants the credential.
Credential Server:     The server that knows how/who/when to give
                       the credential to the client.
Repository:            Where the credentials are stored. The repository
                       might have access control features but those
                       aren't sufficient in themselves for protecting
                       credentials.
 

----------------------------------------------------------------------
 

protocol 1:
-----------
In several cases, the client doesn't have any credentials yet .... so TLS remote client authentication is not possible.

I've assumed each client would have to be preconfigured in a nearby credential server and a unique password given to the client via some out of band method.  At connect time, the client is authenticated to the credential server via user name and a password (one-time password?) that is submitted over the secure channel.  The credential server is authenticated via digital signature.  Use of the client password can be dropped as soon as the client obtains a credential that is acceptable to the server (credential #1?).  Use of SSL/TLS also allows addition of device-specific variations as needed for optimum secure delivery of credentials (without affecting existing functionality).  I agree that LDAP does not appear to be a natural fit here.

Sandi has asked whether all clients will be able to support SSL/TLS (which is very good question).
 

protocol 3:
-----------
Allows direct access between client and repository.  Maybe I missed something but the full purpose of this protocol is not obvious to me.

The credential server is responsible for insuring that key material is supplied only to the correct / currently authorized end user.  Shouldn't the credential server always perform that function?  If it's critical user authentication function is compromised all bets are off.

Alternatively, protocol 3 could be limited to download of credentials 2-N and upload of updated credentials (e.g. remote client authentication via digital signature always required by repository before client can directly read or write credential info.) via LDAP/TLS.  This could be made to work but it seems like an unnecessary complication to overlap the functionality of credential server and repository.

In any case, repository servers can be backed up to a vault, meshed as necessary to replicate credential information, etc.  Does that satisfy most large network replication needs?

Best Regards,

Dale Gustafson
 
 

John Hughes wrote:

Pierre,

no - your are not missing anything.  We will have to "bootstrap" the system
somehow, whether we use TLS or VPN/network style of security.  If we use TLS
(as one of the options) then we will have to decide if client authentication
is required.  If it is - then how do all of the w/s that interact with the
credential repository get a client cert/PSE.

John

> -----Original Message-----
> From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com]
> Sent: 13 July 2000 14:06
> To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail)
> Subject: RE: LDAP
>
>
> Is really w/TLS what is needed ? Might be okay for Server
> authentication,
> but how does the client get authenticated to the credential
> server ? Or am I
> missing something ?
>
>               -----Original Message-----
>               From:   Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil]
>               Sent:   Thursday, July 13, 2000 1:07 PM
>               To:     'John Hughes'; Ietf-Scared (E-mail)
>               Subject:        RE: LDAP
>
>               I had believed the LDAP w/TLS was the preferred choice
> emerging from the wg.
>               However, when looking at all the possible
> access protocol /
>               network*transport layer confidentiality
> possibilities, does
> it make sense to
>               constrain choice to only one?
>
>               will there be discussion of management
> transactions (vice
> retrieval only)?
>               Given the potential sensitivity of the
> credential server,
> will there be
>               discussion of intrusion detection notifications
> above and
> beyond rudimentary
>               audit logs?
>
>               regards,
>               Sandi Miklos
>
>               -----Original Message-----
>               From: John Hughes [mailto:john.hughes@entegrity.com]
>               Sent: Thursday, July 13, 2000 4:28 AM
>               To: Ietf-Scared (E-mail)
>               Subject: LDAP
>
>
>               If we use LDAP (either a MUST or SHOULD) then
> we could use
> LDAP over SSL.
>               This would then give us both authentication to the
> credential repository
>               plus another layer of protection whilst the
> credential is
> being transferred.
>
>
>               John
>
>
>
>
> **************************************************************
> **************
>               *
>               This confirms that this email message has been swept by
>               MIMEsweeper for the presence of computer viruses.
>
> **************************************************************
> **************
>               **
>

--------------9C2640A3E9A53D4C84E0CC36-- From owner-ietf-sacred Thu Jul 13 16:26:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA11720 for ietf-sacred-bks; Thu, 13 Jul 2000 16:26:44 -0700 (PDT) Received: from front001.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11711 for ; Thu, 13 Jul 2000 16:26:43 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by front001.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 13317572; Thu, 13 Jul 2000 19:28:16 -0400 Message-Id: <3.0.5.32.20000713192428.00814bc0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 13 Jul 2000 19:24:28 -0400 To: "Miklos, Sue A." From: David Jablon Subject: RE: LDAP Cc: john.hughes@entegrity.com, ietf-sacred@imc.org In-Reply-To: <200007131156.HAA23774@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 08:07 AM 7/13/00 -0400, Miklos, Sue A. wrote: > I had believed the LDAP w/TLS was the preferred choice emerging from the wg. It seems silly to presume that a choice is *emerging* from the working group today. It's not even officially listed yet at IETF.org! > However, when looking at all the possible access protocol / > network*transport layer confidentiality possibilities, does it make sense to > constrain choice to only one? I believe not, and if so, not *that* choice. There are many methods much stronger than LDAP w/TLS, and I see no reason to jump to conclusions at this stage of the process. See my follow-on post to Dale for discussion of the inadequacy of that proposal. -- dpj From owner-ietf-sacred Thu Jul 13 16:26:53 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA11727 for ietf-sacred-bks; Thu, 13 Jul 2000 16:26:53 -0700 (PDT) Received: from front001.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11716 for ; Thu, 13 Jul 2000 16:26:43 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by front001.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 13317573; Thu, 13 Jul 2000 19:28:16 -0400 Message-Id: <3.0.5.32.20000713192423.00815510@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 13 Jul 2000 19:24:23 -0400 To: Dale Gustafson From: David Jablon Subject: Re: LDAP Cc: John Hughes , "'Pierre Heuze'" , "'Miklos, Sue A.'" , ietf-sacred@imc.org In-Reply-To: <396E2917.726F951D@bpsi.net> References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dale, In your model, and in the LDAP+TLS model that everyone seems to be talking about, there are severe and unnecessary presumptions. If these presumptions are left unchallenged, the group will end up with much weaker-than-necessary methods. So ... here's my challenge: (1) There should be no presumption that most users have any credential other than a password. Sure, some may have smartcards, but we'd like to accomodate a broad population. (2) There should be no presumption that the user can handle a password of any better quality than typical passwords in use today. We must not presume that we can design a better human. ... and finally ... (3) There should be no presumption that the user can or will authenticate the server by name ... for much the same reason as (2). I think striving to meet these challenges will result in a simpler security model that fits very well with the charter as defined so far. And if you look for the best methods in this model, you'll invariably find better solutions than LDAP+TLS. -- dpj At 03:39 PM 7/13/00 -0500, Dale Gustafson wrote: > Hi John, Pierre, and Sandi, TLS seems like a much better choice than VPN >for the protocol between client and the credential server (protocol #1 per >Stephen's diagram) which is copied here: >---------------------------------------------------------------------- > +------------+ > | Client +-----------+ Credential | > | > +-----+------+ > | > | 2. > | > +-----+------+ > +-----+ Repository | > +------------+ > The entity that wants the credential. > The server that knows how/who/when to give > the credential to the client. > Where the credentials are stored. The repository > might have access control features but those > aren't sufficient in themselves for protecting > credentials. > ---------------------------------------------------------------------- > protocol 1: >----------- >In several cases, the client doesn't have any credentials yet .... so TLS >remote client authentication is not possible. I agree that LDAP does >not appear to be a natural fit here. Sandi has asked whether all clients >will be able to support SSL/TLS (which is very good question). One answer is: "No. And even if they did, they shouldn't count on the user explicitly authenticating the server." > protocol 3: >----------- > Maybe I missed something but the full purpose of this protocol is not >obvious to me. If it's critical user authentication function is >compromised all bets are off. This could be made to work but it seems >like an unnecessary complication to overlap the functionality of credential >server and repository. Does that satisfy most large network replication >needs? Best Regards, Dale Gustafson Keeping the repository "close" to the credential server reduces the requirement for a secure communication channel between the two. > John Hughes wrote: Pierre, We will have to "bootstrap" the system > If we use TLS >(as one of the options) then we will have to decide if client authentication > If it is - then how do all of the w/s that interact with the >credential repository get a client cert/PSE. John > -----Original Message----- >> From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] >> Sent: 13 July 2000 14:06 >> To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) >> Subject: RE: LDAP >> >> >> Is really w/TLS what is needed ? Might be okay for Server >> authentication, >> but how does the client get authenticated to the credential >> server ? Or am I >> missing something ? >> > -----Original Message----- > Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > Thursday, July 13, 2000 1:07 PM > 'John Hughes'; Ietf-Scared (E-mail) > RE: LDAP >> > I had believed the LDAP w/TLS was the preferred choice >> emerging from the wg. > However, when looking at all the possible >> access protocol / > network*transport layer confidentiality >> possibilities, does >> it make sense to > constrain choice to only one? >> > will there be discussion of management >> transactions (vice >> retrieval only)? > Given the potential sensitivity of the >> credential server, >> will there be > discussion of intrusion detection notifications >> above and >> beyond rudimentary > audit logs? >> > regards, > Sandi Miklos >> > -----Original Message----- > From: John Hughes [mailto:john.hughes@entegrity.com] > Sent: Thursday, July 13, 2000 4:28 AM > To: Ietf-Scared (E-mail) > Subject: LDAP >> >> > If we use LDAP (either a MUST or SHOULD) then >> we could use >> LDAP over SSL. > This would then give us both authentication to the >> credential repository > plus another layer of protection whilst the >> credential is >> being transferred. >> >> > John From owner-ietf-sacred Fri Jul 14 08:10:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA22626 for ietf-sacred-bks; Fri, 14 Jul 2000 08:10:49 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22622 for ; Fri, 14 Jul 2000 08:10:46 -0700 (PDT) Received: from bpsi.net (port414.bpsi.net [209.54.245.214]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id KAA09517; Fri, 14 Jul 2000 10:12:36 -0500 (CDT) Message-ID: <396F2D82.B0FBE7AC@bpsi.net> Date: Fri, 14 Jul 2000 10:10:59 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: David Jablon CC: John Hughes , "'Pierre Heuze'" , "'Miklos, Sue A.'" , ietf-sacred@imc.org Subject: Re: LDAP References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, Thanks for your suggestions. Additional comments inline. Best Regards, --dg David Jablon wrote: > Dale, > > In your model, and in the LDAP+TLS model that everyone seems to be > talking about, there are severe and unnecessary presumptions. > > If these presumptions are left unchallenged, the group will end up with > much weaker-than-necessary methods. > > So ... here's my challenge: > > (1) There should be no presumption that most users have any credential > other than a password. Sure, some may have smartcards, but we'd like > to accomodate a broad population. I think that's our basic assumption. > (2) There should be no presumption that the user can handle a password > of any better quality than typical passwords in use today. We must not > presume that we can design a better human. Of course. > ... and finally ... > > (3) There should be no presumption that the user can or will authenticate > the server by name ... for much the same reason as (2). Not sure what you mean here. > I think striving to meet these challenges will result in a simpler > security model that fits very well with the charter as defined so far. > And if you look for the best methods in this model, you'll invariably > find better solutions than LDAP+TLS. > -- dpj [snip] > > Sandi has asked whether all clients > > will be able to support SSL/TLS (which is very good question). > > One answer is: "No. And even if they did, they shouldn't count on the > user explicitly authenticating the server." If no, a new protocol may be needed (as Stephen suggests). If yes, connecting to a secure web server should automate server authentication by the client. [snip] > > Does that satisfy most large network replication needs? > Keeping the repository "close" to the credential server reduces the > requirement for a secure communication channel between the two. The network model, as pictured, says the two can be very close (inside the same machine) or very far away. If the data in the repository is secured such that only the credential server can access it, a secure channel between the two is somewhat redundant. I think the original issue raised by Sandi in another message is "will I be able to access my current credentials from anywhere at any time". I've inferred that we want to have credentials automatically replicated across a large network if/as/when appropriate (e.g., also assuming the credential server is an LDAP client). After a little reflection, I think I may have dived into implementation issues a little early. Without more detailed requirements, it's difficult to differentiate this from capabilities that vendors such as AOL/Netscape, Microsoft, and others already have or likely will soon provide. > > John Hughes wrote: Pierre, We will have to "bootstrap" the system > > If we use TLS > >(as one of the options) then we will have to decide if client authentication > > If it is - then how do all of the w/s that interact with the > >credential repository get a client cert/PSE. John > -----Original Message----- > >> From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] > >> Sent: 13 July 2000 14:06 > >> To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) > >> Subject: RE: LDAP > >> > >> > >> Is really w/TLS what is needed ? Might be okay for Server > >> authentication, > >> but how does the client get authenticated to the credential > >> server ? Or am I > >> missing something ? > >> > > -----Original Message----- > > Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > > Thursday, July 13, 2000 1:07 PM > > 'John Hughes'; Ietf-Scared (E-mail) > > RE: LDAP > >> > > I had believed the LDAP w/TLS was the preferred choice > >> emerging from the wg. > > However, when looking at all the possible > >> access protocol / > > network*transport layer confidentiality > >> possibilities, does > >> it make sense to > > constrain choice to only one? > >> > > will there be discussion of management > >> transactions (vice > >> retrieval only)? > > Given the potential sensitivity of the > >> credential server, > >> will there be > > discussion of intrusion detection notifications > >> above and > >> beyond rudimentary > > audit logs? > >> > > regards, > > Sandi Miklos > >> > > -----Original Message----- > > From: John Hughes [mailto:john.hughes@entegrity.com] > > Sent: Thursday, July 13, 2000 4:28 AM > > To: Ietf-Scared (E-mail) > > Subject: LDAP > >> > >> > > If we use LDAP (either a MUST or SHOULD) then > >> we could use > >> LDAP over SSL. > > This would then give us both authentication to the > >> credential repository > > plus another layer of protection whilst the > >> credential is > >> being transferred. > >> > >> > > John From owner-ietf-sacred Fri Jul 14 08:35:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA24930 for ietf-sacred-bks; Fri, 14 Jul 2000 08:35:32 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24926 for ; Fri, 14 Jul 2000 08:35:30 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA20977 for ; Fri, 14 Jul 2000 11:26:50 -0400 (EDT) Message-Id: <200007141526.LAA20955@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'Dale Gustafson'" , David Jablon Cc: John Hughes , "'Pierre Heuze'" , ietf-sacred@imc.org Subject: RE: LDAP Date: Fri, 14 Jul 2000 11:37:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: thank you for such thoughtful discussion. I am in an environment where some of the fundamental presumptions include: 1) by (optimistically) mid 2002, every entity that 'belongs' to the infrastructure will have some form of cryptographically bound identity credential (most likely a V3 X.509) that will be the basis for Identification & Authentication to any of the corporate resources; 2) the ability to acquire one's credentials must be global. We intend to have this information replicated or transparently available in one of approximately 15 'megacenters'. This precludes the host sharing of the credential server/repository in a singular location. However, if the repository and credential information require the same protection in transit, then host sharing might make sense. this tends to affect my thinking and I appreciate the wider viewpoints expressed. regards, Sandi -----Original Message----- From: Dale Gustafson [mailto:dale.gustafson@bpsi.net] Sent: Friday, July 14, 2000 11:11 AM To: David Jablon Cc: John Hughes; 'Pierre Heuze'; Miklos, Sue A.; ietf-sacred@imc.org Subject: Re: LDAP David, Thanks for your suggestions. Additional comments inline. Best Regards, --dg David Jablon wrote: > Dale, > > In your model, and in the LDAP+TLS model that everyone seems to be > talking about, there are severe and unnecessary presumptions. > > If these presumptions are left unchallenged, the group will end up with > much weaker-than-necessary methods. > > So ... here's my challenge: > > (1) There should be no presumption that most users have any credential > other than a password. Sure, some may have smartcards, but we'd like > to accomodate a broad population. I think that's our basic assumption. > (2) There should be no presumption that the user can handle a password > of any better quality than typical passwords in use today. We must not > presume that we can design a better human. Of course. > ... and finally ... > > (3) There should be no presumption that the user can or will authenticate > the server by name ... for much the same reason as (2). Not sure what you mean here. > I think striving to meet these challenges will result in a simpler > security model that fits very well with the charter as defined so far. > And if you look for the best methods in this model, you'll invariably > find better solutions than LDAP+TLS. > -- dpj [snip] > > Sandi has asked whether all clients > > will be able to support SSL/TLS (which is very good question). > > One answer is: "No. And even if they did, they shouldn't count on the > user explicitly authenticating the server." If no, a new protocol may be needed (as Stephen suggests). If yes, connecting to a secure web server should automate server authentication by the client. [snip] > > Does that satisfy most large network replication needs? > Keeping the repository "close" to the credential server reduces the > requirement for a secure communication channel between the two. The network model, as pictured, says the two can be very close (inside the same machine) or very far away. If the data in the repository is secured such that only the credential server can access it, a secure channel between the two is somewhat redundant. I think the original issue raised by Sandi in another message is "will I be able to access my current credentials from anywhere at any time". I've inferred that we want to have credentials automatically replicated across a large network if/as/when appropriate (e.g., also assuming the credential server is an LDAP client). After a little reflection, I think I may have dived into implementation issues a little early. Without more detailed requirements, it's difficult to differentiate this from capabilities that vendors such as AOL/Netscape, Microsoft, and others already have or likely will soon provide. > > John Hughes wrote: Pierre, We will have to "bootstrap" the system > > If we use TLS > >(as one of the options) then we will have to decide if client authentication > > If it is - then how do all of the w/s that interact with the > >credential repository get a client cert/PSE. John > -----Original Message----- > >> From: Pierre Heuze [mailto:Pierre.Heuze@CardBase.com] > >> Sent: 13 July 2000 14:06 > >> To: 'Miklos, Sue A.'; 'John Hughes'; Ietf-Scared (E-mail) > >> Subject: RE: LDAP > >> > >> > >> Is really w/TLS what is needed ? Might be okay for Server > >> authentication, > >> but how does the client get authenticated to the credential > >> server ? Or am I > >> missing something ? > >> > > -----Original Message----- > > Miklos, Sue A. [mailto:samiklo@missi.ncsc.mil] > > Thursday, July 13, 2000 1:07 PM > > 'John Hughes'; Ietf-Scared (E-mail) > > RE: LDAP > >> > > I had believed the LDAP w/TLS was the preferred choice > >> emerging from the wg. > > However, when looking at all the possible > >> access protocol / > > network*transport layer confidentiality > >> possibilities, does > >> it make sense to > > constrain choice to only one? > >> > > will there be discussion of management > >> transactions (vice > >> retrieval only)? > > Given the potential sensitivity of the > >> credential server, > >> will there be > > discussion of intrusion detection notifications > >> above and > >> beyond rudimentary > > audit logs? > >> > > regards, > > Sandi Miklos > >> > > -----Original Message----- > > From: John Hughes [mailto:john.hughes@entegrity.com] > > Sent: Thursday, July 13, 2000 4:28 AM > > To: Ietf-Scared (E-mail) > > Subject: LDAP > >> > >> > > If we use LDAP (either a MUST or SHOULD) then > >> we could use > >> LDAP over SSL. > > This would then give us both authentication to the > >> credential repository > > plus another layer of protection whilst the > >> credential is > >> being transferred. > >> > >> > > John **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From owner-ietf-sacred Sat Jul 15 07:53:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA28156 for ietf-sacred-bks; Sat, 15 Jul 2000 07:53:14 -0700 (PDT) Received: from front001.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28139 for ; Sat, 15 Jul 2000 07:53:03 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by front001.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 13431196; Sat, 15 Jul 2000 10:54:41 -0400 Message-Id: <3.0.5.32.20000715104756.0086d730@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 15 Jul 2000 10:47:56 -0400 To: Dale Gustafson From: David Jablon Subject: Re: LDAP (and SSL server authentication) Cc: "'Pierre Heuze'" , "'Miklos, Sue A.'" , ietf-sacred@imc.org In-Reply-To: <396F2D82.B0FBE7AC@bpsi.net> References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think we must not presume that the user will authenticate the "name" of a server. Experience with common web browsers illustrates the severe limitations of this approach. More comments are embedded below. At 10:10 AM 7/14/00 -0500, Dale Gustafson wrote: > David Jablon wrote: >> (1) There should be no presumption that most users have any credential >> other than a password. Sure, some may have smartcards, but we'd like >> to accomodate a broad population. > > I think that's our basic assumption. > >> (2) There should be no presumption that the user can handle a password >> of any better quality than typical passwords in use today. We must not >> presume that we can design a better human. > > Of course. > >> ... and finally ... >> >> (3) There should be no presumption that the user can or will authenticate >> the server by name ... for much the same reason as (2). > > Not sure what you mean here. In other words, the password and private key must remain secure even when the user cannot verify the name of the server. Security should not depend on a user action that is typically skipped. For example, browser-based SSL server authentication doesn't seem to work. When was the last time you clicked to verify a cert chain? When was the last time your Mom did, and knew what she was looking at? >> > Sandi has asked whether all clients >> > will be able to support SSL/TLS (which is very good question). >> >> One answer is: "No. And even if they did, they shouldn't count on the >> user explicitly authenticating the server." > > If no, a new protocol may be needed (as Stephen suggests). > > If yes, connecting to a secure web server should automate server authentication by > the client. This is a good analysis. I think your wording that the system "should automate server authentication by the client" could be part of our requirements, and this too may drive the protocol selection process. For example, in something like SSL server authentication, we can't assume that the server "automates" the actions of a human. It doesn't work that way. In contrast, consider systems where a password provides mutual authentication. The user gets direct evidence of the identity of the server, in a step that the user can't skip or ignore. In this case, the credential server proves to the client that it has the credential that corresponds to the password. This does raise an important issue: Is the credential stored on the server a sensitive user secret, or is it public information? For the case where the user only has a password, the credential must be considered sensitive user data. Years of experience have taught us to keep even hashed password files secure from public view. This also implies that the credential server assumes at least partial responsibility for protecting the credential from disclosure. > I think the original issue raised by Sandi in another message is "will I be able to > access my current credentials from anywhere at any time". I've inferred that we > want to have credentials automatically replicated across a large network if/as/when > appropriate (e.g., also assuming the credential server is an LDAP client). In any case, it seems important to consider the sensitive nature of credentials in any replication mechanism. > After a little reflection, I think I may have dived into implementation issues a > little early. Without more detailed requirements, it's difficult to differentiate > this from capabilities that vendors such as AOL/Netscape, Microsoft, and others > already have or likely will soon provide. I think exploring implementation is fine at this stage, for the purposes of discussion, because it sheds light on these issues. -- dpj From owner-ietf-sacred Sat Jul 15 07:53:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA28149 for ietf-sacred-bks; Sat, 15 Jul 2000 07:53:05 -0700 (PDT) Received: from front001.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28144 for ; Sat, 15 Jul 2000 07:53:04 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by front001.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 13431197; Sat, 15 Jul 2000 10:54:42 -0400 Message-Id: <3.0.5.32.20000715105012.008d5c20@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 15 Jul 2000 10:50:12 -0400 To: "Miklos, Sue A." From: David Jablon Subject: RE: LDAP (and replication) Cc: "'Dale Gustafson'" , John Hughes , "'Pierre Heuze'" , ietf-sacred@imc.org In-Reply-To: <200007141526.LAA20955@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:37 AM 7/14/00 -0400, Miklos, Sue A. wrote: >I am in an environment where some of the fundamental presumptions include: > >1) by (optimistically) mid 2002, every entity that 'belongs' to the >infrastructure will have some form of cryptographically bound identity >credential (most likely a V3 X.509) that will be the basis for >Identification & Authentication to any of the corporate resources; I'm always amused when I hear "people" referred to as "entities". :-) I presume that in this model the human entities that "belong to the infrastructure" are also cryptographically bound to it in a specific way. Do you have plans for how this will be done, or is this more of a requirements statement for your environment? >2) the ability to acquire one's credentials must be global. We intend to >have this information replicated or transparently available in one of >approximately 15 'megacenters'. This precludes the host sharing of the >credential server/repository in a singular location. However, if the >repository and credential information require the same protection in >transit, then host sharing might make sense. I think the credential repository and the credential information in transit deserve equal levels of protection. And credentials related to a password must be presumed to be sensitive data, as I briefly discussed in another thread. Clearly replicating public information would be easy, while replicating sensitive data requires that the servers provide some suitable level of protection for the channels. I do see that when considering a specific method, it may be difficult to assess whether the risks of decentralization outweigh the benefits. But somebody has to do it. -- dpj From owner-ietf-sacred Mon Jul 17 01:38:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06217 for ietf-sacred-bks; Mon, 17 Jul 2000 01:38:59 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06212 for ; Mon, 17 Jul 2000 01:38:58 -0700 (PDT) Received: from cooper (195.222.54.3 [195.222.54.3]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYL5CS9; Mon, 17 Jul 2000 01:48:33 -0700 Message-Id: <3.0.5.32.20000717103610.013db200@mail.cost.se> X-Sender: nada@mail.cost.se (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 17 Jul 2000 10:36:10 +0200 To: ietf-sacred@imc.org From: Nada Kapidzic Cicovic Subject: patents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In parallel with proposing the solution for the problem of remote credentials, we should also be careful not to hit against any of the existing patents. I heard that there are some held in this area. Do any of you have details on any of the existing patents? Regards, Nada From owner-ietf-sacred Mon Jul 17 04:52:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA12363 for ietf-sacred-bks; Mon, 17 Jul 2000 04:52:42 -0700 (PDT) Received: from front001.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA12359 for ; Mon, 17 Jul 2000 04:52:41 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by front001.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 13517589; Mon, 17 Jul 2000 07:54:31 -0400 Message-Id: <3.0.5.32.20000717075029.007c1de0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 17 Jul 2000 07:50:29 -0400 To: Nada Kapidzic Cicovic From: David Jablon Subject: Re: patents Cc: ietf-sacred@imc.org In-Reply-To: <3.0.5.32.20000717103610.013db200@mail.cost.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:36 AM 7/17/00 +0200, Nada Kapidzic Cicovic wrote: > In parallel with proposing the solution for the problem of remote > credentials, we should also be careful not to hit against any of the > existing patents. I heard that there are some held in this area. I disagree. Patents are not the primary issue, and treating them as such by avoiding them too early in the process reveals a design philosophy based on fear. This will preclude *any* innovative solution. No matter how careful you are, there is always a risk that a pending patent can surface to cover your approach. This is true even if you think you're being careful to limit yourself to using no technology developed in, say, the past ten years. If you have a primary fear of patents, you'll have to stear clear of all innovation, including your own. A better approach is to provide user choice, in the face of uncertainty. Make a reasonable attempt during the design process to avoid being blocked by any single known issued patent. But if a really good patented solution is found, it is only reasonable to include that solution as an option. Obviously, an attempt should also be made to include comparable methods, for which the patent status is often unknown . -- dpj --------------------------------------------------- David P. Jablon dpj@world.std.com www.IntegritySciences.com From owner-ietf-sacred Mon Jul 17 05:16:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12629 for ietf-sacred-bks; Mon, 17 Jul 2000 05:16:02 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12623 for ; Mon, 17 Jul 2000 05:16:00 -0700 (PDT) Received: by balinese.baltimore.ie; id NAA22597; Mon, 17 Jul 2000 13:18:20 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma022551; Mon, 17 Jul 00 13:17:43 +0100 Received: from baltimore.ie (lease216-21.baltimore.ie [192.168.21.216]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA25659; Mon, 17 Jul 2000 13:17:42 +0100 Message-ID: <3972F97D.DDCC2C34@baltimore.ie> Date: Mon, 17 Jul 2000 13:18:05 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: Nada Kapidzic Cicovic , ietf-sacred@imc.org, xme Subject: Re: patents References: <3.0.5.32.20000717075029.007c1de0@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave, Nada, My take on this is that we have to do two things if we're to succeed: - since there are many relevant techniques in existence, (and they're evolving), we should not preclude extensions (that may, or may not, be encumbered) - in my mind that means we probably need to have an extensible framework, - however, we'll fail if we don't figure out a "secure-enough", working, interoperable, solution where all the MUSTs are acceptable in the IETF context (see rfc2026). So, in a sense you're both right. For now though, I don't think its really productive for us to enter into IPR dicussions, since its not directly relevant to a charter or requirements (unless someone chooses to donate their IPR for free, of course:-). If it turns out that the requirements we end up with require encumbered technology, then so be it, we live with that (or, quite possibly, the putative WG dies with that:-). In any case, this list is definitely not a forum for generic discussion of IPR, standards and innovation. So, let's get back to sacred charter/requirements. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Jul 17 05:35:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13001 for ietf-sacred-bks; Mon, 17 Jul 2000 05:35:04 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12997 for ; Mon, 17 Jul 2000 05:35:02 -0700 (PDT) Received: by balinese.baltimore.ie; id NAA26465; Mon, 17 Jul 2000 13:37:23 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma026356; Mon, 17 Jul 00 13:36:25 +0100 Received: from baltimore.ie (lease216-21.baltimore.ie [192.168.21.216]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA26164; Mon, 17 Jul 2000 13:36:24 +0100 Message-ID: <3972FDE0.15F20122@baltimore.ie> Date: Mon, 17 Jul 2000 13:36:48 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: "'Roaming Credentials List'" , xme Subject: Re: Premise question: serverless models? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, I think the idea of serverless transfer is interesting, but I'm not sure how it would work, except if one of the devices has the capability to act as a server. Do you think that there's a real serverless option here, where neither device is capable of being a server (say a pot and a kettle)? Or do you mean where there may be an untrusted server (say an SMTP server) as an intermediary? I've no problem including in scope the case where a client device can also act as the server. Stephen. "Linn, John" wrote: > > Much of the discussion here so far has been emphasizing elements of > "upload", "download", and "credential server". Given that a primary use for > credential transfer could be to get a user's credentials from one of the > user's devices to another of the user's devices, a third-party intermediary > server might not always be necessary; if feasible, a direct peer-peer > transfer between the user's devices would avoid potential compromise at the > intermediary. Should consideration of both server-based and serverless > models be identified explicitly in the charter? > > --jl -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Jul 17 06:57:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14494 for ietf-sacred-bks; Mon, 17 Jul 2000 06:57:21 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14489 for ; Mon, 17 Jul 2000 06:57:20 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jul 2000 13:59:37 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA05506; Mon, 17 Jul 2000 09:58:33 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jul 2000 09:59:38 -0400 Message-ID: From: "Linn, John" To: "'stephen.farrell@baltimore.ie'" Cc: "'Roaming Credentials List'" Subject: RE: Premise question: serverless models? Date: Mon, 17 Jul 2000 09:59:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen, I'm thinking of cases where there's no intermediary server at the credential transfer protocol layer, and hence so that there's a single unbroken hop for the protections that layer provides. It could be possible to accomplish this by having a device operate as a server, given that the protocol doesn't preclude two server-capable devices from interworking with each other. There can certainly be intermediaries lower in the protocol stack, but these shouldn't be visible or need to be trusted for purposes of the credential transfer protocol. --jl > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: Monday, July 17, 2000 8:37 AM > To: Linn, John > Cc: 'Roaming Credentials List'; xme > Subject: Re: Premise question: serverless models? > > > > John, > > I think the idea of serverless transfer is interesting, but I'm > not sure how it would work, except if one of the devices has the > capability to act as a server. Do you think that there's a > real serverless option here, where neither device is capable > of being a server (say a pot and a kettle)? Or do you mean > where there may be an untrusted server (say an SMTP server) > as an intermediary? > > I've no problem including in scope the case where a client > device can also act as the server. > > Stephen. > > "Linn, John" wrote: > > > > Much of the discussion here so far has been emphasizing elements of > > "upload", "download", and "credential server". Given that > a primary use for > > credential transfer could be to get a user's credentials > from one of the > > user's devices to another of the user's devices, a > third-party intermediary > > server might not always be necessary; if feasible, a direct > peer-peer > > transfer between the user's devices would avoid potential > compromise at the > > intermediary. Should consideration of both server-based > and serverless > > models be identified explicitly in the charter? > > > > --jl > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com > From owner-ietf-sacred Mon Jul 17 08:52:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17305 for ietf-sacred-bks; Mon, 17 Jul 2000 08:52:28 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17301 for ; Mon, 17 Jul 2000 08:52:26 -0700 (PDT) Received: from bpsi.net (port411.bpsi.net [209.54.245.211]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id KAA01729; Mon, 17 Jul 2000 10:54:34 -0500 (CDT) Message-ID: <39732BD8.6CC03FC8@bpsi.net> Date: Mon, 17 Jul 2000 10:52:56 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: David Jablon CC: "'Pierre Heuze'" , "'Miklos, Sue A.'" , ietf-sacred@imc.org Subject: Re: LDAP (and SSL server authentication) References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> <3.0.5.32.20000715104756.0086d730@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, Comments inline. Best Regards, --dg David Jablon wrote: > I think we must not presume that the user will authenticate the > "name" of a server. Experience with common web browsers illustrates > the severe limitations of this approach. > > More comments are embedded below. [snip] > >> > Sandi has asked whether all clients > >> > will be able to support SSL/TLS (which is very good question). > >> > >> One answer is: "No. And even if they did, they shouldn't count on the > >> user explicitly authenticating the server." > > > > If no, a new protocol may be needed (as Stephen suggests). > > > > If yes, connecting to a secure web server should automate server authentication by > > the client. > > This is a good analysis. I think your wording that the system "should automate > server authentication by the client" could be part of our requirements, > and this too may drive the protocol selection process. > > For example, in something like SSL server authentication, we can't assume > that the server "automates" the actions of a human. It doesn't work that way. My recollection is that the browser sends a random value which the server signs using it's private key. The browser verifies the SSL server's certificate and every other cert in the chain as part of server signature validation which should work so long as the browser's configured with the necessary "root certificate" which was delivered to the client by an out-of-band method. Is that what you mean? > In contrast, consider systems where a password provides mutual authentication. > The user gets direct evidence of the identity of the server, in a step that the > user can't skip or ignore. In this case, the credential server proves to > the client that it has the credential that corresponds to the password. It sounds like you're suggesting a special method that could be used in the process of obtaining an initial credential. That's something the group may want to discuss. This work should not (and need not) get entangled in IPR issues. Hopefully, an installed credential will be complete such that it will work correctly with a browser and other secure applications. > This does raise an important issue: > > Is the credential stored on the server a sensitive user secret, > or is it public information? > > For the case where the user only has a password, the credential must be > considered sensitive user data. Years of experience have taught us to keep > even hashed password files secure from public view. This also implies > that the credential server assumes at least partial responsibility for > protecting the credential from disclosure. Probably both. In the context of a credentail server, user data should be fully protected to minimize privacy concerns. Since the credential server decides who/what/when to release credentials to a user, it must have significant responsibility for protecting user information from unauthorized disclosure. > > I think the original issue raised by Sandi in another message is "will I be able to > > access my current credentials from anywhere at any time". I've inferred that we > > want to have credentials automatically replicated across a large network if/as/when > > appropriate (e.g., also assuming the credential server is an LDAP client). > > In any case, it seems important to consider the sensitive nature of credentials > in any replication mechanism. It may be that repositories don't need to know how to decrypt the data stored by credential servers. [snip] From owner-ietf-sacred Mon Jul 17 13:51:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA23496 for ietf-sacred-bks; Mon, 17 Jul 2000 13:51:48 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23492 for ; Mon, 17 Jul 2000 13:51:47 -0700 (PDT) Received: from rhousley_laptop (dhcp-3.spyrus.com [207.212.34.162]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA08158; Mon, 17 Jul 2000 13:53:35 -0700 (PDT) Message-Id: <4.2.0.58.20000717142400.00ab88e0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 17 Jul 2000 14:27:50 -0400 To: "Linn, John" From: Russ Housley Subject: Re: Premise question: serverless models? Cc: "'Roaming Credentials List'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John: I support this concept. There are several situations where this makes sense, but isn't this unnecessary in others. For example, a simple transfer of a PKCS#12 between a desktop and a hand-held computer may be adequate. How do we characterize the peer-to-peer transfers that we want to address? Russ At 08:50 AM 07/13/2000 -0400, Linn, John wrote: >Much of the discussion here so far has been emphasizing elements of >"upload", "download", and "credential server". Given that a primary use for >credential transfer could be to get a user's credentials from one of the >user's devices to another of the user's devices, a third-party intermediary >server might not always be necessary; if feasible, a direct peer-peer >transfer between the user's devices would avoid potential compromise at the >intermediary. Should consideration of both server-based and serverless >models be identified explicitly in the charter? > >--jl From owner-ietf-sacred Mon Jul 17 17:11:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27149 for ietf-sacred-bks; Mon, 17 Jul 2000 17:11:31 -0700 (PDT) Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27145 for ; Mon, 17 Jul 2000 17:11:29 -0700 (PDT) Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id UAA07490; Mon, 17 Jul 2000 20:13:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <39732BD8.6CC03FC8@bpsi.net> References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> <3.0.5.32.20000715104756.0086d730@world.std.com> <39732BD8.6CC03FC8@bpsi.net> Date: Mon, 17 Jul 2000 18:04:06 -0400 To: Dale Gustafson From: Stephen Kent Subject: Re: LDAP (and SSL server authentication) Cc: ietf-sacred@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:52 AM -0500 7/17/00, Dale Gustafson wrote: > > >My recollection is that the browser sends a random value which the >server signs using it's >private key. The browser verifies the SSL server's certificate and >every other cert in the >chain as part of server signature validation which should work so >long as the browser's >configured with the necessary "root certificate" which was delivered >to the client by an >out-of-band method. Is that what you mean? Just a quick note that this is not how SSL works. In SSL, the server sends its certificate and the user encrypts a locally generated PRNG value with the server's public key. That value becomes part of the later computation of the encryption and authentication keys used by SSL. Server authentication is indirect, i.e., unless the server holds the private key corresponding public key in the server cert, it will not be able to decrypt the secret value from the client and will not be able to complete the SSL connection. Steve From owner-ietf-sacred Mon Jul 17 19:06:06 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA06082 for ietf-sacred-bks; Mon, 17 Jul 2000 19:06:06 -0700 (PDT) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06075 for ; Mon, 17 Jul 2000 19:06:04 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000718020828.GFAA2546.mail.rdc1.md.home.com@home.com>; Mon, 17 Jul 2000 19:08:28 -0700 Message-ID: <3973BC0A.D8E46076@home.com> Date: Mon, 17 Jul 2000 22:08:10 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Russ Housley CC: "Linn, John" , "'Roaming Credentials List'" Subject: Re: Premise question: serverless models? References: <4.2.0.58.20000717142400.00ab88e0@mail.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I believe that work needs to be done to support both "server-based" and "server-less" models. The requirement for the former is fairly obvious; it is needed to support the notion of a "remote wallet" that can be accessed by a user with whatever device is appropriate at the time. (E.g., I use a "remote wallet" server to store my credentials, which, at appropriate times, I can download into my cell phone, my pager, my PDA, ...) The requirement for "server-less" models also exists, I believe, and John has done a good job of summing it up. The case may exist where my credentials are held in my laptop. I want to transfer (copy? move?) them to my PDA. I'd prefer not to use a complex "credential server" to facilitate the transfer; I just want to move the file(s) necessary from one device currently in my position to another device currently in my possession. Now, how this is to be achieved with a relative level of security ought to be a major goal of this "community" (since it's not a "group" yet :-). It may be that, as Russ suggests, a simple transfer of a PKCS12 object will be sufficient. It may be that something more complex, or more flexible, is required. But the requirement, I believe, is there. So, in answer to Russ's question, "How do we characterize the peer-to-peer transfers that we want to address?", I believe that we need to support: - peer-to-peer transfers that use a credential server as an intermediary; and - peer-to-peer transfers that appear at the credential layer to be direct; i.e., there is no intermediate hop through a credential server. Al Arsenault Chief Security Architect Diversinet Corp. Russ Housley wrote: > > John: > > I support this concept. There are several situations where this makes > sense, but isn't this unnecessary in others. For example, a simple > transfer of a PKCS#12 between a desktop and a hand-held computer may be > adequate. > > How do we characterize the peer-to-peer transfers that we want to address? > > Russ > > At 08:50 AM 07/13/2000 -0400, Linn, John wrote: > >Much of the discussion here so far has been emphasizing elements of > >"upload", "download", and "credential server". Given that a primary use for > >credential transfer could be to get a user's credentials from one of the > >user's devices to another of the user's devices, a third-party intermediary > >server might not always be necessary; if feasible, a direct peer-peer > >transfer between the user's devices would avoid potential compromise at the > >intermediary. Should consideration of both server-based and serverless > >models be identified explicitly in the charter? > > > >--jl From owner-ietf-sacred Tue Jul 18 04:13:52 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA11193 for ietf-sacred-bks; Tue, 18 Jul 2000 04:13:52 -0700 (PDT) Received: from front002.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11189 for ; Tue, 18 Jul 2000 04:13:50 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by front002.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 13310395; Tue, 18 Jul 2000 07:14:46 -0400 Message-Id: <3.0.5.32.20000717232941.0079e4a0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 17 Jul 2000 23:29:41 -0400 To: Dale Gustafson From: David Jablon Subject: Re: LDAP (and SSL server authentication) Cc: "'Pierre Heuze'" , "'Miklos, Sue A.'" , ietf-sacred@imc.org In-Reply-To: <39732BD8.6CC03FC8@bpsi.net> References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> <3.0.5.32.20000715104756.0086d730@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dale, I think I need to elaborate more on my issue with user participation in SSL server authentication. See below. -- David At 10:52 AM 7/17/00 -0500, Dale Gustafson wrote: >David Jablon wrote: >> I think we must not presume that the user will authenticate the >> "name" of a server. Experience with common web browsers illustrates >> the severe limitations of this approach. >> >> More comments are embedded below. > >[snip] > >> >> > Sandi has asked whether all clients >> >> > will be able to support SSL/TLS (which is very good question). >> >> >> >> One answer is: "No. And even if they did, they shouldn't count on the >> >> user explicitly authenticating the server." >> > >> > If no, a new protocol may be needed (as Stephen suggests). >> > >> > If yes, connecting to a secure web server should automate server authentication by >> > the client. >> >> This is a good analysis. I think your wording that the system "should automate >> server authentication by the client" could be part of our requirements, >> and this too may drive the protocol selection process. >> >> For example, in something like SSL server authentication, we can't assume >> that the server "automates" the actions of a human. It doesn't work that way. > >My recollection is that the browser sends a random value which the server signs using it's >private key. The browser verifies the SSL server's certificate and every other cert in the >chain as part of server signature validation which should work so long as the browser's >configured with the necessary "root certificate" which was delivered to the client by an >out-of-band method. Is that what you mean? Actually, that's beside the point. My issue is that all this browser crypto activity is worthless if it doesn't authenticate the server that the user expects. This model is easy to attack because the user is a passive participant, who may not be at all aware of what's really going on underneath. >From a user perspective, all this cert-checking and crypto activity is in vain when someone tricks the user into connecting to the wrong server. Or, in a related attack, none of these actions occur at all because the user doesn't notice the state of the "secure" icon at the right time, and thus reaches a cloned insecure page. This is a fundamental flaw in a system where server-authentication is a passive act. It is a crucial flaw when server-authentication is needed to protect subsequent user authentication. Mutual authentication is stronger. But it is trickier, and not provided by SSL today, when a user doesn't have a full-strength private key. >> In contrast, consider systems where a password provides mutual authentication. >> The user gets direct evidence of the identity of the server, in a step that the >> user can't skip or ignore. In this case, the credential server proves to >> the client that it has the credential that corresponds to the password. > >It sounds like you're suggesting a special method that could be used in the process of >obtaining an initial credential. That's something the group may want to discuss. This >work should not (and need not) get entangled in IPR issues. Yes, though I'm not sure what you mean by "obtaining an initial credential". I'm assuming the user is enrolled somewhere and has a secret private key, stored somewhere other than on the client. The trick is to get it to the user, without requiring other machine-stored credentials to be already in the user's possession. >Hopefully, an installed credential will be complete such that it will work correctly with a >browser and other secure applications. Sure, though I would modify "browser and other" to "browser or other". One application might need to install a user's private key on-the-fly so that the browser can use it for SSL client authentication. Another application might not need SSL at all, and instead use the private key directly. In either case, we might focus first on the protocol to get the private key securely to the client. >> This does raise an important issue: >> >> Is the credential stored on the server a sensitive user secret, >> or is it public information? >> >> For the case where the user only has a password, the credential must be >> considered sensitive user data. Years of experience have taught us to keep >> even hashed password files secure from public view. This also implies >> that the credential server assumes at least partial responsibility for >> protecting the credential from disclosure. > >Probably both. In the context of a credentail server, user data should be fully protected >to minimize privacy concerns. Yes, our terminology for user "credential" may be getting overused, as it seems to encompass both public and private parts, and both stored and memorized parts. >Since the credential server decides who/what/when to release credentials to a user, it must >have significant responsibility for protecting user information from unauthorized >disclosure. I believe so. -- dpj From owner-ietf-sacred Tue Jul 18 06:19:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA19007 for ietf-sacred-bks; Tue, 18 Jul 2000 06:19:02 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19002 for ; Tue, 18 Jul 2000 06:19:00 -0700 (PDT) Received: by balinese.baltimore.ie; id OAA10626; Tue, 18 Jul 2000 14:21:25 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010577; Tue, 18 Jul 00 14:20:49 +0100 Received: from baltimore.ie (lease179-20.baltimore.ie [192.168.20.179]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA28874; Tue, 18 Jul 2000 14:20:49 +0100 Message-ID: <397459C9.AD59D705@baltimore.ie> Date: Tue, 18 Jul 2000 14:21:13 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: xme , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: timing.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, Although the agenda doesn't show it yet, the BOF description (http://www.ietf.org/ietf/00aug/sacred-agenda.txt) shows us meeting Tuesday 1700-1800. If you'd like to get a slot on the agenda, can you let myself and/or magnus know in the next couple of days? Given that we've only an hour, and have to cover charter discussion, slots will have to be short (~5 minutes). Also, it'll help if we can get specific charter comments (i.e. suggested changes) so we can do up another draft charter during next week for discussion at the meeting. So far I don't think we've had much that'd be controversial at the level of the charter, so let's see if we can get that mostly done before arriving in Pittsburgh. Thanks, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Jul 18 06:42:41 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA20575 for ietf-sacred-bks; Tue, 18 Jul 2000 06:42:41 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20570 for ; Tue, 18 Jul 2000 06:42:40 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA09696 for ; Tue, 18 Jul 2000 09:33:43 -0400 (EDT) Message-Id: <200007181333.JAA09679@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'David Jablon'" Cc: "'Dale Gustafson'" , John Hughes , "'Pierre Heuze'" , ietf-sacred@imc.org Subject: RE: LDAP (and replication) Date: Tue, 18 Jul 2000 09:45:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:37 AM 7/14/00 -0400, Miklos, Sue A. wrote: >I am in an environment where some of the fundamental presumptions include: > >1) by (optimistically) mid 2002, every entity that 'belongs' to the >infrastructure will have some form of cryptographically bound identity >credential (most likely a V3 X.509) that will be the basis for >Identification & Authentication to any of the corporate resources; I'm always amused when I hear "people" referred to as "entities". :-) I presume that in this model the human entities that "belong to the infrastructure" are also cryptographically bound to it in a specific way. (SM) In this case we are referring to humans, devices and application processes when we say "entities". Managing the initial registration has turned into quite an exercise. Attempting to define the strategy for integrating management into the wide variety of devices has also become extremely interesting. Do you have plans for how this will be done, or is this more of a requirements statement for your environment? (SM) The largest challenge, by far, has been the search for that 'authoritative data source' that the registration manager taps into, to find the identity. We are planning on utilizing existing eligibility databases for the 'human entities' who are organization employees, or actually have 'seats' inside the facilities. We have found some candidate databases for 'visiting human entities' who are not native members or directly funded by the organization. We have begun the laborious task of identifying the data sources for devices, and expect this to be incomplete by 2002. >2) the ability to acquire one's credentials must be global. We intend to >have this information replicated or transparently available in one of >approximately 15 'megacenters'. This precludes the host sharing of the >credential server/repository in a singular location. However, if the >repository and credential information require the same protection in >transit, then host sharing might make sense. I think the credential repository and the credential information in transit deserve equal levels of protection. And credentials related to a password must be presumed to be sensitive data, as I briefly discussed in another thread. Clearly replicating public information would be easy, while replicating sensitive data requires that the servers provide some suitable level of protection for the channels. I do see that when considering a specific method, it may be difficult to assess whether the risks of decentralization outweigh the benefits. But somebody has to do it. (SM) availability (bandwidth as well as server performance) preclude a completely centralized solution, which we've already learned. thus, we must decentralize and must figure out the least risky means. The notion of off-line encryption/decryption and using the 'encrypted attribute variant' is appealing, but then we must also work through the key management issues associated with that path. Regards, Sandi **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From owner-ietf-sacred Tue Jul 18 10:24:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02676 for ietf-sacred-bks; Tue, 18 Jul 2000 10:24:55 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02672 for ; Tue, 18 Jul 2000 10:24:53 -0700 (PDT) Received: from bpsi.net (port400.bpsi.net [209.54.245.200]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id MAA13838; Tue, 18 Jul 2000 12:27:04 -0500 (CDT) Message-ID: <39749372.F1B33692@bpsi.net> Date: Tue, 18 Jul 2000 12:27:14 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.7 [en]C-NSCPCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: "'Pierre Heuze'" , "'Miklos, Sue A.'" , ietf-sacred@imc.org Subject: Re: LDAP (and SSL server authentication) References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> <3.0.5.32.20000715104756.0086d730@world.std.com> <3.0.5.32.20000717232941.0079e4a0@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, Comments inline. Best Regards, --dg David Jablon wrote: > Dale, > > I think I need to elaborate more on my issue with > user participation in SSL server authentication. See below. > > -- David [snip] > This is a fundamental flaw in a system where server-authentication is a passive act. > It is a crucial flaw when server-authentication is needed to protect subsequent > user authentication. > > Mutual authentication is stronger. But it is trickier, and not provided by SSL today, > when a user doesn't have a full-strength private key. The type of mutual authentication you describe is achieved by various out-of-band methods today. The start-up/restart method is as secure as the manual procedure actually used for each event. Do you want to suggest something at this point ? > >> In contrast, consider systems where a password provides mutual authentication. > >> The user gets direct evidence of the identity of the server, in a step that the > >> user can't skip or ignore. In this case, the credential server proves to > >> the client that it has the credential that corresponds to the password. > > > >It sounds like you're suggesting a special method that could be used in the process of > >obtaining an initial credential. That's something the group may want to discuss. This > >work should not (and need not) get entangled in IPR issues. > > Yes, though I'm not sure what you mean by "obtaining an initial credential". I was thinking of a bootstrap process whereby a first user (with credential) is trusted to fetch them for other users or where the first keypair/cert could be used by an end user to securely obtain subsequent ones. [snip] > Yes, our terminology for user "credential" may be getting overused, as it seems to > encompass both public and private parts, and both stored and memorized parts. private/public key pair, certificate, secret key, application-specific data, device-specific data (optional) ... > >Since the credential server decides who/what/when to release credentials to a user, it must > >have significant responsibility for protecting user information from unauthorized > >disclosure. > > I believe so. > > -- dpj From owner-ietf-sacred Tue Jul 18 11:40:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04244 for ietf-sacred-bks; Tue, 18 Jul 2000 11:40:03 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04240 for ; Tue, 18 Jul 2000 11:40:01 -0700 (PDT) Received: from bpsi.net (port419.bpsi.net [209.54.245.219]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id NAA17373; Tue, 18 Jul 2000 13:42:22 -0500 (CDT) Message-ID: <3974A517.C3F029AF@bpsi.net> Date: Tue, 18 Jul 2000 13:42:31 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.7 [en]C-NSCPCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ietf-sacred@imc.org Subject: Re: LDAP (and SSL server authentication) References: <000901bfeccc$816c1190$1138d90a@johnhughes.cost.se> <3.0.5.32.20000713192423.00815510@world.std.com> <3.0.5.32.20000715104756.0086d730@world.std.com> <39732BD8.6CC03FC8@bpsi.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Stephen, Yes, my recollection re: SSL server authentication was indeed incorrect and thanks for pointing that out. Clearly, I should have checked my facts more carefully. As you noted, The client computes a pre-master secret value then encrypts it using the server's public key. The server must possess the corresponding private key in order to decrypt and use this value. It's the client that does the signing; in the reverse direction (and only if the server has requested client authentication). The client uses it's private key to create a "CertificateVerify" message that essentially signs a master secret and all preceding handshake messages sent by either party. My apologies if this caused anyone any inconvenience. Best Regards, --dg From owner-ietf-sacred Tue Jul 18 16:41:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA11398 for ietf-sacred-bks; Tue, 18 Jul 2000 16:41:49 -0700 (PDT) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11393 for ; Tue, 18 Jul 2000 16:41:48 -0700 (PDT) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.2.4) with ESMTP id 2565224 for ietf-sacred@imc.org; Tue, 18 Jul 2000 18:44:16 -0500 Date: Tue, 18 Jul 2000 18:44:16 -0500 (CDT) From: Eric Norman To: Sacred list Subject: Message to self model In-Reply-To: <3973BC0A.D8E46076@home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 17 Jul 2000, Al Arsenault wrote: > - peer-to-peer transfers that use a credential server as an > intermediary; and > - peer-to-peer transfers that appear at the credential layer to be > direct; i.e., there is no intermediate hop through a credential server. I have a different perspective on the personal preferences and mobility problem and I wonder if it could simplify anything. I view saving my certificates, keys, and other personal stuff for later retrieval as nothing more than sending a message to myself. In Alice -> Bob lingo, this means that Alice and Bob are the same person. The only authentication that needs to happen is that Alice (aka Bob) has to know that the bunch of bits that she is currently retrieving is the bunch of bits that she sent to herself when she saved them. What this means is that simple old symmetric key cryptography can be used to protect that bunch of bits. Since Alice and Bob are the same person, the encryption key needn't be shared. Alice can take advantage of the authentication that you "get for free" with symmetric key algorithms; that is, she knows that the message that she got back is the one she sent merely from the fact that it decrypted correctly (the decryption "makes sense" instead of being garbage). The symmetric key can be stored on a token, derived from a passphrase, or perhaps even derived from personal entropy (see http://www.counterpane.com/personal-entropy.html). If there's an intermediate server involved, the only thing that you might really need to worry about is the denial of service that can obtain if the server allows someone to write their stuff on top of someone elses stuff. Perhaps the server just needs to provide a pool of storage space and some mechanism (perhaps derived from a one-way hash of Alice's secret) so that Alice can find her allocated space. Think of a bank of storage lockers at an airport or bus station. Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". From owner-ietf-sacred Wed Jul 19 07:48:48 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA07547 for ietf-sacred-bks; Wed, 19 Jul 2000 07:48:48 -0700 (PDT) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07541 for ; Wed, 19 Jul 2000 07:48:47 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000719145117.YLNA2546.mail.rdc1.md.home.com@home.com> for ; Wed, 19 Jul 2000 07:51:17 -0700 Message-ID: <3975C05A.C34A14B@home.com> Date: Wed, 19 Jul 2000 10:51:06 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred@imc.org Subject: Comments on draft Charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steven, Magnus, et alia, Some comments on the draft charter as posted on www.imc.org/ietf-sacred. I've first made the comments & explained them, and then provided a proposed rewritten charter at the end: Comments: 1. Change "smart card" throughout the document to "hardware token". While smart cards are the most commonly used hardware tokens in use today, they're not the only ones. And, the security features attributed to smart cards in the draft charter can also be ascribed to, e.g., PCMCIA cards. 2. Per some of the discussion on the mailing list, I believe that the charter should be expanded from only considering the case where a credentials server is involved. I believe that we also need to consider the case where credentials are transferred directly from device to device; e.g., from mobile phone to PDA, without benefit of an intermediate credentials server. (It may be the case that we wind up with an SCTP - Simple Credentials Transfer Protocol - that works something like SMTP, in which devices exhibit both client and server behavior. But I'd prefer to not be locked into that architecture now.) 3. Delete the current second paragraph; it describes the operation of a protocol and is somewhat extraneous to the charter. 4. Do we need to define terms like "hot desking", "kiosk" style operation, and "free-seating"? I'm comfortable with their meanings, and thus haven't inserted definitions into the revision below, but it may be an issue. 5. I don't understand the fifth paragraph (begins, "Finally some applications may benefit..." ) in the current charter - I don't know what you mean here. Are you actually going to physically move during operation a set of credentials from a phone to a smart card inserted into that phone? So, I left this paragraph out of the proposed rewrite. 6. I cleaned up a few grammatical nits, and almost certainly inserted a few of my own. :-) Proposed Revision: So, here's my proposal for a rewritten first paragraph (plus new paragraphs to be inserted): ____________start proposed revision_____________ A nice feature of PKIs using hardware tokens (e.g., smart cards, PCMCIA cards) is the "free-seating solution," or the portabilty of the user's credentials. In many situations, 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. (In general, the security provided by systems using such 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 environment, the security offered by the soft tokens will be sufficient.) Even in some cases where real hardware tokens are used, there may be some benefit to using such a protocol - e.g. when a new token is received, but "old" credentials should be used. If the tokens offered the appropriate install and delete interfaces, then the credentials could be (securely) moved between tokens. Many desktop applications also require mobility of credentials, for example to support some "kiosk" style operation, when a user upgrades a PC, or when "hot-desking". It is sometimes required to integrate such credential mobility with single-sign-on solutions. A protocol that could be used in the hardware token case can also be used to solve this case. There are two different types of solutions for providing software credential mobility. The first type 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 indefinitely and downloaded when needed by the same or a different device (e.g., a mobile phone, PDA, or laptop computer). The second type of solution involves the "direct" transfer of credentials from one device to another (e.g., from a mobile phone to a PDA). While there certainly may be some other devices involved in the transfer providing lower-layer protocol translation, at the credential-transfer level, there are no intermediate devices, and the transfer is direct. While it is possible that a single approach can be found that works for both types of credential transfer described above, it is quite likely that at least two 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 entities should be allowed to download credentials, credentials must be protected against eavesdropping and cut & paste attacks; attackers must not be able to succesfully replace an entity's credentials at a credential server; etc. Availability is also at a premium. A credential server must be reachable from 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 such a solution, and to develop, adapt, or adopt the required protocols and credential formats. ___________ end of proposed rewrite ________________________ Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-sacred Wed Jul 19 07:58:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07761 for ietf-sacred-bks; Wed, 19 Jul 2000 07:58:57 -0700 (PDT) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07757 for ; Wed, 19 Jul 2000 07:58:56 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000719150127.YQZX2546.mail.rdc1.md.home.com@home.com> for ; Wed, 19 Jul 2000 08:01:27 -0700 Message-ID: <3975C2BE.D0B8231@home.com> Date: Wed, 19 Jul 2000 11:01:18 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred@imc.org Subject: Comments on Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen, Magnus, et alia, The only major comment I have on this draft is that it only addresses the "credential server" aspect of the solution set. If the working group (if there is one :-) decides to handle both cases, then either a companion document will be needed for the direct-credential-transfer case, or section 2 will need to be expanded. Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-sacred Wed Jul 19 11:18:27 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA19328 for ietf-sacred-bks; Wed, 19 Jul 2000 11:18:27 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19324 for ; Wed, 19 Jul 2000 11:18:25 -0700 (PDT) Received: from bpsi.net (port426.bpsi.net [209.54.245.226]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id NAA22729; Wed, 19 Jul 2000 13:20:40 -0500 (CDT) Message-ID: <3975F115.A16D368D@bpsi.net> Date: Wed, 19 Jul 2000 13:19:02 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Al Arsenault CC: ietf-sacred@imc.org Subject: Re: Comments on draft Charter References: <3975C05A.C34A14B@home.com> Content-Type: multipart/alternative; boundary="------------7DF8B9D3F6D57B83E364E38D" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------7DF8B9D3F6D57B83E364E38D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Looks good. I suggest a few tweaks (minor wordsmithing) and made a couple of other suggestions -- please see inline. Best Regards, --dg Al Arsenault wrote: > Steven, Magnus, et alia, [snip] > ____________start proposed revision_____________ > > A nice feature of PKIs using hardware tokens (e.g., smart cards, PCMCIA > cards) is the "free-seating solution," or the portabilty of the user's > credentials. In many situations, 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. suggest we add one sentence above to highlight the intended portability aspect: 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 devices. > (In general, the security provided by systems using such 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 > the soft tokens will be sufficient.) > Even in some cases where real hardware tokens are used, there may be > some benefit to using such a protocol - e.g. when a new token is > received, but "old" credentials should be used. If the tokens offered > the appropriate install and delete interfaces, then the credentials > could be (securely) moved between tokens. suggest we move the preceding paragraph. because of other changes it no longer fits here -- also suggest we update as shown below. > Many desktop applications also require mobility of credentials, for > example to support some "kiosk" style operation, when a user upgrades a > PC, or when "hot-desking". It is sometimes required to integrate such > credential mobility with single-sign-on solutions. A protocol that could > be used in the hardware token case can also be used to solve this case. > > There are at least two possible solutions for providing software > credential mobility. The first proposed 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 indefinitely and downloaded > when needed by the same or a different device (e.g., a mobile phone, > PDA, or laptop computer). moved / updated paragraph: When real hardware tokens are used, there may be substantial benefit derived from using the credential server and it's attendant protocols in support of credential and token management functions such as, for example, credential installation, token (locked PIN) recovery, or token replacement. When the tokens offer the appropriate install and delete interfaces, credentials can be (securely) installed / updated / moved between tokens. > A second possible solution involves the "direct" transfer of > credentials from one device to another (e.g., from a mobile phone to a > PDA). While there certainly may be some other devices involved in the > transfer providing lower-layer protocol translation, at the > credential-transfer level, there are no intermediate devices, and the > transfer is direct. > While it is possible that a single approach can be found that works for > both types of credential transfer described above, it is quite likely > that at least two 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 > entities should be allowed to download credentials, credentials must be > protected against eavesdropping and cut & paste attacks; attackers > must not be able to succesfully replace an entity's credentials at a > credential server; etc. > > Availability is also at a premium. A credential server must be reachable > from 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 such a solution, and to develop, adapt, or > adopt the required protocols and credential formats. > > > ___________ end of proposed rewrite ________________________ > > Al Arsenault > Chief Security Architect > Diversinet Corp. --------------7DF8B9D3F6D57B83E364E38D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit All,

Looks good.

I suggest a few tweaks (minor wordsmithing) and made a couple of other suggestions -- please see inline.

Best Regards,

--dg
 

Al Arsenault wrote:

Steven, Magnus, et alia,
[snip]
____________start proposed revision_____________

A nice feature of PKIs using hardware tokens (e.g., smart cards, PCMCIA
cards) is the "free-seating solution," or the portabilty of the user's
credentials.  In many situations, 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.

suggest we add one sentence above to highlight the intended portability aspect:

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 devices.

(In general, the security provided by systems using such 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
the soft tokens will be sufficient.)
Even in some cases where real hardware tokens are used, there may be
some benefit to using such a protocol - e.g. when a new token is
received, but "old" credentials should be used. If the tokens offered
the appropriate install and delete interfaces, then the credentials
could be (securely) moved between tokens.
suggest we move the preceding paragraph.  because of other changes it no longer fits here -- also suggest we update as shown below.
Many desktop applications also require mobility of credentials, for
example to  support some "kiosk" style operation, when a user upgrades a
PC, or when "hot-desking". It is sometimes required to integrate such
credential mobility with single-sign-on solutions. A protocol that could
be used in the hardware token case can also be used to solve this case.

There are at least two possible solutions for providing software
credential mobility.  The first proposed 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 indefinitely and downloaded
when needed by the same or a different device (e.g., a mobile phone,
PDA, or laptop computer).

moved / updated paragraph:

When real hardware tokens are used, there may be substantial benefit derived from using the credential server and it's attendant protocols in support of credential and token management functions such as, for example, credential installation, token (locked PIN) recovery, or token replacement.  When the tokens offer the appropriate install and delete interfaces, credentials can be (securely) installed / updated / moved between tokens.

A second possible solution involves the "direct" transfer of
credentials from one device to another (e.g., from a mobile phone to a
PDA).  While there certainly may be some other devices involved in the
transfer providing lower-layer protocol translation, at the
credential-transfer level, there are no intermediate devices, and the
transfer is direct.
While it is possible that a single approach can be found that works for
both types of credential transfer described above, it is quite likely
that at least two 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
entities should be allowed to download credentials, credentials must be
protected against eavesdropping and cut & paste attacks; attackers
must not be able to succesfully replace an entity's credentials at a
credential server; etc.

Availability is also at a premium. A credential server must be reachable
from 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 such a solution, and to develop, adapt, or
adopt the required protocols and credential formats.
 

___________ end of proposed rewrite ________________________

                        Al Arsenault
                        Chief Security Architect
                        Diversinet Corp.

--------------7DF8B9D3F6D57B83E364E38D-- From owner-ietf-sacred Thu Jul 20 02:48:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA08842 for ietf-sacred-bks; Thu, 20 Jul 2000 02:48:00 -0700 (PDT) Received: from relay07.indigo.ie (relay07.indigo.ie [194.125.133.231]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA08837 for ; Thu, 20 Jul 2000 02:47:59 -0700 (PDT) Received: (qmail 17137 messnum 1016308 invoked from network[194.125.134.186/ts02-059.dublin.indigo.ie]); 20 Jul 2000 09:50:33 -0000 Received: from ts02-059.dublin.indigo.ie (HELO cb?bridge.CardBase.com) (194.125.134.186) by relay07.indigo.ie (qp 17137) with SMTP; 20 Jul 2000 09:50:33 -0000 Received: by CB_BRIDGE with Internet Mail Service (5.0.1460.8) id <32PLL8HS>; Thu, 20 Jul 2000 10:46:41 +0100 Message-ID: <831D1A07A4B1D31186DA00062950FA573BB603@_CB_MAIL> From: Pierre Heuze To: ietf-sacred@imc.org Subject: RE: draft-farrell-sacred-00.txt Date: Thu, 20 Jul 2000 10:47:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA08838 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some comments (more might follow): A Requirements: ============= Any ambiguity in the requirements should be remove,.MUST, REQUIRED have well defined interpretation but what about easy, possibly and "if the user is able" as in: 10. The credential server MUST NOT have easy access to the cleartext credentials -> Suggestion: Segregate the cases where it is necessary to get access to the cleartext credentials and when it is not. 12. Credential servers MUST be authenticated to the user for all operations except (possibly) download 13. It MUST be possible to authenticate the credential server to the user prior to download (if the user is able to verify the authentication) 13. It MUST be possible to authenticate the credential server to the user prior to download (if the user is able to verify the authentication) B "strong" password scheme: ====================== I have a problem with the reversible functions password-generator and reverse-password. reverse-password is a one-one function onto the key space. A the result the size of the key space is not given by level (e.g. 2^80 for level3) but is constrained by the size of the password space, which is unfortunately much smaller (e.g. about 2^13 to 2^27 for normal digit based password, about 2^24 to 2^48 for printable ascii based password). This leads to some password guessing attacks, as it is difficult to ask the user to remember large password (20 digits or even sentences if we go with about 11bits per word as suggested for the OTP six word picker scheme). The problem isn't so critical with hardware token as they usually "blocks" after a couple of unsuccessful attempts. C General: ======== It seems that there is a general bias toward the fact that the user generates the credentials. (e.g. Assumption: User has credential Cd.). Is this really a fact, would that be always the case ? Previously it was suggested to use the terminology "hardware token" instead of "smart card" by the same token can we use "Passphrase" instead of "Password" or "PIN". -----Original Message----- From: Magnus Nystrom [mailto:magnus@rsasecurity.com] Sent: Thursday, July 13, 2000 2:01 PM To: ietf-sacred@imc.org Subject: draft-farrell-sacred-00.txt All, The above mentioned I-D is now available from ietf.org, as an individual submission. Please regard it as a strawman and a basis for discussions more than anything else. Thanks, -- Magnus Magnus Nyström Email: magnus@rsasecurity.com RSA Security From owner-ietf-sacred Thu Jul 20 19:31:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA26364 for ietf-sacred-bks; Thu, 20 Jul 2000 19:31:45 -0700 (PDT) Received: from mail02.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26356 for ; Thu, 20 Jul 2000 19:31:43 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by mail02.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 1622760; Thu, 20 Jul 2000 22:39:10 -0400 Message-Id: <3.0.5.32.20000720221853.007d9d90@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Jul 2000 22:18:53 -0400 To: "Miklos, Sue A." From: David Jablon Subject: RE: LDAP (and replication) Cc: "'Dale Gustafson'" , John Hughes , "'Pierre Heuze'" , ietf-sacred@imc.org In-Reply-To: <200007181333.JAA09675@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sue, Thanks for the clarification. Can you explain the last part further? At 09:45 AM 7/18/00 -0400, Miklos, Sue A. wrote: >>2) the ability to acquire one's credentials must be global. We intend to >>have this information replicated or transparently available in one of >>approximately 15 'megacenters'. This precludes the host sharing of the >>credential server/repository in a singular location. However, if the >>repository and credential information require the same protection in >>transit, then host sharing might make sense. > >I think the credential repository and the credential information in transit >deserve equal levels of protection. And credentials related to a >password must be presumed to be sensitive data, as I briefly discussed >in another thread. > >Clearly replicating public information would be easy, while replicating >sensitive data requires that the servers provide some suitable level >of protection for the channels. > >I do see that when considering a specific method, it may be difficult >to assess whether the risks of decentralization outweigh the benefits. >But somebody has to do it. > >(SM) availability (bandwidth as well as server performance) preclude a >completely centralized solution, which we've already learned. thus, we must >decentralize and must figure out the least risky means. The notion of >off-line encryption/decryption and using the 'encrypted attribute variant' >is appealing, but then we must also work through the key management issues >associated with that path. Can you elaborate more on "off-line encryption/decryption" and the "encrypted attribute variant"? -- dpj --------------------------------------------------- David P. Jablon dpj@world.std.com www.IntegritySciences.com From owner-ietf-sacred Thu Jul 20 19:31:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA26363 for ietf-sacred-bks; Thu, 20 Jul 2000 19:31:45 -0700 (PDT) Received: from mail02.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26351 for ; Thu, 20 Jul 2000 19:31:42 -0700 (PDT) Received: from [24.240.72.114] (HELO 76wru) by mail02.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with SMTP id 1622759; Thu, 20 Jul 2000 22:39:09 -0400 Message-Id: <3.0.5.32.20000720222537.008299e0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Jul 2000 22:25:37 -0400 To: Pierre Heuze From: David Jablon Subject: RE: draft-farrell-sacred-00.txt Cc: ietf-sacred@imc.org In-Reply-To: <831D1A07A4B1D31186DA00062950FA573BB603@_CB_MAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Pierre, I've embedded a few comments below. At 10:47 AM 7/20/00 +0100, Pierre Heuze wrote: >13. It MUST be possible to authenticate the >credential server to the user prior to download (if the user is able to >verify the authentication) The qualification "if the user is able to verify" is not clear to me. I like solutions that make it "easy and natural for a user to verify" the server. But I'm skeptical of solutions where the user is merely "able to verify" the server, but in practice, very rarely does. I realize that words like "easy" and "natuiral" are subjective, but it would be good to somehow capture this meaning. >B "strong" password scheme: >====================== > >I have a problem with the reversible functions password-generator and >reverse-password. reverse-password is a one-one function onto the key >space. A the result the size of the key space is not given by level (e.g. >2^80 for level3) but is constrained by the size of the password space, which >is unfortunately much smaller (e.g. about 2^13 to 2^27 for normal digit >based password, about 2^24 to 2^48 for printable ascii based password). I'm not sure what you have a problem with. Can you give an example of a problematic "reversible functions" scheme? I agree that it is very important to recognize when password-derived data has essentially the same "entropy" as the password. We have to be very careful with how these vulnerable secrets are used. >This leads to some password guessing attacks, as it is difficult to ask the >user to remember large password (20 digits or even sentences if we go with >about 11bits per word as suggested for the OTP six word picker scheme). >The problem isn't so critical with hardware token as they usually "blocks" >after a couple of unsuccessful attempts. This problem is also not so critical in strong password-based "EKE-style" credential-server protocols. The secret may be small, but the attacker's guesses are limited by the server. So, I think we want to say something more like: The solution MUST NOT allow unconstrained guessing by an attacker. By the way, it's also nice when unconstrained guessing by a credential-server are prevented too, but I don't think this should be a requirement. >C General: >======== > >... Previously it was suggested to use the terminology "hardware token" instead >of "smart card" by the same token can we use "Passphrase" instead of >"Password" or "PIN". Wishing won't make it so. Simply calling it a passphrase won't make the method secure, unless you're also going to mandate passphrase selection techniques to *force* the user to use lengthy complex input. Filtering tricks might help increase the randomness of user chosen secrets, but nobody really knows by how much, and this is done at the expense of user convenience. People typically rebel against this, one way or another. We need to support "password" and "PIN" explicitly, for some simple reasons. Not all input devices have 102 keys, and not all people have the patience for typing and remembering random phrases. -- dpj --------------------------------------------------- David P. Jablon dpj@world.std.com www.IntegritySciences.com From owner-ietf-sacred Fri Jul 21 08:06:26 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01568 for ietf-sacred-bks; Fri, 21 Jul 2000 08:06:26 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01564 for ; Fri, 21 Jul 2000 08:06:24 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA05929 for ; Fri, 21 Jul 2000 10:57:30 -0400 (EDT) Message-Id: <200007211457.KAA05906@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'David Jablon'" Cc: "'Dale Gustafson'" , John Hughes , "'Pierre Heuze'" , ietf-sacred@imc.org Subject: RE: LDAP (and replication) Date: Fri, 21 Jul 2000 11:05:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, I cannot recall the specific draft where the encrypted attribute variant syntax is defined - I believed either S/MIME or PKIX. Perhaps someone else on the list knows. I know there's a definition available in the 1997 X.500, but relies heavily on the use of a 'presentation layer' element. Thus, a non-starter, in my view. In either case, it's the syntax that 'wraps' around an attribute syntax and contains sufficient information to know which algorithm was used to encrypt the attribute value. Essentially, some application would 'wrap' the value and store it in a repository. Any application that would need to retrieve the wrapped data would, by prior key management techniques, be able to decrypt and subsequently use the content. All of the cryptographic processing occurs outside the space occupied by the transport protocol and the credential repository. does this answer your question? regards, Sandi -----Original Message----- From: David Jablon [mailto:dpj@world.std.com] Sent: Thursday, July 20, 2000 10:19 PM To: Miklos, Sue A. Cc: 'Dale Gustafson'; John Hughes; 'Pierre Heuze'; ietf-sacred@imc.org Subject: RE: LDAP (and replication) Sue, Thanks for the clarification. Can you explain the last part further? At 09:45 AM 7/18/00 -0400, Miklos, Sue A. wrote: >>2) the ability to acquire one's credentials must be global. We intend to >>have this information replicated or transparently available in one of >>approximately 15 'megacenters'. This precludes the host sharing of the >>credential server/repository in a singular location. However, if the >>repository and credential information require the same protection in >>transit, then host sharing might make sense. > >I think the credential repository and the credential information in transit >deserve equal levels of protection. And credentials related to a >password must be presumed to be sensitive data, as I briefly discussed >in another thread. > >Clearly replicating public information would be easy, while replicating >sensitive data requires that the servers provide some suitable level >of protection for the channels. > >I do see that when considering a specific method, it may be difficult >to assess whether the risks of decentralization outweigh the benefits. >But somebody has to do it. > >(SM) availability (bandwidth as well as server performance) preclude a >completely centralized solution, which we've already learned. thus, we must >decentralize and must figure out the least risky means. The notion of >off-line encryption/decryption and using the 'encrypted attribute variant' >is appealing, but then we must also work through the key management issues >associated with that path. Can you elaborate more on "off-line encryption/decryption" and the "encrypted attribute variant"? -- dpj --------------------------------------------------- David P. Jablon dpj@world.std.com www.IntegritySciences.com **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From owner-ietf-sacred Sun Jul 23 12:52:50 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA01905 for ietf-sacred-bks; Sun, 23 Jul 2000 12:52:50 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01900 for ; Sun, 23 Jul 2000 12:52:47 -0700 (PDT) Received: by balinese.baltimore.ie; id UAA01692; Sun, 23 Jul 2000 20:55:39 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma001686; Sun, 23 Jul 00 20:55:12 +0100 Received: from baltimore.ie ([192.168.20.104]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA00708; Sun, 23 Jul 2000 20:54:58 +0100 Message-ID: <397B4DA8.7A89B64B@baltimore.ie> Date: Sun, 23 Jul 2000 20:55:20 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miklos, Sue A." CC: ietf-sacred@imc.org, xme Subject: Re: LDAP (and replication) References: <200007211457.KAA05906@roadblock.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sandi, I guess you're referring to the encrypted attribute support in the PKIX attribute certificates profile draft (draft-ietf-pkix-ac509prof-04.txt)? If so, then its not directly relevant as it stands, since it uses a trick to prevent ciphertext stealing which is dependent on the encrypted attribute being contained in an AC. However, by itself this doesn't invalidate your idea, which could be useful if we end up with a situation where a client reads directly from a repository via LDAP. Stephen. "Miklos, Sue A." wrote: > > David, > > I cannot recall the specific draft where the encrypted attribute variant > syntax is defined - I believed either S/MIME or PKIX. Perhaps someone else > on the list knows. I know there's a definition available in the 1997 X.500, > but relies heavily on the use of a 'presentation layer' element. Thus, a > non-starter, in my view. > > In either case, it's the syntax that 'wraps' around an attribute syntax and > contains sufficient information to know which algorithm was used to encrypt > the attribute value. Essentially, some application would 'wrap' the value > and store it in a repository. Any application that would need to retrieve > the wrapped data would, by prior key management techniques, be able to > decrypt and subsequently use the content. > > All of the cryptographic processing occurs outside the space occupied by the > transport protocol and the credential repository. > > does this answer your question? > regards, > Sandi > > -----Original Message----- > From: David Jablon [mailto:dpj@world.std.com] > Sent: Thursday, July 20, 2000 10:19 PM > To: Miklos, Sue A. > Cc: 'Dale Gustafson'; John Hughes; 'Pierre Heuze'; ietf-sacred@imc.org > Subject: RE: LDAP (and replication) > > Sue, Thanks for the clarification. Can you explain the last part further? > > At 09:45 AM 7/18/00 -0400, Miklos, Sue A. wrote: > >>2) the ability to acquire one's credentials must be global. We intend to > >>have this information replicated or transparently available in one of > >>approximately 15 'megacenters'. This precludes the host sharing of the > >>credential server/repository in a singular location. However, if the > >>repository and credential information require the same protection in > >>transit, then host sharing might make sense. > > > >I think the credential repository and the credential information in transit > >deserve equal levels of protection. And credentials related to a > >password must be presumed to be sensitive data, as I briefly discussed > >in another thread. > > > >Clearly replicating public information would be easy, while replicating > >sensitive data requires that the servers provide some suitable level > >of protection for the channels. > > > >I do see that when considering a specific method, it may be difficult > >to assess whether the risks of decentralization outweigh the benefits. > >But somebody has to do it. > > > >(SM) availability (bandwidth as well as server performance) preclude a > >completely centralized solution, which we've already learned. thus, we > must > >decentralize and must figure out the least risky means. The notion of > >off-line encryption/decryption and using the 'encrypted attribute variant' > >is appealing, but then we must also work through the key management issues > >associated with that path. > > Can you elaborate more on "off-line encryption/decryption" and > the "encrypted attribute variant"? > > -- dpj > --------------------------------------------------- > David P. Jablon > dpj@world.std.com > www.IntegritySciences.com > > **************************************************************************** > * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > **************************************************************************** > ** -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Jul 24 08:43:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA14702 for ietf-sacred-bks; Mon, 24 Jul 2000 08:43:47 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14698 for ; Mon, 24 Jul 2000 08:43:46 -0700 (PDT) Received: from rhousley_laptop ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA04400; Mon, 24 Jul 2000 08:46:08 -0700 (PDT) Message-Id: <4.2.0.58.20000723235222.00a964a0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 23 Jul 2000 23:54:12 -0400 To: "Miklos, Sue A." From: Russ Housley Subject: RE: LDAP (and replication) Cc: ietf-sacred@imc.org In-Reply-To: <200007211457.KAA05906@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There is a definition of an encrypted attribute in draft-ietf-pkix-ac509prof-04.txt. It is intended to encrypt sensitive attributes carried in attribute certificates. Russ At 11:05 AM 07/21/2000 -0400, Miklos, Sue A. wrote: >David, > >I cannot recall the specific draft where the encrypted attribute variant >syntax is defined - I believed either S/MIME or PKIX. Perhaps someone else >on the list knows. I know there's a definition available in the 1997 X.500, >but relies heavily on the use of a 'presentation layer' element. Thus, a >non-starter, in my view. > >In either case, it's the syntax that 'wraps' around an attribute syntax and >contains sufficient information to know which algorithm was used to encrypt >the attribute value. Essentially, some application would 'wrap' the value >and store it in a repository. Any application that would need to retrieve >the wrapped data would, by prior key management techniques, be able to >decrypt and subsequently use the content. > >All of the cryptographic processing occurs outside the space occupied by the >transport protocol and the credential repository. > >does this answer your question? >regards, >Sandi > >-----Original Message----- >From: David Jablon [mailto:dpj@world.std.com] >Sent: Thursday, July 20, 2000 10:19 PM >To: Miklos, Sue A. >Cc: 'Dale Gustafson'; John Hughes; 'Pierre Heuze'; ietf-sacred@imc.org >Subject: RE: LDAP (and replication) > > >Sue, Thanks for the clarification. Can you explain the last part further? > >At 09:45 AM 7/18/00 -0400, Miklos, Sue A. wrote: > >>2) the ability to acquire one's credentials must be global. We intend to > >>have this information replicated or transparently available in one of > >>approximately 15 'megacenters'. This precludes the host sharing of the > >>credential server/repository in a singular location. However, if the > >>repository and credential information require the same protection in > >>transit, then host sharing might make sense. > > > >I think the credential repository and the credential information in transit > >deserve equal levels of protection. And credentials related to a > >password must be presumed to be sensitive data, as I briefly discussed > >in another thread. > > > >Clearly replicating public information would be easy, while replicating > >sensitive data requires that the servers provide some suitable level > >of protection for the channels. > > > >I do see that when considering a specific method, it may be difficult > >to assess whether the risks of decentralization outweigh the benefits. > >But somebody has to do it. > > > >(SM) availability (bandwidth as well as server performance) preclude a > >completely centralized solution, which we've already learned. thus, we >must > >decentralize and must figure out the least risky means. The notion of > >off-line encryption/decryption and using the 'encrypted attribute variant' > >is appealing, but then we must also work through the key management issues > >associated with that path. > >Can you elaborate more on "off-line encryption/decryption" and >the "encrypted attribute variant"? > >-- dpj >--------------------------------------------------- >David P. Jablon >dpj@world.std.com >www.IntegritySciences.com > > > >**************************************************************************** >* >This confirms that this email message has been swept by >MIMEsweeper for the presence of computer viruses. >**************************************************************************** >** From owner-ietf-sacred Mon Jul 24 17:07:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA26315 for ietf-sacred-bks; Mon, 24 Jul 2000 17:07:26 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26311 for ; Mon, 24 Jul 2000 17:07:24 -0700 (PDT) Received: by balinese.baltimore.ie; id BAA24444; Tue, 25 Jul 2000 01:10:22 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma024440; Tue, 25 Jul 00 01:10:13 +0100 Received: from baltimore.ie (lease199-20.baltimore.ie [192.168.20.199]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id BAA04119; Tue, 25 Jul 2000 01:10:12 +0100 Message-ID: <397CDB0E.414D001E@baltimore.ie> Date: Tue, 25 Jul 2000 01:10:54 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: xme Subject: agenda Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, So far I've got the following agenda items: Tuesday August 1, 1700-1800 1. agenda bashing (0-5 mins) 2. scene setting (5 mins) Magnus Nystrom 3. more use cases (5 mins) Al Arsenaut 4. relevant IEEE P1363 work items (5 mins) Ari Singer see http://grouper.ieee.org/groups/1363/StudyGroup/submissions.html 5. draft-farrell-sacred-00.txt (5 mins) Stephen Farrell 6. draft-perlman-strong-pass-00.txt (5 mins) Radia Perlman see also: http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/perlman.pdf 7. WG charter discussion (~30 mins) Which probably makes for a pretty full hour. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Fri Jul 28 07:22:01 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA26761 for ietf-sacred-bks; Fri, 28 Jul 2000 07:22:01 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26747 for ; Fri, 28 Jul 2000 07:21:59 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA15198; Fri, 28 Jul 2000 15:25:15 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015129; Fri, 28 Jul 00 15:24:33 +0100 Received: from baltimore.ie (lease174-21.baltimore.ie [192.168.21.174]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA17222; Fri, 28 Jul 2000 15:24:33 +0100 Message-ID: <398197D2.6B851D6B@baltimore.ie> Date: Fri, 28 Jul 2000 15:25:22 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: xme , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: draft charter - is it ok? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, 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. Regards, Stephen. --------- Securely Available Credentials (sacred) Chairs: Stephen Farrell Magnus Nystrom Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: TBD. Mailing Lists: General Discussion: ietf-sacred@imc.org To Subscribe: ietf-sacred-request@imc.org 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 devices. 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 computer). 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 interoperability. 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@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Fri Jul 28 07:41:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27853 for ietf-sacred-bks; Fri, 28 Jul 2000 07:41:08 -0700 (PDT) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27848 for ; Fri, 28 Jul 2000 07:41:07 -0700 (PDT) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.2.4) with ESMTP id 2676286 for ietf-sacred@imc.org; Fri, 28 Jul 2000 09:44:23 -0500 Date: Fri, 28 Jul 2000 09:44:23 -0500 (CDT) From: Eric Norman To: Sacred list Subject: Re: draft charter - is it ok? In-Reply-To: <398197D2.6B851D6B@baltimore.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 28 Jul 2000, Stephen Farrell wrote: > > Folks, > > 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. I think that considerating the portability of cryptographic keys in isolation is a mistake. I think the real problem is portability of "personal information" among sundry platforms; i.e. mail client configuration, address books, browser preferences, certificates, and so forth. The protection of private keys as they are transported deserves special consideration, to be sure. However, I think it would be a mistake to consider only that and ignore how that fits in with the larger picture, which is usually characterised by the word "roaming". There are things other than cryptographic keys among ones personal configuration stuff that may deserve cryptographic protection. And please don't assume that this is an argument for the ACAP protocol. In my opinion, that protocol should be scrapped; the idea behind it shouldn't. Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". From owner-ietf-sacred Fri Jul 28 08:04:06 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28773 for ietf-sacred-bks; Fri, 28 Jul 2000 08:04:06 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28767 for ; Fri, 28 Jul 2000 08:04:04 -0700 (PDT) Received: by balinese.baltimore.ie; id QAA20175; Fri, 28 Jul 2000 16:07:20 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma020130; Fri, 28 Jul 00 16:06:41 +0100 Received: from baltimore.ie (lease174-21.baltimore.ie [192.168.21.174]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA18598; Fri, 28 Jul 2000 16:06:40 +0100 Message-ID: <3981A1B1.53528E29@baltimore.ie> Date: Fri, 28 Jul 2000 16:07:30 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Norman CC: Sacred list , xme Subject: Re: draft charter - is it ok? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric, I didn't notice the suggested replacement text:-) Seriously though, what you're proposing is certainly much more ambitious than anyone else has suggested on this list, and I would suspect is really too large a topic, and also not a potential security WG. However, if you were to suggest a separate BOF for that topic, then you could make use of the protocols defined by sacred (assuming we become a WG) in order to handle credentials (and then you could use those to secure download of all your other personal information if you liked). Basically, this forum is not about tackling every possible piece of personal information. Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Fri Jul 28 08:30:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA06455 for ietf-sacred-bks; Fri, 28 Jul 2000 08:30:55 -0700 (PDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06447 for ; Fri, 28 Jul 2000 08:30:53 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA16862; Fri, 28 Jul 2000 11:34:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 28 Jul 2000 11:31:38 -0400 To: Eric Norman From: Stephen Kent Subject: Re: draft charter - is it ok? Cc: Sacred list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This would-be working group is focused on the credential portability problem because of the special security concerns that arise with regard to this data, vs. different concerns for the more general category of personal information. I think it would be a mistake at this time to try to address the larger, less well defined topic you suggest. Steve From owner-ietf-sacred Fri Jul 28 09:16:43 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA09573 for ietf-sacred-bks; Fri, 28 Jul 2000 09:16:43 -0700 (PDT) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09568 for ; Fri, 28 Jul 2000 09:16:41 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000728161958.NKBM2546.mail.rdc1.md.home.com@home.com>; Fri, 28 Jul 2000 09:19:58 -0700 Message-ID: <3981B29D.B674F744@home.com> Date: Fri, 28 Jul 2000 12:19:41 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: ietf-sacred , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: Re: draft charter - is it ok? References: <398197D2.6B851D6B@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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. Al Arsenault Stephen Farrell wrote: > > Folks, > > 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. > > Regards, > Stephen. > > --------- > > Securely Available Credentials (sacred) > > Chairs: > > Stephen Farrell > Magnus Nystrom > > Security Area Director(s): > > Jeffrey Schiller > Marcus Leech > > Security Area Advisor: > > TBD. > > Mailing Lists: > > General Discussion: ietf-sacred@imc.org > To Subscribe: ietf-sacred-request@imc.org > 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 > devices. > > 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 > computer). > > 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 > interoperability. > > 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@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Wed Aug 2 14:02:02 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA23554 for ietf-sacred-bks; Wed, 2 Aug 2000 14:02:02 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23543 for ; Wed, 2 Aug 2000 14:01:58 -0700 (PDT) Received: by balinese.baltimore.ie; id WAA09635; Wed, 2 Aug 2000 22:05:39 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma009612; Wed, 2 Aug 00 22:04:55 +0100 Received: from baltimore.ie ([192.168.20.132]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA12823 for ; Wed, 2 Aug 2000 22:04:54 +0100 Message-ID: <39888D2C.FF0A3FC9@baltimore.ie> Date: Wed, 02 Aug 2000 22:05:48 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: draft minutes Content-Type: multipart/mixed; boundary="------------BC9A8B9453A97FF86D5450BD" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------BC9A8B9453A97FF86D5450BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, My slightly edited version of Ernie's notes are attached (thanks Ernie). Corrections accepted until the 8th. Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com --------------BC9A8B9453A97FF86D5450BD Content-Type: text/plain; charset=us-ascii; name="pittsburgh notes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pittsburgh notes.txt" Draft Minutes of the IEFT sacred BOF session, Aug 1, 2000. Ernie Brickell agreed to act as note taker. Magnus Nystrom, cochair of the BOF, gave presentation on Setting the Scene, which motivated the need for a standard to allow users to remotely access credentials. Al Arsenaut , gave perspective from wireless PKI. Points that were stressed were: * People want to access their credential from multiple and different devices * Users want to have a consistent and convenient method for accessing their credential * Speaker would prefer if credential was in a hardware device, but realistically, there is a need for a software mobile credential * The standard must support direct transfer so that a user can directly transfer a credential from one device to another without going through a server. Comment from audience that we wanted to be sure that the use of hardware tokens for storage of mobile credentials was covered in the charter. Steve Farrell assured him that this was in the charter. Next Speaker - Ari Singer. The IEEE P1363 standard is coming out soon. It covers three families of algorithms, discrete exponentiation, elliptic curves, and integer factoring based. The IEEE P1363A, the first addendum is being worked on now. They are looking at lattice based algorithms and attributes. There is a project authorization request for new work on password based authenticated key exchange, which is relevant to sacred. The next meeting on this is after the Crypto converence, Aug. 24, in Santa Barbara. They should know soon after this whether this will be worked on as part of P1363. If this piece of work is accepted, the expected time to completion will be 1.5 to 2 years. Stephen Farrell, cochair of the BOF. Gave presentation on proposed requirements and an example protocol. Mentioned numerous times that the example protocol was given to help think about what the issues were, and not as a proposed protocol. Emphasized the point that the protocol should work for multiple types of credentials, and should treat the credential as opaque. Question from audience about whether the protocol would support authentication methods other than passwords, for example SecureID, for the authentication prior to the download of a credential. Stephen stated that the plan is to support a framework that could allow SecureID. Question from audience about the purpose of the direct protocol. Is it just for efficiency, since it seems that the functionality could be achieved with a server? Response that it was needed for efficiency, but the point was made that the direct method would be of use between two device that were non web connected devices. Radia Perlman presented a method for password based authenticated key exchange. They motivated their work by stating that they wanted to have a method for password based authenticated key exchange that was not encumbered by any patents. They believe they have done this (to their actual knowledge). They believe that their scheme is as efficient as other schemes. There is also an efficiency improvement if the user remembers one extra character in addition to their password. There was a question from the audience about whether SRP could be used. Their response was that SRP had issues, that it had not been closely examined, and that it was patented, and that it might be covered by the Bellovin - Merritt patent. There was a response from the audience that it was not patented, and that IESG would not have approved it if it had been patented. This last point was disputed. However, this discussion ended with confusion about the patent position of SRP. Stephen Farrell led a discussion on the draft charter for the BOF. Most of the participants had not read the charter. He displayed the charter on the screen, and summarized key points of the charter. One question from the audience was whether the charter should include credentials other than PKI. Stephen responded that we would prefer not to consider other credentials, for example credit cards. Steve Bellovin pointed out there was some overlap between the charter of sacred and items being considered in ipsra. There was several comments about the similarities and differences. Ipsra has a requirement to work with legacy systems, which precludes some technology, and the users of ipsra might not have a credential. The conclusion was that if ipsra wanted to transfer a piece of their work to sacred, then sacred would support requirements for ipsra. There was a question about adding to the requirements to address access control after the user has obtained the credential. However, this was stated as being out of scope for sacred. Stephen Farrell asked for any objections to the charter. There were none raised. David Jablon was the last speaker and spoke on the benefits of using a password based authenticated key exchange. Mentioned that there were 3 or 4 additional methods for this under discussion at P1363. Made the point that if you don't have to interoperate with legacy infrastructure, then you can use these new methods. --------------BC9A8B9453A97FF86D5450BD-- From owner-ietf-sacred Wed Aug 9 04:43:18 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA07599 for ietf-sacred-bks; Wed, 9 Aug 2000 04:43:18 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07592 for ; Wed, 9 Aug 2000 04:43:15 -0700 (PDT) From: stephen.farrell@baltimore.ie Received: by balinese.baltimore.ie; id MAA19296; Wed, 9 Aug 2000 12:47:30 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma018835; Wed, 9 Aug 00 12:46:44 +0100 Received: from baltimore.ie (ip195-221.ie.baltimore.com [192.168.21.195]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA24785; Wed, 9 Aug 2000 12:47:04 +0100 Message-ID: <399144EF.A9ED0076@baltimore.ie> Date: Wed, 09 Aug 2000 12:47:59 +0100 Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: xme , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: minutes of meeting Content-Type: multipart/mixed; boundary="------------BDFBE318C01385E16D90C2CE" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------BDFBE318C01385E16D90C2CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I corrected the spelling of Al's name (sorry Al) and added the fact that we'd about 110 people present - otherwise same as last time. Stephen. --------------BDFBE318C01385E16D90C2CE Content-Type: text/plain; charset=us-ascii; name="pittsburgh notes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pittsburgh notes.txt" Minutes of the IEFT sacred BOF session. We met for an hour on Tuesday, Aug 1. Approx. 110 people attended (not bad given the collision with TLS). Ernie Brickell agreed to act as note taker. Magnus Nystrom, cochair of the BOF, gave presentation on Setting the Scene, which motivated the need for a standard to allow users to remotely access credentials. Al Arsenault , gave perspective from wireless PKI. Points that were stressed were: * People want to access their credential from multiple and different devices * Users want to have a consistent and convenient method for accessing their credential * Speaker would prefer if credential was in a hardware device, but realistically, there is a need for a software mobile credential * The standard must support direct transfer so that a user can directly transfer a credential from one device to another without going through a server. Comment from audience that we wanted to be sure that the use of hardware tokens for storage of mobile credentials was covered in the charter. Steve Farrell assured him that this was in the charter. Next Speaker - Ari Singer. The IEEE P1363 standard is coming out soon. It covers three families of algorithms, discrete exponentiation, elliptic curves, and integer factoring based. The IEEE P1363A, the first addendum is being worked on now. They are looking at lattice based algorithms and attributes. There is a project authorization request for new work on password based authenticated key exchange, which is relevant to sacred. The next meeting on this is after the Crypto converence, Aug. 24, in Santa Barbara. They should know soon after this whether this will be worked on as part of P1363. If this piece of work is accepted, the expected time to completion will be 1.5 to 2 years. Stephen Farrell, cochair of the BOF. Gave presentation on proposed requirements and an example protocol. Mentioned numerous times that the example protocol was given to help think about what the issues were, and not as a proposed protocol. Emphasized the point that the protocol should work for multiple types of credentials, and should treat the credential as opaque. Question from audience about whether the protocol would support authentication methods other than passwords, for example SecureID, for the authentication prior to the download of a credential. Stephen stated that the plan is to support a framework that could allow SecureID. Question from audience about the purpose of the direct protocol. Is it just for efficiency, since it seems that the functionality could be achieved with a server? Response that it was needed for efficiency, but the point was made that the direct method would be of use between two device that were non web connected devices. Radia Perlman presented a method for password based authenticated key exchange. They motivated their work by stating that they wanted to have a method for password based authenticated key exchange that was not encumbered by any patents. They believe they have done this (to their actual knowledge). They believe that their scheme is as efficient as other schemes. There is also an efficiency improvement if the user remembers one extra character in addition to their password. There was a question from the audience about whether SRP could be used. Their response was that SRP had issues, that it had not been closely examined, and that it was patented, and that it might be covered by the Bellovin - Merritt patent. There was a response from the audience that it was not patented, and that IESG would not have approved it if it had been patented. This last point was disputed. However, this discussion ended with confusion about the patent position of SRP. Stephen Farrell led a discussion on the draft charter for the BOF. Most of the participants had not read the charter. He displayed the charter on the screen, and summarized key points of the charter. One question from the audience was whether the charter should include credentials other than PKI. Stephen responded that we would prefer not to consider other credentials, for example credit cards. Steve Bellovin pointed out there was some overlap between the charter of sacred and items being considered in ipsra. There was several comments about the similarities and differences. Ipsra has a requirement to work with legacy systems, which precludes some technology, and the users of ipsra might not have a credential. The conclusion was that if ipsra wanted to transfer a piece of their work to sacred, then sacred would support requirements for ipsra. There was a question about adding to the requirements to address access control after the user has obtained the credential. However, this was stated as being out of scope for sacred. Stephen Farrell asked for any objections to the charter. There were none raised. David Jablon was the last speaker and spoke on the benefits of using a password based authenticated key exchange. Mentioned that there were 3 or 4 additional methods for this under discussion at P1363. Made the point that if you don't have to interoperate with legacy infrastructure, then you can use these new methods. --------------BDFBE318C01385E16D90C2CE-- From owner-ietf-sacred Thu Aug 24 09:58:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02213 for ietf-sacred-bks; Thu, 24 Aug 2000 09:58:24 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02203 for ; Thu, 24 Aug 2000 09:58:18 -0700 (PDT) Received: by balinese.baltimore.ie; id RAA26143; Thu, 24 Aug 2000 17:58:49 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma026123; Thu, 24 Aug 00 17:58:47 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA22735; Thu, 24 Aug 2000 17:58:46 +0100 Message-ID: <39A554A4.1AB6C61D@baltimore.ie> Date: Thu, 24 Aug 2000 18:00:20 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: xme , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: tweaked charter Content-Type: multipart/mixed; boundary="------------01427891991D4C80A709C2C3" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------01427891991D4C80A709C2C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Hope you all had nice vacations (I did!), but now we're back to the sacred grindstone. The ADs are looking for a final charter suggestion from us, and I've told them they'll have it on Monday. I've done another slight tweak on the text from Pittsburgh, which gives you a day to send your last charter comments (as suggested alternate text, anything else is liable to be ignored), and then we can send it off and get to work. Cheers, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com --------------01427891991D4C80A709C2C3 Content-Type: text/plain; charset=us-ascii; name="August 24 charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="August 24 charter.txt" Securely Available Credentials (sacred) Chairs: Stephen Farrell Magnus Nystrom Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: ? Mailing Lists: General Discussion: ietf-sacred@imc.org To Subscribe: ietf-sacred-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-sacred/mail-archive/ Web site: http://www.imc.org/ietf-sacred Description of Working Group: The credentials used in a public key infrastructure (PKI) typically consist of a public/private key pair, a corresponding certificate or certificate chain and some trust or root certification authority information. They are usually stored on a desktop or laptop system as part of an application specific store. Currently, support for credential export/import is uneven and end users need to get too involved with the mechanics of creating and maintaining their PKI credentials. Application specific stores also mean that user's cannot easily use the same credential in multiple applications 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). 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, 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 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 interoperability. 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 & 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 --------------01427891991D4C80A709C2C3-- From owner-ietf-sacred Thu Aug 24 11:42:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03522 for ietf-sacred-bks; Thu, 24 Aug 2000 11:42:15 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03518 for ; Thu, 24 Aug 2000 11:42:14 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id SAA10003; Thu, 24 Aug 2000 18:43:42 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 24 Aug 2000 18:42:42 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 11:42:41 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9978@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'stephen.farrell@baltimore.ie'" , ietf-sacred Subject: RE: tweaked charter Date: Thu, 24 Aug 2000 11:42:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA03519 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steven: Great job. I think it reflects the discussion from the BOF very well. Here are two very minor and one major nits: While it is 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. I'd like "While it is possible..." to be replaced with "While it might be possible..." or smething similar, unless someone demonstrates a single protocol that on analysis actually does provide both functions securely. 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. It is not evident to me why smart cards are categorically more secure than the mechanisms the WG may provide. Could you either ellaborate or else soften the language? 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. Yes, true, all motherhood and apple pie. But, having made all that explicit, to me there seems to be a missing requirement or two to balance these requirements. What I have in mind is there shouldn't be any very byzantine organization of the protocol whereby someone is required to select among e.g., 792 symmetric key encryption algorithms, 134 hash algorithms, 479 Diffie-Hellman variants, 82 key wrap algorithms and 399 ways to authenticate himself in order to use the protocol. If we specify the protocol in such a way that the GUI has to present any choices whatsoever to end users, then we will probably be wasting our time, as no one but a handful of security professionals will ever bother to use it. I am not protesting against the protocol being designed to be crypto algorithm agnostic; everyone will acknowledge that is probably desriable. The issue that I am raising is that the way algorithm agnosticism has been defined in many security protocols has often lead to the need for organizations deploying them to first preposition huge quantities of policy on every affected device, because real users aren't trained to select intelligently among the presented options, and the protocols are defined in such a way as to leave no implementation choice except to force selection by some presumably human being. This forced policy provisioning is a great burden; it has made the deployment of implementations of many security protocols much more problematic and much less widely useful than had been hoped. This "minimize policy provisioning" (or "minimize configuration", or "define the protocol to permit ease-of-use", or whatever you wish to call it) requirement is, of course, at odds with making security paramount, but I feel it is nonetheless should be enumerated as a requirement. On the other hand, forced selection is itself a security flaw: no one (i.e., no sufficiently large population) will deploy a protocol that requires them to make choices they can't. We should not design yet another submission to the Darwin Awards committee. -- Jesse Walker -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Thursday, August 24, 2000 10:00 AM To: ietf-sacred Cc: xme; Magnus Nyström Subject: tweaked charter Hi All, Hope you all had nice vacations (I did!), but now we're back to the sacred grindstone. The ADs are looking for a final charter suggestion from us, and I've told them they'll have it on Monday. I've done another slight tweak on the text from Pittsburgh, which gives you a day to send your last charter comments (as suggested alternate text, anything else is liable to be ignored), and then we can send it off and get to work. Cheers, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Thu Aug 24 12:42:38 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA04257 for ietf-sacred-bks; Thu, 24 Aug 2000 12:42:38 -0700 (PDT) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04242 for ; Thu, 24 Aug 2000 12:41:55 -0700 (PDT) Received: by balinese.baltimore.ie; id UAA05458; Thu, 24 Aug 2000 20:39:51 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma005439; Thu, 24 Aug 00 20:39:08 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA25374; Thu, 24 Aug 2000 20:39:08 +0100 Message-ID: <39A57A3A.F972F489@baltimore.ie> Date: Thu, 24 Aug 2000 20:40:42 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Walker, Jesse" CC: ietf-sacred , xme Subject: Re: tweaked charter References: <392A357CE6FFD111AC3E00A0C99848B002FE9978@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id UAA25374 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA04254 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Walker, Jesse" wrote: > > Steven: > > Great job. I think it reflects the discussion from the BOF very well. Thanks. > > Here are two very minor and one major nits: What's a major nit:-) > > While it is 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. > > I'd like "While it is possible..." to be replaced with "While it might be > possible..." or smething similar, unless someone demonstrates a single > protocol that on analysis actually does provide both functions securely. Fine. > > 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. > > It is not evident to me why smart cards are categorically more secure than > the mechanisms the WG may provide. Could you either ellaborate or else > soften the language? I think "In general...tend to be..." is fairly soft already, so I'd rather leave it as is, in the absence of alternative text. > > 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. > > Yes, true, all motherhood and apple pie. But, having made all that explicit, > to me there seems to be a missing requirement or two to balance these > requirements. I think that your point is well made, (and I mostly tend to agree that we haven't emphasised user interaction enough in designing security stuff), but I don't think it needs to be raised in the charter; as you say yourself, its a requirement, and we'll get on to requirements soon as we're a proper working group. Stephen. > What I have in mind is there shouldn't be any very byzantine > organization of the protocol whereby someone is required to select among > e.g., 792 symmetric key encryption algorithms, 134 hash algorithms, 479 > Diffie-Hellman variants, 82 key wrap algorithms and 399 ways to authenticate > himself in order to use the protocol. If we specify the protocol in such a > way that the GUI has to present any choices whatsoever to end users, then we > will probably be wasting our time, as no one but a handful of security > professionals will ever bother to use it. > > I am not protesting against the protocol being designed to be crypto > algorithm agnostic; everyone will acknowledge that is probably desriable. > The issue that I am raising is that the way algorithm agnosticism has been > defined in many security protocols has often lead to the need for > organizations deploying them to first preposition huge quantities of policy > on every affected device, because real users aren't trained to select > intelligently among the presented options, and the protocols are defined in > such a way as to leave no implementation choice except to force selection by > some presumably human being. This forced policy provisioning is a great > burden; it has made the deployment of implementations of many security > protocols much more problematic and much less widely useful than had been > hoped. > > This "minimize policy provisioning" (or "minimize configuration", or "define > the protocol to permit ease-of-use", or whatever you wish to call it) > requirement is, of course, at odds with making security paramount, but I > feel it is nonetheless should be enumerated as a requirement. On the other > hand, forced selection is itself a security flaw: no one (i.e., no > sufficiently large population) will deploy a protocol that requires them to > make choices they can't. We should not design yet another submission to the > Darwin Awards committee. > > -- Jesse Walker > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: Thursday, August 24, 2000 10:00 AM > To: ietf-sacred > Cc: xme; Magnus Nyström > Subject: tweaked charter > > Hi All, > > Hope you all had nice vacations (I did!), but now we're > back to the sacred grindstone. > > The ADs are looking for a final charter suggestion from > us, and I've told them they'll have it on Monday. > > I've done another slight tweak on the text from Pittsburgh, > which gives you a day to send your last charter comments (as > suggested alternate text, anything else is liable to be > ignored), and then we can send it off and get to work. > > Cheers, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Thu Aug 24 13:46:16 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA05463 for ietf-sacred-bks; Thu, 24 Aug 2000 13:46:16 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05459 for ; Thu, 24 Aug 2000 13:46:15 -0700 (PDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id UAA05973; Thu, 24 Aug 2000 20:47:45 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 24 Aug 2000 20:46:45 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 13:46:43 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE997C@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred Subject: RE: tweaked charter Date: Thu, 24 Aug 2000 13:46:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Thursday, August 24, 2000 12:41 PM To: Walker, Jesse Cc: ietf-sacred; xme Subject: Re: tweaked charter "Walker, Jesse" wrote: > > Steven: > > Great job. I think it reflects the discussion from the BOF very well. Thanks. > > Here are two very minor and one major nits: What's a major nit:-) > > While it is 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. > > I'd like "While it is possible..." to be replaced with "While it might be > possible..." or smething similar, unless someone demonstrates a single > protocol that on analysis actually does provide both functions securely. Fine. > > 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. > > It is not evident to me why smart cards are categorically more secure than > the mechanisms the WG may provide. Could you either ellaborate or else > soften the language? I think "In general...tend to be..." is fairly soft already, so I'd rather leave it as is, in the absence of alternative text. > > 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. > > Yes, true, all motherhood and apple pie. But, having made all that explicit, > to me there seems to be a missing requirement or two to balance these > requirements. I think that your point is well made, (and I mostly tend to agree that we haven't emphasised user interaction enough in designing security stuff), but I don't think it needs to be raised in the charter; as you say yourself, its a requirement, and we'll get on to requirements soon as we're a proper working group. Stephen. > What I have in mind is there shouldn't be any very byzantine > organization of the protocol whereby someone is required to select among > e.g., 792 symmetric key encryption algorithms, 134 hash algorithms, 479 > Diffie-Hellman variants, 82 key wrap algorithms and 399 ways to authenticate > himself in order to use the protocol. If we specify the protocol in such a > way that the GUI has to present any choices whatsoever to end users, then we > will probably be wasting our time, as no one but a handful of security > professionals will ever bother to use it. > > I am not protesting against the protocol being designed to be crypto > algorithm agnostic; everyone will acknowledge that is probably desriable. > The issue that I am raising is that the way algorithm agnosticism has been > defined in many security protocols has often lead to the need for > organizations deploying them to first preposition huge quantities of policy > on every affected device, because real users aren't trained to select > intelligently among the presented options, and the protocols are defined in > such a way as to leave no implementation choice except to force selection by > some presumably human being. This forced policy provisioning is a great > burden; it has made the deployment of implementations of many security > protocols much more problematic and much less widely useful than had been > hoped. > > This "minimize policy provisioning" (or "minimize configuration", or "define > the protocol to permit ease-of-use", or whatever you wish to call it) > requirement is, of course, at odds with making security paramount, but I > feel it is nonetheless should be enumerated as a requirement. On the other > hand, forced selection is itself a security flaw: no one (i.e., no > sufficiently large population) will deploy a protocol that requires them to > make choices they can't. We should not design yet another submission to the > Darwin Awards committee. > > -- Jesse Walker > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: Thursday, August 24, 2000 10:00 AM > To: ietf-sacred > Cc: xme; Magnus Nyström > Subject: tweaked charter > > Hi All, > > Hope you all had nice vacations (I did!), but now we're > back to the sacred grindstone. > > The ADs are looking for a final charter suggestion from > us, and I've told them they'll have it on Monday. > > I've done another slight tweak on the text from Pittsburgh, > which gives you a day to send your last charter comments (as > suggested alternate text, anything else is liable to be > ignored), and then we can send it off and get to work. > > Cheers, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 07:30:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA09036 for ietf-sacred-bks; Mon, 25 Sep 2000 07:30:13 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09032 for ; Mon, 25 Sep 2000 07:30:10 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA19281; Mon, 25 Sep 2000 15:33:21 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma019265; Mon, 25 Sep 00 15:33:10 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA31045 for ; Mon, 25 Sep 2000 15:33:09 +0100 Message-ID: <39CF62C3.9D80038D@baltimore.ie> Date: Mon, 25 Sep 2000 15:35:47 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Content-Type: multipart/mixed; boundary="------------53E2BB67629BC4CB26FDC96F" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------53E2BB67629BC4CB26FDC96F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I posted this on Friday, but it hasn't shown up in the drafts directory so far. In any case, let's now see how much agreement we have on requirements, so please comment to the list on the attached (which is still very much a first draft). Just to update you on our WG status: we've now agreed the charter (no significant change) with Marcus Leech, one of the security ADs and are on the list of putative WGs for which messages will be sent to the IETF announce list sometime "soon". (see: http://www.ietf.org/iesg/1wg_actions.txt if you like that sort of stuff) Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com --------------53E2BB67629BC4CB26FDC96F Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA21711; Fri, 22 Sep 2000 18:29:16 +0100 Message-ID: <39CB9786.4D77D939@baltimore.ie> Date: Fri, 22 Sep 2000 18:31:50 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: Al Arsenault , xme , "Magnus =?iso-8859-1?Q?Nystr=F6m?=" Subject: new draft (draft-arsenault-sacred-reqs-00.txt) Content-Type: multipart/mixed; boundary="------------8A4D2D563AA059A29186EFB3" X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------8A4D2D563AA059A29186EFB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Could you post the attached non-WG draft? Thanks, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com --------------8A4D2D563AA059A29186EFB3 Content-Type: text/plain; charset=iso-8859-1; name="draft-arsenault-sacred-reqs-00.txt" Content-Disposition: inline; filename="draft-arsenault-sacred-reqs-00.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id PAA31045 INTERNET-DRAFT A. Arsenault expires in six months Diversinet S. Farrell Baltimore Technologies September 2000 Securely Available Credentials - Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes requirements to be placed on Securely Available Credentials (sacred) protocols. This is the initial draft of the sacred requirements specification and is therefore highly likely to change substantially. Discussion of this draft is taking place on the sacred list (see http://www.imc.org/ietf-sacred for subscription information). Table Of Contents Status of this Memo.............................................1 Abstract........................................................1 Table Of Contents...............................................1 1. Introduction.................................................2 1.1 Background and Motivation..............................2 1.2 Working Group Organization and Documents...............4 1.3 Structure of This Document.............................4 Arsenault & Farrell [Page 1] =0C INTERNET-DRAFT September 2000 2. Framework Requirements.......................................4 2.1 Credential Server and Direct solutions.................4 2.2 User authentication....................................6 2.3 Credential Formats.....................................7 2.4 Transport Issues.......................................7 3. Protocol Requirements........................................7 3.1 General Protocol Requirements..........................7 3.2 Requirements for Credential Server-based solutions.....8 3.3 Requirements for Direct-Transfer Solutions.............9 4. Open Issues..................................................9 5. Security Considerations.....................................10 References.....................................................10 Authors' Addresses.............................................10 Full Copyright Statement.......................................11 1. Introduction. "Credentials" are information that can be used to establish the identity of an entity, or help that entity communicate securely. Credentials include such things as private keys, trusted roots, tickets, or the private part of a Personal Security Environment (PSE)[RFC2459] - that is, information used in secure communication on the Internet. Credentials are used to support various Internet protocols, e.g. S/MIME, IPSec and TLS. In simple models, users and other entities are provided with credentials, and these credentials stay in one place. However, the number, and more importantly the number of different types, of devices that can be used to access the Internet is increasing. It is now possible to access Internet services and accounts using desktop computers, laptop computers, wireless phones, pagers, personal digital assistants (PDAs) and other types of devices. Further, many users want to access private information and secure services from a number of different devices, and want access to the same information from any device. This draft identifies a set of requirements for credential mobility. The Working Group will also produce companion documents, which describe a framework for secure credential mobility, and a set of protocols for accomplishing this goal. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119]. <>. 1.1 Background and Motivation In simple models of Internet use, users and other entities are provided with credentials, and these credentials stay in one place. Arsenault & Farrell [Page 2] =0C INTERNET-DRAFT September 2000 For example, Mimi generates a public and private key on her desktop computer, provides the public key to a Certification Authority (CA) to be included in a certificate, and keeps the private key on her computer. It never has to be moved. However, the number, and more importantly the number of different types, of devices that can be used to access the Internet is increasing. It is now possible to access Internet services and accounts using desktop computers, laptop computers, wireless phones, pagers, personal digital assistants (PDAs) and other types of devices. Further, many users want to access private information and secure services from a number of different devices, and want access to the same information from any device. For example, Mimi may want to able to send signed e-mail messages from her desktop computer when she is in the office, and from her laptop computer when she is on the road, and she does not want message recipients to know the difference. In order to do this, she must somehow make her private key available on both devices - that is, that credential must be moved. Similarly, Will may want to retrieve and read encrypted e-mail from either his wireless phone or from his two-way pager. He wants to use whichever device he has with him at the moment, and does not want to be denied access to his mail or to be unable to decrypt important messages simply because he has the wrong device. Thus, he must be able to have the same private key available on both devices. It is generally accepted that the private key in these examples must be transferred securely. In the first example, the private key should not be exposed to anyone other than Mimi herself (and ideally, it would not be directly exposed to her). Furthermore, it must be transferred correctly. It must be transferred to the proper device, and it must not be corrupted - improperly modified - during transfer. One way of accomplishing these goals is to put the credentials on hardware tokens - e.g., smart cards, PCMCIA cards, or other devices. There are a number of types of hardware tokens today that provide secure storage for sensitive information, some degree of authentication, and interfaces to a number of types of wireless devices. Thus, in the second example above, Will could simply put his private key on a smart card, always take the smart card with him, and be assured that whichever device he uses to retrieve his e- mail, he will have all of the information necessary to decrypt and read messages. However, hardware tokens are not appropriate for every environment. They cost more than software-only solutions, and the additional security they provide may not be worth the incremental cost. Not all devices have interfaces for the same hardware tokens. And hardware tokens are subject to different failure modes than typical computers Arsenault & Farrell [Page 3] =0C INTERNET-DRAFT September 2000 - it is not at all unusual for a smart card to be lost or stolen; or for a PCMCIA card to physically break. Thus, it is appropriate to develop a complementary (?) software- based solution that allows credentials to be moved from one device to another, and provides a level of security sufficient for its environments. While we recognize that the level of security provided by a software solution may not be as high as that provided by the hardware solutions discussed above, and some organizations may not consider it sufficient at all, we believe that a worthwhile solution can be developed. In the remainder of this draft we present a set of requirements for the secure transfer of software-based credentials. 1.2 Working Group Organization and Documents <> The Securely Available Credentials (sacred) Working Group is working on a set of protocols for the standardization of the secure transfer of credentials among devices. A general framework is being developed that will give an abstract definition of protocols which can meet the credential-transfer requirements. This framework will allow for the development of a set of protocols, which may vary from one another in some respects. Specific protocols which conform to the framework can then be developed. Work is being done on a number of documents. This document identifies the requirements for the general framework, as well as the requirements for specific protocols. Another document will describe the protocol framework. Still others will define the protocols themselves. 1.3 Structure of This Document Section 1 of this document provides an introduction to the problem being solved by this working group. Section 2 describes requirements on the framework. Section 3 identifies the overall requirements for secure credential-transfer protocols, and separate requirements for the two different classes of solutions. Section 4 addresses remaining issues. Section 5 identifies Security Considerations. 2. Framework Requirements This section describes requirements that the sacred framework has to meet, as opposed to requirements that are to be met by a specific protocol that uses the framework. 2.1 Credential Server and Direct solutions Arsenault & Farrell [Page 4] =0C INTERNET-DRAFT September 2000 There are at least two different ways to solve the problem of secure credential transfer between devices. One class of solutions uses a "credential server" as an intermediate node, and the other class provides direct transfer between devices. A "credential server" can be likened to a server that sits in front of a repository where credentials can be securely stored for later retrieval. The credential server is active in the protocol, that is, it implements security enforcing functionality. To transfer credentials securely from one end device to another is a straightforward two-step process. Users can have their credentials securely "uploaded" from one device, e.g., a wireless phone, to the credential server. They can be stored on the credential server, and "downloaded" when needed using another device; e.g., a two-way pager. The advantages of a credential server approach to credential transfer are two-fold: 1. It provides a conceptually clean and straightforward approach. For all end devices, there is one protocol, with a set of actions defined to transfer credentials from the device to the server, and another set of actions defined to transfer credentials from the server to the device. Furthermore, this protocol involves clients (the devices) and a server (the credential server), like many other Internet protocols; thus, the design of this protocol is likely to be familiar to most people familiar with most other Internet protocols. 2. It provides for a place where credentials can be securely stored for arbitrary lengths of time. Given a reasonable-quality server operating under generally accepted practices, it is unlikely the credentials will be permanently lost due to a hardware failure. This contrasts with systems where credentials are only stored on end devices, in which a failure of or the loss of the device could mean that the credentials are lost forever. However, the credential server approach has some potential disadvantages, too: 1. It might be somewhat expensive to maintain and run the credential server, particularly if there are stringent requirements on availability and reliability of the server. 2. The credential server may have to be "trusted" in some sense and also introduces a point of potential vulnerability. (See the Security Considerations section for some of the issues.) Good protocol and system design will limit the vulnerability that exists at the credential server, but at a minimum, someone with access to the credential server will be able to delete credentials and thus deny the sacred service to system users. Arsenault & Farrell [Page 5] =0C INTERNET-DRAFT September 2000 Thus, some users may prefer a different class of solution, in which credentials are transferred directly from one device to another. In this case "directly" may not mean from one device to another, without any other device participating in the transaction. Rather, it simply means that the transfer is "direct" from the view of the credential-transfer protocol; there is no intermediate credential server involved which is active in security terms. It may be the case that at lower protocol layers, an arbitrary number of other devices are involved in moving bits around. For example, consider the case where Mimi sends a message from her wireless phone containing the credentials in question, and retrieves it using her two-way pager. In getting from one place to another, the bits of the message cross the wireless phone network to a base station. These bits are likely transferred over the wired phone network to a message server run by the wireless phone operator, and are transferred from there over the Internet to a message server run by the paging operator. From the paging operator they are transferred to a base station and then finally to Mimi=92s pager. Certainly, there are devices other than the original wireless phone and ultimate pager that are involved in the credential transfer, in the sense that they transmit bits from one place to another. However, to all devices except the pager and the wireless phone, what is being transferred is an un-interpreted and unprocessed set of bits. No security-related decisions are made, and no actions are taken based on the fact that this message contains credentials, at any of the intermediate nodes. They exist simply to forward bits. Thus, we consider this to be a "direct" transfer of credentials. Solutions involving the direct transfer of credentials from one device to another are potentially somewhat more complex than the credential-server approach, owing to the large number of different devices and formats that may have to be supported. Complexity is also added due to the fact that each device may in turn have to exhibit the behavior of both a client and a server. We believe that both classes of solutions are useful in certain environments, and thus that the sacred framework will have to define solutions for both. The extent to which elements of the above solutions overlap remains to be determined. This all leads to our first set of requirements: 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. 2.2 User authentication There is a wide range of deployment options for credential mobility solutions. In many of these cases, it is useful to be able to re-use Arsenault & Farrell [Page 6] =0C INTERNET-DRAFT September 2000 an existing user authentication scheme, for example where passwords have previously been established, it may be more secure to re-use these than try to manage a whole new set of passwords. Different devices may also limit the types of user authentication scheme that are possible, e.g. not all mobile devices are practically capable of carrying out asymmetric cryptography. F3. The framework MUST allow for protocols which support different user authentication schemes 2.3 Credential Formats Today there is no single standard format for credentials and this is not likely to change in the near future. There are a number of fairly widely deployed formats, e.g. [PGP], [PKCS#12] that have to be supported. This means that the framework has to allow for protocols supporting any credential format. 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 <> 2.4 Transport Issues Different devices allow for different transport layer possibilities, e.g. current WAP 1.x devices do not support TCP. For this reason the framework has to be transport "agnostic". F5. The framework MUST allow use of different transports. <> 3. Protocol Requirements In this section, we identify the requirements for secure credential- transfer solutions. We will begin by identifying those requirements that must be met by all solutions. Then, we will identify additional requirements that must be met by solutions involving a credential server, followed by additional requirements that must be met by solutions involving direct transfer of credentials. 3.1 General Protocol Requirements Looking again at the examples described in Section 1.1, we can readily see that there are a number of requirements that must apply Arsenault & Farrell [Page 7] =0C INTERNET-DRAFT September 2000 to the transfer of credentials if the ultimate goal of supporting the Internet security protocols (e.g., TLS, IPSec, S/MIME) is to be met. For example, the credentials must remain confidential at all times; it is unacceptable for nodes other than the end-user=92s device(s) to see the credentials in any readable, cleartext form. These, then, are the requirements that apply to all secure credential-transfer solutions: 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). G5. The protocol MUST support a range of cryptographic algorithms, including symmetric and asymmetric algorithms, hash algorithms, and MAC algorithms. G6. The protocol MUST support the use of various credential types and formats (e.g., X.509, PGP, PKCS12, ...). 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). G11. The protocol MUST NOT be vulnerable to any spoofing attacks (e.g. server spoofing). <> G12. The protocol MUST be able to support privacy, that is, anonymity for the client. 3.2 Requirements for Credential Server-based solutions The following requirements assume that there is a credential server from which credentials are downloaded to the end user device, and to which credentials are uploaded from an end user device. 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. 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. Arsenault & Farrell [Page 8] =0C INTERNET-DRAFT September 2000 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). S10. The protocol MUST support "away-from-home" operation, where the user enters both a name and a domain (e.g.=20 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. 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. 3.3 Requirements for Direct-Transfer Solutions The following requirements apply to solutions supporting the "direct" transfer of credentials from one device to another. (See Section 2 for the note on the meaning of "direct" in this case.) 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. 4. Open Issues This document is intended to foster discussion of the requirements for secure credential transfer solutions. However, the authors recognize that there are many issues that remain to be resolved. Some of the most pressing are: Vulnerabilities: Which attacks can/should the framework and protocol protect against? What do we depend on the end user device for? Robustness: Credential stores should not unacceptably increase the potential for denial-of-service or other attacks. Performance: Users should not typically have to wait too long for access to credentials. Arsenault & Farrell [Page 9] =0C INTERNET-DRAFT September 2000 Bootstrapping: The use of, e.g. TLS server authentication as a way of having the client authenticate the credential server, depends on the client having a (set of) trusted root(s). As the protocol may be providing these roots, there may be some hard bootstrapping issues. Finally, we note that whether or not the user authentication, credential protection and specific credential formats should be separated, or should be intertwined, is an open issue that warrants careful consideration. 5. Security Considerations Mobile credentials will never be as secure as a "pure" hardware- based solution, because of potential attacks through the operating system of the end-user device. However, an acceptable level of security may be accomplished through some simple means. One should keep in mind, however, that platforms to which credentials are downloaded usually cannot be regarded as tamper-resistant, and it therefore is not too hard to analyze contents of their memories. Further, storage of private keys, even if they are encrypted, on a credential server, will be unacceptable in some environments. <> References [PGP] Callas, J., Donnerhacke, L., Finney, H., & Thayer, R., "OpenPGP Message Format", RFC 2440. [PKCS12] "PKCS #12 v1.0: Personal Information Exchange Syntax Standard", RSA Laboratories, June 24, 1999. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet Public Key Infrastructure - X.509 Certificate and CRL profile", RFC 2459. [RFC2616] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616. Authors' Addresses Alfred Arsenault Diversinet Corp. P.O. Box 6530 Ellicott City, MD 21042 Arsenault & Farrell [Page 10] =0C INTERNET-DRAFT September 2000 USA tel: +1 410-480-2052 email: aarsenault@dvnet.com Stephen Farrell, Baltimore Technologies, 61/62 Fitzwilliam Lane, Dublin 2, IRELAND tel: +353-1-647-3000 email: stephen.farrell@baltimore.ie Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 module presented in Appendix B may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Arsenault & Farrell [Page 11] --------------8A4D2D563AA059A29186EFB3-- --------------53E2BB67629BC4CB26FDC96F-- From owner-ietf-sacred Mon Sep 25 08:14:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10697 for ietf-sacred-bks; Mon, 25 Sep 2000 08:14:56 -0700 (PDT) Received: from puma.dub0.ie.cp.net (puma.dub0.ie.cp.net [194.106.154.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10687 for ; Mon, 25 Sep 2000 08:14:54 -0700 (PDT) Received: from starcraft (194.106.155.123) by puma.dub0.ie.cp.net (5.1.046) id 39B3DCD4000030F1 for ietf-sacred@imc.org; Mon, 25 Sep 2000 16:19:11 +0100 Message-ID: <05fb01c02704$4107b330$7b9b6ac2@isocor.ie> Reply-To: "Michael Leahy" From: "Michael Leahy" To: Subject: Fw: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Date: Mon, 25 Sep 2000 16:21:19 +0100 Organization: Critical Path MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA10690 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Stephen Once a user authenticates themselves into the "credential server" is there a concept of time limit that the authentication is valid for (i.e they have re-authenticate themselves again). I am particularly thinking of the "internet cafe" or "computer services offered at airports" type of environments. I pay for use of the computer for 1 hour and I have been using the "credential server". So really I have 2 qts 1. Is there a concept of how long the credentials extracted from the server can be used on the desktop/PDAs/wireless device. 2. While using the extracted data do they have re-validate themselves after a few minutes before using the credentials My thinking here is the idea of a credential server policy on extracted data. Regards Michael ----- Original Message ----- From: Stephen Farrell To: ietf-sacred Sent: Monday, September 25, 2000 3:35 PM Subject: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] > > Hi All, > > I posted this on Friday, but it hasn't shown up in the drafts > directory so far. In any case, let's now see how much agreement > we have on requirements, so please comment to the list on the > attached (which is still very much a first draft). > > Just to update you on our WG status: we've now agreed the > charter (no significant change) with Marcus Leech, one of > the security ADs and are on the list of putative WGs for > which messages will be sent to the IETF announce list > sometime "soon". > > (see: http://www.ietf.org/iesg/1wg_actions.txt if you like > that sort of stuff) > > Regards, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 08:36:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14628 for ietf-sacred-bks; Mon, 25 Sep 2000 08:36:22 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14624 for ; Mon, 25 Sep 2000 08:36:20 -0700 (PDT) Received: by balinese.baltimore.ie; id QAA04167; Mon, 25 Sep 2000 16:39:32 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma004014; Mon, 25 Sep 00 16:38:35 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA01675; Mon, 25 Sep 2000 16:38:34 +0100 Message-ID: <39CF7218.C5FE0D1D@baltimore.ie> Date: Mon, 25 Sep 2000 16:41:12 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Leahy CC: ietf-sacred@imc.org Subject: Re: Fw: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <05fb01c02704$4107b330$7b9b6ac2@isocor.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Michael, I would imagine that setting a TTL or equivalent on downloaded credentials is reasonable enough, however I think the question of whether we can provide a good solution for kiosks is interesting, and I'd solicit others' opinions on this point. Basically, I don't think we can avoid having to place a certain amount of trust in the client s/w and its not clear whether a kiosk can provide the requisite level of trust. Be nice if it could, but I'm not sure. Michael Leahy wrote: > > Hi Stephen > > Once a user authenticates themselves into the "credential server" > is there a concept of time limit that the authentication is valid > for (i.e they have re-authenticate themselves again). > > I am particularly thinking of the "internet cafe" or "computer > services offered at airports" type of environments. I pay for use > of the computer for 1 hour and I have been using the "credential > server". So really I have 2 qts > > 1. Is there a concept of how long the credentials extracted from > the server can be used on the desktop/PDAs/wireless device. > 2. While using the extracted data do they have re-validate > themselves after a few minutes before using the credentials I think something along these lines would be reasonable as "MAY", requirements on the protocol(s), i.e. I don't think its a "MUST" that a protocol be able to support this, but OK if it does. I think it'd be sensible to add in something along these lines to the next version of the draft. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 08:55:26 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA15068 for ietf-sacred-bks; Mon, 25 Sep 2000 08:55:26 -0700 (PDT) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15064 for ; Mon, 25 Sep 2000 08:55:25 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000925155836.YBRI12026.mail.rdc1.md.home.com@home.com>; Mon, 25 Sep 2000 08:58:36 -0700 Message-ID: <39CF7689.2A6DE848@home.com> Date: Mon, 25 Sep 2000 12:00:09 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: Michael Leahy , ietf-sacred@imc.org Subject: Re: Fw: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <05fb01c02704$4107b330$7b9b6ac2@isocor.ie> <39CF7218.C5FE0D1D@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael, Stephen et alia, I'd agree that a TTL on the connection time between client and credential server is reasonable. However, once a credential has been downloaded onto the client device, I'm not sure you can force the client to not use it any more after a certain time. That is, if I've used my mobile phone to connect to the credential server and download my credentials, then use broken that connection and gone off to do "m-commerce" using the phone/credential pair, it's not clear to me how you force the phone to stop using the credential after, say, 24 hours. However, if people think that this makes a worthwhile option, I won't violently object. As Stephen notes, at that point you're relying entirely on the client software to enforce it, though. Re: kiosks: yes, I think that this a mode we have to support with sacred. However, it does carry with it the risk that if the kiosk software is malicious, the user loses, and we have to acknowledge that. There's not much we can do about that. Al Arsenault Chief Security Architect Diversinet Corp. aarsenault@dvnet.com Stephen Farrell wrote: > > Hi Michael, > > I would imagine that setting a TTL or equivalent on downloaded > credentials is reasonable enough, however I think the question > of whether we can provide a good solution for kiosks is > interesting, and I'd solicit others' opinions on this point. > Basically, I don't think we can avoid having to place a > certain amount of trust in the client s/w and its not clear > whether a kiosk can provide the requisite level of trust. > Be nice if it could, but I'm not sure. > > Michael Leahy wrote: > > > > Hi Stephen > > > > Once a user authenticates themselves into the "credential server" > > is there a concept of time limit that the authentication is valid > > for (i.e they have re-authenticate themselves again). > > > > I am particularly thinking of the "internet cafe" or "computer > > services offered at airports" type of environments. I pay for use > > of the computer for 1 hour and I have been using the "credential > > server". So really I have 2 qts > > > > 1. Is there a concept of how long the credentials extracted from > > the server can be used on the desktop/PDAs/wireless device. > > 2. While using the extracted data do they have re-validate > > themselves after a few minutes before using the credentials > > I think something along these lines would be reasonable as > "MAY", requirements on the protocol(s), i.e. I don't think > its a "MUST" that a protocol be able to support this, but > OK if it does. I think it'd be sensible to add in something > along these lines to the next version of the draft. > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 09:34:16 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA16883 for ietf-sacred-bks; Mon, 25 Sep 2000 09:34:16 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16878 for ; Mon, 25 Sep 2000 09:34:14 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id QAA01320; Mon, 25 Sep 2000 16:38:16 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 25 Sep 2000 16:37:12 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 09:37:11 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9A3D@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'stephen.farrell@baltimore.ie'" , ietf-sacred Subject: RE: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Date: Mon, 25 Sep 2000 09:37:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Al and Stephen: This is a very good starting point for the discussion. The community owes you a great deal of thanks for your effort. I have only a few comments at this time: Page 5: The advantages of a credential server approach to credential transfer are two-fold: There is plausibly a third advantage, namely, the credential server can enforce a uniform security policy governing credentials transfer. This assertion is based on the assumption that credentials are typically issued by an organization for its own purposes, and are not the creation of the end user, so must be governed by the policies of the issuer, not the user. Correspondingly, this becomes a disadvantage of the direct approach. In the direct case an organization has to trust clients to correctly implement their policies when moving credentials from one device to another. Everyone wants the convenience of direct transfer, but they strike me as less secure than the server based mechanism. Page 7: <> Presumably, the supposed advantage of treating them as opaque octet strings is then the protocol can be extended transparently to transport new formats. But, as the community has seen time and time again, doing so usually renders a protocol immune from security analysis; it is usually difficult or impossible to understand the security properties of the extended protocol, and to build in checking to at least nominally enforce security, without also understanding the details of what gets sent (or appears to get sent). If this is indeed true, then requiring some kind of structure on the credentials will probably allow us to converge on a protocol faster. It seems to me that CMS has dealt with this issue about as well as can be dealt with by ideas in general circulation today. Page 7 continues with Section 2.4 and F5. The framework MUST allow use of different transports. <> This is a really critical question, but it strikes me as premature. There has not been sufficient discussion about the properties needed by SACRED to resolve it. Usually no one wants to pay the cost of a TCP connection, but then again the operational requirements may drive us to re-invent TCP to cause the protocol to behave correctly, in which case we should declare victory and then use some TCP based transport. We need to identify and understand what sort of synchronization primitives SACRED requires in order to resolve this issue. Page 8: I was surprised that section 3.1 failed to require that the protocol be immune from on-line and off-line dictionary attacks, or at least make this a goal, given that the document alludes to password based methods in prior sections. I have a question on requirement S6: S6. Credential servers MUST be authenticated to the user for all operations except (possibly) download. Why the "except (possibly) download"? It is not evident to me that the user would ever want to engage an unauthenticated server. I want to understand the reasoning behind these three words. Page 9: Requirement S7 says 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). It seems like this MUST must also to apply to upload. If we end up with password wrapped credentials, do you really want to store them in the credentials server run by Hackers-R-Us, accessed via their wireless access point in the parking lot? The user really has to get at least a warm feeling that she is dealing with the valid credentials server prior to storing them in the network. S11. Users MUST be able to manage their credentials stored on the credential server. This is really a key point to enable scaling. If the security or network administrator himself has to manage the credentials, no one will ever deploy this protocol on a large enough scale to make it interesting. Having said this, it is not clear to me how this system will work without having some access control mechanism around deletes and replacements, so that the legitimate user is the only party ("perhaps" aside from a duely authorized "administrator") can perform these operations. Page 10: Mobile credentials will never be as secure as a "pure" hardware- based solution... It might however be worth noting that mobile credentials might be more secure than the current widely common practice of storing credentials on a hard drive, encrypted under a weak password (or worse)! My compliments again on a very fine document. Jesse Walker Intel Corporation 2111 NE 25th Avenue JF3-448 Hillsboro, OR 97124-5961 (503) 712-1849 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Monday, September 25, 2000 7:36 AM To: ietf-sacred Subject: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Hi All, I posted this on Friday, but it hasn't shown up in the drafts directory so far. In any case, let's now see how much agreement we have on requirements, so please comment to the list on the attached (which is still very much a first draft). Just to update you on our WG status: we've now agreed the charter (no significant change) with Marcus Leech, one of the security ADs and are on the list of putative WGs for which messages will be sent to the IETF announce list sometime "soon". (see: http://www.ietf.org/iesg/1wg_actions.txt if you like that sort of stuff) Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 09:42:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16977 for ietf-sacred-bks; Mon, 25 Sep 2000 09:42:14 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16972 for ; Mon, 25 Sep 2000 09:42:13 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id QAA07638; Mon, 25 Sep 2000 16:46:27 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 25 Sep 2000 16:45:24 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 09:45:22 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9A3E@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Michael Leahy'" , ietf-sacred@imc.org Subject: RE: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Date: Mon, 25 Sep 2000 09:45:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael: I didn't find the requirement anywhere in the requirement document that the user authenticate himself to the credentials server, only that the credentials server authenticates itself to the user. Do you believe user-to-server authentication should be a requirement? I guess I'd want this at least for downloads (especially if my credentials are protected by a weak password), deletes, and replacements. Jesse Walker Intel Corporation 2111 NE 25th Ave JF3-448 Hillsboro, OR 97124-5961 (503) 712-1849 -----Original Message----- From: Michael Leahy [mailto:Michael.Leahy@cp.net] Sent: Monday, September 25, 2000 8:21 AM To: ietf-sacred@imc.org Subject: Fw: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Hi Stephen Once a user authenticates themselves into the "credential server" is there a concept of time limit that the authentication is valid for (i.e they have re-authenticate themselves again). I am particularly thinking of the "internet cafe" or "computer services offered at airports" type of environments. I pay for use of the computer for 1 hour and I have been using the "credential server". So really I have 2 qts 1. Is there a concept of how long the credentials extracted from the server can be used on the desktop/PDAs/wireless device. 2. While using the extracted data do they have re-validate themselves after a few minutes before using the credentials My thinking here is the idea of a credential server policy on extracted data. Regards Michael ----- Original Message ----- From: Stephen Farrell To: ietf-sacred Sent: Monday, September 25, 2000 3:35 PM Subject: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] > > Hi All, > > I posted this on Friday, but it hasn't shown up in the drafts > directory so far. In any case, let's now see how much agreement > we have on requirements, so please comment to the list on the > attached (which is still very much a first draft). > > Just to update you on our WG status: we've now agreed the > charter (no significant change) with Marcus Leech, one of > the security ADs and are on the list of putative WGs for > which messages will be sent to the IETF announce list > sometime "soon". > > (see: http://www.ietf.org/iesg/1wg_actions.txt if you like > that sort of stuff) > > Regards, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 10:08:33 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA19256 for ietf-sacred-bks; Mon, 25 Sep 2000 10:08:33 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19252 for ; Mon, 25 Sep 2000 10:08:31 -0700 (PDT) Received: by balinese.baltimore.ie; id SAA24764; Mon, 25 Sep 2000 18:11:43 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma024733; Mon, 25 Sep 00 18:11:17 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA05209; Mon, 25 Sep 2000 18:11:17 +0100 Message-ID: <39CF87D3.97F60850@baltimore.ie> Date: Mon, 25 Sep 2000 18:13:55 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Walker, Jesse" CC: ietf-sacred Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <392A357CE6FFD111AC3E00A0C99848B002FE9A3D@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Jesse, > I have only a few comments at this time: Hate to see if you'd a lot of comments:-) > Page 5: > > The advantages of a credential server approach to credential > transfer are two-fold: > > There is plausibly a third advantage, namely, ... Fine. No problem adding something like that. > < just regard them as octet strings? The latter is simpler, except > that perhaps a password is used both to authenticate to a credential > server *and* to encrypt the private parts of a pkcs#12 file.>> > > Presumably, the supposed advantage of treating them as opaque octet strings > is then the protocol can be extended transparently to transport new formats. > But, as the community has seen time and time again, doing so usually renders > a protocol immune from security analysis; it is usually difficult or > impossible to understand the security properties of the extended protocol, > and to build in checking to at least nominally enforce security, without > also understanding the details of what gets sent (or appears to get sent). > If this is indeed true, then requiring some kind of structure on the > credentials will probably allow us to converge on a protocol faster. It > seems to me that CMS has dealt with this issue about as well as can be dealt > with by ideas in general circulation today. Couple of things:- - A client has to know the details of the credential format, but we don't necessarily have to force a credential server to know it. This could be achieved if the password change is done by the client sending up the new/modified credential, along with the authentication information in a format that the credential server can understand. That way, whether the credential format uses the same or a different password is a client-only issue. - In terms of picking a format, I'm not sure CMS is right here, I think that one of pkcs#15 or a combination of a pkcs#12 with a pkcs#7 certs-only message (for root information that isn't usually in p#12 files) would be reasonable. Early days for diving into such detail, though of course, we will have to pick one format as the MUST implement at some stage. > Page 7 continues with Section 2.4 and > > F5. The framework MUST allow use of different transports. > > < doesn't fit to be worked on later? If we pick one, possiblities > would include: directly over TCP or UDP or even SCTP, on top of > HTTP, or SMTP or even FTP or BEEP. >> > > This is a really critical question, but it strikes me as premature. There > has not been sufficient discussion about the properties needed by SACRED to > resolve it. Usually no one wants to pay the cost of a TCP connection, but > then again the operational requirements may drive us to re-invent TCP to > cause the protocol to behave correctly, in which case we should declare > victory and then use some TCP based transport. We need to identify and > understand what sort of synchronization primitives SACRED requires in order > to resolve this issue. Fair point. > > Page 8: > > I was surprised that section 3.1 failed to require that the protocol be > immune from on-line and off-line dictionary attacks, or at least make this a > goal, given that the document alludes to password based methods in prior > sections. We were trying to elicit others' input here, specifically, we'd welcome specific suggested text as to the attacks against which we MUST/SHOULD protect. We definitely do need some text on this. > > I have a question on requirement S6: > > S6. Credential servers MUST be authenticated to the user for all > operations except (possibly) download. > > Why the "except (possibly) download"? It is not evident to me that the user > would ever want to engage an unauthenticated server. I want to understand > the reasoning behind these three words. In case the client starts with no root information and e.g. cannot use an SSL server authenticated session. > Page 9: > > Requirement S7 says > > 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). > > It seems like this MUST must also to apply to upload. If we end up with > password wrapped credentials, do you really want to store them in the > credentials server run by Hackers-R-Us, accessed via their wireless access > point in the parking lot? The user really has to get at least a warm feeling > that she is dealing with the valid credentials server prior to storing them > in the network. Fair enough. OTOH, be nice if the mechanism we come up with was so strong that hackers-r-us was usable as a credential server (should we make that a requirement:-) > > S11. Users MUST be able to manage their credentials stored on the > credential server. > > This is really a key point to enable scaling. If the security or network > administrator himself has to manage the credentials, no one will ever deploy > this protocol on a large enough scale to make it interesting. Having said > this, it is not clear to me how this system will work without having some > access control mechanism around deletes and replacements, so that the > legitimate user is the only party ("perhaps" aside from a duely authorized > "administrator") can perform these operations. I agree, but I'm not sure that we can get into more detail in this document, nor that the access control solution is required to be interoperable (it seems mostly like a credential server implementation issue). Would welcome suggested text of course. > Page 10: > > Mobile credentials will never be as secure as a "pure" hardware- > based solution... > > It might however be worth noting that mobile credentials might be more > secure than the current widely common practice of storing credentials on a > hard drive, encrypted under a weak password (or worse)! Good idea! Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 10:11:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19341 for ietf-sacred-bks; Mon, 25 Sep 2000 10:11:34 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19337 for ; Mon, 25 Sep 2000 10:11:31 -0700 (PDT) Received: by balinese.baltimore.ie; id SAA25030; Mon, 25 Sep 2000 18:14:44 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma024978; Mon, 25 Sep 00 18:14:14 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA05288; Mon, 25 Sep 2000 18:14:13 +0100 Message-ID: <39CF8883.2F5C6758@baltimore.ie> Date: Mon, 25 Sep 2000 18:16:51 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Walker, Jesse" CC: "'Michael Leahy'" , ietf-sacred@imc.org Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <392A357CE6FFD111AC3E00A0C99848B002FE9A3E@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Walker, Jesse" wrote: > > Michael: > > I didn't find the requirement anywhere in the requirement document that the > user authenticate himself to the credentials server, only that the > credentials server authenticates itself to the user. Do you believe > user-to-server authentication should be a requirement? I guess I'd want this > at least for downloads (especially if my credentials are protected by a weak > password), deletes, and replacements. User authentication (of some sort) should be explicitly required for download. I'll make sure we're clearer on this next time 'round. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Sep 25 15:36:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA25847 for ietf-sacred-bks; Mon, 25 Sep 2000 15:36:24 -0700 (PDT) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25843 for ; Mon, 25 Sep 2000 15:36:21 -0700 (PDT) Received: from djablon.world.std.com (netegrity.netegrity.com [63.73.77.10]) by world.std.com (8.9.3/8.9.3) with ESMTP id SAA13998; Mon, 25 Sep 2000 18:34:55 -0400 (EDT) Message-Id: <4.3.2.7.0.20000925172213.00b081b0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Sep 2000 18:34:33 -0400 To: stephen.farrell@baltimore.ie, "Walker, Jesse" From: David Jablon Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Cc: ietf-sacred In-Reply-To: <39CF87D3.97F60850@baltimore.ie> References: <392A357CE6FFD111AC3E00A0C99848B002FE9A3D@hdsmsx31.hd.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are some comments on the requirements for preventing attacks and server-authentication, with suggested text. Jesse Walker raised some good points, including: > > Page 8: > > I was surprised that section 3.1 failed to require that the protocol be > > immune from on-line and off-line dictionary attacks, or at least make > this a > > goal, given that the document alludes to password based methods in prior > > sections. At 06:13 PM 9/25/00 +0100, Stephen Farrell wrote: >We were trying to elicit others' input here, specifically, we'd welcome >specific suggested text as to the attacks against which we MUST/SHOULD >protect. We definitely do need some text on this. How about text like the following: "The protocol MUST prevent off-line brute-force attacks from the network, and MUST support mechanisms to deter on-line brute-force attacks. The protocol MAY support mechanisms to prevent off-line brute-force attacks from the server." Here's some explanation behind this wording ... point 1) "Brute-force" seems more appropriate than "dictionary", since the latter term is sometimes construed (too-)narrowly to designate pre-built dictionaries, English word lists, and so on. point 2) A separate treatment of on-line and off-line attacks is necessary because deterring on-line attacks, via server-counting of bad attempts, etc., seems at least partly outside the scope of the protocol. point 3) The primary focus should be on *network-based* off-line attacks, rather than server-based off-line attacks, since the latter may also be addressed in ways that are outside the scope of the protocol. > > I have a question on requirement S6: > > S6. Credential servers MUST be authenticated to the user for all > > operations except (possibly) download. > > > > Why the "except (possibly) download"? It is not evident to me that the user > > would ever want to engage an unauthenticated server. I want to understand > > the reasoning behind these three words. > >In case the client starts with no root information and e.g. cannot use an >SSL server authenticated session. Regardless of whether the client has "root" information, there may also be concerns over whether the user has the ability or motivation to perform the necessary actions to authenticate the server. We must also accommodate download protocols that can operate securely without this assumption. I'd suggest removing the word "(possibly)" from S6 to avoid confusion, or better still, explicitly list the operations where server authentication *is* required. The download case can be treated separately, perhaps in a suitably modified S7. > > Page 9: > > Requirement S7 says > > 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). > > > > It seems like this MUST must also to apply to upload. If we end up with > > password wrapped credentials, do you really want to store them in the > > credentials server run by Hackers-R-Us, accessed via their wireless access > > point in the parking lot? The user really has to get at least a warm > feeling > > that she is dealing with the valid credentials server prior to storing them > > in the network. >Fair enough. OTOH, be nice if the mechanism we come up with was so strong >that hackers-r-us was usable as a credential server (should we make that >a requirement:-) S7 needs to be re-written to separately treat upload and download, and to more broadly state the desired security goals, instead of focusing on the specific mechanism of prior user authentication of the server. As mentioned above, this requirement is not necessary in all secure download protocols, and it can introduce unnecessary risks. The parenthetical remark in S7 above also raises interesting questions. It suggests that *the* user (as if there is only one) is either able or unable to verify the server, and further implies that if he is able to do it, then it will be done. But what about a heterogeneous population -- with some users who can and do authenticate the server, and some who can't or don't? I think a design requirement should be worded in a form that more clearly encompasses all users. The use of the term MUST in S7 seems to imply that the specific feature of users authenticating servers is a cornerstone of the security model. Yet, an alternate mechanism, perhaps one that is strong enough to permit a hacker to run a credentials server, would definitely make Requirement S7 unnecessary as it is written. I suggest that S7 be replaced by a more broadly worded statement of higher level requirements, that focuses on the goals, and not the mechanism, perhaps something more like: "The protocol MUST prevent an enemy from posing as a credential server and obtaining either the user's credentials or the user's authentication data needed to masquerade as the user." This is meant to broadly encompasses solutions that need a pre-authenticated server, and solutions that authenticate a server and/or credential delivery package using other mechanisms. -- David From owner-ietf-sacred Tue Sep 26 01:07:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA05172 for ietf-sacred-bks; Tue, 26 Sep 2000 01:07:28 -0700 (PDT) Received: from puma.dub0.ie.cp.net (puma.dub0.ie.cp.net [194.106.154.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA05168 for ; Tue, 26 Sep 2000 01:07:26 -0700 (PDT) Received: from starcraft (194.106.155.123) by puma.dub0.ie.cp.net (5.1.046) id 39B3DCD400003277 for ietf-sacred@imc.org; Tue, 26 Sep 2000 09:11:53 +0100 Message-ID: <015601c02791$b8b429d0$7b9b6ac2@isocor.ie> Reply-To: "Michael Leahy" From: "Michael Leahy" To: Subject: Audit trails with Credential Server Date: Tue, 26 Sep 2000 09:13:58 +0100 Organization: Critical Path MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0153_01C0279A.1A70F0B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0153_01C0279A.1A70F0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 "You are only as secure as your last audit trail" - Someone once said = this to me (can not remember who) and it always sticks in my mind. So = any thoughts on what information {if any} SHOULD be logged by the = credential server. I don't really want to go down the route of notaries = but I do beleive that some minimum information should be kept.=20 Here's a list that comes to mind 1. User login ID (in whatever form the user authenticates themselves) 2. Time that request was made=20 3. User ip address - Since we have not decided on TCP/IP as the = transport mechanism then what we log here will obviously change.=20 4. I would also recommend logging the request syntax (user) and server = response. This way whatever we decide on as the authentication mechanism = we would get for free in the log Again I realize that what gets logged will be implementation dependent = but it is in my opinion a necessary function - so I beleive me should = define a minimum set.=20 Any thoughts ? Regards Michael ------=_NextPart_000_0153_01C0279A.1A70F0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
"You are only as secure as your last = audit trail" -=20 Someone once said this to me (can not remember who) and it always sticks = in my=20 mind. So any thoughts on what information {if any} SHOULD be logged by = the=20 credential server. I don't really want to go down the route of notaries = but I do=20 beleive that some minimum information should be kept.
 
Here's a list that comes to = mind
1. User login ID (in whatever form the = user=20 authenticates themselves)
2. Time that request was made =
3. User ip address - Since we have not = decided on=20 TCP/IP as the transport mechanism then what we log here will = obviously=20 change.
4. I would also recommend logging the = request=20 syntax (user) and server response. This way whatever we decide on as the = authentication mechanism we would get for free in the log
 
Again I realize that what gets = logged will be=20 implementation dependent but it is in my opinion a necessary function - = so I=20 beleive me should define a minimum set.
 
Any thoughts ?
 
Regards
Michael
------=_NextPart_000_0153_01C0279A.1A70F0B0-- From owner-ietf-sacred Tue Sep 26 03:25:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09307 for ietf-sacred-bks; Tue, 26 Sep 2000 03:25:56 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09303 for ; Tue, 26 Sep 2000 03:25:51 -0700 (PDT) Received: by balinese.baltimore.ie; id LAA03165; Tue, 26 Sep 2000 11:29:06 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma002923; Tue, 26 Sep 00 11:28:06 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA19393; Tue, 26 Sep 2000 11:28:04 +0100 Message-ID: <39D07AD2.D40732C4@baltimore.ie> Date: Tue, 26 Sep 2000 11:30:43 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Leahy CC: ietf-sacred@imc.org Subject: Re: Audit trails with Credential Server References: <015601c02791$b8b429d0$7b9b6ac2@isocor.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael, You're right that audit is important, however, I don't see where any of this affects interoperability, at least not with the data you suggest auditing. If that's true, then it doesn't belong in our specs, except perhaps if we want to give some guidance in an area where folks are otherwise likely to go wrong. Stephen. > Michael Leahy wrote: > > Hi > > "You are only as secure as your last audit trail" - Someone once said this to me (can not remember > who) and it always sticks in my mind. So any thoughts on what information {if any} SHOULD be > logged by the credential server. I don't really want to go down the route of notaries but I do > beleive that some minimum information should be kept. > > Here's a list that comes to mind > 1. User login ID (in whatever form the user authenticates themselves) > 2. Time that request was made > 3. User ip address - Since we have not decided on TCP/IP as the transport mechanism then what we > log here will obviously change. > 4. I would also recommend logging the request syntax (user) and server response. This way whatever > we decide on as the authentication mechanism we would get for free in the log > > Again I realize that what gets logged will be implementation dependent but it is in my opinion a > necessary function - so I beleive me should define a minimum set. > > Any thoughts ? > > Regards > Michael -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 03:38:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09447 for ietf-sacred-bks; Tue, 26 Sep 2000 03:38:58 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09443 for ; Tue, 26 Sep 2000 03:38:56 -0700 (PDT) Received: by balinese.baltimore.ie; id LAA06624; Tue, 26 Sep 2000 11:42:12 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma005953; Tue, 26 Sep 00 11:39:50 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA19874; Tue, 26 Sep 2000 11:39:48 +0100 Message-ID: <39D07D93.6D36BC70@baltimore.ie> Date: Tue, 26 Sep 2000 11:42:27 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: "Walker, Jesse" , ietf-sacred Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <392A357CE6FFD111AC3E00A0C99848B002FE9A3D@hdsmsx31.hd.intel.com> <4.3.2.7.0.20000925172213.00b081b0@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, > "The protocol MUST prevent off-line brute-force attacks from the > network, and MUST support mechanisms to deter on-line brute-force > attacks. The protocol MAY support mechanisms to prevent > off-line brute-force attacks from the server." > > Here's some explanation behind this wording ... > > point 1) "Brute-force" seems more appropriate than "dictionary", since the > latter term is sometimes construed (too-)narrowly to designate pre-built > dictionaries, English word lists, and so on. > > point 2) A separate treatment of on-line and off-line attacks is necessary > because deterring on-line attacks, via server-counting of bad attempts, > etc., seems at least partly outside the scope of the protocol. > > point 3) The primary focus should be on *network-based* off-line attacks, > rather than server-based off-line attacks, since the latter may also be > addressed in ways that are outside the scope of the protocol. If we need the explanation behind the wording, then we don't have the wording right:-) It is better that what's currently there, of course, so we're improving. I don't think I follow what is meant by "network-based off-line". Can you elaborate? > I'd suggest removing the word "(possibly)" from S6 to avoid confusion, > or better still, explicitly list the operations where server authentication > *is* > required. The download case can be treated separately, perhaps in a > suitably modified S7. I like your new S7 text, but can't list the operations here since we don't know 'em yet (they'll be part of the framework draft I guess). I think S6 is ok as is, given the new S7 text. > "The protocol MUST prevent an enemy from posing as a credential > server and obtaining either the user's credentials or the user's > authentication data needed to masquerade as the user." Looks good. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 04:02:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09797 for ietf-sacred-bks; Tue, 26 Sep 2000 04:02:38 -0700 (PDT) Received: from puma.dub0.ie.cp.net (puma.dub0.ie.cp.net [194.106.154.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09793 for ; Tue, 26 Sep 2000 04:02:36 -0700 (PDT) Received: from starcraft (194.106.155.123) by puma.dub0.ie.cp.net (5.1.046) id 39B3DCD400003395 for ietf-sacred@imc.org; Tue, 26 Sep 2000 12:07:03 +0100 Message-ID: <029101c027aa$31414aa0$7b9b6ac2@isocor.ie> Reply-To: "Michael Leahy" From: "Michael Leahy" To: References: <015601c02791$b8b429d0$7b9b6ac2@isocor.ie> <39D07AD2.D40732C4@baltimore.ie> Subject: Re: Audit trails with Credential Server Date: Tue, 26 Sep 2000 12:09:08 +0100 Organization: Critical Path MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA09794 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Stephen true, it does not affect interoperability. So just defining a minimum set of attributes {or data blocks} that should be logged would suffice and any gotcha's that might be associated with these. Regards Michael ----- Original Message ----- From: Stephen Farrell To: Michael Leahy Cc: Sent: Tuesday, September 26, 2000 11:30 AM Subject: Re: Audit trails with Credential Server > > Michael, > > You're right that audit is important, however, I don't see > where any of this affects interoperability, at least not > with the data you suggest auditing. If that's true, then > it doesn't belong in our specs, except perhaps if we want > to give some guidance in an area where folks are otherwise > likely to go wrong. > > Stephen. > > > Michael Leahy wrote: > > > > Hi > > > > "You are only as secure as your last audit trail" - Someone once said this to me (can not remember > > who) and it always sticks in my mind. So any thoughts on what information {if any} SHOULD be > > logged by the credential server. I don't really want to go down the route of notaries but I do > > beleive that some minimum information should be kept. > > > > Here's a list that comes to mind > > 1. User login ID (in whatever form the user authenticates themselves) > > 2. Time that request was made > > 3. User ip address - Since we have not decided on TCP/IP as the transport mechanism then what we > > log here will obviously change. > > 4. I would also recommend logging the request syntax (user) and server response. This way whatever > > we decide on as the authentication mechanism we would get for free in the log > > > > Again I realize that what gets logged will be implementation dependent but it is in my opinion a > > necessary function - so I beleive me should define a minimum set. > > > > Any thoughts ? > > > > Regards > > Michael > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 07:37:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA17585 for ietf-sacred-bks; Tue, 26 Sep 2000 07:37:14 -0700 (PDT) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17581 for ; Tue, 26 Sep 2000 07:37:13 -0700 (PDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id HAA19563 for ; Tue, 26 Sep 2000 07:40:31 -0700 (PDT) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 26 Sep 2000 14:40:30 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Sep 2000 07:40:28 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9A4E@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: ietf-sacred@imc.org Subject: RE: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Date: Tue, 26 Sep 2000 07:40:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen: Two-way authentication does seem necessary for normal operation. There is, however, at least one case for which it may be worthwhile to consider one-way authentication of the SACRED server to its client, during initial enrollment into the system. It may be worth considering an enrollment framework that works like SSL as normally deployed (maybe the enrollment framework will use SSL), where the server is strongly authenticated to the client but not vice versa, but a relatively secure channel is established between the client and the server. Once the server is strongly authenticated to the client and a secure channel established between them, there are a wide variety of exchanges that could occur between them to effect enrollment. For example, someone running a commercial SACRED service might not want to authenticate the user at all during enrollment--a valid credit card number received over the secure channel may suffice, as anything more would drive the service's administrative costs. Or an enterprise might want to use weak authentication like a username and cleartext password or even an employee ID sent over the secure channel, so they can reuse existing databases to control access to the service. Or they might require the user to authenticate via the credentials the user wants to store at the SACRED server. Once any of these steps completes, presumably the initial enrollment protocol would permit the user to establish the user authentication information needed to allow access her own SACRED records. My point is the one-way authentication model adopted by SSL seems to be a very powerful framework for attacking bootstrap problems, and it is worth considering this paradigm as a way to get users enrolled into SACRED. A SACRED initial enrollment protocol may or may not be considered within scope, but we know from past efforts (e.g. think of certificate management protocols and IPsec) that this sort of thing is almost always a source of interoperability problems and therefore a deployment barrier when it is not dealt with. Jesse Walker -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Monday, September 25, 2000 10:17 AM To: Walker, Jesse Cc: 'Michael Leahy'; ietf-sacred@imc.org Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] "Walker, Jesse" wrote: > > Michael: > > I didn't find the requirement anywhere in the requirement document that the > user authenticate himself to the credentials server, only that the > credentials server authenticates itself to the user. Do you believe > user-to-server authentication should be a requirement? I guess I'd want this > at least for downloads (especially if my credentials are protected by a weak > password), deletes, and replacements. User authentication (of some sort) should be explicitly required for download. I'll make sure we're clearer on this next time 'round. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 07:53:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17855 for ietf-sacred-bks; Tue, 26 Sep 2000 07:53:17 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17851 for ; Tue, 26 Sep 2000 07:53:16 -0700 (PDT) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id OAA01166; Tue, 26 Sep 2000 14:57:24 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 26 Sep 2000 14:56:22 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Sep 2000 07:55:56 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9A50@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred@imc.org Subject: RE: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Date: Tue, 26 Sep 2000 07:55:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen: That's fine. Thanks. -- Jesse -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Tuesday, September 26, 2000 7:56 AM To: Walker, Jesse Cc: ietf-sacred@imc.org Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Hi Jesse, I agree that we need to be sure that we allow for enrollment. How about including requirements to the effect that user self-enrollment MUST be allowed for in the framework and SHOULD (?) be provided by the concrete protocol. Whether enrollment is just a specific form of an upload operation or something else can be decided once we start delving into the framework more. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 07:50:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17793 for ietf-sacred-bks; Tue, 26 Sep 2000 07:50:45 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17786 for ; Tue, 26 Sep 2000 07:50:43 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA19709; Tue, 26 Sep 2000 15:54:00 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma019677; Tue, 26 Sep 00 15:53:11 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA28367; Tue, 26 Sep 2000 15:53:11 +0100 Message-ID: <39D0B8F5.F047610B@baltimore.ie> Date: Tue, 26 Sep 2000 15:55:49 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Walker, Jesse" CC: ietf-sacred@imc.org Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <392A357CE6FFD111AC3E00A0C99848B002FE9A4E@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Jesse, I agree that we need to be sure that we allow for enrollment. How about including requirements to the effect that user self-enrollment MUST be allowed for in the framework and SHOULD (?) be provided by the concrete protocol. Whether enrollment is just a specific form of an upload operation or something else can be decided once we start delving into the framework more. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 09:27:38 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23416 for ietf-sacred-bks; Tue, 26 Sep 2000 09:27:38 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23410 for ; Tue, 26 Sep 2000 09:27:33 -0700 (PDT) Received: from bpsi.net (port409.bpsi.net [209.54.245.209]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e8QGUQn03802; Tue, 26 Sep 2000 11:30:26 -0500 (CDT) Message-ID: <39D0CE9C.CEDFB3E1@bpsi.net> Date: Tue, 26 Sep 2000 11:28:12 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: stephen.farrell@baltimore.ie, ietf-sacred , Al Arsenault Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <39CF62C3.9D80038D@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All, Al and Stephen should be commended for their excellent work on this draft. Please see a couple of additional comments, below. Best Regards, Dale Gustafson --------------------------------------------------------------------------------- 1.1 Background and Motivation Presently, roaming is most often accomplished by exporting a key and certificate (as a PKCS#12 file) from one PC and importing it to some other PC. Current versions of Netscape Communicator support a more elegant (application-specific) “roaming” capability that can be used to transfer desktop settings, the email address book, URL bookmarks, you-name-it, to another PC (also running Netscape) through a roaming server. See { Edit | Preferences | Roaming Access | Item Selection } in current versions of Netscape Communicator. Moreover, smart cards may not work well in a PKI environment when configured as read-only (sometimes called "write-once") devices, as is being alluded to here. In any event, in this document the emphasis should be placed on "interoperability" -- articulating the need for a standard protocol or protocols and standard secure credential data formats. I suggest replacing the last four paragraphs of this section with something like ... It is envisioned that making credentials securely available to “roaming” users (in an interoperable fashion) will provide substantial value to network owners, administrators, and end users. The intent is that this value be provided largely independent of which hardware device is used to access the secure credential and what type of storage media the secure credential is written to. Each different credential storage device, be it desktop or laptop PC computer memory, a 3.5 inch flexible diskette, a hard disk file, a cell phone, a smart card, (or whatever) will have very different security characteristics and, perhaps, very different protocol handling capabilities. Users will be able to securely and reliably move their credentials between different locations, different Internet devices, and different storage media as needed. --------------------------------------------------------------------------------- > 2.3 Credential Formats ... > < just regard them as octet strings? The latter is simpler, except > that perhaps a password is used both to authenticate to a credential > server *and* to encrypt the private parts of a pkcs#12 file.>> Ideally, credential protocols and data formats will be architected in an extensible fashion that ensures each defined element is clearly identified (within the protocol and within the credential) and also allows new formats and versions to be added over time. One or more methods of extending the protocol or data format are designed in at the outset. The real art form here is in making things both sufficiently well structured and sufficiently open-ended such that product builders can utilize this new standard without arbitrarily forcing a redesign of products that are currently in the market or in the R&D pipeline. While I agree this could make security analysis more complex, it doesn't necessarily make it impractical -- it's a concern to be kept in mind throughout but not necessarily a show-stopper. The credential format, the download and upload protocols, and the credential storage device’s unique capabilities may be highly interrelated in some cases. Shouldn't we say something about that in this section ? --------------------------------------------------------------------------------- > 5. Security Considerations The current wording tends to downplay the benefits of the standardization work ahead -- which is clearly an important step forward. I would like to think this work will enable substantial progress beyond the current state of the art. I suggest we save this discussion until it can be stated more specifically in subsequent documents and replace the existing section 5 with the standard clause ... 5. Security Considerations This entire document is about security. From owner-ietf-sacred Tue Sep 26 10:20:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24801 for ietf-sacred-bks; Tue, 26 Sep 2000 10:20:57 -0700 (PDT) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24797 for ; Tue, 26 Sep 2000 10:20:54 -0700 (PDT) Received: from djablon.world.std.com (netegrity.netegrity.com [63.73.77.10]) by world.std.com (8.9.3/8.9.3) with ESMTP id NAA09592; Tue, 26 Sep 2000 13:20:57 -0400 (EDT) Message-Id: <4.3.2.7.0.20000926123137.00b15cc0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Sep 2000 13:21:31 -0400 To: stephen.farrell@baltimore.ie From: David Jablon Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Cc: "Walker, Jesse" , ietf-sacred In-Reply-To: <39D07D93.6D36BC70@baltimore.ie> References: <392A357CE6FFD111AC3E00A0C99848B002FE9A3D@hdsmsx31.hd.intel.com> <4.3.2.7.0.20000925172213.00b081b0@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regarding the text: > > "The protocol MUST prevent off-line brute-force attacks from the > > network, and MUST support mechanisms to deter on-line brute-force > > attacks. The protocol MAY support mechanisms to prevent > > off-line brute-force attacks from the server." > > > > Here's some explanation behind this wording [...] > > point 3) The primary focus should be on *network-based* off-line attacks, > > rather than server-based off-line attacks, since the latter may also be > > addressed in ways that are outside the scope of the protocol. At 11:42 AM 9/26/00 +0100, Stephen Farrell wrote: >If we need the explanation behind the wording, then we don't >have the wording right:-) It is better that what's currently >there, of course, so we're improving. Thanks, I think. :-) >I don't think I follow what is meant by "network-based off-line". >Can you elaborate? I meant "network-based off-line attacks" to be the same as "off-line brute-force attacks from the network" -- generally attacks where the enemy is *not* presumed to be in control of the credentials server or have access to secret data on the server. But this enemy may eavesdrop, or pose (unsuccessfully) as a client to the server, or vice-versa, or maybe act as a man-in-the-middle, to obtain some crucial data. He then uses the data off-line to crack a password or private key. -- David From owner-ietf-sacred Tue Sep 26 14:11:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA00456 for ietf-sacred-bks; Tue, 26 Sep 2000 14:11:15 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00452 for ; Tue, 26 Sep 2000 14:11:13 -0700 (PDT) Received: by balinese.baltimore.ie; id WAA29424; Tue, 26 Sep 2000 22:14:28 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma029416; Tue, 26 Sep 00 22:14:03 +0100 Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA04060; Tue, 26 Sep 2000 22:14:01 +0100 Message-ID: <39D11237.BDD89C9@baltimore.ie> Date: Tue, 26 Sep 2000 22:16:39 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: ietf-sacred Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <392A357CE6FFD111AC3E00A0C99848B002FE9A3D@hdsmsx31.hd.intel.com> <4.3.2.7.0.20000925172213.00b081b0@world.std.com> <4.3.2.7.0.20000926123137.00b15cc0@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, > Thanks, I think. :-) You're welcome. Honest. :-) > > >I don't think I follow what is meant by "network-based off-line". > >Can you elaborate? > > I meant "network-based off-line attacks" to be the same as "off-line > brute-force > attacks from the network" -- generally attacks where the enemy is *not* > presumed > to be in control of the credentials server or have access to secret data on > the server. > But this enemy may eavesdrop, or pose (unsuccessfully) as a client to the > server, > or vice-versa, or maybe act as a man-in-the-middle, to obtain some crucial > data. > He then uses the data off-line to crack a password or private key. Ok, now I see what you mean. Does anyone know of an existing classification of various attacks against password based authentication schemes that we might be able to re-use here? (Or feel like creating one?) Reason I ask is that I can see us spending a lot of time explaining ourselves to one another otherwise. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Sep 26 14:20:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01041 for ietf-sacred-bks; Tue, 26 Sep 2000 14:20:10 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01035 for ; Tue, 26 Sep 2000 14:20:08 -0700 (PDT) Received: by balinese.baltimore.ie; id WAA29526; Tue, 26 Sep 2000 22:23:27 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma029522; Tue, 26 Sep 00 22:22:55 +0100 Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA04233; Tue, 26 Sep 2000 22:22:53 +0100 Message-ID: <39D11448.631CC402@baltimore.ie> Date: Tue, 26 Sep 2000 22:25:28 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dale Gustafson CC: ietf-sacred Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <39CF62C3.9D80038D@baltimore.ie> <39D0CE9C.CEDFB3E1@bpsi.net> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id WAA04233 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA01037 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Dale, > I suggest replacing the last four paragraphs > of this section with something like ... Ahh, suggested text - great! (Looks good too.) > The credential format, the download and upload protocols, and the credential > storage device’s unique capabilities may be highly interrelated in some cases. > Shouldn't we say something about that in this section ? Agreed. But before we know what to say, we first need to figure out if we've consensus that credentials are regarded (by the protocol) as octet strings or whether the credential structure is "exposed" in the protocol. *If* we can keep knowledge of the credential structure in the client, then I don't think we need to bother with it in the protocol or credential server. Personally, I'm not sure. > > 5. Security Considerations > > This entire document is about security. Hmm. Doesn't that generate general scoffing at the SAAG every now and then? Some of the more interesting text I've seen in these recently has been about d-o-s attacks, which tends not to fit elsewhere. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Wed Sep 27 08:04:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25393 for ietf-sacred-bks; Wed, 27 Sep 2000 08:04:02 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25385 for ; Wed, 27 Sep 2000 08:04:00 -0700 (PDT) Received: from bpsi.net (port408.bpsi.net [209.54.245.208]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e8RF75S29519; Wed, 27 Sep 2000 10:07:06 -0500 (CDT) Message-ID: <39D20C94.681510EA@bpsi.net> Date: Wed, 27 Sep 2000 10:04:52 -0500 From: Dale Gustafson X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: ietf-sacred Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] References: <39CF62C3.9D80038D@baltimore.ie> <39D0CE9C.CEDFB3E1@bpsi.net> <39D11448.631CC402@baltimore.ie> Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Stephen,

Please see comments inline.

Regards,

Dale Gustafson
 

Stephen Farrell wrote:

> The credential format, the download and upload protocols, and the credential
> storage device’s unique capabilities may be highly interrelated in some cases.
> Shouldn't we say something about that in this section ?

Agreed. But before we know what to say, we first need to figure out
if we've consensus that credentials are regarded (by the protocol) as
octet strings or whether the credential structure is "exposed" in the
protocol. *If* we can keep knowledge of the credential structure in
the client, then I don't think we need to bother with it in the
protocol or credential server. Personally, I'm not sure.

That's likely to be self-evident when the details of what must be done to download and install credentials in a secure fashion are clear.  Not obvious, right now, I agree.

My first thought is that, in some cases, the server may have to do something special based on being informed of device specifics by the client.

> > 5. Security Considerations
>
> This entire document is about security.

Hmm. Doesn't that generate general scoffing at the SAAG every now
and then? Some of the more interesting text I've seen in these
recently has been about d-o-s attacks, which tends not to fit
elsewhere.

Interesting.  I thought the above is what most PKIX documents have done for section 5.

In this context, d-o-s applies to the credential server requirements list, right?

Stephen.

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.               mailto:stephen.farrell@baltimore.ie
Ireland                            http://www.baltimore.com

From owner-ietf-sacred Wed Sep 27 10:15:20 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02104 for ietf-sacred-bks; Wed, 27 Sep 2000 10:15:20 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02100 for ; Wed, 27 Sep 2000 10:15:18 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA10297 for ; Wed, 27 Sep 2000 13:01:22 -0400 (EDT) Message-Id: <200009271701.NAA10254@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'Michael Leahy'" , ietf-sacred@imc.org Subject: RE: Audit trails with Credential Server Date: Wed, 27 Sep 2000 13:17:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is there any intent to allow remote access to audit information to manage thresholds, retrieve logs? Will this default to the most recent SNMP (or equivalent) standards as opposed to trying to re-create this work? regards, Sandi Miklos -----Original Message----- From: Michael Leahy [mailto:Michael.Leahy@cp.net] Sent: Tuesday, September 26, 2000 7:09 AM To: ietf-sacred@imc.org Subject: Re: Audit trails with Credential Server Hi Stephen true, it does not affect interoperability. So just defining a minimum set of attributes {or data blocks} that should be logged would suffice and any gotcha's that might be associated with these. Regards Michael ----- Original Message ----- From: Stephen Farrell To: Michael Leahy Cc: Sent: Tuesday, September 26, 2000 11:30 AM Subject: Re: Audit trails with Credential Server > > Michael, > > You're right that audit is important, however, I don't see > where any of this affects interoperability, at least not > with the data you suggest auditing. If that's true, then > it doesn't belong in our specs, except perhaps if we want > to give some guidance in an area where folks are otherwise > likely to go wrong. > > Stephen. > > > Michael Leahy wrote: > > > > Hi > > > > "You are only as secure as your last audit trail" - Someone once said this to me (can not remember > > who) and it always sticks in my mind. So any thoughts on what information {if any} SHOULD be > > logged by the credential server. I don't really want to go down the route of notaries but I do > > beleive that some minimum information should be kept. > > > > Here's a list that comes to mind > > 1. User login ID (in whatever form the user authenticates themselves) > > 2. Time that request was made > > 3. User ip address - Since we have not decided on TCP/IP as the transport mechanism then what we > > log here will obviously change. > > 4. I would also recommend logging the request syntax (user) and server response. This way whatever > > we decide on as the authentication mechanism we would get for free in the log > > > > Again I realize that what gets logged will be implementation dependent but it is in my opinion a > > necessary function - so I beleive me should define a minimum set. > > > > Any thoughts ? > > > > Regards > > Michael > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > Dublin 2. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** From owner-ietf-sacred Wed Sep 27 12:37:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA04878 for ietf-sacred-bks; Wed, 27 Sep 2000 12:37:12 -0700 (PDT) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04873 for ; Wed, 27 Sep 2000 12:37:10 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000927194034.OCSV10653.mail.rdc1.md.home.com@home.com>; Wed, 27 Sep 2000 12:40:34 -0700 Message-ID: <39D24D8E.6147F94D@home.com> Date: Wed, 27 Sep 2000 15:42:06 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miklos, Sue A." CC: "'Michael Leahy'" , ietf-sacred@imc.org Subject: Re: Audit trails with Credential Server References: <200009271701.NAA10254@roadblock.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Sandi, I for one would argue strongly that SACRED (assuming that we do at some point actually become an official working group :-) should not re-invent any wheels, particularly with respect to remote management of system functions. I'm not sure whether "audit of transactions between client and server" properly belongs in our charter or not - I'm inclined against it at this point, except for maybe a discussion in "Security Considerations" about the need to actually do things like record important parameters of transactions and then actually look at and do something about those logs. Al Arsenault "Miklos, Sue A." wrote: > > Is there any intent to allow remote access to audit information to manage > thresholds, retrieve logs? Will this default to the most recent SNMP (or > equivalent) standards as opposed to trying to re-create this work? > > regards, > Sandi Miklos > > -----Original Message----- > From: Michael Leahy [mailto:Michael.Leahy@cp.net] > Sent: Tuesday, September 26, 2000 7:09 AM > To: ietf-sacred@imc.org > Subject: Re: Audit trails with Credential Server > > Hi Stephen > > true, it does not affect interoperability. So just defining a minimum set of > attributes {or data blocks} that should be logged would suffice and any > gotcha's that might be associated with these. > > Regards > Michael > ----- Original Message ----- > From: Stephen Farrell > To: Michael Leahy > Cc: > Sent: Tuesday, September 26, 2000 11:30 AM > Subject: Re: Audit trails with Credential Server > > > > > Michael, > > > > You're right that audit is important, however, I don't see > > where any of this affects interoperability, at least not > > with the data you suggest auditing. If that's true, then > > it doesn't belong in our specs, except perhaps if we want > > to give some guidance in an area where folks are otherwise > > likely to go wrong. > > > > Stephen. > > > > > Michael Leahy wrote: > > > > > > Hi > > > > > > "You are only as secure as your last audit trail" - Someone once said > this to me (can not remember > > > who) and it always sticks in my mind. So any thoughts on what > information {if any} SHOULD be > > > logged by the credential server. I don't really want to go down the > route of notaries but I do > > > beleive that some minimum information should be kept. > > > > > > Here's a list that comes to mind > > > 1. User login ID (in whatever form the user authenticates themselves) > > > 2. Time that request was made > > > 3. User ip address - Since we have not decided on TCP/IP as the > transport mechanism then what we > > > log here will obviously change. > > > 4. I would also recommend logging the request syntax (user) and server > response. This way whatever > > > we decide on as the authentication mechanism we would get for free in > the log > > > > > > Again I realize that what gets logged will be implementation dependent > but it is in my opinion a > > > necessary function - so I beleive me should define a minimum set. > > > > > > Any thoughts ? > > > > > > Regards > > > Michael > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 647 7406 > > 61 Fitzwilliam Lane, fax: +353 1 647 7499 > > Dublin 2. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com > > **************************************************************************** > * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > **************************************************************************** > ** From owner-ietf-sacred Thu Sep 28 11:21:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA23177 for ietf-sacred-bks; Thu, 28 Sep 2000 11:21:16 -0700 (PDT) Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23172 for ; Thu, 28 Sep 2000 11:21:14 -0700 (PDT) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 14:26:06 -0400 Message-ID: <3120721CA75DD411B8340090273D20B1295F0E@sottmxs06.entrust.com> From: Mike Just To: "'stephen.farrell@baltimore.ie'" , David Jablon Cc: ietf-sacred Subject: RE: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] Date: Thu, 28 Sep 2000 14:17:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some suggested definitions below... > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: Tuesday, September 26, 2000 5:17 PM > To: David Jablon > Cc: ietf-sacred > Subject: Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)] > <...snip...> > Does anyone know of an existing classification of various attacks > against password based authentication schemes that we might be > able to re-use here? (Or feel like creating one?) > How about these for a start? 1. Encrypting for the "wrong server". The attacker impersonates the server to the user, so that the user unknowingly sends their password to the attacker, as opposed to the server that they had intended to send their password to. << I think that this is an important one to try to protect against.>> 2. Online password guessing. In an online password guessing attack, an attacker attempts to impersonate the user to a server by attempting to guess the legitimate user's password. 3. Offline password guessing. In an offline password guessing attack, an attacker has obtained an "image" of a user's password, and attempts to exhaust potential passwords in an effort to reproduce the image. When they have found a password that reproduces the image, then they are able to successfully impersonate the user. There's also "shoulder surfing" and "social engineering" attacks, though I don't think that the protocol will be able to prevent these (whereas user education might). I hadn't thought of David's distinction for "network-based offline" before this. Mike J. From owner-ietf-sacred Fri Sep 29 03:39:06 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA18596 for ietf-sacred-bks; Fri, 29 Sep 2000 03:39:06 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18592 for ; Fri, 29 Sep 2000 03:39:00 -0700 (PDT) Received: by balinese.baltimore.ie; id LAA13927; Fri, 29 Sep 2000 11:42:29 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma013879; Fri, 29 Sep 00 11:41:44 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA11029 for ; Fri, 29 Sep 2000 11:41:45 +0100 Message-ID: <39D4728A.D02F8BDD@baltimore.ie> Date: Fri, 29 Sep 2000 11:44:26 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: FYI: reqs draft in I-Ds directory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The requirements draft is now available from: ftp://ftp.ietf.org/internet-drafts/draft-arsenault-sacred-reqs-00.txt Cheers, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Oct 10 20:08:52 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA22258 for ietf-sacred-bks; Tue, 10 Oct 2000 20:08:52 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22252 for ; Tue, 10 Oct 2000 20:08:50 -0700 (PDT) Received: from clonvick-nt2.cisco.com (clonvick-isdn.cisco.com [171.70.238.6]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA07881 for ; Tue, 10 Oct 2000 20:12:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20001006123051.00dd0390@sj-email.cisco.com> X-Sender: clonvick@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Oct 2000 22:12:47 -0500 To: ietf-sacred@imc.org From: "Chris M. Lonvick" Subject: Some Thoughts on draft-arsenault-sacred-reqs-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I've been having some thoughts about credentials from a different angle. I'd like to express them here for some discussion. In section 1.1, and in the proposed charter, the examples deal with the mobility of credentials as they relate to people. I'd like to suggest that there are credentials that are exclusively associated with devices that still require some amount of mobility. I have started calling the credentials of a device its' "identity". For example, a Unix device may be running sshd in which case it has a public RSA key that it can present. All ssh sessions initiated to that server should expect to see the same credential and will then know that it is the same Unix device. Let's say, however, that the poor Unix box is struck by lightning before a backup could be made of the keys. When the device is replaced, a new key-pair will have to be generated and all ssh clients attempting sessions to the "new" device will have to be informed that the "identity" of the device has changed. It would have been far better if the key-pair had been backed-up. In that case, when the new device is installed, the credentials could be placed in it so that it could assume the identity of the wrecked device. Then, other devices attempting ssh sessions to it would recognize it as if it had never been replaced. This is a case of archiving the identity of a device so that it may be resurrected in the case of a catastrophic failure. Another case for the mobility of credentials is for the duplication of an identity. Let's say that I set up an e-commerce site with one web server that becomes wildly successful. I may choose to place more servers behind a load-balancer. In that case, it would be nice to have the same X.509 certificate on each of those servers for SSL. I would like to be able to securely transfer the certificate from some device to each of the web servers. In both of these cases the identity of a device may be easily moved from one device to another. I can do the same for the identity of my laptop; I have copied my PGP keyring from my old machine to my new machine. However, this ease is only available at a small scale. Consider that each router and switch in a large network may have an X.509 certificate that it uses for IPsec. The same could be said for each "server" type of machine in an administrative domain. The network administrators would not like to provision each of those individually. Also, in the case of my PGP keyring, I transferred it via a floppy. The idea of dynamically transferring a keypair to each router claiming to require it (similar to downloading an image or configuration via tftp) does not appeal to me. ;-) I don't think that is a problem that needs to be addressed by this group, and it may very well be unsolvable. On the other hand, in the case that a router is taken out of service, I would like for the operators to be able to download the correct key-pair to that router in a secure method. In some cases, that may be preferable to revoking the certificate of the removed device. I don't think that the network operators really want to physically touch each router for that transfer of its "identity". I think that the bottom-line to all of this is, if no one vehemently disagrees, that the examples in the draft become slightly less "user" focused and that the group keeps in mind that credentials are not always coupled with a person. I don't think that this diverges from the intent of the charter or of the draft. Comments welcome. Thanks, Chris From owner-ietf-sacred Wed Oct 11 03:38:41 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA05289 for ietf-sacred-bks; Wed, 11 Oct 2000 03:38:41 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05281 for ; Wed, 11 Oct 2000 03:38:39 -0700 (PDT) Received: by balinese.baltimore.ie; id LAA26839; Wed, 11 Oct 2000 11:43:11 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma026702; Wed, 11 Oct 00 11:42:48 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA10086; Wed, 11 Oct 2000 11:43:51 +0100 Message-ID: <39E4442A.2AA0062A@baltimore.ie> Date: Wed, 11 Oct 2000 11:42:50 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chris M. Lonvick" CC: ietf-sacred@imc.org Subject: Re: Some Thoughts on draft-arsenault-sacred-reqs-00.txt References: <4.3.2.7.2.20001006123051.00dd0390@sj-email.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Chris, I wouldn't have a problem with catering for devices in addition to people, but would note that the charter does specifically talk about end users and doesn't specfically mention devices, so I think if there were ever to be a conflict the people beat the machines! (Comforting, eh:-) Having said that, I'm not sure there's that much conflict, but have the following questions: - Can you describe a scenario in which there's no user involvement at all whilst the sacred protocol is being used and adds value? I guess there would be some security concerns - if the device can't store the credential securely through say, a boot cycle, then how can it securely store the authentication information needed to get the credential back? Also some applicability issues - since devices don't have a problem with long passwords, where's the need for sacred? (I.e. why not just have the device encrypt the credential in a proprietary format outside and reload as needed?) I'm not saying there aren't good answers, but a scenario that clearly demonstrated the benefits of sacred while answering the above would be useful. - Where do you draw the line between private key backup as provided by all decent crypto hardware, (e.g. typically onto smartcards or tokens) and use of sacred? - Other than the examples, does this impact on the requirements posited in the draft? If so, how? Regards, Stephen. "Chris M. Lonvick" wrote: > > Hi, > > I've been having some thoughts about credentials from a different > angle. I'd like to express them here for some discussion. > > In section 1.1, and in the proposed charter, the examples deal with the > mobility of credentials as they relate to people. I'd like to suggest > that there are credentials that are exclusively associated with devices > that still require some amount of mobility. I have started calling the > credentials of a device its' "identity". For example, a Unix device may > be running sshd in which case it has a public RSA key that it can > present. All ssh sessions initiated to that server should expect to see > the same credential and will then know that it is the same Unix device. > Let's say, however, that the poor Unix box is struck by lightning before > a backup could be made of the keys. When the device is replaced, a new > key-pair will have to be generated and all ssh clients attempting > sessions to the "new" device will have to be informed that the "identity" > of the device has changed. It would have been far better if the key-pair > had been backed-up. In that case, when the new device is installed, the > credentials could be placed in it so that it could assume the identity of > the wrecked device. Then, other devices attempting ssh sessions to it > would recognize it as if it had never been replaced. This is a case of > archiving the identity of a device so that it may be resurrected in the > case of a catastrophic failure. > > Another case for the mobility of credentials is for the duplication of an > identity. Let's say that I set up an e-commerce site with one web server > that becomes wildly successful. I may choose to place more servers behind > a load-balancer. In that case, it would be nice to have the same X.509 > certificate on each of those servers for SSL. I would like to be able to > securely transfer the certificate from some device to each of the web > servers. > > In both of these cases the identity of a device may be easily moved from > one device to another. I can do the same for the identity of my laptop; I > have copied my PGP keyring from my old machine to my new machine. However, > this ease is only available at a small scale. Consider that each router > and switch in a large network may have an X.509 certificate that it uses > for IPsec. The same could be said for each "server" type of machine in an > administrative domain. The network administrators would not like to > provision each of those individually. Also, in the case of my PGP keyring, > I transferred it via a floppy. > > The idea of dynamically transferring a keypair to each router claiming to > require it (similar to downloading an image or configuration via tftp) > does not appeal to me. ;-) I don't think that is a problem that needs to > be addressed by this group, and it may very well be unsolvable. On the > other hand, in the case that a router is taken out of service, I would > like for the operators to be able to download the correct key-pair to that > router in a secure method. In some cases, that may be preferable to > revoking the certificate of the removed device. I don't think that the > network operators really want to physically touch each router for that > transfer of its "identity". > > I think that the bottom-line to all of this is, if no one vehemently > disagrees, that the examples in the draft become slightly less "user" > focused and that the group keeps in mind that credentials are not always > coupled with a person. I don't think that this diverges from the intent > of the charter or of the draft. > > Comments welcome. > > Thanks, > Chris -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Wed Oct 11 07:36:57 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA15810 for ietf-sacred-bks; Wed, 11 Oct 2000 07:36:57 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15806 for ; Wed, 11 Oct 2000 07:36:56 -0700 (PDT) Received: from clonvick-nt2.cisco.com (dhcp-aus-162-157.cisco.com [171.69.162.157]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA10514; Wed, 11 Oct 2000 07:40:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20001011062849.00e7c440@sj-email.cisco.com> X-Sender: clonvick@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Oct 2000 09:41:03 -0500 To: stephen.farrell@baltimore.ie From: "Chris M. Lonvick" Subject: Re: Some Thoughts on draft-arsenault-sacred-reqs-00.txt Cc: ietf-sacred@imc.org In-Reply-To: <39E4442A.2AA0062A@baltimore.ie> References: <4.3.2.7.2.20001006123051.00dd0390@sj-email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Stephen, At 11:42 AM 10/11/00 +0100, Stephen Farrell wrote: >Hi Chris, > >I wouldn't have a problem with catering for devices in addition to >people, but would note that the charter does specifically talk >about end users and doesn't specfically mention devices, so I >think if there were ever to be a conflict the people beat the >machines! (Comforting, eh:-) Maybe I'm just odd as well, but I like having a greater priority than a machine. :-) >Having said that, I'm not sure there's that much conflict, but >have the following questions: > >- Can you describe a scenario in which there's no user involvement >at all whilst the sacred protocol is being used and adds value? That scenario would be unrealistic as I agree that there needs to be some level of user involvement. As I said before, that situation may be an unsolvable problem. On the other hand, here is a scenario that I think is realistic and demonstrates an acceptable use of sacred. It does require the intervention of a person acting in the role of the owner. Once upon a time, a router generated a keypair. The administrators transferred the public key of that router to a lot of other (peer) routers and used that router to encrypt traffic to the other routers. ..and this was good for many years. Then one day, the network administrators found that this particular little router couldn't handle an OC-192. So they trashed it and replaced it with a really big router. While they were there, the craft workers inserted a smart card into the router and logged into the router. They give the appropriate commands and entered the correct answers and so the credentials (keypair) were transferred to the new, big router. Alternatively, the craft people could have logged into the router, given it a minimal configuration and transferred the credentials from the credential server to the router. They would have to perform the correct incantations and authentications for the transfer to be successful. In this way, the identity of the router was moved from an old router to a new one. The administrators were glad that they didn't have to edit the configurations of all of the peer routers as well. >I >guess there would be some security concerns - if the device can't >store the credential securely through say, a boot cycle, then how >can it securely store the authentication information needed to get >the credential back? I fully agree. There are major security concerns there which is why it may be unsolvable at this time. Let's agree to not go there. >Also some applicability issues - since devices >don't have a problem with long passwords, where's the need for >sacred? (I.e. why not just have the device encrypt the credential >in a proprietary format outside and reload as needed?) I think that it's along the lines of "Betamax v. VHS". If a good, open standard can be built, then I don't want to go down a proprietary path. At some future time when this group finishes its work, I'd like to be able to say, "Cisco routers and switches can securely transfer their credentials in the method described in RFC-xxxx." If the wording in that RFC clearly states that the credentials belong to a person (unique individual) and only that person can manipulate the credentials, then I won't be able to truthfully say that. If the wording is a bit looser, then we'll have a solution that fits more scenarios such as the one I describe above. >I'm not saying there aren't good answers, but a scenario that clearly >demonstrated the benefits of sacred while answering the above would be useful. Let me know if the scenario above fits the bill. >- Where do you draw the line between private key backup as provided >by all decent crypto hardware, (e.g. typically onto smartcards or >tokens) and use of sacred? ----------------------------------------- | | | | We currently | | | have no solution | sacred | | | | ----------------------------------------- ^ the line _______________| :-) We are capable of a proprietary solution but I don't think that is what we want to offer. Given the option, I would prefer to say, "If you want to transfer the credentials of a router to another router, then go get the same stuff that you would use to transfer your credentials from your laptop to your cell phone." >- Other than the examples, does this impact on the requirements >posited in the draft? If so, how? Not in any way that I can see. I need to do a more thorough review, but I can't see that there are any differences in the functionality of what you propose and what I would like. I honestly think that we're discussing a bit of interpretation about the definition of the ownership of the credentials. A strict interpretation would say that the credentials are totally associated with a unique individual. A looser interpretation would allow the association of the credentials to a device. In the case of an individual transferring the credentials, the individual would have to perform the tasks. In the case of the transfer of credentials of a device, the tasks would have to be performed by someone acting in the role of the owner - the operator or administrator. I think that the work of this group as it is chartered and outlined in the draft can be applied to devices and roles and not just to individuals and their credentials. I'd like for that to be part of the IDs. >Regards, >Stephen. Thanks, Chris >"Chris M. Lonvick" wrote: >> >> Hi, >> >> I've been having some thoughts about credentials from a different >> angle. I'd like to express them here for some discussion. ---remainder deleted for brevity--- From owner-ietf-sacred Wed Oct 11 07:47:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16531 for ietf-sacred-bks; Wed, 11 Oct 2000 07:47:41 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16523 for ; Wed, 11 Oct 2000 07:47:39 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA19219; Wed, 11 Oct 2000 15:52:12 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma019108; Wed, 11 Oct 00 15:52:03 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA19062; Wed, 11 Oct 2000 15:53:07 +0100 Message-ID: <39E47E94.1E091542@baltimore.ie> Date: Wed, 11 Oct 2000 15:52:04 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chris M. Lonvick" CC: ietf-sacred Subject: Re: Some Thoughts on draft-arsenault-sacred-reqs-00.txt References: <4.3.2.7.2.20001006123051.00dd0390@sj-email.cisco.com> <4.3.2.7.2.20001011062849.00e7c440@sj-email.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Chris, Good, we seem to be on the same page. I think it'd be good to add your scenario to the next rev of the requirements draft. > >- Where do you draw the line between private key backup as provided > >by all decent crypto hardware, (e.g. typically onto smartcards or > >tokens) and use of sacred? > > ----------------------------------------- > | | | > | We currently | | > | have no solution | sacred | > | | | > ----------------------------------------- > ^ > the line _______________| > > :-) I like that! (And will not hesitate to steal it for many, many ppts :-) Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Oct 16 12:33:51 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA23236 for ietf-sacred-bks; Mon, 16 Oct 2000 12:33:51 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23231 for ; Mon, 16 Oct 2000 12:33:49 -0700 (PDT) Received: by balinese.baltimore.ie; id UAA14647; Mon, 16 Oct 2000 20:38:48 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma014633; Mon, 16 Oct 00 20:38:12 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.ie.baltimore.com (8.9.3/8.9.3) with ESMTP id UAA01529; Mon, 16 Oct 2000 20:38:12 +0100 Message-ID: <39EB5A01.FD5206CE@baltimore.ie> Date: Mon, 16 Oct 2000 20:41:53 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred CC: Magnus =?iso-8859-1?Q?Nystr=F6m?= , xme Subject: framework draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All, We should be set as a WG pretty soon now, (later this week all going to plan), so I guess we should try to meet the dates in the charter:-) The I-D cutoff date for San Diego is also only a month away (17th Nov.) so now's the time to get started on the framework draft (or proposals for the framework). To that end, could folks who'd like to volunteer for editing duties please contact Magnus and I and let us know. If you write up your ideas first, that's *much* better. Goes without saying of course, that if you've running code, that's *much, much* better (well, I said it anyway:-). FWIW what I think the draft should contain is a fairly abstract model of the messages exchanged in a sacred protocol with (again abstract) details of what those messages contain. Interworking diagrams and message definitions, that sort of thing. A state machine would be no harm either. I reckon it should cover both the direct and credential server approaches. I don't think the framework should choose a transport - it should be open to different transports (e.g. HTTP, SMTP, etc.); nor should it determine any particular authentication mechanisms or credential formats, unless that's unavoidable. Of course it should address the requirements, including as much of what was discussed on the list as you can rememeber. (Meanwhile, Al and I will try to get another round of the requirements draft out, reflecting the list discussion to date.) In particular, there was some discussion about self-enrollment and management stuff that should be covered in the framework. In terms of how to write it up: maybe XML might be a useful way to represent PDUs, or ASN.1, or ABNF, or whatever you like, the point is that the framework should be suitable for different implementations: i.e. XML in the framework draft says nothing about what'll end up in the final protocol draft(s). Same goes for ASN.1 or ABNF or anything else. NB: I do *not* want to have a generic discussion on the list about whether any of these are better or worse than the others, we've all done that enough times to know its not useful. (If you particularly like one of 'em, then write a proposal for the framework draft using it - *please* don't tell us about how it'd be great if... :-) So...any volunteers for the above? Regards, Stephen. PS: I've asked for 2 hour slot for San Diego, anyone who wants to suggest an agenda item, please let Magnus and I know including an indication as to how long it might take. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Oct 24 14:04:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14596 for ietf-sacred-bks; Tue, 24 Oct 2000 14:04:24 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14592 for ; Tue, 24 Oct 2000 14:04:21 -0700 (PDT) Received: by balinese.baltimore.ie; id WAA29776; Tue, 24 Oct 2000 22:10:01 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma029772; Tue, 24 Oct 00 22:09:28 +0100 Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA08640 for ; Tue, 24 Oct 2000 22:09:26 +0100 Message-ID: <39F5FB69.C2A85AB2@baltimore.ie> Date: Tue, 24 Oct 2000 22:13:13 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: we're official... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All, We're now an official WG. Charter page is at: http://www.ietf.org/html.charters/sacred-charter.html Stephen. BTW: Still calling for volunteers for the framework draft! Go on - don't be shy! -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Fri Oct 27 07:20:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01332 for ietf-sacred-bks; Fri, 27 Oct 2000 07:20:00 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01328 for ; Fri, 27 Oct 2000 07:19:58 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA25065; Fri, 27 Oct 2000 15:25:50 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma024847; Fri, 27 Oct 00 15:24:56 +0100 Received: from baltimore.ie (ip203-221.ie.baltimore.com [192.168.21.203]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA02576 for ; Fri, 27 Oct 2000 15:24:56 +0100 Message-ID: <39F9911E.E786BB1E@baltimore.ie> Date: Fri, 27 Oct 2000 15:28:46 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: enrollment/mgt operations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All, I'm looking through the comments we got on the requirements and would like to get some opinions about how much detail to include (in the requirments document) about management operations. Right now, there's just a generic requirement that the protocols must support mgt operations. Self-enrollment was mentioned on the list and should at least get a mention too. I guess the overall list of operations might be something like: GET for downloads from a CS PUT to update/change a credential or direct transfer one ENROLL could be a special case of PUT? DELETE to zap a credential (carefully:-) So, questions: - Should the requirements document specify these separately, each with associated MUSTs etc? - If yes, then what other management operations might there be? (e.g. do we need an interoperable form of DISABLE/ENABLE to temporarily make credentials unavailable, MODIFY to change an existing credential...) - Does all this just apply to the credential server case, or also for direct transfers? Regards, Stephen. BTW: Dale and Magnus have taken on drafting a framework document (thanks guys:-) so we should have one to discuss in San Diego if they manage to make the cutoff. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Sun Oct 29 13:58:02 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA01748 for ietf-sacred-bks; Sun, 29 Oct 2000 13:58:02 -0800 (PST) Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01744 for ; Sun, 29 Oct 2000 13:57:59 -0800 (PST) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA18856; Mon, 30 Oct 2000 09:10:29 +1100 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 10:02:37 +1100 Message-ID: From: Carlos Sotomayor To: stephen.farrell@baltimore.ie, ietf-sacred Subject: RE: enrollment/mgt operations Date: Mon, 30 Oct 2000 10:02:27 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think there should be some clarification of the management issues. Some queries I have are ... Are there plans to provide delegated credential access. An example could be that a manager could be given access to the team members credentials or a secretary could read and decrypt mail for the person they work for. Also there should be the ability to make an entity a retrieval authority such as a system admin or high ranking company employee. Also what about scenarios of revoking access to credentials for an entity but still allow the credential to be retrieved by another entity or authority. This could happen in a company when an employee leaves the company but their correspondence still needs to be accessible by an existing member of the company. Registering a new entity onto the system may warrant its own function. Many things could be configured at this point such as authentication method for that entity and also it provides a point at which an admin person can actually reject or allow an entity access to the system. There might be other situations where there already exists a compant entity registration database which is to be reused so the user registration will not neccessarily happen on the first credential upload. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Saturday, 28 October 2000 0:29 To: ietf-sacred Subject: enrollment/mgt operations Hi All, I'm looking through the comments we got on the requirements and would like to get some opinions about how much detail to include (in the requirments document) about management operations. Right now, there's just a generic requirement that the protocols must support mgt operations. Self-enrollment was mentioned on the list and should at least get a mention too. I guess the overall list of operations might be something like: GET for downloads from a CS PUT to update/change a credential or direct transfer one ENROLL could be a special case of PUT? DELETE to zap a credential (carefully:-) So, questions: - Should the requirements document specify these separately, each with associated MUSTs etc? - If yes, then what other management operations might there be? (e.g. do we need an interoperable form of DISABLE/ENABLE to temporarily make credentials unavailable, MODIFY to change an existing credential...) - Does all this just apply to the credential server case, or also for direct transfers? Regards, Stephen. BTW: Dale and Magnus have taken on drafting a framework document (thanks guys:-) so we should have one to discuss in San Diego if they manage to make the cutoff. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Oct 30 04:41:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA27542 for ietf-sacred-bks; Mon, 30 Oct 2000 04:41:15 -0800 (PST) Received: from msw.mimesweeper.com (mail.mimesweeper.com [194.168.91.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27537 for ; Mon, 30 Oct 2000 04:41:13 -0800 (PST) Received: from mswctl1.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 30 Oct 2000 12:47:29 +0000 Received: from BELL.mimesweeper.com (unverified) by mswctl2.mimesweeper.com (Content Technologies SMTPRS 4.2.0) with ESMTP id for ; Mon, 30 Oct 2000 12:46:47 +0000 Received: from GK-VAIO.Dial.pipex.com (gk-vaio.mimesweeper.com [194.168.90.137]) by BELL.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VVV0NYPM; Mon, 30 Oct 2000 12:44:59 -0000 Message-Id: <4.3.2.7.2.20001006120727.00ab0ee0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Oct 2000 12:46:19 +0100 To: ietf-sacred From: Graham Klyne Subject: Comments on draft-arsenault-sacred-reqs-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, I offer the following observations for your consideration. They consist mostly of presentational nits. General: I noticed a few instances of a non-ASCII character being used where (I assume) an apostrophe (') was intended. E.g. "Mimi?s" in section 2.1. Abstract: I think it would be helpful for the first paragraph to mention mobility of credentials in some way. E.g. This document describes requirements to be placed on Securely Available Credentials (sacred) mobility protocols. Section 1, final para: I have found that the RFC2119 keywords, designed as they are for describing protocols, don't always work well when describing _requirements_ on protocols. For example, I'm not sure exactly what is meant by requirements G9, S4: are these saying the "protocol specification MAY define...", or that the protocol must be specified in a way such that "protocol implementations MAY..."? An alternative approach to describing protocol requirements levels can be found in RFC 2542, section 1.1. Section 1.1, 2nd para: When reading this, it occurred to me that having Mimi keep credentials on her computer was also not really very secure. I'm not sure if it's worth saying anything about this -- maybe properly managed mobile credentials would be _more_ secure. Or, to put it another way, is it possible that the sacred framework would help to protect credentials on a single system (regarding the transfer between long-term storage and immediate use as a kind of movement of credentials)? Section 1.2: How does the secure transfer of credentials between devices differ from the secure transfer of *any* sensitive information? (A clear answer to that question might help to convey the essence of this effort.) Section 2: Starting to read this, it seems to consist of background material as much as requirements. I would suggest that the pedagogical background material (which I think is very useful) be separated from the specific requirements. Section 2.1, page 5, final para (bullet 2): You say the credential server "may" have to be trusted... Is this strong enough? Otherwise, why not use any old web server? Section 2.1, page 6, 1st 2 paras: I found the first paragraph confusing, and the second paragraph to be rather laboured (though it did clear up my confusion). In general, I think the idea of a "direct" transfer as described is already implicit in the way Internet applications and protocols work. Thus, I think the two paragraphs could be replaced by: Thus, some users may prefer a different class of solution, in which credentials are transferred directly from one device to another (i.e. having no intermediary element that processes or has any understanding of the credentials). Section 2.2, requirement F3: I think the "which" here should be "that". Section 2.4, editorial comment: IMXP might be a candidate, suitable to a range of operating environments. Section 3.1, requirement G3: Is SHOULD strong enough? I'd have thought this is a MUST. Section 3.1, requirement G6: is this "MUST support the use of ..." or "MUST support the transfer of ..." Section 3.1, requirement G9: Section 3.2, requirement S4: I'm not sure what MAY means in these contexts (see earlier comment) Section 3.1, requirement G10: There's more to full I18N than charset use. Also language tagging for human readable text. Section 3.1, requirement G12: Privacy from whom? For example, it seems to me the client must be identified to somebody if credentials are transferred only to properly authorized recipients. Section 4, item "Vulnerabilities:" Should the framework specification not include some kind of trust model? -- That's all. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-sacred Wed Nov 1 00:57:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA20925 for ietf-sacred-bks; Wed, 1 Nov 2000 00:57:44 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA20921 for ; Wed, 1 Nov 2000 00:57:42 -0800 (PST) Received: (qmail 61354 invoked from network); 1 Nov 2000 09:04:00 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 1 Nov 2000 09:04:00 -0000 Received: (qmail 27324 invoked by uid 1183); 1 Nov 2000 09:04:20 -0000 Date: Wed, 1 Nov 2000 10:04:20 +0100 (MET) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sacred@imc.org Subject: Agenda for San Diego Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear All, A suggested agenda for "sacred." Comments, suggestions, and proposals are welcome and solicited. Thanks, -- Magnus Magnus Nystrom RSA Security Sacred meeting agenda. Thursday Dec 14th, 1 - 3 pm -------------------------------------------------- 1. Introduction, Agenda walkthrough (5 min) WG Chairs 2. Working Group Status (5 min) WG Chairs 3. Requirements Draft discussion (35min) A.Arsenault 4. Framework Draft discussion (35min) D.Gustafsson 5. Protocol and credential formats - proposals and discussion (35min) Contributors 6. Wrap up (5 min) WG Chairs From owner-ietf-sacred Thu Nov 2 07:02:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15781 for ietf-sacred-bks; Thu, 2 Nov 2000 07:02:34 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15777 for ; Thu, 2 Nov 2000 07:02:32 -0800 (PST) Received: from clonvick-nt2.cisco.com (clonvick-isdn.cisco.com [171.70.238.6]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA06528; Thu, 2 Nov 2000 07:08:24 -0800 (PST) Message-Id: <4.3.2.7.2.20001102083240.00d0be70@sj-email.cisco.com> X-Sender: clonvick@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 09:08:23 -0600 To: stephen.farrell@baltimore.ie, ietf-sacred From: "Chris M. Lonvick" Subject: Re: enrollment/mgt operations In-Reply-To: <39F9911E.E786BB1E@baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steven and Everyone, At 03:28 PM 10/27/00 +0100, Stephen Farrell wrote: >Hi All, > >I guess the overall list of operations might be something >like: > >GET for downloads from a CS >PUT to update/change a credential or direct transfer one >ENROLL could be a special case of PUT? >DELETE to zap a credential (carefully:-) Would it make sense to add COMPARE to compare the stored credential to the credential on the CS or another device For explanation, let's take the case that I am upgrading my Hand95 to a HandMM and I just transfered everything over from one to the other. This _should_ mean that my credentials were also moved over. ...umm... or were they? That ol' Hand95 was getting a bit long in the tooth. I think that it would be nice to just link my new HandMM to the network and ask it to COMPARE the stored credentials against those that are held on the CS. I figure that this will probably be a lot better than destroying the old credential and doing a GET. This may be as simple as sending in a fingerprint and getting a [yes|no] response from the CS. Along the same line, perhaps I take my phone into the shop for repair. They hand it back to me and everything 'looks' OK, but it just 'feels' different. I'd again like to just COMPARE my credentials to ensure that no one maliciously or accidentally tampered with them. >So, questions: > >- Does all this just apply to the credential server case, or > also for direct transfers? I'd suggest both. For any set of circumstances of which I can see, one device would be acting as a 'client' and the other as a 'server'. This is evident in the case of a device and the CS. For a direct transfer, I can't think that they would be acting as peers or anything other than one being a 'client' and the other being its 'server' for the moment. Those roles may reverse the next moment. Does it make sense to mandate that the initiator always play the role of 'client' in all cases? Thanks, Chris From owner-ietf-sacred Thu Nov 2 08:19:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23799 for ietf-sacred-bks; Thu, 2 Nov 2000 08:19:56 -0800 (PST) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23790 for ; Thu, 2 Nov 2000 08:19:54 -0800 (PST) Received: by balinese.baltimore.ie; id QAA23273; Thu, 2 Nov 2000 16:26:17 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma023184; Thu, 2 Nov 00 16:25:44 GMT Received: from baltimore.ie (wks131-4.ie.baltimore.com [10.153.4.131]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA28960; Thu, 2 Nov 2000 16:25:43 GMT Message-ID: <3A019685.847ABF4E@baltimore.ie> Date: Thu, 02 Nov 2000 16:29:57 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chris M. Lonvick" CC: ietf-sacred Subject: Re: enrollment/mgt operations References: <4.3.2.7.2.20001102083240.00d0be70@sj-email.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Chris, > Would it make sense to add > COMPARE to compare the stored credential to the credential > on the CS or another device > [...] I must admit I find this a bit of a stretch, does anyone else think we should add this now? I'd be for leaving it out for now, but keeping it on the list for discussion once we've a framework I-D in front of us. > >So, questions: > > > >- Does all this just apply to the credential server case, or > > also for direct transfers? > > I'd suggest both. For any set of circumstances of which I can > see, one device would be acting as a 'client' and the other as > a 'server'. This is evident in the case of a device and the CS. > For a direct transfer, I can't think that they would be acting > as peers or anything other than one being a 'client' and the other > being its 'server' for the moment. Those roles may reverse the > next moment. Does it make sense to mandate that the initiator > always play the role of 'client' in all cases? How about when there's e.g. a filesystem in between? Its probably different in the sense that there's no request/response, just an export (PUT?). Otherwise, I agree that any connection-oriented direct transfer might well be able to use a very similar protocol, at least at the level we've gotten to so far. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Tue Nov 7 02:57:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA14076 for ietf-sacred-bks; Tue, 7 Nov 2000 02:57:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14071 for ; Tue, 7 Nov 2000 02:57:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06271; Tue, 7 Nov 2000 06:04:37 -0500 (EST) Message-Id: <200011071104.GAA06271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sacred@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sacred-reqs-00.txt Date: Tue, 07 Nov 2000 06:04:37 -0500 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securely Available Credentials Working Group of the IETF. Title : Securely Available Credentials - Requirements Author(s) : A. Arsenault, S. Farrell Filename : draft-ietf-sacred-reqs-00.txt Pages : 14 Date : 06-Nov-00 This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This is the initial draft of the SACRED requirements specification and is therefore highly likely to change substantially. Discussion of this draft is taking place on the SACREDmailing list of the IETF SACRED working group (see http://www.imc.org/ietf-sacred for subscription information). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sacred-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sacred-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001106120305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sacred-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sacred-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106120305.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sacred Tue Nov 7 07:48:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10112 for ietf-sacred-bks; Tue, 7 Nov 2000 07:48:09 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10108 for ; Tue, 7 Nov 2000 07:48:07 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Nov 2000 15:52:59 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA18069 for ; Tue, 7 Nov 2000 10:51:01 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Nov 2000 10:54:56 -0500 Message-ID: From: "Linn, John" To: ietf-sacred@imc.org Subject: SACRED's vs. credentials' protection requirements [Was: RE: I-D A CTION:draft-ietf-sacred-reqs-00.txt] Date: Tue, 7 Nov 2000 10:54:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to ask a general question about scope. Credentials in their "native" formats, before presentation to a SACRED protocol for transport, may vary widely in terms of the levels of protection they incorporate. Some may be plaintext, others may be protected with secrets having password-level entropy, and others may be protected with strong cryptographic keys. It seems clear, e.g., that the level of confidentiality protection functionally required within a SACRED protocol is stronger for credentials provided to SACRED as plaintext than for credentials which are already strongly-encrypted. Should we specify that the level of protection required to be active within SACRED may vary depending on the characteristics of credentials being input to SACRED? Under 3.1, it's probably hard to come up with an accurate and exhaustive set of vulnerabilities; one which seems to be missing is the case of masquerading as a credential server in order to directly obtain a password which can then be presented by the attacker to the user's legitimate credential server. (V2 concerns dictionary attack, but here there isn't even any dictionary involved.) --jl From owner-ietf-sacred Tue Nov 7 18:27:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA04598 for ietf-sacred-bks; Tue, 7 Nov 2000 18:27:13 -0800 (PST) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04594 for ; Tue, 7 Nov 2000 18:27:11 -0800 (PST) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001108023403.SVGJ10139.mail.rdc1.md.home.com@home.com>; Tue, 7 Nov 2000 18:34:03 -0800 Message-ID: <3A08BBF5.E048D7CC@home.com> Date: Tue, 07 Nov 2000 21:35:33 -0500 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: ietf-sacred@imc.org Subject: Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, Thanks for your excellent comments. I've put some responses in-line, prefaced by my initials. "Linn, John" wrote: > > I'd like to ask a general question about scope. Credentials in their > "native" formats, before presentation to a SACRED protocol for transport, > may vary widely in terms of the levels of protection they incorporate. Some > may be plaintext, others may be protected with secrets having password-level > entropy, and others may be protected with strong cryptographic keys. It > seems clear, e.g., that the level of confidentiality protection functionally > required within a SACRED protocol is stronger for credentials provided to > SACRED as plaintext than for credentials which are already > strongly-encrypted. Should we specify that the level of protection required > to be active within SACRED may vary depending on the characteristics of > credentials being input to SACRED? > AWA: Interesting point - I hadn't directly thought of this before (but then, the solutions I've seen all have the property of working with homogeneous levels of protection for the credentials with which they deal, so it hasn't been an issue). Yes, this should probably be addressed at some point, but I'm uncomfortable with the idea of specifying/mandating given security levels - e.g., "if credentials are plaintext, be this strong"; "if credentials are strongly protected, weakening down to this level is okay". Those levels are probably going to be dictated by the individual environments. So I think that the best we can do in the requirements document is identify that we have to support all the cases you mention, and that the protocols have to be able to provide varying levels of security, according to the other protection provided to the credentials and the environment. > Under 3.1, it's probably hard to come up with an accurate and exhaustive set > of vulnerabilities; one which seems to be missing is the case of > masquerading as a credential server in order to directly obtain a password > which can then be presented by the attacker to the user's legitimate > credential server. (V2 concerns dictionary attack, but here there isn't > even any dictionary involved.) > AWA: True. The question is, how long a list do we want? We sort of wanted some sort of list, to show some examples, but you're right, it's probably impossible to come up with an exhaustive list. We'd welcome other input on this topic - should we have such a vulnerability list; if so, how complete should we try to make it? (Assuming we keep the list, we'll certainly include the one John mentions above.) > --jl > > Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-sacred Thu Nov 9 07:35:23 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA13648 for ietf-sacred-bks; Thu, 9 Nov 2000 07:35:23 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA13638 for ; Thu, 9 Nov 2000 07:35:21 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Nov 2000 15:40:21 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA10770; Thu, 9 Nov 2000 10:42:20 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 10:42:20 -0500 Message-ID: From: "Linn, John" To: "'Al Arsenault'" Cc: ietf-sacred@imc.org Subject: RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt] Date: Thu, 9 Nov 2000 10:42:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Al wrote: > John, > > Thanks for your excellent comments. I've put some > responses in-line, > prefaced by my initials. Thanks for this response. Here are some follow-on comments, and a separate point. > > "Linn, John" wrote: > > > > I'd like to ask a general question about scope. > Credentials in their > > "native" formats, before presentation to a SACRED protocol > for transport, > > may vary widely in terms of the levels of protection they > incorporate. Some > > may be plaintext, others may be protected with secrets > having password-level > > entropy, and others may be protected with strong > cryptographic keys. It > > seems clear, e.g., that the level of confidentiality > protection functionally > > required within a SACRED protocol is stronger for > credentials provided to > > SACRED as plaintext than for credentials which are already > > strongly-encrypted. Should we specify that the level of > protection required > > to be active within SACRED may vary depending on the > characteristics of > > credentials being input to SACRED? > > > > AWA: Interesting point - I hadn't directly thought of this before (but > then, the solutions I've seen all have the property of working with > homogeneous levels of protection for the credentials with which they > deal, so it hasn't been an issue). Yes, this should probably be > addressed at some point, but I'm uncomfortable with the idea of > specifying/mandating given security levels - e.g., "if credentials are > plaintext, be this strong"; "if credentials are strongly protected, > weakening down to this level is okay". Those levels are > probably going > to be dictated by the individual environments. So I think > that the best > we can do in the requirements document is identify that we have to > support all the cases you mention, and that the protocols have to be > able to provide varying levels of security, according to the other > protection provided to the credentials and the environment. This seems reasonable in principle, but should temper later discussions about how any MUST-implement protection requirement should be framed for purposes of conformant interoperability. Given an environment where credentials are themselves strongly protected, it could be a strong deterrent to SACRED adoption if the price of admission were deployment of additional infrastructure to support an additional layer of key management which wasn't strictly necessary from a security perspective. More generally, I think it's important to recognize that protection facilities enabling secure transfer of credentials can be provided in many layers, particularly the following: (1) in the underlying credential format (2) within a credential transfer protocol like SACRED (3) in another protocol (e.g., TLS) within which the credential transfer protocol might be encapsulated If we focus tightly or exclusively within the SACRED protocol, which seems an understandably likely result for a WG that's organizationally chartered to specify that protocol, there's a risk that we'll mandate facilities which are (sometimes or often) functionally redundant relative to those available in the other layers. These incur costs, which may be particularly difficult to satisfy under some of the initialization scenarios for which SACRED could be most useful; while individual users will probably invoke SACRED only on fairly infrequent occasions, those occasions are important ones and may operate under some tight constraints. I urge, therefore, that the protection facilities provided within SACRED be modular so as to be effectively tailorable to correspond to the surrounding layers and operational environment. > > > Under 3.1, it's probably hard to come up with an accurate > and exhaustive set > > of vulnerabilities; one which seems to be missing is the case of > > masquerading as a credential server in order to directly > obtain a password > > which can then be presented by the attacker to the user's legitimate > > credential server. (V2 concerns dictionary attack, but > here there isn't > > even any dictionary involved.) > > > > AWA: True. The question is, how long a list do we want? We sort of > wanted some sort of list, to show some examples, but you're > right, it's > probably impossible to come up with an exhaustive list. We'd welcome > other input on this topic - should we have such a > vulnerability list; if > so, how complete should we try to make it? (Assuming we keep > the list, > we'll certainly include the one John mentions above.) I'm OK with a list of example vulnerabilities, caveated as non-exhaustive, and think that this is useful and informative material to present. Rather than considering them as a separate and different type of requirements, though, I'd suggest that their implied countermeasures be distilled into corresponding functional requirements within the existing protocol requirements sections. A separate point: shortly before the end of Sec. 2.1, it's stated that: "Solutions involving the direct transfer of credentials from one device to another are potentially somewhat more complex than the credential-server approach, owing to the large number of different devices and formats that may have to be supported. Complexity is also added due to the fact that each device may in turn have to exhibit the behavior of both a client and a server." I don't think that the presence or absence of a server influences the number of client device types that may exist, or the variety of credential formats they may use. I'm assuming the underlying premise here that the use of a server may simplify individual clients by making it unnecessary for them to provide functions to support other client types, at the cost of complexity present in the server to be able to interact with each of those client types. If so, this might be a worthwhile clarification to include. --jl From owner-ietf-sacred Thu Nov 9 10:48:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA24771 for ietf-sacred-bks; Thu, 9 Nov 2000 10:48:22 -0800 (PST) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24767 for ; Thu, 9 Nov 2000 10:48:20 -0800 (PST) Received: by balinese.baltimore.ie; id SAA07492; Thu, 9 Nov 2000 18:55:17 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma007469; Thu, 9 Nov 00 18:55:01 GMT Received: from baltimore.ie (ip203-221.ie.baltimore.com [192.168.21.203]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA08159; Thu, 9 Nov 2000 18:55:01 GMT Message-ID: <3A0AF407.918A9297@baltimore.ie> Date: Thu, 09 Nov 2000 18:59:20 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: "'Al Arsenault'" , ietf-sacred@imc.org Subject: Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi John, [snip] > This seems reasonable in principle, but should temper later discussions > about how any MUST-implement protection requirement should be framed for > purposes of conformant interoperability. Given an environment where > credentials are themselves strongly protected, it could be a strong > deterrent to SACRED adoption if the price of admission were deployment of > additional infrastructure to support an additional layer of key management > which wasn't strictly necessary from a security perspective. [snip] You're right that there will be cases where using whatever ends up as the standards track SACRED protocol will require overhead that isn't actually useful in the context of a particularly "strong" credential format. However, I think that in order to get an interoperable protocol that allows one to meet the overall charter we'll probably have to mandate that overhead, since we certainly will have to pick some credential format, and I'd be very surprised if that format is likely to be safe to use without the additional overhead. Bit fuzzy I know, but I hope you get what I mean. > I'm OK with a list of example vulnerabilities, caveated as non-exhaustive, > and think that this is useful and informative material to present. Rather > than considering them as a separate and different type of requirements, > though, I'd suggest that their implied countermeasures be distilled into > corresponding functional requirements within the existing protocol > requirements sections. I'm not sure that that'd work very easily but am certainly willing to consider it. I guess the reason for listing vulnerabilities (and I agree that whatever list we end up with will be non-exhaustive) was that I think its easier to do this way for requirements (i.e. less danger of inadvertently including design in the requirements draft). Note also that the current draft doesn't say "protocols MUST prevent..." but rather that they "SHOULD offer protection" and MUST specify how they do, or don't, protect against the listed vulnerabilities. There wasn't an intent to declare a protocol as not meeting the requirements just because there's some vulnerability listed that the protocol doesn't absolutely prevent (as long as that's noted in the protocol specification). Maybe this needs to be clearer? > A separate point: shortly before the end of Sec. 2.1, it's stated that: > > "Solutions involving the direct transfer of credentials from one > device to another are potentially somewhat more complex than the > credential-server approach, owing to the large number of different > devices and formats that may have to be supported. Complexity is > also added due to the fact that each device may in turn have to > exhibit the behavior of both a client and a server." > > I don't think that the presence or absence of a server influences the number > of client device types that may exist, or the variety of credential formats > they may use. I'm assuming the underlying premise here that the use of a > server may simplify individual clients by making it unnecessary for them to > provide functions to support other client types, at the cost of complexity > present in the server to be able to interact with each of those client > types. If so, this might be a worthwhile clarification to include. Good point. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred Mon Nov 13 10:59:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA14049 for ietf-sacred-bks; Mon, 13 Nov 2000 10:59:15 -0800 (PST) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14043 for ; Mon, 13 Nov 2000 10:59:13 -0800 (PST) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA02635 for ; Mon, 13 Nov 2000 13:43:41 -0500 (EST) Message-Id: <200011131843.NAA02621@roadblock.missi.ncsc.mil> From: "Miklos A. Sue" To: "'Al Arsenault'" , "Linn, John" Cc: ietf-sacred@imc.org Subject: RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt] Date: Mon, 13 Nov 2000 14:06:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04DA4.DA44EF60" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04DA4.DA44EF60 Content-Type: text/plain; charset="iso-8859-1" May I suggest that some reference be made to the Common Vulnerabilities database www.cve.mitre.org as opposed to trying to list all the potential vulnerabilities? regards, Sandi -----Original Message----- From: Al Arsenault [mailto:awa1@home.com] Sent: Tuesday, November 07, 2000 9:36 PM To: Linn, John Cc: ietf-sacred@imc.org Subject: Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] John, Thanks for your excellent comments. I've put some responses in-line, prefaced by my initials. "Linn, John" wrote: > > I'd like to ask a general question about scope. Credentials in their > "native" formats, before presentation to a SACRED protocol for transport, > may vary widely in terms of the levels of protection they incorporate. Some > may be plaintext, others may be protected with secrets having password-level > entropy, and others may be protected with strong cryptographic keys. It > seems clear, e.g., that the level of confidentiality protection functionally > required within a SACRED protocol is stronger for credentials provided to > SACRED as plaintext than for credentials which are already > strongly-encrypted. Should we specify that the level of protection required > to be active within SACRED may vary depending on the characteristics of > credentials being input to SACRED? > AWA: Interesting point - I hadn't directly thought of this before (but then, the solutions I've seen all have the property of working with homogeneous levels of protection for the credentials with which they deal, so it hasn't been an issue). Yes, this should probably be addressed at some point, but I'm uncomfortable with the idea of specifying/mandating given security levels - e.g., "if credentials are plaintext, be this strong"; "if credentials are strongly protected, weakening down to this level is okay". Those levels are probably going to be dictated by the individual environments. So I think that the best we can do in the requirements document is identify that we have to support all the cases you mention, and that the protocols have to be able to provide varying levels of security, according to the other protection provided to the credentials and the environment. > Under 3.1, it's probably hard to come up with an accurate and exhaustive set > of vulnerabilities; one which seems to be missing is the case of > masquerading as a credential server in order to directly obtain a password > which can then be presented by the attacker to the user's legitimate > credential server. (V2 concerns dictionary attack, but here there isn't > even any dictionary involved.) > AWA: True. The question is, how long a list do we want? We sort of wanted some sort of list, to show some examples, but you're right, it's probably impossible to come up with an exhaustive list. We'd welcome other input on this topic - should we have such a vulnerability list; if so, how complete should we try to make it? (Assuming we keep the list, we'll certainly include the one John mentions above.) > --jl > > Al Arsenault Chief Security Architect Diversinet Corp. **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** ------_=_NextPart_001_01C04DA4.DA44EF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SACRED's vs. credentials' protection requirements [Was: RE: = I-D ACTION:draft-ietf-sacred-reqs-00.txt]

May I suggest that some reference be made to the = Common Vulnerabilities database www.cve.mitre.org as opposed to trying = to list all the potential vulnerabilities?

regards,
Sandi

-----Original Message-----
From: Al Arsenault [mailto:awa1@home.com]
Sent: Tuesday, November 07, 2000 9:36 PM
To: Linn, John
Cc: ietf-sacred@imc.org
Subject: Re: SACRED's vs. credentials' protection = requirements [Was: RE:
I-D ACTION:draft-ietf-sacred-reqs-00.txt]


John,

        Thanks for = your excellent comments.  I've put some responses in-line,
prefaced by my initials.

"Linn, John" wrote:
>
> I'd like to ask a general question about = scope.  Credentials in their
> "native" formats, before presentation = to a SACRED protocol for transport,
> may vary widely in terms of the levels of = protection they incorporate.  Some
> may be plaintext, others may be protected with = secrets having password-level
> entropy, and others may be protected with = strong cryptographic keys.  It
> seems clear, e.g., that the level of = confidentiality protection functionally
> required within a SACRED protocol is stronger = for credentials provided to
> SACRED as plaintext than for credentials which = are already
> strongly-encrypted.  Should we specify = that the level of protection required
> to be active within SACRED may vary depending = on the characteristics of
> credentials being input to SACRED?
>

AWA: Interesting point - I hadn't directly thought of = this before (but
then, the solutions I've seen all have the property = of working with
homogeneous levels of protection for the credentials = with which they
deal, so it hasn't been an issue).  Yes, this = should probably be
addressed at some point, but I'm uncomfortable with = the idea of
specifying/mandating given security levels - e.g., = "if credentials are
plaintext, be this strong"; "if = credentials are strongly protected,
weakening down to this level is okay".  = Those levels are probably going
to be dictated by the individual environments.  = So I think that the best
we can do in the requirements document is identify = that we have to
support all the cases you mention, and that the = protocols have to be
able to provide varying levels of security, = according to the other
protection provided to the credentials and the = environment.
 
> Under 3.1, it's probably hard to come up with = an accurate and exhaustive set
> of vulnerabilities; one which seems to be = missing is the case of
> masquerading as a credential server in order to = directly obtain a password
> which can then be presented by the attacker to = the user's legitimate
> credential server.  (V2 concerns = dictionary attack, but here there isn't
> even any dictionary involved.)
>

AWA: True.  The question is, how long a list do = we want? We sort of
wanted some sort of list, to show some examples, but = you're right, it's
probably impossible to come up with an exhaustive = list.  We'd welcome
other input on this topic - should we have such a = vulnerability list; if
so, how complete should we try to make it?  = (Assuming we keep the list,
we'll certainly include the one John mentions = above.)
 
> --jl
>
>


        =         =         Al = Arsenault
        =         =         Chief = Security Architect
        =         =         Diversinet = Corp.


***************************************************************= **************
This confirms that this email message has been swept = by
MIMEsweeper for the presence of computer = viruses.
***************************************************************= ***************