Re: [dtn] BPSEC and COSE

[Mehmet Adalier <[e-mail]>]

While there may be potential value in developing a separate spec/RFC for BPsec COSE context(s), please do not bind the BPsec protocol to COSE in any way. 

In my opinion, this proposed effort should not change the current draft BPsec RFC in any way.

 

mehmet

 

From: dtn <[e-mail]> on behalf of Brian Sipos <[e-mail]>
Date: Monday, June 15, 2020 at 9:42 AM
To: "Birrane, Edward J." <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [dtn] BPSEC and COSE

 

Ed,

Sounds good, I don't have the broader view of BPSEC target environments. I'll look forward to seeing the security context guidance document.

 

My initial feel would be to define:

One context for "COSE Integrity" with no parameters and a result ID for corresponding COSE structures COSE_Sign, COSE_Sign1, COSE_MAC, and COSE_MAC0.
One context for "COSE Confidentiality" with no parameters and a result ID for COSE structures COSE_Encrypt, and COSE_Encrypt0.
A simplified COSE profile to map block data into plaintext for the COSE algorithms.
A restricted set of algorithms available to use with a focus on symmetric keys and authenticating block headers, require AEAD encryption, etc.
 

I think between the definitions already in BPSEC and the framework of COSE the binding between the two should not be too complex.

From: Birrane, Edward J. <[e-mail]>
Sent: Thursday, June 11, 2020 22:08
To: Brian Sipos <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: BPSEC and COSE 

 

Brian,

 

The draft interop contexts were meant to be the minimum set of information to show that two implementations on BPSec could interoperate, with the expectation that other contexts would be defined for deployment. However, I see no harm with updating the interop contexts to be more useful. 

 

  COSE did come up in the WG discussions on BPSec and the selected path was what you describe as #1 below – there is good value in COSE (of course) and a COSE security context would cover many cases.   Tying BPSec to COSE (what you describe as #2 below) would break other use cases for no reason.

 

  If you would like to work a COSE security context we should discuss the right mapping to BPSec security results. I am currently working on policy and template information for security contexts that might inform this. I-D coming in time for a July meeting.

 

  I assume there is a July DTNWG (virtual) meeting?

 

-Ed

 

 

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

 

From: Brian Sipos <[e-mail]> 
Sent: Thursday, June 11, 2020 9:50 PM
To: [e-mail]
Cc: Birrane, Edward J. <[e-mail]>
Subject: [EXT] BPSEC and COSE

 

APL external email warning: Verify sender [e-mail] before clicking links or attachments

 

This is directed mostly at Ed, being the author of the BPSEC draft:

In reviewing use cases of BPSEC securing bundles between networks, for example internet gateways transporting bundles between sites, I ran into the fact that the current interoperability contexts [1] don't provide any parameterization of key material, etc. which would be absolutely necessary between networks.

 

I have some bit of background with COSE [2] and it seems to have some amount of existing library support, but most importantly has a number of parameterized signing and encryption algorithms [3] already specified (and others in the pipeline).

 

In looking at how COSE could be used with BPSEC, the only difference in structure that I see is that BPSEC assumes security data has a hard division between "paramters" and "results" while in COSE it's a mix of "headers" defining both parameters and results of an operation. COSE already has the concept of a "detached" payload, and already deals with CBOR encodings.

 

I see two paths for this type of integration:

Keep BPSEC as is and define a context for using COSE. Because of the COSE structure, no "parameters" would be used but each COSE top-level type (COSE_Sign, etc.) would be a "result" type. This preserves the current structure of BPSEC but complicates the processing of COSE contexts.
Request the BPSEC draft focus more on COSE as the primary mechanism for encoding security services. This would simplify BPSEC encoding at the expense of tethering it fully to COSE and any baggage that goes along with it.
Any thoughts on this topic? Is the focus on BPSEC on private networks with locally-defined, parameter-less security contexts? With the more general-purpose contexts a niche use?

If #1 is the way to go, I would start into a COSE context draft. The end goal is to use all of the good preexisting COSE algorithms and also get direct benefit of ongoing COSE work.

 

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-interop-sc-01

[2] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-22

[3] https://www.iana.org/assignments/cose/cose.xhtml#algorithms

_______________________________________________ dtn mailing list [e-mail] https://www.ietf.org/mailman/listinfo/dtn