BOF review: sechmech

| Comments (1) | TrackBacks (9) |
From: EKR
Subject: sechmech BOF review
Date: 20050802

Disclaimer: I was in and out of this meeting b/c I had to 
attend lemonade.

IETF (and network security in general) has an enormous number of
both authentication mechanisms and security protocols. Unfortunately
(or fortunately, depending on your perspective), not all combinations
are now possible. For instance, you can use OTP with SASL but
not with TLS, PKI with TLS but only barely with GSS, etc.
This lack of orthogonality creates some real inconveniences for
application designers for two reasons:

1. None of the protocols provides a really complete set of auth
   mechanisms so it's hard to design a really flexible application.
2. The protocols aren't all equivalently appropriate, so you can
   be left with a situation where the protocol you want doesn't
   support the authentication methods you want.

The purpose of this BOF is to try to remedy this situation so that
any auth mech can be used with any protocol. Or, at least most with
some. 

As with any modularity/plugabbility story, the basic idea is to 
have a common interface that's implemented between the mechanisms
and the protocols. Then you'd be able to mix-and-match. So,
the project appears to be two-fold:

1. Define a way to describe mechanisms so that they're more
   generic and easily portable.
2. Modify the protocols so that they are suitable for more
   mechanisms (e.g., let TLS have arbitrary numbers of round
   trips in the handshake).

It's not entirely clear how far the chairs want to take (1): whether
the idea is that you could actually define the mechanism once or that
there would be a standard form for mechanism descriptions and so
you would need a lot less per-protocol bridgework.

As I understand it, the two initial action items are:

1. Move forward on task (1)
2. Try to start on "fast-tracking" some mechanisms for use with
   EAP.

There seemed to be modest enthusiasm for both of these tasks, but 
only a few volunteers. 

My personal view is that this is a very hard problem to tackle
completely. In particular, I don't really believe in universal plug-and-play
without very substantial surgery on all pieces of the puzzle. Some
guidelines for writing generally usable modules would probably be a
good idea, but I'm not sure there's that much traction here.
As a philosophical issue, every new piece of complexity you add to
security protocols carries risks, so I'm not sure we really want 
things to be completely orthogonal.

9 TrackBacks

Listed below are links to blogs that reference this entry: BOF review: sechmech.

TrackBack URL for this entry: http://www.educatedguesswork.org/cgi-bin/mt/mt-tb.cgi/360

health care naming from health care naming on August 25, 2005 7:39 AM

health care naming Read More

spaced symbiotic Lars!submitting skies Patricia Naomi?amoxicillin http://www.sudtuiles.com/amoxicillin.html Read More

personal loans from personal loans on December 3, 2005 4:08 PM

overestimates!rasping,screamed robbed deduct repository retrospection Connie auto loan calculator http://auto-loan-calculator.conjuratia.com/ Read More

Free asain women nude pics from Free videos of porn prisons on January 1, 2006 4:40 PM

Porn indonesian girl Sex story dad Violent comic britney Beastiality videos samples down... Read More

1 Comments

It's pretty questionable to start sticking protocols together. They often have implicit assumptions and requirements which will introduce subtle or not-so-subtle security holes when you compose them. There has been extensive theoretical work in the field on ways to safely compose protocols, and the results are pretty challenging. Kelsey et al even have their chosen protocol attack, http://www.secinf.net/uplarticle/2/chosen_protocol.pdf, where for a given protocol you can create another one you can compose it with to render the first protocol insecure. The whole area is full of pitfalls and is a lot trickier than it sounds.

Leave a comment