IEEE P1363 Teleconference minutes May 9, 2002 - 2:00 pm - 5:00 pm Teleconference Minutes (unapproved) Attendees: Dan Brown David Jablon Ari Singer Burt Kaliski Mike Brenner William Whyte Phil MacKenzie Agenda: 2:00 - 2:10: Introductions 2:10 - 3:00: P1363a ballot comment resolution 3:00 - 4:45: P1363.2 - status of submissions - review of recent submissions - other business 4:45 - 5:00: P1363.1 update. Minutes: P1363a Discussion ============== Whyte reported that 1363a had passed the letter ballot 17 for, 3 against and 4 abstentions. There were some comments that needed addressing and we discussed the issues in Minneapolis. Burt has sent around e-mails discussing some of the issues. We'd like to get these resolved as much as possible on this call so that we can move forward. Whyte turned the floor over to Kaliski to discuss P1363a. There were four primary items to discuss relating to P1363a: point compression, how security proofs are to be discussed in the draft, resolution of other ballot comments and the process for progression to standard. 1) Point compression There has been some intense discussion on the list about elliptic curve point compression. This stems from a ballot comment from Schlafly about adding a technique in order to avoid patents and perhaps improve efficiency. There was some discussion about adding a technique to perform point compression for elliptic curve points over GF(p^m). It was agreed that this would be entirely new technical material and is not necessary for this draft. The addition of the technique "DropY" would also be a very big technical change to the draft and is not necessary. Other techniques may be possible that do not require this kind of change. The group agreed that patent encumbrance is unlikely to cause RevCom to reject the draft. It appears that these changes are probably not necessary for this draft and should be deferred to another document such as P1363b (if and when it comes into existence). There was no strong support on the call to make changes to add new point compression techniques for GF(p^m) or GF(2^m). 2) Security proof treatment Schlafly had said that the discussion about security proofs is misleading and not precise about assumptions and models, etc. As was discussed at the March ad hoc meeting, the group agreed to have the editor review the document for use of phrases such as "proved secure" and change those instances to something like "the authors provided a security proof for . . . " This seems appropriate as the term "security proof" has more clearly understood connotations. Kaliski will review the document with this in mind. 3) Other ballot issues Issues from Berger: The group agreed that adding the copyright statement and other editorial changes should be accepted. Berger's comment #4 addressed automatic updating of references to standards. There was originally some concern about having the references automatically updated as there might be a break in interoperability, but it was agreed that since these other standards are not core to the public-key techniques, it is appropriate to simply reference other standards as defined by those standards bodies. Issues from Kaliski: Kaliski asked for volunteers to update references. None forthcoming, but he would welcome any assistance that could be provided. Kaliski's comment #12 addressed making changes to DL/ECIES (addressing the flaw discovered by Victor Shoup and improving consistency between block cipher and stream cipher use). There are no contentious issues here. There is a new paper from Certicom that mentions an attack on variants of ECDH that do not perform key validation. Brown will forward a paper on the attack to Kaliski. It is unclear if this paper should be referenced in P1363a or if it should be placed elsewhere since it did not come from a ballot comment. Issues from Schlafly: Raised issues about DL/ECIES and point compression (already discussed). Wants to drop RSA OAEP. There was no support within the group to remove RSA OAEP. Issues from Singer: Kaliski has requested patent letters from Certicom and relating to PV signatures and has asked if they are aware of any other patent holders. Other issues from Singer were already addressed. 4) Process for progression to standard We would like to get the draft voted on in the next month or so and get it back to IEEE and back to the ballot body. If it passes the ballot with no new significant negative comments, the draft can be passed on to RevCom for final approval. Next steps: Working group (acting as ballot resolution committee) needs to approve changes. The group should send back responses to the ballot comments and a list of changes made to the draft. The group plans on holding the following e-votes in the coming weeks. a) Changes to draft covering all non-contentious issues starting next week (including DL/ECIES) b) How to deal with the point compression issue c) How to deal with the security proof issue Since the changes to the draft are going to be very specific, we don't need to vote on the draft itself. Kaliski left the call. P1363.2 discussion ============== Whyte turned the floor over to Jablon to discuss P1363.2. Call for submissions deadline was May 6th (this has now passed). There are new submissions from Phil MacKenzie (The PAK Suite) and David Jablon (SRP-4 and Password Authentication Using Multiple Servers). Yongge Wang also sent in information that was an update to ECSRP - he noted that the only change is that he included an IP statement saying that he is not aware of any new patents on this technique. May 9th draft of P1363.2 is now online on the Integrity Sciences web site http://www.integritysciences.com/p1363/drafts. The new submissions are at http://www.integritysciences.com/p1363/submissions. These files are restricted to viewing by P1363 members with the P1363 username and password. They will eventually be copied to the IEEE P1363 web site. The list of submissions and research contributions to P1363.2 to date include the following: Jablon, 11/1996, SPEKE Wu, 8/1998, SRP MacKenzie, 8/1999, SNAPI Bellary & Rogaway, 2/2000, AuthA Katz, Ostrovsky & Yung, 2/2000 Kwon, 5/2000, AMP Jablon, 3/2001, B-SPEKE Wang, 6/2001, ECSRP Kaliski, 8/2001, multi-server methods MacKenzie, 5/2002, PAK Jablon, 5/2002, multi-server methods Jablon, 5/2002, SRP-4 Wang, 5/2002, ECSRP update The group discussed plans to figure out which techniques are going into the draft. Jablon will go with what he feels is the consensus in the next draft. After the presentations of the remaining material, the group will presumably have discussions about what changes need to be made. There is still a fair amount of work to be done even on the techniques that there is consensus about including. For IP issues, Yongge Wang has included a statement about his knowledge of IP in the updated EC-SRP submission. The chair will still need to do a call for IP when things are voted into the draft. No comments on the ECSRP document. PAK submission: The group asked MacKenzie about the patent situation and the reason for the submission. The reason for the submission is that there wasn't an official submission on this before. Made minor corrections and updates to other things that have been published are included. PAK can be thought of as a DH exchange in which the parties include the hash of the password. This draft adds discussion about making it only the hash of the password instead of the hash of the password with other inputs. This has more straightforward proofs than the previously available ones. There is also a new part to one of the protocols: the PAK-Z protocol. This makes a change that the server also stores a public key and secret key encrypted with a password. The part that authenticates the server is identical. The server also sends over the encrypted secret key and the client uses that to authenticate itself. One then proves that the credentials have been correctly obtained. MacKenzie also included the EKE protocol as an official submission. This is a completely specified version of it. Unclear if we want it to be included in the draft as it is very similar to PAK, which is a refinement or instantiation of it. IP situation - Lucent has patents and patent applications on these protocols. Password Authentication Using Multiple Servers: Slide presentation and paper are available at http://www.integritysciences.com/p1363/submissions. This paper presented at RSA 2001 updates the WETICE 2000 paper and P1363.2 submission by Ford and Kaliski. Discussed how the published version of the WETICE paper described how the methods can work without a prior server-authenticated channel, which was one of the points of the RSA 2001 paper. Claims to get better theoretical security using a password derived generator, providing more even distribution in the group, when using smaller exponents. One technique to do that uses a composite generator (from two separate generators) as shown in the {DL,EC)REDP-2 primitive in the current P1363.2 draft. This submission also includes a forgiveness protocol, which may be something to include in an appendix for P1363.2. SRP-4: This is a hybrid of SRP-3 and B-SPEKE. It uses the SPEKE technique for creating the password entangled public key. Uses a password entangled public key in both directions. Key confirmation does not have to happen in any particular order. Defined to also use other types of groups (such as ECC). Server needs to store 2 values associated with a particular user. Key validation is somewhat different than SRP-3. Discussed recent changes to P1363.2: a) Updated definitions to reflect discussions from Minneapolis. b) Several other minor editing changes included. c) A change was made to DL parameters - to accomodate the generator group element in SRP-3 having order q-1 instead of r. d) Removed password-authenticated key agreement protocols We discussed what the meaning of a "valid public key" is and the reasons and meaning of doing key validation - do we need to keep this in if it is not useful? Jablon wants it to be more explicit in the draft. Discussion about whether we want to be fully flexible in what underlying fields we allow ourselves to work in like we do in P1363a. It is necessary that GCD (k, r) must be 1 for certain methods, but it currently says that this must always be true. Should we leave this as a requirement for all DL domain parameters? No conclusion reached. The group discussed whether DL and EC domain paramters should generally be expanded to match scope of P1363a, including GF(p^m) with m > 1. The group discussed why it would be nice to have PAK-Z and EKE in the document. PAK-Z is similar to PAK-X, except that it is more general so that you can use one of a number of different signature schemes. The basic EKE protocol with only 2 messages (no key confirmation) is provably secure in the forward secrecy sense, whereas the PPK protocol does not have a proof of security in relation to forward secrecy. Also, EKE may have slightly better concrete security reductions. EKE is also older than PAK. It wasn't clear whether these are compelling reasons for including EKE or not. Review of the roadmap for P1363.2: There were a couple of submissions that Jablon was expecting that didn't come in. For instance, he thought there might be changes to SRP and AMP. If there is the potential to tweak some of the methods, we would be open to doing that. We would like to make sure that all the methods that should be included are in the draft in some form in the very near future. P1363.1 Discussion ============== Whyte gave a status update on P1363.1. We have not yet closed submissions for P1363.1. There is minor editing going on for NTRUEncrypt. Also there is work on the security considerations section. No submission yet for NTRUSign, but one is expected. Other Issues ============== There was an e-mail about the ISO work on password based public-key techniques. There was to be discussion at the Berlin meeting at SC27/WG2, but we haven't heard anything about what happened there. The submitter said he would be glad to coordinate their work with what is going on in P1363.2. May be able to get together around Crypto to discuss collaboration. There is a signature algorithm presented by Goubin called SFlash that is in the second round of NESSIE that may be submitted to P1363 even though we don't currently have a document going that would include it. We would like to have a meeting in the Boston area at the end of June. There is an ANSI X9 F1 meeting June 26-29. We hope to have a vote on inclusion of the techniques that are currently in P1363.2 at the next meeting. The meeting ended at 5:00 pm.