Hi Yaron, draft-ietf-trill-channel-tunnel-09 has been posted. I believe the security aspects are much improved and would appreciate it if you could take a look.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Fri, Apr 22, 2016 at 2:01 PM, Donald Eastlake <[email protected]> wrote: > Hi Yaron, > > As we discussed in Buenos Aires, here is a revised response to your > SECDIR review of draft-ietf-trill-channel-tunnel based on the -08 > reversion of that draft. This version of the draft has the group > keying material removed as per > http://www.ietf.org/mail-archive/web/trill/current/msg07215.html > > On Sun, Aug 30, 2015 at 5:00 PM, Yaron Sheffer <[email protected]> > wrote: > > > >... > > > > Summary > > > > I believe the draft is not ready for IETF LC in its current form. I > > assume the original intention was to use DTLS, but the use of DTLS > > is not well specified and the alternative that's proposed for > > multicast comes with inferior security. > > See below. > > > Details > > > > • In general, I don't understand why it makes sense to define a whole new > > security protocol, just for control-plane traffic of one specific > protocol, > > important as it may be. At the very least I would expect an analysis of > > potential alternatives (IPsec? MACsec?) and why they do not fit this use > > case. > > Version -08 of the draft has been significant modified as below. I > believe the use of DTLS is better specified and group keying is > no longer in the draft, being deferred to subsequent documents. The > draft specifies the use of serial unicast for multicast / broadcast / > unknown unicast. > > > • As a result of the home-brew transport protocol, we also don't get > > a standard key management protocol. > > In this revised draft, although an authentication only option is > provided, which leverages IS-IS key management, when DTLS is used its > key management facilities are available. > > > • And from a process POV, the TRILL WG may not be the best place, as > > far as participants' expertise, to develop a security protocol. An > > early SecDir review certainly helps, but I'm not sure the current > > reviewer is capable of detecting every last issue that might be > > lurking in the protocol. > > At this point, the Channel Tunnel protocol is being used to tunnel > DTLS so I don't think there is that much risk. > > > • 4.1: the A and E bits are not guaranteed to be correct? Then why > > are they here? They describe critical security properties, and > > therefore someone is bound to use them to make critical policy > > decisions. If the bits' semantics are not guaranteed, we'd better > > drop them. > > • A bit: I think we are confusing authentication with integrity > > protection. With opportunistic security, you usually don't have > > authentication, but integrity protection is still worthwhile. > > These bits have been eliminated. > > > • 4.2: Coverage - it would be nice if Fig. 2.1 showed the coverage > > of authentication (integrity protection!) and encryption. Why is an > > Ethernet frame's FCS not covered by integrity protection? Is there > > any non-malicious reason someone would want to modify the FCS in > > transit? > > Figures showing coverage have been added to Section 4.2. > > The only time there is an FCS is if the link between two RBridge ports > is Ethernet. If, for example, the link is PPP or pseudowire, there is > no FCS; In particular, the inner Ethernet-like payload of a TRILL Data > packet does not have an FCS. So providing integrity protection of an > FCS does not make sense. An RBridge Channel packet looks like a TRILL > Data packet and can go multiple RBridge hops some of which are > Ethernet and have an FCS and some of which are not Ethernet and do not > have an FCS. Even if all were Ethernet, the FCS can change due to > changes in presences/absence of an outer VLAN tag or other tags or the > like. > > > • 4.3: "in some cases" - why not simply say, "When SType is 1 or 3"? > > While this is always done for SType 1, it might or might not be used > for SType 2 or future STypes. (The SType numbering has changed a bit > and there is no STyp3 in the revised draft.) > > > • 4.3: why deconstruct HKDF and use HKDF-Expand instead of simply > > using the whole thing, including HKDF-Extract? > > Because the draft follows the advice in RFC 5869 that specifies HKDF: > > In some applications, the input may already be a > good pseudorandom key; in these cases, the "extract" stage is not > necessary, and the "expand" part can be used alone. > > Version -08 of the draft says, "It is assumed that the IS-IS keying > material is of high quality." > > > • I am confused about 4.1 vs. 4.5, and specifically, what does the > > Size byte cover. I think this is incorrect in 4.5. > > Maybe I am missing something but they look compatible with me. Section > 4.1 is more general, and now says that when security information is > present it consists of four reserved bits followed by 12 bits of size > information followed by zero to 2**12-1 bytes of "More Info". Section 4.5 > is more specific and says that for a particular SType, this "More > Info" consists of the two byte RFC 5310 Key ID followed by a variable > amount of "Authentication Data". > > > • 4.6: this section starts with certificates (presumably, both > > client and server should authenticate with a cert) and then moves on > > to PSK. Are both allowed? > > The current draft provides that if DTLS is in use, then PSK MUST be > supported and certificates MAY be supported. Perhaps that MAY should > be turned back into a SHOULD. > > > • 4.6: TLS is rapidly moving toward perfect-forward secrecy. Why > > require a cipher suite that's being deprecated across all of > > industry (TLS_RSA_WITH_AES_128_CBC_SHA256)? > > The draft no longer specifies cipher suites and is intended to just > defer to whatever the DTLS implementation requirements are. > > I am not sure how much the following comments apply to the current draft... > > • 4.6.: I am still unclear on how CT keys are derived from DTLS. > > • 4.6: Why have a TRILL-level key ID with DTLS-PSK has the notion of > > key ID? > > • 4.6: with certificates the frames may be very large. Does the protocol > > support such sizes? > > • 4.6: there should be a lot more text about how DTLS is used to wrap L2 > > frames. > DTLS is not used to wrap L2 frames but rather to wrap Channel Tunnel > payloads. The type of the payload is give by the PType. True, there is > a PType that says the payload is an Ethernet frame. Figure 3.4 show > what it would look like without security or with just authentication. > Possibly a figure should be added for the DTLS security case. > > > • 4.7: if this mode is assumed for multicast, what is the > > assumed/recommended mode for unicast? > > • Obviously integrity protection where the MAC key is shared with all > peers > > is very weak. There are various ways to deal with that, starting with RSA > > signatures but including more efficient methods (TESLA comes to mind). > Have > > you considered any of them? > > Group security for multi-destination Channel Tunnel messages is being > deferred to another document. The revised draft only covers use of > serial unicast with pairwise security. > > > • 4.7.1: if the authentication data is variable length, you must ensure > that > > the field that indicates its size is integrity-protected as well. > > • Actually, I'm not sure where this size is indicated. > > Its size would be indicated in the Channel Tunnel Header (which > includes the Security Information field) that is shown as > authenticated in Figure 4.2. > > > • It seems to me that a fully random 128-bit nonce would be both > > simpler to implement and more secure than the scheme proposed here. > > • Typo: designed -> designated. > > • 5: assuming we will have DTLS handshakes nested within CT, how are > > errors indicated? > > If DTLS is not supported at the destination, then you get a Channel > Tunnel (actually RBridge Channel) error saying SType not supported. > > If DTLS is supported at the destination, you get a DTLS error Alert > back as a Channel Tunnel message. > > > • General: is there any facility for replay protection? If no, why > > not? > > When DTLS is used, the DTLS replay protection is available. There is > no replay protection if no security is used or if RFC 5310 > authentication is used. > > > • 7: The more normative parts of the Security Considerations would > > probably fit nicely into a separate Applicability section. > > • 7: I think the document should be much more clear (normative) > > about what message types are allowed within the tunnel, or not. And > > possibly about required filtering by address. > > I disagree. The whole idea is to be a general, extensible messaging > facility. I don't think it is possible to anticipate in advance what > people might want to use it for and the tests they should > make. I'm not sure how much more can generally and validly be said > other than to be conservative in what you accept and, as it states in > the draft "only process payload types required and then only with > adequate authentication for the particular circumstances". > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
