Subject: [paws] FW: comments on draft-das-paws-protocol-02.txt

From: Gerald Chouinard <[email-masked]>
Date: Tue, 24 Jul 2012 13:41:03 -0400

Cuiyang,

Below are some further comments on these multiple points from our resident
security expert in the IEEE 802.22 Working Group.

Gerald Chouinard

-----Original Message-----
From: Ranga Reddy [mailto:[email-masked]] 
Sent: Monday, 23 July, 2012 21:54
To: Gerald Chouinard
Cc: Apurva Mody; Ranga Reddy
Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt

Overall I agree with Yang Cui's points. Here are my reponses to Yang Cui's
comments:

1) It's true that the "HTTP Digest Auth" is weaker. However, the statement
about TLS being only server-side is not entirely true. A TLS transaction can
be setup so that the client and server authenticate each other (see
http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_T
LS_handshake for an example).

2) I don't have any idea of what Yang is talking about here. There is a
5-layer model PHY(1)<->MAC(2)<->Network(3)<->Transport(4)<->Application(5).
PAWS could likely be a set of protocols that runs across layers 3-5, but
most likely a Layer 3 (Network) protocol. "HTTP digest Auth" is just an
application layer, or layer (5) protocol. I don't think a layer 5 only
protocol would be sufficent. I would think a layer 3-5 or layer 3 protocol
would meet the PAWS requirements. This is assuming PAWS is built from an
existing set of IETF protocols.

3) Yang brings up a good point here, given the issue raised by comment (2).
What PAWS is doing at each layer, if it's developed to be a multi-layer
protocol, needs to be defined explicitly!

4) His initial understanding was/is slightly incorrect (see my response to
1). Mutual authentication can be done by TLS. Because of this an "HTTP
Digest Auth" is not needed.

5) Agreed in order to provided confidentiality and authentication of the
devices and data transmitted between them, as defined in the PAWS
requirements, "HTTP Digest Auth" is not sufficient and should not be used.

6) Agreed.

7) Agree with the point Yang makes, but disagree with the selection of
algorithms. HMAC and SHA-1 should be avoided if possible. Both have been
shown to have issues and can be compromised. In fact, I believe most
(current) references will show that SHA-1 has been deprecated by NIST. Any
TLS quite that can make use of SHA-2 should be used.

Of the comments, comment (3) needs to be addressed. What is being along each
step of the PAWS transaction must be defined before we can make an attempt
to secure it.

Vr,
Ranga Reddy
[email-masked]

On Jul 23, 2012, at 2:47 PM, Gerald Chouinard
<[email-masked]> wrote:

