Subject: Re: [lp-wan] WGLC on LPWAN Overview draft

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Jul 2017 19:03:49 +0100

Hi Russ,

I'm updating the draft for now as described below. I'll shoot out
version -05 soon but in the meantime these changes are visible in
the repo [1] as always.

   [1] https://github.com/sftcd/lpwan-ov

The WG have a virtual interim on Wednesday if you wanted to follow
up via voice.

On 21/06/17 22:40, Russ Housley wrote:
> Section 2.1.2 talks about three symmetric keys that are used with
> AES.  The text explains how the keys are used, but it would be
> helpful to add this to the tables: NwkSKey : 128-bit network session
> key used with AES-CMAC AppSKey : 128-bit application session key used
> with AES-CTR AppKey  : 128-bit long term application key used with
> AES-ECB

Done.

> 
> Section 2.2.2 tells us that the Packet Data Convergence Protocol
> (PDCP) provides ciphering and integrity protection.Unlike the earlier
> section, we do not learn anything about the source of the keys for
> these cryptographic operations or the modes that are used.  A quick
> look at the 3GPP document tells me that PDCP is configured by upper
> layers, which leads to more documents.  So, these answers are not
> trivial to find, but if they are known it would be useful to include
> them here.

Agreed and I can't answer that one myself. OTOH, my assumption has
always been that, for LPWAN purposes, nbIoT keying could be considered
to the same as LTE. I don't think there're differences that'd be visible
or meaningful for the WG, do you? If not, then I think it's ok to omit
that detail, as LTE is fairly well-known, even if extremely complex;-)

> 
> Section 2.3.2 does not talk about encryption, so I assume that the
> messages are always in the clear. 

IIUC confidentiality is left to applications yes and is not
supported by sigfox. I added a note making saying that.

> However, the section does talk
> about a message authentication code.  The section does not say
> anything about the source of the authentication keys or the
> authentication algorithm.  If they are known it would be useful to
> include them here.

I took a look about and didn't find details so it looks like those
aren't public as of now. I guess Juan-Carlos can correct that if
it's incorrect.

> 
> Section 2.4.2 tells us that security is based on 802.1X and 802.11i.
> Does the Wi-SUN Alliance require a particular public key algorithm
> for use with EAP-TLS? 

I added the ciphersuite detail provided by Paul to table 5.

> Does 802.11i mean that AES-CCM is used for
> encryption and integrity?

I added the CCM* info to table 5 too.

> 
> Section 4.1 observes that "cryptographic protocols such as IPsec and
> TLS, in addition to the round-trips required for secure session
> establishment, cryptographic operations can require padding and
> addition of authenticators that are problematic when considering
> LPWAN lower layers.”  However,  the Wi-SUN Alliance seems to use
> 802.1X with EAP-TLS.  This is quite different than the other three
> example LP WANs.  How does the gap analysis address this situation?

I added a note as per Paul's mail.

> 
> Nits
> 
> Section 2.1.2: s/described below../described below./ s/AEs-encrypt
> operation/AES-encrypt operation/

Thanks for the review,
Cheers,
S.

> 
>> Date: Mon, 19 Jun 2017 21:29:05 +0200 From: Alexander Pelov
>> <[email-masked]> To: [email-masked] Subject: [lp-wan] WGLC on LPWAN
>> Overview draft
>> 
>> Dear all,
>> 
>> As discussed during the last interim, we are starting a WGLC on the
>>  LPWAN Overview document:
>> 
>> https://tools.ietf.org/html/draft-ietf-lpwan-overview-04
>> 
>> 
>> There should be no issues with the document at this stage, but
>> please, DO review the document now and DO provide your comments and
>> remarks if you see any issues.
>> 
>> The WGCL will end in two weeks, on July 3rd, 2017, 23h55 CEST.
>> 
>> Best, Pascal and Alexander
> 
> _______________________________________________ lp-wan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 1 Jul 2017 16:54:09 -0400

Stephen:

It seems only one comment still needs any discussion, so I dropped the others.

> that detail, as LTE is fairly well-known, even if extremely complex;-)

I was hoping that someone on the mail list would volunteer the answers.  If we do not have anyone that knows the answers, then we cannot include them.

Russ

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 2 Jul 2017 17:04:19 +0000

On 7/1/17, 1:54 PM, "lp-wan on behalf of Russ Housley"
<[email-masked] on behalf of [email-masked]> wrote:

>I was hoping that someone on the mail list would volunteer the answers.
>If we do not have anyone that knows the answers, then we cannot include
>them.

>From my reading, the text in NBIOT section is just stating that there is
security with integrity protection in the user plane protocol stack. The
challenge with this document is that its attempts to summarize some
complex system architectures defined outside IETF and present it in few
paragraphs. This is the case with all the LPWAN protocols included in this
document and not just with NBIOT.  As long as there are pointers to all
the key specifications, it should be sufficient IMO.

It is not trivial to cover all the protocol/security aspects in sufficient
detail in few paragraphs and that may not even be needed. If I want to
understand a specific LPWAN technology in detail, I will review those
system specs and the last thing I will read is this document. I always
wondered why this document was even needed.  The document would have
carried some value if it had drawn some commonalities between various
LPWAN system architectures and made the case for standardized protocol
interfaces between network elements. So far any such attempts resulted in
folks saying a given SDO has already defined that interface. So, I view
this as a very high level document that tells me what are all the LPWAN
technologies that are out there; that may be useful for some folks and so
its fine. 

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 2 Jul 2017 17:14:46 +0000

(formatting error in my prev email.. resending thisŠ)

Sri