Roamops IETF Meeting 1. Agenda Agenda Bashing Document Status XML Phone Book Limiting Fraud in Roaming Charter Revision 2. Document Status draft-ietf-roamops-auth-10.txt in is the RFC Editor's queue The XML Phone Book is still in draft What do we want to do with the ADIF draft? Certificate Based Roaming - to be discussed Pat Calhoun will send a list of expired drafts to Randy Bush and Internet-Drafts. 3. XML Phone Books (Max Riegel) Rev 02 The draft is draft-ietf-roamops-phonebook-xml-01.txt. The new draft includes the changes that were requested at the last IETF meeting. Element Definition for 'Phone Book' and POP Arrangement of element definitions and descriptions Additional format for 'providerIcon' (JPEG and GIF) XML Phonebook is a single file (no external references) Typing by notification for: Fully qualified domain name IP address Picture format (base 64 encoded JPEG/GIF) All other elements are pure '#PCDATA' Updated 'Complete XML DTD' Some security considerations added. There is a new W3C working group working on this, and we hope to use their output in a next version of our security consideration section. Some new values for 'modemProtocols' and 'isdnProtocols' Several editorial changes The existing XML phone book entry makes use of cryptic bit masks for values. A proposal would be to change the document to make use of more readable labels (e.g. V90, ISDN, etc). There seems to be a preference for the latter, but since the xml phone book is not intended to be read by humans, it is not clear that it is useful to change the draft. We need to consider which one we would like to use. Refinement of number of occurrences of elements 'Attribute' declaration (e.g.) Position Property ---------- ----------------------------- 0x0001 Multilink 0x0002 Mobile-IP 0x0004 Multicast Reception 0x0008 Multicast Transmission Issue: The IANA does register strings, but not XML attributes. How would the phonebook be extended in the future? This will be taken to the list. Issue: Do we need strong typing for telephone numbers? Some definition of how a telephone number should look like, and how it means could be included. We could define the global reachable telephone number. We need to take this to the list. One recommendation is to define the telephone number to be in the format of . We will take this to the list. Issues: The W3C is working on a first proposal for an XML schema. This is still early in the process. We would have to wait until the end of this year before a schema is ready for us to use. There are currently no tools available to create schemas, and none are planned by the end of the year. Therefore, we propose using the DTD. 4. Limiting Fraud in Roaming (Glen and Pat) In the requirements RFC, it mentions that we should be able to limit, detect or eliminate the risk of fraud. The RADIUS protocol is not able to meet this requirement, so a new protocol by Glen and Pat was submitted after the last IETF. The issue is that the RADIUS server, in a roaming environment, cannot send an unsolicited message. The draft, draft-ietf-roamops-fraud-limit-00.txt, talks about a way that an ISP, or home provider, can control the risk of fraud they are willing to accept, at the cost of CPU and bandwidth. This is done by enforcing that authentication is done between the PPP user, and the home DIAMETER Server. The DIAMETER Server generates the challenge, and validates the challenge when the response is received. The DIAMETER server also generates a signed token that includes the username, session-ids, timestamp, etc. This token must be present in the accounting messages. The DIAMETER server also returns a session lifetime in the reply. The home DIAMETER Server initiates an authentication to the user before the session expires. A successful authentication creates a new signed object, which can be used in the Interim Accounting requests. If a broker is present, it can either proxy the request to the home DIAMETER server, or return a referral messages back to the proxy DIAMETER server. The broker acts as a CA, issuing certificates to all roaming partners. This allows the roaming partners to sign their accounting messages, which is used for end-to-end security. The proposal does not support fraud if accounting is based on traffic. There appears to be quite a bit of interest in the Working Group, we need to take this to the list as well. 5. Charter Revision The Working Group has rough consensus that we will NOT wait for the AAA to finish, but will fulfill our own requirements by creating or adopting a protocol. Once a generic protocol is completed, and is useful to ROAMOPS, we will look into it. The Working Group will move the ADIF draft to last call in 2 months. We will talk about the certificate based roaming draft on the list. We will add a work item to define a new protocol for roaming authentication, authorization and accounting. The Working Group had consensus that protocol developed will be DIAMETER base and extensions necessary to fulfill ROAMOPS requirements. Pat Calhoun and Ken Peirce will develop the BCP to compare COPS and DIAMETER against the roaming protocol requirements.