Re: [dispatch] BEHAVE for B2BUAs charter proposal

[Wilhelm Wimmreuter <[e-mail]>]

On 17.10.2011, at 22:31, Paul Kyzivat wrote:

> On 10/17/11 4:03 PM, Wilhelm Wimmreuter wrote:
>> Think it shall be RFC4474
>> 
>> Agree, it is underspecified and in parts to some extents way overloaded.
>> - Signs elements that will be modified by SBCs
>> - Signs things that have only marginally to do with the originators identity
>> - does nit clearly distinguish between the originators domain and a phone number
>> - ...
>> 
>> However it seems to be quite difficult and likely becomes even more complex if we add things like federations and cross PKI certificate acceptance.
>> 
>> My guess is that we to take a lot of usability issues in to consideration if we want to make it really useful. e.g. initial enrollment and certificate renewal.
>> 
>> Besides usability, one shall think about reducing the functionality to sign the originating identity and domain only. This still would allow to protect the sip message by other means. This approach has the advantage of separating transport security and the originating identity. With this clear separation, authentication would become transparent to SBCs and other servers in the setup path. With that, any element in the call path can validate the caller ID and decide on further authorization. This would also be relevant for the recently signed CALLER-ID Act.
> 
> IIUC you are in essence suggesting signing a blank sheet of paper and then sending it. The recipient will know that the sheet was blank when signed, and gets to decide whether to believe other stuff on the received sheet.

Not really a blank shet of paper ;-). Just the identity of the originator but not the parts of the message that can be changed on link by link. Other elements shall be protected link by link if necessary. As such the digest will be reduced to a minimum and can be forwarded transparently throughout the chain.


> 
> When you say "protecting the message by other means", presumably you mean transitive trust, since a lot of what matters in the message is changed by the B2BUAs. The point of 4474 was to get beyond transitive trust.

Guess transitive is the best way since all other stuff can only be protected on a link by link base. Did we not have the same problem with IPsec as well?

On top of this, I believe that the final solution must be a user centric authentication anyhow and with that we can only accept a digest with information that will not be modified throughout the communication path. e.g. originating id, terminating id and possibly the timestamp. 

Thanks

Willi

> 
> 	Thanks,
> 	Paul
> 
>> Willi
>> 
>> 
>> On 17.10.2011, at 17:16, Olle E. Johansson wrote:
>> 
>>> 
>>> 14 okt 2011 kl. 22:24 skrev Hadriel Kaplan:
>>> 
>>>> Howdy,
>>>> a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusion of the discussion, but it appears there was not enough interest at the time, or perhaps not enough concrete work to do and people to do it.  Since that time, we've had several I-Ds which could arguably fit in such a WG, or at least benefit from one, if it applied to B2BUAs in general.
>>>> 
>>>> This email is to see if there's interest now, but with a slightly different tack: a concrete WG charter proposal, as described below.
>>>> 
>>>> Interest/comments/flames welcomed.
>>> I think it's high time to start this work. We have seen the need for it in the discussions around Asterisk
>>> for a very long time. One could easily add SIP Identity for User Agents to this list, as RFC 4744 is
>>> horribly underspecified in this regard...
>>> 
>>> /O
>>>> 
>>>> 
>>>> Description of STRAW Working Group
>>>> ====================================
>>>> Name: Sip Traversal Required for Applications to Work (STRAW)
>>>> 
>>>> Problem Statement:
>>>> Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between.
>>>> 
>>>> In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.
>>>> 
>>>> It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.
>>>> 
>>>> The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>>>> 
>>>> For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.
>>>> 
>>>> Objectives:
>>>> The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.
>>>> 
>>>> Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.
>>>> 
>>>> The intention of this WG is to document such requirements in separate documents, per SIP or media function, instead of as one document for all functions.  That will both reduce the time to publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply criteria.
>>>> 
>>>> 
>>>> Initial Deliverables:
>>>> 1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.
>>>> 2) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
>>>> 3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
>>>> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
>>>> 5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end.
>>>> 
>>>> [also add a taxonomy document?]
>>>> 
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>> 
>>> ---
>>> * Olle E Johansson - [e-mail]
>>> * Cell phone [phone], Office [phone], Sweden
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch