[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issues with IKE that need resolution

Pyda Srisuresh wrote:
> Dan Harkins wrote:
> >
> >   Is there a point in identifying yourself as "198.31.2.0/24"? What
> > does that mean? "I speak for this network"? Without something like the KX
> > record in DNS to delegate that authority why should I belive it? Chances
> > are he'd probably be making this statement through another interface anyway
> > so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are
> > you going to do about the ID_KEY_ID identity? A certificate that certifies
> > that my identity is an intentionally incomprehensible blob is not going
> > to be all that useful.
> >
> 
> I agree. I dont see much point in having IDs for address ranges and
> transport IDs and so forth. Single address (or multiple addresses for
> a multi-homed node) based IDs seem to be the only valid IDs (be it for
> phase I or phase II).

Disagree. Ranges of addresses (etc.) are extremely useful identifiers
for a security gateway which is representing those within the range. 

As for Dan's question,

> >   Is there a point in identifying yourself as "198.31.2.0/24"? What
> > does that mean? "I speak for this network"? Without something like 


Yes, "I speak for this network" is *exactly* what it means, and you
don't need a kx record or anything like it to verify my veracity.
Instead, you need a way to indicate in your policy entry that I am an
authorized proxy in this case. I guess you *could* use a kx record if
you want to, but that's an implementation detail.


<trimmed...>

Dan wrote:
> >   It seems to me that we have identities that are only useful in phase 1 and
> > some of those should have ways to be encoded into a cert. There are others
> > that really only make sense in phase 2 because their purpose is to
> > constrain use of an IPSec SA. As an example, a gateway product receiving
> > phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr =
> > "ID_FQDN dharkins@cisco.com" would not be particularly useful. What
> > does "dharkins@cisco.com" mean? There is no machine cisco.com and there
> > sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and
> > a way to encode it in a cert is good. But passing it in phase 2 would not
> > make much sense. Similarly, a list of subnets is not a very good phase 1
> > identity and I don't see much value in defining a way to encode that in a
> > cert but as a phase 2 identity it may be quite useful. Or am I missing
> > something here?
> >
> 
> I agree, ID payload is predominantly useful in phase 1. However, there
> is need for ID payload in phase II as well. When the IP address of client
> for which IKE is negotiating is different from that of IKE itself, it is
> necessary for IKE to identify the client ID in phase II, (just as it
> specifies the ID for itself in phase I).
> 
> What we need is a new type of policy payload in phase II.

I agree that we may need different payloads for the 2 phases, but think
we need to reconcile the issue I raised in a related post, i.e. that the
ID payload is, by definition, DOI-specific, and this (I think) means
it's a phase 2 critter only. In that case, the new payload type would
need to be in phase 1, or the appropriate language in the ISAKMP doc
would need correcting.

> >From the IKE stand point, I believe, we need to be able to do the following:
> 
>      (1)  Identify one or more policies associated with an SA.
>           Each Policy needs to be assigned an ID, to identify with
>           during the lifetime of SA (or, its extended lifetime). Policy
>           could be as simple as:
> 
>           PERMIT <src address list> <dest address list> <IP protocol>
>                  [<src transport ID list>] [<Dest transport ID list>]
>                  [<Additional options?>]
> 
>           If there is rough consensus on this approach, I dont see a problem
>           with coming up with a payload format to represent policies.
> 

I strongly disagree with your assertion, if I understand it correctly.
Individual policies are a local matter and should NEVER be sent across
the link, but should be somehow indexable based on conversational
context. We currently use either the ID payload or the IP header
contents to index these. We may also use certificates, FQDNs, and
whatever else is defined in for the ID payload, and this whole
(sub)thread started as a result of the assertion that we need other
indices.

I still don't understand this resistance to using some sort of endpoint
identifier to index policy - after all, we are using an identity-based
security model, right?

>      (2)  Ability to add/delete policies dynamically to an SA.
> 
>           This would be particularly useful when some applications
>           require policy changes on the fly. Ex: Take a policy that requires
>           encryption on H.323 application sessions. The signalling protocol
>           in H.323 sets up sessions dynamically and these dynamic sessions
>           need to be notified so that all such sessions are supported by
>           IPsec.
> 

Again, I'm not sure I understand what you mean here, but will point out
that it is possible to share an existing SA, and [ARCH] gives the
details. However, difficulties arise if you negotiate the SA for 2
specific endpoints using IKE, then want to try to piggyback others
(whose selectors will not match upon decryption) onto the session if
both sides do not strictly comply with description in [ARCH]. Again,
though, these are local implementation issues, I think.

Scott
Follow-Ups: References: