Subject: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09

From: Dean Willis <[email-masked]>
Date: Tue, 23 Aug 2011 16:05:34 -0500

The spprov draft uses Organization as a sort of owner-and-association ID for registry objects. Current text defines it thusly:

   o  Organization:
      An Organization is an entity that may fulfill the role of a
      registrant or a peering organization.  All SPPP objects are
      associated with an organization identifier to identify each
      object's registrant, while tracking the identity of the registrar
      that provisioned each SPPP object is left as a matter of policy
      for an SPPP implementation.  A Route Group object is also
      associated with a set of zero or more organization identifiers
      that identify the peering organization(s) whose resolution query
      responses may include the routing information (SED) defined in the
      Route Records within that Route Group.  A peering organization is
      an entity that the registrant intends to share the SED data with.
      A route group SPPP object is associated with a set of zero or more
      organization identifiers that identify the peering organizations
      whose resolution query responses may include the routing
      information (SED) defined in the route records within that route
      group.

So, Organization is a very important thing.  It controls 1) who "owns" an object, possibly for the purpose (it's not clear to me) of controlling write access to that object. Some objects contain a list of Organizations with read access to the object.  It's also used in controlling offer-and-acceptance in peering operations. So, sometimes "Organization" also controls read access to an object.

Would using Organization as an authentication ID (or auth-ID key) and subsequently using the requester's authenticated Organization as a data access mask be okay? Or do we need to have another table that relates user-IDs and organizations for access control purposes, on the assumption that some organizations have multiple authenticated users and that some authenticated users have access to multiple Organizations?

Furthermore, the protocol defines no mechanism of adding, querying. or changing Organizations. Such operations are outside of the  scope of the protocol. For the OpenSPP project work, we've just manually shoved test records into an Organization table. I've "broken" my test environment a dozen times by dropping the database, reinitializing the schema, and then forgetting to manually insert the Organization records needed to run our test cases. If those test cases started with a bunch of "AddOrganization" use cases, I probably wouldn't forget.

Point 1: A more concise explanation of the utility of Organization in both authentication and authorization is required. This doesn't need to be overly complex: A brief discourse on the relationship between "authenticated user" and Organization at the top level and the addition of  an "Authorization" discussion in each access method would suffice.

Point 2: Given that the protocol does not include manipulation of Organization, it's impossible to actually initialize a registry using the protocol functions.  Something external has to initialize the Organization records. Is this how we want it to be? If yes, then we need to document this in the protocol specifications (probably 1 added paragraph). If no, then we need to add some protocol primitives to address it (GetOrg, UpdateOrg, DelOrg)

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 24 Aug 2011 09:43:24 -0400

Point 1:  Maybe.  On the other hand it is not the purpose of the spec to describe how to implement a protocol server.  Imo, this discussion would get into that realm.
Point 2:  As we've discussed the creation of organizations happens outside the protocol.  The job of setting up organization identifiers and their associated authentication credentials and their authorization roles is not the purpose of this protocol, not should it be.

Ken
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dean Willis [[email-masked]]
Sent: Tuesday, August 23, 2011 5:05 PM
To: [email-masked]
Subject: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09

   o  Organization:

--
Dean

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 08:45:22 -0500

On 8/24/11 8:43 AM, Cartwright, Ken wrote:
> Point 1:  Maybe.  On the other hand it is not the purpose of the spec
> to describe how to implement a protocol server.  Imo, this discussion
> would get into that realm.

Many at the IETF feel that the purpose of an IETF protocol specification
is to allow for multiple interoperable implementations of a protocol. I
suspect that without making the relationships between Owner and other 
things clear, we won't get interoperability.

> Point 2:  As we've discussed the creation of organizations happens
> outside the protocol.  The job of setting up organization
> identifiers and their associated authentication credentials and
> their authorization roles is not the purpose of this protocol, not
> should it be.

 From the Abstract:

    This document describes the Session Peering Provisioning Protocol
    used by clients to provision registries.

We can't use the protocol to provision a registry without (somehow) 
provisioning Owner objects. As defined, the protocol doesn't manipulate 
Owner objects. Given this constraint, does the protocol meet the goals
laid out in the Abstract? Perhaps this could be addressed in the 
protocol specification by declaring Owner "out of scope" and stating 
that some other protocol is required for manipulating Owner?

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 25 Aug 2011 12:19:57 -0400

See comments in line.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, August 25, 2011 9:45 AM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09

KJC:  Sorry, but I do not know what you mean by "making the relationships between Owner and other things clear".  Each object already contains the registrantID of the "owner".  What do you mean by "things"?

 From the Abstract:

KJC:  Your use of the term "Owner object" is not clear to me.  Are you just talking about the Registrant (technically speaking it is the "Registrant" that owns each object)?  If that is the case then, you are correct that the protocol does not provide the ability to create new Registrant IDs.  Managing registrant organizations and registrar organizations with their authentication credentials was not in scope for this protocol.  I guess we can certainly add in a statement stating that the protocol does _not_ have that feature.  However, it is not necessarily true that "some other protocol is required for that purpose".  Most registries that work at an organizational level have something like an administration portal that is used to create new organizations, rather than a standardized protocol.  This is because (1) allowing a protocol client to create _itself_ does not make sense, and (2) there are contractual and legal activities involved in setting up organizational relationships (that result in authorization privileges) between registrars and registrants.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 14:28:36 -0500

On 8/25/11 11:19 AM, Cartwright, Ken wrote:

>
> KJC:  Sorry, but I do not know what you mean by "making the
> relationships between Owner and other things clear".  Each object
> already contains the registrantID of the "owner".  What do you mean
> by "things"?

OpenSPP maps the SPPP schema to SQL. In doing so, we ended up with 
another table called "Organization". This is supported in or 
DataAccessObjects layer by another Java class, "OrganizationDAO.java"

The Organizaton schema is:

CREATE  TABLE IF NOT EXISTS `openspp`.`Organization` (
   `OrgId` INT NOT NULL AUTO_INCREMENT ,
   `OrgName` VARCHAR(255) NOT NULL ,
   `Cdate` DATETIME NULL ,
   `MDate` DATETIME NULL ,
   PRIMARY KEY (`OrgId`) ,
   UNIQUE INDEX `UK_Organization_OrgName` (`OrgName` ASC) )
ENGINE = InnoDB;

In the WSD, the protocol defines an OrgIdType as a simple unbounded 
string (in practice, this needs validation constraints).

Registrant, as encoded in the "rant" member of "objKey" and 
"BasicObjType" is related to Organization.

In practice, the "rant" member of objKey relates to the Organization 
table, in that values of "rant" in objKey and "BasicObjType" MUST appear 
as "OrgName" columns in rows of the Organization table.

I think that "Registrant" as you use the term isa "Organization" as 
defined in the OpenSPP database schema. Are there other sorts of 
"Organization" needed? Maybe, maybe not, depending on the AAA model, and 
on whether an implementation needs other "owned" objects that are not 
owned by Registrants. More below ...

 > KJC:  Your use of the term "Owner object" is not clear to me.  Are
 > you just talking about the Registrant (technically speaking it is the
 > "Registrant" that owns each object)?

Is the authoritative owner actually the "Registrant" (aka 
"Organization")? Or is it the "Registrar" (currently undefined in our 
schema) who interfaces with our database (the Registry) on behalf of the 
Registrant?

Assume a mapping of authentication identities (Auth_ID for short, and 
currently undefined in our schemae). In a minimal model, each Auth-ID 
has a name (username) and authentication credentials (password, cert, 
private key, whatever).

Is there a one-to-one mapping between Auth_ID and Registrant? I'd argue 
strongly "no".

Analysis of Auth_ID per Registrant
----------------------------------

Registrant "Alice" registers some routes with registrar "Reg1" and some 
with "Reg2". We add an Organization/Registrant table entry with an 
OrgId/RantID of "Alice".

If we issue a single Auth_ID for Alice, both Reg1 and Reg2 get a copy of 
the credentials. Either can then access or delete routes registered by 
Alice with their competitor. Is this acceptable

Alternate: One Auth_ID per Registrar-Registrant Relationship:
-------------------------------------------------------------

One alternative is to issue two Auth_ID, one for Reg1 and another for 
Reg2. Both have the name "Alice", but they have different credentials. 
So when Alice registers a route with Reg1, Reg1 uses its Auth_ID to put 
the route in the registry, and the route record has a RantId of "Alice". 
But now when Reg2 queries for all of Alice's routes (assuming we lack 
something else to indicate which of Alice's routes Reg2 can see or 
edit), Reg2 will see the route added via Reg1. Reg2 can even retract the 
route or alter it to point through another path more favorable to Reg2. 
Is this acceptable? Would it be better to consider the Registrar as the 
"owner" of the record? Of course, that raises other questions:

Alternate: One Auth_ID per Registar-Registrant Relationship plus one per 
Registrant:
--------------------------------------------------------------------

Alice might want to check the routes registered for her by Reg1 and 
Reg2. Alice now needs yet another Auth_ID. This doesn't have the same 
cross-visibility problems as do the Auth_IDs for Reg1 and Reg2, but it 
gets interesting in that there are now three different passwords per 
username Alice, and we don't know which record was created by whom. 
Alice queries her route records, but cannot by examination tell which 
were inserted by Reg1 and which wee inserted by Reg2.

Related case: The registry operator might want to audit routes. Assume 
Alice calls up the registry and says "Check on what these guys are doing 
to me." They fire up an admin console with the intent of using SPPP to 
query the registry. They now either need Alice's, Reg1, or Reg2's 
Auth-ID for Alice. Or they need a fourth Auth_ID -- and another such for 
every additional registrant. It would be a lot better to have the 
registry operator only need one Auth-ID with administrative rights, no? 
The same probably applies to the registrars.

What if we added a new Auth_ID table?
-------------------------------------

We could add Yet Another Table (or object, depending on your worldview). 
Call it for now the Auth_ID table. Minimally each Auth_ID has columns 
for name, credential, cDate, mDate, and the other usual things (expiry?).

How do we relate Auth_ID to other things in our database? Otherwise 
said, what can a given Auth_ID read or write in the database?