> Hi Ranga,
> 
> You may be interested in the points raised in the email below about the
use
> of HTTP/TLS for PAWS security. I believe we had it right in the 802.22
> Standard.
> 
> Gerald
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cuiyang
> Sent: Monday, 23 July, 2012 08:45
> To: [email-masked]; [email-masked]
> Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt
> 
> Hi All,
> 
> I would like to provide some comments to this draft, from a security point
> of view.
> Hope that it will be helpful.
> 
> The TLS and "HTTP Digest Auth" have been used, but seem unclear for me.
> Besides, it is not recommended to use the latter for some reasons listed
> below.
> - It is said that the HTTP/TLS protocol is deployed for mutual
> authentication. However, "HTTP digest authentication" is actually used for
> authenticating the device, which is typically weaker than normal TLS. Only
> the server side authentication is performed by TLS certificate-based
crypto
> method.
> - It appears that authentication is done in different layers, i.e., device
> is done in PAWS layer by "HTTP digest auth" and server is achieved in TLS
> layer by certificate. I do not understand why security is done in mixed
> layers?
> - It is said that confidentiality is protected in HTTPS layer, but if
> authenticating device is achieved in different layer (i.e. in PAWS layer),
> how can the device and server negotiate the session key?
> - Or, if my above understanding is wrong and mutual authentication is
indeed
> done in TLS layer, why does it need to have additional "HTTP digest auth"
in
> PAWS layer?
> - "HTTP digest auth" only provides a hash-based protection for secrets
like
> password and ID, and is known to be vulnerable to MitM (Man-in-the-Middle)
> attacks. Since according to the PAWS WG document,
> draft-ietf-paws-problem-stmt-usecases-rqmts-06, Chapter 8, threat 7, MitM
> attack should be thwarted. This draft using "HTTP digest auth" obviously
> does not satisfy the security requirement.
> - "HTTP digest auth" differs from HTTP over TLS, where the former provides
> no encryption for content, but the latter can encrypt the content by
Public
> Key crypto. Thus TLS is preferred.
> - "HTTP digest auth" does not support HMAC algorithm (so-called Keyed
Hash),
> thus it is yet a little risky to use SHA-1 to replace current MD5
algorithm,
> because NIST has not recommended to use the collision resistance of SHA-1
> (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and does not have
> such a problem.
> 
> From the above analysis, it is clear to see that the security and privacy
of
> PAWS is not straightforward and needs to be carefully investigated, for
> design and implementation.
> It is also the reason why we have submitted an independent draft for PAWS
> security, to provide a base for discussion.
> 
> BR,
> Yang
> ==================
> Yang Cui,  Ph.D.
> Huawei Technologies
> [email-masked]
> 
> 
>> -----邮件原件-----
>> 发件人: [email-masked] [mailto:[email-masked]] 代表
>> [email-masked]
>> 发送时间: 2012年7月22日 7:31
>> 收件人: [email-masked]
>> 主题: [paws] comments on draft-das-paws-protocol-02.txt
>> 
>> It would be beneficial if there were discussions on the drafts to
> submitted
>> ahead of the F2F presentations.
>> Thus, I've taken the initiative to read the draft and provide some
initial
>> comments:
>> 
>> 1. I do not understand the purpose of the initialization process and why
>> messages INT-REQ and INT-RESP are necessary. The capability exchange can
>> be done during the registration process.
>> We may even consider merging the registration process with the DB query
>> process, there doesn't seem to be any reason to have them as separate
>> messages.
>> 
>> 2. you may need a section where you map your newly defined messages to
>> existing http protocol messages. I saw that you have an example section,
> but a
>> normative section would be more desirable.
>> 
>> 3. the data model part needs some more work. The structure is not very
> clear
>> to me, and some of the attributes reference obsolete RFC.
>> Eg, RFC3825 is referenced for the longitude/latitude attributes. I think
> you
>> should be better of using an element for geo-location, with the structure
> as
>> defined in RFC5491, a separate element for the civic location, with the
>> structure as defined in RFC5139, etc.
>> Instead of the DeviceOwner object, I would use a vCard element, with the
>> structure as defined in RFC2426.
>> You may also need an iCalendar element (RFC5545) to specify the channel
>> availability time (eg, when the channel is not available for the full
> 24H).
>> Etc.
>> 
>> More comments are welcome.
>> - Gabor
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> ext Das, Subir
>> Sent: Saturday, July 14, 2012 7:36 AM
>> To: [email-masked]
>> Subject: [paws] FW: New Version Notification for
>> draft-das-paws-protocol-02.txt
>> 
>> Dear Chairs,
>> We have updated our draft and would like to request a slot in IETF-84 to
>> present it.
>> 
>> Regards,
>> _Subir
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Saturday, July 14, 2012 10:30 AM
>> To: Das, Subir
>> Cc: [email-masked]; [email-masked]
>> Subject: New Version Notification for draft-das-paws-protocol-02.txt
>> 
>> 
>> A new version of I-D, draft-das-paws-protocol-02.txt has been
successfully
>> submitted by Subir Das and posted to the IETF repository.
>> 
>> Filename:	 draft-das-paws-protocol
>> Revision:	 02
>> Title:		 Device to Database Protocol for White Space
>> Creation date:	 2012-07-14
>> WG ID:		 Individual Submission
>> Number of pages: 32
>> URL:
>> http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt
>> Status:          http://datatracker.ietf.org/doc/draft-das-paws-protocol
>> Htmlized:        http://tools.ietf.org/html/draft-das-paws-protocol-02
>> Diff:
> http://tools.ietf.org/rfcdiff?url2=draft-das-paws-protocol-02
>> 
>> Abstract:
>>   This document describes the `Protocol to Access White Space database
>>   (PAWS)' that uses HTTP/TLS as transport.  The protocol is used for
>>   retrieving the necessary TV white space information (e.g., channel,
>>   frequency, transmitted power) at a given location and time from a
>>   database that is operating under a regulatory domain.  The document
>>   includes the protocol functionalities, its elements, corresponding
>>   data model and recommends its encoding scheme.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> _______________________________________________
>> paws mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/paws
>> _______________________________________________
>> paws mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/paws
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 24 Jul 2012 11:14:31 -0700

in line below

> existing set of IETF protocols.

Ranga,  This masks a problem that is outside of the comms net but
important to the information system.  In your model, diff between layer
4 and 5.
	TLS (or any other transport layer security measure) has scope from TCP
socket to TCP socket.  The rest of the operating system on each end is
outside of this security scope.  So the data is unprotected once it is
on the OS side of the TCP socket.  
	Application security measures (e-mail sign/crypt is an example) secure
the data rather than the connection.  This allows the data to remain
secured through the operating system except in the part where it is
actually used/read/generated.  
	
vis PAWS, there don't seem to be any inhibitions to using application
layer security measures which allow placing most of the OS outside the
necessary security perimeter.