From owner-ietf-sacred@mail.imc.org Wed Nov 1 04:20:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23784 for ; Wed, 1 Nov 2000 04:20:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA20925 for ietf-sacred-bks; Wed, 1 Nov 2000 00:57:44 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA20921 for ; Wed, 1 Nov 2000 00:57:42 -0800 (PST) Received: (qmail 61354 invoked from network); 1 Nov 2000 09:04:00 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 1 Nov 2000 09:04:00 -0000 Received: (qmail 27324 invoked by uid 1183); 1 Nov 2000 09:04:20 -0000 Date: Wed, 1 Nov 2000 10:04:20 +0100 (MET) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sacred@imc.org Subject: Agenda for San Diego Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear All, A suggested agenda for "sacred." Comments, suggestions, and proposals are welcome and solicited. Thanks, -- Magnus Magnus Nystrom RSA Security Sacred meeting agenda. Thursday Dec 14th, 1 - 3 pm -------------------------------------------------- 1. Introduction, Agenda walkthrough (5 min) WG Chairs 2. Working Group Status (5 min) WG Chairs 3. Requirements Draft discussion (35min) A.Arsenault 4. Framework Draft discussion (35min) D.Gustafsson 5. Protocol and credential formats - proposals and discussion (35min) Contributors 6. Wrap up (5 min) WG Chairs From owner-ietf-sacred@mail.imc.org Thu Nov 2 10:28:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23311 for ; Thu, 2 Nov 2000 10:28:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15781 for ietf-sacred-bks; Thu, 2 Nov 2000 07:02:34 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15777 for ; Thu, 2 Nov 2000 07:02:32 -0800 (PST) Received: from clonvick-nt2.cisco.com (clonvick-isdn.cisco.com [171.70.238.6]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA06528; Thu, 2 Nov 2000 07:08:24 -0800 (PST) Message-Id: <4.3.2.7.2.20001102083240.00d0be70@sj-email.cisco.com> X-Sender: clonvick@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Nov 2000 09:08:23 -0600 To: stephen.farrell@baltimore.ie, ietf-sacred From: "Chris M. Lonvick" Subject: Re: enrollment/mgt operations In-Reply-To: <39F9911E.E786BB1E@baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steven and Everyone, At 03:28 PM 10/27/00 +0100, Stephen Farrell wrote: >Hi All, > >I guess the overall list of operations might be something >like: > >GET for downloads from a CS >PUT to update/change a credential or direct transfer one >ENROLL could be a special case of PUT? >DELETE to zap a credential (carefully:-) Would it make sense to add COMPARE to compare the stored credential to the credential on the CS or another device For explanation, let's take the case that I am upgrading my Hand95 to a HandMM and I just transfered everything over from one to the other. This _should_ mean that my credentials were also moved over. ...umm... or were they? That ol' Hand95 was getting a bit long in the tooth. I think that it would be nice to just link my new HandMM to the network and ask it to COMPARE the stored credentials against those that are held on the CS. I figure that this will probably be a lot better than destroying the old credential and doing a GET. This may be as simple as sending in a fingerprint and getting a [yes|no] response from the CS. Along the same line, perhaps I take my phone into the shop for repair. They hand it back to me and everything 'looks' OK, but it just 'feels' different. I'd again like to just COMPARE my credentials to ensure that no one maliciously or accidentally tampered with them. >So, questions: > >- Does all this just apply to the credential server case, or > also for direct transfers? I'd suggest both. For any set of circumstances of which I can see, one device would be acting as a 'client' and the other as a 'server'. This is evident in the case of a device and the CS. For a direct transfer, I can't think that they would be acting as peers or anything other than one being a 'client' and the other being its 'server' for the moment. Those roles may reverse the next moment. Does it make sense to mandate that the initiator always play the role of 'client' in all cases? Thanks, Chris From owner-ietf-sacred@mail.imc.org Thu Nov 2 11:44:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13922 for ; Thu, 2 Nov 2000 11:44:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23799 for ietf-sacred-bks; Thu, 2 Nov 2000 08:19:56 -0800 (PST) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23790 for ; Thu, 2 Nov 2000 08:19:54 -0800 (PST) Received: by balinese.baltimore.ie; id QAA23273; Thu, 2 Nov 2000 16:26:17 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma023184; Thu, 2 Nov 00 16:25:44 GMT Received: from baltimore.ie (wks131-4.ie.baltimore.com [10.153.4.131]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA28960; Thu, 2 Nov 2000 16:25:43 GMT Message-ID: <3A019685.847ABF4E@baltimore.ie> Date: Thu, 02 Nov 2000 16:29:57 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chris M. Lonvick" CC: ietf-sacred Subject: Re: enrollment/mgt operations References: <4.3.2.7.2.20001102083240.00d0be70@sj-email.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Chris, > Would it make sense to add > COMPARE to compare the stored credential to the credential > on the CS or another device > [...] I must admit I find this a bit of a stretch, does anyone else think we should add this now? I'd be for leaving it out for now, but keeping it on the list for discussion once we've a framework I-D in front of us. > >So, questions: > > > >- Does all this just apply to the credential server case, or > > also for direct transfers? > > I'd suggest both. For any set of circumstances of which I can > see, one device would be acting as a 'client' and the other as > a 'server'. This is evident in the case of a device and the CS. > For a direct transfer, I can't think that they would be acting > as peers or anything other than one being a 'client' and the other > being its 'server' for the moment. Those roles may reverse the > next moment. Does it make sense to mandate that the initiator > always play the role of 'client' in all cases? How about when there's e.g. a filesystem in between? Its probably different in the sense that there's no request/response, just an export (PUT?). Otherwise, I agree that any connection-oriented direct transfer might well be able to use a very similar protocol, at least at the level we've gotten to so far. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred@mail.imc.org Tue Nov 7 06:25:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13161 for ; Tue, 7 Nov 2000 06:25:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA14076 for ietf-sacred-bks; Tue, 7 Nov 2000 02:57:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14071 for ; Tue, 7 Nov 2000 02:57:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06271; Tue, 7 Nov 2000 06:04:37 -0500 (EST) Message-Id: <200011071104.GAA06271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sacred@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sacred-reqs-00.txt Date: Tue, 07 Nov 2000 06:04:37 -0500 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securely Available Credentials Working Group of the IETF. Title : Securely Available Credentials - Requirements Author(s) : A. Arsenault, S. Farrell Filename : draft-ietf-sacred-reqs-00.txt Pages : 14 Date : 06-Nov-00 This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This is the initial draft of the SACRED requirements specification and is therefore highly likely to change substantially. Discussion of this draft is taking place on the SACREDmailing list of the IETF SACRED working group (see http://www.imc.org/ietf-sacred for subscription information). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sacred-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sacred-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001106120305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sacred-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sacred-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106120305.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sacred@mail.imc.org Tue Nov 7 11:28:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24409 for ; Tue, 7 Nov 2000 11:28:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10112 for ietf-sacred-bks; Tue, 7 Nov 2000 07:48:09 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10108 for ; Tue, 7 Nov 2000 07:48:07 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Nov 2000 15:52:59 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA18069 for ; Tue, 7 Nov 2000 10:51:01 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Nov 2000 10:54:56 -0500 Message-ID: From: "Linn, John" To: ietf-sacred@imc.org Subject: SACRED's vs. credentials' protection requirements [Was: RE: I-D A CTION:draft-ietf-sacred-reqs-00.txt] Date: Tue, 7 Nov 2000 10:54:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to ask a general question about scope. Credentials in their "native" formats, before presentation to a SACRED protocol for transport, may vary widely in terms of the levels of protection they incorporate. Some may be plaintext, others may be protected with secrets having password-level entropy, and others may be protected with strong cryptographic keys. It seems clear, e.g., that the level of confidentiality protection functionally required within a SACRED protocol is stronger for credentials provided to SACRED as plaintext than for credentials which are already strongly-encrypted. Should we specify that the level of protection required to be active within SACRED may vary depending on the characteristics of credentials being input to SACRED? Under 3.1, it's probably hard to come up with an accurate and exhaustive set of vulnerabilities; one which seems to be missing is the case of masquerading as a credential server in order to directly obtain a password which can then be presented by the attacker to the user's legitimate credential server. (V2 concerns dictionary attack, but here there isn't even any dictionary involved.) --jl From owner-ietf-sacred@mail.imc.org Tue Nov 7 22:04:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29445 for ; Tue, 7 Nov 2000 22:04:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA04598 for ietf-sacred-bks; Tue, 7 Nov 2000 18:27:13 -0800 (PST) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04594 for ; Tue, 7 Nov 2000 18:27:11 -0800 (PST) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001108023403.SVGJ10139.mail.rdc1.md.home.com@home.com>; Tue, 7 Nov 2000 18:34:03 -0800 Message-ID: <3A08BBF5.E048D7CC@home.com> Date: Tue, 07 Nov 2000 21:35:33 -0500 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: ietf-sacred@imc.org Subject: Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John, Thanks for your excellent comments. I've put some responses in-line, prefaced by my initials. "Linn, John" wrote: > > I'd like to ask a general question about scope. Credentials in their > "native" formats, before presentation to a SACRED protocol for transport, > may vary widely in terms of the levels of protection they incorporate. Some > may be plaintext, others may be protected with secrets having password-level > entropy, and others may be protected with strong cryptographic keys. It > seems clear, e.g., that the level of confidentiality protection functionally > required within a SACRED protocol is stronger for credentials provided to > SACRED as plaintext than for credentials which are already > strongly-encrypted. Should we specify that the level of protection required > to be active within SACRED may vary depending on the characteristics of > credentials being input to SACRED? > AWA: Interesting point - I hadn't directly thought of this before (but then, the solutions I've seen all have the property of working with homogeneous levels of protection for the credentials with which they deal, so it hasn't been an issue). Yes, this should probably be addressed at some point, but I'm uncomfortable with the idea of specifying/mandating given security levels - e.g., "if credentials are plaintext, be this strong"; "if credentials are strongly protected, weakening down to this level is okay". Those levels are probably going to be dictated by the individual environments. So I think that the best we can do in the requirements document is identify that we have to support all the cases you mention, and that the protocols have to be able to provide varying levels of security, according to the other protection provided to the credentials and the environment. > Under 3.1, it's probably hard to come up with an accurate and exhaustive set > of vulnerabilities; one which seems to be missing is the case of > masquerading as a credential server in order to directly obtain a password > which can then be presented by the attacker to the user's legitimate > credential server. (V2 concerns dictionary attack, but here there isn't > even any dictionary involved.) > AWA: True. The question is, how long a list do we want? We sort of wanted some sort of list, to show some examples, but you're right, it's probably impossible to come up with an exhaustive list. We'd welcome other input on this topic - should we have such a vulnerability list; if so, how complete should we try to make it? (Assuming we keep the list, we'll certainly include the one John mentions above.) > --jl > > Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-sacred@mail.imc.org Thu Nov 9 11:03:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22255 for ; Thu, 9 Nov 2000 11:03:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA13648 for ietf-sacred-bks; Thu, 9 Nov 2000 07:35:23 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA13638 for ; Thu, 9 Nov 2000 07:35:21 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Nov 2000 15:40:21 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA10770; Thu, 9 Nov 2000 10:42:20 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 10:42:20 -0500 Message-ID: From: "Linn, John" To: "'Al Arsenault'" Cc: ietf-sacred@imc.org Subject: RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt] Date: Thu, 9 Nov 2000 10:42:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Al wrote: > John, > > Thanks for your excellent comments. I've put some > responses in-line, > prefaced by my initials. Thanks for this response. Here are some follow-on comments, and a separate point. > > "Linn, John" wrote: > > > > I'd like to ask a general question about scope. > Credentials in their > > "native" formats, before presentation to a SACRED protocol > for transport, > > may vary widely in terms of the levels of protection they > incorporate. Some > > may be plaintext, others may be protected with secrets > having password-level > > entropy, and others may be protected with strong > cryptographic keys. It > > seems clear, e.g., that the level of confidentiality > protection functionally > > required within a SACRED protocol is stronger for > credentials provided to > > SACRED as plaintext than for credentials which are already > > strongly-encrypted. Should we specify that the level of > protection required > > to be active within SACRED may vary depending on the > characteristics of > > credentials being input to SACRED? > > > > AWA: Interesting point - I hadn't directly thought of this before (but > then, the solutions I've seen all have the property of working with > homogeneous levels of protection for the credentials with which they > deal, so it hasn't been an issue). Yes, this should probably be > addressed at some point, but I'm uncomfortable with the idea of > specifying/mandating given security levels - e.g., "if credentials are > plaintext, be this strong"; "if credentials are strongly protected, > weakening down to this level is okay". Those levels are > probably going > to be dictated by the individual environments. So I think > that the best > we can do in the requirements document is identify that we have to > support all the cases you mention, and that the protocols have to be > able to provide varying levels of security, according to the other > protection provided to the credentials and the environment. This seems reasonable in principle, but should temper later discussions about how any MUST-implement protection requirement should be framed for purposes of conformant interoperability. Given an environment where credentials are themselves strongly protected, it could be a strong deterrent to SACRED adoption if the price of admission were deployment of additional infrastructure to support an additional layer of key management which wasn't strictly necessary from a security perspective. More generally, I think it's important to recognize that protection facilities enabling secure transfer of credentials can be provided in many layers, particularly the following: (1) in the underlying credential format (2) within a credential transfer protocol like SACRED (3) in another protocol (e.g., TLS) within which the credential transfer protocol might be encapsulated If we focus tightly or exclusively within the SACRED protocol, which seems an understandably likely result for a WG that's organizationally chartered to specify that protocol, there's a risk that we'll mandate facilities which are (sometimes or often) functionally redundant relative to those available in the other layers. These incur costs, which may be particularly difficult to satisfy under some of the initialization scenarios for which SACRED could be most useful; while individual users will probably invoke SACRED only on fairly infrequent occasions, those occasions are important ones and may operate under some tight constraints. I urge, therefore, that the protection facilities provided within SACRED be modular so as to be effectively tailorable to correspond to the surrounding layers and operational environment. > > > Under 3.1, it's probably hard to come up with an accurate > and exhaustive set > > of vulnerabilities; one which seems to be missing is the case of > > masquerading as a credential server in order to directly > obtain a password > > which can then be presented by the attacker to the user's legitimate > > credential server. (V2 concerns dictionary attack, but > here there isn't > > even any dictionary involved.) > > > > AWA: True. The question is, how long a list do we want? We sort of > wanted some sort of list, to show some examples, but you're > right, it's > probably impossible to come up with an exhaustive list. We'd welcome > other input on this topic - should we have such a > vulnerability list; if > so, how complete should we try to make it? (Assuming we keep > the list, > we'll certainly include the one John mentions above.) I'm OK with a list of example vulnerabilities, caveated as non-exhaustive, and think that this is useful and informative material to present. Rather than considering them as a separate and different type of requirements, though, I'd suggest that their implied countermeasures be distilled into corresponding functional requirements within the existing protocol requirements sections. A separate point: shortly before the end of Sec. 2.1, it's stated that: "Solutions involving the direct transfer of credentials from one device to another are potentially somewhat more complex than the credential-server approach, owing to the large number of different devices and formats that may have to be supported. Complexity is also added due to the fact that each device may in turn have to exhibit the behavior of both a client and a server." I don't think that the presence or absence of a server influences the number of client device types that may exist, or the variety of credential formats they may use. I'm assuming the underlying premise here that the use of a server may simplify individual clients by making it unnecessary for them to provide functions to support other client types, at the cost of complexity present in the server to be able to interact with each of those client types. If so, this might be a worthwhile clarification to include. --jl From owner-ietf-sacred@mail.imc.org Thu Nov 9 14:13:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29455 for ; Thu, 9 Nov 2000 14:13:03 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA24771 for ietf-sacred-bks; Thu, 9 Nov 2000 10:48:22 -0800 (PST) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24767 for ; Thu, 9 Nov 2000 10:48:20 -0800 (PST) Received: by balinese.baltimore.ie; id SAA07492; Thu, 9 Nov 2000 18:55:17 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma007469; Thu, 9 Nov 00 18:55:01 GMT Received: from baltimore.ie (ip203-221.ie.baltimore.com [192.168.21.203]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA08159; Thu, 9 Nov 2000 18:55:01 GMT Message-ID: <3A0AF407.918A9297@baltimore.ie> Date: Thu, 09 Nov 2000 18:59:20 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: "'Al Arsenault'" , ietf-sacred@imc.org Subject: Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi John, [snip] > This seems reasonable in principle, but should temper later discussions > about how any MUST-implement protection requirement should be framed for > purposes of conformant interoperability. Given an environment where > credentials are themselves strongly protected, it could be a strong > deterrent to SACRED adoption if the price of admission were deployment of > additional infrastructure to support an additional layer of key management > which wasn't strictly necessary from a security perspective. [snip] You're right that there will be cases where using whatever ends up as the standards track SACRED protocol will require overhead that isn't actually useful in the context of a particularly "strong" credential format. However, I think that in order to get an interoperable protocol that allows one to meet the overall charter we'll probably have to mandate that overhead, since we certainly will have to pick some credential format, and I'd be very surprised if that format is likely to be safe to use without the additional overhead. Bit fuzzy I know, but I hope you get what I mean. > I'm OK with a list of example vulnerabilities, caveated as non-exhaustive, > and think that this is useful and informative material to present. Rather > than considering them as a separate and different type of requirements, > though, I'd suggest that their implied countermeasures be distilled into > corresponding functional requirements within the existing protocol > requirements sections. I'm not sure that that'd work very easily but am certainly willing to consider it. I guess the reason for listing vulnerabilities (and I agree that whatever list we end up with will be non-exhaustive) was that I think its easier to do this way for requirements (i.e. less danger of inadvertently including design in the requirements draft). Note also that the current draft doesn't say "protocols MUST prevent..." but rather that they "SHOULD offer protection" and MUST specify how they do, or don't, protect against the listed vulnerabilities. There wasn't an intent to declare a protocol as not meeting the requirements just because there's some vulnerability listed that the protocol doesn't absolutely prevent (as long as that's noted in the protocol specification). Maybe this needs to be clearer? > A separate point: shortly before the end of Sec. 2.1, it's stated that: > > "Solutions involving the direct transfer of credentials from one > device to another are potentially somewhat more complex than the > credential-server approach, owing to the large number of different > devices and formats that may have to be supported. Complexity is > also added due to the fact that each device may in turn have to > exhibit the behavior of both a client and a server." > > I don't think that the presence or absence of a server influences the number > of client device types that may exist, or the variety of credential formats > they may use. I'm assuming the underlying premise here that the use of a > server may simplify individual clients by making it unnecessary for them to > provide functions to support other client types, at the cost of complexity > present in the server to be able to interact with each of those client > types. If so, this might be a worthwhile clarification to include. Good point. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred@mail.imc.org Mon Nov 13 14:34:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19599 for ; Mon, 13 Nov 2000 14:34:03 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA14049 for ietf-sacred-bks; Mon, 13 Nov 2000 10:59:15 -0800 (PST) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14043 for ; Mon, 13 Nov 2000 10:59:13 -0800 (PST) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA02635 for ; Mon, 13 Nov 2000 13:43:41 -0500 (EST) Message-Id: <200011131843.NAA02621@roadblock.missi.ncsc.mil> From: "Miklos A. Sue" To: "'Al Arsenault'" , "Linn, John" Cc: ietf-sacred@imc.org Subject: RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt] Date: Mon, 13 Nov 2000 14:06:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04DA4.DA44EF60" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04DA4.DA44EF60 Content-Type: text/plain; charset="iso-8859-1" May I suggest that some reference be made to the Common Vulnerabilities database www.cve.mitre.org as opposed to trying to list all the potential vulnerabilities? regards, Sandi -----Original Message----- From: Al Arsenault [mailto:awa1@home.com] Sent: Tuesday, November 07, 2000 9:36 PM To: Linn, John Cc: ietf-sacred@imc.org Subject: Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] John, Thanks for your excellent comments. I've put some responses in-line, prefaced by my initials. "Linn, John" wrote: > > I'd like to ask a general question about scope. Credentials in their > "native" formats, before presentation to a SACRED protocol for transport, > may vary widely in terms of the levels of protection they incorporate. Some > may be plaintext, others may be protected with secrets having password-level > entropy, and others may be protected with strong cryptographic keys. It > seems clear, e.g., that the level of confidentiality protection functionally > required within a SACRED protocol is stronger for credentials provided to > SACRED as plaintext than for credentials which are already > strongly-encrypted. Should we specify that the level of protection required > to be active within SACRED may vary depending on the characteristics of > credentials being input to SACRED? > AWA: Interesting point - I hadn't directly thought of this before (but then, the solutions I've seen all have the property of working with homogeneous levels of protection for the credentials with which they deal, so it hasn't been an issue). Yes, this should probably be addressed at some point, but I'm uncomfortable with the idea of specifying/mandating given security levels - e.g., "if credentials are plaintext, be this strong"; "if credentials are strongly protected, weakening down to this level is okay". Those levels are probably going to be dictated by the individual environments. So I think that the best we can do in the requirements document is identify that we have to support all the cases you mention, and that the protocols have to be able to provide varying levels of security, according to the other protection provided to the credentials and the environment. > Under 3.1, it's probably hard to come up with an accurate and exhaustive set > of vulnerabilities; one which seems to be missing is the case of > masquerading as a credential server in order to directly obtain a password > which can then be presented by the attacker to the user's legitimate > credential server. (V2 concerns dictionary attack, but here there isn't > even any dictionary involved.) > AWA: True. The question is, how long a list do we want? We sort of wanted some sort of list, to show some examples, but you're right, it's probably impossible to come up with an exhaustive list. We'd welcome other input on this topic - should we have such a vulnerability list; if so, how complete should we try to make it? (Assuming we keep the list, we'll certainly include the one John mentions above.) > --jl > > Al Arsenault Chief Security Architect Diversinet Corp. **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** ------_=_NextPart_001_01C04DA4.DA44EF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SACRED's vs. credentials' protection requirements [Was: RE: = I-D ACTION:draft-ietf-sacred-reqs-00.txt]

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

regards,
Sandi

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


John,

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

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

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

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


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


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

------_=_NextPart_001_01C04DA4.DA44EF60-- From owner-ietf-sacred@mail.imc.org Tue Nov 14 16:44:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10014 for ; Tue, 14 Nov 2000 16:44:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18599 for ietf-sacred-bks; Tue, 14 Nov 2000 13:02:52 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA18595 for ; Tue, 14 Nov 2000 13:02:51 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Nov 2000 21:08:10 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA10181; Tue, 14 Nov 2000 16:10:13 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 16:10:13 -0500 Message-ID: From: "Linn, John" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred@imc.org Subject: RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt] Date: Tue, 14 Nov 2000 16:09:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen wrote, excerpting: > [snip] > > This seems reasonable in principle, but should temper later > discussions > > about how any MUST-implement protection requirement should > be framed for > > purposes of conformant interoperability. Given an environment where > > credentials are themselves strongly protected, it could be a strong > > deterrent to SACRED adoption if the price of admission were > deployment of > > additional infrastructure to support an additional layer of > key management > > which wasn't strictly necessary from a security perspective. > [snip] > > You're right that there will be cases where using whatever ends up as > the standards track SACRED protocol will require overhead that isn't > actually useful in the context of a particularly "strong" credential > format. > > However, I think that in order to get an interoperable protocol that > allows one to meet the overall charter we'll probably have to mandate > that overhead, since we certainly will have to pick some credential > format, and I'd be very surprised if that format is likely to be safe > to use without the additional overhead. > > Bit fuzzy I know, but I hope you get what I mean. > Protection quality may be separate from credential format; in general, interoperability may require not only that a common format be selected but also that a common protection mode. A format could simply specify encryption with a key, independent of whether or not that key was password-derived. PKCS #12, as another example, specifies both password-based and public-key privacy and integrity modes. Have we established a working premise for the level (if any) of protection to be assumed in SACRED-transported credential objects before they're placed in SACRED hands? --jl From owner-ietf-sacred@mail.imc.org Wed Nov 15 04:24:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03233 for ; Wed, 15 Nov 2000 04:24:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03589 for ietf-sacred-bks; Wed, 15 Nov 2000 01:00:07 -0800 (PST) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA03580 for ; Wed, 15 Nov 2000 01:00:05 -0800 (PST) Received: by balinese.baltimore.ie; id JAA02331; Wed, 15 Nov 2000 09:07:33 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma000627; Wed, 15 Nov 00 09:06:34 GMT Received: from irlbdc.ie.baltimore.com (irlbdc.ie.baltimore.com [10.153.25.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id FAA15647; Wed, 15 Nov 2000 05:15:20 GMT Received: from lapdev-2 (wks151-25.ie.baltimore.com [10.153.25.151]) by irlbdc.ie.baltimore.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W53L5PVM; Wed, 15 Nov 2000 05:14:40 -0000 Reply-To: From: "William Whyte" To: "'Linn, John'" , Cc: Subject: RE: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt] Date: Tue, 14 Nov 2000 23:45:35 -0500 Message-ID: <002001c04ec3$9f3984b0$e7d06520@lapdev-2.ie.baltimore.com> 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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi John, > Protection quality may be separate from credential format; in general, > interoperability may require not only that a common format be selected but > also that a common protection mode. A format could simply specify encryption > with a key, independent of whether or not that key was password-derived. > PKCS #12, as another example, specifies both password-based and public-key > privacy and integrity modes. Have we established a working premise for the > level (if any) of protection to be assumed in SACRED-transported credential > objects before they're placed in SACRED hands? I think the key is that SACRED is Secure _Access_ to Credentials; in other words, we're saying that the access has to be secured, independent of whether or not the credentials are secured. Cheers, William From owner-ietf-sacred@mail.imc.org Wed Nov 22 06:30:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23573 for ; Wed, 22 Nov 2000 06:30:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA22186 for ietf-sacred-bks; Wed, 22 Nov 2000 03:11:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22179 for ; Wed, 22 Nov 2000 03:11:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21214; Wed, 22 Nov 2000 06:12:36 -0500 (EST) Message-Id: <200011221112.GAA21214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sacred@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sacred-framework-00.txt Date: Wed, 22 Nov 2000 06:12:35 -0500 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securely Available Credentials Working Group of the IETF. Title : Securely Available Credentials - Framework Author(s) : D. Gustafson, M. Nystrom Filename : draft-ietf-sacred-framework-00.txt Pages : 15 Date : 21-Nov-00 As the number, and more particularly the number of different types, of devices, connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This draft responds to the requirements listed in [SACRED}. It presents a strawman framework and outlines protocols for securely available credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sacred-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sacred-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121112209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sacred-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sacred-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121112209.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sacred@mail.imc.org Wed Nov 22 07:49:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05562 for ; Wed, 22 Nov 2000 07:49:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA28653 for ietf-sacred-bks; Wed, 22 Nov 2000 04:27:05 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA28648 for ; Wed, 22 Nov 2000 04:27:03 -0800 (PST) Received: (qmail 83915 invoked from network); 22 Nov 2000 12:27:56 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 22 Nov 2000 12:27:56 -0000 Received: (qmail 19632 invoked by uid 1183); 22 Nov 2000 12:28:23 -0000 Date: Wed, 22 Nov 2000 13:28:23 +0100 (MET) From: Magnus Nystrom X-Sender: Reply-To: Magnus Nystrom To: Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt In-Reply-To: <200011221112.GAA21214@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id EAA28649 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id EAA28653 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA05562 Dear Working Group, The I-D mentioned above is a first attempt at defining a framework for sacred -operations, protocol functionality and authentication options. Several sections are still incomplete, and others will surely be re-drafted. It is our hope, however, that the draft will serve both as a basis for discussions in San Diego (as well as on this mailing list), and as a stepping-stone for a better understanding of the challenges we face. -- Magnus & Dale On Wed, 22 Nov 2000 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Securely Available Credentials Working Group of the IETF. > > Title : Securely Available Credentials - Framework > Author(s) : D. Gustafson, M. Nystrom > Filename : draft-ietf-sacred-framework-00.txt > Pages : 15 > Date : 21-Nov-00 > > As the number, and more particularly the number of different types, > of devices, connecting to the Internet increases, credential mobility > becomes an issue for IETF standardization. This draft responds to the > requirements listed in [SACRED}. It presents a strawman framework and > outlines protocols for securely available credentials. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sacred-framework-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sacred-framework-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Magnus Magnus Nyström RSA Security From owner-ietf-sacred@mail.imc.org Thu Nov 23 12:00:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25916 for ; Thu, 23 Nov 2000 12:00:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA13577 for ietf-sacred-bks; Thu, 23 Nov 2000 07:05:34 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA13572 for ; Thu, 23 Nov 2000 07:05:32 -0800 (PST) Received: (qmail 95755 invoked from network); 23 Nov 2000 15:06:32 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 23 Nov 2000 15:06:32 -0000 Received: (qmail 1005 invoked by uid 1183); 23 Nov 2000 15:06:59 -0000 Date: Thu, 23 Nov 2000 16:06:59 +0100 (MET) From: Magnus Nystrom X-Sender: Reply-To: Magnus Nystrom To: Subject: An IPR note Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Working Group, Just to avoid any confusion - the Ford-Kaliski scheme mentioned in the framework I-D is patent-encumbered (or at least a patent application has been filed; see http://www.verisign.com/rsc/wp/roaming/index.html). But please also note that the I-D does not suggest this method, but merely reference it. Thanks, -- Magnus From owner-ietf-sacred@mail.imc.org Wed Nov 29 11:36:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01859 for ; Wed, 29 Nov 2000 11:36:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA23572 for ietf-sacred-bks; Wed, 29 Nov 2000 08:11:07 -0800 (PST) Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23563 for ; Wed, 29 Nov 2000 08:11:05 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 11:12:52 -0500 Message-ID: <3120721CA75DD411B8340090273D20B1EEC27C@sottmxs06.entrust.com> From: Mike Just To: "'Magnus Nystrom'" , ietf-sacred@imc.org Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt Date: Wed, 29 Nov 2000 11:11:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05A1F.140AEC00" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05A1F.140AEC00 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id IAA23572 Content-Transfer-Encoding: quoted-printable Some comments: - [Section 1, 1st para] In motivating the requirement for roaming, it's stated that import/export tools exist, but not for all environments. Anot= her statement worth making here is that the use of such tools is also impractical for the typical user.=20 - [Section 3.1, 2nd bullet] The requirement for http might be ok, but why require TLS. This gets into the argument that you mention in Section 6, regarding the (de)coupling of the credential and protocol protections. Th= e strong password algorithms of Section 4.2 would not require TLS protectio= n, for example. - [Section 3.1.1, 1st paragraph above the sequence diagram] It is stated that "[t]he client MAY provide an additional layer of encryption (as defi= ned by the credential format) to ensure the credential is not exposed within = the credential server or repository." Is there any good reason to not make t= his a MUST? - [Section 3.1.2, 2nd bullet] It is stated that "TLS server authenticatio= n SHOULD be used to authenticate the server." I think that this is fine, s= o long as we also include something like "Server authentication MUST be use= d to authenticate the server." Therefore server authentication MUST be use= d; how it is performed depends on the protocol. - [Section 3.1.4, 4th bullet] Where you say "change password", do you mea= n the password protecting the object containing the credentials or the password used for authentication to the server? It is worth splitting the= se cases up, even though it may be that the same password is used to derive = the key used to protect the credentials and the key used to authenticate to t= he server. - [Section 4, end of 2nd paragraph] It is stated that "the user authentication method/data may be updated from time to time thereafter by the authorized user." Although the user is more suited to update the data= , wouldn't an administrator be the right person for updating the method? - [Section 4.2, 3rd paragraph] The Ford-Kaliski comment (if kept) is equa= lly applicable to the OTP schemes in section 4.1 (and any other password-base= d scheme) so that it might be better placed outside of Section 4.2. - [Section 4.3] Is this only being considered for the PUT and DELETE operations (as opposed to GET) since the goal of this WG is to provide a protocol to retrieve such credentials (i.e. chicken-egg problem)? - [Section 4.4, 4th bullet] I was a little unclear with this paragraph. D= oes this exclude the case where a different key is used for credential protection than for authentication even though such keys might be generat= ed from the same password? - [Section 5] I think that an important property for the ultimate credent= ial format is that it be extensible. This would support interoperability yet still allow vendors to transport additional, vendor-specific attributes. - [Section 6] Regarding the credential protection, I think that the credential object should be protected, independent of the protection of t= he transport protocol, though additional protection must also be provided by the transport protocol. The protection of the credentials ensures they ne= ed not be in the clear at the credential server, while the transport protect= ion offers increased protection (especially necessary since the credentials themselves will likely be protected by a password-derived key).=20 - [Section 7, last sentence] For this reason, I think that server authentication needs to be required (as I've also stated above). Cheers, Mike J. > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Wednesday, November 22, 2000 7:28 AM > To: ietf-sacred@imc.org > Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt >=20 >=20 > Dear Working Group, >=20 > The I-D mentioned above is a first attempt at defining a framework for > sacred -operations, protocol functionality and authentication options. > Several sections are still incomplete, and others will surely be > re-drafted. It is our hope, however, that the draft will=20 > serve both as a > basis for discussions in San Diego (as well as on this=20 > mailing list), and > as a stepping-stone for a better understanding of the=20 > challenges we face. >=20 > -- Magnus & Dale >=20 > On Wed, 22 Nov 2000 Internet-Drafts@ietf.org > wrote: >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Securely Available=20 > Credentials Working Group of the IETF. > > > > Title : Securely Available Credentials - Framework > > Author(s) : D. Gustafson, M. Nystrom > > Filename : draft-ietf-sacred-framework-00.txt > > Pages : 15 > > Date : 21-Nov-00 > > > > As the number, and more particularly the number of different types, > > of devices, connecting to the Internet increases,=20 > credential mobility > > becomes an issue for IETF standardization. This draft=20 > responds to the > > requirements listed in [SACRED}. It presents a strawman=20 > framework and > > outlines protocols for securely available credentials. > > > > A URL for this Internet-Draft is: > >=20 http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sacred-framework-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sacred-framework-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Magnus Magnus Nystr=F6m RSA Security ------_=_NextPart_001_01C05A1F.140AEC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-sacred-framework-00.txt

Some comments:

- [Section 1, 1st para] In motivating the requirement = for roaming, it's stated that import/export tools exist, but not for = all environments. Another statement worth making here is that the use = of such tools is also impractical for the typical user.

- [Section 3.1, 2nd bullet] The requirement for http = might be ok, but why require TLS. This gets into the argument that you = mention in Section 6, regarding the (de)coupling of the credential and = protocol protections. The strong password algorithms of Section 4.2 = would not require TLS protection, for example.

- [Section 3.1.1, 1st paragraph above the sequence = diagram] It is stated that "[t]he client MAY provide an additional = layer of encryption (as defined by the credential format) to ensure the = credential is not exposed within the credential server or = repository."  Is there any good reason to not make this a = MUST?

- [Section 3.1.2, 2nd bullet] It is stated that = "TLS server authentication SHOULD be used to authenticate the = server."  I think that this is fine, so long as we also = include something like "Server authentication MUST be used to = authenticate the server."  Therefore server authentication = MUST be used; how it is performed depends on the protocol.

- [Section 3.1.4, 4th bullet] Where you say = "change password", do you mean the password protecting the = object containing the credentials or the password used for = authentication to the server? It is worth splitting these cases up, = even though it may be that the same password is used to derive the key = used to protect the credentials and the key used to authenticate to the = server.

- [Section 4, end of 2nd paragraph] It is stated that = "the user authentication method/data may be updated from time to = time thereafter by the authorized user." Although the user is more = suited to update the data, wouldn't an administrator be the right = person for updating the method?

- [Section 4.2, 3rd paragraph] The Ford-Kaliski = comment (if kept) is equally applicable to the OTP schemes in section = 4.1 (and any other password-based scheme) so that it might be better = placed outside of Section 4.2.

- [Section 4.3] Is this only being considered for the = PUT and DELETE operations (as opposed to GET) since the goal of this WG = is to provide a protocol to retrieve such credentials (i.e. chicken-egg = problem)?

- [Section 4.4, 4th bullet] I was a little unclear = with this paragraph. Does this exclude the case where a different key = is used for credential protection than for authentication even though = such keys might be generated from the same password?

- [Section 5] I think that an important property for = the ultimate credential format is that it be extensible. This would = support interoperability yet still allow vendors to transport = additional, vendor-specific attributes.

- [Section 6] Regarding the credential protection, I = think that the credential object should be protected, independent of = the protection of the transport protocol, though additional protection = must also be provided by the transport protocol. The protection of the = credentials ensures they need not be in the clear at the credential = server, while the transport protection offers increased protection = (especially necessary since the credentials themselves will likely be = protected by a password-derived key).

- [Section 7, last sentence] For this reason, I think = that server authentication needs to be required (as I've also stated = above).

Cheers,
Mike J.

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com= ]
> Sent: Wednesday, November 22, 2000 7:28 = AM
> To: ietf-sacred@imc.org
> Subject: Re: I-D = ACTION:draft-ietf-sacred-framework-00.txt
>
>
> Dear Working Group,
>
> The I-D mentioned above is a first attempt at = defining a framework for
> sacred -operations, protocol functionality and = authentication options.
> Several sections are still incomplete, and = others will surely be
> re-drafted. It is our hope, however, that the = draft will
> serve both as a
> basis for discussions in San Diego (as well as = on this
> mailing list), and
> as a stepping-stone for a better understanding = of the
> challenges we face.
>
> -- Magnus & Dale
>
>  On Wed, 22 Nov 2000 = Internet-Drafts@ietf.org
> wrote:
>
> > A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
> > This draft is a work item of the Securely = Available
> Credentials Working Group of the IETF.
> >
> >     Title   =         : Securely Available = Credentials - Framework
> >     = Author(s)       : D. Gustafson, M. = Nystrom
> >     = Filename        : = draft-ietf-sacred-framework-00.txt
> >     Pages   =         : 15
> >     Date    =         : 21-Nov-00
> >
> > As the number, and more particularly the = number of different types,
> > of devices, connecting to the Internet = increases,
> credential mobility
> > becomes an issue for IETF standardization. = This draft
> responds to the
> > requirements listed in [SACRED}. It = presents a strawman
> framework and
> > outlines protocols for securely available = credentials.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-ietf-sacred-= framework-00.txt
>
> Internet-Drafts are also available by anonymous = FTP. Login with the username
> "anonymous" and a password of your = e-mail address. After logging in,
> type "cd internet-drafts" and = then
>       "get = draft-ietf-sacred-framework-00.txt".
>
> A list of Internet-Drafts directories can be = found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by = e-mail.
>
> Send a message to:
>       = mailserv@ietf.org.
> In the body type:
>       "FILE = /internet-drafts/draft-ietf-sacred-framework-00.txt".
>
> NOTE: The mail server at ietf.org can return = the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, insert = the command "ENCODING mime" before the = "FILE"
>       command.  = To decode the response(s), you will need "munpack" or
>       a MIME-compliant = mail reader.  Different MIME-compliant mail readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into multiple = messages), so check your local documentation on
>       how to = manipulate these messages.
>
>
> Below is the data which will enable a MIME = compliant mail reader
> implementation to automatically retrieve the = ASCII version of the
> Internet-Draft.
>

-- Magnus
Magnus Nystr=F6m
RSA Security

------_=_NextPart_001_01C05A1F.140AEC00-- From owner-ietf-sacred@mail.imc.org Thu Nov 30 12:48:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26130 for ; Thu, 30 Nov 2000 12:48:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA00347 for ietf-sacred-bks; Thu, 30 Nov 2000 09:21:35 -0800 (PST) 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 JAA00342 for ; Thu, 30 Nov 2000 09:21:32 -0800 (PST) Received: from bpsi.net (port446.bpsi.net [209.54.245.246]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id eAUHMfb06809; Thu, 30 Nov 2000 11:22:42 -0600 (CST) Message-ID: <3A268C3C.4A098842@bpsi.net> Date: Thu, 30 Nov 2000 11:19:57 -0600 From: Dale Gustafson X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mike Just CC: "'Magnus Nystrom'" , ietf-sacred@imc.org, Stephen Farrell Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt References: <3120721CA75DD411B8340090273D20B1EEC27C@sottmxs06.entrust.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA00347 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA26130 Hi Mike, Thanks for your comments. I have responded to several of them -- please see my comments, inline. Best Regards, Dale Gustafson Mike Just wrote: > Some comments: > > - [Section 1, 1st para] In motivating the requirement for roaming, it's stated > that import/export tools exist, but not for all environments. Another > statement worth making here is that the use of such tools is also impractical > for the typical user. > > - [Section 3.1, 2nd bullet] The requirement for http might be ok, but why > require TLS. This gets into the argument that you mention in Section 6, > regarding the (de)coupling of the credential and protocol protections. The > strong password algorithms of Section 4.2 would not require TLS protection, > for example. In this draft, we removed a few restrictions that had been suggested earlier -- originally HTTP over TLS was the only transport considered and was mandantory. In this revision HTTP / TLS is not the only possible transport protocol. We may have to refine the wording in several additional places to make this more clear. > - [Section 3.1.1, 1st paragraph above the sequence diagram] It is stated that > "[t]he client MAY provide an additional layer of encryption (as defined by the > credential format) to ensure the credential is not exposed within the > credential server or repository." Is there any good reason to not make this a > MUST? We have attempted to define a protocol framework that could accomodate any, arbitrary (opaque) credential, such as: - pkcs#15 software token - pkcs#12 key pair / certificate file - other I was trying to indicate that the designers of each credential format have determined (or will determine) which part of the credential needs to be encrypted. > - [Section 3.1.2, 2nd bullet] It is stated that "TLS server authentication > SHOULD be used to authenticate the server." I think that this is fine, so > long as we also include something like "Server authentication MUST be used to > authenticate the server." Therefore server authentication MUST be used; how > it is performed depends on the protocol. Please see earlier comment re: HTTP / TLS is an optional transport layer. If anyone disagrees with this choice please speak up. > - [Section 3.1.4, 4th bullet] Where you say "change password", do you mean the > password protecting the object containing the credentials or the password used > for authentication to the server? It is worth splitting these cases up, even > though it may be that the same password is used to derive the key used to > protect the credentials and the key used to authenticate to the server. I mean the password used by the server to authenticate the credential user. Since the credential is opaque, the server has no inherent capability to decrypt the credential. > - [Section 4, end of 2nd paragraph] It is stated that "the user authentication > method/data may be updated from time to time thereafter by the authorized > user." Although the user is more suited to update the data, wouldn't an > administrator be the right person for updating the method? We assume all devices are not able to support all user authentication methods. We thought about protecting a single credential with more than one authentication method / data so the credential could easily be used with different devices. This issue needs further consideration. I think we have assumed throughout that the administrator is not an authorized user of the credential. An administrator may need to have some control over which authentication method or methods are allowed to be used with a given credential but that may be more an implemention issue for the server application builder. > - [Section 4.2, 3rd paragraph] The Ford-Kaliski comment (if kept) is equally > applicable to the OTP schemes in section 4.1 (and any other password-based > scheme) so that it might be better placed outside of Section 4.2. > - [Section 4.3] Is this only being considered for the PUT and DELETE > operations (as opposed to GET) since the goal of this WG is to provide a > protocol to retrieve such credentials (i.e. chicken-egg problem)? No. Download of the first / only credential to a particular device cannot be done using HTTP over TLS. Download of credentials 2 - N using HTTP / TLS is possible. > - [Section 4.4, 4th bullet] I was a little unclear with this paragraph. Does > this exclude the case where a different key is used for credential protection > than for authentication even though such keys might be generated from the same > password? If it's easy for someone who steals a password verifier from the server to determine the authentication password (via simple dictionary attack). And if that derived password can then be used to both download some else's credential and decrypt and use that credential, then yes, that's what we want to preclude. > - [Section 5] I think that an important property for the ultimate credential > format is that it be extensible. This would support interoperability yet still > allow vendors to transport additional, vendor-specific attributes. Since the credential is an opaque object, vendors are free to define whatever they need. > - [Section 6] Regarding the credential protection, I think that the credential > object should be protected, independent of the protection of the transport > protocol, though additional protection must also be provided by the transport > protocol. The protection of the credentials ensures they need not be in the > clear at the credential server, while the transport protection offers > increased protection (especially necessary since the credentials themselves > will likely be protected by a password-derived key). > - [Section 7, last sentence] For this reason, I think that server > authentication needs to be required (as I've also stated above). > > Cheers, > Mike J. > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, November 22, 2000 7:28 AM > > To: ietf-sacred@imc.org > > Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt > > > > > > Dear Working Group, > > > > The I-D mentioned above is a first attempt at defining a framework for > > sacred -operations, protocol functionality and authentication options. > > Several sections are still incomplete, and others will surely be > > re-drafted. It is our hope, however, that the draft will > > serve both as a > > basis for discussions in San Diego (as well as on this > > mailing list), and > > as a stepping-stone for a better understanding of the > > challenges we face. > > > > -- Magnus & Dale > > > > On Wed, 22 Nov 2000 Internet-Drafts@ietf.org > > wrote: > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > This draft is a work item of the Securely Available > > Credentials Working Group of the IETF. > > > > > > Title : Securely Available Credentials - Framework > > > Author(s) : D. Gustafson, M. Nystrom > > > Filename : draft-ietf-sacred-framework-00.txt > > > Pages : 15 > > > Date : 21-Nov-00 > > > > > > As the number, and more particularly the number of different types, > > > of devices, connecting to the Internet increases, > > credential mobility > > > becomes an issue for IETF standardization. This draft > > responds to the > > > requirements listed in [SACRED}. It presents a strawman > > framework and > > > outlines protocols for securely available credentials. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-00.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sacred-framework-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-sacred-framework-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > -- Magnus > Magnus Nyström > RSA Security From owner-ietf-sacred@mail.imc.org Thu Nov 30 13:43:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19376 for ; Thu, 30 Nov 2000 13:43:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03552 for ietf-sacred-bks; Thu, 30 Nov 2000 10:20:30 -0800 (PST) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03532 for ; Thu, 30 Nov 2000 10:20:26 -0800 (PST) Received: (qmail 35781 invoked from network); 30 Nov 2000 18:21:58 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 30 Nov 2000 18:21:58 -0000 Received: (qmail 28521 invoked by uid 1183); 30 Nov 2000 18:21:59 -0000 Date: Thu, 30 Nov 2000 19:21:59 +0100 (MET) From: Magnus Nystrom X-Sender: Reply-To: Magnus Nystrom To: cc: Subject: Proposed agenda for SACRED in San Diego Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id KAA03547 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id KAA03552 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA19376 Dear All, This is the proposed agenda for SACRED in San Diego. ------------------------------------------------------------ 1. Introduction, Agenda walkthrough and Working Group Status (5 min) WG Chairs 2. Requirements Draft discussion (35 min) A. Arsenault 3. Framework Draft discussion (30 min) D. Gustafsson 4. Desirable properties for strong password-based credentials download protocols (15 min) R. Perlman 5. Authentication methods, actual protocol and credential formats - proposals and discussion (30 min) All - led by chairs 6. Wrap up (5 min) WG Chairs Documents which will be discussed under agenda item 2 and 3 are: draft-ietf-sacred-reqs-00.txt draft-ietf-sacred-framework-00.txt For agenda item 4 and 5, attendees are recommended to read RFC 2945. Welcome to - what we believe will be - a productive meeting in San Diego! -- Magnus Magnus Nyström RSA Security