Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

On Wed, Aug 24, 2005 at 03:40:17PM -0700, Bernard Aboba wrote:
> > Does tunnelling various other weak mechanisms over TLS meet said
> > criteria?
> 
> If "weak" means mechanisms that do not generate a key (e.g. 
> MD5-Challenge), then these would violate RFC 4017 mandatory 
> requirement 6:

No, I used "weak" to mean mechanisms that are subject to off-line
dictionary attacks by eavesdroppers or MITMs.

>    [6]  Protection against man-in-the-middle attacks.  This corresponds
>         to the "Cryptographic binding", "Integrity protection", "Replay
>         protection", and "Session independence" security claims defined
>         in [RFC3748], Section 7.2.1.
> 
> > CAT WG closed years ago...
> 
> It appears that responsibility for IAKERB transitioned to the Kerberos WG 
> once CAT WG was closed. 
> 
> [...]

Summary: IAKERB and EAP-GSS are dead at this time, mostly for lack of
people willing to do the work, not for any political or technical
reasons.

I.e., I'm pretty sure there'd be no opposition from the IETF, the
Internet Security Area Directors or the IESG as a whole to a revival of
IAKERB and/or EAP-GSS, provided someone does the work.  See below.

> Sam further commented: 
> 
> "I don't believe that iakerb is likely to have any issues with 
> clarifications, but the mode of iakerb that has reduced number of round 
> trips is likely to be incompatible with extensions because extensions will 
> integrity-protect  the request to make sure no changes are made."
> 
> "I believe that one of iakerb, EAP krb5, , EAP GSS should actually go 
> forward.  Eap krb5 has been sketched out (although not publicly) but does 
> not really exist within the IETF context.  EAP GSS has significant 
> security issues and I hope it does not go forward at all.  Iakerb has 
> significant esthetic issues that we have discussed to death here.  I think 
> we should wait until there is clear interest either from the wireless or 
> dialup community that they want to use Kerberos and then work on one of 
> these mechanisms." 

The EAP GSS issues Sam mentions are addressed by KITTEN WG work, namely
GSS_Pseudo_random() (which reminds me, I have to update that I-D so we
can finish WGLC on that already).

The last IAKERB I-D turns out to have problems with Kerberos V
extensions exactly as Sam described them way back at IETF 56.  But
there's no reason that we couldn't fix this.

Nico
-- 

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech