Re: [secdir] Secdir review of draft-ietf-scim-use-cases
"Kepeng Li" <kepeng.lkp@alibaba-inc.com> Tue, 07 April 2015 15:40 UTC
Return-Path: <kepeng.lkp@alibaba-inc.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 0BF651B3750 for <secdir@ietfa.amsl.com>; Tue, 7 Apr 2015 08:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level:
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
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 cvbqBCxDIiQ5 for <secdir@ietfa.amsl.com>; Tue, 7 Apr 2015 08:39:56 -0700 (PDT)
Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2341B37EE for <secdir@ietf.org>; Tue, 7 Apr 2015 08:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1428420956; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=vH6K2+H3dZvrpoohFDveuFhVP3OD6J24VP5BVy1MYSw=; b=tsQA57vP/OirjeTdCACfLUkNSx62YO34yZMOv1/kc+zX3MHjYCQKHZtuzFcyKakQ5uC6BAm5ppyid0WpiP9rw34QxSZs+EbuziFT2E+eCj/Icv8Asbu44D85Xb4qXvASZGYGwzvQUbq5PBjrVg9jWrt3x1h0ShmJ21fynQsOpLU=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R471e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02010; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0;
Received: from 10.22.49.47(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Tue, 07 Apr 2015 23:35:48 +0800
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Tue, 07 Apr 2015 23:35:43 +0800
From: Kepeng Li <kepeng.lkp@alibaba-inc.com>
To: Magnus Nyström <magnusn@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-scim-use-cases@tools.ietf.org
Message-ID: <D14A1752.5013%kepeng.lkp@alibaba-inc.com>
Thread-Topic: Secdir review of draft-ietf-scim-use-cases
References: <CADajj4ZnkjwQtZPqASTHqNvzgkDn_tVJKYiJqjAKyVujZP73DA@mail.gmail.com>
In-Reply-To: <CADajj4ZnkjwQtZPqASTHqNvzgkDn_tVJKYiJqjAKyVujZP73DA@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3511294548_3671932"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/qZdnSl93EoHIWC_g6D2SBq6xYZg>
X-Mailman-Approved-At: Tue, 07 Apr 2015 08:47:50 -0700
Subject: Re: [secdir] Secdir review of draft-ietf-scim-use-cases
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, 07 Apr 2015 15:40:00 -0000
Hi Magnus, Thanks for the review. >Section 3.5: Shouldn't there also be a requirement for the secure transfer of attributes between A and B based on matters such as A trusting authentication results from B, a means to provide those authentication results securely to B, etc.? Essentially similar to what was presented in Section 3.3? OK, I propose to add the following to section 3.5 as requirements: Relying party B must be able to authenticate the end user Relying party B must be able to securely provide the authentication results to directory service A Directory service A must be able to securely provide end user’s identity information (e.g., attributes) to relying party B >Section 3.6: Similar comment as for Section 3.5. There seems to be general security requirements missing for these two scenarios? Similarly, I propose to add the following sentences to section 3.6 as requirements: Relying party B must be able to authenticate the end user Relying party B must be able to securely provide the authentication results to directory service A Directory service A must be able to securely provide end user’s changed identity information (e.g., attributes) to relying party B >Section 4: Editorial suggestion: "only authenticated entity" -> "only authenticated entities”. OK. Thanks, Kind Regards Kepeng 发件人: Magnus Nyström <magnusn@gmail.com> 日期: Monday, 6 April, 2015 9:51 am 至: "secdir@ietf.org" <secdir@ietf.org>, <draft-ietf-scim-use-cases@tools.ietf.org> 主题: Secdir review of draft-ietf-scim-use-cases 重发发件人: <magnusn@gmail.com> 重发收件人: <draft-ietf-scim-use-cases@ietf.org> 重发日期: Sun, 5 Apr 2015 18:51:14 -0700 (PDT) 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. This memo describes the "System for Cross-domain Identity Management (SCIM)." SCIM is a companion document to the SCIM Schema memo and the SCIM Protocol memo. Section 3.5: Shouldn't there also be a requirement for the secure transfer of attributes between A and B based on matters such as A trusting authentication results from B, a means to provide those authentication results securely to B, etc.? Essentially similar to what was presented in Section 3.3? Section 3.6: Similar comment as for Section 3.5. There seems to be general security requirements missing for these two scenarios? Section 4: I only glanced the Security Consideration sections referenced here, but they do seem adequate, and given that I don't see that this memo's Security Consideration section need to contain more information. Editorial suggestion: "only authenticated entity" -> "only authenticated entities". -- Magnus
- [secdir] Secdir review of draft-ietf-scim-use-cas… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-scim-use… Kepeng Li