Subject: [drinks] corInfo discussion in spprov-12

From: Dean Willis <[email-masked]>
Date: Wed, 4 Jan 2012 10:30:06 -0600

Based on comments I made about -11, the text relating to corInfo has been heavily revised in -12.

Specifically, in 6.2 we have:

   o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record (see [RFC5067]).  This is done by
        setting the value of <corClaim> element of the CORInfoType
        object structure to "true".  The other two parameters of the
        CORInfoType, <cor> and <corDate> are set by the registry to
        describe the outcome of the carrier-of-record claim by the
        registrant.  In general, inclusion of <corInfo> parameter is
        useful if the registry has the authority information, such as,
        the number portability data, etc., in order to qualify whether
        the registrant claim can be satisfied.  If the carrier-of-record
        claim disagrees with the authority data in the registry, whether
        the TN add operation fails or not is a matter of policy and it
        is beyond the scope of this document.

This seems reasonably clear, but leaves me wondering: What are the implications of the corInfo parameter should a registry policy allow a registrar to claim COR responsibility for a registrant with respect to a TN that cannot be verified by the registry? Does it actually impact processing of anything in such a way that this could be a useful attack vector that we should warn registrars or users of registrar data about in Security Considerations? Or is it the corInfo status effectively meaningless? If meaningless, why do we even have it in the database?

If corInfo is important, then it's probably important that the registry handle it appropriately, and provide the information-consumer with knowledge about the registry's policy with respect to corInfo. Consequently, it's also important for the information consumer to understand the registry's policies in this regard, and take them into consideration when deciding how much trust to place in the corInfo data.

If this were the only such policy question, it could probably be dealt with in Security Considerations:

====
The telephone number data type "TNType" includes an optional parameter "corInfo" that indicates whether or not the containing public identifier is the "carrier of record" for this telephone number. Different registries may have different definitions for "carrier of record" and different mechanisms for authenticating this claim. Such definitions and mechanisms are outside the scope of this protocol document. Therefore, it is critical that a consumer of registry information be aware of the specific policies applicable to a registry providing information to that consumer, and consider those policies when making decisions based on such registry data.
====

Or, should we make authentication of corInfo mandatory for a registry before allowing it to be registered? Does this mean we need to define an authentication mechanism and document its use by a registry?

However, I'm now wondering: Is this just the tip of the "policy" iceberg? Remember, we've said that a lot of things are "local policy" driven. Don't we actually have many data elements whose meaning or authenticity is subject to variations in registry policy? Perhaps we need a disclaimer like the above for many (or all) data elements. How dhould a registry describe its policy for the consumer?  Does this mean we need  a formal means of declaring registry policy with respect to these data items? Or do we need to revisit the "policy-driven" aspect and specify behavior for all the policy-driven data?

If you think I ask too many questions now, you should have met me as a child ...

--
Dean

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Mon, 16 Jan 2012 17:14:19 -0500

Please see my thoughts below..

> This seems reasonably clear, but leaves me wondering: What are the
> implications of the corInfo parameter should a registry policy allow a
> registrar to claim COR responsibility for a registrant with respect to a
> TN that cannot be verified by the registry? Does it actually impact
> processing of anything in such a way that this could be a useful attack
> vector that we should warn registrars or users of registrar data about
> in Security Considerations? Or is it the corInfo status effectively
> meaningless? If meaningless, why do we even have it in the database?
>
> If corInfo is important, then it's probably important that the registry
> handle it appropriately, and provide the information-consumer with
> knowledge about the registry's policy with respect to corInfo.
> Consequently, it's also important for the information consumer to
> understand the registry's policies in this regard, and take them into
> consideration when deciding how much trust to place in the corInfo data.

"corInfo" is type "CORInfoType" (pasted below for quick ref). As mentioned in section 6.2, a registrant/registrar can claim being a COR by setting "corClaim" element in corInfo to true. If the registry policy is to allow this to happen without having a way to verify this then the registry shall not return "cor" and "corDate" elements in the response to the consumers of this information.
==
    <complexType name="CORInfoType">
     <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
     </sequence>
    </complexType>
==

> However, I'm now wondering: Is this just the tip of the "policy"
> iceberg? Remember, we've said that a lot of things are "local policy"
> driven. Don't we actually have many data elements whose meaning or
> authenticity is subject to variations in registry policy? Perhaps we
> need a disclaimer like the above for many (or all) data elements. How
> dhould a registry describe its policy for the consumer?  Does this mean
> we need  a formal means of declaring registry policy with respect to
> these data items? Or do we need to revisit the "policy-driven" aspect
> and specify behavior for all the policy-driven data?

As you also allude to, there are other items in the protocol/framework document that are a matter of policy (use of "priority" field on RG, allowable values for ENUM Service(s) etc.). Not sure if the design team has considered this subject in past discussions. Imo, instead of listing each of them separately in the Security Considerations, a generic statement to that effect in the Security Considerations section can be added to say that "There are items in the document that are a matter of policy and are indicated as such in the respective sections...Consumer of the registry information be aware.." (have not thought through the exact text).

.
.
.
There were too many questions:-).

Thanks,
Vikas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dean Willis
> Sent: Wednesday, January 04, 2012 11:30 AM
> To: [email-masked]
> Subject: [drinks] corInfo discussion in spprov-12
>
>
> This seems reasonably clear, but leaves me wondering: What are the
> implications of the corInfo parameter should a registry policy allow a
> registrar to claim COR responsibility for a registrant with respect to a
> TN that cannot be verified by the registry? Does it actually impact
> processing of anything in such a way that this could be a useful attack
> vector that we should warn registrars or users of registrar data about
> in Security Considerations? Or is it the corInfo status effectively
> meaningless? If meaningless, why do we even have it in the database?
>
> If corInfo is important, then it's probably important that the registry
> handle it appropriately, and provide the information-consumer with
> knowledge about the registry's policy with respect to corInfo.
> Consequently, it's also important for the information consumer to
> understand the registry's policies in this regard, and take them into
> consideration when deciding how much trust to place in the corInfo data.
>
> The telephone number data type "TNType" includes an optional parameter
> "corInfo" that indicates whether or not the containing public identifier
> is the "carrier of record" for this telephone number. Different
> registries may have different definitions for "carrier of record" and
> different mechanisms for authenticating this claim. Such definitions and
> mechanisms are outside the scope of this protocol document. Therefore,
> it is critical that a consumer of registry information be aware of the
> specific policies applicable to a registry providing information to that
> consumer, and consider those policies when making decisions based on
> such registry data.
> ====
>
>
> Or, should we make authentication of corInfo mandatory for a registry
> before allowing it to be registered? Does this mean we need to define an
> authentication mechanism and document its use by a registry?
>
> However, I'm now wondering: Is this just the tip of the "policy"
> iceberg? Remember, we've said that a lot of things are "local policy"
> driven. Don't we actually have many data elements whose meaning or
> authenticity is subject to variations in registry policy? Perhaps we
> need a disclaimer like the above for many (or all) data elements. How
> dhould a registry describe its policy for the consumer?  Does this mean
> we need  a formal means of declaring registry policy with respect to
> these data items? Or do we need to revisit the "policy-driven" aspect
> and specify behavior for all the policy-driven data?
>
> _______________________________________________
> 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.