Subject: [stir] Policy/Architecture versus Protocol

From: Eric Burger <[email-masked]>
Date: Sun, 19 Jul 2015 20:38:51 -0400

We (the IETF) are good at protocols. We are not quite as good at architectures. We suck at policy.

High-level:
===========
A major weakness of the current 4474bis-04 draft is rather than focus on the protocol extension, it has a lot of focus on the architecture. Moreover, sometimes it makes policy suggestions, other times it makes policy decisions.

This draft could be made much clearer by taking out the architecture and policy stuff and moving that to a different document. I would offer that fits into the current charter, because the charter wisely says "Submit in-band mechanism for Proposed Standard,” not “update 4474.”  Yes, I will volunteer to put together that document.

Details:
========
The draft speaks of an authentication service and a validation service. It then goes on to specify an architecture, where the authentication service is literally a service, most likely in or near an outbound proxy or B2BUA (explicit in the draft) and the validation service is literally a service, most likely in a P-CSCF or SBC (not by name in the draft, but certainly by implication).

It would be much cleaner if the draft focused on the behavior of the SIP UAC that implements an authentication function and a SIP UAS that implements a validation function. We (the IETF) are good at that. That means we can take out all of the confusing language about unenforceable and outside the scope of the IETF restrictions on the authentication function. For example, show me where in SIP one can enforce that an intermediary MUST authenticate SIP users (Section 4.1)?

We manage to leave the interaction of an IP PBX to a phone alone. For example, we do not specify that an IP PBX *MUST* be a SIP Proxy that can only help a SIP phone route calls. It might be that, it might be a SIP B2BUA, or, for that matter, the protocol between the phone and the IP PBX could be Skinny (SCCP) ;-)

Likewise, we should leave the interaction between an outbound proxy that happens to do the authentication *function* and the phone as a local matter. Yes, we can help implementors, which would be the different document I mentioned above.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Jul 2015 08:26:32 +0000

Perhaps unsurprisingly, I don't see the need to break this draft into separate protocol and policy documents - largely because I don't think there's much by way of policy lurking in the pages of rfc4474bis. 

The term "authentication service" follows the RFC3261 usage of "location service" as a logical function that might be instantiated by either an endpoint or an intermediary. There is considerable text in rfc4474bis (almost all of it retained from RFC4474) that explains how an authentication service can be an endpoint, for example. 

And the notion that an authentication service MUST authenticate the entity whose identity it is attesting seems to me not so much a statement of policy as a tautology. It is by definition what the service does. The text in 4.1 makes it very clear that it is entirely a matter of local policy how an authentication service authenticates users, and even gives an example of an endpoint considering a user authenticated simply by virtue to having access to the endpoint device. A reading of that sentence in 4.1 as requiring that an intermediary MUST challenge a SIP request with a 407 or something would I think be quickly clarified by glancing at any of the surrounding text. It would indeed be unhelpful and unenforceable, so I'm glad the spec doesn't say that. 

Taking a step back, I do think there could be some benefit in a document that talks about authorization policy and practices - especially when and if we have some operational experience with these mechanisms. But rfc4474 has been careful not stray into those questions. 

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Jul 20, 2015, at 2:39 AM, Eric Burger <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir