Subject: AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

From: [email-masked]
Date: Mon, 22 Aug 2005 13:46:57 +0200

>
>>
>>On Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote:
>>> On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote:
>>> > I think the Kerberos community needs to work on standardizing password 
>>> > based pre-authentication mechanisms invulnerable to dictionary attack 
>>> > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication
>>> > mitigates the threat somewhat. But PKINIT isn't really an option for 
>>> > the many sites that don't plan to authenticate users with public key 
>>> > credentials (or deploy PKI).
>>> 
>>> Did you attend the SACRED WG meeting at IETF 63?
>>
>>No, but I just read a summary of their session. The credential
>>mobility stuff isn't really relevant to (non PKINIT) Kerberos
>>sites. So I assume you are referring to the IPR issues with those
>>protocols. It sounds like there might be some hope though!
>>
>>> > At one time, some of us were talking about an EAP method that
>>> > transported Kerberos messages directly. It seems to me that putting
>>> > some effort into completing that work would be immediately useful
>>> > to Kerberos sites that need to deploy 802.1X or 802.11i soon.
>>> 
>>> Indeed.  That would be an example of framework bindings of a security
>>> mechanisms, as opposed to EAP-GSS, which would be a bridge.
>>
>>Agreed.
>>
>>Some folks at Penn are interested in working on an EAP-Kerberos 
>>method. Is there anyone else interested in this?
>
>
>Hi Shumon, 
>
>I`ve also thought about a new EAP method which makes use of Kerberos.
>When designing a new EAP method, it must extend current available set
>of EAP methods by a new mechanism.
>
>Some weeks ago, I`ve asked publicly in the Kerberos Mailing List what
>the folks expect from a EAP-Kerberos method. See <a 
>href="http://mailman.mit.edu/pipermail/kerberos/2005-July/008131.html">http://m
>ailman.mit.edu/pipermail/kerberos/2005-July/008131.html</a>
>Some opinions can be found there.
>
>There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99),
>which can be run in EAP-TLS, so the question is: 
>
>* Is there need for EAP-Kerberos at all? * 
>
>So before all, we should investigate in how far EAP-Kerberos improves
>the TLS-based solution. 
>
>For instance, the mandatory resistance to dictionary attacks. Thomas Wu
>has given in his Kerberos paper a hint how to mitigate this, however,
>even if there is a strong-password protocol without IPR claims,
>strong password methods suffer in general from heavy computation and thus
>the EAP method would have worse performance.
>
>Any comments are welcome
>Thomas
>
>_______________________________________________
>SECMECH mailing list
>[email-masked]
><a 
>href="https://www1.ietf.org/mailman/listinfo/secmech">https://www1.ietf.org/mai
>lman/listinfo/secmech</a>

_______________________________________________
SECMECH mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 26 Aug 2005 08:40:10 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, August 26, 2005 8:01 AM
> To: Shumon Huque
> Cc: Salowey, Joe; [email-masked]
> Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
> 
> > The AAA server could perform the service ticket validation 
> on behalf 
> > of the NAS. This requires another round trip with the AAA 
> server, but 
> > I don't think this is too much of a problem.
> 
> How does the EAP peer figure out the scope of usage of the 
> "network access service" ticket?  If each NAS is a separate 
> Kerberos principal, then the peer needs a distinct ticket for 
> each NAS;  if the AAA server is the principal, then it can 
> submit the same ticket to any NAS. 
> 

[Joe] I don't think there is necessarily a problem service ticket for
the AAA.  This is how EAP typically works today. 

> > If we need the NAS to support Kerberos, then I think the barrier to 
> > practical deployment is too high. Or am I missing something?
> 
> I think that the NAS needs to be modified even in the case 
> where the AAA server is the Kerberos principal, in order to 
> be able to securely inform the EAP peer of the ticket scope.  
> Otherwise, the EAP peer can't know when it needs to acquire 
> another ticket. 

[Joe] How would the NAS know anything about the ticket scope?  If you
are concerned about scope why would you trust the NAS to tell you?  It
would seem that this information needs to encoded in the ticket. Perhaps
scope can be derived from the service principal name.