headers
Jeffrey Altman | 10 Nov 2005 20:39
Favicon

IETF64 Kitten WG Summary

The Kitten working group met at IETF64 on Wednesday morning.

The presentation materials are available at:
   https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64

The Audio Stream is available at

http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf64/ietf64-ch8-wed.mp3.1

The Jabber Logs are available at:

http://www.xmpp.org/ietf-logs/kitten <at> ietf.xmpp.org/2005-11-09.html

---------------------------------------------------------------------------------

The Kitten Working Group continued its efforts to use the IETF meeting
time for providing high-bandwidth work time to make progress on active
documents.   Unlike the Paris meeting, this room suffered from a lack
of microphones sufficient facilitate our purpose.   I propose that rooms
should provide five microphones.  One for the chair, one wireless for
the presenter, two microphones for front row participants who have read
the documents, and one floor microphone for others.

---------------------------------------------------------------------------------

Summary of document status:

* PRF API extension for GSS draft -07 submitted to IESG

* PRF API extension for GSS KRB5 mech draft -04 submitted to IESG
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Yu | 10 Nov 2005 20:42
Picon
Favicon

IETF64 SASL WG summary


SASL WG
Tuesday, November 8, 2005
09:00-11:30

SUMMARY
=======

Thanks to Bob Morgan for scribing.

SASL base spec is late; Kurt to revise and post new version this week.
No objections to WGLC for the GSSAPI mech, but require positive
support to progress.  Plain mech will hold for base.  Previous
consensus during IETF63 for taking CRAM-MD5 off standards track, but
objections in mailing list.  Some people prefer standards track for
CRAM-MD5, but do not object to making it Informational.

DIGEST-MD5: Added channel bindings text.  Dropped AES CBC mode with
separate IV.  Update ABNF to reference RFC.  Some discussion about how
to get AES counter mode text written.  Some remaining issues about ISO
8859-1 compat with HTTP DIGEST.  Check with apps area.

SASL base: Minor changes re error handling, empty initial server
challenge, etc.  Some proposed cleanup of security considerations
section.  Discussion re IANA considerations re family of mechs.
Consensus for delegation to registrant upon assignment.

GSSAPI family of mechs: Simon will write some text; note base-32
encoding needs checking vs DNSEXT.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Salowey, Joe | 11 Nov 2005 20:27
Picon
Favicon

EMU BOF Summary

EAP Method Update (EMU) BOF
Thursday, November 10, 2005
9:00 - 11:00 AM

This was a continuation of the SECMECH BOF from last IETF, but it
focused on the EAP method standardization work item.  The goal of the
BOF was to determine if there was interest to work on the
standardization of a small number of EAP methods.  There were
presentations on requirements for EAP methods and different types of
methods.  We had a discussion on the different types of credentials and
authentication infrastructures that methods can support.  In the end we
reached consensus to create a working group to look at three things: 

(1) an update of EAP-TLS for certificate-based infrastructure 
(2) a method based on strong shared secrets
(3) a method based on using existing password infrastructure such as AAA
servers password databases

It would be better if some of these requirements could be combined into
one mechanism, however it was brought up that this may not be possible
to do and still maintain compact mechanism implementations that are
usable in constrained environments.  After these work items are done it
will be possible to add additional items to the working group charter to
work on additional methods.  The meeting concluded with presentations on
several EAP method drafts.
Permalink | Reply | 0 comments |
headers
Russ Housley | 24 Nov 2005 20:12

Security Area Response to Hash Function "Breaks"

Below is a summary of the discussion that occurred at the SAAG 
session during IETF 64. When MD5 or SHA-1 is used to support digital 
signatures or used by itself, recent cryptographic research findings 
indicate the need for a transition.  Therefore, I encourage all IETF 
WGs to follow the lead of the Security Area in transition away from 
MD5 and SHA-1 toward SHA-256.

TCP-MD5 is one example where a transition is needed.  In this case, a 
transition to HMAC-SHA-1 or HMAC-SHA-256 seems like a reasonable move.

Russ Housley
Security Area Director

= = = = = = = = = =

During IETF 64, the Security Area Advisors Group (SAAG) session was 
dedicated to the discussion of hash function "breaks" and the 
appropriate IETF response to this situation.

Eric Rescorla from gave a presentation on deploying a new hash 
function.  The presentation is based on a paper that Eric co-authored 
with Steve Bellovin.  All of the IETF security protocols that were 
analyzed required work in order to support transition to new hash 
functions.  The paper is available at 
http://www.cs.columbia.edu/~smb/papers/new-hash.pdf

Russ Housley gave a presentation on the Security Area response to 
these hash function "breaks."  We should "walk, not run."  This is 
not a problem yet, but as the attacks are improved it will become a 
problem.  Russ shared his conclusions from the NIST Hash Workshop
(Continue reading)

Permalink | Reply | 0 comments |

Gmane