Subject: [sacm] FW: New Version Notification for draft-zhuang-sacm-telereq-01.txt

From: "Minpeng Qi" <[email-masked]>
Date: Fri, 21 Mar 2014 11:37:41 +0800

Hi all,
We have updated our telecommunication requirement draft in order to make it more clear. 
The main update wording is about problem statement section. We removed remediation and gave more detailed description for the other.
All your comments are welcome and valuable.

BRs,
Minpeng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2014年3月21日 19:29
收件人: Judy Zhu; Xiaojun Zhuang; Judy Zhu; Minpeng Qi; Xiaojun Zhuang; Minpeng Qi
主题: New Version Notification for draft-zhuang-sacm-telereq-01.txt

A new version of I-D, draft-zhuang-sacm-telereq-01.txt
has been successfully submitted by Minpeng Qi and posted to the
IETF repository.

Name:		draft-zhuang-sacm-telereq
Revision:	01
Title:		Telecommunication Requirement
Document date:	2014-03-20
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-zhuang-sacm-telereq-01.txt
Status:         https://datatracker.ietf.org/doc/draft-zhuang-sacm-telereq/
Htmlized:       http://tools.ietf.org/html/draft-zhuang-sacm-telereq-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-zhuang-sacm-telereq-01

Abstract:
   This memo documents describes an additional use case based on
   telecommunication scenario which is also fit for common enterprise scenario

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 21 Mar 2014 10:19:35 -0400

Minpeng & Judy,

You should be commended for integrating the
telecom requirements into the SACM work
and presumably also facilitating collaboration
with SECAM work in SA3.

best,
tony

On 2014-03-20 11:37 PM, Minpeng Qi wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

-- 
Tony Rutkowski
Yaana Technologies LLC
542 Gibraltar Dr.
Milpitas CA 95035 USA

---

From: "Minpeng Qi" <[email-masked]>
Date: Mon, 24 Mar 2014 02:12:56 +0800

Hi Tony,

Thanks for your comment. We'd like to merge it into the current SACM work. The revision version is for clarification because we had received comment that we need to make our requirement more clear.

BRs,
Minpeng

-----邮件原件-----
发件人: sacm [mailto:[email-masked]] 代表 Tony Rutkowski
发送时间: 2014年3月21日 22:20
收件人: Minpeng Qi; [email-masked]
主题: Re: [sacm] FW: New Version Notification for draft-zhuang-sacm-telereq-01.txt

Minpeng & Judy,

best,
tony

-- 
Tony Rutkowski
Yaana Technologies LLC
542 Gibraltar Dr.
Milpitas CA 95035 USA

---

From: Adam Montville <[email-masked]>
Date: Tue, 25 Mar 2014 08:50:39 -0500

Minpeng,

Thank you for your updated submission, which does make your observations a bit clearer than they were before.  In particular, I'd like to discuss the following paragraph from your draft, which I believe describes what you're looking for:
 
"For example, a device needs to ensure the secure communications with others, so a main requirement is defined as "using the safe channel to transmit data". The manufacturers could use TLS and IPsec to achieve the goals when they build up their devices. So some alternative detailed definitions should be attached after the main requirements: When the device uses TLS based mechanism to meet such requirement, the certificates should be used as the credential in TLS handshake. When the device uses IPsec instead, the pre-shared key should be used as the credential in IKEv2." -- from draft-zhuang-sacm-telereq-01.txt.

From my perspective, you're talking about taking into account abstract security controls as they would be described in a Control Framework.  In the example you provided, the framework control is "using the safe channel to transmit data."  There are many ways to meet the needs of such a framework control, and you have provided two: 1) use a TLS-based mechanism, and 2) use IPsec-based mechanism.  Each of these mechanisms should be addressed by SACM, but I do not believe that mapping these mechanisms to a more abstract security control is within the scope of our charter.

During our BoF in Atlanta (IETF 85) we presented a slide deck describing where SACM would be focused (see slide three of http://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf).  The diagram we presented had a four-layer model with Operational Risk Management at the top, followed by Information Risk Management, Control Frameworks, and Controls respectively.  The use case you've put forward ("using the safe channel to transmit data") would be most appropriately placed at the Control Framework level, whereas use of TLS and/or IPsec would be placed at the Control level.  

While SACM must ensure that the models it uses can be leveraged by the Control Framework level (i.e. a particular Control can be positively associated with a Control Framework requirement), I don't believe SACM must account for such association mechanisms.

Regards,

Adam

---

From: "Minpeng Qi" <[email-masked]>
Date: Fri, 28 Mar 2014 10:44:19 +0800

Dear Adam,

Thanks for your comment and sorry to reply late.

Our intention is to describe that a security policy guidance could be divided as two parts. The first part is more general and the second is more specific and have different options. The example is just used to describe such intention. 

Now Let me try to make another example under the condition that you consider the use of TLS could be place at the control level:
We can make such description "using TLS, the certificate should be used as the credential in TLS handshake" as a general description, the alternative detailed definition can be recognized as "if RSA is used in certificate, the length of the key should be 1024 bits" and "if ECC is used in certificate, the length of the key should be 160 bits".

What is your opinion on this example? Is it can solve your concern or will you still consider that the general description is a control framework now?

BRs,
Minpeng

-----邮件原件-----
发件人: Adam Montville [mailto:[email-masked]] 
发送时间: 2014年3月25日 21:51
收件人: Minpeng Qi
抄送: [email-masked]
主题: Re: [sacm] New Version Notification for draft-zhuang-sacm-telereq-01.txt

Minpeng,

Regards,

Adam

On Mar 20, 2014, at 10:37 PM, Minpeng Qi <[email-masked]> wrote:

> A new version of I-D, draft-zhuang-sacm-telereq-01.txt has been 
> successfully submitted by Minpeng Qi and posted to the IETF 
> repository.
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
>

---

From: Adam Montville <[email-masked]>
Date: Mon, 31 Mar 2014 12:01:21 -0500

> What is your opinion on this example? Is it can solve your concern or will you still consider that the general description is a control framework now?

Hi Minpeng, 

No worries, thanks for driving the discussion further!

From my perspective this has less to do with whether things should be “divided" and more to do with how much expressivity we have available to us.  It seems that what we want is to do something like this:

(TLS_configuration_check) AND (for all certificates (RSA/1024 OR ECC/160) )

There are probably other ways to do this, but I still don’t see that there needs to be a division.  The enterprise/operational standard is to use RSA/1024 or ECC/160 on TLS authentication certificates.  As long as we can tie these all together, we’re in good shape.  The difference is in the granularity of the expression we need to assess more than it is a division between the general and the specific.  Different organizations will operate at different levels of maturity, so some may only have (TLS_configuration) as an assessment, where others may have the more complete assessment above.

So, what I think you’re looking for is specificity of expression and extensibility inherent in the model we use.  We should be able to move from the very general TLS_configuration_check to a very specific assessment that would include TLS_configuration_check AND specific certificates with specific properties in specific locations and with specific permissions, etc.