LDP Hello Cryptographic Authentication
RFC 7349
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Adrian Farrel; former steering group member) (was Discuss, Yes) Yes
IANA's questions have been addressed through several revisions and clarifications. This document is ready to progress. --- Please fix the nit raised by Joel Halpern in his Rtg Dir review... The one nit is that I could not find the text indicating that if a receiver receives an unauthenticated LDP Hello packet, and is expecting authentication to be used (either always, or with the source the packet claims to be from) then the hello packet should be silently discarded.
(Alia Atlas; former steering group member) (was Discuss) Yes
Thanks for handling my concerns so quickly.
(Stephen Farrell; former steering group member) Yes
Many thanks to the authors/chairs and the secdir reviewer (Yaron Sheffer) for working hard to significantly improve this document (from the security weeny point of view:-) abstract: this is really defining a way to use HMAC (with SHA) and not just SHA, it'd be better to put it that way in the abstract. intro says: "The LSRs could be configured to only accept Hello messages from specific peers when authentication is in use." Isn't "could" a little understated there? Presumably you would only ever use this if you have some list of (keys/identifiers) and you don't want messages from outside that set to affect that set of LDPs? I'm not suggesting you add a MUST (unless you want to) but more that you say that this mechanism only makes sense if you are in fact configured to "only accept..." 2.2: The last para here calls for extending the lifetime of the "last" key indefinitely. That's probably justifiable for operational reasons, but would be considered "odd" for crypto devs perhaps. And there could be issues with using a key a really really large number of times even for HMAC, I'd have to go ask someone (that kind of formula is not in my brain-buffer:-) and its probably mainly theoretical here but a crypto API just might insist on that in some cases causing an interesting failure case. Anyway, I think it might be worth making this last para a subsection of its own so its more likely to be noticed by developers. And you might want to consider what happens if a crypto API insists that the application can no longer use that key because its been used too many times. section 5: I think that the AuthTag having the source IP address as input is what prevents reflection attacks. Is that correct? If so, then I think that would be worth calling out specifically either here or in the security considerations. (And whenever we get to the point of running LDP via NATs, then this AuthTag will need to change, but that, I assume, is ok for now.) 6.1: Why the last sentence? section 7: not asking for this to go into the doc (unless you want) but I'd be interested in knowing if there are any interesting residual threats related to the fact that we're not providing confidentiality here. Its ok if you don't want to answer this bit btw, I'm just curious.
(Alissa Cooper; former steering group member) No Objection
Section 1:
"Of the above, implementations MUST include
support for at least HMAC-SHA-256 and SHOULD include support for
HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or
HMAC-SHA-512."
This makes it sound as if HMAC-SHA-384 and HMAC-SHA-512 support are mutually exclusive. I think the phrasing in Section 3 is better and should be repeated here (or, in any event, the two sections should say the same thing):
"Of the above, implementations of this specification MUST include
support for at least HMAC-SHA-256 and SHOULD include support for
HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC-
SHA-512."
Section 2.2:
"This is a 32-bit unsigned integer used to uniquely identify an LDP
SA between two LDP peers, as manually configured by the network
operator (or, in the future, possibly by some key management
protocol specified by the IETF)."
It would help to clarify whether you mean (1) a key management protocol that does not already exist may be defined in the future and used for this purpose, or (2) in the future SA IDs may be configured using a key management protocol that already exists.
"In order to achieve smooth key transition, KeyStartAccept SHOULD be
less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
KeyStopAccept."
What are the conditions under which these SHOULDs might be violated?
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
The definition of the Length field in section 2.3 is nebulous. Does it include the 96 bits of fixed-length fields or just the variable length Authentication Data. It is unclear since the definition says it is the length of the "value field". Is it worth mentioning why DTLS is not sufficient for this UDP-based protocol?
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
Thank you for addressing the SecDir review. I support Stephen's comments and will watch the responses. I don't have anything else to add.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
I agree with Ted's DISCUSS in spirit, even if I disagree with it as stated. What needs to be clear here is that the LSR receiving Hello messages needs to have a policy for each neighbor as to whether it requires authentication or does not. If it is configured to require authentication, it MUST NOT accept unauthenticated Hello messages. (Ted's message implies that this policy should be configured based on receipt of authenticated messages, which is a terrible idea.)
(Spencer Dawkins; former steering group member) No Objection
I'm also curious about Brian's "Is it worth mentioning why DTLS is not sufficient for this UDP-based protocol?" comment, but whatever you decide in conversations with him will be fine with me.
(Ted Lemon; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSS point (included below FTR): Adrian raised this as a nit, but it's really a DISCUSS: a conforming implementation of this specification could perfectly well accept an unauthenticated hello after it's accepted an authenticated hello, because there's no requirements language forbidding this behavior. One would hope that implementors would be smart and not do this, but given that this is a standard, it SHOULD be mentioned explicitly. :)