Subject: [MSEC] DHHMAC draft

From: canetti <[email-masked]>
Date: Tue, 7 Oct 2003 12:20:54 -0400 (EDT)

Folks,

The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently
completed its last call with no remarks. Infact, there seemed to have been
little discussion on this draft on the list. In light of this, we'd like
to poll the WG on whether there is interest in advancing this draft to
proposed standard, along with MIKEY. Please speak your mind.

Best,

Thomas and Ran

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Tue, 07 Oct 2003 13:10:02 -0400

This may have been brought up before (it was in another context).  But, 
has the following question been answered for dhhmac I-D

"Do we need the IETF standardizing yet another DH-based key management 
protocol?"

regards,
Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Tue, 7 Oct 2003 15:52:37 -0400

Ran,

With the caveat that was included in the spec.

   Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond
   a point-to-point constellation; thus, both MIKEY Diffie-Hellman
   protocols do not support group-based keying for any group size larger
   than two entities.

Very little can be said about this draft from the perspective of group 
security.

Hugh

I just worry that people will automatically

> proposed standard, along with MIKEY. Please speak your mind.
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: Mark Baugher <[email-masked]>
Date: Tue, 07 Oct 2003 14:07:05 -0700

Hugh,

>Very little can be said about this draft from the perspective of group 

It's appropriate to a registration protocol for group security.

Mark

---

From: Hugh Harney <[email-masked]>
Date: Tue, 7 Oct 2003 17:44:34 -0400

Mark,

Yes it is a registration protocol.

It's very narrowly focused to a specific architecture.

Hugh

On Tuesday, Oct 7, 2003, at 17:07 US/Eastern, Mark Baugher wrote:

>> Very little can be said about this draft from the perspective of 
>> group security.
>
>> Hugh Harney                                                     
>> Sparta, Inc.
Hugh Harney							Sparta, Inc.

---

From: Mark Baugher <[email-masked]>
Date: Tue, 07 Oct 2003 17:43:33 -0700

Hugh,

>It's very narrowly focused to a specific architecture.

I understand.  It can go either way whether IP telephony protocols stay 
strictly pairwise in their security or employ group-key methods.  So if it 
seems out of scope for group security, I think this is why.

Mark

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 08 Oct 2003 08:21:52 +0200

Mark, Hugh,

yes, it may be used as a registration protocol for group 
security purposes. 

In IP telephony environemnts it may appropriate for group based 
communication using a centralized entity providing the group 
based key to all communicating entities. Here, the approach the 
DHHMAC draft discusses, provides for a secure registration at 
the group controller.

Regards
	Steffen

To:             	Hugh Harney <[email-masked]>
From:           	Mark Baugher <[email-masked]>
Subject:        	Re: [MSEC] DHHMAC draft
Copies to:      	canetti <[email-masked]>, [email-masked]
Date sent:      	Tue, 07 Oct 2003 17:43:33 -0700

> I understand.  It can go either way whether IP telephony protocols
> stay strictly pairwise in their security or employ group-key methods. 
> So if it seems out of scope for group security, I think this is why.
> 
> Mark
> 
> 
> >Hugh
> >
> >
> >>>   Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale
> >>>   beyond a point-to-point constellation; thus, both MIKEY
> >>>   Diffie-Hellman protocols do not support group-based keying for
> >>>   any group size larger than two entities.
> >>>
> >>>>The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has
> >>>>recently completed its last call with no remarks. Infact, there
> >>>>seemed to have been little discussion on this draft on the list.
> >>>>In light of this, we'd like to poll the WG on whether there is
> >>>>interest in advancing this draft to proposed standard, along with
> >>>>MIKEY. Please speak your mind.
> >>>>
> >>>>Best,
> >>>>
> >>>>Thomas and Ran
> >>>>
> >>>>
> >>>>
> >[email-masked]                                   7075 Samuel Morse
> >Drive (410) 872-1515 x203                                   Columbia,
> >MD, 21046
> >
> >

---

From: Hugh Harney <[email-masked]>
Date: Wed, 8 Oct 2003 09:40:21 -0400

Steffen,

I agree with you on the registration at the group controller.

My point was that you only have a single controller AND that controller 
knows a lot about the group members AND the GMs have pre-stored 
knowledge of the GC. Your architecture and assumptions about 
pre-existing knowledge between the GC and the GM greatly simplifies the 
process of setting up a secure cryptographic group.

For example, your architecture makes sure that the GMs know that the GC 
is authorized to download key for this group. This is a fair 
assumption, if you have a common server based architecture in mind. 
However, things get trickier if the GMs don't know which server to go 
to. Or if the GMs don't have pre-stored knowledge of the GC and trust 
it to download key.

Also, the GMs trust the GC to make the appropriate access control 
decision for their data. The GMs in your architecture don't have to 
verify the access control rules to make sure that they are appropriate 
for data the GM is protecting. This is to say that the GMs pretty much 
blindly trust the GC to make the right decision for them.

Hugh

Hugh Harney							Sparta, Inc.