Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Srihari Raghavan (srihari)]

Hi all

First off, thanks much for all the comments and for your time.

Trying to answer comments and queries received till now in this email along 
with reference to the new revision posted here..

Thanks
Srihari

1. Fixed the text in the new revision, regarding voucher handling by MASA.

2. "Unfortunately, the result of the year+ effort to provide a way to
   incrementally extend RFC8366 has failed due to limitations in YANG.
   Under the hood, it ought to be trivial to do in the JSON or CBOR.
   RFC8366bis simply revises the module as a whole, and your extension would
   have to go into 8366bis, if it made sense."
   >>>>SRI_1: If the consensus of the WG after the review of the new version 
deems it useful to add this text to RFC8366bis, we can surely do that...<<<<

3. " Indeed letting the owner independently set security policies for the 
owner's own domain sounds useful...If we let the domain owner's security policy 
settings piggy-back on the Voucher document, so that all security policies are 
distributed via one signed document, that may be nice and simple but it's less 
flexible that having policies that the domain owner can determine fully 
independent from the MASA."
   >>>>SRI_1: Yes. The intent of this proposal is to keep it nice and simple 
via voucher extensions, but there are also other reasons like licensing and 
security gates to be opened in the device.  There are updates in the new 
version to explain this a bit more and also captured some aspects of what you 
mentioned.  I have also added text in the acknowledgement section to the fact.  
In addition, if there is sufficient interest, please consider this as an 
enthusiastic invite to be co-authors of the future versions of the draft and 
help with the direction of the same as well.<<<<

 4. " 32 is not enough bits.  Using bits is probably a failure.
   Probably you need an IANA registry of posture definitions, and it probably
   needs to have an integer per item.  There is probably need to have vendor
   extensions, probably by PEN."
   >>>>SRI_1: Yes. Increased it to 64-bit and made some changes to yang as well 
w.r.t typedef and grouping and also pointed out PEN/IANA aspects<<<<

5. " that's a entire API from Registrar to MASA which you have to design and 
document."
   >>>>SRI_1: Yes. We have not done that in this version.  We can document this 
in the next version, as needed <<<<


On 08/06/23, 2:36 PM, "Esko Dijk" mailto:esko.d...@iotconsultancy.nl>> wrote:


> I think that there are better ways to do accomplish the configuration, such
> as extending the BRSKI-EST link with new actions.


Indeed letting the owner independently set security policies for the owner's 
own domain sounds useful. Such policies could be sent by the Registrar over the 
same TLS / DTLS connection that is created for the BRSKI-EST, or for the 
standalone EST, protocol. E.g. device gets a policy update every time it gets a 
renewed LDevID. The policy data can be a voucher-like document, or a JWT, or a 
CWT, signed by the Domain CA. 


To get the policy data, the BRSKI/EST client could request it using a RESTful 
request. This has the benefit that we can define it as a building block 
independent from EST itself, while the underlying security and effort and 
standards-text of setting up the TLS connection is shared with EST. I'm 
assuming the protection provided by the TLS connection is useful and wanted in 
this case.


That said, security policies determined by the vendor (through MASA) could also 
be useful for some use cases. The vendor could enforce policies on the use of 
the Pledge for the particular target Domain/customer. E.g. enable some 
features, disable others. Currently that would be encoded in the Voucher in a 
vendor-specific way. Question is if there's a need to standardize this format? 
Or maybe have an informative document showing how to do it is sufficient. 
If we let the domain owner's security policy settings piggy-back on the Voucher 
document, so that all security policies are distributed via one signed 
document, that may be nice and simple but it's less flexible that having 
policies that the domain owner can determine fully independent from the MASA.


Esko




-Original Message-
From: Anima mailto:anima-boun...@ietf.org>> On Behalf 
Of Michael Richardson
Sent: Tuesday, May 30, 2023 18:47
To: Srihari Raghavan (srihari) mailto:srih...@cisco.com>>; 
anima@ietf.org <mailto:anima@ietf.org>; jabir Mohammed (jamohamm) 
mailto:jamoh...@cisco.com>>; Reda Haddad (rehaddad) 
mailto:rehad...@cisco.com>>; Sandesh Rao (sandeshr) 
mailto:sande...@cisco.com>>
Subject: Re: [Anima] FW: New Version Notification for 
draft-mohammed-anima-voucher-security-profile-00.txt




Srihari Raghavan (srihari) mailto:srih...@cisco.com>> wro

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Srihari Raghavan (srihari)]

Thank you Michael and Esko for the time and comments.

An 01 revision is in the works, that has changes like 64 bits and some 
corrections based on your comments.  Once uploaded, I will also add comments on 
the need for standardization as well as other aspects.

Thanks
Srihari

On 08/06/23, 2:36 PM, "Esko Dijk" mailto:esko.d...@iotconsultancy.nl>> wrote:


> I think that there are better ways to do accomplish the configuration, such
> as extending the BRSKI-EST link with new actions.


Indeed letting the owner independently set security policies for the owner's 
own domain sounds useful. Such policies could be sent by the Registrar over the 
same TLS / DTLS connection that is created for the BRSKI-EST, or for the 
standalone EST, protocol. E.g. device gets a policy update every time it gets a 
renewed LDevID. The policy data can be a voucher-like document, or a JWT, or a 
CWT, signed by the Domain CA. 


To get the policy data, the BRSKI/EST client could request it using a RESTful 
request. This has the benefit that we can define it as a building block 
independent from EST itself, while the underlying security and effort and 
standards-text of setting up the TLS connection is shared with EST. I'm 
assuming the protection provided by the TLS connection is useful and wanted in 
this case.


That said, security policies determined by the vendor (through MASA) could also 
be useful for some use cases. The vendor could enforce policies on the use of 
the Pledge for the particular target Domain/customer. E.g. enable some 
features, disable others. Currently that would be encoded in the Voucher in a 
vendor-specific way. Question is if there's a need to standardize this format? 
Or maybe have an informative document showing how to do it is sufficient. 
If we let the domain owner's security policy settings piggy-back on the Voucher 
document, so that all security policies are distributed via one signed 
document, that may be nice and simple but it's less flexible that having 
policies that the domain owner can determine fully independent from the MASA.


Esko




-Original Message-
From: Anima mailto:anima-boun...@ietf.org>> On Behalf 
Of Michael Richardson
Sent: Tuesday, May 30, 2023 18:47
To: Srihari Raghavan (srihari) mailto:srih...@cisco.com>>; 
anima@ietf.org <mailto:anima@ietf.org>; jabir Mohammed (jamohamm) 
mailto:jamoh...@cisco.com>>; Reda Haddad (rehaddad) 
mailto:rehad...@cisco.com>>; Sandesh Rao (sandeshr) 
mailto:sande...@cisco.com>>
Subject: Re: [Anima] FW: New Version Notification for 
draft-mohammed-anima-voucher-security-profile-00.txt




Srihari Raghavan (srihari) mailto:srih...@cisco.com>> wrote:
> Agreed that MASA is the signing authority and the draft is meant to
> convey that the owner can influence the choice by way of parameterized
> inputs to the MASA APIs. So, owner can be presented with a 'security
> profile selector' input via the MASA external APIs and when the owner
> provides the PDC and the selector input values, MASA can then go ahead
> and create the voucher with appropriate security profile settings
> (after verification and validation) for the device.


okay, that's a entire API from Registrar to MASA which you have to design and
document. And you mention SZTP, and it doesn't have that link.


I think that there are better ways to do accomplish the configuration, such
as extending the BRSKI-EST link with new actions.


--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*









___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Esko Dijk]

> I think that there are better ways to do accomplish the configuration, such
> as extending the BRSKI-EST link with new actions.

Indeed letting the owner independently set security policies for the owner's 
own domain sounds useful. Such policies could be sent by the Registrar over the 
same TLS / DTLS connection that is created for the BRSKI-EST, or for the 
standalone EST, protocol. E.g. device gets a policy update every time it gets a 
renewed LDevID.   The policy data can be  a voucher-like document, or a JWT, or 
a CWT, signed by the Domain CA. 

To get the policy data, the BRSKI/EST client could request it using a RESTful 
request.  This has the benefit that we can define it as a building block 
independent from EST itself, while the underlying security and effort and 
standards-text of setting up the TLS connection is shared with EST. I'm 
assuming the protection provided by the TLS connection is useful and wanted in 
this case.

That said, security policies determined by the vendor (through MASA) could also 
be useful for some use cases. The vendor could enforce policies on the use of 
the Pledge for the particular target Domain/customer. E.g. enable some 
features, disable others. Currently that would be encoded in the Voucher in a 
vendor-specific way. Question is if there's a need to standardize this format? 
Or maybe have an informative document showing how to do it is sufficient.  
If we let the domain owner's security policy settings piggy-back on the Voucher 
document, so that all security policies are distributed via one signed 
document, that may be nice and simple but it's less flexible that having 
policies that the domain owner can determine fully independent from the MASA.

Esko


-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Tuesday, May 30, 2023 18:47
To: Srihari Raghavan (srihari) ; anima@ietf.org; jabir 
Mohammed (jamohamm) ; Reda Haddad (rehaddad) 
; Sandesh Rao (sandeshr) 
Subject: Re: [Anima] FW: New Version Notification for 
draft-mohammed-anima-voucher-security-profile-00.txt


Srihari Raghavan (srihari)  wrote:
> Agreed that MASA is the signing authority and the draft is meant to
> convey that the owner can influence the choice by way of parameterized
> inputs to the MASA APIs.  So, owner can be presented with a 'security
> profile selector' input via the MASA external APIs and when the owner
> provides the PDC and the selector input values, MASA can then go ahead
> and create the voucher with appropriate security profile settings
> (after verification and validation) for the device.

okay, that's a entire API from Registrar to MASA which you have to design and
document.  And you mention SZTP, and it doesn't have that link.

I think that there are better ways to do accomplish the configuration, such
as extending the BRSKI-EST link with new actions.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Michael Richardson]

Srihari Raghavan (srihari)  wrote:
> Agreed that MASA is the signing authority and the draft is meant to
> convey that the owner can influence the choice by way of parameterized
> inputs to the MASA APIs.  So, owner can be presented with a 'security
> profile selector' input via the MASA external APIs and when the owner
> provides the PDC and the selector input values, MASA can then go ahead
> and create the voucher with appropriate security profile settings
> (after verification and validation) for the device.

okay, that's a entire API from Registrar to MASA which you have to design and
document.  And you mention SZTP, and it doesn't have that link.

I think that there are better ways to do accomplish the configuration, such
as extending the BRSKI-EST link with new actions.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Srihari Raghavan (srihari)]

Hi Michael

Thank you for your time.

Agreed that MASA is the signing authority and the draft is meant to convey that 
the owner can influence the choice by way of parameterized inputs to the MASA 
APIs.  So, owner can be presented with a 'security profile selector' input via 
the MASA external APIs and when the owner provides the PDC and the selector 
input values, MASA can then go ahead and create the voucher with appropriate 
security profile settings (after verification and validation) for the device.

Hope it clarifies and I can modify the draft text to better convey the same.

Thanks
Srihari

On 30/05/23, 9:35 PM, "Michael Richardson" mailto:m...@sandelman.ca>> wrote:




Hi, I'll read your I-D, but:


Srihari Raghavan \(srihari\) mailto:40cisco@dmarc.ietf.org>> wrote:
> 2. This allows the owner to change and
> customize the security posture of the device dynamically and securely
> and under scale. 3. This lets the owner to selectively enable or
> disable each of the underlying security parameters that make up the
> security posture of the device.


Hi, RFC8366 Vouchers are signed by the MASA, not the owner, so this doesn't
follow.


We do desperately need a configuration backup/restore mechanism that can be
audited and trusted, and this does need to be wrapped up into onboarding, but
I don't think it can be done WITHIN the voucher, which is what I'm guessing
you have done.


--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca  http://www.sandelman.ca/ 
| 
ruby on rails [





___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Michael Richardson]

In the ID, you write:

} 5. Changes to Registrar Behavior
} The Registrar is the component that authenticates the pledge, makes
} authorization decisions, and distributes vouchers. If the extensions are
} supported, the Registrar MAY process a security profile selector request from
} owner that identifies what underlying security parameters need to be enabled
} in the security-profile-selector send down to the pledge as part of these
} extensions.

1. You haven't understood how vouchers are used.  The Registrar does not
   create them.

2. Unfortunately, the result of the year+ effort to provide a way to
   incrementally extend RFC8366 has failed due to limitations in YANG.
   Under the hood, it ought to be trivial to do in the JSON or CBOR.
   RFC8366bis simply revises the module as a whole, and your extension would
   have to go into 8366bis, if it made sense.

3. 32 is not enough bits.  Using bits is probably a failure.
   Probably you need an IANA registry of posture definitions, and it probably
   needs to have an integer per item.  There is probably need to have vendor
   extensions, probably by PEN.





--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Michael Richardson]

Hi, I'll read your I-D, but:

Srihari Raghavan \(srihari\)  wrote:
> 2. This allows the owner to change and
> customize the security posture of the device dynamically and securely
> and under scale.  3. This lets the owner to selectively enable or
> disable each of the underlying security parameters that make up the
> security posture of the device.

Hi, RFC8366 Vouchers are signed by the MASA, not the owner, so this doesn't
follow.

We do desperately need a configuration backup/restore mechanism that can be
audited and trusted, and this does need to be wrapped up into onboarding, but
I don't think it can be done WITHIN the voucher, which is what I'm guessing
you have done.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Srihari Raghavan (srihari)]

Hi all

Just wanted to bring to your attention, the following Individual IETF draft, 
that we believe, best fits under the auspices of the ANIMA WG.

Requesting your time and effort to review the same and provide feedback and 
also, to see if other WG participants would be interested in working on this as 
well.

The high level summary is as follows:
==
1. This document describes an extension of the RFC8366 Voucher Artifact in 
order to support security profiles.
2. The security profile for a device can be defined as a sum collection of the 
settings of the different underlying security parameters that determine the 
overall security posture of a device.
2. This allows the owner to change and customize the security posture of the 
device dynamically and securely and under scale.  
3. This lets the owner to selectively enable or disable each of the underlying 
security parameters that make up the security posture of the device.

More details including requirements and intent are available in the ID text.

Thanks
Srihari


On 30/05/23, 1:59 PM, "internet-dra...@ietf.org 
" mailto:internet-dra...@ietf.org>> wrote:




A new version of I-D, draft-mohammed-anima-voucher-security-profile-00.txt
has been successfully submitted by Srihari Raghavan and posted to the
IETF repository.


Name: draft-mohammed-anima-voucher-security-profile
Revision: 00
Title: Security Profiles in Bootstrap Voucher Artifacts
Document date: 2023-05-30
Group: Individual Submission
Pages: 11
URL: 
https://www.ietf.org/archive/id/draft-mohammed-anima-voucher-security-profile-00.txt
 

Status: 
https://datatracker.ietf.org/doc/draft-mohammed-anima-voucher-security-profile/ 

Html: 
https://www.ietf.org/archive/id/draft-mohammed-anima-voucher-security-profile-00.html
 

Htmlized: 
https://datatracker.ietf.org/doc/html/draft-mohammed-anima-voucher-security-profile
 





Abstract:
This document describes an extension of the RFC8366 Voucher Artifact
in order to support security profiles. This allows the owner to
change and customize the security posture of the device dynamically
and securely. This lets the owner to selectively enable or disable
each of the underlying security parameters that make up the security
posture of the device.








The IETF Secretariat







___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima