Subject: [HOKEY] issues, issue tracker

From: Charles Clancy <[email-masked]>
Date: Wed, 18 Jul 2007 22:09:15 +0100

Now that we're off and running with a few documents, I fired up the 
issue tracker (and removed the inappropriate issues created by some very 
clever spammers).  We have 3 issues so far...

#3: Madjid's concerns about the EMSK hierarchy and the depth to which it 
should be specified

#4: CB/3PK in ERX

#5: optional server-initiated message in ERX

I know there should be plenty more.  Please, let's start capturing these 
in succinct posts to the list, and I'll get them in the tracker.

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

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

---

From: Charles Clancy <[email-masked]>
Date: Wed, 18 Jul 2007 22:33:10 +0100

BTW, tracker URL is http://www.ltsnet.net:8080/hokey/

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 19 Jul 2007 18:05:15 -0700

Thanks Charles for starting this...

Yes, issue 3 is that EMSK hierarchy draft does not discuss the possibility
of derivation of DSUSRK (domain AND usage specific keys). This can be ok,
since the doc is only supposed to discuss EMSK child key derivation, but
since DSUSRKs can be generated from both DSRK and USRK, this needs to be
captured and guidelines should be provided to avoid conflicts: 

what DSUSRKs for what services can be generated from DSRK and what DSUSRKs
are be generated from USRK. One idea is to have "the policy to specify what
usages DSRKs are delivered for" to be captured in scope??

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 2:09 PM
To: [email-masked]
Subject: [HOKEY] issues, issue tracker

#4: CB/3PK in ERX

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 19 Jul 2007 18:15:33 -0700

This can be an issue for either EMSK hierarchy or key mgm or both:

At some point we discussed generation of DSUSRK from EMSK directly, since we
had both a usage label and a domain label in the EMSK child derivation.
While writing the key mgm doc I did not have access to the latest EMSK
hierarchy draft so I have that branch included in the draft.

The new emsk hierarchy draft only includes a key label and the key label can
specify either 
usage (as "label-string" or "label_string@specorg") to get a USRK
or
domain (as "[email-masked] + domain info within optional data) to get a DSRK

It seems to be possible to also include usage data within the optional data
and thus get a DSUSRK, no?

If no, is there a reason to not have DSUSRK as a EMSK child key?

Also, if no, then Key mgm key hierarchy needs to be updated.

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 2:09 PM
To: [email-masked]
Subject: [HOKEY] issues, issue tracker

#4: CB/3PK in ERX

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 19 Jul 2007 18:51:53 -0700

Hi Charles,
Thanks for putting this together. On issue #4, the ERX document
presently has the following: 

The Authenticator-ID can be carried in the EAP Initiate/Re-auth and EAP
Finish/Re-auth messages and it can be one of the following: 

         '130' - NAS-Identifier

         '131' - NAS-IP-Address

         '132' - NAS-IPv6-Address

The following additional parameters for channel binding are also
defined, although, I think these will be sent in AAA by the
authenticator to the server or vice-versa: 

         '128' - Called-Station-Id

         '129' - Calling-Station-Id

The use of authenticator-ID is described in sections 5.3.1 (peer to
server) and 5.3.2 (server to peer); the values are defined in section
5.3.3; section 5.5 captures the channel binding aspects briefly. 

Can someone take a look at the text and provide suggestions on what
additions/changes are needed for completeness or if the existing text
provides the necessary aspects?  

The sending of peer-id from the authenticator to the server and
vice-versa needs to be specified in the AAA companion documents in my
view. Thoughts on that? 

Thanks,
Vidya

> Sent: Wednesday, July 18, 2007 2:33 PM
> To: [email-masked]
> Subject: Re: [HOKEY] issues, issue tracker
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 19 Jul 2007 18:53:11 -0700

Hi Charles, all,
For issue #5 (optional server-initiated message in ERX), one question on
the issue itself - I assume you meant optional "authenticator-initiated"
message and not server-initiated message?  When operating in
multiplexing mode, that'd be one and the same; otherwise, it would be
the authenticator sending this message - is that correct? 

If so, would the following work? 

- Define EAP Initiate/Re-auth-Start to be optionally sent from the
authenticator to the peer, including the authenticator ID;
- The message has the same code (Initiate) as what the peer sends, with
a new type (Re-auth-Start)
- Re-transmission semantics for this message would be similar to the
EAPoL-Start message in 802.1x

Questions: 

Does sending the above message from the authenticator assume that the
authenticator somehow has knowledge of that particular peer having
completed a successful EAP authentication in the past and possessing a
valid EMSK?  Or, are we assuming that an authenticator may send this
message along with an EAP Request Identity to the peer, letting the peer
decide if it needs to do a full EAP exchange or an ER exchange? 

Vidya

---

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

Hi Vidya,

If memory serves right, EAP Start today IS sent directly from authenticator
in some implementations, so I personally don't have an issue with that, but
we should check to see if any spec prohibits that.

As for what trigger this, I think for now, you should allow for both cases:
1) after receiving an EAP success and 2) starting a HOKEY process.
Personally (1) makes more sense, but I am sure I have a better opinion after
reading EAP-ERX (hopefully today:))

