Subject: [core] draft-sarikaya-core-sbootstrapping-01.txt

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Feb 2011 18:00:10 +0200

Hello,

I just read draft-sarikaya-core-sbootstrapping-01.txt and here are my
comments.

This I-D covers lot of aspects, such as definition of bootstrapping,
requirements, specific solutions, scenarios. Was that the intention? It was
difficult to follow the flow as somewhat the document does not lay these out
clearly and delineate them.

Maybe this is a style thing, but I think including the problem definition,
usage scenarios, requirements in one document, and presenting each solution
in a separate document is better.

The document tries to recap things like definition of basic security
terminology, how EAP and PANA works. Like a tutorial. It's best if these
were simply provided as references. Otherwise these "recapping" can be
source of unnecessary discussion and text expansion.

Abstract says: 

	From these a more generic approach is presented, which can solve the
problem for a wide range of situations.

Which solution is that?

   The phases are provisioning phase and bootstrapping phase.  

These two terms can easily be confused. Maybe the former can be replaced
with "pre-provisioning phase".

Note that some devices may not have any user interface.

I was hoping to see enumeration of bootstrapping different layers. Such as:
- bootstrapping secure network access (L2)
- bootstrapping IP layer 
- bootstrapping application-layer
etc.

   The requirements for the use of PANA as a bootsrapping protocol can
   be stated as follows:

   o  A new entity called PANA Relay Element needs to be added to the
      PANA architecture.  Behaviour of PANA Relay Element needs to be
      defined.

   o  New AVPs needed for PANA Relay Element operation for properly
      relaying messages from the client to the authenticator and vice
      versa are required to be specified.

These have nothing to do with using PANA for bootstrapping. These are
specific needs of  Zigbee IP arch due to its IP address/routing management
and security design.

   o  An extension to PANA to securely distribute keys from the PANA
      Authentication Agent to the PANA Client using AES Key Wrap with
      Padding algorithm needs to be defined.  This is needed in order to
      use PANA for group key distribution.

Overall, there are mentions of some specific solutions, but details are
lacking. This one is a good example. What "group key" is this talking about,
not clear... 

The appendix has many scenarios and their own solutions. And those solutions
stand separate from the ones in the main document. There is a disjoint
there.

Regards,

Alper

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Feb 2011 13:12:14 -0800 (PST)

Hi Alper,
  Thanks for your comments. See my replies inline.

Regards,

Behcet

> clearly and delineate them.

Well, the document was initiated by Colin as a bootstrapping document. Later on 
we took over and made it on security bootstrapping. We pushed most of 
bootstrapping text to the annexes, I think it is useful read but if WG wishes we 
can remove it.

> in a separate  document is better.

In the current Core WG charter, there is a single document for security 
bootstrapping. That's why we have all solution approaches in one document.

> source of unnecessary discussion and text  expansion.

We tried to keep the recapping to a minimum, again I believe it is a useful 
read.

> problem for a wide  range of situations.

As I mentioned above, we have reoriented the document quite drastically but 
maybe forgot to reflect it in the abstract except for the last paragraph.
Thanks for reminding, we need some revision to do in the abstract as well.

> with  "pre-provisioning phase".

Sure.

> - bootstrapping  application-layer

As I mentioned above, security bootstrapping is the focus of this document. In 
that we do cover different layers but mainly secure network access.

> specific  needs of  Zigbee IP arch due to its IP address/routing management

We can probably clarify this a bit.

> lacking. This one is a  good example. What "group key" is this talking about,

Multicast group key

> stand separate from the ones in the main document. There is a  disjoint

See above

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 2 Feb 2011 11:54:21 +0200

Hi Behcet,

> that we do cover different layers but mainly secure network access.

The charter says:

  Security, particularly keying of new Devices, is very challenging for
  these applications. The WG will work to select approaches to security
  bootstrapping which are realistic given the constraints and requirements
  of the network. To ensure that any two nodes can join together, all
  nodes must implement at least one universal bootstrapping method.

  Security can be achieved using either session security or object
  security. For both object and session security, the WG will work with
  the security area to select appropriate security framework and protocol
  as well as selecting a minimal required to implement cipher suite. CoAP
  will initially look at CMS (RFC 5652), TLS/DTLS, and EAP.

  Dec 2010 - Constrained security bootstrapping specification submitted to
IESG as PS

My question is, which one(s) of the following will be defined according to
this charter.
If there are assumptions being made for any (e.g., devices a pre-provisioned
with device certificates), what are they?

1. Pre-provisioning of devices (with cert, PSK, SIM, etc.).

2. Authenticating/authorizing the device for network access. This also
includes enabling cryptographically-secured  L2/L3 access.

3. Authenticating/authorizing the apps on the device for accessing the apps
(servers) on the network. This also includes enabling
cryptographically-secured application access (session/object security).

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 11 Feb 2011 13:36:51 +0200

Does anyone have any idea about this?

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2011 11:54 AM
> To: 'Behcet Sarikaya'; 'core'
> Subject: RE: [core] draft-sarikaya-core-sbootstrapping-01.txt
> 
> Hi Behcet,
> 
>   Dec 2010 - Constrained security bootstrapping specification submitted
> to IESG as PS
> 
> My question is, which one(s) of the following will be defined according
> to this charter.
> If there are assumptions being made for any (e.g., devices a pre-
> provisioned with device certificates), what are they?
> 
> 3. Authenticating/authorizing the apps on the device for accessing the
> apps (servers) on the network. This also includes enabling