[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADEXT Milestone revisions



Hi all,

 A quick comment below,
 

On Tue, Feb 21, 2006 at 06:13:07PM +0100, Tschofenig, Hannes wrote:
> Hi David, 
> 
> > Hannes Tschofenig writes...
> > 
> > > wouldn't be something like radius domain of interopretation 
> > for isakmp
> > > be appropriate here.
> > 
> > I don't know.  We're talking about keywrap for specific uses, e.g.
> > 802.11.  OTOH, there is a charter prohibition on developing a new
> > security model for RADIUS.
> 
> Here is my understanding what is going on with the keywrap:
> 
> The Problem: 
>  
> EAP-derived keying material has to be sent confidentiality protected
> from the RADIUS server to the RADIUS client. 
> Intermediate proxies MUST NOT see the EAP-derived keying material.

 I'm not sure that this is really important but
 I was thinking that maybe it could be sufficient to require that the
 keying material MUST be confidentiality protected between the home AAA
 server to the Visited AAA server. The reason is that even if the Keying
 material is protected from the home AAA server to the NAS, the NAS may
 send the keying material to its local AAA server. 

 Just my 2 cents,

 -- Julien


> 
> The Solution: 
> 
> KeyWrap keys* need to be available at the RADIUS server and the RADIUS
> client to allow protected key transport between these two endpoints. 
> 
> *: These keys can either be static or dynamically established. Key
> management is known to be difficult. 
> 
> The Open Question: 
> 
> Is an out-of-band based key management really an option? 
> My argument is that you also have to care about the key management.
> Dealing also with the encryption of the EAP-derived keying material is
> not enough. 
> 
> > 
> > > there is also a rule that says "adding manpower to a late project
> > makes
> > > it later."
> > 
> > Yes.  "The Mythical Man-Month".  :-)  It is a balance, to be sure.
> >  
> > > in ecrit we scheduled an interim meeting that helped a lot 
> > to speedup
> > > the work on the document.
> > > you might also want to think about it.
> > 
> > This is something that we could consider.  Sometimes a couple 
> > of days of
> > face-time is very  helpful.  The other alternative is teleconferences.
> 
> yes, we also investigated this option. the problem is: the rules for
> official phone conferences and interim meetings are the same. this gives
> very little time for phone conferences and a face-to-face meeting is
> more efficient. 
> these rules are also probably something to revisit. 
>  
> > While providing less bandwidth, teleconferences have the 
> > benefit of not
> > requiring travel (and travel budget).
> sure. 
> 
> i am willing to host a meeting in munich, if you would like to schedule
> one.
> 
> ciao
> hannes
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>