Madjid

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 6:53 PM
To: Charles Clancy; [email-masked]
Subject: Issue #5 - Thoughts (RE: [HOKEY] issues, issue tracker)

Hi Charles, all,

Questions: 

Vidya

---

From: Charles Clancy <[email-masked]>
Date: Sun, 22 Jul 2007 16:34:09 +0100

Captured as issue #6.

This seems easy to accomplish given the current KDF construction.  If 
there is consensus to add it, then it should be added to the EMSK document.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc
adjunct professor, electrical engineering, university of maryland

---

From: Charles Clancy <[email-masked]>
Date: Sun, 22 Jul 2007 16:39:33 +0100

Narayanan, Vidya wrote:
> message and not server-initiated message? 

Correct.

 > When operating in

... and also any AAA domain information that could be necessary in key 
derivation and channel bindings.  I guess we still need to formally 
define what needs to be included in that.

> a new type (Re-auth-Start)

Sounds reasonable.

> EAPoL-Start message in 802.1x

Yes.

> decide if it needs to do a full EAP exchange or an ER exchange? 

I think sending both could be a useful way of providing backward 
compatibility.  If the authenticator did have some way of knowing, 
however, it could just send one or another.

---

From: Charles Clancy <[email-masked]>
Date: Sun, 22 Jul 2007 16:45:12 +0100

> captured and guidelines should be provided to avoid conflicts: 

I see how a DSUSRK can be derived from a USRK, but an application 
receiving a USRK may not want to use that type of keying hierarchy. 
Since we're handing the key off to that application, we don't have any 
control over how it derives additional keys.  Any hierarchy we defined 
stemming from a USRK should not be normative.

> usages DSRKs are delivered for" to be captured in scope??

I see DSUSRKs and USRKs as similar keys -- USRKs are just versions of 
the DSUSRK that aren't tied to a particular domain.  A service needs to 
decide whether it wants its root key to be domain-specific, or whether 
it wants to manage its own cross-domain handoff and scoping.  If it 
didn't do any cross-domain handoff, for example, it may only need a USRK.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 24 Jul 2007 11:52:15 -0700

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Sunday, July 22, 2007 8:45 AM
To: Madjid Nakhjiri
Cc: [email-masked]; 'Joseph Salowey (jsalowey)'
Subject: Re: [HOKEY] issues: DSUSRK as USRK child key.. issue tracker

Madjid>>Sure, agree, but then also the type of inter-domain trust
relationship may not allow handing DSRKs to a domain for unspecified usage
either. So we agree that both ways of creating DSUSRKs are allowed. 
The point I just mentioned needs to be stated in the draft, most reasonably
in the security consideration section.

Madjid>>Well, if we are arguing semantics, to me DSUSRK is domain specific
version of USRK:) 
I don't think a service needs to decide whether its root key is domain
specific or not. At least that is not part of the key derivation, otherwise
you probably needed a flag somewhere to indicate that.