The area director for this working group, Harald Alvestrand, discussed where we are - we have a set of specifications, some implementations and some faith that the specifications and implemenations will give us security. He also discussed where we can go - the market is asking us to stop tinkering and start shipping. The working group can either ask that the documents with identified revisions be promoted or abandon hope and close the working group. The introductory document, draft-ietf-snmpv3-intro-02.txt, has had no comments since the posting of the last ID. There were no major comments on it and no objections to forwarding it for publication as informational when the core specifications are forwarde. The coexistence document, draft-ietf-snmpv3-coex-02.txt, has been tidied up for consistency with the other documents and the SMIv2 documents. The major point of discussion was how to handle counter64s in proxies. In most v1 situations they are treated as simply not in view. In the unlikely case of proxying from a v1 manager to a v2/v3 target they currently cause a no such name error. In the given proxy case (v1 manager, v2/v3 target) both options have problems. Skipping over counter64s may require large amounts of packet exchanges if they are clustered together and it may cause problems with the relative timing for multiple objects in one messasge. The current scheme will cause managers doing walks to terminate early. One possible solution is to use a different error, such as GenErr. This would still cause the walk to terminate but the manager wouldn't think it had reached the end of the mib. Some other larger but straightforward changes were suggested but not described, they should be posted to the mailing list. It was agreed that, while it would be good to do so, this document did not have to move forward with the rest of the core set of documents. Comments for this document should be submitted by Jan 15 1999 and the counter64 question should be resolved on the mailing list. An implementation report from Wes Hardaker was provided. They have been working on a full implementation - MD5, SHA, and DES but not proxy. There are still a few known bugs outstanding and some more interoperability testing is needed. This was a non-author implementation and several clarifications were requested on the mailing list and in the meeting. The meeting clarifications are in a separate section later in the minutes. This is a freely available reference implementation and can be found at http://ucd-snmp.ucdavis.edu/snmpv3.html. Doug Maughan and some others from the IPSEC community were asked to analyze the core specifications. Their analysis may be found in draft-maughan-nsa-snmpv3-sec-00.txt, it suggests a different modularity and placement of interfaces (the ASIs) but does not affect the external behaviour. An implementation of their architecture will be attempted in 1999. Doug came by to discuss their analysis. One point of the discussion was if implementors would follow the ASIs directly or not. The ASIs are used for clarity and modularity and are not a required part of an implementation. Doug and his co-authors feel that many implementors might follow the ASIs anyway and that the security may be increased by reducing the information accessible by all modules. Some of the implementations that have been described on the mailing list do follow the ASIs and some, including many SDK vendors, don't. An open question with respect to the newly suggested modularity is how it would work with multiple access control modules. Two other points were made but not debated. The first was that the new modularity would line up better with what might happen in a sub agent scheme and the second was that to actually take advantage of such modularity the message format would need to be redone. Lastly Doug was asked, as a security type, about reports. He sided with those that feel reports might be a problem and therefore should be deferred. Another implementation report was provided by Lauren Heintz. This was also a non-author implementation and was done several months ago with the documents being updated to include their comments. They implemented MD5, SHA and DES and didn't use the ASIs. Overall they found the documents acceptable with some areas of confusion. The areas included - some mib descriptions especially the row status and when rows can be modified, row status and storage type, what security level to use for certain reports and an example in the description of pass phrases to keys being incorrect. The chair also made some general requests. One was to re-set the subject line when changing the subject of a mail message. The other was for information about publicly available test sites to be posted to the mailing list. Joe Marzot is on the team working on the implementation that Wes Hardaker described earlier. Joe discussed the areas they felt needed clarification in more detail. The working group then discussed the areas and tried to reach consensensus. In RFC2272 there are contradictory statemetns regarding whether a report should be sent when the reportable flag is zero. While several people thought it would be good to allow a manager to disable reports by setting the reportable flag to zero this was counter to the previous consensus of the working group in Munich. The consensus was to finish the changes from Munich, of which this one was missed, and that in cases where the reportable flag was inconsistent with the PDU type then the PDU type should override the reportable flag. In RFC2272 and RFC2275 the security parameters for reports are not clearly defined. The suggested fix is to not send reports with invalidly cached data. Bert (the editor) will examine the edits. The documents do not clearly describe the Denial of Service (DOS) potential inherent with reports. There was some discussion about how many other items we might need to document that would lead to DOS attacks and which docuemnts should include any such clarifications. There was vague consensus to make a small number of changes to mention the DOS possibilities but that they should not paint reports as evil as the same possibilities exist with any unauthenticated response. Two points were mentioned by Joe but not discussed by the group. In RFC2274 3.3.2, the elements of procedure indicate the caching of data which may later be found to be in error. The data include user name, security engine ID and security level. In RFC2274 3.1.1.a states that the security state reference is used in preference to formal parameters, so a zero length engine id from a probe request would cause problems. In RFC2274 sections 3.2.3.a and 3.2.3.b discuss how to handle unkown engine ids. If (a) is chosen the engine id is added, in an implementation specific way, to the LCD if (b) is chosen an unknown engine id error is returned. The document doesn't give much guidance in choosing between these two options. There was a vague consensus to add some hints for implementations to choose, but that it was an implementation question. One example was that an API might allow information to be passed into the engine to allow it to determine if it should do discovery or not. In RFC2272 the description of msgid could be clearer regarding whether separate message ids are used for retried requests. The consensus was to modify the text to use the word "SHOULD" instead of "should". There is no protocol reason that would require a "MUST" but a user should use a new id. Randy Presuhn then discussed report generation in RFC2272 and it's follow on draft-ietf-snmpv3-mpc-02.txt. In section 7.1.3.c of the RFC was unclear which security information to use, a clarfication has been added to the draft. This clarification will be kept. What should be done in section 7.2.5.d, the case where, on an incoming message, the auth flag is not set and the priv flag is set? There was some discussion about the fact that this message can only be generated by a broken implementation and that sending a report is unlikely to help clear up the problem. A general principle is of only sending reports for differences in configuration and not for broken implementations is suggested without a check on consensus. There is a consensus to change the RFC and draft to simply discard the above message. Randy proposes to add a reference to section 7.1.3 in section 7.2.6.a for fields not extracted if the decrpytion step failed. There should be no changes from the RFC or draft. In the draft the generation of a report was added for the case of an ASN.1 parse error when the reportable flag was set. This was a chagne from the RFC and was added to simplify expeimentation with new PDU or data types. The consensus was to return to the handling specified in the RFC. One suggestion is that when the community starts defining new methods, pdus or data types it should also define a mib to specify what the agent supports. The RFC was unlcear on how to handle a response or internal PDU with the reportable flag set. A clarification to process the PDU as though the reportable flag was not set was added to the draft. A summary of the proposed changes is: 1) Never generate a report in response to something whcih has been IDed as belonging to the unconfirmend class. 2) Reports may only be generated as a result of processIncomingMsg() returning an error OID/value from the security service. This item was removed as per previous discussion R1) Never generate a report in response to soemthing in which the reportableflag is zero. Russ then proposed that after the fixes for inconsistency and clarity are incorporated in the IDS they be moved forward to the IESG for publication as draft RFCs. Note that the documents must move forward as a group. Additional interoperability information will also be submitted. There was major support and no objections for this proposal. The following schedule was agreed to: Dec 18 revised text due for current IDs Jan 15 revised IDs posted to snmpv3 list Jan 15 interoperability report due Jan 15 revised text due for coexistence doc Jan 18 - Feb 1 working group last call Feb 3 IDs forwarded to IESG Feb 8-22 IETF Last Call The topic of allowing a user to be in multiple groups was raised. The chair ruled that it had been decided and, for these docs, rejected on the mailing list. 1) it would be a change in design which is not currently allowed except for show stoppers. 2) that the architecture would allow it to be added later. One member of the WG felt that a "fast one" was being pulled, that the group was an operational problem, that schedules are too aggressive and the group was not actually looking for comments. He suggested we may need new leadership to conclude this. To "pull people together, to get operational experience". In response Harald, as AD, (harald.alvestrand@maxware.no) suggested that if people don't feel comfortable with the apparent group consenssus the issue should be raised to him. If people can convince him that there are specific problems the docs won't advance, unspecific comments will be discarded. Any specific problems should be either made public on the mailing list or privately to Harald. Lastly there was a brief discussion about the dates and if there would be enough time to review the docs or if the dates could be pused back any. The critical date is Feb 25, which is the last meeting of the IESG before the next IETF meeting.