Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba <> Wed, 24 August 2005 23:03 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E84HE-0007yQ-Q4; Wed, 24 Aug 2005 19:03:24 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E83v7-0000S7-80 for; Wed, 24 Aug 2005 18:40:33 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id SAA27158 for <>; Wed, 24 Aug 2005 18:40:28 -0400 (EDT)
Received: from ([] ident=mailnull) by with esmtp (Exim 4.43) id 1E83vT-0002r6-8z for; Wed, 24 Aug 2005 18:40:56 -0400
Received: from ([] by with esmtpa (Exim 4.51) id 1E83v2-0006Ht-DR for; Wed, 24 Aug 2005 18:40:28 -0400
Received: by (Postfix, from userid 1000) id 4534160DD8; Wed, 24 Aug 2005 15:40:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38C5760DAD for <>; Wed, 24 Aug 2005 15:40:17 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: aboba
Date: Wed, 24 Aug 2005 15:40:17 -0700 (PDT)
From: Bernard Aboba <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <20050824213010.GO10174@binky.Central.Sun.COM>
Message-ID: <>
References: <> <> <Pine.GSO.4.60.0508220801430.1114@ismene> <35850EE42DFD2824F0DDBBC8@cumulus> <Pine.GSO.4.60.0508221008260.1174@ismene> <1DCACCAC04655B3AFE9733A8@cumulus> <Pine.GSO.4.60.0508221047001.1307@ismene> <20050822154044.GE7789@binky.Central.Sun.COM> <> <> <20050824213010.GO10174@binky.Central.Sun.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
X-Mailman-Approved-At: Wed, 24 Aug 2005 19:03:23 -0400
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> 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:

   [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. 

The last version of IAKERB was submitted in October 2002:

The last version of EAP GSS was submitted in April 2002:

On March 17, 2003 an IESG Draft Tracker entry shows that IAKERB was moved 
from the "Waiting for Writeup" state to the "AD is watching  :: Revised ID 
Needed" by Russ Housley, who inherited the document from Jeff Schiller. 

Another entry on March 17, 2003 shows that IAKERB was "Sent back 
to the WG for revision based on request that was received during the IETF 
56 session."  Minutes of the IETF 56 Kerberos WG are enclosed below. 

On February 13, 2004 another entry was entered indicating that "IAKERB is 
not going to come back to the IESG.  There is not any interest in the 
KRB-WG since the general solution is to use the Kerberos EAP mechanism."
On that same date, the status changed to "DEAD" from AD is Watching::ID 

Minutes of the Kerberos WG at IETF 56 San Francisco 

The Kerberos WG met on 3/17/2003 for about 1 and a half hours. In 
attendance where approximately 53 people. 

I talked on the IAKERB  about how it had been before the IESG, for over a 
year, but there has been some concerns about it.  It has being 
withdrawn, and will be considered again if there is  substantial 
interest. It should be update with regards to Extensions.  (Since then I 
realize I should not have made this statement.  I and the AD have been in 
contact with the author on this, and it is expected the draft will be 

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." 

SECMECH mailing list