44th Internet Engineering Task Force (IETF) Meeting
Minneapolis, USA 15th March 1999 - 19th March 1999
Edmund Whelan, University College London
Contents
A) IP Security Protocol WG Mon am
B) Secure Network Time BOF Mon pm
C) XML Digital Signatures BOF Tue am
D) Authentication, Authorization and Accounting WG Tue pm
E) Common Authentication Technology WG Tue pm
F) S/MIME Mail Security WG Wed am
G) Public Key Infrastructure (X.509) WG Wed pm
H) Open Security Area Directorate Meeting Thu pm
I) Transport Friendly ESP BOF Thu pm
J) MMUSIC Wed am
K) Glossary
A) IP Security Protocol WG (ipsec)
===============================
Agenda (1) Document Status Moskowitz
(2) IPSec MIB Tim Jenkins
(3) Deprecating 1DES J. Gilmore
(4) IKE SAs with Non-fixed IP Addresses Yael Dayan
(5) IPSec Interaction With ECN Sally Floyd
(6) Open Items
(1) Document Status - Moskowitz
There is one more transform for authentication - RIPEM-MD. This will
go into last call next week.
RFCs 1825, 1826 and 1827 have been obsoleted by the new RFCs
RFCs 1828 and 1829 (AH and ESP transform) and RFC 1852 (Triple DES) are not
obsoleted and will be moved to historic.
In order to get to draft standard from proposed standard the only major
work item is the MIB.
(2) IPSec MIB (Management Information Base) - Tim Jenkins (TImestep Corp)
This is the only major work item left in the working group
Objective:
- monitoring only of IKE and IPSec
- separate branches in MIB tree:
- ISAKMP DOI independent
- IKE
- IPSec (SAs)
- intended to provide a base for application specific uses of Phase 1
and Phase 2 SAs.
- IPSec branch:
- entity stats
- six IPSec Phase 2 SA tables
- inbound and outbound separate
- ESP, AH, IPCOMP
- ISAKMP branch
- entity stats
- traps for error and attack detection
- ...
- IKE branch
- entity stats
- IKE DOI-dependent portion of Phase 1 SA table
- protection suites as defined in ISAKMP
- traps for error/attack detection
- Table Linkage
ISAKMP SA table <-- IKE SA table
^
|
Protection Suite Table
|
v
IPSec Table (6 tables)
Issues:
- Is the basic architecture correct
- How high up should the branches split
- Should we provide multiple tables to make it easier to hide more
sensitive information
- IPv4 and IPv6 addressing - currently propose duplication of addresses
everywhere needed
- indexing of protection suite table - needs many objects for uniqueness
- too cumbersome to use same as index
- should there be two documents - IPSec MIB and ISAKMP MIB ?
(3) Deprecating 1DES J. Gilmore (presented by Hugh Daniels)
DeepCrack cracked 1DES and showed this could be done with relatively few
resources and over a matter of days. This has shaken faith in 1DES as an
algorithm which the IETF mandates use of.
[Aside: Electronic Frontier Foundation used its DES cracker to decrypt a
DES encrypted message in about 23 hrs for less than $250,000 - Jan 99]
The question is "How can we get rid of 1DES quickly ?"
Currently, 1DES is used for bulk encryption and for negotiating key in
IKE and applications MUST support 1DES
In the meeting no-one wanted to use 1DES the only question was whether to
keep it as a mandatory algorithm or not. The main argument for leaving it
as a MUST was for backwards compatibility. There was much discussion and
the comment was also made that it depends on your threat model - if all you
have to worry about is joy hackers then 1DES is sufficient. Also there should
be a standard and easy way of getting rid of algorithms once they have been
shown to be insecure. There should be two algorithms so that if one is
broken there is still one which can be used until another algorithm is
put in place. The main algorithm to "replace" 1DES are either 3DES or DES-X
as these are the most well-understood within the cryptographic community.
Straw poll: 3DES MUST IMPLEMENT. Many yeahs, some objections
DESX MANDATORY: not many.
Remove DES from MANDATORY: some
Keep DES in the MANDATORY: more
(4) Establishing IKE SA's with non-fixed IP address - Yael Dayan
This is a new idea - using aggressive mode means that the gateway must
do D-H operations before it can trust the user.
ISAKMP is okay but you only get the IDs in the 3rd or 4th messages
This is a new Phase 1 exchange proposal when using pre-shared keys and
non-fixed IP addresses so can't use the IP addresses to look up the keys.
This is basically like ISAKMP but moves the IDs up to earlier messages ?
It was thought that this was of some interest but should be discussed on the
mailing list.
(5) IPSEC Interactions with Explicit Congestion Notification - Sally Floyd
RFC 2481 - Explicit Congestion Notification
There will be a draft soon looking at the interaction between IPSec and ECN
- it will be draft-ietf-ipsec-ecn-00.txt
ECN is an experimental standard and redefines two bits in the IP header
to be:
(i) ECN Capable Transport Bit - set by end node - "I understand ECN"
(ii) Congestion Experience Bit - set by router - "I experienced
congestion" and is set instead of dropping packet and the
receiver acts as if the packet was dropped.
The problem is that you cannot use ECN with IPSec because there are
interactions between ECN and IPSec tunnel mode. The inner header gets
copied to the outer header, sets congestion bit, gets decapsulated and
the relevant bits get thrown out.
There are two ways this can be solved:
(i) Limited functionality option:
- outer header in IPSec tunnel always marked as not ECN compatible
- if packet encounters congestion it is dropped
(ii) Full functionality option:
- outer header in IPSec tunnel can be marked as ECN compatible
- if encounters congestion mark it and don't drop it
- security of this approach is discussed in the draft
Detailed changes:
- add new field to SA database indicating whether ECN tunnels allowed
- changes IPsec tunnel header processing for the ECN fields
- add optional ability for tunnels to negotiate use of ECN
Comments:
- We don't want to go back and change things at this stage for something
which is only experimental anyway
- Reply that ECN is only experimental as IESG aren't sure the advantages
gained justify the use of two valuable bits in the IP header and not
due to any shortcomings in ECN
(6) Open Items
(a) Error codes need sorting out
(b) IKE - some fields are not protected (eg version number). There is no
obvious attack but it should be fixed anyway. This issue was going
to be deferred because didn't want to delay draft but it should
be looked at now.
(c) Need to sort out Best Common Practice document
(d) Need to move the PKI requirements document forward because having
having problems in the field with compatibility issues when using
certificates.
- maybe hold BOF at next IETF
- need to take offline with Area Directors (PKIX, IPsec etc)
(e) ICMP Error numbers - what happened ? The interaction between ICMP and
IPsec seems open to mischief.
(f) Next VPN interoperability workshop is May 23-28 in Santa Barbara and
will include IPsec-IKE-SA
(g) IPsec remote access: ietf-ipsra@vpcn.org
subscribe to: ietf-ipsra-request@vpcn.org
B) Secure Time BOF
===============
Agenda:
(1) Admin
(2) Charter Issues
(3) Secure NTP Draft
(4) Open Discussion
(1) Admin
Had previous BOF in Orlando at last IETF meeting
Mailing list: ietf-stime@stime.org
Subscribe: ietf-stime-request@stime.org with "subscribe" in body
WWW: http://www.stime.org (there is a draft document here)
(2) Charter Issues
- How does the internet system obtain reliable time without a useful onboard
clock ?
- Draft charter was more extensive than is now being proposed but it has been
decided to stick with the basic issue and just add security to the widely
used NTP protocol.
Basics of the charter:
- 12 month lifetime
- concentrate on securing NTP
- schedule :
- Today: agree charter
- May 99: 4th draft of authentication scheme extensions to NTP
- Nov 99: agree on NTP extensions and submit for RFC
- Feb 00: end WG
A straw poll agreed to reduce the charter as proposed
C) XML Dsig BOF
============
Agenda:
(1) Signature Layers
(2) DOMHASH
(3) XML Dsig
(4) FSTC Input
(1) XML Signature Layers
XML (eXtensible Markup Language)
XMLDsig - signature syntax; XML hashing
Other - Certificate policy, signature semantics etc
There was some discussion about specific signatures and alternatives. The
draft needs to give reasons for preferring one over another. Much was
application specific and the question of what to do if one signature fails and
another doesn't ?
(2) DOM Hash - Hiroshi Maruyama (IBM Research)
draft-hiroshi-dom-hash-01.txt
There can be variance in an XML surface string when the basic underlying
format is the same due to whitespace, character encoding, order etc
The Hash value must then be based on the internal structure rather than
this "surface string" (Document Object Model)
There is a namespace consideration - need to expand name to a real
namespace name as you can define prefixes outside the document itself and
this must be expanded so you can be sure you are signing the whole thing.
There is an implementation of DOMHash available from:
http://www.alphaworks.ibm.com
It was also noted that W3C doesn't require XML generators/parsers to handle
comments so these must be left out of any signatures
There was a question over whether you should sign the surface string or a
canonical representation. If the former then you are just signing a file
and you can do this already. If the latter it is like ASN.1.
(3) XML Digital Signatures (should have been Richard Brown - Globeset but he was snowed in)
draft-brown-xml-dsig-00.txt
Requirements:
- authenticate XML and arbitrary binary content
- algorithm independence
- composite documents
- external/internal items
- handle endorsement, multiple recipients and co-signatures
Overall structure:
resource info block
originator info block
recipient info block
other attributes
signature algorithms info block
encoded signature value
Originally derived for PKCS#7 but changed to make it more flexible
Denis Pinkas commented:
- draft lets you sign a part of the document so signature can be part of
the document
REPLY: this was specifically requested by the financial sector as they
want to be able to transfer signature on one part of document A
into document B etc
- need policy referenced so can know if using the same one as the signer
- does this BOF include all the stuff which was discussed at the last
IETF around digital signatures. If it does then you need to deal with
things like timestamping, policy etc
(4) FSTC - Financial Services Technical Consortium (Milton Anderson - not here)
Want to add criticality flag for resources whose verification is necessary
for a signature to be valid
eg - version field
- nonce, sigtype, timestamp, signing location, user
- minor changes to and structure
Comments: CMS experience with the criticality flag has shown this to be a
_BAD_ idea so they removed it
(5) Assorted points
(a) What is the relation to W3C ? There is a W3C workshop on this in
April and details can be found at:
http://www.w3.org/1999/02/ds-xml-cfp-19990218.html
(b) What is the relation to MIME re packaging, multipart/signed etc ?
(6) Draft Charter
There is a 2nd draft out
Apr 99 - submit draft to WG
Jun 99 - updates to Internet Drafts
Jul 99 - Oslo IETF
Aug 99 - Submit final internet drafts and go to IETF last call
Sep 99 - Proposed standard RFCs to RFC editor
Comments: Need to specify more stuff in the charter about what is actually
needed
(D) Authentication, Authorization and Accounting WG (aaa)
=====================================================
This working group will quantify and qualify the aaa problem; produce
informational RFCs; not develop protocols; separate the 3 A's
Applications which will make use of the AAA service include
- Remote Access (this is the main driver)
- VPNs
- Bandwidth broker, voice over IP, Mobile IP etc
Authentication
--------------
- multiple existing algs and techniques
- what persistent data is required
- what features are required in the protocols
- how many protocols are necessary
Accounting
----------
- Fairly well separable from the other two areas
- transaction rather than session oriented
- needs for billing
- needs for resource allocation, usage, network engineering
Some people wanted to avoid the use of the word "billing" because this is a
customer issue.
Note that accounting is about what resources are used and by whom; monitoring
is just about what resources are used.
Authorization
-------------
- least well understood of the three areas
- How does it relate to policy ?
- Does it require authentication ?
The meeting decided that the various subgroups would meet and feed back into
the next meeting. I couldn't go to the next meeting due to a clash with
another one. The minutes will contain details of what they discussed/decided.
(E) Common Authentication Technology WG
===================================
Agenda:
(1) Summary of CAT Session in Orlando
(2) PKINIT Resolution
(3) Kerberos Revisions
(4) GAA-API
(5) Other Drafts
(6) Java GSS Bindings
(7) Low Infrastructure Mechanisms
(1) Summary of CAT Session in Orlando
- minor edits to GSS v2 and C-Bindings documents (gone to IESG)
- PKINIT was to be restructured
(2) PKINIT Resolution
This has been done. ie
- removed digital signature option
- removed private key storage option
- modified server response to use CMS by reference
- some clarifications
Planned changes
- remove reference to PKCS#6
- change certificate type to PKInitCertificate
- a few more including KDC returns
Issues left
- should the request message use CMS (eg signedData inside envelopedData)
- requires too many options to be supported
- error messages collide with user to user
- Cliff will address this in Kerberos Revisions
- What error message should be used if the server/KDC name in the
PKAuthentication is wrong ?
- PKINIT supported encryption types need to be specified by the client
to the KDC
- Kerberos uses a SEQUENCE of INTEGERS
- will be addressed in Kerberos revisions
- Should the PK encryption types be OIDs ?
Comments:
Denis Pinkas: it is best practice to use different certificates for signing
and encryption - this isn't done here.
Others: supported this comment
(3) Kerberos Revisions
The revision is not yet complete
Revisions in progress:
- integration of encryption specs
- numbering of error messages
- tighten definitions of optional/default values
- direction bits if addresses are omitted
- if the authorization data elements are not understood this results in
rejection - wasn't specified in draft
Open Issues:
- how to deal with added fields eg KRBERROR and ticket extensions
- encryption types
- KRB-CRED optional issues
Encryption types
----------------
- Problem in CMS around how KDC knows which algs a client supports
- Solutions : list algs in pre-data field
list algs in KDC-REQ
- Also should we be using OIDs ?
Support for additional/changed fields
-------------------------------------
- motivation:
- e-typed data, encryption types, ticket extensions
- issues
- how do we maintain interoperability with older versions which don't
support them
A list of issues will be sent to the mailing list, then there will be a 2 week
discussion period after which we should move to last call
(4) GAA-API
- new draft by next IETF
- work has been done on a reference implementation
- x500, x509 support nearly done
- ssl integration supports user certs
- working with other projects
- Xerox on CORBA integration
- Globus
Details at:
http://gost.isi.edu/info/gaa-api
http://gost.isi.edu/info/gssapi
The drafts are a little out of date but will be updated within 3 weeks
(5) Other drafts
There were some comments on the GSS-API v2 checksum
(6) GSS-API Java bindings (Mayank Upadhyay - SUN)
Should we have concrete classes or interfaces ?
He discussed the pros and cons and it seemed that concrete classes is the
preferred method
(7) Low Infrastructure GSS-API Mechanisms
- might have wider uptake if had easily deployable mechanisms
- employ pre-administered secrets, easy to implement
- avoid new servers
- low performance overhead
- easier to code than GSS
- avoid long term secret storage at client
- compatible with existing host login
Concern: Is this competing with SASL ?
Reply: They are two solutions to problems which overlap
Specific Mechanisms Proposed:
(a) GSS-API Easy Mechanism Denis Pinkas (Bull)
- draft-ietf-cat-gsseasy-00.txt
- just uses password
- easy to deploy
- change password protocol defined in document
Features:
- allows unilateral and multilateral authentication
- allows integrity and privacy
- supports anonymous authentication
How to strengthen a weak mechanism:
- EASY is based on 1-way crypto functions eg SHA1
- passkey derived from client name and passphrase
- authentication mechanism uses unique number (time and random No)
Encryption Algorithms:
- Doesn't use DES or T-DES
- Uses 1-way hash functions - SHA-1/MD5
Comments: Most people think the use of this instead of conventional 3-DES is
a _BAD_ idea - it may be open to attacks whereas 3-DES is well
understood
There was a straw poll that indicated a strong majority felt that 3DES etc
was better than a new encryption scheme.
Discussion:
- should SHA-1 be used and MD5 be removed
- should HMAC be used (RFC 2104)
- ASN1 encoding - this is used in Kerberos v5 and is painful
There was a preference not to use ASN.1
(b) LIPKEY (Mike Eisler - SUN)
Lower Infrastructure Public Key Mechanism
Basically like TLS with passwords.
Uses SPKM (Simple Public Key Mechanism) and tweaks it a bit
There is a draft out
(c) There are also two more options proposed
(i) Digest Authentication and D-H enhanced digest
(ii) EKE/SPEKE/SRP Methods
Both have been discussed on the list but weren't presented here.
There was a straw poll to see if any interest:
GSS-EASY 12 people interested
LIPKEY 19 people interested
D-H... 10 people interested
EKE... 1 person interested
(F) S/MIME WG
=========
Agenda
Drafts
(i) CMS
(ii) X9.42
(iii) Avoiding small subgroups
(iv) MSG
(v) CERT
(vi) ESS
(vii) CERTDIST
(viii) DOMSEC
(ix) Examples
Security Policies and Labels
(i) CMS Draft Status Russ Housley
In IETF last call
- some minor comments received and addressed
- Birthday attack (crypto issue with 3DES key wrap alg - fixed)
- comments included into CMS 11
- harmonization between 3DES and RC2
- still waiting for X9.42 document
CMS 12 will be ready for IESG when X9.42 done and will be put in the
repository when it opens
Denis Pinkas has provided a _LONG_ change regarding whether the correct public
key is used. Basically says that the protocol document doesn't specify how
to validate a public key as this is outside its spec.
(ii) X9.42 - Eric Rescorla
An attack was found by John Linn on the key generation affecting X9.42.
It has been fixed by making the real RC2 keylength exactly the same as
the effective key length
The only other change is to use multiple OIDs
Basically this draft is finished and it will be sent to the list
(iii) Avoiding small subgroup attacks - Robert Zuccherato
This to do with small subgroup attacks on D-H
A new draft discussing the problem and how to avoid it will be written
The precise details of the attack were described and you need protection:
For Sender: ephemeral key -> OK
static key -> need protection
For recipient: if no decryption info available -> OK
if decryption info is available -> need protection
Methods of protection:
- public key validation by user (described in S/MIME X9.42)
- possibly encumebred by certicom (patent pending)
- public key validation by CA
- only realistic for static public keys
- choose (p-1)=2*q*r where r=product of large primes
- must still check whether public key is +/- 1
- compatible cofactor exponentiation (IEEE P13-63)
- compute shared secret in special way
- also possibly encumbered
The draft will be out soon and will let people know if they need to worry
about it
(iv) MSG Blake Ramsdell
In IETF last call
- no open issues
Comments: Paul Hoffmann said should put a sentence in saying that S/MIME v2
clients ONLY do RSA and not D-H
Seems okay to add this.
(v) CERT Blake Ramsdell
In IETF last call
Comments:
Denis Pinkas raised issue of some wording about CRLs and checking them.
This was a contentious discussion and was held over to the end of the meeting
where the following was decided: The draft would be changed to read as follows:
"All agents MUST be capable of performing revocation checks using CRLs as
specified in RFC2459. All agents MUST perform revocation status checks
in accordance with RFC2459"
This allows people to use OCSP if they want to rather than CRLs.
Denis also commented on the possibility that leaf certificates won't
contain a Distinguished name but only an emailId. We refer to PKIX but if
PKIX doesn't address this issue fully then we will need to address it here.
Reply: The vast majority of people at the meeting felt that a reference to
PKIX was _ALL_ that is required.
(vi) ESS - Paul Hoffmann
In IETF last call
Some minor comments so there will be one more draft before going to IESG
(vii) CERTDIST - Jim Schaad
- no significant changes since last meeting, just need an example of D-H
and then move to IETF last call
(viii) DOMSPEC Bill Ottaway
New draft out in May, no comments have been received
(ix) S/MIME v3 Examples document - Paul Hoffmann
Draft is full of holes at the moment but he will fill them in
(x) Security Policies and Labels - Russ Housley
These labels are in the ESS document and no-one knows how they will get used.
An Informational document should be created to explain how security labels
can support security policies within an organisation.
Three major companies have agreed to allow their policies to be published
and to show how these labels can support policies
They are: Whirlpool
Caterpillar
Amoco
To do this document requires a WG charter change so an email thread will be
started to get this addressed by the IESG.
(G) PKIX WG
=======
Agenda:
i Status Update
ii Charter Changes
iii D-H Proof of Possession
iv CMC Draft
v PKIX Roadmap
vi Qualified Certs
vii Data Certification
viii Time Stamping
ix AOB
(i) Status Update
CERT/CRL - approved -> RFC 2459
KEA algorithms for profile - approved as informational RFC
HTTP/FTP operations - approved as proposed standard
CMP/CRMF/Cert Policy/OCSP - approved as proposed standard
LDAPv2 protocols/schema - approved as proposed standard
Work in Progress
ECDSA - Tim is doing some minor work on this
CMC/D-H POP/TimeStamp/DCS - all being discussed today
Qualified Certs - discussed today
CMMF - dormant (must be killed or can't close WG
Web based integrated CA service protocols - discuss today if anyone here
(ii) Charter Changes
This is to do with: TimeStamp/Qualified Certs/Notary/Attribute Certs
New Charter will be sent to list and then to Area Directors soon for
approval
(iii) Diffie-Hellman Proof Of Possession (D-H POP) Jim Schaad Microsoft
There is a draft "draft...pkix-dhpop"
It concerns a new DSA based POP algorithm:
- signature value based on SHA
- signature value extended SHA
Needed to replace previous method as this didn't work. The only work left is
to write the examples and then can move into last call
(iv) CMC draft Jim Schaad Microsoft
Changes from 02 -> 03
- link identity and POP information
- Revisions to state reduction technique for POP for encryption only key
- editorial changes
The identity is linked to the POP Info by:
- shared secret identity info provided for entire Full PKI Request
- POP info provided on a per cert request basis
- link the two by forcing the client to sign a quantity into each request
that is signed
Can only attach if get {shared secret, random No} which comes up with same HMAC
There will be mods:
- Key archival and recovery
- LRA/RA clarifications
- examples
There are some politics around the issue of key recovery but this will
probably be covered in an informational RFC.
(v) PKIX Roadmap Draft A. Arsenault
- 01 missed the deadline so will be put out soon
Changes from 00:
- terminology clarification
- POP section added
- PKIX history section added
- Document status updated:
- RFCs 2459, 2510, 2511, 2527
- CMMF to be dropped
- Other IDs
- description of new documents
- DCS (Data Certification)
- Time Stamp
- Qualified Certs
- Section 4.5 deleted as it got very messy
Remaining issues:
- Name constraint section
- Path validation
- Validation of new sections by authors
- Keep up with rest of WG
(vi) Qualified Certificates
First draft is out
Main objectives are:
- certificate profile is aimed at supporting legally recognized electronic
signatures
- provide mechanisms to express identity of subject but not how identity
formed
- does NOT prescribe certification with privacy sensitive info
- Specifies optional data structure which can be put into subjAltName
eg DoB, place of birth
- still keeps the standard technical name in the normal fields
- information is available from http://www.accurata.se/QC/
Settled Topics:
- mandatory country name -> not mandatory
- don't want to tie country name into the personal data field
- general properties of qualified certificates
- attribute semantics in personal data field (some disagreement)
Unsettled:
- mandatory names in subject field
- policy OID for the QC profile regarding issuerName, subject and
personalData fields
- defining OIDs
- example certificate in profile
(vii) Data Certification Server - Robert Zuccherato
draft-ietf-pkix-dcs-00.txt
There will be another draft out very soon. (couple of months)
DCS (nee "notary") provides a notary service which certifies the correctness
of signatures/certificates
There are no changes since the last draft but work needs doing on it
There have been comments about
- ASN.1
- explanations about what DCS is doing
- specification of OIDs, socket numbers etc
(viii) Timestamping - Robert Zuccherato
New draft will be released soon
The only major change is going to be the support for timestamp tokens which
don't contain a message or nonce - clients could "pick up" a signed time to
prove an event happened after a given time.
Some changes will be made to OIDs, socket numbers but the document is
stable and close to completion. Should go to last call after the next version
Patent Issues:
- There is a patent section in the draft
- Surety/Bellcore have filed legal charges against an earlier version of
the draft citing patent infringement
- this issue must be dealt with before the draft can be approved
The WG chair said we should continue working on it but it can't be moved
forward unless/until the patent issues are resolved.
There was a query over whether the same patent issues apply to DCS.
(ix) AOB
(a) Profile - Tim Polk (NIST)
RFC 2459 came out in January '99
- minor errors have been noted which will be fixed
- an errata sheet will be sent out detailing changes which will be made
when move from proposed to standard
- eligible to go to draft in July '99
- must identify 2 independently developed CAs which can generate ALL
mandatory fields and extensions as well as processing them.
- NIST is willing to coordinate this
(b) OCSP
- Approved by IESG - will be put out as RFC
Some clarifications:
- an OCSP server must support
- sign with same key as certificate
- sign with different key with special properties
- Client must handle it if signed by
- CA
- someone delegated by CA
- anyone the user chooses to trust
(c) Certificate Policies and Practices Part IV
There is some interest in making this a new draft
Probably make a new list for this as it is a bit off-topic
(d) Leaf Certificates - fat or low-fat Denis Pinkas
Want this certificate slimmer (about half the size)
- we have solved a lot of problems by adding more and more extensions
- this has made certificates big and we now want to put them on
smartcards where space is limited
(e) EDSI (Education Development Syndicate International ?)
Has security groups working on electronic signatures (not the same as
digital signatures per se but the electronic equivalent of real
signatures)
The draft will be available to non-members in 4-6 weeks
(f) Attribute Certificates - Stephen Farrell (SSE)
There is a draft "draft-tls-attr-cert" which specifies a way of using
attribute certificates for authentication in TLS
Also "draft-tls-ac509prof-00" profiles these certificates
Motivation:
- manageable authorization support
- flexible authorization
- delegation
This is staying inside the TLS group but is of interest here potentially
(g) Interoperability testing with OCSP Results
- 7 independent implementations of the OCSP client
- all used POST request forms over HTTP
- crlEntity and serviceLocator extensions were useful
- no base64 encoding required in POST requests
- Direct trust is under-specified
- method of hashing issuers public key differs from RFC 2459
- delegated trust of OCSP responder is popular
- NONCE support is desirable
(h) Simple Certification Validation Protocol (SCVP)
- Possibly a new work item for this WG
Certificate usage is getting complicated because of
- chain building
- certificate validation
- policy management
- trust management
- changing specifications
- differing profiles
Proposal is to introduce server-based trust ie send all stuff to the server
and it sends back whether you can trust it.
Applicability:
- routers, mobile devices (cell phones etc)
Pros/Cons:
Disadvantages: Requires an SCVP server and is a single point of attack
Advantages: simplifies devices, enable quicker/wider PKIX deployment,
centralizes policy/trust management
Comments: Some of this functionality is in the DCS document so should
work together
(i) Tim Polk (NIST)
There is a MISPC reference implementation
- NIST has reference implementations of a CA, RA and client
- src/executable for win95/98/NT
- no src for crypto just executable
- Conforms to the MISPC
- a profile of RFC2459, CMP and CRMF
- available upon request from
- http://csrc.nist.gov/pki/mspc
(H) Open Security Meeting (saag)
============================
(1) Working Groups
--------------
cat/ipsec/pkix/smime/idwg all met this time
(a) CAT
Basically went through what happened in the CAT meeting
- see my notes earlier
(b) IPsec
Basically went through what happened in the IPsec meeting
- see my notes earlier
(c) PKIX
Basically went through what happened in the PKIX meeting
- see my notes earlier
(d) S/MIME
Basically went through what happened in the S/MIME meeting
- see my notes earlier
(e) IDWG
The chairs weren't present so this wasn't discussed
(f) Working Groups which didn't meet this time
- DNSsec (some comment that it did meet but it wasn't a public meeting ?)
- new set of RFCs came out recently
- some issues remain around dynamic updating
- AFT
- OTP
- SecSH
- SPKI
- TLS
- WTS
(2) BOFs
stime/ipsra/ipsp/xmldsig all met this time
(a) stime (secure time)
Basically went through what happened in the STIME meeting
- see my notes earlier
Comments: Jeff Schiller - have NTP which already works well and can
even add authentication to this already but it isn't
very secure. This will be addressed by this WG
Question: Why is this different to running NTP over IPsec ?
Answers: (1) Maybe thats the best way
(2) IPsec works with SAs of around 15 minutes and you
you may not want to keep it around that long
(b) ipsra - IPsec Remote Access
There was some confusion over the term "remote access"
This WG/BOF is to address the following problem:
- I dial up to an ISP and get an IP Address and then want to
establish a tunnel into a corporate network and get authenticated
(c) ipsp - IPsec Policy
This went very well and it was agreed that a WG is needed to discuss
this issue. A policy WG was discussed but it was decided that
shouldn't be doing "core" policy just IPsec specific policy.
(d) xmldsig
Trade WG uses XML (financial use mainly) and authentication is needed
There is a real problem though:
- XML is a feature of the WWW Consortium (W3C) and there is an
XML/RDF workshop in April in Massachusetts. Most people
believed digital signatures in XML were important but were less
sure as to whether the IETF was the place to do the work if W3C
are going to do it anyway.
- The consensus was to wait until after the W3C workshop and see
what happens there.
(3) Triple-DES in IKE
This was a big issue which was brought up in the IPsec meeting
Proposal:
Make 3-DES mandatory in IKE
Reason:
Bulk encryption is only as strong as the IKE used to exchange keys.
Performance is not an issue in IKE
Problems:
May break backwards compatibility
Background:
1DES is now considered insecure
There was much discussion and a straw poll. The results were:
(1) 3-DES - everyone wanted this to be a MUST
(2) 1-DES - MUST about 5 people
SHOULD about 10 people
MAY vast majority
NB. The IPsec meeting had decided 1-DES should be kept as SHOULD. This
has been changed to be a MAY only. This is a larger forum.
Comment was made that PKIX will be available in a year or so anyway so
any implementations out there will have to undergo a major change anyway
in order to support them. They will want to do this so backwards
compatibility is not really a major concern here.
Comment: Need a standard way of removing/replacing algorithms as and
when they are shown to be insecure. Maybe this could be done
with Best Current Practice (BCP) RFCs as these are a lot
quicker to put out than standards track RFCs.
Comment: There is an advanced encryption standard effort at NIST and,
in about 2 years time there will be a list of standard
algorithms
Comment: It is a sensible idea to have two standard algorithms so if
one is shown to be weak you can rely on the other until you
can find a replacement.
(I) TF-ESP - Transport Friendly ESP BOF
===================================
This is concerned with allowing some of the encrypted IPsec header to be
seen by routers etc as this will let them do things like network
monitoring and also helps with satellite routing etc
There are two ways of doing this:
(a) Create a "disclosure" header at the start which is structured
(b) "leak" the start of the encrypted header by a variable amount which
could possibly be set by the user. This is possible because, by
chance, the really sensitive information in IPsec headers isn't at the
beginning whereas the useful routing information is.
There was a split as to whether you should weaken the security in this way
but it is clearly something which certain parts of the community want
eg network monitors, routing, wireless/mobile IP, satellite.
Jeff Schiller commented that if he _HAD_ to choose (a) or (b) then he would
choose (a) because it is more structured and has less chance of the user
slackening security by mistake. BUT he'd rather get run over by a bus.
Several mechanisms were discussed and it is clear that this is something
which is at an early stage with many options being put forward.
J) MMUSIC
This meeting was mainly concerned with SIP (Session Initiation Protocol).
The report submitted by Colin Perkins (also of UCL) should be consulted for
a full report.
SAP (Session Announcement Protocol) was also discussed to a lesser extent
and it was decided that Editorial Control of the SAP/SAP Security Document
will be passed over to University College London as we are doing all the
implementation work as well as writing the specification itself.
K) GLOSSARY
Below is a glossary of some of the commonly used acronyms in the IETF:
AFT Authenticated Firewall Traversal (WG)
AH Authenticated Header (IPsec authentication protocol)
ASN.1 Abstract Syntax Notation 1
BCP Best Current Practice
BOF Birds of a Feather Meeting
CA Certification Authority
CAT Common Authentication Technology (WG)
CERT S/MIME Ceritificate/CRL Profile Document
CERTDIST S/MIME Ceritificate Distribution document
CMS Cryptographic Message Syntax (S/MIME specification of PKCS#7)
D-H Diffie-Hellman Key Exchange
DCS Data Certification Server
DES Data Encryption Standard
DNSsec DNS Security Protocol (WG)
DOI Domain of Interpretation (IPsec document)
DOMHASH Document Object Model Hash
ECN Explicit Congestion Notification
EDSI Education Development Syndicate International
EFF Electronic Frontier Foundation
ESP Encapsualted Security Payload (IPsec confidentiality protocol)
FSTC Financial Services Technical Consortium
GAA-API Generic Authentication API
GSS-API Generic Security Services API
ICMP IPsec Certificate Management Protocol
IDWG Intrusion Detection (WG)
IKE Internet Key Exchange
IPsec IP Security Protocol (WG)
IPSP IPsec Security Policy (BOF)
IPSRA IPsec Remote Access (BOF)
ISAKMP Ipsec Security Association and Key Management Protocol
KDC Key Distribution Centre
KEA Key Encryption Algorithm
LIPKEY Lower Infrastructure Public Key Mechanism (in GSS-API)
MIB Management Information Base
MSG S/MIME Message Specification Document
NTP Network Time Protocol
OCSP Online Certificate Status Protocol
OID Object IDentifier
OTP One Time Password (WG)
PKCROSS Public Key Cross (using public keys for kerberos cross-realm auth'n)
PKINIT Public Key Initial (using public keys for initial auth'n in Kerberos)
PKIX Public Key Infrastructure (X.509) (WG)
POP Proof of Possession
RA Registration Authority
RFC Request For Comments
S/MIME Secure MIME (WG)
SA Security Association (re IPsec)
SASL Simple Authentcation and Security Layer (RFC 2444)
SCVP Simple Certification Validation Protocol
SecSH Secure Shell (WG)
SPKI Simple Public Key Infrastructrure (WG)
STIME Secure Time (BOF)
TF-ESP Transport Friendly ESP (BOF)
TLS Transport Layer Security (based on SSL)
VPN Virtual Private Network
W3C WWW Consortium
WTS Web Transaction Security (WG)
X9.42 S/MIME Draft detailing Diffie Hellman Key Exchange as in ANSI 9.42
XML eXtensible Markup Language
XMLDSIG XML Digital Signatures (BOF)