Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18

Phil Hunt <phil.hunt@yahoo.com> Tue, 05 May 2015 06:35 UTC

Return-Path: <phil.hunt@yahoo.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3EE1B2E88 for <secdir@ietfa.amsl.com>; Mon, 4 May 2015 23:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1OF0B4GzIhB for <secdir@ietfa.amsl.com>; Mon, 4 May 2015 23:35:58 -0700 (PDT)
Received: from nm23-vm0.bullet.mail.ne1.yahoo.com (nm23-vm0.bullet.mail.ne1.yahoo.com [98.138.91.57]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110691B2E85 for <secdir@ietf.org>; Mon, 4 May 2015 23:35:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430807757; bh=Ot9MGkI7lBqPoncHM4jKXr458WEHDD9MKwlvMIsZmMo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=IOg1+lx0KSrg7DiomzXU4Keyjdkec2RMJ6SHKE7eaDCEVEMC4IwX7e5iS0ULqbPhMmO6ew0jyaj/wk5QuJDT74D2bCh2yt7uWAK5xedTKcnlIxEkLFHAahUqlhsUp/hdHjU11KEqjTXk26PldWTYBMxHvtbmYfg7q6d7d7Bsqkwlzvge3WO1o6tCMg90qcAbue+FM+aWs20uXBCHOMB7Dgw3v6sce8jFdzQ06W42VRt4oeb3RgV68n5MR8f7qXhJMal6vbhTOkvvZXXJ5zv0uw0XO1ANiQiKXUdrfr+VwfoId4aGRUFdIhNFPhf0AOYb1IbpxWoy8AAU9Vo+bUZ47w==
Received: from [98.138.100.111] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 05 May 2015 06:35:57 -0000
Received: from [98.138.84.41] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 05 May 2015 06:35:57 -0000
Received: from [127.0.0.1] by smtp109.mail.ne1.yahoo.com with NNFMP; 05 May 2015 06:35:57 -0000
X-Yahoo-Newman-Id: 219295.75728.bm@smtp109.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 6Rq62V8VM1mlmA.uGKs4CsrJsj8eerdBSj9UBEuFFngq_J1 8dzNFkedXmyPjVLrpydI7eFQK3uZMRVQwi.7IPCXC9wK6kliWJfvPVFCNU12 8bkmDv1GnnCXmPAmVqXh52W.igSpznB1V9ovtbWqbuMjTtNW_ri6zUpIY9eO qp17upwFCM2kBhsmMxju4VQiIs.C6KvHmgPBrFpeXKrTWENpGii8z0IRpDv_ ev1Ey88Grl8psiDjPnQZGptgD2mpGR9bcEFw4BVzIC4811iES5MieJpj8qVV x3er8feyRgnYsFlFUJAcsQO3lHm9o7DCMvFWenBhj6W2LozEup1D_LBqtDCp hkLKDjrgUCwViMCYJ4slp.ZOS_UNyINJYprleuhPpv80KGFdLwjHsGIJmxy2 WR8l0HpPIxNjsZyWC06O5GJzPbp7iItqvlV.nxMuMTSP.HdZWiSzMqOMFNQr O3K0_wrWh2GPVik7r2UCR5XNgH5.RnWxf7VTHnWdPC96FBLb5hWR4yGHOR2s IPxS0w4CcY3hImXW1WRIr9A--
X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w--
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Phil Hunt <phil.hunt@yahoo.com>
In-Reply-To: <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com>
Date: Mon, 04 May 2015 23:35:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDB61C27-816E-41FB-8BB9-11B681D1D8E7@yahoo.com>
References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com> <53991217-3DC8-4A97-9FCC-93B632D3C878@yahoo.com> <5D457571-55CA-45D4-A9F4-9F1B8C96E6B4@cisco.com>
To: "Brian Weis (bew)" <bew@cisco.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/4uwCsL7NTe2ewqGwzdrKK9T-sy8>
X-Mailman-Approved-At: Sat, 16 May 2015 08:37:45 -0700
Cc: "draft-ietf-scim-core-schema.all@tools.ietf.org" <draft-ietf-scim-core-schema.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-scim-core-schema-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2015 06:35:59 -0000

Brian,

I think we may be talking about different things. Maybe there is some confusion on the role of provisioning vs. authentication or maybe protocol vs. storage?

If a client were to pre salt/hash a password (supposedly to protect it in transit) then the service provider and client would have to agree on a salt and hash.  This decreases security dramatically since multiple domain now have the same hashed values.  

The intent is that every service provider endpoint that gets a clear-text password, generates its own unique salted hash and stores that value.

Phil

phil.hunt@yahoo.com

> On May 4, 2015, at 12:26 PM, Brian Weis (bew) <bew@cisco.com> wrote:
> 
> Hi Phil,
> 
> On May 4, 2015, at 11:45 AM, Phil Hunt <phil.hunt@yahoo.com> wrote:
> 
>> Brian,
>> 
>> Thanks for taking time to review both the recent documents. My proposed corrections inline…
>> 
>> Phil
>> 
>> phil.hunt@yahoo.com
>> 
>>> On May 4, 2015, at 10:39 AM, Brian Weis (bew) <bew@cisco.com> wrote:
>>> 
>>> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
>>> 
>>> For the security area directions, I consider this document to be "Ready with nits”.
>>> 
>>> This document documents resources a JSON scheme for Cross-Domain Identity Management, a standard definition of attributes representing users and groups, and a set of named schemas incorporating these attributes. The goal of the document  is to make identity management in cloud based applications and services easier. This is used when identity information needs to be shared between services.
>>> 
>>> The Security Considerations (Section 9) in version 18 is reasonably clear in the first two sub-sections that there are risks to sensitive information defined in the schema, these sub-sections point to helpful text in draft-ietf-scim. It is much improved over version 17. I have a couple of comments suggesting clarification be added to the document.
>>> 
>>> Section 9.3 begins by stating the schema “defines attributes that MAY contain personally identifiable information as well as other sensitive data”. I don’t understand the “MAY”. Just about every attribute described in this document is arguably personally identifiable information (PII), since transporting PII between services seems to be the actual need for development of the schema. It seems more accurate to say “defines attributes that contain personally identifiable information as well as other sensitive data”. (Also “MAY” is intended to declare a part of the standard that is optional for an implementation, and I don’t see how that could apply here.)
>> You are right. The 2119 MAY is probably not appropriate. How about 
>> “defines attributes that are sensitive and may be considered personally identifiable information(PII).”
>> 
>> I think that inverts the emphasis getting people to realize that almost all data is likely at least sensitive. 
> 
> That’s a fine way to state it, thanks.
> 
>>> 
>>> Section 4.1.1 defines the “password” attribute as a “clear text password”. It is much safer to store and pass a salted and hashed password. Do none of the services using this schema support a method of hashing a user password to see if it matches a given hashed value ? Or could this be an option in the scheme definition? If so, it would be worth describing that here and in the Security Considerations section.
>> 
>> This may be a question of document structure.  We could copy/move the salting/hashing requirements to the schema definition. However, my thinking was the salting/hashing is not part of the protocol - thus should not be in the core spec sections. My thinking was that salting/hashing is really a security consideration for the implementer since it is a practical consideration of “using" the protocol.
>> 
>> I’m not sure what you mean by “pass a salted and hashed password” (may be I am mis-reading your intent). That would seem to be something to say must not be done since it implies multiple servers having a common salt/hash.  In LDAP, even replication passes the clear text but the servers only store replica unique salted hashes.
> 
> The distinction I’m making is the difference between a  clear text password (e.g., "t1meMa$heen”) and a hashed version of the password, which although still sensitive is considered to be safer. My hope would be for the schema to represent  both forms of passwords, because it would be a significant improvement in security. If this is the case, then it would be good to describe the use of the hashed password wherever you feel makes the most sense. If this is not the case, it would be worth mentioning in Security Considerations that hashed passwords are not supported, because the omission is likely to be surprising to some readers.
> 
> Thanks,
> Brian 
> 
>> 
>>> 
>>> Brian
> 
> -- 
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: +1 408 526 4796
> Email: bew@cisco.com
>