Dan Wing | 1 Feb 2007 21:58
Picon
Favicon

FW: I-D ACTION:draft-wing-rtpsec-keying-eval-02.txt


(Sorry about that last message.)

Differences are:
  A.1.  Changes from -01 to -02  
     o  Removed DTLS-RTP
     o  Added note about SDP Capability Negotiation and its impact on
        best-effort SRTP

Diff is available at:
  http://tinyurl.com/3cxf99

Comments welcome.

-d

> -----Original Message-----
> From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org] 
> Sent: Thursday, February 01, 2007 12:50 PM
> To: i-d-announce <at> ietf.org
> Subject: I-D ACTION:draft-wing-rtpsec-keying-eval-02.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Evaluation of SRTP Keying with SIP
> 	Author(s)	: F. Audet, D. Wing
> 	Filename	: draft-wing-rtpsec-keying-eval-02.txt
> 	Pages		: 35
(Continue reading)

Cullen Jennings | 3 Feb 2007 03:23
Picon
Favicon
Gravatar

Good News on RTPSEC BOF


This BOF has been approved.

Thanks,
Cullen <with my AD hat on>

Cullen Jennings | 4 Feb 2007 17:36
Picon
Favicon
Gravatar

Re: FIPS-140 required?


On Jan 26, 2007, at 2:54 PM, Dan Wing wrote:

>
> Is anyone seeing a requirement for FIPS-140 for products that  
> implement
> SRTP?

Yes

(with my guy who works at cisco hat:-)

dan_york | 5 Feb 2007 01:35
Favicon

Re: FIPS-140 required?


Dan,

Cullen's note reminded me that I also wanted to reply... with two different hats:


Yes, we are occasionally seeing RFPs that state a FIPS-140 requirement for any encryption, including that of SRTP.  They are typically from government or occasionally financial institutions.

  (with my guy who works at Mitel hat)

I am assuming this is probably true, but I want to just state it so that it's out in the open -  I'm not entirely sure why you are asking, Dan, but I would certainly NOT want to see any changes to SRTP RFCs or other documents that made FIPS-140 certification either a requirement or a default for SRTP.  I would like to see (and believe you do too) SRTP adopted widely and would not want to set up barriers that might get in the way of a startup or other companies implementing SRTP (or using it as an excuse for why they can NOT implement SRTP).  There's also the wee little detail that FIPS is only a US government standard (although various other countries do follow it).

Again, I'm assuming you are not doing this, but with such a cryptic question, I thought I'd just state that to be clear.

  (with my guy who works with VOIPSA and wants to help encourage better VoIP security throughout the industry hat)

Dan-who-has-too-many-hats

--
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel Corp.     http://www.mitel.com
dan_york <at> mitel.com +1-613-592-2122
PGP key (F7E3C3B4) available for
secure communication




Cullen Jennings <fluffy <at> cisco.com>
Sent by: owner-ietf-rtpsec <at> mail.imc.org

02/04/2007 11:36 AM

       
        To:        Dan Wing <dwing <at> cisco.com>
        cc:        <ietf-rtpsec <at> imc.org>
        Subject:        Re: FIPS-140 required?





On Jan 26, 2007, at 2:54 PM, Dan Wing wrote:

>
> Is anyone seeing a requirement for FIPS-140 for products that  
> implement
> SRTP?


Yes

(with my guy who works at cisco hat:-)


Michael Richardson | 5 Feb 2007 14:56
Picon

Re: RTPSec BOF proposal for IETF 68


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Lakshminath" == Lakshminath Dondeti <ldondeti <at> qualcomm.com> writes:
    Lakshminath> Next, do we have a consensus set of evaluation criteria
    Lakshminath> now to weigh the solution drafts against?  It would be
    Lakshminath> good to publish that soon in some form 
    Lakshminath> (probably as an update to Dan and Francois's draft?)

  I didn't think we had reached that point yet.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRcc3dICLcPvd0N1lAQLg4wgAqZMdIYqPccblM/KVMw/omXYCZkNnluK/
HrWA/NeHJ4is7iDFKLPdO/zh3LHtJZI3YgXOuZbHLYCZHJP4y3dFSVMPMKZRjLyw
Xz42Dpgf2d++cVpBJ7QL4283FUeymvoephanyJsEUteKUdD3sr+J/t1cHr2T8ZOu
O/rQF3gkuaFVQZhu9xk3r2jmEMaVb449MJKS6Va10mqQva95WuKoc8wbGKkKo7WF
qHlY/XEZj34Z4rYdYGokDZVj4J7/NuIk1c9yV8U/jOACJN+kQv96jK37OZrpxsq1
ixknzHITvE4ZSfaQppR2P/wOYk26J0VCEs/Y/sD+WHZ/huZLMy8RSQ==
=H56R
-----END PGP SIGNATURE-----

Nhut Nguyen | 5 Feb 2007 20:31

Early and late rogue RTP packets

Hi everyone,

Congrats on the approval of the upcoming BoF session! Looking forwards to great discussions!

 

BTW, anybody knows of a generally agreed upon definition of late and early rogue RTP packets? There are some references out there but the definition seems conflicting based on whether the reference timing is based on detection or on the session:

 

1)     Early rogue RTP packets: detected BEFORE analyzing packet, e.g. packets received after a session has been closed. Late rogue: detected AFTER analyzing packets: e,g. malformed RTP packets.

 

