UNIVERSITE LIBRE DE BRUXELLES
FACULTE DES SCIENCES
SERVICE TELEMATIQUE ET COMMUNICATION
Report on 51st IETF Meeting
August 5th – 10th 2001, London (UK)
Faculté des Sciences ULB - Rapport STC
Service Télématique et Communication 01-10
CP 230 - Blvd du Triomphe décembre 2001
Report on 50th IETF Meeting
August 5th – 10th, 2001, London (UK)
Alain Jourez, ULB/STC
This 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 WG
This 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 Draft 4. 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
draft-ietf-ipsec-monitor-mib-04.txt and draft-ietf-ipsec-ike-monitor-mib-02.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
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
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
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.
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
1 remove aggressive mode (because hiding identities is whether important or not)
2 remove the public encryption variants
3 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 variant
9 additional functionality: unidirectional authentication, strong password based
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
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
Someone commented that there is no reason to remove IKE, but another new protocol could
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
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) WG
This 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
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
RFC2511, RFC2510, RFC2560, RFC2797, RFC2459, RFC2875
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
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
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.
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 WG
Win 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.
draft-ietf-pkix-cmc-trans-00.txt, draft-ietf-pkix-cmc-archive-00.txt, draft-ietf-pkix-cmc-compl-00.txt, draft-
draft-ietf-pkix-ocspv2-02.txt, draft-ietf-pkix-ocsp-path-00.txt, draft-ietf-pkix-ocsp-valid-00.txt
The first point on the agenda is moving RFC 2246 to Draft Standard
Eric 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
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.
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
This 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 BoF
This 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-
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 draft 27, in which some
mechanisms are suppressed and some wording has been clarified. GSSAPI support is put in
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.
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 WG
This 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
Someone expressed his concern about the size of the examples draft 29. 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 matrix
The matrix was updated to reflect the new requirements of the current drafts 30. 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
draft-ietf-smime-esformats-04.txt, draft-ietf-smime-espolicies-01.txt, draft-ietf-smime-seclabel-04.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 CMS
CMS 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
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
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, 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
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
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
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)
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 WG
The group is chaired by Wei Lu (permeo.com). The chair wants to discuss the status of the
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.
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
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 draft 42 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
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 Group
There 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
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.