Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN

[William Atwood <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
> 

-- 

Dr. J.W. Atwood, Eng.             tel:   [phone] x3046
Distinguished Professor Emeritus  fax:   [phone]
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[e-mail]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8