From owner-ietf-sacred@mail.imc.org Fri Dec 1 05:20:52 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 FAA16028 for ; Fri, 1 Dec 2000 05:20:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA05678 for ietf-sacred-bks; Fri, 1 Dec 2000 01:58:54 -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 BAA05667 for ; Fri, 1 Dec 2000 01:58:52 -0800 (PST) Received: (qmail 45151 invoked from network); 1 Dec 2000 10:00:31 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 1 Dec 2000 10:00:31 -0000 Received: (qmail 28763 invoked from network); 1 Dec 2000 10:00:30 -0000 Received: from storas08.dynas.se (10.129.29.108) by spirit.dynas.se with SMTP; 1 Dec 2000 10:00:30 -0000 Date: Fri, 1 Dec 2000 10:01:12 +0000 (GMT Standard Time) From: Magnus Nystrom To: ietf-sacred@imc.org Subject: Re: Proposed agenda for SACRED in San Diego Message-ID: X-X-Sender: magnus@[172.16.1.10] 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, I should also have mentioned that for agenda item 4, it is probably helpful to read draft-perlman-strong-cred-00.txt. Apologies, -- Magnus Magnus Nystrom RSA Security From owner-ietf-sacred@mail.imc.org Fri Dec 1 06:29:42 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 GAA23632 for ; Fri, 1 Dec 2000 06:29:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA10240 for ietf-sacred-bks; Fri, 1 Dec 2000 03:02:46 -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 DAA10231 for ; Fri, 1 Dec 2000 03:02:43 -0800 (PST) Received: (qmail 45906 invoked from network); 1 Dec 2000 11:04:22 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 1 Dec 2000 11:04:22 -0000 Received: (qmail 1209 invoked from network); 1 Dec 2000 11:04:16 -0000 Received: from storas08.dynas.se (10.129.29.108) by spirit.dynas.se with SMTP; 1 Dec 2000 11:04:16 -0000 Date: Fri, 1 Dec 2000 11:04:56 +0000 (GMT Standard Time) From: Magnus Nystrom To: Mike Just cc: ietf-sacred@imc.org Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt In-Reply-To: <3A268C3C.4A098842@bpsi.net> Message-ID: X-X-Sender: magnus@[172.16.1.10] 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 DAA10234 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 DAA10240 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23632 Mike, Just a few additional remarks. On Thu, 30 Nov 2000, Dale Gustafson 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. Agreed. [...] > > - [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. Note also that it only says "must be able to..." - it does not require TLS. I agree that the memo requires some clarification in this respect however, e.g. Section 3.1.1, first item in the list should probably read something like "..., that is, when TLS is used, only cipher suites..." [...] > > - [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. Yes, but even though it is opaque for the server, it is not opaque for the client, so in order to ensure interoperability we need to mandate some credential format. Both PKCS #12 (through the extensible SecretTypes object set) and PKCS #15 (e.g. through the DataObject type) are extensible. > > - [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). Yes, I would tend to agree. > > - [Section 7, last sentence] For this reason, I think that server > > authentication needs to be required (as I've also stated above). If a client authenticating to a credential server (for the purpose of downloading its credentials) have to reveal information which can be used by an attacker to get access to the client's credentials, then I agree. As it will likely be the case that clients do reveal some information of that kind, I am inclined to strengthen the "SHOULD" to a "MUST" - but let's revisit this when the actual protocol implementation is discussed. -- Magnus > > > -----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 > > -- Magnus Magnus Nystrom RSA Security From owner-ietf-sacred@mail.imc.org Fri Dec 1 08:47:39 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 IAA06517 for ; Fri, 1 Dec 2000 08:47:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA23573 for ietf-sacred-bks; Fri, 1 Dec 2000 05:23:55 -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 FAA23567 for ; Fri, 1 Dec 2000 05:23:53 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 08:25:49 -0500 Message-ID: <3120721CA75DD411B8340090273D20B1EEC296@sottmxs06.entrust.com> From: Mike Just To: "'Magnus Nystrom'" Cc: ietf-sacred@imc.org Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt Date: Fri, 1 Dec 2000 08:24:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05B9A.12B46F80" 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_01C05B9A.12B46F80 Content-Type: text/plain; charset="iso-8859-1" Magnus, Just two comments below. Thanks for your responses. > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, December 01, 2000 6:05 AM > To: Mike Just > Cc: ietf-sacred@imc.org > Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt > <.....snip.....> > [...] > > > - [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 makethis more clear. > > Note also that it only says "must be able to..." - it does not > require TLS. I agree that the memo requires some clarification in > this respect however, e.g. Section 3.1.1, first item in the list > should probably read something like "..., that is, when TLS is used, > only cipher suites..." > [MJ] I guess that "requiring" and "being able to" aren't that different to me. Your rewording sounds fine in any case. <.....snip.....> > > > - [Section 7, last sentence] For this reason, I think that server > > > authentication needs to be required (as I've also stated above). > > If a client authenticating to a credential server (for the purpose of > downloading its credentials) have to reveal information which can be > used by an attacker to get access to the client's credentials, then I > agree. As it will likely be the case that clients do reveal some > information of that kind, I am inclined to strengthen the "SHOULD" to > a "MUST" - but let's revisit this when the actual protocol > implementation is discussed. > [MJ] I sounds like we're on the same page. My thinking was that if I were able to successfully authenticate to a server to obtain only your protected credentials and it were completely infeasible for me to obtain your credentials from these protected credentials, then there's probably no reason to have authentication to the server in the first place. I don't think this is the case, hence the requirement for server authentication. Mike J. ------_=_NextPart_001_01C05B9A.12B46F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-sacred-framework-00.txt

Magnus,

Just two comments below.  Thanks for your = responses.

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com= ]
> Sent: Friday, December 01, 2000 6:05 AM
> To: Mike Just
> Cc: ietf-sacred@imc.org
> Subject: Re: I-D = ACTION:draft-ietf-sacred-framework-00.txt
>

<.....snip.....>

> [...]
> > > - [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 makethis more clear.
>
> Note also that it only says "must be able = to..." - it does not
> require TLS. I agree that the memo requires = some clarification in
> this respect however, e.g. Section 3.1.1, first = item in the list
> should probably read something like "..., = that is, when TLS is used,
> only cipher suites..."
>

[MJ] I guess that "requiring" and = "being able to" aren't that different to me. Your rewording = sounds fine in any case.

<.....snip.....>

> > > - [Section 7, last sentence] For this = reason, I think that server
> > > authentication needs to be required = (as I've also stated above).
>
> If a client authenticating to a credential = server (for the purpose of
> downloading its credentials) have to reveal = information which can be
> used by an attacker to get access to the = client's credentials, then I
> agree. As it will likely be the case that = clients do reveal some
> information of that kind, I am inclined to = strengthen the "SHOULD" to
> a "MUST" - but let's revisit this = when the actual protocol
> implementation is discussed.
>

[MJ] I sounds like we're on the same page. My = thinking was that if I were able to successfully authenticate to a = server to obtain only your protected credentials and it were completely = infeasible for me to obtain your credentials from these protected = credentials, then there's probably no reason to have authentication to = the server in the first place. I don't think this is the case, hence = the requirement for server authentication.  

Mike J.

------_=_NextPart_001_01C05B9A.12B46F80-- From owner-ietf-sacred@mail.imc.org Fri Dec 1 08:52:53 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 IAA08795 for ; Fri, 1 Dec 2000 08:52:52 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA23589 for ietf-sacred-bks; Fri, 1 Dec 2000 05:24:05 -0800 (PST) Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23585 for ; Fri, 1 Dec 2000 05:24:04 -0800 (PST) Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 08:16:45 -0500 Message-ID: <3120721CA75DD411B8340090273D20B1EEC297@sottmxs06.entrust.com> From: Mike Just To: "'Dale Gustafson'" Cc: "'Magnus Nystrom'" , ietf-sacred@imc.org, Stephen Farrell Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt Date: Fri, 1 Dec 2000 08:24:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05B9A.1923ED50" 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_01C05B9A.1923ED50 Content-Type: text/plain; charset="iso-8859-1" Dale, Thanks for your responses. Magnus' responses answer some of my follow-ups. I have a few additional comments below. > -----Original Message----- > From: Dale Gustafson [mailto:dale.gustafson@bpsi.net] > Sent: Thursday, November 30, 2000 12:20 PM > To: Mike Just > Cc: 'Magnus Nystrom'; ietf-sacred@imc.org; Stephen Farrell > Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt > <.....snip.....> > > - [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. > [MJ] True. The administrator has no need to know or modify the authentication data. > 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. > [MJ] It might be. I'm sure it'll be clearer to me once we start discussing some more authentication methods and protocols. I was primarily thinking of security policy enforcement by the administrator in environments where only certain authentication methods might be permitted. > > - [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. > [MJ] I guess that I hadn't thought of this. It sounds a little odd to me (one credential would always have to be retrieved before obtaining some set of remaining credentials) but that's no reason to exclude it :-) > > - [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. > [MJ] I wouldn't want to preclude this model if it means requiring a user to remember two different passwords. Mike J. ------_=_NextPart_001_01C05B9A.1923ED50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-sacred-framework-00.txt

Dale,

Thanks for your responses.  Magnus' responses = answer some of my follow-ups.  I have a few additional comments = below.

> -----Original Message-----
> From: Dale Gustafson [mailto:dale.gustafson@bpsi.net]
> Sent: Thursday, November 30, 2000 12:20 = PM
> To: Mike Just
> Cc: 'Magnus Nystrom'; ietf-sacred@imc.org; = Stephen Farrell
> Subject: Re: I-D = ACTION:draft-ietf-sacred-framework-00.txt
>

<.....snip.....>

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

[MJ] True. The administrator has no need to know or = modify the authentication data.

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

[MJ] It might be. I'm sure it'll be clearer to me = once we start discussing some more authentication methods and = protocols. I was primarily thinking of security policy enforcement by = the administrator in environments where only certain authentication = methods might be permitted.

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

[MJ] I guess that I hadn't thought of this. It sounds = a little odd to me (one credential would always have to be retrieved = before obtaining some set of remaining credentials) but that's no = reason to exclude it :-) 

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

[MJ] I wouldn't want to preclude this model if it = means requiring a user to remember two different passwords.

Mike J.

------_=_NextPart_001_01C05B9A.1923ED50-- From owner-ietf-sacred@mail.imc.org Fri Dec 1 11:58: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 LAA17298 for ; Fri, 1 Dec 2000 11:58:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA08270 for ietf-sacred-bks; Fri, 1 Dec 2000 08:33:31 -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 IAA08266 for ; Fri, 1 Dec 2000 08:33:29 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Dec 2000 16:34:58 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 LAA07762; Fri, 1 Dec 2000 11:35:04 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 11:35:03 -0500 Message-ID: From: "Linn, John" To: "'Mike Just'" Cc: ietf-sacred@imc.org Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt Date: Fri, 1 Dec 2000 11:34:49 -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: Mike wrote, excerpting: > [...] > > > - [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 makethis more clear. > > Note also that it only says "must be able to..." - it does not > require TLS. I agree that the memo requires some clarification in > this respect however, e.g. Section 3.1.1, first item in the list > should probably read something like "..., that is, when TLS is used, > only cipher suites..." > [MJ] I guess that "requiring" and "being able to" aren't that different to me. Your rewording sounds fine in any case. I take the intent as requiring support for TLS in the interests of interoperability, though without mandating that it must always be active and used. More broadly, though, I believe that there's a dependency that warrants some explicit discussion. In order to validate TLS server-side authentication, it's necessary for the verifier to hold a corresponding trusted public key. Strong password schemes, in contrast, may not incur this dependency in order to establish a trusted channel to a server and therefore could enable an entity's trusted keys to be provisioned across that channel. Does/should the scope of credential download include transfer of an entity's trusted public key(s), or do we assume that they're already available as a basis for authenticating credential servers in the course of obtaining credentials? The first paragraph of draft-ietf-sacred-reqs-00.txt's Introduction refers to trusted roots as one element within credentials themselves, but I'm unsure where we currently stand on this question. --jl From owner-ietf-sacred@mail.imc.org Thu Dec 7 00:15:44 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 AAA10843 for ; Thu, 7 Dec 2000 00:15:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23594 for ietf-sacred-bks; Wed, 6 Dec 2000 20:58:29 -0800 (PST) Received: from bsd.gymparnr.sk (bsd.gymparnr.sk [195.168.176.67]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA23566 for ; Wed, 6 Dec 2000 20:58:26 -0800 (PST) From: hjghjgjh@yahoo.com Received: (qmail 16813 invoked from network); 6 Dec 2000 00:18:35 -0000 Received: from 1cust62.tnt1.los-angeles.ca.da.uu.net (HELO 1ltL44a1D?) (63.57.183.62) by bsd.gymparnr.sk with SMTP; 6 Dec 2000 00:18:35 -0000 DATE: 05 Dec 00 4:38:11 PM Message-ID: SUBJECT: 1+1=2 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Internet's Finest and Most Reliable Bulk Email Provider! Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use. We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics. Call us for a free consultation at (323)- 851- 8386 [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value! BULK EMAIL PRICES 500,000........................$375 750,000........................$562 1,200,000........................$720 1,600,000.................. ...$960 3,000,000......................$1,500 3,000,000+ ...................PLEASE CALL FOR A QUOTE Resellers welcome. We accept Visa, MasterCard and check by FAX. DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!! Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ietf-sacred@mail.imc.org Fri Dec 8 10:27: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 KAA28187 for ; Fri, 8 Dec 2000 10:27:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10113 for ietf-sacred-bks; Fri, 8 Dec 2000 07:01:28 -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 HAA10105 for ; Fri, 8 Dec 2000 07:01:25 -0800 (PST) Received: (qmail 34610 invoked from network); 8 Dec 2000 15:03:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 8 Dec 2000 15:03:40 -0000 Received: (qmail 3894 invoked from network); 8 Dec 2000 15:03:42 -0000 Received: from mnystrom-lap.d.dynas.se (172.16.13.246) by spirit.dynas.se with SMTP; 8 Dec 2000 15:03:42 -0000 Date: Fri, 8 Dec 2000 16:04:27 +0100 (W. Europe Standard Time) From: Magnus Nystrom To: "Linn, John" cc: ietf-sacred@imc.org Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt In-Reply-To: Message-ID: X-X-Sender: magnus@[172.16.1.10] 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: The intent is to include trusted public keys in the credential and not to assume they already are available. -- Magnus On Fri, 1 Dec 2000, Linn, John wrote: > Mike wrote, excerpting: > > > [...] > > > > - [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 makethis more > clear. > > > > Note also that it only says "must be able to..." - it does not > > require TLS. I agree that the memo requires some clarification in > > this respect however, e.g. Section 3.1.1, first item in the list > > should probably read something like "..., that is, when TLS is used, > > only cipher suites..." > > > > [MJ] I guess that "requiring" and "being able to" aren't that different to > me. Your rewording sounds fine in any case. > > I take the intent as requiring support for TLS in the interests of > interoperability, though without mandating that it must always be active and > used. More broadly, though, I believe that there's a dependency that > warrants some explicit discussion. In order to validate TLS server-side > authentication, it's necessary for the verifier to hold a corresponding > trusted public key. Strong password schemes, in contrast, may not incur this > dependency in order to establish a trusted channel to a server and therefore > could enable an entity's trusted keys to be provisioned across that channel. > > > Does/should the scope of credential download include transfer of an entity's > trusted public key(s), or do we assume that they're already available as a > basis for authenticating credential servers in the course of obtaining > credentials? The first paragraph of draft-ietf-sacred-reqs-00.txt's > Introduction refers to trusted roots as one element within credentials > themselves, but I'm unsure where we currently stand on this question. > > --jl > > -- Magnus Magnus Nystrom RSA Security From owner-ietf-sacred@mail.imc.org Fri Dec 8 10:58:52 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 KAA02080 for ; Fri, 8 Dec 2000 10:58:52 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA13750 for ietf-sacred-bks; Fri, 8 Dec 2000 07:32:22 -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 HAA13739 for ; Fri, 8 Dec 2000 07:32:20 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 10:34:43 -0500 Message-ID: <3120721CA75DD411B8340090273D20B1EEC2C7@sottmxs06.entrust.com> From: Mike Just To: "'Magnus Nystrom'" , "Linn, John" Cc: ietf-sacred@imc.org Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt Date: Fri, 8 Dec 2000 10:33:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0612C.3006EF30" 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_01C0612C.3006EF30 Content-Type: text/plain Unless I'm overlooking something, this seems to imply that for the initial authentication request from the client, either we're not doing server authentication (since there are no trusted keys to perform server auth with TLS), which I think is a bad idea, or we are performing server authentication, and we're doing it using a strong password based protocol. I'm not saying this is bad. It just seems to be an implication of your statement. Mike J. > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, December 08, 2000 10:04 AM > To: Linn, John > Cc: ietf-sacred@imc.org > Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt > > > The intent is to include trusted public keys in the credential > and not to assume they already are available. > > -- Magnus > > On Fri, 1 Dec 2000, Linn, John wrote: > > > Mike wrote, excerpting: > > > > > [...] > > > > > - [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 makethis more > > clear. > > > > > > Note also that it only says "must be able to..." - it does not > > > require TLS. I agree that the memo requires some clarification in > > > this respect however, e.g. Section 3.1.1, first item in the list > > > should probably read something like "..., that is, when > TLS is used, > > > only cipher suites..." > > > > > > > [MJ] I guess that "requiring" and "being able to" aren't > that different to > > me. Your rewording sounds fine in any case. > > > > I take the intent as requiring support for TLS in the interests of > > interoperability, though without mandating that it must > always be active and > > used. More broadly, though, I believe that there's a > dependency that > > warrants some explicit discussion. In order to validate > TLS server-side > > authentication, it's necessary for the verifier to hold a > corresponding > > trusted public key. Strong password schemes, in contrast, > may not incur this > > dependency in order to establish a trusted channel to a > server and therefore > > could enable an entity's trusted keys to be provisioned > across that channel. > > > > > > Does/should the scope of credential download include > transfer of an entity's > > trusted public key(s), or do we assume that they're already > available as a > > basis for authenticating credential servers in the course > of obtaining > > credentials? The first paragraph of draft-ietf-sacred-reqs-00.txt's > > Introduction refers to trusted roots as one element within > credentials > > themselves, but I'm unsure where we currently stand on this > question. > > > > --jl > > > > > > -- Magnus > Magnus Nystrom > RSA Security > > ------_=_NextPart_001_01C0612C.3006EF30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-sacred-framework-00.txt

Unless I'm overlooking something, this seems to imply = that for the initial authentication request from the client, either = we're not doing server authentication (since there are no trusted keys = to perform server auth with TLS), which I think is a bad idea, or we = are performing server authentication, and we're doing it using a strong = password based protocol. I'm not saying this is bad. It just seems to = be an implication of your statement.

Mike J.

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com= ]
> Sent: Friday, December 08, 2000 10:04 AM
> To: Linn, John
> Cc: ietf-sacred@imc.org
> Subject: RE: I-D = ACTION:draft-ietf-sacred-framework-00.txt
>
>
> The intent is to include trusted public keys in = the credential
> and not to assume they already are = available.
>
> -- Magnus
>
> On Fri, 1 Dec 2000, Linn, John wrote:
>
> > Mike wrote, excerpting:
> >
> > > [...]
> > > > > - [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 makethis more
> > clear.
> > >
> > > Note also that it only says = "must be able to..." - it does not
> > > require TLS. I agree that the memo = requires some clarification in
> > > this respect however, e.g. Section = 3.1.1, first item in the list
> > > should probably read something like = "..., that is, when
> TLS is used,
> > > only cipher suites..."
> > >
> >
> > [MJ] I guess that "requiring" = and "being able to" aren't
> that different to
> > me. Your rewording sounds fine in any = case. 
> >
> > I take the intent as requiring support for = TLS in the interests of
> > interoperability, though without mandating = that it must
> always be active and
> > used.  More broadly, though, I = believe that there's a
> dependency that
> > warrants some explicit discussion.  = In order to validate
> TLS server-side
> > authentication, it's necessary for the = verifier to hold a
> corresponding
> > trusted public key. Strong password = schemes, in contrast,
> may not incur this
> > dependency in order to establish a trusted = channel to a
> server and therefore
> > could enable an entity's trusted keys to = be provisioned
> across that channel.
> >
> > 
> > Does/should the scope of credential = download include
> transfer of an entity's
> > trusted public key(s), or do we assume = that they're already
> available as a
> > basis for authenticating credential = servers in the course
> of obtaining
> > credentials?  The first paragraph of = draft-ietf-sacred-reqs-00.txt's
> > Introduction refers to trusted roots as = one element within
> credentials
> > themselves, but I'm unsure where we = currently stand on this
> question.
> > 
> > --jl
> >
> >
>
> -- Magnus
> Magnus Nystrom
> RSA Security
>
>

------_=_NextPart_001_01C0612C.3006EF30-- From owner-ietf-sacred@mail.imc.org Fri Dec 8 11:07:59 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 LAA03692 for ; Fri, 8 Dec 2000 11:07:58 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA15669 for ietf-sacred-bks; Fri, 8 Dec 2000 07:40:42 -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 HAA15665 for ; Fri, 8 Dec 2000 07:40:39 -0800 (PST) Received: (qmail 35071 invoked from network); 8 Dec 2000 15:42:54 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 8 Dec 2000 15:42:54 -0000 Received: (qmail 5914 invoked from network); 8 Dec 2000 15:42:56 -0000 Received: from mnystrom-lap.d.dynas.se (172.16.13.246) by spirit.dynas.se with SMTP; 8 Dec 2000 15:42:56 -0000 Date: Fri, 8 Dec 2000 16:43:40 +0100 (W. Europe Standard Time) From: Magnus Nystrom To: Mike Just cc: ietf-sacred@imc.org Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt In-Reply-To: <3120721CA75DD411B8340090273D20B1EEC2C7@sottmxs06.entrust.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] 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: Yes. The problem is, I guess, that one cannot assume that keys needed to enable a server-side TLS authentication will be present at the client end. -- Magnus On Fri, 8 Dec 2000, Mike Just wrote: > Unless I'm overlooking something, this seems to imply that for the initial > authentication request from the client, either we're not doing server > authentication (since there are no trusted keys to perform server auth with > TLS), which I think is a bad idea, or we are performing server > authentication, and we're doing it using a strong password based protocol. > I'm not saying this is bad. It just seems to be an implication of your > statement. > > Mike J. > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Friday, December 08, 2000 10:04 AM > > To: Linn, John > > Cc: ietf-sacred@imc.org > > Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt > > > > > > The intent is to include trusted public keys in the credential > > and not to assume they already are available. > > > > -- Magnus > > > > On Fri, 1 Dec 2000, Linn, John wrote: > > > > > Mike wrote, excerpting: > > > > > > > [...] > > > > > > - [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 makethis more > > > clear. > > > > > > > > Note also that it only says "must be able to..." - it does not > > > > require TLS. I agree that the memo requires some clarification in > > > > this respect however, e.g. Section 3.1.1, first item in the list > > > > should probably read something like "..., that is, when > > TLS is used, > > > > only cipher suites..." > > > > > > > > > > [MJ] I guess that "requiring" and "being able to" aren't > > that different to > > > me. Your rewording sounds fine in any case. > > > > > > I take the intent as requiring support for TLS in the interests of > > > interoperability, though without mandating that it must > > always be active and > > > used. More broadly, though, I believe that there's a > > dependency that > > > warrants some explicit discussion. In order to validate > > TLS server-side > > > authentication, it's necessary for the verifier to hold a > > corresponding > > > trusted public key. Strong password schemes, in contrast, > > may not incur this > > > dependency in order to establish a trusted channel to a > > server and therefore > > > could enable an entity's trusted keys to be provisioned > > across that channel. > > > > > > > > > Does/should the scope of credential download include > > transfer of an entity's > > > trusted public key(s), or do we assume that they're already > > available as a > > > basis for authenticating credential servers in the course > > of obtaining > > > credentials? The first paragraph of draft-ietf-sacred-reqs-00.txt's > > > Introduction refers to trusted roots as one element within > > credentials > > > themselves, but I'm unsure where we currently stand on this > > question. From owner-ietf-sacred@mail.imc.org Sat Dec 9 12:32:26 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 MAA25953 for ; Sat, 9 Dec 2000 12:32:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17741 for ietf-sacred-bks; Sat, 9 Dec 2000 09:12:44 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17735; Sat, 9 Dec 2000 09:12:42 -0800 (PST) Message-Id: <200012091712.JAA17735@ns.secondary.com> From: Mail Sender To: ietf-rip-request@baynetworks.com CC: ietf-run@mailbag.cps.intel.com, ietf-sacred@imc.org, ietf-sacred-request@imc.org, ietf-secretariat@ietf.org, ietf-smime@imc.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 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: www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-sacred@mail.imc.org Mon Dec 11 18:23:16 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 SAA00441 for ; Mon, 11 Dec 2000 18:23:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08729 for ietf-sacred-bks; Mon, 11 Dec 2000 14:58:30 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08724 for ; Mon, 11 Dec 2000 14:58:29 -0800 (PST) Received: by sentry.gw.tislabs.com; id SAA25989; Mon, 11 Dec 2000 18:04:03 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma025977; Mon, 11 Dec 00 18:03:42 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id RAA29321 for ietf-sacred@imc.org; Mon, 11 Dec 2000 17:59:58 -0500 (EST) Date: Mon, 11 Dec 2000 17:59:58 -0500 (EST) From: "David M. Balenson" Message-Id: <200012112259.RAA29321@clipper.gw.tislabs.com> To: ietf-sacred@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-sacred@mail.imc.org Mon Dec 18 10:18: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 KAA09595 for ; Mon, 18 Dec 2000 10:18:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA26260 for ietf-sacred-bks; Mon, 18 Dec 2000 06:45:08 -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 GAA26254 for ; Mon, 18 Dec 2000 06:45:06 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Dec 2000 14:47:40 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 JAA17305 for ; Mon, 18 Dec 2000 09:48:12 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 09:48:12 -0500 Message-ID: From: "Linn, John" To: "'ietf-sacred@imc.org'" Subject: DRAFT minutes, SACRED WG San Diego meeting Date: Mon, 18 Dec 2000 09:47:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by sdtihq24.securid.com id JAA17305 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA26256 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 GAA26260 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09595 SACRED WG, Thursday, 14 December 2000 DRAFT minutes, collected by John Linn (RSA Laboratories). INTRODUCTION Stephen Farrell (Baltimore) opened the meeting, which was the group's first meeting as a WG. SACRED WG contact information is available on the IETF web page. Co-chair Magnus Nystrom (RSA Security) was unavailable for the meeting because of a schedule conflict. Stephen outlined the following WG goals intended between now and the next meeting: get the requirements document suitable for WG Last-Call, and issue a next-to-last draft for the framework document. Before/during/after next meeting, intended work items include candidate protocol drafts and selection of standards track protocol(s). REQUIREMENTS DRAFT Stephen led a discussion on the requirements draft (draft-ietf-sacred-reqs-00.txt), which he co-authored with Al Arsenault (Diversinet), who was not available at this meeting. The overall goal is to develop one or more solutions that allow for secure transfer of credentials from one device to another. Credentials can include private keys, trusted root keys, etc. Solutions must fit a defined protocol framework and a common set of requirements agreed to by the WG. Stephen emphasized that more active document review and discussion on the list is needed. Many attendees indicated that they had read at least one of the current drafts. It had been noted around the time of the SACRED BOF held at the Pittsburgh IETF that both credential server and direct transfer scenarios were valid. The WG charter seeks to provide solutions for both scenarios, with either one or two distinct approaches, and the requirements draft discusses their respective advantages and disadvantages. Little attention has recently been paid to the direct transfer approach; Stephen solicited proponents to contribute material in this area. Absent such contributions, it may be deferred. Specific requirements follow. Note: the requirements as recorded in these minutes are briefly paraphrased. See draft-ietf-sacred-reqs-00 for full texts. Proposed requirements on framework: * MUST support both server and direct approaches * Server and direct SHOULD use same technology as far as possible * MUST allow for protocols which support different user authentication schemes * Protocol MUST NOT depend on internal structure of any credential type of format. Regarding this requirement, Stephen believed, in response to a query from John Linn (RSA Laboratories), that it means that protocol characteristics shouldn't vary based on a credential's own protection even if some of the cryptographic layers applied within the protocol may be redundant. This continues a discussion on the list, which hasn't yet reached closure. Bob Morgan (U. Washington) interpreted the position as stating that the protocol must assume credential elements to be highly sensitive and themselves wholly unprotected. * MUST allow use of different transports A general issue was identified regarding the vulnerabilities list: should it stay? Should more items be added? General protocol requirements were identified as follows: * Transfer both to and from a device MUST be supported * Credentials MUST never be present in cleartext at any device other than the end user's. Comment: "end user device" needs clear definition. Bob Moskowitz (ICSA) commented that this is out of scope as a protocol requirement per se, but it was agreed that characteristics of the protocol shouldn't, e.g., force credentials to be stored in cleartext on the server. * Transferred credentials SHOULD be authenticated in some way * Transferred credentials MUST be integrity protected in some way * Protocol MUST support a range of crypto algorithms * Protocol MUST support various credential types and formats (e.g., X.509, PGP, PKCS #12). John Linn and Eric Rescorla (RTFM) commented that the protocol isn't "supporting" opaque objects in a strong sense, except to the extent of tagging their types. Perhaps the requirement should be restated to "allow", Stephen suggests? This could be an end entity support requirement, but not really one imposed on the protocol per se. * One mandatory to support credential format MUST be defined * One mandatory to support user authentication scheme MUST be defined * Credentials MAY be labeled with a text handle to allow the end user to select amongst a set of credentials or to name a particular credential. * Full I18N support is required. * Protocol MUST be able to support privacy (anonymity) for the client. Eric Rescorla was skeptical that this can be feasibly and comprehensively accomplished. Radia Perlman (Sun) asked whether it could be sufficient to do an anonymous Diffie-Hellman exchange before sending identity information, even though this wouldn't be secure against an active attacker? * Transferred credentials MAY incorporate timing information, e.g., a time-to-live value determining the maximum time usable following transfer/download. Credential server protocol requirements: · Downloads and uploads MUST be supported * Credentials MUST only be downloadable following user authentication. Radia Perlman asked whether a not-yet confirmed partial authentication operation would be sufficient. * MUST be possible to ensure authenticity of credential during upload * Different user devices MAY be used to upload/download/manage the same set of credentials * Credential server MUST NOT have easy access to the cleartext credentials. Comment: given prior requirements, how can any cleartext access, whether easy or not, be allowed? Phill Hallam-Baker (VeriSign) observed that this isn't appropriately framed as a protocol requirement per se, but that it is important that characteristics of the protocol not imply that cleartext storage must be required at participating peers. Steve Bellovin (AT&T Research) pointed out that there may be an operational need for some mechanism, duly authenticated and authorized, to allow override; this may imply need for an additional requirement. * Credential servers MUST be authenticated to the user for all operations except (possibly) download * MUST be possible to authenticate the credential server to user prior to download, if the user is capable of verifying the authentication * User SHOULD only have to enter a single secret * Sharing of secrets across multiple servers MUST be possible. * MUST support "away-from-home" roaming operation to remote domains, enabling domain-based location of appropriate remote credential server. Bob Morgan commented that designs should seek consistency with existing service location approaches. * Users MUST be able to manage their credentials stored on the credential server (comment: protocol must support, but users, vs. administrators, may not necessarily be permitted to perform management operations.) * Users MUST be able to retrieve a list of their credentials stored on a server, add credentials to the server, delete credentials from the server (same comment as on previous bullet) * Client-initiated authentication information change MUST be supported * User SHOULD be able to retrieve a list of access/changes to credentials * Protocol MUST support user self-enrollment * Protocol MUST NOT prevent bulk initialization of a credential server's repository. * Additional desired requirement (Charlie Kaufman (Iris)): no pre-configuration of cryptographic information on client. Eric Rescorla concurs. * * Direct transfer requirements: * SHOULD be possible to authenticate * SHOULD be possible for acceptance to be acknowledged * * Open issues: * Vulnerabilities * Robustness * Performance * Bootstrapping * Separation or not of: user authentication, credential protection, [! There was another element in this bullet, as I recall. What was it?] FRAMEWORK DRAFT Next, Dale Gustafson (Future Foundation) led a discussion on the SACRED framework draft. This document presents an abstraction of SACRED protocol, leaving open authentication and key management schemes, credential format(s), and bindings/transports. Dale's discussion: * Introduction: Credentials may be used and shared among a variety of clients, in either client-server or peer-peer exchanges. Credential format is currently open, but PKCS #12 and PKCS #15 are cited as candidates. . There is intent to support several authentication methods and credential formats, with one of each specified as mandatory. * Network Architectures: Dale presented an overview of the client-server model and possible protocol flow diagrams for operations. Three basic operations (GET, PUT, DELETE) were proposed. * Authentication methods: Candidates include username/password, OTP, strong password, and HTTP over TLS (for server authentication, or also to authenticate remote clients). Eric Rescorla pointed out that other functional requirements imply that, if TLS is used, at least server side authentication is needed. John Linn observed, following on list discussion, that this implies that a trusted root key must be held before the TLS connection is established; therefore, the trusted root key cannot be transferred as part of credentials downloaded over that connection. * * The following open issues were identified for the framework draft: * Peer-Peer protocol * Should user authentication method and data be linked to a specific credential or to a user's identity, thereby applying to all of that user's credentials? * Is the proposed set of operations sufficient? * Credential format(s) selection * Authentication method(s) selection. Charlie Kaufman observed an apparent collision among assumptions. Some participants are trying to solve the initial bootstrap operation problem, and others are assuming that existing configuration data exists and can be leveraged. He suggested that perhaps a simple protocol could be defined to obtain the trusted roots, then to take advantage of them for other operations in a subsequent phase. Stephen thought that these cases would both be handled in one protocol, and that it would ordinarily be appropriate to take advantage of configured data whenever available. Charlie asserted that a single approach wouldn't necessarily be effective and appropriate for all scenarios. Steve Bellovin thought that a 2-phase or 3-phase protocol might be needed in many cases. It was also noted that documentation of operational scenarios would provide useful clarification. PASSWORD-BASED CREDENTIALS DOWNLOAD AND PDM Next, Radia Perlman gave a presentation on desirable properties for strong password-based credentials download, drawing on work with Charlie Kaufman and Eric Rescorla. The proposal is documented in draft-perlman-strong-cred-00.txt; this is not currently cited as a SACRED WG document but can become one at a later date. Issues raised in Radia's discussion: * Why use strong password protocols? They're cheaper and more convenient than smart cards. They also avoid problems with reliance on trust anchors for server authentication, and reduce the need for users to rely on a browser's UI to indicate when connections are secured. * Mutual authentication vs. credential download protocols: Many strong password protocols have features that are unnecessary for credential download (authentication, avoidance of PW-equivalent storage at server). A protocol specifically oriented to credential download protocol can be stateless for servers. Radia cited the following as desired properties for credential download protocols: secure; unencumbered; stateless for server; low computation for server; few messages; good enough performance at client; no cryptographic configuration at client * Performance: Radia argued that server performance is the primary concern, as long as a client's performance level is acceptable for a once-per-session operation. * Since last meeting, the name PDM (Password Derived Moduli) was chosen for the proposed approach. Also, investigation clarified that protocols like SRP, which were designed for mutual authentication have various undesired properties including statefulness. The PDM technique involves the following steps: have a deterministic method to derive a safe (Sophie-Germaine) prime p from a password; store p and a user's credentials at a server; store also B and 2**B mod p; do Diffie-Hellman using 2 as base, mod p. To speed up the client side, tell the user a single character hint, which is 6 bits of p. The following results were obtained for generating safe primes on a Pentium II/400: mean values for 512-bit modulus: 8 secs without hint, .11 sec with a hint; 1024-bit modulus: 111 secs. without hint, 1.8 with hint. * Work had been undertaken with Tom Wu on a new S3P-RSA protocol with good client performance, but the approach proved to be broken. * Radia discussed several FAQs about PDM. PDM is not intended for "wimpy devices like PDAs", which ordinarily travel with a person and can therefore appropriately be configured with a strong secret for that person. The generated hint is different from a longer password because it's machine-supplied and can be forgotten without loss of access, but at the cost of some more processing time. As an additional performance enhancement, Radia considered it likely that with PDM, a Diffie-Hellman exchange can safely use a smaller modulus given the use of secret moduli; each PW guess would effectively require breaking Diffie-Hellman. It's notable that PDM requires one exponentiation operation at the server, while the best known mutual authentication protocols (SRP) require at least 2. In conclusion, she summarized that PDM is unencumbered to the authors' knowledge, offers acceptable performance at the client, and good performance at the server. Radia was asked whether PDM would just be used for download, rather than other operations. She thought this was probably the case with other, harder, operations being better performed from more richly configuration-equipped clients. In any case, though, it is necessary for users to take care in choosing and trusting the machines where their credentials become available. * In subsequent discussion about possible approaches, Radia expressed concern about multi-server approaches' operational characteristics, in terms of delay and availability impacts. With regard to TLS authentication, it was suggested that anonymous TLS could be used, with another scheme (e.g., SRP or other strong password protocol) then applied to authenticate the TLS finish message. CLOSING REMARKS In closing discussion, Stephen asked attendees whether anyone wished to write proposals for additional authentication protocols or credential formats. None were suggested. A volunteer offered to draft some material on operational scenarios. From owner-ietf-sacred@mail.imc.org Mon Dec 18 13:31:29 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 NAA12666 for ; Mon, 18 Dec 2000 13:31:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA17174 for ietf-sacred-bks; Mon, 18 Dec 2000 10:05:34 -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 KAA17170 for ; Mon, 18 Dec 2000 10:05:32 -0800 (PST) Received: by balinese.baltimore.ie; id SAA05244; Mon, 18 Dec 2000 18:08:38 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma005176; Mon, 18 Dec 00 18:08:05 GMT Received: from baltimore.ie (ip210-24.ie.baltimore.com [10.153.24.210]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA30720; Mon, 18 Dec 2000 18:10:38 GMT Message-ID: <3A3E5293.D07A65BC@baltimore.ie> Date: Mon, 18 Dec 2000 18:08:19 +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: "'ietf-sacred@imc.org'" Subject: Re: DRAFT minutes, SACRED WG San Diego meeting References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id SAA30720 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA17171 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 KAA17174 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12666 Thanks again for taking such good minutes John. If anyone has any corrections, please post them in the next two days. Stephen. "Linn, John" wrote: > > SACRED WG, Thursday, 14 December 2000 > DRAFT minutes, collected by John Linn (RSA Laboratories). > > INTRODUCTION > > Stephen Farrell (Baltimore) opened the meeting, which was the group's first > meeting as a WG. SACRED WG contact information is available on the IETF web > page. Co-chair Magnus Nystrom (RSA Security) was unavailable for the meeting > because of a schedule conflict. Stephen outlined the following WG goals > intended between now and the next meeting: get the requirements document > suitable for WG Last-Call, and issue a next-to-last draft for the framework > document. Before/during/after next meeting, intended work items include > candidate protocol drafts and selection of standards track protocol(s). > > REQUIREMENTS DRAFT > > Stephen led a discussion on the requirements draft > (draft-ietf-sacred-reqs-00.txt), which he co-authored with Al Arsenault > (Diversinet), who was not available at this meeting. The overall goal is to > develop one or more solutions that allow for secure transfer of credentials > from one device to another. Credentials can include private keys, trusted > root keys, etc. Solutions must fit a defined protocol framework and a > common set of requirements agreed to by the WG. Stephen emphasized that > more active document review and discussion on the list is needed. Many > attendees indicated that they had read at least one of the current drafts. > > It had been noted around the time of the SACRED BOF held at the Pittsburgh > IETF that both credential server and direct transfer scenarios were valid. > The WG charter seeks to provide solutions for both scenarios, with either > one or two distinct approaches, and the requirements draft discusses their > respective advantages and disadvantages. Little attention has recently been > paid to the direct transfer approach; Stephen solicited proponents to > contribute material in this area. Absent such contributions, it may be > deferred. > > Specific requirements follow. Note: the requirements as recorded in these > minutes are briefly paraphrased. See draft-ietf-sacred-reqs-00 for full > texts. > > Proposed requirements on framework: > * MUST support both server and direct approaches > * Server and direct SHOULD use same technology as far as possible > * MUST allow for protocols which support different user authentication > schemes > * Protocol MUST NOT depend on internal structure of any credential > type of format. Regarding this requirement, Stephen believed, in response to > a query from John Linn (RSA Laboratories), that it means that protocol > characteristics shouldn't vary based on a credential's own protection even > if some of the cryptographic layers applied within the protocol may be > redundant. This continues a discussion on the list, which hasn't yet > reached closure. Bob Morgan (U. Washington) interpreted the position as > stating that the protocol must assume credential elements to be highly > sensitive and themselves wholly unprotected. > * MUST allow use of different transports > > A general issue was identified regarding the vulnerabilities list: should it > stay? Should more items be added? General protocol requirements were > identified as follows: > * Transfer both to and from a device MUST be supported > * Credentials MUST never be present in cleartext at any device other > than the end user's. Comment: "end user device" needs clear definition. Bob > Moskowitz (ICSA) commented that this is out of scope as a protocol > requirement per se, but it was agreed that characteristics of the protocol > shouldn't, e.g., force credentials to be stored in cleartext on the server. > * Transferred credentials SHOULD be authenticated in some way > * Transferred credentials MUST be integrity protected in some way > * Protocol MUST support a range of crypto algorithms > * Protocol MUST support various credential types and formats (e.g., > X.509, PGP, PKCS #12). John Linn and Eric Rescorla (RTFM) commented that the > protocol isn't "supporting" opaque objects in a strong sense, except to the > extent of tagging their types. Perhaps the requirement should be restated > to "allow", Stephen suggests? This could be an end entity support > requirement, but not really one imposed on the protocol per se. > * One mandatory to support credential format MUST be defined > * One mandatory to support user authentication scheme MUST be defined > * Credentials MAY be labeled with a text handle to allow the end user > to select amongst a set of credentials or to name a particular credential. > * Full I18N support is required. > * Protocol MUST be able to support privacy (anonymity) for the client. > Eric Rescorla was skeptical that this can be feasibly and comprehensively > accomplished. Radia Perlman (Sun) asked whether it could be sufficient to > do an anonymous Diffie-Hellman exchange before sending identity information, > even though this wouldn't be secure against an active attacker? > * Transferred credentials MAY incorporate timing information, e.g., a > time-to-live value determining the maximum time usable following > transfer/download. > > Credential server protocol requirements: > · Downloads and uploads MUST be supported > * Credentials MUST only be downloadable following user authentication. > Radia Perlman asked whether a not-yet confirmed partial authentication > operation would be sufficient. > * MUST be possible to ensure authenticity of credential during upload > * Different user devices MAY be used to upload/download/manage the > same set of credentials > * Credential server MUST NOT have easy access to the cleartext > credentials. Comment: given prior requirements, how can any cleartext > access, whether easy or not, be allowed? Phill Hallam-Baker (VeriSign) > observed that this isn't appropriately framed as a protocol requirement per > se, but that it is important that characteristics of the protocol not imply > that cleartext storage must be required at participating peers. Steve > Bellovin (AT&T Research) pointed out that there may be an operational need > for some mechanism, duly authenticated and authorized, to allow override; > this may imply need for an additional requirement. > * Credential servers MUST be authenticated to the user for all > operations except (possibly) download > * MUST be possible to authenticate the credential server to user prior > to download, if the user is capable of verifying the authentication > * User SHOULD only have to enter a single secret > * Sharing of secrets across multiple servers MUST be possible. > * MUST support "away-from-home" roaming operation to remote domains, > enabling domain-based location of appropriate remote credential server. Bob > Morgan commented that designs should seek consistency with existing service > location approaches. > * Users MUST be able to manage their credentials stored on the > credential server (comment: protocol must support, but users, vs. > administrators, may not necessarily be permitted to perform management > operations.) > * Users MUST be able to retrieve a list of their credentials stored on > a server, add credentials to the server, delete credentials from the server > (same comment as on previous bullet) > * Client-initiated authentication information change MUST be supported > * User SHOULD be able to retrieve a list of access/changes to > credentials > * Protocol MUST support user self-enrollment > * Protocol MUST NOT prevent bulk initialization of a credential > server's repository. > * Additional desired requirement (Charlie Kaufman (Iris)): no > pre-configuration of cryptographic information on client. Eric Rescorla > concurs. > * > * Direct transfer requirements: > * SHOULD be possible to authenticate > * SHOULD be possible for acceptance to be acknowledged > * > * Open issues: > * Vulnerabilities > * Robustness > * Performance > * Bootstrapping > * Separation or not of: user authentication, credential protection, [! > There was another element in this bullet, as I recall. What was it?] > > FRAMEWORK DRAFT > > Next, Dale Gustafson (Future Foundation) led a discussion on the SACRED > framework draft. This document presents an abstraction of SACRED protocol, > leaving open authentication and key management schemes, credential > format(s), and bindings/transports. Dale's discussion: > * Introduction: Credentials may be used and shared among a variety of > clients, in either client-server or peer-peer exchanges. Credential format > is currently open, but PKCS #12 and PKCS #15 are cited as candidates. . > There is intent to support several authentication methods and credential > formats, with one of each specified as mandatory. > * Network Architectures: Dale presented an overview of the > client-server model and possible protocol flow diagrams for operations. > Three basic operations (GET, PUT, DELETE) were proposed. > * Authentication methods: Candidates include username/password, OTP, > strong password, and HTTP over TLS (for server authentication, or also to > authenticate remote clients). Eric Rescorla pointed out that other > functional requirements imply that, if TLS is used, at least server side > authentication is needed. John Linn observed, following on list discussion, > that this implies that a trusted root key must be held before the TLS > connection is established; therefore, the trusted root key cannot be > transferred as part of credentials downloaded over that connection. > * > * The following open issues were identified for the framework draft: > * Peer-Peer protocol > * Should user authentication method and data be linked to a specific > credential or to a user's identity, thereby applying to all of that user's > credentials? > * Is the proposed set of operations sufficient? > * Credential format(s) selection > * Authentication method(s) selection. > > Charlie Kaufman observed an apparent collision among assumptions. Some > participants are trying to solve the initial bootstrap operation problem, > and others are assuming that existing configuration data exists and can be > leveraged. He suggested that perhaps a simple protocol could be defined to > obtain the trusted roots, then to take advantage of them for other > operations in a subsequent phase. Stephen thought that these cases would > both be handled in one protocol, and that it would ordinarily be appropriate > to take advantage of configured data whenever available. Charlie asserted > that a single approach wouldn't necessarily be effective and appropriate for > all scenarios. Steve Bellovin thought that a 2-phase or 3-phase protocol > might be needed in many cases. It was also noted that documentation of > operational scenarios would provide useful clarification. > > PASSWORD-BASED CREDENTIALS DOWNLOAD AND PDM > > Next, Radia Perlman gave a presentation on desirable properties for strong > password-based credentials download, drawing on work with Charlie Kaufman > and Eric Rescorla. The proposal is documented in > draft-perlman-strong-cred-00.txt; this is not currently cited as a SACRED WG > document but can become one at a later date. Issues raised in Radia's > discussion: > > * Why use strong password protocols? They're cheaper and more > convenient than smart cards. They also avoid problems with reliance on trust > anchors for server authentication, and reduce the need for users to rely on > a browser's UI to indicate when connections are secured. > * Mutual authentication vs. credential download protocols: Many strong > password protocols have features that are unnecessary for credential > download (authentication, avoidance of PW-equivalent storage at server). A > protocol specifically oriented to credential download protocol can be > stateless for servers. Radia cited the following as desired properties for > credential download protocols: secure; unencumbered; stateless for server; > low computation for server; few messages; good enough performance at client; > no cryptographic configuration at client > * Performance: Radia argued that server performance is the primary > concern, as long as a client's performance level is acceptable for a > once-per-session operation. > * Since last meeting, the name PDM (Password Derived Moduli) was > chosen for the proposed approach. Also, investigation clarified that > protocols like SRP, which were designed for mutual authentication have > various undesired properties including statefulness. The PDM technique > involves the following steps: have a deterministic method to derive a safe > (Sophie-Germaine) prime p from a password; store p and a user's credentials > at a server; store also B and 2**B mod p; do Diffie-Hellman using 2 as base, > mod p. To speed up the client side, tell the user a single character hint, > which is 6 bits of p. The following results were obtained for generating > safe primes on a Pentium II/400: mean values for 512-bit modulus: 8 secs > without hint, .11 sec with a hint; 1024-bit modulus: 111 secs. without hint, > 1.8 with hint. > * Work had been undertaken with Tom Wu on a new S3P-RSA protocol with > good client performance, but the approach proved to be broken. > * Radia discussed several FAQs about PDM. PDM is not intended for > "wimpy devices like PDAs", which ordinarily travel with a person and can > therefore appropriately be configured with a strong secret for that person. > The generated hint is different from a longer password because it's > machine-supplied and can be forgotten without loss of access, but at the > cost of some more processing time. As an additional performance enhancement, > Radia considered it likely that with PDM, a Diffie-Hellman exchange can > safely use a smaller modulus given the use of secret moduli; each PW guess > would effectively require breaking Diffie-Hellman. It's notable that PDM > requires one exponentiation operation at the server, while the best known > mutual authentication protocols (SRP) require at least 2. In conclusion, > she summarized that PDM is unencumbered to the authors' knowledge, offers > acceptable performance at the client, and good performance at the server. > Radia was asked whether PDM would just be used for download, rather than > other operations. She thought this was probably the case with other, > harder, operations being better performed from more richly > configuration-equipped clients. In any case, though, it is necessary for > users to take care in choosing and trusting the machines where their > credentials become available. > * In subsequent discussion about possible approaches, Radia expressed > concern about multi-server approaches' operational characteristics, in terms > of delay and availability impacts. With regard to TLS authentication, it > was suggested that anonymous TLS could be used, with another scheme (e.g., > SRP or other strong password protocol) then applied to authenticate the TLS > finish message. > > CLOSING REMARKS > > In closing discussion, Stephen asked attendees whether anyone wished to > write proposals for additional authentication protocols or credential > formats. None were suggested. A volunteer offered to draft some material > on operational scenarios. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred@mail.imc.org Mon Dec 25 03:21:45 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 DAA26464 for ; Mon, 25 Dec 2000 03:21:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA25925 for ietf-sacred-bks; Mon, 25 Dec 2000 00:05:35 -0800 (PST) Received: from sem_mail.smkb.ac.il (skbb3.skb2.macam.ac.il [192.115.171.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25914; Mon, 25 Dec 2000 00:05:32 -0800 (PST) From: hj4hj6@yahoo.com Received: from 0B7Y8vq40 (1Cust34.tnt21.lax3.da.uu.net [63.28.123.34]) by sem_mail.smkb.ac.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y4M7R6B6; Thu, 21 Dec 2000 23:32:21 +0200 DATE: 21 Dec 00 1:39:22 PM Message-ID: SUBJECT: Improve your stepfamily life Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From owner-ietf-sacred@mail.imc.org Thu Dec 28 17:25:42 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 RAA20224 for ; Thu, 28 Dec 2000 17:25:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04146 for ietf-sacred-bks; Thu, 28 Dec 2000 14:06:09 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04142 for ; Thu, 28 Dec 2000 14:06:07 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01302 for ; Thu, 28 Dec 2000 14:10:05 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA06395 for ; Thu, 28 Dec 2000 17:10:05 -0500 (EST) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA04159 for ; Thu, 28 Dec 2000 17:10:05 -0500 (EST) Message-Id: <200012282210.RAA04159@bcn.East.Sun.COM> Date: Thu, 28 Dec 2000 17:10:05 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Two more thoughts about credentials download protocols To: ietf-sacred@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aNN/KvgV/DykUUflriWtkQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First thought: A correction to what I presented at the sacred WG: Tom Wu pointed out to me afterwards that the same trick we used in PDM of having the server store B, for each user, and reusing the same B in order to save an exponentiation, works also for SRP, if you were to use SRP for credentials download (but not for use for mutual authentication). He's right about that, so SRP therefore requires an expensive exponentiation and a 32-bit exponent exponentiation, whereas PDM requires 1. With the same size modulus, this makes them comparable, since a 32-bit exponentiation is negligible. However, since PDM can almost certainly be sufficiently secure with smaller moduli, then the server computation is still significantly less with PDM than with any scheme that has a well-known p. And SRP is still a 4-message protocol, whereas PDM can be 2. ******************* The second thought is about the issue someone brought up about how if you get out of sync with typing name and password, you could wind up sending your password over the wire in the clear. Charlie suggested a low-tech fix to that, which is that the password be required to contain a character which is illegal in a name. For instance, if "=" isn't legal in a name, and the user's password is "mypassword", the user could be required to type ==mypassword. And this might make a good user interface for putting in a hint. If the hint is, say, "J", then the user could either type =J=mypassword (which includes the hint), or ==mypassword (no hint) Radia