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