IETF Security Area Advisory Group

headers Stephen Kent | 5 Apr 2004 15:49

_______________________________________________
saag mailing list
saag <at> mit.edu
https://jis.mit.edu/mailman/listinfo/saag

Steve-

> the BGP document cites mandatory use of RFC 2385 as one of the 
> changes, up front, but then never makes any reference to the RFC in 
> the text. That's not a good way to communicate the intent of the 
> change, i.e., the intent of the change has not been integrated into 
> the body of the spec.

It seems that you simply have missed the following reference in the "Security
Considerations" section:

 draft-ietf-idr-bgp4-23.txt:

    The authentication mechanism that an implementation of BGP MUST sup-
    port is specified in [RFC2385]. The authentication provided by this
    mechanism could be done on a per peer basis.

    BGP vulnerabilities analysis is discussed in [BGP_VULN].

> in the context of Steve Bellovin's document there is no reason to
> perpetuate the error of the RFC 2385 title, i.e., to continue to 
> refer to the message authentication code created by the use of a 
> shared secret and a hash function as a "signature."  One might even 
> take this opportunity to point out that the title of the RFC is 
> misleading and should not be confused with digital signature 
> technologies.

My understanding is that Steve used the wording from the 2385's title on
purpose, since we're talking about a specific document with a specific title,
plus about a TCP option with a specific name (though now considered misleading).

>>  > LDP is a much newer protocol and so there is less of a "large
>>>  installed base that has been using this for years" sense.
>>
>>We do have quite considerable installed base for LDP and strictly speaking it
>>has been there for a few years. So, though the statement may not 
>>sound as strong
>>when applied to LDP, it is correct.

> then the text should say that LDP represents as big an installed base 
> as BGP's use of MD5, if that is the case. If not, then find some 
> accurate but similarly persuasive characterization that justifies 
> this use.

OK. We'll see if the wording can be improved.

> For contrast, RFC xxxx specifies use of MD5 in the same 
> fashion for OSPF security, but nobody is suggesting that this be 
> approved, presumably because there is no large, installed base, right?

RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its
transport nature). It's widely deployed and is a full IETF Standard. If you mean
"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
only one or two implementations.

>>>   I am also
>>>  disturbed that the LDP spec (RFC 3036) refers to this as a signature
>>>  as well, and incorporates bad text from the old BGP RFC, e.g., "...
>>>  acts like a signature for that segment .." further perpetuating the
>>>  confusion between message authentication codes and digital
>>>  signatures. Any chance we can get this fixed in both the BGP document
>>>  before it progresses and in the next rev of 3036?
>>
>>The BGP spec (neither old nor new) does not include this 
>>terminology, so I don't
>>think we need to fix it from this perspective.
>>
>>Improvement of the LDP spec could be considered by the MPLS WG when it starts
>>working on a new revision of the spec.
>>
>>Thank you.
>>
>>Alex

> you are right that the primary focus of this discussion is 
> progression of BGP. But, since you argued that LDP is appropriately 
> included in the rationale discussion for this document, I assume you 
> will want to progress that RFC too,
> otherwise why bother mentioning it now?  I would rather not have to 
> revisit this at that time, so I suggest you ask the MPLS WG to make a 
> note of this error now.

Looking at the LDP spec, it uses the word "signature" as part of the reference
to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
that 2385 uses incorrect terminology, it would be confusing to refer to it as
something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
Option", as this is not what 2385 specifies.

Thanks

Alex

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

At 4:26 PM -0700 4/6/04, Alex Zinin wrote:
>Steve-
>
>>  the BGP document cites mandatory use of RFC 2385 as one of the
>>  changes, up front, but then never makes any reference to the RFC in
>>  the text. That's not a good way to communicate the intent of the
>>  change, i.e., the intent of the change has not been integrated into
>>  the body of the spec.
>
>It seems that you simply have missed the following reference in the "Security
>Considerations" section:
>
>  draft-ietf-idr-bgp4-23.txt:
>
>     The authentication mechanism that an implementation of BGP MUST sup-
>     port is specified in [RFC2385]. The authentication provided by this
>     mechanism could be done on a per peer basis.
>
>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

No, I didn't miss it, Alex. I consider it a trivial reference that 
fails to do an adequate job. The Security Considerations section of a 
document is not where one first specifies a requirement for a 
protocol. It is a place to comment upon what has already been 
specified, putting it in context relative to security.

>  > in the context of Steve Bellovin's document there is no reason to
>>  perpetuate the error of the RFC 2385 title, i.e., to continue to
>>  refer to the message authentication code created by the use of a
>>  shared secret and a hash function as a "signature."  One might even
>>  take this opportunity to point out that the title of the RFC is
>>  misleading and should not be confused with digital signature
>>  technologies.
>
>My understanding is that Steve used the wording from the 2385's title on
>purpose, since we're talking about a specific document with a specific title,
>plus about a TCP option with a specific name (though now considered 
>misleading).

Alex, the terminology was always wrong, and I pointed that out to the 
IESG when the RFC was out for last call years ago. But Jeff Schiller 
apparently didn't think the terminology error was worth fixing, and I 
doubt that the rest of the IESG was concerned back then. Don't phrase 
this as though we're in the realm of revisionist political 
correctness. It was wrong then, and it's still wrong.

>	<SNIP>
>
>>  For contrast, RFC xxxx specifies use of MD5 in the same
>>  fashion for OSPF security, but nobody is suggesting that this be
>>  approved, presumably because there is no large, installed base, right?
>
>RFC 2328 includes the OSPF MD5 authentication option (similar to 
>TCP-MD5 in its
>transport nature). It's widely deployed and is a full IETF Standard. 
>If you mean
>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
>only one or two implementations.

Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
I was referring to 2238. We have a slightly odd situation here. 
Steve's document explains why BGP is being progressed even though it 
contains a normative reference to an RFC (TCP MD5 ...) that will not 
be progressed. The argument is that the latter RFC is technically 
poor, but it's not so awful to use it with BGP considering the 
context, because it is widely deployed, and because it is the only 
point-to-point authentication mechanism defined for BGP.  Then there 
is the minor mention of LDP at te end.

