LDP Hello Cryptographic Authentication
RFC 7349

Note: This ballot was opened for revision 06 and is now closed.

(Alia Atlas) (was Discuss) Yes

Comment (2014-06-19)
No email
send info
Thanks for handling my concerns so quickly.

(Adrian Farrel) (was Discuss, Yes) Yes

Comment (2014-06-04 for -08)
No email
send info
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.

(Stephen Farrell) Yes

Comment (2014-06-09 for -08)
No email
send info
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.

(Jari Arkko) No Objection

(Richard Barnes) No Objection

Comment (2014-06-11 for -08)
No email
send info
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.)

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2014-06-09 for -08)
No email
send info
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?

(Spencer Dawkins) No Objection

Comment (2014-06-09 for -08)
No email
send info
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.

(Brian Haberman) No Objection

Comment (2014-06-09 for -08)
No email
send info
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?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) (was Discuss) No Objection

Comment (2014-06-19)
No email
send info
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.  :)

(Kathleen Moriarty) No Objection

Comment (2014-06-09 for -08)
No email
send info
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.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection