PAWS Monday July 30 15:30 Georgia A 1. Administrivia (5 min) Blue sheets, minutes taker, jabber proxy, jabber scribe? 2. WG doc status (5 min) Rechartering is done, added text to cover the reporting from master device back to database Problem statement, use cases, requirements document went through WGLC, no comments in the past 6 weeks. One comment yesterday on the list: make optional requirement to specify channel numbers. Don't want to make protocol dependent on TV bands. Gabor puts up proposed change to make channel numbers optional. PeteR: important to get MUSTs and MAYs right. MUST support frequencies and MAY see channel numbers and you have to support it, then that's fine. If the first one is a MUST the second one is MAY, if second one is just optional, first is probably not a MUST. PeteM: This change means that we might do a protocol that does not support channel numbers PeteR: ok, I will scrub document later for MUSTs and MAYs BrianR: support this, channel numbers would be nice, but frequency bands are more important. TecoBoot: the real requirement is the frequency band Gabor: no objections, we will make this change and then send up to IESG. Subir: aware of what PeteM said? PeteR: yes, as long as the content is what we agree on. 3. http://www.ietf.org/id/draft-das-paws-protocol-02.txt (Subir, 30min) Subir Submitted version -02, worked together with John and Don Protocol layers: skip Protocol Features/Functionalities WSD Initialization Exchanges regulatory info, authentication WSD Registration location information, other information Database Query / Response Channel use notification and Response WSD Validation Master device validates subtending slave devices After submitted -02, received mailing list discussion/comments Purpose of Initialization, Registration, Authentication, Data Model Lat/Long representation, use of vCard Will cover some of these WSD Initialization Assumption: have not discussed how URI of DB is discovered Assume that the channel is secure, HTTP connection is established, use server certificate First step: INIT-REQ/RESP, two reasons BrianR: keep using WSD, going back and forth between Master and Slave Subir: WSD is master, when we mean slave we say slave BrianR: WSD is being authenticated, right? Still saying have to do shared key because WSD can't do anything better? Is that true of the master? Subir: let's defer this to later slide Gabor: what Subir is saying is that if you have a shared key, this is the way to authenticate BrianR: doc is not very clear about that point Subir: two reasons Client authentication using a shared secret Exchange information Device type, serial number, regulatory id, frequency when Master WSD should query again. This info is not available at discovery time, needs to happen in-band. DB needs to know he is talking to the right entity. That's why client authentication happens. Generic process through which these functions are achieved. Gabor: want to know if there is need for this step where info is sent from the DB to the WSD. Asked on the list whether we need this, is there any objection? BrianR: if we want it, this should be a response to a requirement. I do think it is a requirement. Need to do this after discovery of the database. Needs to be a requirement, don't ask whether it should be in the protocol, ask whether it should be in the requirements. Vincent: still question the necessity for this. With FCC, there are predefined databases, not sure whether this step will be needed. Also question whether client authentication is part of the requirements. If it is not required, what is purpose of making this message a requirement? Subir: In this particular step, we are doing a couple of things. Need to exchange information in both directions. That needs to happen. If that needs to happen, then if client auth is required, it happens then. If you think that in some domain auth is not required, then you need to do the first step. Don Joslyn: why we need this: in the FCC, every 24 hours we have to go back, this would make it easier to make this a variable instead of updating a large number of devices. This is just one example. Vincent: that information comes back naturally through the spectrum response. It will have a lifetime it is valid for. BrianR: still think you need the interchange, not sure you always need it, you want the option at first connection to exchange information about who you are, what kind of device, so you don't have to repeat it. Some domains require to put it into the request. Maybe it doesn't need to be here, but maybe some other domains do need this message. Gabor: so you are in favor of this message ZhuLei: have had discussion about whether we need this message, also some questions whether registration is needed. This message is duplicating registration if its purpose is to just share information. Gabor: speaking against having this message? ZhuLei: yes, it duplicates Registration message which is used for DB to update the spectrum availability. Gabor: not sure understood exactly... ZhuLei: if we need the address of the Master to send updates, registration message can do that. Gabor: do you assume the master device is going to have all info about regulatory domain, or does it find out the information after the discovery of the regulatory domain? mic: don't mandate use of shared secret, so why have it at all? BrianR: need to separate issue of authentication from the issue of whether there is a need for exchanging information at the first connection. Do we believe we need a protocol exchange? JohnMalyar: discussion on reflector was whether Registration could be combined with this information. Initialization could be done separately, for authentication, for conveying specifics of regulatory domain, if we don't do that, we would then be hard coding that information in the device. BrianR: Do we believe that we need, have a requirement, for an exchange just after discovery? Is that a requirement? PeteR: simply ask objection question BrianR: Does anyone object? No objections BrianR: is there anyone who objects to the possibility of doing shared secret authentication? Russ: maybe. If you're saying that, for other reasons, the parties possess this shared secret, then ok. If you are saying that you want to set up a shared secret just for this, then I might have a problem. BrianR: chair or individual? Russ: as an individual. Gabor: any objection to having this info in the message exchange? BrianR: too soon to have that discussion. Subir: features later WSD Registration Provide the database with parameters such as owner/operator parameters and location information. Needs to provide this info in certain regulatory domains. This step may be required by some spectrum management authorities. This step should be done prior to getting service from the database. BrianR: as an individual, you have not sufficiently motivated why there has to be two separate messages. Why can't they be combined? JohnMalyar: no particular reason, but second message may not be required by all spectrum management regimes, there is a set of things that go with this message, since only some devices need to register, so we keep it as a separate message. No particular reason why you couldn't combine it. BrianR: Don't agree with the argument, but at least I understand it? Gabor: objections to having a separate message? BrianR: too early again. I don't think we have a requirement for a separate message. Subir: Some authorities require this message, there has to be a way to exchange that information BrianR: agree with that, personally, need an exchange between database and device that exchanges information. Registration is one of those things. Need to exchange it at particular times. Maybe there is only one exchange but what goes in it changes. Subir: agree exchange needs to happen, whether this message and init message needs to be combined BrianR: that's a protocol design opinion. My opinion is one message, variable data; you say two messages fixed data Subir: understand John's argument BrianR: yes, but as a protocol designer, I think one message is better than two. Gabor: we will come back to this later. Device Authentication Digest based on 2617 principles Yang: why do you suggest using shared secret instead of client certificates? Gabor: you have to authenticate based on what the client has Yang: this seems to rule out client cert Gabor: not necessarily Data Model Device location, Device Owner Structure in 5491 and 5139 may be fine, but there may be concerns over future compatibility Gabor: is there some input from this room as to whether we should redefine these attributes or refer? Subir: our belief is that PAWS would use less than 20% of the properties defined in vCard and smaller number of attributes used in iCal DonJoslyn: trying to keep it lightweight, there is a lot of extra baggage that comes from vCard and iCal, there is a lot to implementing those. Might be difficult. BrianR: more or less agree with iCal, probably overkill, but vCard might be ok it's not that much overhead. Would hate to come up with another way to specify a name and an address. OritLevin: information is going to be used to describe master or also slave? Subir: anything we proposed is just master device JohnMalyar: device registration is just the master. However, validation function has info about slave, but this owner info is not required. Only ID of device is required. Orit: specific info subset to describe the slave, are we going to talk about it later? Subir: we have a backup slide on the validation, but all these things are master device Gabor: any objection to using vCard? JohnM: what Brian had shared, about using the subset of vCard, is that what we are talking about? That is important to understand. BrianR: problem we face as protocol design team is that we don't know what the next regulatory regime is going to require. For any environment, there may be a defined subset, but we can't define in advance what those are going to be. Vincent: between two proposals, JSON, what's the impact of that on use of vCard or not? Don Joslyn: question: JSON was used as an example, we can support both simultaneously? PeteM: can always carry a string with XML Subir: do you believe in future, there will be subset that we can identify? BrianR: in each regulatory domain there will be a minimum, we can't say that in the protocol. PeteM: don't have to call out subset of vCard in the protocol document, you just don't implement the parts you don't want Gabor: so consensus is we will reference vCard? Subir: would like to have more discussion Gabor: going back to location attributes, can we reference 5491 and 5139? Subir: those RFCs have XML BrianR: same thing. I am familiar with 5491 and 5139, need to add antenna info, should be straightforward. Gabor: willing to reference? BrianR: one thing that is important: characteristic of 5139, civic address, is that it breaks the street into all of its components. That is more work than address line 1, address line 2. If you don't want to go through that, it might require something else. Gabor: will continue discussion of this on the list as well. Next Steps/Considerations We have received comments from several folks Channel number should be optional Device authentication should be optional Client certs should be allowed Gabor: ok, we made a few decisions, will discuss more on the mailing list. 1. Presentation on draft-wei-paws-framework-00.pdf - Peter MCCann a. Slide 2 - Comparison with draft -das, review of slide content i. Will the registration request response be used to exchange information pertaining to the regulatory data? ii. Yes, use this to exchange data as needed. iii. Do not support putting an authentication protocol, leave to lower layers. iv. Don't want to dive in detail about the security architecture. v. Assume every client must have a client cert? vi. Yes, also open to leaving authentication optional. vii. Use with PKI versus shared secret architecture. viii. Decision of the Master devices ix. Certain choices will make the deployment more difficult. x. Support both, and leave to deployments. xi. Basic problem - if using a symmetric key, key distribution is more costly, need a secure channel to distribute the shared keys. Have an easier time if have private key on the device. Find a way to validate the public part of the key, can be done out of band, don't need a secure channel. xii. What does an option for client certs mean? xiii. If need authentication, use client certs are the best option. If the group wants shared secrets, ok. xiv. If in a regulator domain where authentication xv. Don't specify a new shared secret digest algorithm. xvi. Don't believe we need a new digest. b. Slide 3 - Security Discussion i. Review of slide content. ii. Not using header field, using body of the message. iii. Additional procedures are listed. iv. Don't get to re-use HTTP digest implementation. v. Another option is to put a new algorithm type into the http headers. vi. Draft-das didn't change anything, just document use. vii. In IETF, have security expertise to tap. Don't want to start down a road that we are not going to finish. Make sure we have sustained attention from experts so that we can complete. Concern that we will be able to do this. Before we lock into positions, use expertise, ensure road leads to success. Don't settle into positions yet. viii. Security concerns with using secret keys inside of tunnels, make user not fooled into using outside of tunnel c. Slide 4 - Encoding Discussion i. XML schema versus JSON ii. XML schema is more rigorously defined iii. Chair asks for preference iv. Clarification: why is it important to choose one over the other? v. Intent is to be able to support lightweight devices, JSON is more lightweight. vi. Which is more fashionable? vii. If reference other RFCs that use HTML, easier to integrate. viii. Do we want to choose one, or allow both options? ix. Straw poll, no decision at this point. Hum for JSON - strong hum. Hum for XML - not as strong hum. x. Take as input to chairs. xi. Start with conversation about the issues with JSON. Have identified one issue (more work with XML referenced docs) d. Slide 5 - HTML usage Discussion i. Review slide content e. Slide 6 - Messages Discussion i. Review slide content. ii. Is it a problem to send additional round trip. iii. Open question about persistent TLS connection. iv. Initialization question. Don't understand extra round trip. v. Need message with digest, nonce. vi. Digest is in request. Can't compute the digest until have the nonce. vii. Need 2 round trips anyway. One with post in -das proposal. viii. If agree that there is an initial exchange. First message not authenticated from device side. ix. Confused. x. Have a TLS channel open. Need a nonce. Client sends a message to the server. Server responds with a nonce. Client responds with digest. Have an extra transaction. xi. Don't understand the "extra" xii. Need 2 exchanges with authentication, 1 without. xiii. Not using another message, just using existing messages. xiv. With shared secret, need 2 round trips. xv. With a client cert, don't know if there are 2 round trips. xvi. Chair - take to the security guys, and group needs to decide on certs only or certs and shared secrets. xvii. Chair: Continue discussion on the list. f. Questions i. Questions around message exchanges, will influence security considerations. What is conclusion? ii. Have agreed that we will do TLS exchange. iii. Does anyone have a problem having an option for mutual authentication in the TLS exchange? iv. Options are TLS for channel protection, plus option for shared secret for mutual authentication. v. For edification of chairs, questions: vi. Chair: Who has read both documents? - Many hands. vii. Chair: Is there a preference for one or the other documents as a starting point? Will identify an editor, document will change. viii. Question: this industry is in its infancy. Building infrastructure. Need clarity on IPR. Are there IPR declarations? ix. If anyone has submitted a contribution without an IPR declaration, in violation of the policy. x. No licensing declarations to date. xi. IETF chair: boilerplate says that the IPR has been posted or will be done soon. Can ask which state you are in. xii. Eric Chu Google: all contributions under royalty free license. xiii. Amer Hassan Microsoft: contributions under similar terms. xiv. Did I hear that "there will be an IPR declaration coming, and whatever we have will be royalty free"? xv. Getting into a sensitive area. If declare royalty free, then get sued. xvi. Amer Hassan, MSFT - have filed declaration that IPR related to PAWS contributions are royalty free. xvii. If folks are making disclosures, say that they are planning to make disclosures. Beyond that if everyone says "no disclosures" xviii. John Malar - SpectrumBridge - has made a disclosure, there may be IPR. Don't know about royalty free or not. xix. Rules must state document to which IPR applies. xx. Pete McCann - Huawei - In full compliance with disclosures, no further disclosures planned. xxi. Subir Das, Telcordia: In full compliance with disclosures, no further disclosures planned. xxii. Chair: das: middle strength hum, Huawei: weakest hum, Don't know: strongest hum xxiii. Chair: chairs will discuss with AD, considering plan to get an editor, start using both documents as sources for material. xxiv. Selection of the document editor and plan is decision of the chairs, will discuss on the list. xxv. Need to move forward, agreement on that. xxvi. Chair: want to start on protocol design now. In absence of a strong preference for a single document, chairs will appoint an editor. Will have list discussion to decide how to go forward with all/part of existing submissions. Want to have a draft-ietf-paws document out of this cycle. xxvii. Have made progress on the protocol. Have many similarities. Support chairs actions. xxviii. Need to finish use case document. Need to send to IESG. xxix. Chair: send comment on use cases to the list, need to finish use cases. xxx. Chair: on Requirements: send comments to the list. Want to get document done, but use cases need to get out to define the limits of the problem as soon as possible. 2. Chair: Thank you for contributions.