RE: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00

[Madjid Nakhjiri <[e-mail]>]

Ok, I am quite aware of proxy issues.
 in case you guys forgot IETF has a document called 

draft-housley-aaa-key-mgmt-09.txt

that has a section

Limit key scope

         Following the principle of least privilege, parties MUST NOT
         have access to keying material that is not needed to perform
         their role.  A party has access to a particular key if it has
         access to all of the secret information needed to derive it.

         Any protocol that is used to establish session keys, MUST
         specify the scope for session keys, clearly identifying the
         parties to whom the session key is available.


The sec area directorate and Tim just asked us to address the issues of
proxies regarding a MIP4-RADIUS document and take Housley-aaa-key
requirements into consideration when it comes to MIP keys transport, and for
the record we are not using a 3 party distribution there..

We had addressed zorn-key-wrap draft in that discussion, but obviously IETF
traction of that document is slow too.

Obviously this group and IETF needs to solve the proxy problem one way or
the other, 3 party protocol or not, keys are going to go over proxies
somehow, if you have a Kerberos proposal, lets see it, even a "term paper"
like piece would be appreciated. After all this is an engineering forum,
even though the management style of treating volunteers leaves things to be
desired some times...


As far as taking critique, may be I send (to this list) some of the
conversations where I time after time asked to take the discussions to the
public list, without any resolve...

Also, it is appreciated if the chairs are a bit more available than 2
emails/month if they are going to call their own WG docs "term paper"..
By approved I meant approved as ietf-hokey-... not approved by IETF.

I believe this is the note I got from Charles:

"Madjid, 

Thanks for all your work on the key delivery document.  After a brief 
skim, it looks MUCH more like what I was envisioning.  I'll read it in 
detail in the next week and send more specific comments. "

So maybe between the two of you, you can decide what it is you want??
As for me, may be I should go earn my pay check now.

Madjid




-----Original Message-----
From: Glen Zorn (gwz) [mailto:[e-mail]] 
Sent: Thursday, July 19, 2007 6:51 PM
To: Madjid Nakhjiri; Yoshihiro Ohba
Cc: [e-mail]
Subject: RE: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00

Madjid Nakhjiri <mailto:[e-mail]> allegedly scribbled on
Thursday, July 19, 2007 1:49 PM:

> Nice attaboy from the co-chair on two public lists, I thought a
> clarification is needed (just on HOKEY list however). The initial
> thought coming to mind is:  
> 
> 
> You put your right hand in,
> You put your right hand out,
> You put your right hand in,
> And you shake it all about,
> 
> You do the hokey pokey
> and you turn yourself around
> That what it's all about.
> 
> From http://www.scoutsongs.com/lyrics/hokeypokey.html (to listen to)
> 
> I guess when we named the WG "hokey", we had no idea what we were
> getting into. 
> 
>  As an editor and contributor I have the opinion all along that the
> key-mgm-doc should cover the entire key hierarchy from EMSK down to
> per-authenticator key and since there are two way of doing things
> (EMSK->HRK->Domain specific HRK, versus EMSK->DSRK->domain specific
> HRK) we should discuss the hierarchies and key holders architecture
> for both. We should discuss detailed format of information being
> passed, and agreed to leave the signaling format specifics to ERX. As
> editors we were just following a co-chair instructions to allow ERX
> to include Diameter AVP/RADIUS attribute descriptions. Not having
> discussed the specific architecture for key holders, we had to come
> up with a few to keep the discussion generic..          
> 
> The Key-mgm doc is prepared based on Charles directions (following
> his hokey-plan doc and follow up emails) to turn the 3 party and
> hokey-key-hierarchy into a new doc and to not do any hokey-specific
> details, keep the key hierarchy out, discuss a high level
> distribution mechanism, and keep any specific AAA protocol/ AVP
> specifications doc out, leaving everything for another document that
> does signaling.      
> 
> I think we should start discussing and deciding these things should
> be discussed on the WG list, like the rest of IETF, using issue
> trackers, rather calling the _approved_ doc a "term paper". 

That document has as far as I know not been "approved" as anything but a
starting point.  If you think otherwise that's a shame.  But let's see
if I've got this straight: you want to discuss things on the "public"
list _unless_ that discussion is critical of your work?  

> So far it
> seems, we are continuing in the spirit of HOKEY:   
> 
> "and you turn yourself around
> That what it's all about."

Very cute.  How about addressing the actual issues (like how the
Otway-Reese derivative you propose actually would work in a proxied
network) instead of obsessing over what you appear to have taken as an
insult.  I don't think it will: prove me wrong.  Kerberos, OTOH _could_
work in something like a proxied network because direct trust
relationships between all realm are not required, but you don't talk
about it.  

> 
> I have no problem including specific AAA references 

Specific AAA references are unnecessary, but references to the real
world would be very welcome.

> there and include
> an actual deployable architecture for HOKEY including key delivery
> (at least the high level keys), if we get the green light from the
> WG...   
> 
> Just responding publicly???
> 
> Madjid
> 
> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[e-mail]]
> Sent: Sunday, July 15, 2007 9:01 PM
> To: Yoshihiro Ohba
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00
> 
> Yoshihiro Ohba <mailto:[e-mail]> allegedly scribbled on
> Sunday, July 15, 2007 7:27 PM: 
> 
>> I agree with Glen's analysis (except that the entity that requests a
>> DSRK from home domain server is a visited domain server, not a NAS in
>> my reading of the draft).  Security property of a key management
>> mechanism that relies on a particular AAA protocol deployment can
>> easily be lost when the AAA protocol is deployed in a wrong way
>> (e.g., placing a AAA proxy that can read the key on the key
>> distribution path).  The problem with such an approach is there is no
>> protocol-level mechanism to prevent mis-deployment of AAA protocol. I
>> don't think such a mechanism should survive in the long run.
> 
> Whether or not it should is a theoretical question: the fact is that
> it has & most likely will for the foreseeable future. 
> 
>> 
>> A securer and cleaner way to avoid dependency on AAA protocol
>> deployment is to use a 3-party key distribution protocol that does
>> not rely on underlying transport security.  HOKEY WG is already
>> taking that approach: draft-ietf-hokey-key-mgm-00.txt.
> 
> I'd just like to reiterate (as co-chair) that if this document is to
> survive, it needs to become a lot more protocol specification & a lot
> less term paper rather quickly.  There is far too much handwaving
> going on for it to be taken seriously: the document needs to clearly
> & precisely state how it will work in _existing networks_ (hint: "we
> assume green-field deployments" is _not_ acceptable as far as I'm
> concerned).  In addition, if a three-party protocol is actually
> required from a practical point of view, there need to be very good
> reasons why an existing standard (i.e., Kerberos) is not usable.     
> 
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hokey



_______________________________________________
HOKEY mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hokey