Minutes of the February 25-26, 1998 Meeting of the Technical Advisory Committee to Develop a Federal Information Processing Standard for the Federal Key Management Infrastructure Wednesday, February 25, 1998 A quorum being present, the eighth meeting of the Committee was called to order at 9:15 a.m. by the Chair, Dr. Stephen Kent. In addition to the Chair, members present were: Joe Alexander, Josh Benaloh, Tom Cahill, Dave Carman, Santosh Chokhani, Paul Clark, Jack Edwards, Mark Etzel, Bill Franklin, Roger French, Daniel Harkins, Ken Konechy, Mike Matyas, and Joe Pato. Government liaisons in attendance were Elaine Barker, Miles Smid, Julie Lever, Diane Dunshee, Jan Manning, Clem Boyleston, Richard Sweeney, Judith Currie (a new attendee representing BXA). Also attending was Mark Bohannon of the Department of Commerce. After administrative announcements by Executive Secretary Ed Roback, Dr. Kent thanked all the members for their work efforts in the working drafts that had been provided between the meetings. After short general discussion, the Committee then heard a status report from each of the working groups. Working Group #1 (Framework) Status Report - Roger French Mr. French began by discussing the efforts from Work Group #1 meeting of February 24 which met to review the WG draft in detail. He then reviewed the WG draft components. The announcement section is virtually complete. At the last TAC meeting the introduction was divided into three sections: rationale, development of the FIPS, and overview of the FIPS itself. After much discussion, the rationale was discarded; Miles Smid and Ed Roback are to write the FIPS development paragraphs; the overall summary will be addressed when the FIPS is nearly complete. Regarding the model, Mr. French noted that Mike Matyas would brief it in detail. The functional requirements work has also progressed, thanks to the collaboration of Mike Matyas, Jan Manning, Dianne Dunshee, and Elaine Barker. Policy issues were moved into a guidance document (from the appendix). Interoperability issues would have to be tracked in the FIPS to be sure the issues identified in the WG's work were not inadvertently omitted. Working Group #2 (Security Models) Status Report - Josh Benaloh Dr. Benaloh extended thanks to Dianne Dunshee, Jan Manning and Santosh Chohkani for their efforts to clarify the security requirements. There was considerable discussion regarding whether to provide in the FIPS for a role of a System Administrator to make it possible for recovery to be selectable but not necessarily by the end user. Dr. Kent noted that in some contexts the user and the system administrator would be the same person. He asked Dr. Benaloh if a note to this effect would address the issue. In further discussion the "default-on" requirement was also raised as an issue which the TAC needed to address. Working Group #5 (Interoperability) Status Report - Paul Clark Dr. Clark began by noting that the WG had moved many of the routine interoperability requirements to other WGs. The issue of formats remains to be resolved. Should the document specify type guidelines for the standardization of formats that would be acceptable under the FIPS or specify specific formats? Support of a secure format(s) is not overly onerous. Does the government envision constraints for specifying formats? Question of how many and what constraints is the main question regarding formats. Security requirements make reference to the interaction between a requester and a KRA via a standard protocol. Working Group #8 (Documentation and Assurance) Briefing - Santosh Chokhani Dr. Santosh Chokhani reported on WG8's activities. In short, no action items remain from the earlier draft, so the current draft is as it stands at this time. Model Presentation Dr. Mike Matyas presented the new key recovery model to the TAC, covering the general model for key recovery: KRI generation function, KRI management function, and the key recovery function. The TAC then proceeded to discuss the proposed model. Dr. Matyas also spoke on the subject of key recovery block [KRB] idea and whether the group felt that this example would be one that should be included in the standard. Clarity between the use of the term 'self-escrow' was discussed and noted that it needed to be resolved and used consistently throughout the document. During the afternoon portion of the meeting the members met in meetings of Working Groups 1 and 5. After these meetings were concluded, the Committee met as a whole and discussed the outcome of the respective group meetings. No actions were taken on behalf of the TAC by the WGs. In the short briefings after the WG sessions, Mike Matyas discussed refinements to the proposed KR Model. Although no formal vote was taken, when asked, the Committee appeared to be in general agreement with the proposal. Also, the interoperability working group noted that KRR or KRA interoperability will not be addressed at this time as it is not a requirement of this effort. A minimum set of data between a KRA and a KRR will, however, be defined. The meeting was then recessed for the day at 5:20 p.m. Thursday, February 26, 1998 The meeting reconvened at 9:15 a.m. In order to facilitate progress on the drafts for TAC consideration, the morning session broke into three groups: 1) security requirements, 2) issue of taking systems and establishing correspondence to the functional models for mapping them appropriately and work on the data element definitions for KRA and KRR and 3) defining of security requirements of those exchanges. Before the Committee recessed for lunch, each group gave a short synopsis of their work efforts from the morning session. Dave Carman reported that their breakout group had mapped a few KR systems to the model and it proved robust. In response to the question, it was determined that the model should support the Royal Holloway system. The security requirements had been realigned into six functions and copies distributed. In a discussion about the TAC's timetable, Mark Bohannon stated that currently there are no plans to extend the charter of this Committee after it expires in July. There will be opportunities to work with NIST in other ways on follow-up activities. Therefore, there would only be two more TAC meetings (4/98 and 6/98). Within one to two weeks, all of the revisions that have been made to date should be sent to NIST to format it accordingly into a FIPS-like document. This product should be shipped out to the members asking for any further revisions to be sent back to NIST before the next meeting in April. In April, the TAC could conduct a very detailed review of the document. Expectation for June meeting would be to have a candidate document to take a vote on. The vote would be on the Committee's agreement of a candidate document to forward to NIST to be further developed as a FIPS. Further development of the glossary/definitions is still needed and comments should be provided to NIST on an ongoing basis. The discussion then turned to a list of issues which Dr. Benaloh had identified that required the TAC's attention. These included: 1) how the TAC will use its remaining time, 2) the default-on requirement, 3) the system administrator issue, 4) partial compliance, 5) interoperability between compliant and non-compliant systems, 6) switches for warning messages, 7) strong binding of KRA data to the user & validation requirements for KRI, 8) recoverability for KRA-KRR encrypted interactions, and 9) receiver verification. The first five issues were discussed in some detail; however, because there was not time to discuss each in detail, Dr. Benaloh stated that he would provide the TAC with a write-up of each issue shortly following the meeting. (ACTION - Dr. BENALOH) Regarding how the TAC would use its remaining time, Dr. Kent said that work would continue focusing on the model, and the security and functional requirements. Basic interoperability regarding the KRR-KRA would be finished. He would also like to see NIST aggregate the draft revised pieces (due to NIST in two weeks) into a coherent FIPS for distribution and review before the April meeting. In April the TAC would conduct a very detailed line-by-line review of the draft. He would like to go into the June meeting without the need to make changes at the meeting. To accomplish this, about two weeks following the April meeting a revision would be circulated for comment with a request that each member indicate (as in voluntary standards bodies) their intended vote (and if no, what would have to be changed to change the vote to a "yes.") On the issue of the default-on, after much discussion, it was agreed that the government liaisons had to address what it would really mean to be "default-on." Regarding the system administrator issue, the question was raised whether a switch could only be under the system administrator's control. It was pointed out that many end users are in fact their own administrators, although it was suggested that the product might have a "system administrator" mode. One way to address this issue would be for an organization to configure and distribute an approved configuration of a product in-house. The question was then posed to the government liaisons whether this would be acceptable. (ACTION - LIAISONS) There was also discussion of a three-way switch (always-on, administrative control, user control). The TAC then discussed issues regarding partial compliance. There was no clear resolution of this matter. After discussing the many issues involving interoperability, Drs. Clark and Matyas agreed to go back and define the basic requirement for a KR block. On the requirements side, the question still remains of what it means to complete a validation (i.e., that the user was using KR). The Security WG needs to more clearly examine the KR validation requirements and to check a large number of schemes against them. Dr. Kent agreed to send out a note summarizing this discussion and issues raised and to be addressed. (Action - Dr. KENT) The meeting was adjourned at 6:15 p.m. References (on file with the Secretariat) #1 - General Overview #2 - Announcement section #3 - Interoperability Section #4 - Working Group #2 section #5 - Working Group #5 section #6 - Working Group #8 section #7 - KMI Policies (appendix)