As previously outlined, the process used in the financial infrastructure is exactly what the ISPs do for user login. The POPs typically either:
1) a specific phone number select specific router that have a static binding to a specific RADIUS server (this is like walking into your local branch). the selection of the RADIUS server (and the userid selects the appropriate account recrod) is basically performed by what phone number the client dialed. The phone number used for dialing the ISP service has effectively done the routing specific. 2) the client has their PPP software configured with a prefix in front of the userid, something of the form: XXXX/userid. The router then selects the appropriate RADIUS server based on the XXXX prefix. The XXXX prefix has then the equivalent of the routing number part of a financial account record. In the financial industry, the account number contains both the institutional context (routing number) and account specific information in a single number. In the ISP industry, the routing context (how to get to the correct RADIUS server account record) is either determined statically by the (initial) physical connection or the routing value for the correct context (XXXX prefix) is supplied as part of the connection transaction. So we have instance examples of both the financial industry and the world-wide-internet-service-provider industry working exactly the same. In some past descriptions regarding bilaterial business contracts, a company may do a background check with credit bureau, D&B, and the other companies bank. They then set up an account with various pieces of information regarding the agreed upon business relationship, T&Cs, etc. That account information traditionally shows up on things like purchase orders, etc. Even in the case of past descriptions of SSL domain name certificates, the TTPs are doing D&B checks. The purpose of a certificate is to carry stale, static subset of information in some account record someplace so that a relying-party can complete a transaction without recourse to the real copy of the information (since if they had recourse to the master account record, the stale, static subset of the information obviously becomes redundant and superfluous). So lets look at the relying-party-only certificate scenario for performing a transaction w/o recourse to the real, online information: A transaction is created with the financial account number or ISP login userid (aka some sort of business context specific handle, specific to that environment and transaction). It is digitally signed The relying-party-only certificate is appended and all three pieces are transmitted. The relying-party receives the transmission and tries and first tries to figure out if they can perform the business process based on only having those three pieces (again the whole point of a stale, static certificate is a subset of the account information when there isn't recourse to the real information). Lets keep it simple and say that it is only ISP login. The relying-party (ISP) validates the certificate, and then validates that the digital signature with the public key. Everything works. The vulnerability/exploit is that the userid in the LOGIN transaction and some "handle" in the certificate have to match. If the process doesn't require that the two items have some matching value, then theoritically I could sign up for a any random userid at that ISP, get a certificate, and use a valid certificate to login into every userid at the ISP. This is the traditional chain of trust scenario that is described in almost every description of a certificate-based TTP operation. The relying-party has a table (or set of account records) of trusted TTP public keys. It uses the approprirate TTP public key to verify a presented certificate, it then uses the public key in the certificate to verify the digital signature on some transaction. It then typically uses some information in the certificate (that is bound to the public key) to connect the certificate to the contents of the transaction. This is how financial relying-parties make sure that a person only does withdrawals from bank accounts that they are actually entitled to withdraw from. Just having some random valid certificate doesn't mean that you can perform operations on all accounts at that financial institution. So the redundant and superfluous scenario is that any present day operation of almost any value typically has the relying-party resorting to real-time access to real-time and/or aggregated information in some account type record. As previously described, financial transactions started 30 some years ago doing it to have access to the existing account balance. ISPs do it to have access to currently valid accounts. The transaction specifies necessary and sufficient information to specify the requested operation (including the handle or account number) and the account provides all the information necessary to correctly complete the transaction. Upgrading existing shared-secret based operations to non-shared-secret, replaces a password or PIN on the transaction with a digital signature and replaces the PIN/password in the account record with a public key. Stale, static certificates are superfluous in online environment where the relying-party has direct access to the original of the information that provides the context for performing the business process (purchase order, credit card transaction, ISP login). The account record contains all the information necessary to do real-time operation on the business process, including things like authentication information, aggregated information (transaction done to date), real-time information (remaining balance, which could represent a sequence of aggregated operations). In the real-time chain-of-trust scenario, the account number or userid in the transaction indexes the account record, the digital signature on the transaction is validated with the public key in the account record, and the account record provides all the real-time information necessary for the relying-party to complete the transaction. So, how do you translate that from a relying-party-only certificate operation to a single certificate operation? The traditional chain-of-trust scenario says the transaction contains some handle or identifier; that handle or identifier can be matched in the certificate which shows that the transaction and the certificate relate to the same operation. If it isn't a relying-party-only certificate, but some certificate that has a globally unique identifier ... then has does a single certificate with a globally unique identifier provide the necessary and sufficient trust for a broad range of business transactions from credit card transactions to ISP loging to business purchase order across a broad range of different entities. The design point (purpose) of (stale, static) certificates was to provide chain-of-trust for performing operations when the relying-party didn't have real-time and/or direct access to the real information. The stale, static certificates were desgned as a sort of stand-in/substitute when the relying-party couldn't directly access the real information. So instead of authentication, the single static, stale certificate with globally unique identifier would appear to be heading in the direction of identification in place of authentication. Rather than authenticating the public key owner as being authorized to perform a specific operation in a specific business operation .... it would appear that the single, static, stale certificate paradigm with a globally unique identifier is heading in the direction of identification of the public key owner as opposed to authentication of the public key owner (just the semantics of globally unique identifier seems to carry with it the conotation of identification). Now it is difficult to see how a single, static, stale certificate with a globally unique identifier would provide the necessary business process context (and chain of trust) to indicate that a specific person is authorized to do arbritrary credit card transactions as well as arbritrary ISP logins (where the relying-party is performing this determination in an offline manner w/o access to the real account record). One might imagine a world of where every valid citizen is authomatically authorized to do everything, once they are identified. All possible transactions only require identification. There are no individual business process that are relying-party specific as to whether a citizen is authorized or not. The global (government?) authority gets forwarded all citizen transactions that occured during the month for the aggregated activities of their identified citizens and reconciles each citizens monthly balance sheet. Which somewhat gets back to the original subject line regarding is authentication and identification being confused. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm [EMAIL PROTECTED] on 6/26/2003 6:27 am wrote: Global account numbers (entity IDs) are redundant? Well, that means that business entities must use their partners' unique local account ID when they send for instance a purchase order. It also means that you must keep records of all your business parties local ID of _your_ entity. Having global account numbers you can safely ignore your business partners' account IDs of your business except when you get something in return like an invoice. In those situations it is nice to have the partner's local ID of you, as call- centers usually look on local IDs which are the index in the databases as well. Only in a relying party PK-model global account numbers become redudant. In such systems you not only need to have the unique local ID but also unique private keys depending on the verifiers policy. Further advantages with global account IDs is that TTPs can provide services like credit status. This is one of the reasons D U N S is often required in the states. But are D U N S globally unique? In fact they are, it is just that you currently have to _know_ that it is a D&B-assigned number and not some other registry. The described IETF-draft in preparation is designed to solve this by adding a universal "account authority" solution. My conclusion is that the mechanisms used in the financial industry does not perfectly match the needs of non-payment "transactions". For list-usage reasons I will though refrain from further discussions on this particular subject. /ar
