Subject: [MSEC] msec architecture draft and email flow

From: Hugh Harney <[email-masked]>
Date: Thu, 28 Jun 2001 14:41:17 -0400

All,

I think I need to clarify my position on both GDOI and GSAKMP. I think this 
is necessary because I'm being referenced. I'm also an author of both 
protocols. I believe they both have valid Internet requirements they are 
trying to address.

GDOI is specifically aimed at centralized key distribution for IPSec, ESP 
and AH. It is aimed at applications with some of the following 
characteristics. First, the data is owned by a single entity. Second, it 
was decided during an authors meeting that GDOI would rely on an external 
security policy infrastructure (left undefined in the document). I think 
there are perfectly valid applications for this architecture.

GSAKMP is aimed at non centralized key distribution (although it can 
support a centralized architecture). It also has incorporated the 
mechanisms needed to support applications with multiple sources of data and 
multiple data ownership issues. To support these applications it 
incorporates policy definition and dissemination mechanisms. Unfortunately, 
flexibility in architectures leads to complexity in protocols.

<The following comments are editorial in nature pertaining to the MSEC 
Architecture document as posted. Note: they are editorial because they 
express my opinion and have not been voted upon by the MSEC group.>

I believe the statement "Extensions to IKE, however, are probably the best 
solution for IPSec
protocols over IP multicast services [GDOI]" in the introduction leads the 
reader to a conclusion that GDOI is THE ONLY valid key management protocol 
for IPSec. I believe it is a valid protocol given some constraints on the 
application. (see above)

The Group Key Management Archtecture, policy section, states that MSEC will 
totally rely on an external policy infrastructure. I believe that this 
statement is too narrow. Some applications may rely on external policy 
infrastructures, but not all. This is an architecture document for all 
applications and solutions. I believe the Policy Building Blocks document 
from the SMUG and the new policy work being done for the MSEC working group 
is valid and important work. In fact, I believe policy is critical for MSEC 
to specify.

<The following is an attempt to clarify my position on the policy 
infrastructure issue.>

The position of GDOI is as stated in the document "As is done in IKE, GDOI 
defines and conveys only cryptographic policies, which are contained in the 
SA KEK and SA TEK payloads. "

Given the above condition, I suggested the following be added to the GDOI 
Internet Draft. This second GDOI quote (below) constitutes a criteria I 
believe could make the above GDOI assumption work in a secure system.

<begin second quote from GDOI>
A security policy repository having some access protocol may need to be 
queried prior to key-management session establishment to determine what the 
initial cryptographic policies are for that establishment. GDOI assumes the 
existence of such a repository and protocol for GCKS and member policy 
queries. Thus GDOI requires that group-security policy be represented in a 
policy repository and accessible using a policy protocol.

GDOI assumes that at least the following group-policy information is 
externally managed.
	o Group owner, authentication method, and delegation method for 
identifying a GCKS for the group
	o Group GCKS, authentication method, and any method used for delegating 
another GCKS for the group
	o Group membership rules or list and authentication method

There is a team of individuals who are working on group policy within MSEC. 
This team may develop alternative group policy models that will necessitate 
update to the way group policy is referenced in GDOI. For example, the 
current GDOI draft assumes the existence of a group owner or owners who 
delegate key-distribution authority to a GCKS, which validates a member's 
credentials before adding a member to a particular group. Alternative group 
policy models might require changes to GDOI payloads, exchanges, or processing.
<end GDOI quote>

The above represents a boolean expression. IF GDOI restricts it's policy to 
cryptographic mechanisms, THEN we have to rely on an external 
infrastructure to provide the services expressed in the second GDOI quote. 
I believe GDOI can operate securely with this conditional boolean statement.

This does not mean that I believe all MSec key management algorithms MUST 
restrict themselves to only handling policy that refers to cryptographic 
mechanisms, AND MUST therefor rely on an external policy infrastructure.

Note: Read words written in capital letters as Boolean.

I believe MSec security policy is important to key management. I believe 
that internal or external means can supply that policy to the group. I 
don't believe the MSec architecture should exclude key management 
approaches that provide policy mechanisms internal to the key management 
protocols.

Hugh

________________________________________________________
Hugh Harney		[email-masked]		410-381-9400 x203
________________________________________________________

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 12:39:19 -0700

Hugh,

>believe could make the above GDOI assumption work in a secure system.

For those who have not read GDOI, the quote below IS from the current GDOI 
I-D.

>queried prior to key-management session establishment to determine what 
>the initial cryptographic policies are for that establishment. GDOI 
>assumes the existence of such a repository and protocol for GCKS and 
>member policy queries. Thus GDOI requires that group-security policy be 
>represented in a policy repository and accessible using a policy protocol.
>
>         o Group GCKS, authentication method, and any method used for 
> delegating another GCKS for the group
>There is a team of individuals who are working on group policy within 
>MSEC. This team may develop alternative group policy models that will 
>necessitate update to the way group policy is referenced in GDOI. For 
>example, the current GDOI draft assumes the existence of a group owner or 
>owners who delegate key-distribution authority to a GCKS, which validates 
>a member's credentials before adding a member to a particular group. 
>Alternative group policy models might require changes to GDOI payloads, 
>exchanges, or processing.
><end GDOI quote>
>
>The above represents a boolean expression. IF GDOI restricts it's policy 
>to cryptographic mechanisms, THEN we have to rely on an external 

There is ALWAYS an external policy infrastructure.  And there will always 
be some policy in key management.  I'd prefer to limit that to items that 
are directly pertinent to key management operation.  There are policy 
issues outside of key management that are important such as "who are the 
members of this group?" or "what's this member's USPO zipcode?" that might 
play a crucial role for some participant receiving or sending to a 
particular group, but which SHOULD NOT be handled through the key 
management protocol in my opinion.  Similarly, the policy issue such as 
"you must encrypt all communications with the GCKS with AES" is something 
that CANNOT be handled through the key management protocol.  gkmarch states 
this in 4.1.

Best Regards, Mark

---

From: Hugh Harney <[email-masked]>
Date: Thu, 28 Jun 2001 15:50:17 -0400

Mark,

>that CANNOT be handled through the key management protocol.  gkmarch 
>states this in 4.1.

Your correct there is always a certificate infrastructure at the bare minimum.

I think our only difference of opinion is what policy information is 
relevant to key management. My opinion is that policy should be considered 
relevant to the key management protocol, if omission of that policy would 
lead to a security attack on the key management system. Stated another way, 
security policy for key management must be sufficient to ensure verifiably 
secure key is available for data encryption/authorization.

I do not imply how that policy information is verified or disseminated. In 
the key management protocol or via a trusted infrastructure outside of the 
key management protocol.

I guess the challenge ahead of us is figuring out which policy items are 
important for key management. I look forward to working these issues 
through with you in the future. We should probably write a document 
together, I'd also include Patrick McDaniel, and or Pete Dinsmore. Figuring 
out which data is important is the first step. Then we can figure out how 
to deal with that data and the security requirements on key management 
protocols and/or trusted policy infrastructures. I've had ample input to 
the policy document that is coming out soon. Perhaps you can review that 
document and it can serve as a spring board for a joint effort.

Unfortunately, the security policy data that is relevant to a key 
management protocol is highly dependant on the architecture that protocol 
exists in and the application that protocol supports. Ultimately, our job 
is to provide verifiably good key to algorithms for protection of data. Any 
document we write must also define the architecture and the application 
assumed.

Hugh

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 14:12:21 -0700

Hi Hugh
At 03:50 PM 6/28/2001 -0400, Hugh Harney wrote:
>>members of this group?" or "what's this member's USPO zipcode?" that 
>>might play a crucial role for some participant receiving or sending to a 

I think pre-shared key is much more of a bare minimum than a PKI.

>lead to a security attack on the key management system. Stated another 
>way, security policy for key management must be sufficient to ensure 
>verifiably secure key is available for data encryption/authorization.

Yes.  I think this is our only real difference.  How should we proceed in 
resolving it?

>together, I'd also include Patrick McDaniel,

Thanks, but I still have my hands full from my last document-writing 
assignment :-)  We developed a list of policy items for GDOI - I think that 
you and Andrea actually helped write the text.  The gkmarch authors 
reworked it and put it into gkmarch.  While it's true that certain things 
were taken from the GDOI document and put in gkmarch, it's also true that 
things were taken from the GSAKMP and GKMBB documents and put into 
GDOI.  Would it be useful to go through the list - in section 4.1 of 
gkmarch - and identify things that might be in the key management protocol 
rather than outside of it?

Best Regards, Mark

>and or Pete Dinsmore. Figuring out which data is important is the first 
>step. Then we can figure out how to deal with that data and the security 
>requirements on key management protocols and/or trusted policy 
>infrastructures. I've had ample input to the policy document that is 
>coming out soon. Perhaps you can review that document and it can serve as 
>a spring board for a joint effort.
>
>is to provide verifiably good key to algorithms for protection of data. 
>Any document we write must also define the architecture and the 
>application assumed.
>
>
>
>Hugh
>
>

---

From: Mark Baugher <[email-masked]>
Date: Sat, 30 Jun 2001 01:27:36 -0700

Hugh,

At 02:41 PM 6/28/2001 -0400, Hugh Harney wrote:
>All,
>
>I think I need to clarify my position on both GDOI and GSAKMP. I think 
>this is necessary because I'm being referenced. I'm also an author of both 
>mechanisms needed to support applications with multiple sources of data 
>and multiple data ownership issues. To support these applications it 
>incorporates policy definition and dissemination mechanisms. 
>Unfortunately, flexibility in architectures leads to complexity in protocols.

what if GSAKMP did not incorporate "policy definition and dissemination 
mechanisms?"  How would this lead to a reduction in GSAKMP protocol complexity?

>for IPSec. I believe it is a valid protocol given some constraints on the 

If we meant "THE ONLY valid key management protocol for IPsec" then why did 
we write "probably the best solution."  Obviously you're reading quite a 
bit into this.

>The Group Key Management Archtecture, policy section, states that MSEC 
>will totally rely on an external policy infrastructure. I believe that 
>this statement is too narrow. Some applications may rely on external 
>policy infrastructures, but not all. This is an architecture document for 
>all applications and solutions. I believe the Policy Building Blocks 
>document from the SMUG and the new policy work being done for the MSEC 
>working group is valid and important work. In fact, I believe policy is 
>critical for MSEC to specify.

I too believe that policy is critical for msec to specify.

>defines and conveys only cryptographic policies, which are contained in 
>the SA KEK and SA TEK payloads. "
>

Yes, I agree with this too.  I'll add that we are able to eliminate 
additional parameters and options from GDOI by making this assumption.

>mechanisms, AND MUST therefor rely on an external policy infrastructure.

uh, why doesn't it?

>approaches that provide policy mechanisms internal to the key management 

I think it should.  How do we resolve this.  For one thing, let's refer to 
some of your suggestions that were added to the GDOI spec.

>exchanges, or processing.

Which items in the three bullets might belong in key management?

Mark