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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 15 Jul 2007 15:05:20 -0700

I would like to note that there is pre-existing work in this area
(http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt,
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt).
Be that as it may, however, it's difficult to understand what the
purpose of the Requesting Entity's Identity in the express environment
that is implied by the draft (i.e., a request from a visited network to
a home network).  If, as I assume (please correct me if my assumption is
incorrect), the requesting entity is a NAS it doesn't seem reasonable to
believe that the RADIUS server in a remote network would have any
knowledge of it, even less so in the case where the visited and home
networks are separated by one or more proxies & thus lack any direct
trust relationship.  If this identity is meant to be used for key
binding purposes, I think that this is incredibly dangerous, imputing
trust as it does between the home RADIUS server and an entity of which
it possesses no knowledge.  OTOH, suppose that there _is_ a direct trust
relationship between the home & visited network, intervening proxies
notwithstanding (perhaps by means of an OOB WRT RADIUS key exchange);
further, suppose that this trust is so strong that the home RADIUS
server is willing to take the visited domain at its word as to the
identity of the requesting NAS.  In this case, the security of the
protocol is defeated by the use of IPsec on a hop-by-hop basis since the
message and key are available in plaintext form at each (less trusted)
hop.
_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 15 Jul 2007 22:26:47 -0400

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.

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.

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 15 Jul 2007 21:01:26 -0700

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Sunday, July 15, 2007 7:27 PM:

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 16 Jul 2007 22:22:07 -0700

Glen,

Many thanks for your note.  I was somewhat familiar with the keyreq and 
keywrap drafts, although I haven't followed their progress in the IETF 
closely.  I also haven't reviewed them before working on the ERP 
attributes draft; I should have.

One of the goals of draft-gaonkar-radext-erp-attrs-00 is to piggyback 
the key request and response on the EAP authentication or the EAP 
reauthentication exchange.  After some reading, I think we can use the 
techniques of keyreq and keywrap within new RADIUS attributes.  So, for 
instance we can incorporate the Request and Response Authenticators of 
the keyreq draft (although I don't quite like the MD5 construction there 
and would propose to revise it) and the keying material and other 
attributes of the keywrap drafts.  If that is something the WG might 
like, Kedar and I can work with the authors of keyreq and keywrap 
offline and revise the draft accordingly.

Some notes inline:

On 7/15/2007 3:05 PM, Glen Zorn (gwz) wrote:
> (_http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt_, 
> _http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt_).  

The requesting entity might be a DSRK server.

> trust as it does between the home RADIUS server and an entity of which 

The DSRK server can provide its identity via the lower layer to the peer 
and via RADIUS protocol to the RADIUS server.  The peer can communicate 
the identity in an end-to-end protected manner to the server, thus 
forcing the DSRK server to present the same identity to the peer and the 
server.

regards,
Lakshminath

> message and key are available in plaintext form at each (less trusted) hop.
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 17 Jul 2007 14:06:41 -0700

Lakshminath Dondeti <mailto:[email-masked]> allegedly scribbled
on Monday, July 16, 2007 10:22 PM:

> Glen,
> 
> Many thanks for your note.  I was somewhat familiar with the keyreq
> and keywrap drafts, although I haven't followed their progress in the
> IETF closely.  I also haven't reviewed them before working on the ERP
> reauthentication exchange.  After some reading, I think we can use
> the techniques of keyreq and keywrap within new RADIUS attributes. 
> So, for instance we can incorporate the Request and Response
> Authenticators of the keyreq draft (although I don't quite like the
> MD5 construction there and would propose to revise it) 

The constructs were chosen to make the new messages look as much like
existing RADIUS messages as possible (not to minimize code changes
(which would take about 10 minutes) but to minimize whining from IETF
"experts" (that could go on for years ;-)).

> and the keying
> material and other attributes of the keywrap drafts.  If that is
> something the WG might like, Kedar and I can work with the authors of
> keyreq and keywrap offline and revise the draft accordingly.         
> 
> Some notes inline:
> 
(_http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt_
>> ,
>> that is implied by the draft (i.e., a request from a visited network
>> to a home network).  If, as I assume (please correct me if my
>> assumption is incorrect), the requesting entity is a NAS it doesn't
>> seem reasonable to
> 

What is a "DSRK server"?  Is it the same as a hokey server?  

> The DSRK server can provide its identity via the lower layer to the

One of the things that bothers me a lot about the proposals we're seeing
is the tendency to rely upon unspecified and possibly non-existent
"lower layer" mechanisms.  I think that this is unnecessary.

> and via RADIUS protocol to the RADIUS server.  

In the case where the DSRK server is separated from the home RADIUS
server by one or more proxies, why should the home server believe the
identity it receives?

> The peer can
> communicate the identity in an end-to-end protected manner to the
> server, thus forcing the DSRK server to present the same identity to
> the peer and the server.  

I still have problems understanding the utility of this.  Leaving aside
the "lying proxy" problem, let's take an example from real life: suppose
that someone introduces himself to a young woman as "Ted Bundy" and she
checks with a trusted friend who confirms this claimed identity.  If
neither the young woman nor her friend knows that "Ted Bundy" is a
vicious serial killer, what good does this confirmation do?  If you
assume that the DSRK server cannot be trusted (otherwise why force it to
do anything?), then why does the fact that it's not lying about its
_name_ magically make it trustworthy?  

...

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 17 Jul 2007 16:17:57 -0700

<snip>

> What is a "DSRK server"?  Is it the same as a hokey server?  

In my mind, that is practically the case.  I guess in theory, one could
say that the entity that holds the DSRK doesn't need to also be the
HOKEY server.  I can't make a practical case for that though. 

> One of the things that bothers me a lot about the proposals 
> we're seeing is the tendency to rely upon unspecified and 
> possibly non-existent "lower layer" mechanisms.  I think that 
> this is unnecessary.
> 

Not sure I understand.  It is very much feasible to provide the identity
(of the domain or the HOKEY server) to the peer via the lower layer.
Also, ERP bootstrapping is capable of providing this identity to the
peer - so, a lower layer capability here is not a MUST.  More below on
why the peer needs this identity. 

> In the case where the DSRK server is separated from the home 
> RADIUS server by one or more proxies, why should the home 
> server believe the identity it receives?
> 
> > The peer can
> I still have problems understanding the utility of this.  
> Leaving aside the "lying proxy" problem, let's take an 
> example from real life: suppose that someone introduces 
> himself to a young woman as "Ted Bundy" and she checks with a 
> trusted friend who confirms this claimed identity.  If 
> neither the young woman nor her friend knows that "Ted Bundy" 
> is a vicious serial killer, what good does this confirmation 
> do?  If you assume that the DSRK server cannot be trusted 
> (otherwise why force it to do anything?), then why does the 
> fact that it's not lying about its _name_ magically make it 
> trustworthy?  
> 

I agree with you that channel bindings does not provide for correctness
in identity, it only provides a consistency check.  In this case,
however, I don't think channel bindings is the reason for the identity
being sent.  The DSRK derivation takes the requesting entity's domain
name or server ID as input to the PRF. Both parties deriving the key
(the Home AAA/EAP server and the peer) need to know this identity so
that the DSRK can be derived.  I believe that is the reason the identity
needs to be provided along with a request for DSRK.  Unless the peer and
the server are given the same value, the DSRK cannot be derived
correctly at both ends - so, the property of channel bindings may be
inherently provided for the DSRK by virtue of that. 

Vidya

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 17 Jul 2007 16:32:44 -0700

Narayanan, Vidya <mailto:[email-masked]> allegedly scribbled on
Tuesday, July 17, 2007 4:18 PM:

...

> Not sure I understand.  It is very much feasible to provide the
> identity (of the domain or the HOKEY server) to the peer via the
> lower layer.

OK, cool.  Please provide a list of 1) all target lower layers and b)
how, precisely this identity is provided to the peer _now_.
  
> peer - so, a lower layer capability here is not a MUST.  

OK, if it's not necessary let's not talk about it any more & simply say
that, shall we?

> More below
> on why the peer needs this identity.  
> 
>> server by one or more proxies, why should the home server believe
>> the identity it receives? 
>> 
>>> The peer can
>> Leaving aside the "lying proxy" problem, let's take an example from
>> real life: suppose that someone introduces himself to a young woman
>> as "Ted Bundy" and she checks with a trusted friend who confirms this
>> claimed identity.  If neither the young woman nor her friend knows
>> that "Ted Bundy" is a vicious serial killer, what good does this
>> confirmation do?  If you assume that the DSRK server cannot be
>> trusted (otherwise why force it to do anything?), then why does the
> I agree with you that channel bindings does not provide for
> correctness in identity, it only provides a consistency check.  In
> this case, however, I don't think channel bindings is the reason for
> the identity being sent.  The DSRK derivation takes the requesting
> entity's domain name or server ID as input to the PRF. Both parties
> deriving the key (the Home AAA/EAP server and the peer) need to know
> this identity so that the DSRK can be derived.  I believe that is the
> reason the identity needs to be provided along with a request for
> DSRK.  

OK, but that's not what was said above...it seems to me that for the
purpose you mention the name of the local DSRK server could as or more
easily be supplied by the home server to the peer, rather than relying
upon a lower layer (maybe you've noticed that I don't care for that ;-).

> Unless the peer and the server are given the same value, the
> DSRK cannot be derived correctly at both ends - so, the property of
> channel bindings may be inherently provided for the DSRK by virtue of
> that.           
> 
> Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 17 Jul 2007 17:59:06 -0700

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Tuesday, July 17, 2007 4:33 PM
> To: Narayanan, Vidya; Dondeti, Lakshminath
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
> 
> Narayanan, Vidya <mailto:[email-masked]> allegedly 
> scribbled on Tuesday, July 17, 2007 4:18 PM:
> 
> ...
> 
> > identity (of the domain or the HOKEY server) to the peer 
> via the lower 
> > layer.
> 
> OK, cool.  Please provide a list of 1) all target lower 
> layers and b) how, precisely this identity is provided to the 
> peer _now_.
>   

The point I was making was that evolving link layers can certainly
include this functionality.  But, as indicated below, the protocol
doesn't rely on this possibility and hence, for this discussion, we can
avoid focusing on that. 

> OK, if it's not necessary let's not talk about it any more & 
> simply say that, shall we?
> 

That's fine :) 

> example from 
> OK, but that's not what was said above...it seems to me that 
> for the purpose you mention the name of the local DSRK server 
> could as or more easily be supplied by the home server to the 
> peer, 

Yes, this capability is already in the protocol, as part of
bootstrapping. 

> rather than relying upon a lower layer (maybe you've 
> noticed that I don't care for that ;-).
> 

That seems established :) The point is that we don't need to mandate
that the peer go through the bootstrapping process, IF it happened to
know the identity by means outside the protocol. There's always the
choice that it gets it from the home server as part of bootstrapping, if
the lower layer cannot provide such information. 

Vidya

> > Unless the peer and the server are given the same value, the DSRK 
> > cannot be derived correctly at both ends - so, the property 
> of channel 
> > bindings may be inherently provided for the DSRK by virtue of
> > that.           
> > 
> > Vidya
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 17 Jul 2007 18:44:48 -0700

Narayanan, Vidya <mailto:[email-masked]> allegedly scribbled on
Tuesday, July 17, 2007 5:59 PM:

> include this functionality.  

If the people evolving those link layers are a) paying any attention at
all to what we're doing, b) are as willing as we seem to be to depend
upon massive layer violations to get things going and c) actually know
what the identity is to be in all cases.  For example, I can't for the
life of me imagine why L2 would know or care about a specific hostname
(which after all is an L6 identifier).  In any case, this is the
Internet Engineering Task Force, not the Every Lame Transport on the
Planet Engineering Task Force; we should do our own engineering in a way
that our protocols are (as much as possible) independent of other
folks'.  This appears to me to be one of the cases where any reliance on
a lower layer not under our control is not just unnecessary but
detrimental.

...

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 17 Jul 2007 21:09:38 -0700

> If the people evolving those link layers are a) paying any 
> attention at all to what we're doing, b) are as willing as we 
> seem to be to depend upon massive layer violations to get 
> things going and c) actually know what the identity is to be 
> in all cases.  For example, I can't for the life of me 
> imagine why L2 would know or care about a specific hostname 
> (which after all is an L6 identifier).  

Well, stranger things have been exchanged at L2 for various reasons,
but, that's not important. 

> In any case, this is 
> the Internet Engineering Task Force, not the Every Lame 
> Transport on the Planet Engineering Task Force; we should do 
> our own engineering in a way that our protocols are (as much 
> as possible) independent of other folks'.  

And we are.  The exchange of this data via ERP bootstrapping is totally
independent of the lower layer. 

> This appears to me 
> to be one of the cases where any reliance on a lower layer 
> not under our control is not just unnecessary but detrimental.
> 

As I agreed, no need to debate that.  We have an independent mechanism
to convey the necessary information and can ensure protocol completeness
via that. 

Vidya

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 19 Jul 2007 13:48:41 -0700

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". So far it seems, we are
continuing in the spirit of HOKEY:

"and you turn yourself around
That what it's all about."

I have no problem including specific AAA references 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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 19 Jul 2007 18:50:33 -0700

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

> clarification is needed (just on HOKEY list however). The initial
> thought coming to mind is:  
> 
> 
> I guess when we named the WG "hokey", we had no idea what we were
> getting into. 
> 
> (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:   
> 

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...   
> 
> Whether or not it should is a theoretical question: the fact is that
> it has & most likely will for the foreseeable future. 
> 
>> 
> 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
> 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.     
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 19 Jul 2007 21:08:35 -0700 (PDT)

Glen,

On Thu, July 19, 2007 6:50 pm, Glen Zorn (gwz) wrote:
[snip]
> relationships between all realm are not required, but you don't talk

  Your request to describe why one Otway-Rees-like protocol is
preferrable to another Otway-Rees-like protocol would seem to run
counter to your other request to make the draft less "term paper".

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 19 Jul 2007 22:24:56 -0700

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Thursday, July 19, 2007 9:09 PM:

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

Except that I didn't request that.  I asked to describe how the proposed
protocol would work in a real network.  If it won't work, it needs to be
changed.  You can work with abstractions & not be "term papery" as long
as those abstractions can actually be mapped to something resembling
reality.  The reality is that there are not pair-wise shared keys
between every AAA server on the planet; proxies exist and they exist for
business reasons, not just convenience.  We may not like that reality
but it's there & must be dealt with.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 20 Jul 2007 12:40:56 +0200

Glen Zorn (gwz) wrote:
> ... The reality is that there are not pair-wise shared keys

  And it won't change in the foreseeable future.  Even if the network
protocols can leverage DNS, SRV records, and crypto to do dynamic
discovery of peers, that won't solve the business problems.  There are
business middle-men who need to be in the middle of the network traffic,
too.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 20 Jul 2007 07:37:33 -0700 (PDT)

Glen,

On Thu, July 19, 2007 10:24 pm, Glen Zorn (gwz) wrote:
[snip]
> but it's there & must be dealt with.

  Except that nobody is assuming "pair-wise shared keys between every
AAA server on the planet"....

  So this is an N-party key distribution problem (where N is infinite).
What you're demanding is that N parties know the peer's secret and the
peer has absolutely no idea who these people are. Explain for me one
more time, please, how a 2-party security model applies.

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 20 Jul 2007 09:35:44 -0700

Dan Harkins <mailto:[email-masked]> allegedly scribbled on Friday,
July 20, 2007 7:38 AM:

>> Except that I didn't request that.  I asked to describe how the
>> proposed protocol would work in a real network.  If it won't work, it
>> needs to be changed.  You can work with abstractions & not be "term
>> papery" as long as those abstractions can actually be mapped to
>> something resembling reality.  The reality is that there are not
>> pair-wise shared keys between every AAA server on the planet; proxies
>> exist and they exist for business reasons, not just convenience.  We
>> may not like that reality but it's there & must be dealt with.
> 

My mistake.  Please humor me & re-read section 4.1 of the draft in
question and tell me how a it will work if "server" and "third-party" do
not possess a shared key (therefore a direct trust relationship).  I
can't see it.

> What you're demanding is that N parties know the peer's secret and
> the peer has absolutely no idea who these people are. 
> Explain for me
> one more time, please, how a 2-party security model applies.  

One more time: I don't care what model is used, as long as it models
real, existing networks (i.e., not require massive new infrastructure
development (both technical & legal) or rely upon some imaginary "lower
layer" that happens to have all the qualities that we need and not those
that exist).  If I had to explain, though, it would involve the magic of
abstraction ;-).  Be that as it may, however, I think that we _could_
make Kerberos cross-realm authentication work in the situation we're
talking about but the authors don't mention such an alternative.  Given
that Kerberos v5 is an IETF standard protocol & is supported by the
largest OS vendor in the world, I'd like to know why not (& I'm sure I'm
not alone).

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 20 Jul 2007 10:06:53 -0700 (PDT)

> not possess a shared key (therefore a direct trust relationship).  I

  If they don't have a way to establish a trust relationship then "3rd
party" should not obtain the key from "server". There are numerous ways to
establish a shared key if they have some reason to trust each other, some
of them are IETF standards track RFCs :-)

  Please humor me and tell me why there MUST be N different parties
between "3rd party" and "server" and why the key being distributed from
"server" to "3rd party" MUST be disclosed to each and every one of them.

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 20 Jul 2007 10:14:54 -0700

July 20, 2007 10:07 AM:

...

> between "3rd party" and "server" 

Proxies exist and they exist for business reasons, not just convenience.

> and why the key being distributed
> from "server" to "3rd party" MUST be disclosed to each and every one
> of them.  

Apparently because no one has a better idea (requiring a direct trust
relationship is _not_ a better idea)...

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 10:33:53 -0700

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Jul 2007 13:43:03 -0400

I don't know of anyone who has looked at Kerberos in the scope of
hokey.  Personally I think it would be a good fit, but was unable to
interest any of the Kerberos folks in doing anything with it.
8

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 11:27:20 -0700

Well, not sure if you have read the key-mgm draft anyway, but there are a
few scenarios:

1) USRK delivery from EAP server to a USRK holder, e.g. HRK delivery from
EAP server to a HOKEY server. I believe I am the one that have said several
times, the HOKEY server is probably the same as a AAA server also
implementing EAP, so this is just a local API from EAP layer to AAA layer,
no proxies there. Now people have brought up the notion of HOKEY server as
an independent server with unknown location (probably because it does not
belong to any domain). My response to that was also that since EAP is done
with home AAA, then this HOKEY server is the same as home domain HOKEY
server and you have to come back here for getting keys for other domains..

2) DSRK delivery from EAP server to DSRK holder. Now this definitely crosses
AAA boundaries and probably proxies. Now you are telling me people who want
to allow a foreign domain AAA get a DSRK to do whatever it want to do with
that DSRK, don't establish a shared key between that AAA server and home AAA
server? If yes, then no proxy issues, if no, then there is something really
wrong with that authorization picture.

3) delivery of domain specific keys within a domain, say delivering an
authenticator key to the authenticator. As far as I understand, this is an
intra-domain operation (the authenticator key comes from a DSUSRK). So I
don't see a proxy issue there.

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 12:10:57 -0700

Ok, Glen you humor me and tell me how you are going to get this past IESG:

"The rMSK is transported in a manner similar to
   that of the MSK along with the EAP Success message in a full EAP
   exchange."

Coming from another HOKEY non-"term paper"??

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 9:36 AM
To: Dan Harkins
Cc: Madjid Nakhjiri; Yoshihiro Ohba; [email-masked]
Subject: RE: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00

<snip>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Jul 2007 22:42:58 -0400

On Fri, Jul 20, 2007 at 09:35:44AM -0700, Glen Zorn (gwz) wrote:
[snip]
> largest OS vendor in the world, I'd like to know why not (& I'm sure I'm

Sure, you are not alone :) As you may remember, when I first initiated
the discussion on 3-party key distribution, I recommended Kerberos.
Also, ohba-hokey-3party-keydist mentions Kerberos as a candidate
protocol.

Furthermore, recently I wrote a paper on use of Kerberos for handover
keying.  The paper has been accepted for publication in ACM MobiArch07
(a workshop of SIGCOMM2007, August 27, Kyoto Japan):

  http://user.informatik.uni-goettingen.de/~mobiarch/2007/

  "Kerberized Handover Keying: A Media-Independent Handover Key
  Management Architecture", Yoshihiro Ohba (TARI, USA); Subir Das
  (Telcordia Technologies, USA); Ashutosh Dutta (Telcordia
  Technologies, USA)

hokey-key-mgt draft can refer to this paper once the paper is
published.

Briefly speaking, Kerberos is a very good candidate for key management
for handover, but Kerberos as it is is not usable for handover keying.
We need several additional workaround to make it work, including (i)
how to bootstrap Kerberos from EAP-based network access
authentication, (ii) How to map AAA authorization parameters to
authorization parameters for Kerberos, (iii) how to map AAA domains to
Kerberos realms and (iv) need for signaling optimization for reactive
mode of operation.  All those stuff is described in my paper.
Unfortunately, HOKEY WG in its current charter does not seem to be
allowed to work on all those of details for Kerberos.

Best Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sat, 21 Jul 2007 19:40:15 -0700

Sam Hartman <mailto:[email-masked]> allegedly scribbled on
Friday, July 20, 2007 10:43 AM:

> hokey.  

Yoshi apparently has written a paper on it (!) & I've been think about
it for a little while.  I'm still not convinced that a 3-party mechanism
is really necessary, but if we're going to do it that way Kerberos seems
like a pretty good way.  he really cool thing is that I suspect that if
we do it right it could be independent of both EAP & all these messy
"lower layers" the qualities of which people love to rely upon and over
which we have zero control.

> Personally I think it would be a good fit, but was unable to
> interest any of the Kerberos folks in doing anything with it. 8

---

From: Charles Clancy <[email-masked]>
Date: Mon, 23 Jul 2007 00:46:54 +0100

> As for me, may be I should go earn my pay check now.

That's a little out of context... it was a significant improvement, but 
it's not there yet.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 24 Jul 2007 12:24:23 -0700

Frankly I am loosing the context for a lot of stuff at this point now.
 
Everybody knows that no IETF RFC is done based on draft-00, it is how the WG
work together and how the work is shepherded through the revs..

Instead of a key hierarchy/ mgmt draft and a protocol draft originally
envisioned, we are asked to work a hokey independent draft that only shows
top level keys, without anything that has to do with authenticators and
handovers, with an abstract delivery mechanism
And a second draft that is changing EAP and proposing one key hierarchy
prior to handover and another following it..

Reiterating my point, the key mgm doc needs to describe the entire key
hierarchy, how the keys are managed and scoped and possibly a generic
delivery mechanism, while the signaling doc should discuss the signaling,
and not hack through the hierarchy in a way that no SDO will want to use it.
Add that the use of EAPv2, I think it would be even a bigger mystery where
any of it would be used anywhere..

BTW, I raised the issue on depth of the key hierarchy and I don't see that
on issue tracker, instead I see issues from you on making the key hierarchy
more shallow, can we have competing issues on the list:)

Madjid

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Sunday, July 22, 2007 4:47 PM
To: Madjid Nakhjiri
Cc: 'Glen Zorn (gwz)'; 'Yoshihiro Ohba'; 'Sam Hartman'; 'Tim Polk';
[email-masked]; [email-masked]
Subject: Re: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00

---

From: Charles Clancy <[email-masked]>
Date: Tue, 24 Jul 2007 15:48:18 +0100

Madjid,

In short, here's the breakdown:

1. The EMSK hierarchy defines the USRK, DSRK, and DSUSRK, and the KDFs
    necessary to derive them.
2. The key-mgm document describes how to securely deliver those keys by
    providing a blob that can be transported by a particular application
    to obtain one of the aforementioned keys.  Secure delivery will
    require defining proper context/scoping/management/etc.
3. The ERX document describes how to use those keys for handover, and a
    transport for the aforementioned blob.

I'm not entirely sure we disagree about that, based on your description 
below.

Neither the EMSK document nor the key-mgm document should discuss 
anything other than USRKs, DSRKs, or DSUSRKs.  (Note that the IK, CK, 
DIK, and DCK are USRKs or DSUSRKs.)

Issues #3 and #6 reflect your raised issues with the depth of the EMSK 
hierarchy.  The depth of the EMSK hierarchy should match the depth of 
the key-mgm hierarchy.  Issue #29 reflects that.