Re: [sipcore] SASL Authentication for SIP

["Olle E. Johansson" <[e-mail]>]

> On 19 Oct 2022, at 10:29, Rick van Rein <[e-mail]> wrote:
> 
> Hello,
> 
> I cannot really work out what the formal arrangements are
> for new authentication mechanisms in SIP.  IANA lists a
> Security Mechanism Names registry, but it is dedicated to
> RFC 3329, a meta-protocol for negotiating what would be
> available between peers.
> 
> RFC 3261 is a bit informal when it says
> 
>   SIP provides a stateless, challenge-based mechanism for
>   authentication that is based on authentication in HTTP.

There are a few different auth mechanisms. TLS which is not very well
documented, HTTP digest and token bearers (RFC 8898). The last
one is the newest kid on the block. There’s also a mechanism that is
used for setting up an IPsec VPN after initial registration that could 
inspire you. I think it’s called AKA and is used in IMS - but it starts with
http digest.

For inter-domain trust there’s been a few attempts, SIP identity was one
that is now replaced by the work in stir/shaken that focus a lot on
old-fashioned telephone numbers and the problems related with that.

> 
> Does that mean that any mechanism defined for HTTP will
> automatically be permissible in SIP if peers agreed on
> it?  Lacking a formal registry that is what I would
> assume.
There’s no SIP police. At least I can’t say if there is one or not. ;-)
SIP is very permissive in what you can add in headers.
As long as you don’t request support for an extension, the
receiver may ignore your headers. But if you want other implementers
to pick up your work, you want to convince us to work with you
and get an RFC published. The outcome may be different 
from your original idea, but that is quite often a good thing.
> 
> Then, a specification like SIP-SASL that adds specifics
> for SIP could be an Independent proposal.
You start with the solution. I may have missed it, but I don’t
see a definition of the problem you are trying to solve.
> 
> 
> FWIW, the purpose of this work is to have an end-to-end
> mechanism for key derivation.  This can be useful for
> private telephony, but my purpose for now is the setup
> of Wireguard sessions using SIP.  The two seem to be a
> match made in heaven.  Key derivation can yield a PSK
> that helps the VPN combat quantum computing.


I need to read your document in more detail to understand,
but reading this, I don’t see how SASL is the solution to
what you describe here.

Do you want to use SIP offer/answer to set up a 
peer 2 peer VPN using wireguard? Like we currently
use it to set up RTP streams between user agents?

/O