Edmund Whelan

University College London

Agenda

a) Certificate/CRL Profile

- criticality

- character sets

- wildcarding

b) LDAP (Lightweight Directory Access Protocol)

c) OCSP (Online Certificate Status Protocol)

d) CMP (Certificate Management Protocol)

e) CRS (Certificate Request Syntax)

f) Time Stamping

g) Notary

This meeting was spread over two sessions.

a) Certificate/CRL Document (PKIX Part 1)

This document is basically finished and has gone through its last call. However there are a few unresolved issues which need to be cleared up. The hope is to revise the document by December 15th and submit it to the IESG. A number of issues have been resolved already. These include the discussion around the availability of an OID for RSA with SHA-1 as there already is one. Also resolved were the issues around ASN.1 errors, legal verbage (people had requested additional wording but then decided they were happy as it was) and detail issues. The issue around character sets was resolved as it was decided that if people don't want to use IA5String then they don't want to use T.61 either.

The unresolved issues are:

• wildcarding (this discussion has been deferred)
• 88 vs 93 vs 98 ASN.1 (again this is basically the issue of character sets). It was decided that 88 ASN.1 was preferable as the builders have these compilers and want to build it as it is.
• UTF8String - this is in 98 ASN.1 and it may be wanted - it is not clear whether this will be a problem or not.
• Key Usage. It is thought that the document as it stands matches X.509 exactly and so it is safest to stay with it as it is.
• Conformance and Criticality. There was much discussion around CRITICAL extensions. The example used was cRLDistributionPoint and whether this should be allowed to be marked critical. Implementers must implement all MANDATORY critical and also any OPTIONAL critical extensions as this would give the strongest interoperability. However one doesn't want to force clients to implement things they don't need so it should be made optional. This issue began as the old pkix document didn't allow for the cRLDistributionPoint extension to be set as Critical which was clearly wrong. If it is marked as critical all clients which are compliant must be able to read it even if they cannot make use of all the information it contains. The main feeling seemed to be that the number of extensions which must be understood by all clients should be kept as low as possible. The document already explicitly allows private critical extensions but this would result in a loss of interoperability. It also must be made clear what a client must do if an extension is marked critical. The editorial team will send a new draft, maybe specifying a subset of critical extensions which must be implemented, to the mailing list.

PKIX part 2 has now been split into 3 parts - LDAP, OCSP and FTP/HTTP. There have been no comments on FTP/HTTP so it is not on the agenda.

The LDAPv2 Profile has completed its WG last call and an IESG vote is pending. The need for an LDAPv3 profile has been discussed on the mailing list and the consensus is that there is a need for one. This will address such things as authentication, access control and replication. Work is expected to begin in early 98 with the target being approval by the 4th Quarter 98. There is also the issue of whether the PKIX group or the LDAP group should do this but it was felt that the PKIX group are in a better position to know what will be needed in the profile.

This will be a specification of the minimal requirements necessary to support interoperability and topics could include: attributes; object classes; name forms and recommended DN structure; matching rules. If the document proposal is approved work can begin on the document now with the target for approval being in two meetings time. The question arises as to whether it falls within the PKIX WG Charter - liaison with the LDAP WG is necessary and there is also a LDAP Schema Registry setup already so PKIX may be able to draw up a schema and register it quickly.

This has been around for a long time but interest has only really appeared recently (within the last month or so). The discussion of OCSP was deferred until Wednesday to allow other people to be present.

This has been through the WG last call and submitted to the IESG. The only issue left is that concerned with Character Sets.

This was discussed at Munich with the basic idea being that CMP will be given the option to carry requests using PKCS7 and being compatible with PKCS10. A draft has been published but there was some discussion as to, seeing that there is an S/MIME Working Group which is already bringing PKCS7 and PKCS10 formats into the IETF, this may be a better place for such a document.

Document Timeline:

Status of Draft:

Much work has been done on the document and a Final Draft should be submitted in Feb 98 following review and discussion in January. The last call should be by the next IETF meeting. The question was raised regarding backwards compatibility with PKCS10 (there is a new PKCS10 document which has a number of changes over the old one). The consensus was that this document should stay in the PKIX group rather than move into the S/MIME WG.

