Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

["Bhatia, Manav (Manav)" <[e-mail]>]

Stephen,

> > The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why
> > LDP should be an exception. The same has been proposed for BFD btw.
> 
> Even given the above, I fail to see why you repeat this text over
> and over and over. Is there a real logic for that?

Yes. The logic is that Apad keeps changing based on the protocol. There are some specific attacks that can be prevented by defining Apad to mean something specific. In case of OSPFv2 it means the source address of the sender. In case of OSPFv3, it is a value where the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. L in this case is the length of the hash. 

In case of RIpv2 and IS-IS it's a fixed constant.

In this draft Apad is defined as:

In case of IPv4, the first 4 octets contain the IPv4 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times.  
In case of IPv6, the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times.

One way to avoid this duplication is by writing a new RFC that redefines HMAC and includes the Apad. Other documents can only mention the Apad value, while including a normative reference to that RFC.

This however is a long drawn discussion because everyone needs to be convinced on the merits of updating the HMAC specification -- which I am not sure will take how long.

Cheers, Manav


> 
> S
> 
> >
> > Cheers, Manav
> >
> >> -----Original Message----- From: Stephen Farrell
> >> [mailto:[e-mail]] Sent: Wednesday, May 21, 2014
> >> 2:53 AM To: Bhatia, Manav (Manav); IETF Security Directorate; The
> >> IESG; draft- [e-mail] Cc:
> >> Yaron Sheffer; [e-mail] Subject: Re: SecDir review of
> >> draft-ietf-mpls-ldp-hello-crypto-auth-05
> >>
> >>
> >>
> >> On 19/05/14 21:27, Yaron Sheffer wrote:
> >>>>>
> >>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea.
> >>>>> This reviewer does not have the appropriate background to
> >>>>> critique the proposed solution, but there must be an
> >>>>> overwhelming reason to
> >> reopen> >>>>> cryptographic primitives.
> >>>>
> >>>> This is a decision that was taken by Sec Ads when we were doing
> >>>> the crypto protection for the IGPs based on some feedback from
> >>>> NIST.
> >> This
> >>>> mathematics is not new and has been done for all IGPs and has
> >>>> been approved and rather encouraged by the Security ADs.
> >>
> >> The above does not sound like something I recognise. I have
> >> repeatedly asked that documents not re-define HMAC. Perhaps this
> >> time, I'll make that a DISCUSS and not budge. I probably should
> >> have done that before TBH.
> >>
> >> If you are revising that doc, *please* get rid of the re-definition
> >> and just properly refer to HMAC. Its about time to stop repeating
> >> that error.
> >>
> >> S.
> >
> >
> >