A simple approach might be to build yet another table that relates 
Auth_ID to Registrant (or Organization, the in the OpenSPP schema). The 
first column might be the Auth_ID, the second the RantId (or OrgId), and 
the third the capability flag , like "read", "write", or "both".

This makes it easy to determine which records a requester can access: We 
use the Auth-ID to authenticate, then select records from the database 
which 1) match the request parameters, and 2) have an OrgId for which 
the Auth_ID has the appropriate access rights.

BUT: Remember the use case where registrant Alice sends some route 
records through registrar Reg1 and some through Reg2 and we don't want 
Reg1 messing with Reg2's records? We don't have enough information in 
the database to know which records came from Reg1 and which came from 
Reg2. And our auth model gave both Reg1 and Reg2 access to all of 
Alice's records.

What if we Add the Registrar's Name to Each Record?
---------------------------------------------------

We could add a RegistrarId to each BasicObjType and to objKey. This 
gives us the information to make decisions about whether Reg1 can see 
all of Alice's routes, or just those routes that Alice published through 
Reg1.

To do this, we need a place to store RegistrarIDs. We could add yet 
another table. And another for AdministratorIDs, and every other sort of 
owner-ID we may come up with.

Or we could simply say that both Registrant and Registrar are 
Organizations. Registry operators themselves (and their admin support) 
are also probably Organizations. This lets us use the Organization 
tables (as defined in OpenSPP) to store them all. So, RantId isa OrgId, 
RegisId isa OrgId, and so on.

We Still Need to Deal With Roles and Rights
-------------------------------------------

With the above changes, we can by examination tell who the Registrant 
and Registrar are for each object. We can also identify the actor making 
a request.

What we don't know is whether or not the actor making a request should 
be allowed to do it.

This is a complex topic, and since the protocol doesn't care (it just 
needs to know "who" and reply "yes/no" in response), it really CAN be 
left to the implementation. For the sake of discussion, I hereby propose 
an example solution that might work for a reference implementation such 
as OpenSPP.

First, we need to add an "administrator" flag to the Auth-ID table. 
Organizations flagged with this are by definition administrators.

Second, we need a way to authorize registrars to act on behalf of 
registrants. The easiest approach is to add a new table "rant-regis" 
relating rant to regis; a row containing a binding of rant and regis 
says that that the indicated registrar can act on behalf of the 
registrant except when in conflict with another registrar.

1) If the Auth_ID of a request is an Administrator, the request is 
authorized.

2) If the Auth_ID of a request affecting an existing object is the same 
as the "rant" of that object the request is authorized.

3) If the Auth_ID of a request affecting an existing object is the same 
as the "regis" of that object the request is authorized.

4) If the Auth_ID of a request creating a new object is an 
Administrator, the request is authorized.

5) If the Auth_ID of a request creating a new object is the same as the 
rant of the new object, the request is authorized.

6) If the Auth_ID of a request creating a new object is the same as the 
regis of the new object, AND the regis is an authorized registrar for 
the registrant specified by the rant in the request (see the rant-regis 
table), the request is authorized.

Proposed PROTOCOL solution:

1) Add the concept of an Authenticated Identity (what I above called an 
Auth_ID) to the protocol. How Auth_IDs are added to the system is 
outside the scope of the protocol. How they are USED, however, is within 
the scope. What we know is that there is an Auth_ID presented for each 
transaction, and this this Auth_ID is used to a) identify the actor 
making the request, b) authenticate that the request is validly from 
that actor, and c) decide, along with other information, whether or not 
that actor is authorized to execute the given request.

2) Understand that roles such as Registrant, Registrar, Administrator, 
are all Organizations, each of which has a a unique name within the 
schema (of OrgIdType).

3) Extend BasicObjType to track the Registrar as well as the Registrant 
of each object:

<complexType abstract="true" name="BasicObjType">
  <sequence>
   <element name="rant" type="spppb:OrgIdType"/>
   <element name="regis" type="spppb:OrgIdType"/>
   <element minOccurs="0" name="cDate" type="dateTime"/>
   <element minOccurs="0" name="mDate" type="dateTime"/>
   <element minOccurs="0" name="extBasicObj" type="spppb:ExtAnyType"/>
  </sequence>
</complexType>

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 25 Aug 2011 16:07:11 -0400

Hi Dean,

1) The spec does not specify how to implement a DB or code that manages credentials or roles, nor should it.  There are multiple internal design approaches/decisions to be made.
2) The internal design of the OpenSPP Organization table you have below looks just fine to me, as a bare bones implementation (which I think is what you are going for).  I guess it holds the list of the registrants that exist in the system.  And since I do not see a "hash" or "passkey" column in that table, there must be another table that holds the "registrars" and their IDs and authentication credential in some form, which is what would be used when evaluating/handling the Digest Authentication sequence required by the spec.
3) There is no password or cert associated with a "registrant".  A registrant never authenticates itself to the SPPP server.  It is the "registrar" that authenticates itself to the SPPP server.
3) As discussed on today's call, we did have the "rarId" (registrar ID) in the protocol.  It was an attribute of each object.  However, as the final change to the protocol we removed it at the request of a couple of the work group participants because they felt it got in the way of the local policies that drive their local implementations of authentication and authorization.  We all agreed to do this because we saw that it is not _strictly_ necessary to have the "rarId" data element exist within the context of the SPPP messages going between the client and the server.  But it _is_ certainly necessary within the internal server side implementation DB to keep the ID of the registrar that created each object.

Ken

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 23:24:19 -0500

On 8/25/11 3:07 PM, Cartwright, Ken wrote:
> Hi Dean,
>
> 1) The spec does not specify how to implement a DB or code that
> manages credentials or roles, nor should it.  There are multiple
> internal design approaches/decisions to be made.

The spec needs to define the actors within the protocol. For example, 
registrars are different actors than registrants. And it needs to talk 
about the range of options for each.

> 2) The internal design of the OpenSPP Organization table you have
> below looks just fine to me, as a bare bones implementation (which I
> think is what you are going for).  I guess it holds the list of the
> registrants that exist in the system.  And since I do not see a
> "hash" or "passkey" column in that table, there must be another table
> that holds the "registrars" and their IDs and authentication
> credential in some form, which is what would be used when
> evaluating/handling the Digest Authentication sequence required by
> the spec.

Gee, until today it hadn't been apparent that the database needed to 
hold registrars. It wasn't in the spec as far as the developers could 
tell. It's not in the schema, and is mentioned only in the protocol docs 
(as far as I can tell) as something that's outside the scope of the 
protocol and left up to "policy".

> 3) There is no password or cert associated with a "registrant".  A
> registrant never authenticates itself to the SPPP server.  It is the
> "registrar" that authenticates itself to the SPPP server.

So there's no mechanism for registrants to access the data in the 
registry and audit it?

Can a registrant have relationships with multiple registrars 
(many-many), or does the protocol lock that down to many-one?

Don't registrants need to access data in the database so they can offer 
and accept routing information to/from each other?

> 3) As discussed on today's call, we did have the "rarId" (registrar
> ID) in the protocol.  It was an attribute of each object.  However,
> as the final change to the protocol we removed it at the request of a
> couple of the work group participants because they felt it got in the
> way of the local policies that drive their local implementations of
> authentication and authorization.  We all agreed to do this because
> we saw that it is not _strictly_ necessary to have the "rarId" data
> element exist within the context of the SPPP messages going between
> the client and the server.  But it _is_ certainly necessary within
> the internal server side implementation DB to keep the ID of the
> registrar that created each object.

If an audit query using SPPP needs to be able to tell us which registrar 
added or updated a given object, then we need rarId.

If we explicitly wish to preclude this function (which seems intuitively 
obvious and needful to somebody like me with an ops background) then we 
probably need to state explicitly that we've left it out of the 
protocol, and give reasons why. Otherwise the ops area people (who are 
admittedly less activist than in Randy Bush's IESG-days) are going to 
give us grief.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 26 Aug 2011 09:29:31 -0400

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, August 26, 2011 12:24 AM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09

KJC:  It does define the actors, that's why you see the definition of registrar and registrant.

KJC:  Then where do you store the authentication credentials?

KJC:  Correct.  The registrant role is not an actor/user of SPPP, only the registrars are.  That what Registrant and registrar mean.

No.  The registrar role does that.  Dean, you need to read and understand the definitions of registrar and registrant.  I did not invent those terms.

KJC:  Audit Query?  You're inventing new requirements.  The protocol is not designed for auditing.  Auditing is a very high volume activity that is best done via other means.  That being said, I am not apposed to adding the rarID back in.  But the folks that wanted it removed would need to agree to adding it back in.

KJC:  Huh?  Auditing is not supported by EPP, or Netconf, or .....

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Aug 2011 14:27:31 -0500

On 8/26/11 8:29 AM, Cartwright, Ken wrote:

>  hold registrars. It wasn't in the spec as far as the developers
> could tell. It's not in the schema, and is mentioned only in the
> protocol docs (as far as I can tell) as something that's outside the
> scope of the protocol and left up to "policy".
>

Don't have any yet. Since how it worked was not obvious from the spec, 
we put that off to a future phase. Consequently, OpenSPP "sprint 2 
demonstrable" does no authentication and no authorization checks. It's 
wide-open, and I'm expecting spammers to figure out how to put porn and 
viagra links in there any day. Perhaps if you'd shown up for the demo 
sessions...

> Don't registrants need to access data in the database so they can
> offer and accept routing information to/from each other?
>
> No.  The registrar role does that.  Dean, you need to read and
> understand the definitions of registrar and registrant.  I did not
> invent those terms.

Okay, maybe the business model isn't clear to me.

As a VoIP provider, why on earth would I allow my registrar to negotiate 
which routes I want to accept from a peer? I need control over the 
routes I'm offering my peers and the routes I'm accepting from them.

>> as the final change to the protocol we removed it at the request of
>> a couple of the work group participants because they felt it got in
>> the way of the local policies that drive their local
>> implementations of authentication and authorization.  We all agreed
>> to do this because we saw that it is not _strictly_ necessary to
>> have the "rarId" data element exist within the context of the SPPP
>> messages going between the client and the server.  But it _is_
>> certainly necessary within the internal server side implementation
>> DB to keep the ID of the registrar that created each object.
>
> If an audit query using SPPP needs to be able to tell us which
> registrar added or updated a given object, then we need rarId.
>

> KJC:  Audit Query?  You're inventing new requirements.  The protocol
> is not designed for auditing.  Auditing is a very high volume
> activity that is best done via other means.  That being said, I am
> not apposed to adding the rarID back in.  But the folks that wanted
> it removed would need to agree to adding it back in.

It all comes down to whether or not a registrant can have relations with
multiple registrars. If not, then we can use a single table mapping
registrant to registrar, and don't need to track registrar in the 
objects. If, however, there is a possibility that a single registrant 
can have records with multiple registrars, then we require a registrar 
ID in the object too.

Even if the case where there is a single registrar per registrant, we 
require a table mapping registrant to registrar to be able to manage 
permissions at the registrar level on objects that are only identified 
in the schema by their registrant.

In other words, if I understand you correctly, we authenticate and 
authorize exclusively based on the registrar's identity. That is, only 
registrars have Auth_ID.

But records in the current database are keyed by registrant, not 
registrar. So there's currently no way to look at a record and decide 
whether a given registrar "owns" that record on behalf of the 
registrant, and consequently we have no way to decide whether the 
registrar should be allowed to modify (or even read) that record.

> If we explicitly wish to preclude this function (which seems
> intuitively obvious and needful to somebody like me with an ops
> background) then we probably need to state explicitly that we've
> left it out of the protocol, and give reasons why. Otherwise the ops
> area people (who are admittedly less activist than in Randy Bush's
> IESG-days) are going to give us grief.
>

Auditing is supported by the ability to query the data and see what is 
there, as well as by the ability to insert new data and observe state 
changes on the output. Clearly this can be done in SPPP, EPP, NetConf, 
whatever. The question is: which actors have the rights to do it, and 
what tools do they do it with?

One doesn't necessarily have to do it. it through the provisioning front 
end. But if not for auditing, why do we have query methods instead of 
just add/update methods?

With EPP I can, for example, do a "dig" on the final result and see 
what's there. I suppose in certain use cases, where the information from 
SPPP is eventually making its way into an ENUM presentation, that one 
could audit from that end. I'm accustomed to thinking of data in private 
ENUM as being unavailable, but I suppose the scenarios you have in mind 
require that the registrant be able to query the ENUM directly.

The problem is that the final ENUM presentation is a rather complex 
calculation of destination groups, route groups, offers, answers, 
acceptances, etc. It could be very hard to debug from the output alone.

It would be a lot easier if, as a registrant. I could just query the 
registry using SPPP (or something similar) and verify the inputs.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 26 Aug 2011 15:38:36 -0400

Responses in-line (KJC2).

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, August 26, 2011 3:28 PM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09

On 8/26/11 8:29 AM, Cartwright, Ken wrote:

Don't have any yet. Since how it worked was not obvious from the spec,
we put that off to a future phase.

KJC2:  Dean that is not at all correct.  The spec explicitly requires Digest Authentication.

Consequently, OpenSPP "sprint 2
demonstrable" does no authentication and no authorization checks. It's
wide-open, and I'm expecting spammers to figure out how to put porn and
viagra links in there any day. Perhaps if you'd shown up for the demo
sessions...

KJC2:  Both use case already widely exist in the industry.  Voip providers sometimes are their own registrars, in which case the same company plays the role of registrar and registrant.  Some other Voip providers sometimes delegate the registrant role to another organization.

what's there.

KJC2:  You can also use dig against an SPPP fed resolution server (or issue a SIP query).

I suppose in certain use cases, where the information from

KJC2:  To see the resolution response from a resolution server that is feed using SPPP the way is to do a dig or an SIP invite.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Aug 2011 18:30:22 -0500

On 8/26/11 2:38 PM, Cartwright, Ken wrote:
> -----Original Message----- From: Dean Willis
> [mailto:[email-masked]] Sent: Friday, August 26, 2011 3:28
> PM To: Cartwright, Ken Cc: [email-masked] Subject: Re: Long Followup
> to Thoughts on "Organization" in draft-ietf-drinks-spprov-09
>
>> Gee, until today it hadn't been apparent that the database needed
>> to hold registrars. It wasn't in the spec as far as the developers
>> protocol docs (as far as I can tell) as something that's outside
>> the scope of the protocol and left up to "policy".
>>
> Don't have any yet. Since how it worked was not obvious from the
> spec, we put that off to a future phase.
>

It might require digest authentication but of what/who and using what
credentials isn't in the spec.  So we deferred that part of the
implementation.

> As a VoIP provider, why on earth would I allow my registrar to
> negotiate which routes I want to accept from a peer? I need control
> over the routes I'm offering my peers and the routes I'm accepting
> from them.
>

> KJC2:  Both use case already widely exist in the industry.  Voip
> providers sometimes are their own registrars, in which case the same
> company plays the role of registrar and registrant.  Some other Voip
> providers sometimes delegate the registrant role to another
> organization.

You mean delegate the registrar role, right?

So registrars are the ones offering routs to each other and accepting 
routes from each other, not registrants? Seems backwards to me.

...

>> left it out of the protocol, and give reasons why. Otherwise the
>> ops area people (who are admittedly less activist than in Randy
>> Bush's IESG-days) are going to give us grief.
>>
> Auditing is supported by the ability to query the data and see what
> is there, as well as by the ability to insert new data and observe
> state changes on the output. Clearly this can be done in SPPP, EPP,
> NetConf, whatever. The question is: which actors have the rights to
> do it, and what tools do they do it with?
>
> One doesn't necessarily have to do it. it through the provisioning
> front end. But if not for auditing, why do we have query methods
> instead of just add/update methods?
>
> I suppose in certain use cases, where the information from SPPP is
> eventually making its way into an ENUM presentation, that one could
> audit from that end. I'm accustomed to thinking of data in private
> ENUM as being unavailable, but I suppose the scenarios you have in
> mind require that the registrant be able to query the ENUM directly.
>
> KJC2:  To see the resolution response from a resolution server that
> is feed using SPPP the way is to do a dig or an SIP invite.

A SIP INVITE doesn't normally return a database lookup. It doesn't tell 
me what routes I've offered to people, what routes I've been offered, or 
how my destinations are grouped up. In the "normal" case, it returns 
some SDP for setting up a media flow.

Likewise, the expressive range of a "dig" lookup is much less than the 
expressive range of an SPPP request.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 29 Aug 2011 09:23:04 -0400

In-line KJC3.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, August 26, 2011 7:30 PM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09

KJC3:  (1) Not sure I agree with that.  The spec says that the clients of the SPPP/SOAP/HTTPS must use digest authentication. (2) The IETF RFCs that I've read do not go to the extent of explaining how implementers of a protocol that must use digest authentication will do Digest Authentication.  But if there is some specific statement you would like me to add I will do so.

KJC3:  Yes

KJC3:  As has been explained, registrars take action on behalf of the registrants.  Not backwards at all.

...

> is feed using SPPP the way is to do a dig or an SIP invite.

A SIP INVITE doesn't normally return a database lookup.

KJC3:  That's simply incorrect.  The SIP response is built from a lookup into a DB, be it in memory on on disk.

It doesn't tell

KJC3:  There are several detailed use case around how SIP response are constructed from an underlying set of data, and what the resulting SIP response might be.  You brought up using dig if te protocol id ENUM, so I offered up the additional use of SIP.  ENUM and SIP are analogous here.  Neither of these protocols will tell you all of the data that was _evaluated_ when arriving at the final ENUM or SIP response.

KJC3:  OF course.  You brought up dig, not me.

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Aug 2011 18:21:28 -0500

On 8/29/11 8:23 AM, Cartwright, Ken wrote:

> KJC3:  (1) Not sure I agree with that.  The spec says that the
> clients of the SPPP/SOAP/HTTPS must use digest authentication. (2)
> The IETF RFCs that I've read do not go to the extent of explaining
> how implementers of a protocol that must use digest authentication
> will do Digest Authentication.  But if there is some specific
> statement you would like me to add I will do so.

A counterexample: RFC 3261 has a modest discussion of how it uses digest 
authentication.

EPP, RFC 4930, also discusses how the login" command is used to 
establish authenticated identity.

Some discussion of "how it works" with SPPP might be useful. Oddly 
enough, EPP transports the authentication identity in the payload, 
rather than leaving it fully to the transport binding.

Proposed (but probably inadequate) text:

In the SPPP protocol document:

Only registrars have authentication credentials in SPPP. The registrar 
identifier (name) by which an SPPP request is checked against 
authorization policy is not conveyed in the body of the SPPP request. 
Authentication is performed at the the transport binding layer. The 
transport binding MUST therefore provide the authenticated registrar 
identifier to the lower layers of the implementation.

The implementation MUST check the authenticated registrar identifier 
against local policy in order to determine whether or not the specific 
request is currently authorized for that registrar.

In the SOAP binding document:

The SPPP SOAP binding uses digest authentication over HTTPS as specified 
in RFC 2617. The "username" parameter of the Authorization header 
encodes the name of the registrar making the request, and MUST be passed 
by the implementation along with the SOAP request body to the 
application. Use of this username in the making of authorization 
decisions is subject to local policy in the implementation.

...

> KJC3:  That's simply incorrect.  The SIP response is built from a lookup into a DB, be it in memory on on disk.

SOMETIMES SIP returns the results of a database lookup in a 302 
response. The more common case is for the SIP proxy to send the INVITE 
along to the terminating user agent, which responds with something like 
a 200 OK setting the call up. You certainly can't end SIP INVITE 
requests to arbitrary destination URLs in the hope of doing a database 
lookup, unless you a priori knowledge about the behavior of the servers 
at those URLs.

> KJC3:  OF course.  You brought up dig, not me.

Yeah, I'd still like better diagnostic tools.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 09:44:15 -0400

See responses in-line, KJC4.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, August 30, 2011 7:21 PM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09

KJC4:  There is no "login" command in SPPP, because it uses Digest Authentication, at the explicit request of one of the participants.  So there is no login command to talk about.  I am certainly not apposed to having an explicit "login" operation.  But you would need to convince others.

KJC4:  Yes, it does.  Because it has a direct login type command, not using digest authentication.  Dean, we've addressed this point at least 5 times now with me proposing what can be done about this.

KJC4:  I'm fine with this, as long as we sync this statement with the related statements that are already in the "Transport Requirements Section" of the document.  We also need to remove the "(name)" word in the above.

KJC4:  The spec already has the first sentence in there.  But I don't think the rest of what you propose here is accurate.  But we can change what you propose to explain how digest authentication is/canBe used to authorize (and therefore identify) the entity being authorized, as is the case in all uses of Digest Authentication (because that is what is exists to accomplish).
...

KJC4:  Being responsible for a system that supports ENUM, SIP, and SS7 protocols into the same underlying database, I'm fully aware of the use cases that come into play.  And even the case where a SIP response is "proxied" we still need to hit the DB in order to, among other reasons, know where to proxy to!  Come on dean this back and forth is pointless.

KJC4:  Yea, and they do/will exist, but are not part of the SPP protocol spec.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 31 Aug 2011 10:48:47 -0500

On 8/31/11 8:44 AM, Cartwright, Ken wrote:

> KJC4:  There is no "login" command in SPPP, because it uses Digest
> Authentication, at the explicit request of one of the participants.
> So there is no login command to talk about.  I am certainly not
> apposed to having an explicit "login" operation.  But you would need
> to convince others.

I'm not proposing an explicit login. I AM proposing that the data 
payload carry the validated username, which appears to be the registrar 
identity. I'll propose in further detail below.

> KJC4:  Yes, it does.  Because it has a direct login type command, not
> using digest authentication.  Dean, we've addressed this point at
> least 5 times now with me proposing what can be done about this.

It still hasn't quite resolved to what I think might be robustly 
implementable.

Here's a proposal:

We need some way to tie the "username" from Digest auth with the request 
and with the underlying database.

1) Add rar back into the BasicObjType

2) Say that the username expressed in the Digest MUST be matched against 
the request's rar by local policy to determine whether local policy will 
authorize the request.

This gives us a model where local policy could say that rar A can only 
manipulate stored records owned by rar A, or it could manipulate records 
owned by rar A, B, or C but not D, E, F and so on. In other words, a 
full range of flexibility.

Alternatively, if we really believe that "rant" is the object owner, we 
have to do something like say that request-username (from Auth) is 
matched against the rant in the request via a mapping outside of the 
protocol and under control of local policy in order to decide on the 
authorization of the request.

> The SPPP SOAP binding uses digest authentication over HTTPS as
> specified in RFC 2617. The "username" parameter of the Authorization
> header encodes the name of the registrar making the request, and MUST
> be passed by the implementation along with the SOAP request body to
> the application. Use of this username in the making of authorization
> KJC4:  The spec already has the first sentence in there.  But I don't
> think the rest of what you propose here is accurate.  But we can
> change what you propose to explain how digest authentication is/canBe
> used to authorize (and therefore identify) the entity being
> authorized, as is the case in all uses of Digest Authentication
> (because that is what is exists to accomplish). ...

Okay, what I have might need mods. But we need SOMETHING like it to pass 
security review.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 12:05:16 -0400

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, August 31, 2011 11:49 AM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09

KJK4:  I've already indicated that I am ok either way on this.

Here's a proposal:

KJC4:  Exactly, if I understand what you are saying.  This is the typical implementation approach.

KJC4:  Nope.  But again the term "owner" is not defined.  The terms are registrar and registrant, which are defined and in wide use.  Whether you call the registrar the "owner" or the registrant the "owner" is up to you.

KJC4:  Ok.

--
Dean