UNIVERSITE LIBRE DE BRUXELLES

FACULTE DES SCIENCES

SERVICE TELEMATIQUE ET COMMUNICATION

Report on 51st IETF Meeting

August 5th – 10th 2001, London (UK)

Alain Jourez

Faculté des Sciences ULB - Rapport STCService Télématique et Communication 01-10CP 230 - Blvd du Triomphe décembre 2001

B-1050 Bruxelles

Report on 50th IETF MeetingAugust 5th – 10th, 2001, London (UK)

Alain Jourez, ULB/STC

1 IntroductionThis report provides a summary of the discussions held in various WGs and BoFs during the 51st IETF meeting, based on personal notes.

2 IP Security WGThis working group is chaired by Theodore T'so (MIT) and Barbara Fraser (CISCO). The meeting began with a quick overview of the various topics on the agenda.

After that the meeting went further, with a status of updates of the documents.

IPSEC MIB documents1 (Ted T’so)Those documents are ready since a long time, no specific issues nor comments were raised recently, and typos are being fixed. Those documents will be updated one last time and then be advanced to working group last call.

GSS API DOC STATUS2 (Ted T’so)A new version of this draft has just been posted. Since this draft is foreseen to be an informational RFC, and since it has been stalled for a long time, it will be advanced to working group last call immediately. Theodore T’so asked if someone was aware of an implementation, nobody answered.

MODP Diffie-Hellman groups definitions3 (Tero Kivinen, SSH Communication Security)Though the eight thousand bits group has not been proved yet, the feeling is that this document is ready. This draft will be advanced to last call anyway.

Steve Kent (BBN) presented motivations for adding IV (Initialisation vectors) in AES (Advanced Encryption Standard) counter mode. In order to facilitate high-speed implementation, IPsec will most probably adopt a counter mode with the AES. One of the advantages of counter mode over using IV is that they must not be carried along in the packet; hence they are a net gain in bandwidth. Counter mode is a valid replacement for sequence number management that avoids the problems of race condition appearing with the latter. IV generation should take place into the crypto chip. The counter to be used will at least be 32 bits, more probably 64 bits and maybe 128 bits is the right choice. Steve Bellovin (AT&T Labs) commented that counter mode used in conjunction with manual keying might lead to catastrophic scenarios. He also pointed that a large IV may be a good thing too.

Sheila Frankel discussed the AES cipher Draft4. The draft currently specifies the use of AES in CBC mode. Not only Rijndael (the AES contest winner) can be used but also the last round finalist algorithms. All those algorithms are only used with a 128 bit block size, and a key length of 128, 196, or 256 bits. The only issue that is currently controversial is the modulus of Diffie-Hellman groups, but the groups specified could be kept in sync with the MODP DH groups draft mentioned earlier. As there are multiple interoperable implementations, the draft 1 draft-ietf-ipsec-monitor-mib-04.txt and draft-ietf-ipsec-ike-monitor-mib-02.txt2 draft-ietf-ipsec-isakmp-gss-auth-07.txt3 draft-ietf-ipsec-ike-modp-groups-01.txt4 draft-ietf-ipsec-ciph-aes-cbc-01.txt

should be advanced to last call. The author pointed out that there was interest expressed for a document describing the use of AES-MAC and also for a document describing the use of SHA-2.

Son of IKE, immediate changes to IKE discussion (Ted)A recent moratorium as been posted to the list from the Area Directors, which was heavily commented. This moratorium is mainly a restatement of a position the AD’s took one year ago, that the only changes that will be included in the current version of IKE is SCTP compatibility5 and NAT/Firewall traversal. All addition to IKE will be deferred to another cycle. Ideally, the so-called Son-of-IKE would be implementation preserving. The SCTP draft didn’t generate lots of comments, which could mean that few had interest in it, or that it is quite ready. The WG chairs will contact the authors of this draft to see how to move this document forward.

William Dixon (Microsoft) and Markkus Lentinen (SSH) led the discussion about the NAT/FW Traversal draft6.This draft is the joint version of three previous drafts. The draft has not changed a lot, though the semantics and syntax are a bit different from previous versions. A set of comments about this draft is out and is in the process of being addressed in a future version. Changes to IKE are required to support NAT traversal. Those changes may be incorporated directly in Son of IKE. There is still one controversial point: the UDP encapsulation of IPsec traffic, an I-D giving the justification of the choices made is currently in preparation. There are currently two interoperable implementations. One last issue is that the current draft version specifies incorrectly the AH encapsulation, and the question was asked whether AH support was really needed, since it is quite complicated to find out a correct solution and the semantics of AH in conjunction with NATs are somewhat contrived. A straw poll showed that there was little support for AH, so AH support will probably be dropped, after the poll is repeated on the mailing list.

