Toerless,
The idea to extend IKEv2 for "wider scope" negotiation can certainly be
seen in the KARP documents. In this case:
1) for unicast negotiation, the protocols being keyed include IPsec and
TCP-AO
2) for multicast negotiation, the base model was GDOI (adapted to
IKEv2), but an election procedure was added
The addition is because GDOI's administratively-assigned group
controller/key server was not suitable for a negotiation whose scope was
a single network segment. KARP needed something that would work on its
own. Sounds as if "autonomic" would be a good descriptor for this case...
Unfortunately, these two documents never made it past the "draft-author"
stage. However, they were well-enough defined that I have a student who
has formally validated some of their security properties.
documents (all four that I believe are pertinent):
draft-mahesh-karp-rkmp
draft-hartman-karp-mrkmp
draft-yeung-g-ikev2
draft-chunduri-karp-using-ikev2-with-tcp-ao
Bill
On 08/06/2017 2:25 PM, Toerless Eckert wrote:
> Thanks, Michael:
>
> Any examples of how IKEv2 is used to negotiate other non-IPsec protocols ?
>
> [ I have not found examples describing the use of IKE(v2) for dissimilar
> crypto associations outside of IPsec, except for maybe RFC4595. If i
> wanted for example to negotiate between 802.1ae or IPsec, i wonder what
> amount of trouble/work that would be to define that as an IKEv2 extension
> vs. defining this just as a GRASP negotiation in TLS. ]
>
> Yes, we just made up TLS, and yes, if we can't come to a conclusion that
> IKEv2 is not the most feasible approach (see above for my concerns),
> TLS may potentially also not be the most widely accepted transport given the
> constrained IoT worlds preference to use CoAP/dTLS if i am not mistaken.
>
> In any case this discussion seems to point to need to take the more
> intelligent
> negotiation out of the ACP document into a separate draft where we can
> continue to
> ponder and decide on the best option. Right ?
>
> Eg: Maybe a "lightweight heterogenous security association negotiation
> mechanism"
> would have to be GRASP/CoAP/dTLS. and the negotiation functions should
> defintely be able to argue how they did inherit or differ from IKEv2.
>
> In the end this may simple be a more strategic modularization direction,
> to reuse evolving building blocks eg: IKEv2 was built as a silo when there
> where no widely adopted initial security association protocols like TLS/dTLS.
> And the message formats used in IKEv2 where predating evolving industry
> preferences over a reuse of request/response exchange standards such as those
> of HTTP/CoAP/(hopefully GRASP) or encoding rules such as those of XML or
> JSON/CBOR.
>
> If using IKEv2 to negotiate into eg: 802.1ae would be easier and make
> adoption easier, i'd be all for it. Past experience just makes me think this
> to be less likely.
>
> Wrt to IP in dTLS:
>
> This would of course only be a candidate ACP channel. For negotiation we
> would not
> need IP, it would just be GRASP/(d)TLS or GRASP/CoAP/dTLS.
>
> We had the argument in Chigaco or before whether it would be necessary to
> have a
> 1 paragraph separate document to state that IP packets can be carried in dTLS,
> and i thought we did in the meeting come to the conclusion that that was not
> necessary. But that may have been premature. I was looking at:
> draft-mavrogiannopoulos-openconnect-00. That certainly is mostly complexity
> because it combines TLS for connection negotiation and dTLS for the data.
> Gee, i wonder why they didn't use IKEv2 ;-))
>
> Nevertheless: Would be interesting to find the most simple RFC example of
> an application protocol that just uses dTLS to have an example of what dTLS
> parameters one would need to specify.
>
> (i assume OpenVPN is just an implementation of openconnect mechanism, right ?,
> i have not used it myself but just linux openconnect and Cisco Anyconnect)
>
> Btw: Eric recommended to take a look at
> https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-09 as a
> recent example how to specify security profiles for (d)TLS.
>
> Cheers
> toerless
>
> On Wed, Jun 07, 2017 at 10:36:09PM -0400, Michael Richardson wrote:
>>
>> Toerless Eckert <[email protected]> wrote:
>> > So, in some near term future, ANI/ACP is so successfully that we
>> > have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and
>> > 802.1ae
>>
>> That's only three, btw.
>> And the answer is that you'd use IKEv2 to negotiate which one of them to use,
>> because IKEv2 was designed *SPECIFICALLY* to do this kind of thing.
>>
>> > a) We need a security association before we negotiate so the
>> negotiation does
>> > not become an attack vector. Solution: We build a a TLS connection
>>
>> You just assumed TLS.
>> If you can assume TLS, I can assume IKEv2, and save a lot more code, and
>> pages less
>>
>> And you have to assume TLS 1.3 (so you need new code and new libraries on
>> every device). The process will still be suspectible to trivial TCP RST
>> attacks. So please add some security for that part too!
>>
>>
>> >> 2) We have no meaningful specification for IP over *TLS thing.
>> >> (but that, I mean a deployed protocol with an RFC and widespread
>> >> implementation.)
>>
>> > The negotiation is just GRASP inside TLS. No IP needed.
>>
>> I'm talking about the "dTLS" option above you just named.
>> What is it? "IP in DTLS" isn't anywhere near enough.
>> Why not add OpenVPN to the list too?
>> At least it has widely used, extensively tested reference code, even if it
>> has no public specification.
>>
>> Some developer in Mumbai will still have no idea what that means.
>> Is there an IXIA or SPIRENT module so that I can test it at 10G? or 100G?
>> That's a serious objection: you can't just make stuff up like that.
>>
>> >> 3) I have been trying to understand the MACsec KMP, as some would
>> like to run
>> >> the ACP over MACsec. I originally was led to believe that there
>> was no
>> >> KMP, but after finding the full specifications, it's clear that there
>> is
>> >> support for PSK and other things and even IDevID are mentioned.
>> >> I'd still like to suggest that we negotiate the use of MACsec (or of
>> some
>> >> yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard,
>> and
>> >> if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2
>> minimal
>> >> implementation can be very small; lwig has some good advice, but it
>> >> assumes initiator only, and we need both.
>> >>
>> >> I can not see a purpose for SONN, and I do not think we can do a
>> proper
>> >> security analysis, and it forces TLS to be MTI. SONN will therefore
>> add
>> >> a significant (3-5 pages) of text on how to use TLS properly.
>>
>> > Would be great if you could point me to some example RFC where
>> something like
>> > this ("how to use TLS appropriately") is done!
>>
>> I think that the Opportunistic Security specification,
>> https://tools.ietf.org/html/rfc7435
>> tried to do this. I'm not a TLS guy, so go ask one of them.
>>
>> --
>> Michael Richardson <[email protected]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
--
Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
Distinguished Professor Emeritus fax: +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University EV 3.185 email:[email protected]
1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