2)     Early rogue: packets received BEFORE the session ends and late rogue: received AFTER the session ends.

 

As you can see depending on which definition to be used, RTP packets received after a BYE message can be called EARLY (definition 1) or LATE (definition 2)! L. (one option is to ignore early or late, just rogue RTP packets J)

 

What is the consensus? Inquiring mind wants to know!

 

Cheers,

 

Nhut   

Dan Wing | 6 Feb 2007 00:11
Picon
Favicon

RE: Early and late rogue RTP packets


I haven't seen anything written up on such a thing, and I expect the
different definitions are because of PSTN gateways and other devices (SBCs?)
which re-use UDP ports too quickly; the UDP ports need to remain unused for
a while for all the same reasons TCP ports need to remain unused for a while
(TIME_WAIT).  The existing values for TCP's TIME_WAIT are probably too long
for today's Internet, but re-using a UDP port immediately between two calls
is just asking for trouble.

Related to this topic, I expect you have read
draft-stucker-sipping-early-media-coping-03.txt?  This document shows some
interesting behaviors all of which get even more interesting when combined
with an endpoint that wants to establish an SRTP call.

-d

> -----Original Message-----
> From: owner-ietf-rtpsec <at> mail.imc.org 
> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of Nhut Nguyen
> Sent: Monday, February 05, 2007 11:32 AM
> To: ietf-rtpsec <at> imc.org
> Subject: Early and late rogue RTP packets
> 
> Hi everyone,
> 
> Congrats on the approval of the upcoming BoF session! Looking 
> forwards to great discussions!
> 
>  
> 
> BTW, anybody knows of a generally agreed upon definition of 
> late and early rogue RTP packets? There are some references 
> out there but the definition seems conflicting based on 
> whether the reference timing is based on detection or on the session:
> 
>  
> 
> 1)     Early rogue RTP packets: detected BEFORE analyzing 
> packet, e.g. packets received after a session has been 
> closed. Late rogue: detected AFTER analyzing packets: e,g. 
> malformed RTP packets.
> 
>  
> 
> 2)     Early rogue: packets received BEFORE the session ends 
> and late rogue: received AFTER the session ends.
> 
>  
> 
> As you can see depending on which definition to be used, RTP 
> packets received after a BYE message can be called EARLY 
> (definition 1) or LATE (definition 2)! :-(. (one option is to 
> ignore early or late, just rogue RTP packets :-))
> 
>  
> 
> What is the consensus? Inquiring mind wants to know!
> 
>  
> 
> Cheers,
> 
>  
> 
> Nhut   
> 
> 

Dan Wing | 5 Feb 2007 22:53
Picon
Favicon

RE: RTPSec BOF proposal for IETF 68


Michael Richardson wrote:

