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

Agree with Bill below.

As a co-author of the  pair-wise key drafts https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt & https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05  or 
adaptation of IKEv2 for TCP-AO, I can say there was lot of effort done in KARP for this. 

However, eventually KARP WG  decided routing protocols don't need automated key exchange protocol for both pair-wise or for group-keying (out of KARP charter)  and the effort was  not progressed.

I am not fully clear on the exact requirements current context (*) but can answer any specific questions around usage of IKEv2 other than IPSec.

--
Uma C.
* I don't closely follow all Anima WG posts, Sorry!

-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of William Atwood
Sent: Thursday, June 08, 2017 1:04 PM
To: anima@ietf.org; Toerless Eckert <tte@cs.fau.de>; Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN

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 <tte@cs.fau.de> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works  
>> -= IPv6 IoT consulting =-
>>
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> 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:william.atwood@concordia.ca
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima