RE: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

Thanks Steve, we will scope the text showing the lack of robustness for
targeted attacks as you pointed, or even removing it on favor or a more
encouraging text for stronger encryption.

Thanks

Eduardo

-----Original Message-----
From: Steven M. Bellovin [mailto:smb <at> research.att.com] 
Sent: Tuesday, October 05, 2004 12:49 PM
To: Jean-Francois Mule
Cc: Russ Housley; bwijnen <at> lucent.com; ipcdn <at> ietf.org; Eduardo Cardona;
Richard Woundy  <at>  Comcast; Eric Rosenfeld; Oscar Marcia; Greg White
Subject: Re: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 

That address most of my concerns.  But I also said this:

  The Security Considerations section says

      The time to crack DES could be additionally
      mitigated by a compromised value for the TEK lifetime and Grace
Time
      (up to a minimum of 30 minutes for the TEK lifetime, see
      Appendix A [1]).

  That's only partially correct.  These keys are confidentiality keys; 
  they're still valuable even after they're no longer in active use, 
  because they can be used to decrypt old traffic.  (By contrast, old 
  authentication keys are useless to an attacker.)

Re: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

That address most of my concerns.  But I also said this:

  The Security Considerations section says

      The time to crack DES could be additionally
      mitigated by a compromised value for the TEK lifetime and Grace Time
      (up to a minimum of 30 minutes for the TEK lifetime, see
      Appendix A [1]).

  That's only partially correct.  These keys are confidentiality keys; 
  they're still valuable even after they're no longer in active use, 
  because they can be used to decrypt old traffic.  (By contrast, old 
  authentication keys are useless to an attacker.)

You need to strengthen your text; while frequent key changes help,
an attacker can often select what to attack.  For example, email checking
is generally timer-driven; someone monitoring the link can easily spot
an eamil session by noticing the periodicity.  For example, in the middle
of the night, when there's little email traffic (except, of course, for
the daily spam load), there will be a set of very similar (in length
and timing) packets in each direction, every N minutes, where N is probably
in the range 5-15 minutes.  Select the confidentiality key for this
period, attack it, and recover the user's email password.  For that
attack, a key lifetime of 30 minutes or 30 days is the same -- it's a
targeted attack.

status of ipcdn DOCSIS RFIv2 mib - 2670bis

   This note provides a brief status update on the ipcdn DOCSIS RFIv2
mib Internet-Draft. It is also a follow-up from the IETF meeting #60 in
San Diego.

--- Brief status
The current ID is draft-ietf-ipcdn-docs-rfmibv2-11. 

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt
A working group last call was issued on 1/23/2004 and ended on 2/6/2004.
The authors believe that draft 11 does address all the wg comments as
well as AD review comments from Bert. Based on the input received this
week from the authors and the current editor Eduardo, no new comments
have been received since the ID was revised at the end of July 2004.

--- San Diego wg meeting follow-up
Based on our meeting minutes at
http://www.ietf.org/proceedings/04aug/171.htm#rfimib , we wanted to ping
the mailing list to see if another WGLC is needed. If you think a second
WGLC should be issued, please let the ipcdn wg know by sending an email
to the list by Wednesday October 13, 5pm ET.

--- Next steps
Pending wg consensus that a new WGLC is not needed and no objection to
move this ID forward, it is the wg chairs intent to submit the ID for
publication/IESG review to Bert.

Rich and Jean-Francois.
IPCDN co-chairs

RE: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

	See more inline, sorry for the delay in responding to you.

> -----Original Message-----
> From: Russ Housley [mailto:housley <at> vigilsec.com] 
> Sent: Friday, September 24, 2004 4:41 PM
> To: Jean-Francois Mule; Steven M. Bellovin; 
> bwijnen <at> lucent.com; ipcdn <at> ietf.org
> Cc: Eduardo Cardona; Greg White; Oscar Marcia; Richard Woundy 
>  <at>  Comcast; Eric Rosenfeld
> Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
> 
> 
> Jean-Francois:
> 
> >--- 1. Syntax of docsBpi2CmPublicKey and range limitations:
[snip], the proposed resolution on issue #1 was fine with you.
> This is fine with me.

> >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS
> >BPI+
[snip]
> >  Symmetric encryption:
> >  AES (AES128CbcMode, AES256CbcMode), 3DES, DES
> >  ^^^ new addition, optional to support

You wrote:
> You need to specify a mode for 3DES too.  It will probably be 
> CBC like the 
> rest of the algorithms you support.

RE: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

Jean-Francois:

> > >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS
> > >BPI+
>[snip]
> > >  Symmetric encryption:
> > >  AES (AES128CbcMode, AES256CbcMode), 3DES, DES
> > >  ^^^ new addition, optional to support

Fine.

>You wrote:
> > You need to specify a mode for 3DES too.  It will probably be
> > CBC like the
> > rest of the algorithms you support.
>
>Yes. The following has been proposed:
>  t3DES128EdeMode - equivalent to openssl's DES_ecb2_encrypt() two-key 
> Triple-DES ECB
>  t3DES128CbcMode - equivalent to openssl's DES_ede2_cbc_encrypt() two-key 
> Triple-DES CBC

I seriously doubt that t3DES128EdeMode is useful in this context.  ECB had 
some properties that are probably bad in this environment.

>PS: as a separate note, should the IETF be defining a set of crypto MIB 
>textual-conventions for the crypto libraries (like some of the ones in the 
>openssl lib http://www.openssl.org/docs/crypto/crypto.html)?

I do not think this is needed.  It certainly does not belong in this document.

RE: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

Russ wrote:
> I seriously doubt that t3DES128EdeMode is useful in this 
> context.  ECB had 
            ^^^ 
you mean EDE here
> some properties that are probably bad in this environment.

Okay, we can remove it, no pb.
Just fyi, 3DES EDE was also proposed because it is already used in the
BPI+ spec for the traffic encryption key (TEK). See page 21 of BPI+ at
http://www.cablemodem.com/downloads/specs/BPI+_I11-040407.pdf :
"The traffic encryption key (TEK) in the Key Reply is triple DES
(encrypt-decrypt-encrypt or EDE mode) encrypted, using a two-key, triple
DES key encryption key (KEK) derived from the Authorization Key."

This should close the threads on your comment - thank you again for the
review. 
Jean-Francois

Cadence description text

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

RE: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

Jean-Francois:

> > I seriously doubt that t3DES128EdeMode is useful in this
> > context.  ECB had
>             ^^^
>you mean EDE here
> > some properties that are probably bad in this environment.
>
>Okay, we can remove it, no pb.

Okay.

>Just fyi, 3DES EDE was also proposed because it is already used in the
>BPI+ spec for the traffic encryption key (TEK). See page 21 of BPI+ at
>http://www.cablemodem.com/downloads/specs/BPI+_I11-040407.pdf :
>"The traffic encryption key (TEK) in the Key Reply is triple DES
>(encrypt-decrypt-encrypt or EDE mode) encrypted, using a two-key, triple
>DES key encryption key (KEK) derived from the Authorization Key."

This is still a poor choice.  See RFC 3217 and RFC 3394 for better solutions.

Russ

docsis subscriber management i-d draft -16

I've just submitted draft -16 to fix a couple of issues from the IESG
review and to align the publication order with expected updates of RFC
2669 and 2670. The changes are:

(1) References to RFC 2669 are changed to informative, and the
corresponding RFC editor notes were removed.

(2) The second paragraph of 'Security Considerations' was reworded per
Russ Housley's suggestion.

(3) The section reference in that same paragraph was fixed per Allison
Mankin's note.

(4) Editor notes w.r.t. successor of RFC 2670 were left in, as it is
expected that submgt will be held until that successor is available.

Respectfully submitted,
Wilson Sawyer

I-D ACTION:draft-ietf-ipcdn-subscriber-mib-16.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Management Information Base for Data Over Cable 
			  Service Interface Specification (DOCSIS) Cable 
			  Modem Termination Systems for Subscriber Management
	Author(s)	: W. Sawyer
	Filename	: draft-ietf-ipcdn-subscriber-mib-16.txt
	Pages		: 26
	Date		: 2004-10-12
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines a set of managed objects for SNMP-based
   management of Data-over-Cable Service Interface Specification
   (DOCSIS)-compliant Cable Modem Termination Systems. These managed
   objects facilitate protection of the cable network from misuse by
   subscribers. The Differentiated Services MIB (RFC 3289) provides the
   filtering functions needed here, making use of classification items
   defined in this specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-16.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-subscriber-mib-16.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-16.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn