Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

[<[e-mail]>]

Thanks for clarifying. A follow-up on the last two points, in-line. 

Philippe Fouquart
Orange Labs Networks
[phone]


-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: Tuesday, July 23, 2013 11:11 PM
To: FOUQUART Philippe OLNC/OLN
Cc: [e-mail]
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt


[snip] 

> 
>>  Likewise for nationally-specific number codes, the IKES process 
>>  generates a canonical representation of the number code.  A leading 
>>  country-code is prepended to the number code, to indicate the 
>>  national numbering plan they are for.
> 
> I suppose you've been waiting for this but the usual problem of using such "pseudo E.164 numbers" for non E.164 numbers instead of local numbers is that, for countries that use national trunk codes eg 0, you can have an overlap between the short codes and the initial digits of the E.164 NDC or the SN. It's obviously not a problem as long as we stay in the dialing plan (actually that's precisely what the national trunk code is here for, to have more spare values to use) but it seems this would mean that the assignee of say range 112 could legitimately sign +CC-112, I'm not sure that's a good thing. (although this particular one 112 is indeed generally reserved in the national E.164 numbering plan but I use it to get the picture). 

Yup, I've been waiting for that. :)

So right now in the CIDER draft it talks about there being a different domain name anchor for E.164s vs. number-codes.  So "cid.example.com" might be the E.164 anchor, while "nid.example.com" might be used for number-codes.  So a key holder for the whole E.164 range prefixed by +33-112 couldn't successfully sign a number-code of 112 in France, because the IKES-receiving verifier would look the latter E.164 up as "2.1.1.3.3.nid.example.com", while the attacker's key is only in "2.1.1.3.3.cid.example.com" and thus only valid for that number-code.

I think I put an example in where they used the same anchor, which is probably dangerous for the reason you said.  If I did, I'll fix it next rev.

[PhF] Thanks, I get the picture now (apologies maybe I should have started with cider, always better to start with the lighter stuff first). 

I find the term canonical a bit misleading then for two reasons: 
- the point of converting into a canonical form to me is to have a unique form upon which all subsequent operations can be done whilst the non canonical form and related information that lead to it may be discarded altogether. I now understand why the draft insists on the IKES Generator using the "source identity type" in addition to the "canonical identity", it's just that having two distinct numbers (albeit of a different nature) leading to exactly the same "canonical" string to be processed and signed differently depending on their 'type' is quite confusing. 
- "canonical [E.164] form" for a number is as you know a very common term to describe the international E.164 format of a number stripped out of the visual separators. The canonical form in the draft is not that, well, expect for the E.164 numbers... I wouldn't like this "canonical" form to appear 'as is' in RU/To or From, for that matter, as I said in some numbering plans in would be problematic. 

Maybe that would be preferable to use a different term; if you'd rather not, maybe you want to add something along the lines of 3966 that says that "converting a nationally-specific number code into its canonical form/string does not make it a valid E.164 number: the string consisting of the leading country-code prepended to the number code cannot be assumed to be a valid E.164 number" 

>> 10.  Usage in SS7/ISUP
> [...]
>> the signature, key 
>>  index, and timestamp are carried in the User-to-User Information 
>>  parameter ;
> 
> (Noted past exchanges on this. Don't think this was addressed) Generally speaking, what if the UUI is already used for a different purpose? (eg RFC 6467 use cases)

Yeah, I was waiting for the emails discussion around it to coalesce.  I think the right thing to do would be for RFC 6567 to win - the UUI in that case is for a end-to-end UUI as used in inter-PBX/inter-branch cases, so the IKES Generator or SIP-SS7 interworking gateway should not replace it with the IKES stuff.  I'm thinking that's ok, because as far as I know those inter-PBX cases are already in controlled environments and don't have a faked caller-id problem from random sources.  Yes/no?

[PhF] (thanks, sorry mistyped the rfc number) Well, sort of: a) not all of them are in "controlled environments" b) it is not uncommon in national "PSTN" interconnect offerings to support this and pass it on transparently and c) this type of access may actually be the source if not maliciously-faked, at least erroneously-configured caller-id. Maybe for c) depending on their use of the UUI, they could privately/bilaterally come up with an index of sort to assert the "on-net" calls, but I think that's just too complex.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.