There was some discussion as to whether this WG is the correct place for such work to be done. Presentations were given at the Munich IETF Meeting but discussion was postponed. Since then the Time Stamping and Notary documents have been revised and submitted as drafts.

A Time Stamping Authority (TSA) associates a message with a point in time. It appends the time to a message and signs the result but does NOT examine the message in any way. Consequently it only establishes evidence that the message was generated before the time-stamped time.

A Notary Authority (NA) is basically a Trusted Third Party (TTP) that automatically notarizes data. It produces evidence, in the form of a notary token, relating to: validity of an entity's claim to possess some data; validity and status of a certificate; validity of some other type of data.

The service types are:

- Notarize possession of data (npd) where the NA verifies the signature contained in the request which also contains the data.

- Notarize certificates (nc) where the NA checks the full certification path, crls, policy OIDs etc and provides proof that the certificate has been checked.

- Notarize data (nd) in which case the NA verifies the correctness of data eg assertions, contracts, signatures

- Notarize both (nb) in which case the NA notarizes both the possession of data and also the validity of that data.

There was some discussion again over whether this is the correct WG for such a document as, although it is useful to the pkix WG, it is also useful to numerous other WGs and pkix may not be the best place for it.

Due to time constraints this discussion and the second talk on Timestamping/Notary were postponed until the second pkix meeting later in the week. I could not attend this meeting due to a clash with another meeting.

Agenda:

- Outline Meeting

- WG Goals

- Design of PGP

- OpenPGP Format Draft Status

- RFC 2015 Status - PGP/MIME

- Trust Model

- AOB

The aim of this WG is to provide the IETF standards for PGP processed objects and to provide a MIME framework for exchanging such objects via email or other transport protocols. It is a Technical WG and is not concerned with political issues.

Phil Zimmerman talked briefly about his design of PGP and said that he had tried to keep it lean and resisted attempts to include extra algorithms etc. He said it was with some trepidation that he handed over change control to a group of people and asked people to look after the standard. He mentioned that, in his eyes, PGP won out over PEM because PGP was based at a more grass roots level and he would like to preserve a decentralized trust model rather than a hierarchy. Network Associates have now acquired PGP. A question was raised about the possible use of X.509 certificates with PGP and he replied that he would prefer this to be avoided although he would hope to coexist and have PGP being able to read X.509 certificates. This is however a question for the WG and not any one individual. Another question was raised about the establishment of a PGP Public Key Infrastructure but John said this WG was technical and infrastructure issues were not part of its mandate.

The document was released a few weeks ago and John Callas went through the detailed changes he had made. A few of the things he has changed or is changing are:

- Armor has been moved to its own chapter

- 2.4.1 table of armor headers added

- 2.6 Clear Text signatures needs its own section

- 3.3 remove counted strings

- 3.5.1.3+3.5.3.3 Iterated and Salted String to Keys are a bizarre form and it would be nice to drop them as they add complexity.

- 4.3+5.1 Encrypted Session Encryption Key rename to Public Key Encrypted Session Encrypted Key as there is now also a Symmetric Encrypted Session Encryption Key.

- 5.2 Signatures - a definition will be added and KeyID will also be defined.

- 5.2.2.1 The type description needs reworking

There were a number more changes and a new draft will be circulated to the mailing list soon.

John made the point that Version 4 encryption keys are escrow resistant as the owner can rotate/change his private key. Phil said he would like to be able to have photos used as ids but comments were made that this was probably more simply done using PGP/MIME. The discussion around X.509 Interoperable packets was deferred. Also a new section describing security considerations such as stealth and traffic analysis will be added. In addition the addition of more algorithms was discussed. John said he was adding any that people requested but Phil said he felt this was wrong. In PGP originally he had added several algorithms in case one was broken. If this happened then PGP would still be usable and people's keys wouldn't be useless. There only needed to be a small number of algorithms as Phil considered that he would resist all attempts by people to get certain algorithms added and just tick with a small number of tried and tested algorithms. There was some discussion around this issue with someone pointing out that the general policy in the IETF is to specify a number of algorithms which must be supported and allow a lot of others which may be supported by peoples implementations if they so wish. There is also space reserved in the algorithm numbering field for people to specify private algorithms. For example, if Anne and Bob decide to communicate and use a private algorithm with a number FF then this is fine and Clare and David can also communicate securely with each other, again using a private algorithm (different to that of Anne and Bobs) also with number FF. This is allowed and would work as Anne and BOB aren't attempting to communicate with Clare and David.

A new draft will be sent to the mailing list and, following discussion, the draft should be submitted to the IESG in January.

This document is about 80% complete. New MIME types have been specified namely "application/openpgp-encrypted" and "applicaton/openpgp-signed" rather than "applicaton/pgp-encrypted" and "aplication/pgp-signed". Many people felt strongly that this was wrong as it is not backwardly compatible and it would have to be discussed on the list. There is also the type "application/openpgp_signature". The discussion on Distribution of OpenPGP keys should really be moved to the OpenPGP Certificate Format document.

The WG charter would have to be revised if it was to include the Trust Model Document. This would define trust models and how to implement them with PGP. Discussion was deferred to the mailing list.

Agenda:

- Introduction

- Privacy etc

- Hit Metering

- State Management (a.k.a. cookies)

- W3C P3

- Operational Issues (policy etc)

- Plans for WG

This BOF arose from the http WG as they found themselves dealing with cookies (state management). The question the BOF wants to address is whether, when defining protocols, the IETF needs to have privacy considerations as well as security considerations.

There didn't seem to be any serious privacy issues around hit metering.

There was a fair amount of discussion around the use of cookies. In http messages the cookie mechanism comprises two headers. Such cookies are passed back and forth between the client and the server and can be passed onto third parties if say AltaVista carried a doubleclick ad where the image is held at the doubleclick site.

There seems to be very real concern about the use of cookies as the user is not aware of what is happening and has little control over it. It was also emphasized that if a user click on the "Don't accept cookies" button they may feel their identity and details are private. However there are numerous ways this is revealed eg the HTTP-REFERRER field which can be disabled in NS Communicator only by hacking a preferences file and no-one has seen it being disabled in MSIE. A recent problem with the VISA/MasterCard/SET project was mentioned whereby once a customer has visited a site, and the browser has his credit card information stored, then this can be made available to the next site he visits unless he restarts the browser. 30 days ago their policy was changed to require users to restart after completing a transaction.

A short overview of the W3C and P3P projects was given.

Ted (NASA) described the policy for storing access logs at NASA. Apparently, an IT Consultant had put in a request to NASA under the FOI(Freedom of Information Act) requesting all their web access logs since they began. This runs to 30million hits on their busiest day so the volume of information is large. It also transpires that the same consultant has made similar requests from other DoD establishment and there is a legitimate concern that someone could map users progress. NASA is not allowed however to ask what the user wants the information for. The initial idea was to anonymize the logfiles but this was considered unsatisfactory and they have now decided to keep logfiles for 30 days after which they are deleted. If a summary analysis has been done then this alone can be kept. This is restrictive in some ways eg often an intruder's access is only noticed greater than 30 days after the initial incident and so use was generally made of the logfiles to track what they did etc. This will no longer be possible.

There was overwhelming feeling that this issue needs to be addressed but, partly because there are no specific areas of work, there were no volunteers. Ted's boss at NASA agreed to help Joyce Kennedy to try and set up what is needed and another person volunteered to pull together a document containing people's experiences in this area. Ted suggested that any document should start with a section detailing the threats as they are perceived. A mailing list will be set up by 15th December (next week). To join it send email to:

web-priv-request@nasa.gov

Agenda:

- Kerberos Issues for Discussion

- ftpsec

- spnego

- Next Steps

- Kerberos over TCP/IP - Mandatory for spec 2; Include 32-bit network byte order length; KDC ability to break connection

- IPv6 Addresses

- 3DES encryption - As specified this doesn't conform to template

- Typed e-data

- Anonymous credentials - Fields and flags have been defined; Public Key method in separate ID; reserved principle name "anonymous"

- Ticket extensions (moved around with ticket) - External adata; Null extension

Resolve the open issues

Fix 3DES specification

Add changes that have been decided

Clean up the formatting

Add references/citations (there have been many contributions causing the section to grow large. The citations will be moved to the specific sections to avoid this problem)

Last Call

A question was raised about the RFC1510 Str2Key. MIT has implemented this but others are having problems interoperating. This will be discussed off-line.

The original draft was submitted at the Munich IETF and there are no outstanding technical issues apart from the alignment with RFC 2228 which must be verified. There is one implementation and so this document is ready for a WG Last Call.

I think this makes use of the Fortezza card and the algorithms it uses are classified. There are no outstanding technical issues but a status is being waited for due to the classified algorithms.

There have been some changes but this is ready for a WG Last Call.

Agenda:

- Introduction

- Implementations (TIS, IBM ? , Microsoft ?)

- Documents

- What's next ?

TIS are doing a reference implementation and they have a DNS server running internally. They are implementing most of RFC2065 and they also have a signer application. They hope to make this available very soon. IBM and Microsoft representatives were present but declined to present anything and when asked if they had anything to say they said that they had no comment at this time. It was mentioned that another implementation would be needed as the draft progresses. There was some talk about the use of encumbered algorithms as RFC2065 specifies RSA as being mandatory. The IESG takes the position that if there is an unencumbered way of doing things then this must be the mandatory one and others must only be optional. It is expected that the draft will move to include DSS as the IESG don't want to give RSA a commercial advantage. After 6 months of legal wrangling and talks with RSA they have provided a license to use this.

BIND: TIS have an export license and so would like to include the kit provided by RSA which RSA have given a license for them to distribute and see what the Customs etc do.

There are 15 documents in progress and it would be nice to move some of these along the standards track or kill them off.

The following documents have been moved into Last Call (ends Friday 19th December):

The documents will be worked on and discussed.

Agenda:

- Son of RFC1928 Document

- Multicast

- SocksV6

- General

mailing list: aft-request@socks.nec.com

This document is mainly a minor revision of RFC1928, which addresses some small problems.

GSSAPI as specified is not sufficient

Authentication Algorithm Choice ?

TCP Out of Band data handling is not specified

No "Invalid Address" error

UDP Fragmentation and getsockname() is broken
No extensibility mechanism

Out of Band (OOB) data handling

New error - "invalid address"

Basic UDP handling, removing fragmentation

RFC: GSSAPI and cleartext passwords

Drafts: CHAP, CRAM(prompt based), SSL/TLS

Require:

mandatory method to ensure interoperability

strong method to protect bulk data
- kerberos 5 via GSSAPI

- TLS (SSL)

weak method (but still stronger than passwords)
- CRAM-MD5 (similar t CHAP)

- OTP (S/KEY)

- Son of RFC1928 itself

- Specification of Strong Method (SSL/GSSAPI ?)
- Specification of Weak method (CHAP/CRAM ?)

- UDP Extensions

- Extensions and Compatibility Mechanisms

Note that IPSec may be another way of providing strong security for Socks.

Multicast has several security and management issues

- users can inadvertently multicast sensitive content

- content protection

- code is needed on client to communicate with the firewall

- defined set of UDP extensions for multicast
- supports 2 modes (MultiMulti/MultiUni - MM/MU)

- have a prototype (Win95/NT)

- works with off the shelf apps e.g. vic, vat, rat , sdr, IP/TV etc

- testing has been successful so far

An Internet Draft is available

SocksV6 features:

- server behind proxy (eg SMTP)

- separate control channel

- multicast

- IPsec integration

- proto cleanup

An Internet-Draft will be available in 4-6 weeks.

The comment was made that anything not directly concerned with fixing problems with RFC1928 was outside the scope of this WG and a new WG would have to be set up. This would include work on SocksV6 for example. This would have to go through a BOF and setting up of a charter etc.

Agenda:

Results of document reading party

Next steps on documents

The document reading party looked at the following drafts:

Five groups were set up:

a) encryption (esp docs etc) - inconsistencies in padding

b) authentication (arch and algs) - tunnel mode not explained in a-h

c) roadmap doc

d) isakmp, isakmp-oakley

e) architecture doi (spent time on selector issue and wanted to reconcile what is expressible in doi and what is called for in the document)

Note:

i.e. slrw = single or list or range or wildcard

The above are still fluid.

Notes from the groups are going to be sent to the whole list.

Required IPSec Combinations:

Transport Mode

- AH

- ESP

- AH + ESP

Tunnel Mode

- AH

- ESP

There is no requirement to support nested Security Associations (SAs) originating and terminating at the same endpoints

Only ordering in an SA bundle is explicitly AH then ESP in Transport Mode.

Multicast Key Management - Dan Harkins CISCO (MKMP = Multicast Key Management Protocol)

- Scaleable, secure distribution of multicast keys

- Access control enforced

- Key distribution mutually authenticated

- Liveness proof

- Key itself doesn't cross the wire

- Doesn't unnecessarily burden intermediate communications devices (routers don't need to join a secure multicast group)

- Independent of underlying multicast protocol

- Uses IPSec

- Uses ISAKMP/Oakley type messages for key management

- Allows for incremental deployment

Overall:

Creation of Secure Group:

Policy Management

various people have done some work on this

Tunnel Management

people are looking into various issues in TM

Some interest in doing SNMP MIB -> need to support this

Some areas need OIDs which need to be plugged into IANA

- what next ? Have we missed anything out which needs to be in IPSecond

management maybe ?

draft-ietf-firewallmib-19.txt

Can't use IPSec for object encapsulated security (email use S/MIME or PGP) Use IPSec for Link-to-Link security.

http://ISAKMP-TEST.SSH.FI/

- this was really a marketing thing

- a new draft wll be done.

Introduction (Russ Housley)

CMS (Blake Ramsdell)

MSG (Blake Ramsdell)

CERT (Blake Ramsdell)

ESS (Paul Hoffmann)

CRS (Mike Myers)

Add CRS to the WG Charter ? (Russ Housley)

Interoperability (Tim Dean)

Algorithm Independent

- no longer dependant on RSA

- backwardly compatible with PKCS7v1.5 when RSA

is used

Includes signedData and envelopedData types

- other PKCS7 wrappers are not needed by S/MIME

Which document will specify the mandatory (MUST) algorithms. this could be put in either CMS or the Message Specification document so other uses other than for S/MIME can be catered for. Most people think it is best put into this document. The question then arises as to what the MUST algorithms are:

• Signature Only: DSS with SHA-1
• Key Management: Variant of DH
• Symmetric Algorithm: must be easily exported and also offer confidentiality - Choose 3-DES (3-DES CBC - uses 3 keys rather than 2 keys)

Once CMS02 has been done then CMS03 will contain:

- addition of authenticated Data

- planned to be final version and go to last call

Evolution from V2 Specification to V3.

Add support for DH, DSS in addition to RSA etc. SHOULD -> Weak Crypto, MUST -> 3-DES (This may all be moved to CMS document ?)

Also a few other changes have been made and PKCS10 may move out of this document and into the CRS (Certificate Request Syntax) document.

Also some certificate generation issues need addressing.

Q: What about the separation of encryption and signature keys ?

A: This would probably live in the CERT draft rather than this one.

Another change that is needed is the addition of certificates as authenticated attributes.

This contains the profile of PKIX part I. It uses keyUsage and basicConstraints as defined in PKIX part I and has email address as part of Distinguished Name or rfc822 name.

There are still some concerns about string types e.g. whether Universal string is available etc.

One issue - certificate chaining is now formed by strict chaining based on the Distinguished name - there are other ways of doing this but no decision has been taken yet.

Q: There is a statement in the drafts saying something like "signatures are invalid if the From: field in the email message and the rfc822name field in the certificate are not the same" -this restricts usability and so would like to change to say that the user will be told if they don't match but it won't specify that verification fails. The From field in the email message sometimes gets mangled etc as it is in transit which would cause problems. Apparently it turns out the draft says do something if they don't match but doesn't actually specify what to do. It may be nice to put in some kind of qualifier about this anyway.

These weren't in S/MIME v2 but can be in v3 and some can go back to v2. They are meant for people who need additional security to that in S/MIME e.g. the US DoD is an MSP world. ESS will make S/MIME enough like MSP to satisfy the US Dod i.e. it will do all the S/MIME stuff and also support other algorithms etc

i) Basically get signed receipts saying "I got this message and was able to verify the signature". That is all - there is nothing about how processed.

ii) Security Labels - can say on a message what kind of security a recipient should have - allows specification of security policy.

iii) How to use the messages in a secure mailing list. There is a danger of getting into a loop so some stuff is put outside the encrypted content so a list can recognize it and say it has seen it before and not send it on forever.

Q. What about certifiable timestamps?

A. This would probably be OK to add this if it was written up as it is an ESS.

ASN.1 - the version is important and all drafts use 1988 ASN.1 as there are compilers available. Some types are missing from 88 ASN.1 and the 93 Specification is different but there are no compilers available yet.

This was the same talk as given in the PKIX WG - for details see the PKIX meeting notes.

This discussion is not needed as the CS document will be in PKIX so all that is needed in this WG is a page or two specifying how CRS is wrapped up in a MIME message.

There is a need for interoperability across protocols.

e.g. S/MIME X.400 + MSP Security

Internet ---------X---------- X.400

Where X = Gateway

Is there any way to obtain such interoperability?

A way needs to be defined to allow for the carriage of protected objects. There was some small level of interest but this was not great.

Agenda:

• SIP
• Process of moving SIP forward
• SAP
• Secure SAP
• Multikit
• Future tasks

Changes moving from v3 to v4

- reliability

- call disposition

- delegation

- registration

- location

Much discussion.

Multiple directories (bandwidth issues)

Remove TTL Scoping issues

GZIP - not well specified and not implemented

- should this be removed ?

Deletion Messages

Hope to release SAP and Secure SAP for WG last call in Jan 98.

(From my talks with Colin and Mark the following possible problems were identified:

- want just one mandatory (PGP because free)

- algorithms must be unencumbered

- referring to other IDs (openPGP/S/MIME) may cause problems and what happens if they change )

Agenda:

SPKI Draft Progress (Carl Ellison)

Immediate Tasks

SPI and Web Access

ShrinkWrap

The requirement draft has expired. Should it be split into 3 pieces (this is the certificate format draft).

i) Theory - to be informational RFC

ii) Structure -to be standard RFC

iii) Examples - to be fleshed out for applications

Feedback is coming from the implementers and a reference implementation has been finished. Interoperability testing still needs to take place.

- most *-forms have been removed

- tags are assumed to be positional, append (ie appending stuff to a tag can only restrict it and not expand it)

- separation of name and authorization certificate forms (easier to explain and possible to omit name processing)

- applications, with feedback.

- certificate path discovery (CPD)

- prebundled packages for now

- related to the network routing problem

- experience allocating/delegating authorization

- spell out on-line messages (separate draft)

Questions:

- sequence structured to allow presenter to present the whole certificate path to the verifier to simplify things and allow the verifier to miss out the certificate path discovery stage. There was a comment that this CPD wasn't difficult anyway

- PKI Format (public-key(rsa-sha-pkcs1(e...)(n...))). There was a lot of arguing about thi as the way it is done here means that people will need several certificates with the same key so the decision was to remove the stuff like sha and pkcs1

- date/time nit " " vs "T" vs "-" (choose one and it'll be fine)

- symmetric keys (?) these are called secret keys but this could confuse with private keys.

- display types for all types or only special ones ?

Eric made the comment that DSS can only be used with SHA as use with anything else opens you up for attack.

There was lots of discussion about PK Formats as there are lots of security issues, which need to be understood so the discussion will continue on the mailing list.

- allow symmetric keys (a.k.a. secret keys) - most people want this removed and not made optional. There was an idea to make it a private extension.

- need to specify how algorithm are added - maybe these should be limited in order to aid interoperability and allow the user to ad extensions to the set ?

Sort out documents / cut down / clarify

Goals:

Working Demo

Identify any potential problems

Requirements:

Easy to manage

Easy to extend certificate chains

- allows verifier to reduce certificate chains

- use TCP

- security of protocol depends on security of SPI certificates

- prover has to provide everything in the correct order