Subject: Re: [pcp] ID Indicator option

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 02 Dec 2014 12:58:09 -0700

On 11/26/14, 11:03 PM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message----- From: Peter Saint-Andre - &yet
>> [mailto:[email-masked]] Sent: Thursday, November 27, 2014 8:55
>> AM To: Tirumaleswar Reddy (tireddy); Dave Thaler; [email-masked]
>> Subject: Re: [pcp] ID Indicator option
>>
>> On 11/26/14, 6:45 PM, Tirumaleswar Reddy (tireddy) wrote:
>>>> -----Original Message----- From: Peter Saint-Andre - &yet
>>>> [mailto:[email-masked]] Sent: Thursday, November 27, 2014
>>>> 2:26 AM To: Dave Thaler; Tirumaleswar Reddy (tireddy);
>>>> [email-masked] Subject: Re: [pcp] ID Indicator option
>>>>
>>>> On 11/26/14, 1:54 PM, Peter Saint-Andre - &yet wrote:
>>>>> On 11/26/14, 1:51 PM, Dave Thaler wrote:
>>>>>> Tiru Reddy wrote:
>>>>>>>> -----Original Message----- From: pcp
>>>>>>>> [mailto:[email-masked]] On Behalf Of Peter
>>>>>>>> Saint-Andre - &yet Sent: Tuesday, November 25, 2014
>>>>>>>> 8:51 AM To: [email-masked] Subject: [pcp] ID Indicator
>>>>>>>> option
>>>>>>>>
>>>>>>>> Dave Thaler has asked me to take a look at the ID
>>>>>>>> Indicator option in draft- ietf-pcp-authentication with
>>>>>>>> respect to internationalization.
>>>>>>>>
>>>>>>>> First, it's not clear to me exactly what the ID
>>>>>>>> indicator indicates.
>>>>>>>
>>>>>>> ID indicator will help the PCP client to pick the
>>>>>>> appropriate credentials to use with the server.
>>>>>>>
>>>>>>>> The spec says that it is "the identity of the authority
>>>>>>>> that issued the credentials" and that "the method of
>>>>>>>> generating this value is out of scope". Are there at
>>>>>>>> least any examples of what an ID indicator might look
>> like?
>>>>>>>
>>>>>>> It might look like "[email-masked]"
>>>>>>>
>>>>>>>> For example, what kinds of characters are allowable in
>>>>>>>> an ID indicator ?
>>>>>>>>
>>>>>>>> Over in the PRECIS WG, we have put a great deal of
>>>>>>>> thought into the handling of internationalized strings
>>>>>>>> within protocols. The PRECIS "IdentifierClass" is
>>>>>>>> intended to provide the foundation for identifiers that
>>>>>>>> are quite safe to use (e.g., by forbidding "expressive"
>>>>>>>> characters such as symbols). See draft-ietf-
>>>>>>>> precis-framework
>>>>>>> for details.
>>>>>>>>
>>>>>>>> Based on what I know so far, I think that using the
>>>>>>>> Username profile of the IdentifierClass (defined in
>>>>>>>> draft-ietf-precis-saslprepbis) might make sense here.
>>>>>>>
>>>>>>> Okay, so ID Indicator will consist only of Unicode code
>>>>>>> points that conform to the "IdentifierClass" base string
>>>>>>> class defined in ietf-precis-framework and the string
>>>>>>> MUST be encoded as UTF-8.
>>>>>>>
>>>>>>>> It maps fullwidth and halfwidth characters (common in
>>>>>>>> certain East Asian languages), applies Unicode
>>>>>>>> Normalization Form C (NFC),
>> etc.
>>>>>>>> We have had some debate about handling of case mapping
>>>>>>>> vs. case preservation, and it seems likely that we will
>>>>>>>> end up specifying two Username profiles, one with case
>>>>>>>> mapping and one with case preservation (e.g., does an
>>>>>>>> ID indicator of FooBarCity match an ID indicator of
>>>>>>>> foobarcity during comparison operations?). As Dave
>>>>>>>> pointed out in a recent message to this list, RFC 6943
>>>>>>>> might be consulted
>>>>>>> here as well.
>>>>>>>
>>>>>>> Yup, it was discussed in the PCP WG meeting at IETF-91
>>>>>>> that
>> "Absolute"
>>>>>>> comparison algorithm will be used by the PCP client.
>>>>>>
>>>>>> Absolute means byte-for-byte equality.  The WG actually
>>>>>> wanted
>>>> "Definite"
>>>>>> which means you specify what the normalization/comparison
>>>>>> algorithm is, and that's what we're discussing here.
>>>>>
>>>>> Right. I would suggest the Username profile of the
>>>>> IdentifierClass from draft-ietf-saslprepbis, probably the
>>>>> case-mapping version instead of the case-preserving version.
>>>>> (Right now the spec doesn't have both of those versions in
>>>>> it, but it will soon.)
>>>
>>> Okay, I guess it means that the PCP client will use Case-mapping
>>> rule
>> https://tools.ietf.org/html/draft-ietf-precis-framework-20#section-5.2.3
>> for ID indicator comparison.
>>>
>>> -Tiru
>>
>> Hi Tiru,
>>
>> Well, not quite, because case mapping is only one small part of the
>> problem. (Yes, internationalization is hard in a messy way.)
>>
>> Your message inspired me to update draft-ietf-precis-saslprepbis so
>> that it defines exactly what I think the PCP WG needs:
>>
>> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-11#section-3.2
>>
>>
>>
As Dave Thaler has pointed out, a "Definite" comparison algorithm provides
>> a single well-defined comparison method. In the context of the work
>> we've been doing in the PRECIS WG, such a comparison algorithm
>> includes the following:
>>
>> 1. Specification of the allowable range of Unicode characters (in
>> PRECIS we have narrowed this down to two string classes: the
>> IdentifierClass and the FreeformClass).
>>
>> 2. Specification of rules for width mapping, so-called additional
>> mappings (e.g., mapping of non-ASCII space characters to ASCII
>> space), and case mapping vs. case preservation.
>>
>> 3. Specification of the Unicode normalization form to be applied
>> (typically NFC).
>>
>> 4. Specification of how to handle strings that contain
>> right-to-left characters.
>>
>> 5. Specification of the equivalence rules for comparison purposes
>> (typically octet-for-octet matching performed *after* all the
>> foregoing rules have been applied).
>>
>> The UsernameCaseMapped profile that I point to above does all of
>> those things for you, so I think it is easiest just to point to
>> that profile (as draft-ietf- xmpp-6122bis now does, too). At least
>> I think this is the right thing to do, based on what I understand
>> of the requirements here. I admit that I might be missing
>> something...
>
> Thanks peter. I agree with your assessment and update to
> draft-ietf-precis-saslprepbis meets the PCP authentication needs.
>
> We will update draft- ietf-pcp-authentication with the following
> text:
>
> *The ID indicator field is UTF-8 encoded Unicode code point
> conforming to the "UsernameCaseMapped" profile of the PRECIS
> IdentifierClass.
>
> *PCP client validates that the ID indicator field conforms to the
> "UsernameCaseMapped" profile of the PRECIS IdentifierClass. PCP
> client enforces the rules specified in sections 3.2.2 of
> draft-ietf-precis-saslprepbis to map the ID indicator field. PCP
> client compares the resulting string with the ID indicators stored
> locally on the PCP client to pick the credentials for authentication.
> The two indicator strings are to be considered equivalent by the
> client if they are an exact octet-for-octet match.

Yes, it's important to be very clear about what entities enforce the
rules. You might be able to borrow some text from 6122bis on that score. 
I don't know enough about PCP to say whether the client or the server 
ought to have that responsibility here.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Dec 2014 10:52:34 +0000

> -----Original Message-----
> From: Peter Saint-Andre - &yet [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2014 1:28 AM
> To: Tirumaleswar Reddy (tireddy); Dave Thaler; [email-masked]
> >> [mailto:[email-masked]] Sent: Thursday, November 27, 2014 8:55 AM
> >> To: Tirumaleswar Reddy (tireddy); Dave Thaler; [email-masked]
> >>>> 2:26 AM To: Dave Thaler; Tirumaleswar Reddy (tireddy); [email-masked]
> >>>>>>>> [mailto:[email-masked]] On Behalf Of Peter Saint-Andre -
> >>>>>>>> &yet Sent: Tuesday, November 25, 2014
> >>>>>>>> 8:51 AM To: [email-masked] Subject: [pcp] ID Indicator option
> >>>>>>>>
> >>>>>>>> Dave Thaler has asked me to take a look at the ID Indicator
> >>>>>>>> option in draft- ietf-pcp-authentication with respect to
> >>>>>>>> internationalization.
> >>>>>>>>
> >>>>>>>> First, it's not clear to me exactly what the ID indicator
> >>>>>>>> indicates.
> >>>>>>>
> >>>>>>> ID indicator will help the PCP client to pick the appropriate
> >>>>>>> credentials to use with the server.
> >>>>>>>
> >>>>>>>> The spec says that it is "the identity of the authority that
> >>>>>>>> issued the credentials" and that "the method of generating this
> >>>>>>>> value is out of scope". Are there at least any examples of what
> >>>>>>>> an ID indicator might look
> >> like?
> >>>>>>>
> >>>>>>>> For example, what kinds of characters are allowable in an ID
> >>>>>>>> indicator ?
> >>>>>>>>
> >>>>>>>> Over in the PRECIS WG, we have put a great deal of thought into
> >>>>>>>> the handling of internationalized strings within protocols. The
> >>>>>>>> PRECIS "IdentifierClass" is intended to provide the foundation
> >>>>>>>> for identifiers that are quite safe to use (e.g., by forbidding
> >>>>>>>> "expressive"
> >>>>>>>> characters such as symbols). See draft-ietf- precis-framework
> >>>>>>> for details.
> >>>>>>>>
> >>>>>>>> Based on what I know so far, I think that using the Username
> >>>>>>>> profile of the IdentifierClass (defined in
> >>>>>>> Okay, so ID Indicator will consist only of Unicode code points
> >>>>>>> that conform to the "IdentifierClass" base string class defined
> >>>>>>> in ietf-precis-framework and the string MUST be encoded as
> >>>>>>> UTF-8.
> >>>>>>>
> >>>>>>>> It maps fullwidth and halfwidth characters (common in certain
> >>>>>>>> East Asian languages), applies Unicode Normalization Form C
> >>>>>>>> (NFC),
> >> etc.
> >>>>>>>> We have had some debate about handling of case mapping vs.
> case
> >>>>>>>> preservation, and it seems likely that we will end up
> >>>>>>>> specifying two Username profiles, one with case mapping and one
> >>>>>>>> with case preservation (e.g., does an ID indicator of
> >>>>>>>> FooBarCity match an ID indicator of foobarcity during
> >>>>>>>> comparison operations?). As Dave pointed out in a recent
> >>>>>>>> message to this list, RFC 6943 might be consulted
> >>>>>>> here as well.
> >>>>>>>
> >>>>>>> Yup, it was discussed in the PCP WG meeting at IETF-91 that
> >> "Absolute"
> >>>>>> Absolute means byte-for-byte equality.  The WG actually wanted
> >>>> "Definite"
> >>>>> Right. I would suggest the Username profile of the IdentifierClass
> >>>>> from draft-ietf-saslprepbis, probably the case-mapping version
> >>>>> instead of the case-preserving version.
> >>>>> (Right now the spec doesn't have both of those versions in it, but
> >>>>> it will soon.)
> >>>
> >> 4. Specification of how to handle strings that contain right-to-left
> >> characters.
> >>
> >> those things for you, so I think it is easiest just to point to that
> >> profile (as draft-ietf- xmpp-6122bis now does, too). At least I think
> >> this is the right thing to do, based on what I understand of the
> >> requirements here. I admit that I might be missing something...
> >
> > *The ID indicator field is UTF-8 encoded Unicode code point conforming
> > to the "UsernameCaseMapped" profile of the PRECIS IdentifierClass.
> >
> > "UsernameCaseMapped" profile of the PRECIS IdentifierClass. PCP client
> > enforces the rules specified in sections 3.2.2 of
> Yes, it's important to be very clear about what entities enforce the rules. You
> might be able to borrow some text from 6122bis on that score.

Thanks.

> I don't know enough about PCP to say whether the client or the server ought
> to have that responsibility here.

In PCP authentication scenario the onus is on the PCP client.

-Tiru