Subject: [MSEC] RE: Another MIKEY Question

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Fri, 6 Feb 2004 16:08:00 +0100

Hi,
as SRTP specifies, that information needs to be conveyed 
to RTP. How this is done is an implementation issue, which 
of course may require changes to existing APIs (depending 
on which RTP implementation you use). 

cheers
/E

> -----Original Message-----
> From: Steffen Fries [mailto:[email-masked]]
> Sent: den 5 februari 2004 14:03
> To: Elisabetta Carrara (KI/EAB)
> Cc: [email-masked]
> Subject: RE: Another MIKEY Question
> 
> 
> Hi Elisabetta,
> 
> hm, okay, I did not though on a multicast case.
> 
> Just for my curiousity, how do you get the SSRC in your 
> implementation for the RTP connection? Using the common RTP 
> stacks, there is no option to get the SSRC before actually 
> opening an RTP channel nor is there an interface to set the 
> SSRC from outside. Did you adapt the RTP stack to do this?
> 
> Regards
> 	Steffen
> 
> From:           	"Elisabetta Carrara (KI/EAB)" 
> <[email-masked]>
> To:             	"[email-masked]'" 
> <[email-masked]>
> Copies to:      	[email-masked]
> Subject:        	RE: Another MIKEY Question
> Date sent:      	Thu, 5 Feb 2004 13:36:50 +0100 
> 
> > 
> > Hi Steffen,
> > the RTP spec says that participants in an RTP session 
> > may share the same destination transport address, but 
> > they would use the (unique) SSRC to demultiplex. 
> > In particular, the SSRC is needed in sessions with more 
> > than one participant/data source/listener. Each listener 
> > and data source uses its own SSRC, and the SA may be 
> > different for each.
> > 
> > Cheers
> > /Elisabetta
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Steffen Fries [mailto:[email-masked]]
> > > Sent: den 4 februari 2004 11:02
> > > To: Elisabetta Carrara (KI/EAB)
> > > Cc: [email-masked]
> > > Subject: Another MIKEY Question
> > > 
> > > 
> > > Hi Elisabetta,
> > > 
> > > I've got another question, just for clarification. In section 
> > > 4.4 of the MIKEY draft the following is stated:
> > > "However, the SSRC is not sufficient. For the retrieval 
> of the Data
> > > SA from MIKEY, it is RECOMMENDED that the MIKEY implementation
> > > support a lookup using destination network   address and port
> > > together with SSRC."
> > > 
> > > What would be a scenario, where the network address and the 
> > > port is not suffcient and the SSRC is actually needed?
> > > 
> > > Regards
> > > 	Steffen
> > > 
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Thu, 12 Feb 2004 16:52:18 +0100

Hi Steffen, 
we haven't seen the need for that, mainly because ASFAWK it 
is discouraged to use the same key pair for both v1.5 and OAEP, 
therefore both options together should hopefully not appear. 
If they do, we would assume that the mandatory and default 
one is used (i.e. v1.5). 

Cheers
/Elisabetta

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Steffen Fries
> Sent: den 12 februari 2004 11:43
> Subject: RE: [MSEC] RE: Another MIKEY Question
> 
> 
> Hi Elisabetta,
> 
> thanks for the response. I'm not quit sure if this answers the 
> question completely. Within PKCS#1 there is a list of possible 
> supported encryption mechanisms. This is not a choice. This 
> means, if a peer supports both methods, how does the remote 
> peer know which to chose?
> 
> In contrast, the certificate also describes several possible 
> algorithms for signatures, which is also not a choice. But 
> here, MIKEY signals the chosen signature algorithm as part of 
> the Signature payload (SIGN) in the S type. 
> 
> Regards
> 	Steffen
> 
> Subject:        	RE: [MSEC] RE: Another MIKEY Question
> Date sent:      	Mon, 9 Feb 2004 14:39:02 +0100
> 
> > Hi Steffen, 
> > the information is signaled in the certificate. 
> > Check for ex. appendix A of
> > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
> > 
> > cheers
> > /E
> > 
> > 
> > 
> > > Sent: den 9 februari 2004 10:44
> > > Subject: Re: [MSEC] RE: Another MIKEY Question
> > > 
> > > 
> > > Hi Elisabetta,
> > > 
> > > hope I don't bother you ... here is yet another question.
> > > 
> > > In the 08 version of MIKEY, it is recommended in section 4.2.5 to
> > > support also RSA OAEP. How is this signaled in the Envelope Key
> > > payload (section 6.3)? Is there a new payload header to 
> be defined.
> > > Tight to this would be an error message signaling an error, that a
> > > dedicated key encryption method is not supported.
> > > 
> > > Regards
> > > 	Steffen
> > > 
> > 
> > This communication is confidential and intended solely for the
> > addressee(s). Any unauthorized review, use, disclosure or 
> distribution
> > is prohibited. If you believe this message has been sent to you in
> > error, please notify the sender by replying to this transmission and
> > delete the message without disclosing it. Thank you.
> > 
> > E-mail including attachments is susceptible to data corruption,
> > interruption, unauthorized amendment, tampering and viruses, and we
> > only send and receive e-mails on the basis that we are not 
> liable for
> > any such corruption, interception, amendment, tampering or 
> viruses or
> > any consequences thereof.
> > 
> >