You suggest, above, that OSPF's use of MD5 is also widely deployed, 
something of which I was not aware. (Or did you just mean that many 
OSPF implementations support the feature, but you don't know if it is 
tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 
in the same marginal way internally. So, in one sense there is no 
need to mention this in Steve's document, because it is just 
explaining why the IESG is making an exception for BGP, and LDP in 
the future. But, in a more fundamental sense, we have already 
endorsed the inappropriate use of MD5 in routing protocols in terms 
of OSPF, and we're merely continuing the tradition with BGP and LDP 
.

	<SNIP>

>  > you are right that the primary focus of this discussion is
>  > progression of BGP. But, since you argued that LDP is appropriately
>  > included in the rationale discussion for this document, I assume you
>  > will want to progress that RFC too,
>  > otherwise why bother mentioning it now?  I would rather not have to
>  > revisit this at that time, so I suggest you ask the MPLS WG to make a
>  > note of this error now.
>
>Looking at the LDP spec, it uses the word "signature" as part of the reference
>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
>that 2385 uses incorrect terminology, it would be confusing to refer to it as
>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
>Option", as this is not what 2385 specifies.

If you look at Steve's document, he uses the right terminology 
throughout, while referring to the document via its RFC number. 
That's a good model for any document that wants to avoid perpetuating 
the terminology error inherent in the title of 2385.

Steve

In message <p06020401bc99b101fea7 <at> [128.89.89.75]>, Stephen Kent writes:

>If you look at Steve's document, he uses the right terminology 
>throughout, while referring to the document via its RFC number. 
>That's a good model for any document that wants to avoid perpetuating 
>the terminology error inherent in the title of 2385.
>

It's probably worth putting a note in my document noting the erroneous 
terminology in the title of 2385.  It's not a bad idea having a similar 
parenthetical note in the bgp document.

		--Steve Bellovin, http://www.research.att.com/~smb

Steve-

 [putting IDR back on the Cc: list--I'd like the WG to be in the loop]

Wednesday, April 7, 2004, 8:09:53 AM, Stephen Kent wrote:
> At 4:26 PM -0700 4/6/04, Alex Zinin wrote:
>>Steve-
>>
>>>  the BGP document cites mandatory use of RFC 2385 as one of the
>>>  changes, up front, but then never makes any reference to the RFC in
>>>  the text. That's not a good way to communicate the intent of the
>>>  change, i.e., the intent of the change has not been integrated into
>>>  the body of the spec.
>>
>>It seems that you simply have missed the following reference in the "Security
>>Considerations" section:
>>
>>  draft-ietf-idr-bgp4-23.txt:
>>
>>     The authentication mechanism that an implementation of BGP MUST sup-
>>     port is specified in [RFC2385]. The authentication provided by this
>>     mechanism could be done on a per peer basis.
>>
>>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

> No, I didn't miss it, Alex. I consider it a trivial reference that 
> fails to do an adequate job. The Security Considerations section of a 
> document is not where one first specifies a requirement for a 
> protocol. It is a place to comment upon what has already been 
> specified, putting it in context relative to security.

Steve, would you mind making a suggestion on how the text could be improved?
E.g., would a separate section in the main body of the document specifying
the requirement for TCP-MD5 support be useful?

>>  > in the context of Steve Bellovin's document there is no reason to
>>>  perpetuate the error of the RFC 2385 title, i.e., to continue to
>>>  refer to the message authentication code created by the use of a
>>>  shared secret and a hash function as a "signature."  One might even
>>>  take this opportunity to point out that the title of the RFC is
>>>  misleading and should not be confused with digital signature
>>>  technologies.
>>
>>My understanding is that Steve used the wording from the 2385's title on
>>purpose, since we're talking about a specific document with a specific title,
>>plus about a TCP option with a specific name (though now considered 
>>misleading).

> Alex, the terminology was always wrong, and I pointed that out to the 
> IESG when the RFC was out for last call years ago. But Jeff Schiller 
> apparently didn't think the terminology error was worth fixing, and I 
> doubt that the rest of the IESG was concerned back then. Don't phrase 
> this as though we're in the realm of revisionist political 
> correctness. It was wrong then, and it's still wrong.

I didn't mean to argue whether the terminology is right or wrong, I'll leave up
to you guys. My point was that we have to use the actual title of the document
when referring to it, even though the title may not accurately describe what's
inside. Anyway, Steve suggested that a clarifying note is put in the docs...

>>	<SNIP>
>>
>>>  For contrast, RFC xxxx specifies use of MD5 in the same
>>>  fashion for OSPF security, but nobody is suggesting that this be
>>>  approved, presumably because there is no large, installed base, right?
>>
>>RFC 2328 includes the OSPF MD5 authentication option (similar to 
>>TCP-MD5 in its
>>transport nature). It's widely deployed and is a full IETF Standard. 
>>If you mean
>>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
>>only one or two implementations.

> Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
> I was referring to 2238. We have a slightly odd situation here. 
> Steve's document explains why BGP is being progressed even though it 
> contains a normative reference to an RFC (TCP MD5 ...) that will not 
> be progressed. The argument is that the latter RFC is technically 
> poor, but it's not so awful to use it with BGP considering the 
> context, because it is widely deployed, and because it is the only 
> point-to-point authentication mechanism defined for BGP.  Then there 
> is the minor mention of LDP at te end.

> You suggest, above, that OSPF's use of MD5 is also widely deployed, 
> something of which I was not aware. (Or did you just mean that many 
> OSPF implementations support the feature, but you don't know if it is 
> tuend on?)

All more-or-less mature OSPF implementations I know of certainly support the
feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise
networks. I do not have numbers for you, but even as of 3-4 years ago (when I
worked close with operators on a regular basis), it was not uncommon to see it
configured.

> OSPF does not use the TCP MD5 option, but rather uses MD5 
> in the same marginal way internally. So, in one sense there is no 
> need to mention this in Steve's document, because it is just 
> explaining why the IESG is making an exception for BGP, and LDP in 
> the future.

Agreed.

> But, in a more fundamental sense, we have already 
> endorsed the inappropriate use of MD5 in routing protocols in terms 
> of OSPF, and we're merely continuing the tradition with BGP and LDP 
> .

It seems a discussion on why MD5 is inappropriate or insufficient in
routing protocols would be interesting if we take it to RPSEC.

Thanks.

Alex

> 	<SNIP>

>>  > you are right that the primary focus of this discussion is
>>  > progression of BGP. But, since you argued that LDP is appropriately
>>  > included in the rationale discussion for this document, I assume you
>>  > will want to progress that RFC too,
>>  > otherwise why bother mentioning it now?  I would rather not have to
>>  > revisit this at that time, so I suggest you ask the MPLS WG to make a
>>  > note of this error now.
>>
>>Looking at the LDP spec, it uses the word "signature" as part of the reference
>>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
>>that 2385 uses incorrect terminology, it would be confusing to refer to it as
>>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
>>Option", as this is not what 2385 specifies.

> If you look at Steve's document, he uses the right terminology 
> throughout, while referring to the document via its RFC number. 
> That's a good model for any document that wants to avoid perpetuating 
> the terminology error inherent in the title of 2385.

> Steve

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

On Apr 07, 2004, at 11:09, Stephen Kent wrote:
> You suggest, above, that OSPF's use of MD5 is also widely deployed, 
> something of which I was not aware. (Or did you just mean that many 
> OSPF implementations support the feature, but you don't know if it is 
> tuend on?)

I believe that most shipping OSPF implementations have supported
its MD5 authentication option for some years now.  I also believe
that OSPF MD5 is reasonably widely, though not universally,
deployed, both now and for the past several years.

Absent something that is both better and practical to implement/deploy
(NB: OSPF with Digital Signatures has proven to be impractical to
implement or deploy in commercial IP networks), OSPF MD5 provides
significant very useful risk reduction.

Some few of us here are focused on ways that we can reduce operational
risk today, rather than ignore the current risk.  Other folks mileage
might well vary.

Cheers,

Ran
rja <at> extremenetworks.com

At 8:42 PM -0400 4/8/04, RJ Atkinson wrote:
>	<SNIP>
>
>Absent something that is both better and practical to implement/deploy
>(NB: OSPF with Digital Signatures has proven to be impractical to
>implement or deploy in commercial IP networks), OSPF MD5 provides
>significant very useful risk reduction.
>
>Some few of us here are focused on ways that we can reduce operational
>risk today, rather than ignore the current risk.  Other folks mileage
>might well vary.
>
>Cheers,
>
>Ran
>rja <at> extremenetworks.com

Ran,

here are some questions relevant to the reducing operational risk 
focus of your comments:

	-  how do you think operators choose the keys used with MD5 in OSPF?

	- how often are those keys changed

	- are they unique for each link, or common for all links in a net?

Steve

Alex,

>	<SNIP>
>
>
>Steve, would you mind making a suggestion on how the text could be improved?
>E.g., would a separate section in the main body of the document specifying
>the requirement for TCP-MD5 support be useful?

A reasonable approach would be to have a section of the document that 
describes the use of this TCP option. It should explain why/when one 
would use the option in the context of BGP links and what protection 
it offers. Somewhere there should be a discussion of precautions 
should be taken re selection and use of keys, but maybe this is more 
of a BCP matter than a protocol standards matter.

>	<SNIP>
>
>I didn't mean to argue whether the terminology is right or wrong, 
>I'll leave up
>to you guys. My point was that we have to use the actual title of the document
>when referring to it, even though the title may not accurately describe what's
>inside. Anyway, Steve suggested that a clarifying note is put in the docs...

actually, one often refers to an RFC by number in the text, and 
includes the title only in the references section.

>	<SNIP>
>  > But, in a more fundamental sense, we have already
>>  endorsed the inappropriate use of MD5 in routing protocols in terms
>>  of OSPF, and we're merely continuing the tradition with BGP and LDP
>>  .
>
>It seems a discussion on why MD5 is inappropriate or insufficient in
>routing protocols would be interesting if we take it to RPSEC.
>

of course the issue is not MD5 per se, but the use of MD5 plus a 
secret bit string as a message authentication code, instead of HMAC, 
in any context.

Steve

In message <p0602040dbc9c7531f9ec <at> [128.89.89.75]>, Stephen Kent writes:
>At 8:42 PM -0400 4/8/04, RJ Atkinson wrote:
>>	<SNIP>
>>
>>Absent something that is both better and practical to implement/deploy
>>(NB: OSPF with Digital Signatures has proven to be impractical to
>>implement or deploy in commercial IP networks), OSPF MD5 provides
>>significant very useful risk reduction.
>>
>>Some few of us here are focused on ways that we can reduce operational
>>risk today, rather than ignore the current risk.  Other folks mileage
>>might well vary.
>>
>>Cheers,
>>
>>Ran
>>rja <at> extremenetworks.com
>
>Ran,
>
>here are some questions relevant to the reducing operational risk 
>focus of your comments:
>
>	-  how do you think operators choose the keys used with MD5 in OSPF?
>
>	- how often are those keys changed
>
>	- are they unique for each link, or common for all links in a net?
>

There's some relevant discussion in RFC 3562.

		--Steve Bellovin, http://www.research.att.com/~smb

At 2:38 PM -0400 4/9/04, Steven M. Bellovin wrote:
>In message <p0602040dbc9c7531f9ec <at> [128.89.89.75]>, Stephen Kent writes:
>>At 8:42 PM -0400 4/8/04, RJ Atkinson wrote:
>>>	<SNIP>
>>>
>>>Absent something that is both better and practical to implement/deploy
>>>(NB: OSPF with Digital Signatures has proven to be impractical to
>>>implement or deploy in commercial IP networks), OSPF MD5 provides
>>>significant very useful risk reduction.
>>>
>>>Some few of us here are focused on ways that we can reduce operational
>>>risk today, rather than ignore the current risk.  Other folks mileage
>>>might well vary.
>>>
>>>Cheers,
>>>
>>>Ran
>>>rja <at> extremenetworks.com
>>
>>Ran,
>>
>>here are some questions relevant to the reducing operational risk
>>focus of your comments:
>>
>>	-  how do you think operators choose the keys used with MD5 in OSPF?
>>
>>	- how often are those keys changed
>>
>>	- are they unique for each link, or common for all links in a net?
>>
>
>There's some relevant discussion in RFC 3562.

That RFC focuses on BGP, and there is is potentially harder to 
manages the keys because different parties are at each of of E-BGP 
links. But, my question to Ran was what he believed practice to be in 
OSPF, relative to the reduced operational risk criteria he cited.

Steve

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

22	June 2013
10	May 2013
4	April 2013
39	March 2013
1	February 2013
37	January 2013
12	December 2012
45	November 2012
68	October 2012
7	September 2012
25	August 2012
174	July 2012
107	June 2012
81	May 2012
9	April 2012
36	March 2012
3	February 2012
12	January 2012
9	December 2011
41	November 2011
16	October 2011
18	September 2011
30	August 2011
81	July 2011
43	June 2011
31	May 2011
71	April 2011
30	March 2011
13	February 2011
11	January 2011
22	December 2010
36	November 2010
23	October 2010
5	September 2010
40	August 2010
38	July 2010
16	June 2010
12	May 2010
7	April 2010
17	March 2010
2	February 2010
3	January 2010
3	December 2009
24	November 2009
10	October 2009
1	September 2009
8	August 2009
16	July 2009
6	June 2009
4	May 2009
56	April 2009
84	March 2009
41	February 2009
63	January 2009
110	December 2008
30	November 2008
25	October 2008
14	September 2008
10	August 2008
18	July 2008
4	June 2008
5	May 2008
17	April 2008
37	March 2008
38	February 2008
27	January 2008
41	December 2007
1	November 2007
6	October 2007
29	September 2007
6	August 2007
15	July 2007
33	June 2007
43	May 2007
38	March 2007
6	February 2007
24	January 2007
31	December 2006
23	November 2006
11	October 2006
11	September 2006
2	August 2006
12	July 2006
24	May 2006
4	April 2006
5	March 2006
30	February 2006
8	December 2005
4	November 2005
32	October 2005
6	September 2005
26	August 2005
9	July 2005
23	June 2005
36	May 2005
7	April 2005
56	March 2005
25	February 2005
68	January 2005
3	December 2004
57	November 2004
17	October 2004
42	September 2004
83	August 2004
8	July 2004
8	June 2004
4	May 2004
16	April 2004

Re: draft-iesg-tcpmd5app-00.txt

Re: [saag] draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt

Re: [saag] draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt

Re: draft-iesg-tcpmd5app-00.txt