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

[Toerless Eckert <[e-mail]>]

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 =-
>