IETF Security Area Directors:

	Jeff Schiller <jis@mit.edu>
	Marcus Leech <leech@nortel.ca>

____

Which Working Groups Met in Oslo:
	CAT
	IPsec
	PKIX
	XMLDSIG (joint with W3C)
	AFT
	IDWG
	OpenPGP
	S/MIME

____

CAT:
	revising charter
	working on GSS-API for Java
	Kerberos revisions are going to WG Last Call

IPsec:
	explicit congestion notification proposal from Sally Floyd discussed
	Steve Bellovin gave a quick summary of IAB workshop
		please make sure there are no IP address dependencies in IPsec
	some IKE clarifications

PKIX:
	RFC 2459 - defect in cert path for X.509 validation has been
		reported to ITU; 2459 must be revised.
	policies and procedures for CA's document is being widely reviewed.
	time stamps and patents; there is some lawsuit in progress.
	Qualified CERTs - a European thing documenting how a legal name
		can be bound to a cert, published by the EU.
	Attribute Certificates - used to bind attributes to a public key;
		document in progress.

XML DSIG:
	XML Digital Signatures is working jointly with W3C; this means one
	document, not two.
	requirements draft is out.
	some controversy about canonicalization
	a revised, simplified top-level syntax was devised.

AFT:
	updates to RFC 1928 - socks.
	discussion of update to RFC 1961 - the GSS-API interaction.

IDWG:
	discussion on exploding out the requirements for the Intrusion
		Detection Exchange Format protocol.

IP Security Policy BOF:
	Multidomain IKE presentation
	possible role of COPS in IKE
	semantic model of IPsec policies
	charter discussion

OpenPGP:
	Key Server synchronization protocol discussion
	RFC 2440 revisions, draft due shortly.
	RFC 2015 revisions, new draft ready to go
	OpenPGP ready to advance to "draft" status; time for implementation

S/MIME:
	(hasn't met yet)
	five RFCs 2630 - 2634 all published
	time to revise charter to deal with remaining issues

BOFs that met:
	IPSP
	Secure Time
	IPSRA

Secure Time:
	purpose is to add some extensions to NTP;
	they're in "need to get to a working group" hell, while bashing charter

IP Secure Remote Access BOF:
	did not meet, but will continue

____

DNS-SEC and DNS-IND WGs merged.

Web Transaction Security (WTS) will shut down. Documents to be published as
experimental. This is SHTTP; everyone uses SSL instead. "An example of
expedient  overtaking ``better.''" - JIS.

Security Area Working Groups are going to have web pages - Jeff will be
whacking up better web pages on his flight back home.


The IESG section of the IETF web pages contains the state of documents in
the standards process.

____

NOTA BENE: IP Security Will Deprecate DES and 3DES will be the new required
cipher, HOWEVER, there is a strong desire to have an additional required
cipher. Candidates: CAST-128, BLOWFISH, AES Candidates (these are 128 bit
block ciphers - if you coded for 64 bit blocks, Beware). AES is a year away
from final selection. Maybe CAST-256, and TWOFISH.

Major question: how to select an additional cipher?

Bob Moskowitz thinks that we need a very fast cipher for small boxes. Other
criteria include: speed, not DES based, no intellectual properties
problems, no cryptanalytic deficiencies ("secure"), 128 bit block size,
keyspace >= 128 bits (key strength versus key size), key set up time.

Next month the AES candidate list will be narrowed to five.

Pushback to wait until the AES selection is finished.

Bellovin: we should at least wait until next month because the AES
candidate list will be narrowed, and the "Crypto" conference will happen,
and we can get feedback.

saag@lists.tislabs.com (majordomo) is where the SAAG mailing list lives.

____

It would be a good idea to have DOI (protocol) numbers for each of the AES
cipher - this is an IPsec WG issue.

It would also be a good idea for implementors to make sure that their
software can really do 128-bit block ciphers.

Also make sure that software is ready for long keys (> 128 bits), though it
may be a year or three before this is really required.

____

Steve Bellovin wants feedback on an IAB Security Mechanisms draft document
which is intended as a cookbook for the rest of the IETF to pick
appropriate security mechanisms during protocol design - this would also be
useful to various software developers.

	your itinerant Security Officer,

	Erik <fair@clock.org>