Re: [paws] New draft for PAWS protocol

[<[e-mail]>]

I agree, that section requires some rewording. I think the intention was to say that not all regulatory domains require master device authentication; but where it is required, it is a must to be performed.
I believe the MUST requirement in the reqs doc is the proper language, as the protocol has to have that capability (even if used only by some, and not all regulatory domains).

I expect the editor to come up with resolutions to the comments it receives prior to the F2F, as well as any open issues he is aware of, during the status update of the merged draft.


-          Gabor

From: ext Cuiyang [mailto:[e-mail]]
Sent: Tuesday, October 23, 2012 8:33 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [e-mail]; [e-mail]
Subject: Re: New draft for PAWS protocol

Hi, Gabor and Vincent,

Basically, the merged draft is Okay for me.
By now, one thing worth pointing out is that the master device authentication, which has been mentioned in draft-ietf-paws-problem-stmt-usecases-rqmts, as a “MUST”.

---quote--

- Sec 6.1

P.4: The protocol MUST provide the ability for the database to authenticate the master device.

O.8: The database MUST respond to an available channel list request from an authenticated and authorized device

- Sec 8 (security considerations)
Threat 1: User modifies a device to masquerade as another valid certified device
Threat 5: Unauthorized use of channels by an uncertified device

---quote--
But in the merged draft Sec 10.4, it is said that “Consequently, client authentication is not required for the PAWS protocol.”

I would like to suggest that we clarify this contradiction, such as, remove the underlying sentence; otherwise people may wonder whether we need a “MUST” capability for a “not required” feature.
Alternatively, we could change the “MUST” to “MAY” in the rqmts WG document.

BTW, the two concerns for client auth in Sec 10.4,

-          Authorization

-          Credential leakage
have been taken care of in the draft draft-wu-paws-secutity-01.

Regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies
[e-mail]<mailto:[e-mail]>

发件人: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> 代表 [e-mail]<mailto:[e-mail]>
发送时间: 2012年10月24日 5:28
收件人: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Re: [paws] New draft for PAWS protocol

There has been no response whatsoever to this mail. I am not sure what that means; is everyone ok with the draft Vince submitted, or did the wg loose interest??
I will anyway intend to ask for adoption of it as a wg document in the upcoming F2F. Therefore, if you have any issues with the draft, please send those to the list prior to the F2F meeting.

-          Gabor

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, October 03, 2012 9:36 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [paws] New draft for PAWS protocol

Ok, thanks Vince.
As a next step, I’d like to ask the WG to review it and send to the list any major problem identified with the text in this draft.
Then, I’d like to ask the WG to adopt it as a wg document.

-          Gabor


From: ext Vincent Chen [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Wednesday, October 03, 2012 8:21 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: New draft for PAWS protocol

Hi All,

We have submitted a draft for the PAWS protocol specification that represents a merge of the non-controversial portions
of the two documents presented at the Vancouver F2F. You can find it at:

http://tools.ietf.org/html/draft-vchen-paws-protocol-00

Summary of changes:
 - Be more explicit about required vs optional vs "depends on regulatory domain"
 - Describe the "Data Models" in a more hierarchical fashion and making it more clear
   where extension points are located to address regulatory differences
 - General replacement of "channel" with "frequency" or "spectrum", when
   appropriate.

This version does not include message encoding or specific error codes.

--
-vince
Vincent Chen
Google, Inc.