On Sun, Mar 18, 2018 at 12:21 PM, Donald Eastlake <[email protected]> wrote:
> Hi Eric, > > On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla <[email protected]> wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-trill-over-ip-15: Discuss > > > > ... > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Hopefully this is easy to resolve. In the best case, you will be > > able to demonstrate that this is not a problem in practice and > > document that. If not, the actual fix is straightforward, though > > incompatible. > > > > S 7.1.1. > > I am concerned about the use of the IS-IS key in this way. First, on > > general principles, you should not use a single key both as input to a > > KDF and directly as a working key. Specifically, however, RFC 5310 > > defines the use of HMAC authentication with IS-IS-key as the HMAC > > key, and HKDF-Expand is really just SHA-256. Thus, if an attacker > > was able to observe (or cause to be created) an IS-IS packet that > > happened to have the same contents as the HKDF Info value you > > provide would then know the IKE PSK. > > > > The correct practice here is to separately expand both the IS-IS > > key *and* the IKE PSK from the same original value. If you cannot > > do that, you should at least generate an Info value which is > > guaranteed to not be the input to any RFC 5310 MAC. > > The source may not be easily accessible. > > The first byte of the data to which the RFC 5310 MAC is applied is always > 0x83, the Interdomain Routeing Discriminator. The first byte of the data > below is 0x54 ('T') so they cannot be the same. > > HKDF-Expand-SHA256 ( IS-IS-key, > "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) > > > Could also add some text such as "Note that the value to which the HKDF > function is applied starts with 0x54 ('T') while the data to which RFC 5310 > authentication is applied (an IS-IS PDU) starts with 0x83, the Interdomain > Routeing Discriminator, thus, although they are both SHA256 based, they are > never applied to the same value." > OK. This is not cryptographically ideal (you really should be deriving two separate keys from HKDF) but given this I am not aware of any weakness. We could presumably consult with someone like Karthik Bhargavan or Hugo Krawczyk, but I imagine you'd just get "we don't know of any problems", but it's not great, which is more or less my position. Based on this, I will withdraw my DISCUSS and assume that Alia can shepherd these changes. > When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that > > incorporates the IS-IS shared key in order to bind the TRILL data > > session to the IS-IS session. The pre-shared key that will be used > > > > The technique you provide does not guarantee a binding between the > > sessions. It merely ensures (modulo the caveat above) that both sides > > know the IS-IS Key. It's easy to see this by noting that you could > > move IS-IS traffic from one IPsec association to another. If you > > actually want to bind these sessions, you must do something different. > > I think the idea was just that, in conjunction with the text later in this > section, the IPsec key wouldn't be used for longer than the IS-IS key. > > How about just deleting the words "in order to bind the TRILL data session > to the IS-IS session."? > That seems fine to me. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I see that native encapsulation is incompatible with NATs (S 8). > > That's probably worth stating upfront to minimize confusion. > > > > S 5.4.2. > > > > f. No middleboxes are allowed in the TRILL over IP transport link > > because middlebox support is beyond the scope of this document. > > > > How would you know if no middleboxes were in the link? > > Well, if they map IP addresses, the "neighbor" values inside the Hellos > will not get mapped, will not match, and thus you will be unable to > establish adjacency and nothing will flow over the link except Hellos (no > data, LSPs, etc.). You need an application specific gateway for TRILL to > operate through a NAT. On the other hand, a sufficiently benign middlebox > (if there are such things) which, for example, only had a black list of > some IP protocols / ports / addresses, that had no effect on the TRILL data > or control traffic would be pretty invisible and TRILL should work fine > through it. > > How about the following replacement text: > > f. This document assumes there are no middleboxes in the path and thus > does not cover restrictions on such middleboxes. Middlebox support is > beyond the scope of this document. > > SGTM. > S 5.5. > > Can you use VXLAN with IPsec? > > "VXLAN" is really Ethernet over VXLAN over UDP. I don't see a problem with > doing Ethernet over VXLAN over UDP over IPsec. > Perhaps worth mentioning. > S 5.6. > > What security mechanism do you expect to use for TCP? IPsec again? > > Yes. > Also perhaps worth mentioning. > > the timing and implementation details may be such that P! and P2 each > > > > Nit: P1, right? > > Yes, sorry about that pesky shift key... > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) > 155 Beaver Street, Milford, MA 01757 USA > <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g> > [email protected] > >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