> >>>>> "Lakshminath" == Lakshminath Dondeti 
> <ldondeti <at> qualcomm.com> writes:
>     Lakshminath> Next, do we have a consensus set of 
>     Lakshminath> evaluation criteria
>     Lakshminath> now to weigh the solution drafts against?  
>     Lakshminath> It would be
>     Lakshminath> good to publish that soon in some form 
>     Lakshminath> (probably as an update to Dan and Francois's draft?)
> 
>   I didn't think we had reached that point yet.

Please elaborate.

-d

Dan Wing | 5 Feb 2007 23:09
Picon
Favicon

RE: FIPS-140 required?


Dan York wrote: 

> Yes, we are occasionally seeing RFPs that state a FIPS-140 
> requirement for any encryption, including that of SRTP.  They 
> are typically from government or occasionally financial institutions. 

Ok.

>   (with my guy who works at Mitel hat) 
> 
> I am assuming this is probably true, but I want to just state 
> it so that it's out in the open -  I'm not entirely sure why 
> you are asking, Dan,

Here is the approximate text that I am considering to add to
draft-wing-media-security-requirements:

   The United States Government can only purchase and use crypto
   implementations that have been validated by the FIPS-140 [FIPS-140-2]
   process:

      "This standard [FIPS-140] is applicable to all Federal agencies
      that use cryptographic-based security systems to protect sensitive
      information in computer and telecommunication systems (including
      voice systems) ...  The adoption and use of this standard is
      available to private and commercial organizations."[cryptval]

   Some commercial organizations, such as banks and defense contractors,
   also require or prefer equipment which has validated by the FIPS-140
   process.

and a new requirement:

   A solution SHOULD use algorithms that allow FIPS 140-2
   certification.

> but I would certainly NOT want to see 
> any changes to SRTP RFCs or other documents that made 
> FIPS-140 certification either a requirement or a default for 
> SRTP.  I would like to see (and believe you do too) SRTP 
> adopted widely and would not want to set up barriers that 
> might get in the way of a startup or other companies 
> implementing SRTP (or using it as an excuse for why they can 
> NOT implement SRTP).  There's also the wee little detail that 
> FIPS is only a US government standard (although various other 
> countries do follow it). 

Yes, FIPS-140 is a US Government standard, but I don't 
understand the concern.  For example, FIPS-140, today, allows 
a module that implements IPsec to pass FIPS certification; this 
does not mean IPsec is somehow evil or has weak security.

> Again, I'm assuming you are not doing this, but with such a 
> cryptic question, I thought I'd just state that to be clear. 

Ok, so you want to build equipment that can be FIPS compliant
and you want to build different equipment that was cannot be
FIPS compliant?  It'd be a mistake to choose an Internet 
key exchange mechanism that, for example, did something that
made it impossible to pass FIPS certification.

-d

>   (with my guy who works with VOIPSA and wants to help 
> encourage better VoIP security throughout the industry hat) 
> 
> Dan-who-has-too-many-hats 
> 
> -- 
> Dan York, CISSP
> Dir of IP Technology, Office of the CTO
> Mitel Corp.     http://www.mitel.com
> dan_york <at> mitel.com +1-613-592-2122
> PGP key (F7E3C3B4) available for 
> secure communication
> 
> 
> 
> 
> 
> 	Cullen Jennings <fluffy <at> cisco.com> 
> Sent by: owner-ietf-rtpsec <at> mail.imc.org 
> 
> 02/04/2007 11:36 AM         
>         To:        Dan Wing <dwing <at> cisco.com> 
>         cc:        <ietf-rtpsec <at> imc.org> 
>         Subject:        Re: FIPS-140 required?
> 
> 
> 
> 
> 
> On Jan 26, 2007, at 2:54 PM, Dan Wing wrote:
> 
> >
> > Is anyone seeing a requirement for FIPS-140 for products that  
> > implement
> > SRTP?
> 
> 
> Yes
> 
> (with my guy who works at cisco hat:-)
> 
> 
> 
> 

Michael Richardson | 6 Feb 2007 15:14
Picon

Re: RTPSec BOF proposal for IETF 68


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Dan" == Dan Wing <dwing <at> cisco.com> writes:
    Lakshminath> Next, do we have a consensus set of evaluation criteria
    Lakshminath> now to weigh the solution drafts against?  It would be
    Lakshminath> good to publish that soon in some form (probably as an
    Lakshminath> update to Dan and Francois's draft?)

    mcr> I didn't think we had reached that point yet.

    Dan> Please elaborate.

  I didn't think that we got to the point of having evaluation criteria.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRciNRoCLcPvd0N1lAQLOigf6Amzc7ta7u552gsSx0uGkwIbxgkrSPYhu
1AoCyaQ1nBN7Cym3J5i62fEHwFVa2wbbNpwlmEOu9/kPTFHhlUyCDULXd/KbMKt0
EqxjQr8RAHY/oRFrolMyz6M7OnsIq2xQdgh8Xc07uKmHFQbEpXfmtj3GS4Nn03la
e6Um/kDtX/zwdiXGFXmF4FaJ6tjGrx2Mb3G2cHT4gj063G0ULw9rO30c5nRhBig7
yCI3Lj3UzLuHk1Zi0FOmNttuKN+Ze8RKXjuqlscnJ6r4tGP2+S9L7aETKD4k1unS
pWTFNNoEEfC6akPRD0j/Xg/YryQQ03V+SR9vLghh09m67uhu6HGJoQ==
=LBi5
-----END PGP SIGNATURE-----


Gmane