Subject: [HOKEY] Key mgm : locating the server

From: Saber Zrelli <[email-masked]>
Date: Thu, 09 Aug 2007 11:44:26 +0200

Hi ,

I have a question about draft-ietf-hokey-key-mgm-00

As far as I understood, whenever the key distribution protocol is used,
the third party (The HOKEY server or the EAP Authenticator) ,
has to contact the server (The EAP server or the HOKEY server).

I imagine a scenario where you have many EAP servers per domain, the 
HOKEY server
needs to know which of these EAP servers shares the EMSK with the EAP peer.

How the third-party figure out which server to contact ?

Thanks,
Saber.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 9 Aug 2007 16:51:02 -0400

I commented in the past that server identifier should be used instead
of domain identifier to allow more flexible operation like multiple
servers
(http://www1.ietf.org/mail-archive/web/hokey/current/msg00645.html).

Such a server identifier can be specified by the peer in the key
distribution protocol so that the third-party can determine which
server it has to send a message.  On the other hand, there is still an
issue on how the peer can know the server identifer.

I think that a server discovery mechanism should be defined separately
from a key distribution protocol (e.g., provided by lower-layer),
instead of designing a key distribution protocol to contain a server
discovery mechanism.

Yoshihiro Ohba

---

From: "Saber Zrelli" <[email-masked]>
Date: Mon, 13 Aug 2007 18:56:54 +0900 (JST)

Hi Yoshihiro,

On Fri, August 10, 2007 5:51 am, Yoshihiro Ohba wrote:
> of domain identifier to allow more flexible operation like multiple servers
> distribution protocol so that the third-party can determine which server it has to send a
> message.  On the other hand, there is still an issue on how the peer can know the server
> identifer.

With regard to this issue, I think a possible approach would be to push the HRK from
the EAP peer to the HOKEY server at the time of the initial full EAP authentication.

IMHO, there is no need to use three-party protocol for transferring HRK from the EAP
server to HOKEY server. Regarding context binding of the HRK, the EAP server has already
all information about the peer and the HOKEY server of the access domain.

This would eliminate the the issue of finding which EAP server to contact.

The other use-case is where the third-party is the new EAP authenticator,
the EAP Authenticator needs to determine which HOKEY server to contact in order to
share a key with the peer.

In this case, the EAP peer can refer to the Hokey server using the Hokey domain name
and/or HOKEY server ID, that it would have obtained during the initial full EAP
authentication from an enhanced EAP-Identity Request or lower-layer means, the EAP
authenticator would look up the Hokey server using this information and initiate the
three-party protocol.

> from a key distribution protocol (e.g., provided by lower-layer), instead of designing a
> key distribution protocol to contain a server discovery mechanism.

Such protocols already exist in my opinion, DNS is a good example, no ?
Kerberos entities uses it to locate Key Distribution Centers given a Kerberos
realm name. We could think of using the same approach for locating HOKEY servers.

Best Regards,
Saber Zrelli.

>> the third party (The HOKEY server or the EAP Authenticator) , has to contact the server
>> (The EAP server or the HOKEY server).
>>
>>

--saber