Subject: RE: ICIM: comment on IPsecPolicyGroup

From: "Jason, Jamie" <[email-masked]>
Date: Wed, 10 Jan 2001 09:21:38 -0800

I believe we talked about this in San Diego and I agree that it would be
prudent that we derive the IKERule class from an intermediate that would be
something like you describe.

A small correction - IPsecPolicyGroup binds together a set of IKERules and a
set of IPsecRules (thus the * cardinality on each).

Jamie

> -----Original Message-----
> From: Ricky Charlet [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 4:38 PM
> To: .ipsec-policy
> Subject: ICIM: comment on IPsecPolicyGroup
> 
> 
> Howdy,
> 
> 	IPsecPolciyGroup binds together an IKERule and and 
> IPsecRule. I'd like
> to see a layer of abstraction introduced, namely a KeyManagementRule.
> Then under keyManagementRule, we could use IKE for KM services if we
> wanted, but we could also use kerberose, or son-of-ike or manually
> entered keys, or....
> 
> -- 
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
>

---

From: "Hilarie Orman" <[email-masked]>
Date: Wed, 10 Jan 2001 12:48:07 -0700

I see the attraction of the abstraction in theory, but in practice,
KM protocols don't operate in a vacuum ("hey, get me 128 bits
shared with that guy over there").

IKE is the only KM protocol that understands IPSec.  I think that
if other protocols are needed for IPSec KM, they should be
introduced through ISAKMP, so that the negotiation of SA's
is done properly.  

Also, IPSec supports manually shared keys,
so shouldn't be a need to introduce a new rule for specifying
it, should there?

Hilarie

>>> Ricky Charlet <[email-masked]> 01/09/01 05:38PM >>>
Howdy,

	IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd like
to see a layer of abstraction introduced, namely a KeyManagementRule.
Then under keyManagementRule, we could use IKE for KM services if we
wanted, but we could also use kerberose, or son-of-ike or manually
entered keys, or....

---

From: Ricky Charlet <[email-masked]>
Date: Wed, 10 Jan 2001 14:45:56 -0700

Howdy,
	
	Perhaps the details of my suggestion could be improved, but I think
that what I'm asking for is very realistic. We do see KINK, GSAKMP, and
new version of IKE proposals coming our way. 

	 And as far as I have understood,  we do want KM/SA management to be
architecturally separable from IPsec. All I meant to ask for was that
our policy model reflect the philosophy that KeyManagement/SAManagement
is separate from IPsec and does not have to be IKE.  Perhaps I muddled
up some details in the particular remedy I suggested for the model. But
because Hilarie Orman is hinting that it is ok to blur the architectural
line between keyManagement/SaManagement and IPsec, you give me great
pause. Now I'm caught wondering if you really mean that this
architectural distinction is not worth modeling or was it that some of
the details in my suggested remedy were odd.