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-s