[VOIPSEC] Anyone aware of public disclosures of security incidents rela

[Bggdg at aol.com]

In a message dated 12/29/2009 8:13:48 A.M. Central Standard Time,  
oej at edvina.net writes:


29  dec 2009 kl. 15.04 skrev bggdg at aol.com:

> I wonder what makes the  notion of "someone else" assuring the identity 
of a 
> SIP user less  than a complete solution? While SIP Identity presumably 
> could   allow for self-signed credentials, much as is the case with 
https, this  
> seems a  far more problematic approach than relying upon a  trusted 
neutral  
> third-party.
That's a long discussion you're  heading into. A "trusted neutral 
third-party" sounds very simple, but is not a  simple concept.

> Moreover, one of the benefits of the SIP Identity  reliance on a third 
party 
> validation would seem to be that SIP  Identity does not reveal the  
signing 
> key to relying parties.  Even the neutral third party does not need to  
know 
> the signing  key in SIP Identity. This would seem to offer a far more 
secure 
>  manner of authentication, while simultaneously allowing the user the   
> convenience of employing a single credential for multiple   
services/applications.
I must be missing something. How does SIP  Identity allow the end user this 
convenience?
 
As the SIP Identity RFC states, SIP authentication is particularly  
challenging in an interdomain context. I assume this refers  too current 
authentication schemes working well inside a silo, but once  outside the silo, network 
independent services/applications require the  inconvenience of individual 
passwords for each relying party. However, if I  understand the intent of 
SIP Identity, users could instead  re-use their signing credential and 
validating certificate  for many services/applications, allowing multiple disparate 
relying  parties to validate these signatures through published  
certificates



/O
> 
> Am I missing something?
> 
>  Warren
> 
> 
> In a message dated 12/28/2009 6:11:19 A.M.  Central Standard Time,  
> voipsec-request at voipsa.org  writes:
> 
> Send  Voipsec mailing list submissions  to
> voipsec at voipsa.org
> 
> To subscribe or unsubscribe via  the World Wide Web,  visit
>  http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> or, via email,  send a  message with subject or body 'help' to
>  voipsec-request at voipsa.org
> 
> You can reach the person managing  the list  at
> voipsec-owner at voipsa.org
> 
> When  replying, please edit  your Subject line so it is more specific
>  than "Re: Contents of Voipsec  digest..."
> 
> 
>  Today's Topics:
> 
> 1. Re: Anyone aware  of public  disclosures of security    incidents
> related to SIP trunks?  (Olle E.  Johansson)
> 
> 
>  ----------------------------------------------------------------------
>  
> Message:  1
> Date: Sun, 27 Dec 2009 14:31:08  +0100
> From: "Olle E. Johansson"  <oej at edvina.net>
>  To: Victor Pascual Avila  <victor.pascual.avila at gmail.com>
>  Cc: voipsec at voipsa.org
> Subject:  Re: [VOIPSEC] Anyone aware of  public disclosures of security
> incidents related to SIP  trunks?
> Message-ID:   <E1A71B08-FAE3-4644-889A-A3EBCD737209 at edvina.net>
>  Content-Type:  text/plain; charset=us-ascii
> 
> 
> 24  dec 2009 kl. 09.36 skrev Victor  Pascual Avila:
> 
>>  Hi,
>> 
>> On Thu, Dec 24, 2009 at 1:18  AM, ed guy  <edguy at emcsw.com> wrote:
>>> -----BEGIN PGP SIGNED   MESSAGE-----
>>> Hash: SHA1
>>> 
>>> On  12/22/09 6:09  AM, J. Oquendo wrote:
>>>>  
>>>>> DY> Right.   An attacker could  potentially spoof the IP and trigger
>>>> many  SIP  INVITES, but would not be able to receive the return   
traffic
>>>> and launch the actual call.
>>>>  
>>> Dan,
>>> 
>>> This threat is one of  the reasons  why sip identity (rfc 4474) is
>>> available for  asterisk
>>> and openser/kamilio.   With the right  configuration, it allows you  set
>>> control  access
>>> without significantly impacting  Post Dial  Delay.   e.g., after the
>>> identity is   authenticated,
>>> one can make admittance decisions based on  the  identity or signer.
>> 
>> For the sake of  completeness:
>> 
>  
http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03#section-3.5
>>  
>> "The reason SIP Identity does not work in common situations  is  that
>> B2BUAs, and in particular Session Border Controllers  (SBCs),  have
>> reasons to change some parts of the signed  information when  forwarding
>> a SIP request, thus breaking the  signature."
>> 
> Absolutely an issue.
> 
> Also,  SIP identity is based on "someone else"  assuring the identity of 
a  
> SIP user. While this may work in some situations,  is far from a  
complete  
> solution.
> 
> /O
> 
>  
> ------------------------------
> 
>  _______________________________________________
> Voipsec   mailing  list
> Voipsec at voipsa.org
>  http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
>  
> End  of Voipsec Digest, Vol 60, Issue  6
>  **************************************
> 
>  _______________________________________________
> Voipsec mailing  list
> Voipsec at voipsa.org
>  http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

---
* Olle E  Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96  40 20, Sweden