Optimistic Draft7. (Hugh Arley, FreeSwan).This draft proposes a method to distribute keys using Secure DNS. Those keys can then be used for establishing IPsec connexions in a transparent way. Basically, when one host wants to communicate with another, it most probably does a DNS check to find its peer IP address. If the information he receives from the DNS system contains keying information, it can be used to transparently enable the use of IPsec between the two peers.Matt Blaze commented that it was quite sympathetic but asked what could be the “killer” argument to convince people using it. The response was that this could be used to leverage the use of IPsec on the net, by encouraging an easy set-up of IPsec connexions. Another comment was whether the DNSsec folks would be happy with this unforeseen use of DNS. Bill Summerfeld responded that something like this was used in the secure shell working group and that the DNSsec people had expressed their support for doing it, so this was most probably not an issue. Hugh Arley also pointed out that this could be more efficient than the used of TLS since the information can be cached. It is also far more efficient than requesting an IKE negotiation for each HTTP connexion.

5 draft-ietf-ipsec-sctp-01.txt6 draft-ietf-ipsec-udp-encaps-00.txt7 draft-richardson-ipsec-opportunistic-00.txt

Clarification of message (Marcus Leech/Steve Bellovin)Last week, Jeff Schiller, Marcus Leech, and Steve Bellovin, the area directors, published a position statement on the ground rules for further development of IKE. Marcus noted that its premises were well known to the IPsec community, but others took it more critically than was intended. Steve and Marcus stated that no exploitable attacks on IKE are currently known.The main point that was meant in the position statement was that IKE is too complex to analyse and determine whether or not it's bug-free. The intent is not to preclude progression of PIC in IPSRA, but rather to reiterate that IPSRA shouldn't change IKE. The message wasn't anything new; just a reiteration of what's been said for over a year: i.e., that there should be no drastically new changes to IKE. The issue, now, is what needs to be done to address the shortcomings of IKE.Steve Bellovin stated that a complex protocol requires complex implementations, and complex implementations lend themselves to bugs and security problems. He pointed out the majority of CERT advisories are just bugs. Marcus Leech stated that no one has asserted that any particular implementation is known to be insecure; it's just that complex implementations, by nature, tend to have security problems.

Son of IKE discussion.Barbara Fraser introduces the son-of-IKE discussion. First a set of presentation will be made that will hopefully lead to comment and discussion on the mailing list.

Improving IKE (Radia Perlman SUN Microsystems)Radia Perlman presents a set of improvements8 that could be the basis for the next IKE version:1 remove aggressive mode (because hiding identities is whether important or not)2 remove the public encryption variants3 Allow stateless operation. IKE is not stateless since the responder must recall information from first message of the initiator.4 more compact parameters negotiation (avoid proposals explosion)5 Fix main mode pre-shared key. 6 remove phase 2 (not present in the draft)7 invert identity protection (main mode, signature keys)8 get rid of the pre-shared key variant9 additional functionality: unidirectional authentication, strong password based authentication.

Andrew Krywaniuk (Alcatel) presented some protocol cleanups proposal. His primary concern as an implementer is to preserve his code base. On proposal is to keep phase 2, but perfect forward secrecy should be kept only for phase1. The authentication hashes needs some fixing, a draft from Tero documents how this should be done. From his experience, the biggest interoperability problems come from re-keying, because it is not currently specified. The speaker also advocates a clarification of the usage of certificates and vendor id payloads.

The session continues by opening the microphone to the floor.Matt Blaze pointed out that he teamed Bellovin, and other to produce a new protocol specification called JFK (just fast keying) that will address most of IKE problems. The rationale behind this approach is that given the complexity of IKE no incremental changes

8 draft-kaufman-ipsec-improveike-00.txt

will insure a better and more secure protocol, so replacing it with a provable security protocol is a sound way to go.Some people advocated that the requirements for the new protocol should be published before continuing work. The chair answered that there are drafts in preparation for documenting the requirements.Someone commented that there is no reason to remove IKE, but another new protocol could be co-existing.Steve Bellovin said that removing things is not necessarily easier than adding from an implementer point of view. Bill Summerfeld did not felt concerned about code preserving changes since his implementation was structured in a way that could be retargeted for a new protocol. A straw poll concluded the meeting. The question was: ”How important is code preserving?” The general feeling from the people present was that code preserving was not important.

3 Public Key Infrastructure (X.509) WGThis group is chaired by Steve Kent (BBN) and Tim Polk (NIST). The meeting began with Tim Polk reviewing the agenda and document status, pointing out that there are many drafts in progress.

Document Status Review Tim Polk (NIST)The working group have twenty-six current Internet-Drafts. Four I-Ds are in the IESG Queue and several more ready for Last Call.

Progressing Proposed Standards to Draft Standards. The working group has ten standards track RFCs. All are Proposed Standards. The ongoing interoperability testing may support progression of some specifications to Draft Standard in the near future. The following RFCs should progress to Draft Standard: CRMF, CMP, OCSP CMC Certificate profile, algorithm profile9.Bob Moskovitz gave a brief status update on CMP & CRMF. At the time being only one optional transaction type has not been fully tested, all the other optional features were tested at the last interop meeting. Ten vendors were present at that last interop, and the general feeling is to move forward to draft standard.Another speaker gave some initial interoperability test results about OCSP. At the time being, he is aware of three independent implementations, notably the OpenSSL implementation. The speaker points out that those interop meeting are still unofficial ones, and as such they does not mean very much yet.

The meeting went on with the discussion of new specifications

First, Stefan Santesson (Addtrust) presented the logotype draft10.This draft proposes supplemental mechanisms designed to establishing a corresponding human trust. This means that the certificate contains information about one logo or photograph. The logo or photograph can then be displayed when the certificate is displayed. The main incentive for doing this is to enable branding with the certificates. This influences also the trust to a certificate, since people will more probably relate to the logo rather than to the information carried by the certificate. This could be done by adding in the certificate an URL to the logo or photograph along with the hash of the pointed object. Field of application

9 RFC2511, RFC2510, RFC2560, RFC2797, RFC2459, RFC287510 draft-ietf-pkix-logotypes-00.txt

are for instance: web server identification, email exchange, unstructured e-business, applications with human authorization (such as healthcare). Different technical solutions on how to embed these data are discussed.Tim Polk suggests that the WG should investigate for technical solutions also. Someone propose to use directories for the logos storages. Attributes certificates are another way to do, but the problem is that there is no way to know that there is an supplemental attribute certificate.The major concern in the working group is that there is no way to constrain the logo references and have the same type of strict control that exists for the moment on the name.

Next, Ari Singer (Ntru) talks about his draft about supplemental public key algorithms11.This non-working group Internet Draft has been submitted after the cut-off date but is discussed anyway. It defines support for the NTRU algorithms in PKIX certificates. This draft will be augmented with additional information required to support the new SHA-256, SHA-384, and SHA-512 hash algorithms in the Internet PKI. In this first version, the algorithms identifiers and ASN-1 encoding are specified for the NTRU algorithms. The author is confident that those algorithms are going to be widely deployed in the future. Complete OIDs and encoding for NTRU public keys are also part of this draft. The author asks some question about how best proceed with this draft, having pointed out that an inclusion of his draft with the PKAlg RFC is one of his goal. Paul Hoffman proposes that an IANA registration of the new algorithms could be the smart way to advance.

Next, Denis Pinkas (Integris) talked about the PKI Disaster Planning and Recovery work item.The goal is to provide a framework to limit the key compromise or key loss conditions that should be addressed so that it is possible to prepare Disaster and Recovery Plan. A draft is in preparation that could lead to an informational RFC. Denis Pinkas concludes by a call to reviewers for this to-appear ID.

Simon Josephson (RSA) talks about one personal Internet Draft he is currently writing. This draft will propose using DNS extensions in place of LDAP to store certificates and CRLs. The author mainly asks people to comment his work.

Tim Polk (NIST), then briefly talked about new certificate and CRL extensions.Several new extensions have been proposed during the last year, but were not included in the proposed new ‘RFC2459’. He suggests that an appropriate way to advance could be to start a new draft that defines these extensions for use in the Internet PKI.

The meeting then focuses on the ongoing WG activities.

David Chadwick (University of Salford) talks about the LDAP V3 profile and certificate matching rules draft12

The author asks for feedback regarding the adequation of the specification, waiting feedback on the profile from people using it.

11 dratf-ietf-pkix-pkalgs-supp-00.txt12 draft-ietf-pkix-ldap-schema-01.txt

Jim Schaad (Soaring Hawk Consulting) talks about the CMC drafts13

Those four drafts are the successor of RFC2797, and each contains a part of the original RFC plus a number of extensions. One of the goals is to make the four documents orthogonal. This will enable easier progression of the separate parts. Nothing much has changed in those documents lately. An interop meeting about CMC was organized lately, at which 12 participants attended, and three of them tested actively their interoperability.

Next, Carlisle Adams (Entrust) gave an update about CMP14.He said that interoperability testing yielded some clarification to the specification. The document is now ready to advance to Draft Standard status.

Steven Tuecke (Argonne Labs) gave an update about the proxy certificate draft15.The purpose of this draft is to support single-sign on and restricted delegation. A quick straw poll showed that there were not many people present who had read the newly revised draft. The major issue with this draft is whether the changes that this draft implies on the certificate path validation, should be part of the base standard. The other solution is to process as a separated step after a regular path validation.

Michael Myers (VeriSign) talked about the OCSPv2 drafts16.The authors have decided to publish them at the experimental status.

Ambarish Malpani (ValiCert) talked about the SCVP draft17.There was two significant changes to the draft: At this moment only ASN.1 syntax is employed, and signatures are based on the CMS format. The author asks for some feedback about this new version.

Last, Denis Pinkas (Integris) talked about the DPD/DPV draft18.This is a new Internet draft that proposes a new approach to Delegated Path Validation and Delegated path discovery. This draft makes use of thee protocols: DPV, DPD, and a separate protocol for management of policy data used for validation or discovery. This allows the DPD and DPV protocols to be smaller and simpler, because the management of parameters used for DPD/DPV is part of a separate protocol. References to the parameters, i.e. the policy, used for validation are Object IDs, and there is a provision for a client to not specify a policy, but have a server employ a default policy and return that to the user. Extensive use of hashes of ancillary values is done to keep messages brief, but this stills allows a client to check the policy. DPV proposal allows for validation of current time, or past time (re-validation). DPV can return four answers, reflecting level of knowledge available to the server, especially with regard to revocation data. Denis Pinkas the status of ETSI documents about PKI and issued a solicitation of comments.

4 Transport Layer Security WGWin Treese (ACM) is chairing the working group. The meeting began with a short introduction about the WG and a quick review of the various points at the agenda.13 draft-ietf-pkix-cmc-trans-00.txt, draft-ietf-pkix-cmc-archive-00.txt, draft-ietf-pkix-cmc-compl-00.txt, draft-ietf-pkix-rfc2797-bis-01.txt14 draft-ietf-pkix-rfc2510bis-04.txt15 draft-ietf-pkix-proxy-00.txt16 draft-ietf-pkix-ocspv2-02.txt, draft-ietf-pkix-ocsp-path-00.txt, draft-ietf-pkix-ocsp-valid-00.txt17 draft-ietf-pkix-scvp-06.txt 18 draft-ietf-pkix-dpv-dpd-00.txt

The first point on the agenda is moving RFC 2246 to Draft StandardEric Rescorla (rtfm) Tim Dierks and Win Tresse have teamed to edit RFC 2246 in order to advance it status to Draft Standard. Some discussions were held about the cipher suites. The main question was to know whether AES would be included or not, and if it is should it be specified as mandatory or optional. No binding decisions were taken onto this point.

After that, Simon Blake-Wilson (Certicom) talked about the TLS extensions draft19.This draft proposes extensions that may be used to add functionality to TLS. DNS name extension has been added to the draft, that allows a single host to host multiple servers. Sessions resumption were clarified, short session id support was removed. Client certificates may now be passed through an URL list. Mac algorithms are restricted to HMAC with MD5 and SHA1. New Error Alerts were added. Some issues should still be resolved. One of them is to know how serious is the certificate unobtainable alert? The consensus is that it may be fatal at the discretion of the server. Do wee need to require client driven extension? This is still open discussion. How and where do DNS names get canonicalized? The proposed way to go is that the server should canonicalize both names, but this is still an open issue. There are also issues whether to generalize OCSP status request and if this draft should be tied with the TLS revision. Those issues are to be discussed and put in a new draft version for this draft to advance.

The next point on the agenda was the TLS Delegation Protocol draft20. Unfortunately the foreseen speaker was not there as is the case of the author of the SRP for TLS Authentication draft21. The chair asked to comment the two drafts on the mailing list.

The meeting continued by the discussion over the ciphersuites.The AES ciphersuite for TLS draft22 should now advance to proposed standard, with the OAEP padding (which is still controversial) put out of the draft Concerning the ECC Cipher Suites For TLS23, most of the criticisms concerned the number of ciphersuites, those have been reduced to roughly 6 ciphersuites. There are still issues, namely the ciphersuite numbering, parameters in the CLIENT_HELLO message and whether or not include PFS (perfect forward secrecy).There was much discussion of whether the IANA should handle ciphersuite assignments, issue on which the chair will discuss with the IANA. There was also a discussion about whether patented algorithms should be given RFCs of any kind for ciphersuite identifiers. The chair made two proposals for the handling of future ciphersuite submissions: The first is that new drafts specifying export-grade ciphersuites will not be accepted for publication as working group drafts. Secondly, new drafts should specify temporary ciphersuite identifiers from the experimental range for the initial submission.

Hidenori Ohta (Mitsubishi Electronic Corp.) presented the draft24 co-authored with Hirosato Tsuji, describing the addition of the MISTY1 algorithm to the TLS ciphersuites.

19 draft-ietf-tls-extensions-00.txt20 draft-ietf-tls-delegation-01.txt21 draft-ietf-tls-srp-01.txt22 draft-ietf-tls-ciphersuite-04.txt23 draft-ietf-tls-ecc-01.txt24 draft-ietf-tls-misty1-01.txt

Shiho Moriai (NTT corp.) presented her draft about Addition of the Camellia Encryption Algorithm to TLS25.

Ari Singer (NTRU Cryptosystems) presented his draft26 about the NTRU Cipher Suites for TLSThis draft discusses the way to integrate the NSS signature algorithm and the NTRU encryption algorithm with TLS. Those algorithms are claimed to be more efficient on memory and CPU constrained devices.

5 SASL BoFThis BoF is chaired by Kurt Zeilenga (openldap) and Alexey Melnikov (messagingdirect)

This BOF will discuss the formation a working group to advance SASL to Draft Standard. As a WG proposal has been submitted and is under IAB/IESG consideration, the status of this proposal will be presented and discussed. If the WG creation is accepted, it will deliver a revised SASL Technical Specification suitable for consideration as a Draft Standard. This work will be based upon RFC2222, RFC2195, RFC2931, RFC2945 and on the following drafts: draft-myers-saslrev-00.txt, draft-ietf-cat-sasl-gssapi-02.txt, draft-burdis-cat-srp-sasl-04.txt.Some areas are by purpose out of the scope for this working group: namely new features, other SASL mechanisms that the ones specified above, SASL ‘profiles’. The working group will act as a technical reviewer on SASL related submission by other working groups.

The meeting began by the explanation of the charter for this WG and a first question was asked whether there were objections about it. Someone asked how does the WG plan to constrain the addition of new things compared to the advance of SASL as DS. The answer of the chair was to first advance the specs to Draft Standard and if there is time left, new submissions will be evaluated.

The meeting continued focusing on technical issues.Concerning the base specification, from RFC2222 there is a new draft27, in which some mechanisms are suppressed and some wording has been clarified. GSSAPI support is put in another document.

The meeting continues with open issues. The first one is whether to specify authorization identity, if yes, what kind and which format should be adopted (binary blob or something else?). A discussion followed, about the virtues of UTF-8 (with no null in it) versus binblob. Currently, most authorizations are using UTF-8 encoding. Someone commented that a lot of small incremental improvement may sums in big changes (coding time too great); the same problem exists with liability. Tom Yu (MIT) commented about consequences of using UTF-8 encoded strings on what is not a character string. Someone else comment that there should be a recommendation in the specs on how to make the application profile. LDAP authorization is the only existing authorization ID using binary blob currently. As there is no consensus further discussion will be held on the mailing list.

25 draft-ietf-tls-camellia-01.txt26 draft-ietf-tls-ntru-00.txt27 draft-myers-saslrev-00.txt

The maximal buffer size issue was discussed next. There should be a mechanism to negotiate the size of the buffer. The lack thereof has proven to be problematic. The authors of the draft are going to make a proposal on the mailing list.There is another open question regarding re-authentication. Should the SASL specs contain a recommendation on how to do re-authentication? There are currently no comments about that in the RFC.Other issues are to be addressed too. What should be done about the DES layers, since there is no known implementation of that part of the spec. Should an AES layer be added to the spec? Currently its use is not yet mandated by the IESG. The decision is made to write a document covering the use of AES. The document should also be cleaned up according to comments that were made on the mailing list.

No poll is made concerning the effective creation of the Working Group. The general feeling is that there is enough interest for creating it.

6 S/MIME Mail Security WGThis working group is chaired by Russ Housley (RSA). After a short introduction the chair reviews the various points at the agenda.

Three documents28 are currently in the editor queue to be published as RFC; they are currently blocked because the editor is waiting for some RFCs from the PKIX group to be published at the draft standard level (a Draft Standard RFC cannot cite an Proposed Standard or Experimental RFC).

Someone expressed his concern about the size of the examples draft29. Paul Hoffman (IMC), the author, answered that it was true that the examples draft is quite big. He said also that some RFCs are even bigger and should not bring any problem.

Jim Schaad (Soaring Hawk Consulting) presented the interoperability matrixThe matrix was updated to reflect the new requirements of the current drafts30. CMS now has 96 MUST statements and 79 optional requirements or ‘features’. Of those requirements, implementations have demonstrated interoperability of 56% of the MUST statements and 48% of the features. In the CMS Algorithms draft, there are now 46 MUST statements and 15 optional features. Of those, interoperability has been successfully demonstrated with 93% of the MUST statements and 93% of the optional features.For the other unchanged specifications: RFC 2631, Diffie-Hellman, only 1 of the 13 requirements has passed interoperability testing. RFC 2632, CERT, 16 of the 21 requirements have passed. RFC 2633, MSG, 17 of the 61 requirements have passed. RFC 2634, ESS, 27 of the 81 requirements have passed

Paul Hoffman (IMC) talked about CMS and ESS Examples31

The speaker announce that he had missed the submission cut-off date for posting a new version of his internet draft, but that a new version is in preparation. This new version includes the examples that have been discussed in a specific mailing list. Unfortunately, only two people actively participated to that discussion, and Paul Hoffman requests other S/MIME

28 draft-ietf-smime-esformats-04.txt, draft-ietf-smime-espolicies-01.txt, draft-ietf-smime-seclabel-04.txt29 draft-ietf-smime-examples-06.txt30 draft-ietf-smime-rfc2630bis-01.txt, draft-ietf-smime-cmsalg-01.txt31 draft-ietf-smime-examples-06.txt

implementers to give him feedback, at least on the fact that their implementation can or cannot process successfully the examples in that document.

Next, Russ Housley talked about updates to CMSCMS has been split in two drafts32, dissociating the algorithms being used in CMS from the core specification. Two remaining issues are to be solved, the first one being whether CMS should specify any mandatory to implement algorithm and the second one being whether the version numbers are handled correctly.For the first issue, after explaining pros and cons of a proposed solution, a straw poll is organized. The result was that the ‘should’ and ‘must’ statements for algorithms will be removed. For the second issue, two alternatives are proposed and a poll is organized. Since there are not much people answering to the poll, the issue is still considered as open and will be discussed on the mailing list.

Blake Ramsdell (Tumbleweed Communications) talked about updates to the certificate and message drafts33.The message draft changed the algorithms status for the receiver from MUST DSA to MUST DSA and RSA, and for the sender from ‘SHOULD RSA’ to ‘MUST DSA or RSA’. The ‘MUST DH’ clauses were changed to ‘SHOULD DH’ and the ‘SHOULD RSA’ clauses were changed in ‘MUST RSA’. Similar adaptations were made in the certificate draft, namely the ‘SHOULD SHA-1 with RSA’ were changed to ‘MUST SHA-1 with RSA’ and the ‘SHOULD MD2/MD5 with RSA’ were changed in ‘MAY MD2/MD5 with RSA’.Jim Schaad asked if the requirements to support MD2 could be eliminated. Paul Hoffman made a proposal, that MD5 requirements should be changed to ‘SHOULD’ in lieu of ‘MAY’ and that MD2 requirement should be dropped or changed to ‘MAY’. Somebody particularly concerned by constrained mobile device asked whether the DSA support is now mandatory. He expressed his concern that some device might not be able to implement DSA due to CPU/Memory constraints. The answer from the author and the chair was that the decision was made in a previous meeting that compliant applications must implement both algorithms for signature verification. Finally, Jim Schaad asked if this draft should reference the CMS Algorithm draft or reference the corresponding document from the PKIX working group. The author said that in a future version it would be the PKIX document that would be referenced.

Next, Sean Turner (IECA) discussed the status of the Symmetric Key Distribution draft34.This document went through a working group last call. No comments were posted on the mailing list but some where mailed to Sean Turner directly, most of which were editorial changes.

Chris Bonatti (IECA) talked about the X.400 and CMS drafts35.Those drafts specify the way to use S/MIME in a X.400 context. The wrap draft specifies how to protect X.400 content with CMS objects, the transport draft is concerned with the way to encapsulate CMS object in X.400 messages for transport by X.400 MTAs. Most changes in the new version of the draft were done to accommodate the changes done in RFC2633bis draft. Some editorial changes were also made, but some typos should nevertheless be corrected. The author believes that the drafts are ready for working group last call. Jim Schaad commented that there were still some issues and Paul Hoffmann agreed with Jim Schaad,

32 draft-ietf-smime-rfc2630bis-01.txt, draft-ietf-smime-cmsalg-01.txt33 draft-ramsdell-rfc2632bis-00, draft-ramsdell-rfc2633bis-00.txt 34 draft-ietf-smime-symkeydist-05.txt35 draft-ietf-smime-x400wrap-03.txt, draft-ietf-smime-x400transport-03.txt.

proposing that the issues should be resolved on the list and incorporated in new a new version before issuing a working group last call.

Next Jim Schaad (Soaring Hawk Consulting) gave the status of the AES and RSA-OAEP draft36.This draft specifies the conventions for using the AES encryption algorithm along with RSA-OAEP as key management algorithm with CMS. Some changes were made in this version of the draft, namely added an overview of AES, removed the AuthenticatedData section which was not applicable since RSA is used here as a key transport mechanism, added a place holder for the key wrap algorithms (OID from NIST are still awaited) and added an AES EncryptedData section. Some things are still to be done: get the key wrap algorithm OID from NIST, complete the AES key wrap example according to the awaited OID, added some lacking ASN.1 items and resolve password recipient info key wrap issues. Blake Ramsdell asked what the status of the SHA-2 algorithm (currently being standardized by NIST). Jim Schaad answered that the issue was raised at a previous meeting with RSA peoples, but since then nothing has been done. Someone commented that a SHA-2 draft was issued by the NIST quite some time ago. Jim Schaad said that the issue was not in SHA-2 itself but more on when the key size and OIDs for DSA with SHA-2 will be issued.

Simon Blake-Wilson (Certicom) gave a status update of the Elliptic Curve Cryptography draft37.This document has currently completed both working group and IETF last call. The chair took note to follow up with the Area Directors that have still to review the document. The author pointed out that there were three independent implementers that have done some interoperability tests. He is currently preparing an example draft.

Blake Ramsdell (Tumbleweed Communications) talked about the S/MIME Gateway Protocol draft38.This is a individual draft submission. This draft describes how to use S/MIME to perform server-to-server encryption of mails in transit between two cooperating domain. Some independent implementation of this protocol already exists and some interoperability tests were already conducted. The author asked the working group if this could be considered as a working group item. A discussion ensued. Only a few group members had read the draft. Paul Hoffmann commented that it is an important document since it increases the use of S/MIME and encourages the working group members to read the document. The chair asked someone to compare the document with the DOMSEC draft39 to see whether this new draft could be considered as a working group item, or should be considered as a profile within DOMSEC. The discussion will continue on the mailing list.

Steve Farrell (Baltimore) gave the status of the reuse of CSM content encryption keys draft40. The situation is similar to the ECC draft since it has passed the working group and IETF last call. The document is now under the review of the Area Directors, and the chair will also check the status with the area directors.

Rich Nicholas (Getronics) presented the S/MIME Freeware Library (SFL)36 draft-ietf-smime-aes-alg-02.txt37 draft-ietf-smime-ecc-06.txt38 draft-ramsdell-enc-smime-gateway-00.txt39 draft-ietf-smime-domsec-08.txt40 draf-ietf-smime-rcek-04.txt

This library is a freeware implementation of RFC2630 and RFC2634 available at http://www.getronicsgov.com/hot/sfl_home.htm. The goal for this library is to provide a reference implementation of the RFC2630 and RFC2634.

7 Authenticated Firewall Traversal WGThe group is chaired by Wei Lu (permeo.com). The chair wants to discuss the status of the WG.

The AFT working group is one of the oldest group in the security area (active since 1995). It produced 3 RFCs that are already at Proposed Standard status: RFC1928, RFC1929 and RFC1961. Those RFC defines the SOCKS protocol.Two years ago a BoF was held to know if the work should continue in this working group. There was quite a lot of interest at that time but since then not much work has happened. Though some interesting ideas were proposed back then. The chair is concerned and frustrated because he feels like doing a one-man show with this working group. He asked whether the people present at this WG meeting were interested in contributing and wants to discuss the future of this working group. He then opened the floor to questions.

Some people expressed that they could see the value of having a transport-level proxy solution to the firewall traversal problem.Someone asked what the differences were between AFT and other working groups like OPES or MIDCOM. The answer was that MIDCOM does not break transport at the firewall and is more scoped on IP addresses and port management (for IPTel for instance) and access policies. OPES looks more like extending HTTP proxies. Someone from MIDCOM pointed out that the interest of that working group was not in doing proxies but to allow some enhanced services to open firewalls to provide those enhanced services.A working group attendee asked whether AFT’s solutions could solve SIP firewalls traversal problems. The answer was that it would since AFT solutions would interact at the TCP or UDP level and that they are that way application neutral.Someone asked why there was no current Internet Draft for this working group. The chair answered that he was the only one contributing, he wants to be sure not doing the work for nothing, and that people will contribute and comment the drafts. Some peoples declare to be interested. The next step is that the chair will re-submit internet-drafts and wait for feedback.

8 IP Security remote access WG

This working group is chaired by Sara Bitan (University of Technion) and Paul Hoffman (VPNC). The purpose of this working group is to produce a remote access architecture, a standard mechanism to accomplish human user authentication mechanism, and a standard mechanism to convey user configuration information and access control information from the user’s own private network to its local IPsec implementation.The agenda for this working group is mostly to discuss the PIC (pre-IKE credential) draft41

Marcus Leech briefed the working group about the statement from the area directors about IKE. PIC is not excluded by this statement but should run on another port than 500, and PIC implementations should not share code with IKE implementation on the same host.

41 draft-ietf-ipsra-pic-03.txt

Hugo Krawczyk (Univ. of Technion) gave a presentation of PIC. PIC provides a four-stage protocol using legacy authentication before IKE that retrieve a certificate subsequently used for the authentication phase of IKE.One of the author presents PIC that provides a 4stage protocol using legacy authentication before IKE that retrieves a certificate then used in IKE to authenticate a user. It is partly based an EAP.rfc2284.

After that presentation, the meeting went on with a question an answer period. William Dixon (Microsoft) asked if PIC was going to support the revised hash draft42 from the IPsec working group. Hugo Krawczyk answered that the revised hash draft solves a problem that does not appear in PIC. William Dixon asked bout stateless DOS prevention. The answer was that DOS protection was not part of the requirements for this working group. William Dixon also expressed his concern about the inclusion of certificate request that might crate UDP fragmentation because it could convey a long certificate chain. He proposed to add some wording that limit the size of messages to 1500 bytes in order to avoid this fragmentation. He asked also what about the CMC support. Hugo Krawczyk answered that this was not planned. Someone noted that another server increases the complexity of the network and the architecture. Hugo Krawczyk pointed out that a separate authentication server is optional. The same member asked if PIC should not be moved to the PKIX workgroup since it is an enrolment protocol. Hugo Krawczyk answered that enrolment protocols are under functional and over functional for the purpose of PIC, and are too complex for the purpose. Andrew Krywaniuk (Alcatel) pointed out that a lesson of IKE was that arbitrary payloads and arbitrary lengths should not be allowed. He asked also if PIC has been implemented and what are the CPU requirements of it. The author said that it has not been implemented, that there were some performance issues but that human authentication should be rare. Andrew asked whether PIC was in fact a simplified CA with CA authentication being done by EAP. Hugo answered positively.

The discussion went on with a general discussion. Marcus Leech (Nortel) asked who implemented the DHCP draft43. Someone was aware that RedCreek had an implementation and recalled that another company had an implementation.

The chair announced the procedure for moving forward. A last call period will start at the end of the week. It will last for six weeks. If comments are posted the period will be extended. At the end of the period an IETF last call period will begin. As two implementation is not necessary for the draft to advance to draft standard, the document will be submitted as such after the last call period. The working group might not have to meet at the next IETF meeting in Salt Lake City.

9 Security Area Advisory GroupThere is only one Area Director since Jeff Schiller stayed in USA for family reasons. An executive summary was presented of the results of the various WG and BoF meetings of this week in the security area.

After that Uri Blumenthal (bell-labs) presented his work about the usage of PRF for key generation. He basically stated that generated keys should be pseudo-random. For key generation, usually hash functions are used as a base for constructing the Pseudo-Random

42 draft-ietf-ipsec-ike-hash-revised-02.txt43 draft-ietf-ipsec-dhcp-13.txt

Function. Hash functions have usually the properties of collision resistance and MAC property. The fact that SHA-1 is a pseudo-random generator is in fact a too strong assumption since it turns out that the MAC property is unnecessary to have a correct PRF. The speaker presents a construction base on a modified SHA1. The base initialisation of SHA-1 is modified and the result of one SHA1 round is multiplied modulo a large prime. A certain amount of output bits are extracted from this last result. This type of construction is presented as being a better way of generating the keys than the currently used construction. Someone asked if there was a significant impact on the key derivation operation. The speaker answered that the impact was not very big. Someone else asked the speaker if he was aware of Intellectual Property Issues. The speaker answered that he did not know.

Steve Bellovin presented a slide show about the current status of some security issues, like the presence of the NIMDA worm at the IETF.

Tim Polk made an announcement that NIST was currently starting a set of workshops about different cipher modes.

Someone proposed that the IPsec working group should focus only on IPsec and that another group could be created in order to focus on keying matters. Someone else proposed that since the IPsec working group has almost finished the standardization of IPsec the name could be changed to reflect the new focus of the group. A non-binding straw poll was organized: a majority of people were in favour of a split.