From exim@www1.ietf.org Fri Aug 1 09:27:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14869 for ; Fri, 1 Aug 2003 09:27:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZw1-0003bS-Pe for aaa-archive@odin.ietf.org; Fri, 01 Aug 2003 09:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71DR5dZ013844 for aaa-archive@odin.ietf.org; Fri, 1 Aug 2003 09:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZw1-0003bD-Lc for aaa-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 09:27:05 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09900 for ; Fri, 1 Aug 2003 09:02:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZYB-0002ls-Ca for aaa-web-archive@ietf.org; Fri, 01 Aug 2003 09:02:27 -0400 Date: Fri, 01 Aug 2003 09:02:27 -0400 Message-ID: <20030801130227.29120.60532.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-web-archive@ietf.org: List Password // URL ---- -------- aaa@ietf.org wumate https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org From mailman-admin@ietf.org Fri Aug 1 09:32:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14431 for ; Fri, 1 Aug 2003 09:19:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZYg-0003br-E7 for aaa-archive@lists.ietf.org; Fri, 01 Aug 2003 09:02:58 -0400 Date: Fri, 01 Aug 2003 09:02:58 -0400 Message-ID: <20030801130258.29120.37371.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From owner-aaa-wg@merit.edu Mon Aug 4 19:55:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15843 for ; Mon, 4 Aug 2003 19:55:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE2D091242; Mon, 4 Aug 2003 19:55:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BD4291244; Mon, 4 Aug 2003 19:55:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05FA091242 for ; Mon, 4 Aug 2003 19:55:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0E535DDCC; Mon, 4 Aug 2003 19:55:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 5414E5DDCA for ; Mon, 4 Aug 2003 19:55:33 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2656.59) id ; Mon, 4 Aug 2003 19:55:32 -0400 Message-ID: From: Avi Lior To: "'miguel.a.garcia@ericsson.com'" , "'maria.c.belinchon@ericsson.com'" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Avi Comments (second installment): draft-belinchon-aaa- diameter-mm-app-01.txt Date: Mon, 4 Aug 2003 19:55:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is my second installment of comments: A general comment is the issue of user-name. As indicated in the following comments the text is based on the fact that username is know but as you point out it is sometimes not known. You need to address this issue for this to be a general SIP solution. 5.1 User-Authorization-Request (UAR) Command ................... The user name used for authentication of the user is conveyed in a User-Name AVP (imported from the Diameter baseprotocol [2]). The location of the authentication user name in the SIP REGISTER request varies depending on the authentication mechanism. When the authentication mechanism is HTTP Digest as defined in RFC 2617 [4], the authentication user name is found in the "username" directive of the SIP Authorization header field value. [AL] Sounds like there are other cases -- that is not a HTTP Digest. What are they or are you just giving an example? The SIP or SIPS URI to be registered is conveyed in the SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or SIPS URI is found in the To header field value of the SIP REGISTER request that triggered the Diameter UAR message. The SIP-Visited-Network-Identifier AVP indicates the network that is providing SIP services (e.g., SIP proxy functionality or any other kind of services) to the SIP User Agent. Message Format ::= < Diameter Header: aaa, REQ, PXY > < Session-ID > < Auth-Application-Id > { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } { SIP-Public-User-Identity } [ SIP-Visited-Network-Identifier ] [ SIP-User-Authorization-Type ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] [AL] I think you have an error with the Destination-Host the bracket should either be '{' or it should be moved down the list. OPEN ISSUE: according to the above description, the User-Name AVP is mandatory in the UAR message. This AVP is always available in a 3GPP environment, because 3GPP has mandated the private user identity to be present in every REGISTER request. However, in a general SIP environment, a SIP client will not insert any identity without being challenged. Therefore, the User-Name AVP may not be present. Action: investigate if this AVP can be set to optional. [AL] I think this is a serious issue for this document since it seems to me that you depend very heavily on the existance of the User-Name attribute. To be a general solution which you would have to be in the AAA-WG, I would think you would have to allow for this to be optional. I dont see any other way. 5.2 User-Authorization-Answer (UAA) Command ................... When the authorization procedure succeeds, the Diameter server constructs a User-Authorization-Answer (UAA) message that MUST include either the address of the SIP server already assigned to the user or the capabilities needed by the SIP server (Diameter client) to select another SIP server for the user. This section will be based on the required capabilities of the SIP server to trigger and execute services for the user. The former option is used when the Diameter server is aware of an allocated SIP server to the user, whereas the latter is used when the Diameter server is not aware of an allocated SIP server, letting the SIP server to choose, if needed, an appropriate SIP server according to the required capabilities. [AL] The wording of the above par. is awakward. What do you mean by "This section will be based on the required capabilities...."? At reception of the Diameter UAR message, the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter User-Authorization-Answer (UAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN. [AL] Change "MUST build a" to "MUST reply with a" [AL] Is the above paragraph true? Is the user-name the only thing that can be used to allow the process to continue? This is not really where the authentication happens right? So other attributes could be used to verify whether the process should go on? Especially since the username could be optional. Then Diameter server MUST authorize that User-Name AVP value is able to register the SIP or SIPS URI included in the SIP-Public-User-Identity AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter User-Authorization-Answer (UAA) message. [AL] Change "Then Diameter server" to "Next, the Diameter server" [AL] Again here you are talking about a specific 3GPP behavior no? user-name can be optional right? If there is a SIP-Visited-Network-Identifier AVP in the Diameter UAR message, and the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify whether the user is allowed to roam into the network specified in the SIP-Visited-Network-Identifier AVP in the Diameter UAR message. If the user is not allowed to roam into such network, the Diameter AAA server MUST set the Result-Code AVP value in the Diameter UAA message to DIAMETER_ERROR_ROAMING_NOT_ALLOWED. [AL] Can't i make the decision whether the user is allowed to roam based only on the SIP-Visited-Network-Identifier? If i dont have a roaming agreement with the network why should i bother looking up a user? Its probably faster to do that. SImilar to RADIUS Call Check functionality. ....................... In case that the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION then: o If the Diameter server is not aware of any previous registration of the user name (including registrations of other public user identities allocated to the same user name), then the Diameter server does not know of any SIP server allocated to the user. In this case the Diameter server MUST set the Result-Code AVP value to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and the Diameter server SHOULD include the required SIP server capabilities in the SIP-Server-Capabilities AVP value in the Diameter UAA message. The SIP-Server-Capabilities AVP will assist the Diameter client (SIP server) to select an appropriate SIP server for the user, according to the required capabilities. [AL] what if the diameter server just wants to assign a specific SIP server could it not set the SIP-Server-Name AVP? [AL] There seems to be some wording problem between the above and below par. Above you seem to say that the Diameter Server does not know of any SIP server allocated to the user If the Diameter server is not aware of any previous registration of the user name. Yet in the paragraph below you say that in some cases, the Diameter server is aware of a previously assigned SIP server o In some cases, the Diameter server is aware of a previously assigned SIP server for the same or different public user identity allocated to the same user name. In these cases, re-assignment of a new SIP server may or may not be needed, depending on the capabilities of the SIP server. The Diameter server MUST always include the allocated SIP server URI in the SIP-Server-Name AVP of the UAA message. If the Diameter server does not return the SIP capabilities, the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION. Otherwise, if the Diameter server includes a SIP-Server-Capabilities AVP then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_SERVER_SELECTION. The Diameter client will then determine, based on the received information, whether it needs to select a new SIP server or not. In case that the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION&CAPABILITIES then Diameter Server MUST return the list of capabilities in the SIP-Server-Capabilities AVP value of the Diameter UAA message, it MUST set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return a SIP-Server-Name AVP. The SIP-Server-Capabilities AVP enables the SIP server (Diameter Client) to select another appropriate SIP server for invoking and executing services for the user, depending on the required capabilities. The Diameter server MAY leave the list of capabilities empty to indicate that any SIP proxy can be selected. [AL] What if the Diameter server does not want to allow the Client to change? What would the response be? ............ End of section 5.2 Avi Lior Bridgewater Systems Corporation Phone : (613) 591-9104 x6417 or (613) 591-6655 Fax : (613) 591-6656 E-mail : avi@bridgewatersystems.com www.bridgewatersystems.com From owner-aaa-wg@merit.edu Thu Aug 7 03:58:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03578 for ; Thu, 7 Aug 2003 03:58:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93ADF91284; Thu, 7 Aug 2003 03:58:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EFA591287; Thu, 7 Aug 2003 03:58:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB9B191284 for ; Thu, 7 Aug 2003 03:58:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8DA305DDF7; Thu, 7 Aug 2003 03:58:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id BBA145DDCA for ; Thu, 7 Aug 2003 03:58:28 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h777wF7W021750; Thu, 7 Aug 2003 09:58:15 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL80CS0F; Thu, 7 Aug 2003 09:58:15 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.128]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h777wESZ026353; Thu, 7 Aug 2003 10:58:14 +0300 (EET DST) Message-ID: <3F320695.9050006@ericsson.com> Date: Thu, 07 Aug 2003 10:58:13 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, es MIME-Version: 1.0 To: Avi Lior Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Avi Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Avi: First let me apologize for the delay in answering your mail. I was having a few days of vacation, something common in summer time in Europe. Now, thanks a lot for your comments. Certainly they are valuable. Please see my answers below. I have seen your e-mail with your second round of comments, that I will try to answer asap. /Miguel Avi Lior wrote: > This is my first installment of comments up to section 5. Stay tuned for > the next section > > [AL] General Comments: > > I did not read other peoples reviews. This way if there is duplication > you will get an amplication effect which could be useful. After my > review i will read the other ones. > > However, I did read the first couple of reviews that talked about the name > change > and perhaps it would be a good idea to change the name to reflect the > "SIPness" of this draft. > > Also I am not a SIP expert so you are getting the view of a non-sip > expert reviewer which is a good thing. But make sure you get a SIP type > person to review. > > [AL] End of general comments > > > 2. Introduction > > This document specifies the Diameter Multimedia Application. This is > a Diameter application that allows a Diameter client to request > authentication and authorization information to a Diameter server for > Session Initiation Protocol (SIP) [6] based IP multimedia services. > We assume that the SIP server and the Diameter client are located in > the same node, so that the SIP server is able to receive and process > SIP requests and responses which in turn relies on the AAA > infrastructure for authenticating the SIP request and authorizing the > usage of particular SIP services. > > [AL] What is a node? The SIP server is acting as a Diameter Client. > Perhaps a better way to say this is: In this document we assume that > the SIP server is acting as a Diameter Client..... Good question: what is a node? I guess what we try to say is that the SIP server function and the Diameter client function are co-located, or linked by some sort of communication (e.g., inter process communication or some non-standardized mechanism) that links both processes. The general perception is that both functions (SIP and Diameter) are physically located in the same processor, although it might not be the case. I don't know how to summarize all this, but we will try. Ok with your second comment. > > > This document provides Diameter procedures to implement certain > required functionality when SIP is the protocol chosen to initiate > and tear-down multimedia sessions. However, this document does not > mandate any particular mapping of SIP procedures to Diameter > Multimedia procedures, nor this document > > [AL] mandate OK > > any particular sequence of > events between SIP and Diameter. In some cases, though, this document > provides with useful examples to show the interaction between SIP and > Diameter Multimedia in order to achieve the desired functionality. > > [AL] Delete " In some cases, though," and "with" ok > > The Overview chapter (Section 3) provides the reader with > non-normative description of the Diameter multimedia commands and > responses and some guidance of its linkage with SIP procedures. > > [AL] Can't you use Informative for non-normative? Yes, no problem... I was wondering of the difference between both terms... > > ..... > > 3. Overview of operation > > This section provides an informative description of how the Diameter > Multimedia application can be used together with SIP. By no means > this section mandates any specific usage of the Diameter Multimedia > application nor it mandates a specific mapping between SIP and > Diameter messages. This section is just a collection of examples that > shows how the required AAA functionality can be achieved in > conjunction with SIP. > > [AL] Change: "application nor it mandates a " to: "application nor does > it mandates a " above. ok > > > > According to Figure 2 a SIP User Agent Client (UAC) sends a SIP > REGISTER request (step 1) to its home domain. SIP server 1 will > receive the SIP request. We assume that this SIP server may be > located, e.g., at the edge of the administrative home domain. The > Diameter client in SIP server 1 will contact its Diameter server by > sending a Diameter User-Authorization-Request (UAR) message (step 2) > to determine if this user is allowed to receive service, and if so, > request the address of a local SIP server capable of handling this > user. > > [AL] What do you mean by SIP server 1 will contact *its* Diameter > server. Couldn't it contact a Diameter server? There could be more then > one Diameter server no? What I meant is that SIP server 1 will contact a Diameter server in its own realm. I will clarify this sentence. However if have a short discussion in the past on whether there is a requirement for a network to implement several Diameter servers. Coming from a 3GPP view, the draft has been assuming that, for a paricular user, all its data is stored in a single Diameter server. One can have servers configured in redundant fashion, clusters, or similar things (in order to provide redundancy mainly). But all those servers will contain the same data (will be mirrors), so from the functional perspective, there will be only one Diameter server in the network. Now, I would like to understand if this assumption is correct, otherwise we will need to provide the appropriate mechanisms in the draft to make it work in other environments. > > The Diameter server will answer with a Diameter > User-Authorization-Answer (UAA) message (step 3), which will indicate > either a list of capabilities that the SIP server 1 may use to select > an appropriate SIP server (SIP server 2) or a SIP or SIPS URI > pointing to SIP server 2. > > SIP server 1 will forward the SIP REGISTER request (step 4) to an > appropriate SIP server (SIP server 2). The Diameter client in SIP > server 2 will then request user authentication from the Diameter > server by sending a Diameter Multimedia-Auth-Request (MAR) message > (step 5). > > [AL] Must it be the same Diameter server? Couldnt it be a different one? In this case I believe it should be the same (or a cluster of Diameter servers sharing the same data; I will refer to this as one Diameter server). The issue is than in step 5 the second SIP server will inform the Diameter server that such second SIP server is serving the user. Consequently, further Diameter requrests (such as UAR in step 10) or the LIR command (step 2 in Figure 2) will return in the response routing information, that is, the address of SIP server 2. This point is of vital importance for the whole system. If there are several Diameter servers (with a discongruent view of the data, such us serving SIP server or user profile), we will not achieve the desired functionality. > > This request will also serve to make the Diameter server > aware of the SIP or SIPS URI of the SIP server 2, so as to return > subsequent requests of the same user to the same SIP server 2. > > [AL] So what you are saying here is that you inform the Diameter server > of the SIP Server selected by SIP1. Correct. In doing so, the second SIP server "registers" itself in the Diameter server. > > [AL] What subsequent requests? Why wouldnt subsequent commands go > directly to SIP2? I will explain this with the help of figure 4. Figure 4 is an example of a user calling sip:miguel.a.garcia@ericsson.com. The SIP INVITE will arrive to any of the multiple SIP server 1. This is done by using the procedures in RFC 3263 (Locating SIP servers). This RFC makes usage of DNS to find "entry points" or "edge" SIP servers. So the INVITE in step 1 of Figure 4 will arrive to an edge SIP server in ericsson.com. This SIP server does not know the address of the SIP server that is triggering or providing services to me, so SIP server 1 sends the LIR command to a Diameter server in the ericsson.com real (step 2 in figure 4). LIA will return the address of the SIP server allocated to me, that may be something like sip:server33.ericsson.com (in the example this will correspond to SIP server 2). What I wanted to say is that my SIP URI will be in the format of user@domain rather than user@host.domain, so in general other SIP requests will ***not*** be addressed to sip:miguel.a.garcia@server33.ericsson.com but to sip:miguel.a.garcia@ericsson.com instead. So those subsequent requests need the routing information from the Diameter server, in order for the SIP request to reach the appropriate SIP server. > > [AL] Also if you have multiple Diameter servers one used by SIP1 the > other used by SIP2 will this work? It would only work if the state > (which SIP server) can be shared by both Diameter servers. Alternatively > it would work if Diameter serving SIP1 returns SIP2 again. Yes, this was part of the discussion above. I think the assumption is that there is a single point of data storage, so that even if there are multiple servers, they are just mirrors, as they are sourcing the same data. > > The Diameter server will respond with a Diameter Multimedia-Auth-Answer > (MAA) message (step 6) with Result-Code AVP set to the value > DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a > challenge, which the SIP server 2 will use to map into the > WWW-authentication header in the SIP 401 (Unauthorized) response > (step 7), which is sent back to the SIP server 1 and then to the SIP > UAC (step 8). > > [AL] Seems to me that if SIP1 kept state there would be fewer messages. > > When the SIP server 1 receives a next SIP REGISTER request containing > the user credentials (step 9), as there SIP server 1 does not need to > keep a state (even there is not guarantee the SIP request to arrive > to the same SIP server 1), the Diameter client in SIP server 1 will > contact again the Diameter server by sending a Diameter UAR message > (step 10) to determine the SIP server allocated to the user. The > Diameter server will send the SIP or SIPS URI of SIP server 2 in a > Diameter UAA message (step 11). > > [AL] The above par. in paritucal the first sentence needs to be cleaned > up. The first sentence is almost the entire paragraph ;-) OK > > SIP server 1 will then forward the SIP REGISTER request to SIP server > 2 (step 12). SIP server 2 will extract the credentials from the SIP > REGISTER request. The Diameter client in SIP server 2 will send those > credentials in a Diameter MAR message (step 13)to the Diameter > server. This message will also enable the Diameter server to identify > > > > Garcia-Martin, et al. Expires December 15, 2003 [Page 7] > > Internet-Draft Diameter Multimedia application June 2003 > > > the URI of SIP server 2, so as to return subsequent requests to the > same SIP server 2. At this point, the Diameter server will be able to > authenticate the user, and upon success, will return a Diameter MAA > message (step 14) with the AVP Result-Code set to the value > DIAMETER_SUCCESS. The Diameter MAA message will also include the user > profile information, which the SIP server 2 will use to give service > to the user. > > [AL] I thought Diameter already remembered the URI of SIP server 2 in > the exchange that took place in Step 5? Yes, your statement is correct. Althoug the MAR command will contain the SIP-Server AVP, it does not serve the purpose of storing the SIP server 2 URI in the Diameter server. > > SIP server 2 will then generate a SIP 200 (OK) response (step 15) > which is forwarded to SIP server 1 and eventually to the SIP UAC > (step 16). > > [AL] How does Diameter Server know that the second UAR in (step 10) is > associated with the same session as the one in MAR/MAA in (step 6)? > What happens if the UAC is involved in multiple simultaneous operations > some of which would be routed to different SIP servers? > Both UAR and MAR commands include a mandatory SIP-Public-User-Identity (soon to be renamed as SIP-AOR, Address of Record). This is the identity of the user (e.g., sip:miguel.a.garcia@ericsson.com), and in this case, the identity under registration. A SIP User Agent can only have exactly one ongoing registration for a determined SIP Address of Record. This is an excerpt for RFC 3261 that details this case: "UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out." As a conclusion, for the REGISTER request the SIP AOR is more than enough for the Diameter server to correlate UAR and MAR. If we need to extend UAR and MAR to other cases different than REGISTER requests (very likely to happen in the future), then we will need to put a mechanism to facilitate correlation (this might be as simple as including new AVPs for the so-called "tags" in the From and To headers in SIP, and the Call-ID header. But this is not required for the time being. > > 3.2 SIP server authenticates the user > > [AL] Very little difference between this scenario and the one above. I > found it uncessary to re-read steps 1 to 12 again. Suggest that you > truncate this section and talk about the salient differences so we dont > have to re-read. Yes, we actually got other similar comments to this section, indicating that it was difficult to understand the real meaning and the difference, so certainly a rework is needed. > > An operator with a large base of installed SIP servers may wish to > minimize the impact of modifying SIP servers to interact with > Diameter servers. This can be achieved by allowing SIP servers to > retain the functionality of authentication, rather than centralizing > this capability in a Diameter server. However, it should be noted > that this mode will not leverage the extensive array of > authentication and authorization services which will already be > present regardless in Diameter servers. > > [AL] I think you want to say an *existing* installed based. Because new > deployements would probably not have the SIP server do the > authentication for the reasons you mention. ok > > ............. > > When the SIP server 1 receives a next SIP REGISTER request containing > the user credentials (step 9), as the SIP server 1 does not need to > keep a state (even there is no guarantee that the SIP request arrives > to the same SIP server 1), the Diameter client in SIP server 1 will > contact again the Diameter server by sending a Diameter UAR message > (step 10) to determine the SIP server allocated to the user. The > Diameter server will send the SIP or SIPS URI of SIP server 2 in a > Diameter UAA message (step 11). > > [AL] Change "When the SIP server 1" to: "When SIP server 1" above. ok > > > SIP server 1 will then forward the SIP REGISTER request to SIP server > 2 (step 12). SIP server 2 will validate the credentials, and will > send a Diameter Server-Assignment-Request (SAR) message (step 13) > requesting the Diameter server to store the SIP or SIPS URI of the > SIP server that is currently serving the user. The Diameter SAR > message also serves the purpose to request the Diameter server to > send the user profile to the SIP server. The Diameter server will > respond with a Diameter Server-Assignment-Answer (SAA) message (step > 14). If the Result-Code AVP value does not inform about an error, the > User-Data AVP will contain the information that SIP server 2 needs in > order to provide a service to the user. > > The SIP server 2 will generate then a SIP 200 (OK) response (step 15) > that will be forwarded to SIP server 1 and eventually to the SIP UAC > (step 16). > > [AL] Change "The SIP server 2 will generate then a" to "SIP server 2 > generates a" above. ok > > 3.3 Session attempt > > Figure 4 shows the scenario where the SIP server 1 receives a SIP > INVITE request (step 1). The SIP server 1 needs to find the address > of the SIP server 2, which is serving the addressed UA. Therefore, > the Diameter client in SIP server 1 sends Diameter > Location-Info-Request (LIR) message (step 2) to the Diameter server. > The Diameter server responds with a Diameter Location-Info-Answer > (LIA) message (step 3) that contains the SIP or SIPS URI of the SIP > server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2 > (step 4). SIP server 2 will eventually forward the SIP INVITE to the > appropriate UAS (step 5). > > [AL] Change "where the SIP server 1 receives" to "where SIP server 1 > receives" above. > [AL] Change "The SIP server 1 needs to" to "SIP Server > 1 needs to" ok > > +--------+ +--------+ +--------+ > | SIP | |Diameter| | SIP | > |server 1| | server | |server 2| > +--------+ +--------+ +--------+ > | | | > 1. SIP INVITE | | | > > > > Garcia-Martin, et al. Expires December 15, 2003 [Page 10] > > Internet-Draft Diameter Multimedia application June 2003 > > > -------------->| 2. LIR | | > |------------------>| | > | 3. LIA | | > |<------------------| | > | 4. SIP INVITE | > |-------------------------------------->| > | | | 5. SIP INVITE > | | |--------------> > | | | > | | | > > Figure 4 > > Although the example shows the connection between a SIP INVITE > request and the Diameter LIR message, any other SIP request (such as > SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message. > > [AL] So from the above par. I get that a SIP REGISTER will generate a > Diameter LIR message. Is that true? Obviously not. The text should read "any other SIP request except REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message". > > 3.4 Update of the user profile > > The Diameter Multimedia application provides a mechanism for a > Diameter server to asynchronously download a user profile to a SIP > server whenever there is an update of such user profile. It must be > noted that the Diameter server also attaches the user profile in the > Diameter Server-Assignment-Request (SAR) message. Although this is > valid for most of the daily situations, it may happen that the > administrator decides to update or modify the user profile for a > particular user, due to, e.g., new services made available to the > user. This may involve a human intervention in the Diameter server or > some mechanism outside the scope of this specification. In this > situation, the Diameter server is able to push the new user profile > into the SIP server allocated to the user. > > [AL] Change "This may involve a human intervention in the Diameter > server or some mechanism outside the scope of this specification" to > "This may involve mechanisms outside the scope of this specification > such as human intervention in the Diameter server" ok > > [AL] Change "The scenario is described in Figure 5" to "The scenario is > illustrated in Figure 5" below. ok > > The scenario is described in Figure 5. In case the user profile > changes, the Diameter server will send a Diameter > Push-Profile-Request (PPR) message (step 1) to the Diameter client in > the SIP server allocated to that user (SIP server 2 in the examples). > The Diameter PPR message will contain a SIP-User-Data AVP, a > User-Name AVP and zero or more SIP-Public-User-Identity AVPs. The > presence of the User-Name AVP without any SIP-Public-User-Identity > AVPs serves to indicate that the entire user profile (included in the > SIP-User-Data AVP) associated with the User-Name AVP is updated. A > Diameter PPR message with a User-Name AVP and one or more > SIP-Public-User-Identity AVPs serves to indicate that the user > profile data associated with each of the SIP-Public-User-Identity > AVPs is updated. The Diameter client in SIP server 2 will acknowledge > the Diameter PPR message by sending a Diameter Push-Profile-Answer > (PPA) message (step 2) to the Diameter server. > > ......... > > 3.5 Registration termination > > Termination of a user registration can be achieved by either of the > following three mechanisms: > > [AL] I am having trouble with this because i dont know where or when > Auth-Session-State AVP is delivered. The Auth-Session-State AVP is part of the Diameter base specification. All the commands in this application include an Auth-Session-State. > > In the event that NO_STATE_MAINTAINED (i.e., No Diameter user > session-id is maintained) has been indicated in a prior > Auth-Session-State AVP, termination is handled with a Diameter > Session-Termination-Request (STR) message (if it is initiated by the > Diameter Client/SIP Proxy) or with a Diameter > Registration-Termination-Request (RTR) message (if it is initiated by > the Diameter server). > > On the other hand, if STATE_MAINTAINED has been indicated in a prior > Auth-Session-State AVP, the use of Diameter > Session-Termination-Request (STR) and Abort-Session-Request (ASR) > messages as defined in the base Diameter specification [2] are used > to terminate a user registration. > > Last, if the Diameter server receives a Diameter > Server-Assignment-Request (SAR) message that contains a > SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the > Diameter server will proceed with the deregistration of the user. > > [AL] Move the stuff below to the start of the section. > > Reasons for terminating a user registration include: > > o Expiration of the SIP registration timer in the SIP server. > > o Administrative action taken at the Diameter server. > > o The SIP UAC generates a SIP REGISTER request setting the Expires > header field value to zero or the expires parameter in the Contact > header field to zero (e.g., user initiated deregistration). > > ok > > 4. Advertising Application Support > > Diameter nodes conforming to this specification MAY advertise its > support by including the Auth-Application-Id AVP in the > Capabilities-Exchange-Request and Capabilities-Exchange-Answer > commands, according to the Diameter base protocol [2]. > > Avi Lior > Bridgewater Systems Corporation > Phone : (613) 591-9104 x6417 or (613) 591-6655 > Fax : (613) 591-6656 > E-mail : avi@bridgewatersystems.com > www.bridgewatersystems.com Once more, thanks a lot for your comments. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Thu Aug 7 10:35:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16898 for ; Thu, 7 Aug 2003 10:35:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9E38912CB; Thu, 7 Aug 2003 10:31:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D25C912CD; Thu, 7 Aug 2003 10:31:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 609EA912CB for ; Thu, 7 Aug 2003 10:31:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BBE25DDA6; Thu, 7 Aug 2003 10:31:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 6A8955DDA4 for ; Thu, 7 Aug 2003 10:31:31 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h77EVTJ07152 for ; Thu, 7 Aug 2003 17:31:30 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 7 Aug 2003 17:31:29 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 17:31:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: TEST Date: Thu, 7 Aug 2003 17:31:29 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C7E19@esebe016.ntc.nokia.com> Thread-Topic: TEST Thread-Index: AcNc8JbH0HRDV8DnTY+MG6FYnPp8Cw== From: To: X-OriginalArrivalTime: 07 Aug 2003 14:31:29.0595 (UTC) FILETIME=[973FC0B0:01C35CF0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Just trying my mail address is working since I sent a mail long time ago and didn't appear yet. From owner-aaa-wg@merit.edu Fri Aug 8 11:11:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14625 for ; Fri, 8 Aug 2003 11:11:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B073991293; Fri, 8 Aug 2003 11:11:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FFEB912BA; Fri, 8 Aug 2003 11:11:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8658891293 for ; Fri, 8 Aug 2003 11:11:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AF995DDC7; Fri, 8 Aug 2003 11:11:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id BBE395DDBD for ; Fri, 8 Aug 2003 11:11:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h78Eg2C02866 for ; Fri, 8 Aug 2003 07:42:02 -0700 Date: Fri, 8 Aug 2003 07:42:02 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Marco's document on graceful service termination In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D015C7E10@esebe016.ntc.nokia.com> Message-ID: References: <142DC466081D9B409AAD1DDCA4B21E1D015C7E10@esebe016.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Since the AAA WG mailing list is not accepting file enclosures now (a protection against viruses I suppose), I've made Marco's proposal in graceful service termination of Diameter Credit Control available for download here: http://www.drizzle.com/~aboba/AAA/diamcca-gst.rtf From owner-aaa-wg@merit.edu Fri Aug 8 12:58:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17513 for ; Fri, 8 Aug 2003 12:58:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77B15912BA; Fri, 8 Aug 2003 12:58:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43358912C8; Fri, 8 Aug 2003 12:58:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A963912BA for ; Fri, 8 Aug 2003 12:58:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3A7E5DDD9; Fri, 8 Aug 2003 12:58:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 3738D5DDAB for ; Fri, 8 Aug 2003 12:58:11 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h78Gw5B18813 for ; Fri, 8 Aug 2003 19:58:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Aug 2003 19:58:05 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 8 Aug 2003 19:58:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Graceful Service Termination for the Diameter CC Application Date: Fri, 8 Aug 2003 19:58:04 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0250@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: Marco's document on graceful service termination Thread-Index: AcNdv2UKUDgQA09LQueaRm61xQwdZQADSfkw From: To: , X-OriginalArrivalTime: 08 Aug 2003 16:58:04.0908 (UTC) FILETIME=[3C13C2C0:01C35DCE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Thankyou very much Bernard. I would like to give some background about this proposal. In the issue 408 against the Diameter Credit Control Application, that = was the Avi Lior's review of the document, there is at least one comment = that we didn't address in the current IETF draft = (draft-ietf-aaa-diameter-cc-00): "Redirect In many instances in the text the action to take when a user resources are no longer available is to terminate the session. That is one possible action, the other possible action is to restrict access (or direct the user) to a portal where they can recharge their account etc..." We have been working on a solution to enable three different actions = upon user's resources are no longer available. The solution consists of = an enhancement to the current feature of gracefully disconnect the end = user (i.e. the Final-Unit-Indication AVP is used for that purpose)in = order to enable: TERMINATE, REDIRECT and RESTRICT_ACCESS. I think this was also presented by John Loughney in the last IETF = meeting in Vienna. The solution is called Graceful Service Termination, we have collected = the changes in the proposal that Bernard kindly made available to = everybody to facilitate the review. If there is no objections we would = introduce this solution in the version 01 of the draft. Since in the solution the CC server may also use the server-initiated = re-authorization and in the Diameter base it is stated that = authorization applications MUST state whether server-initiated = authorization is supported, we also added a section "Server-Initiated = Credit Re-Authorization". Of course comments and suggestions are more than welcome. Regards Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 08 August, 2003 17:42 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Re: Marco's document on graceful service=20 > termination >=20 >=20 > Since the AAA WG mailing list is not accepting file enclosures now (a > protection against viruses I suppose), I've made Marco's proposal in > graceful service termination of Diameter Credit Control available for > download here: >=20 > http://www.drizzle.com/~aboba/AAA/diamcca-gst.rtf >=20 >=20 >=20 >=20 From owner-aaa-wg@merit.edu Fri Aug 8 16:38:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25193 for ; Fri, 8 Aug 2003 16:38:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E6BF91205; Fri, 8 Aug 2003 16:38:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A65F91206; Fri, 8 Aug 2003 16:38:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAD5491205 for ; Fri, 8 Aug 2003 16:38:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C62D35DDC4; Fri, 8 Aug 2003 16:38:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 6788E5DDBE for ; Fri, 8 Aug 2003 16:38:24 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2656.59) id ; Fri, 8 Aug 2003 16:38:23 -0400 Message-ID: From: Avi Lior To: "'Miguel A. Garcia'" , Avi Lior Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: Avi Comments: draft-belinchon-aaa-diameter-mm-app-01.txt Date: Fri, 8 Aug 2003 16:38:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk It seems to me that the major issue in my first review piece was the issue relating to deployment of Diameter servers. A single Diameter Server in your document is really a cluster of Diameter Servers sharing a common State Store. This is great. You should perhaps say that somewhere in your document and be done with this aspect of it. The issue still remains however. My gut feel says that having all your subscribers end up at a single cluster sharing the a common State Store is restrictive and will not scale. Think about a carrier with 30 million subscribers plus a bunch of visiting subscribers. Is it worthwhile to address how this will be done? I think yes not sure what others think. Others, what do you think? There are several ways to solve this problem. You can actually store the state in the messages (much the same way that RADIUS uses the State attribute etc). Not sure what is the best solution for this. Related to this I think is the notion of portability and mobility. I suspect that if one designs this for a 3GPP network one would get different constraints then if one were to consider a 3GPP2 network. I think you have to look at least to these two networks inorder to come up with a solution. There maybe other scenarios. More comments inline. > > However if have a short discussion in the past on whether > there is a requirement for a network to implement several > Diameter servers. Coming from a 3GPP view, the draft has been > assuming that, for a paricular user, all its data is stored > in a single Diameter server. One can have servers configured > in redundant fashion, clusters, or similar things (in order > to provide redundancy mainly). But all those servers will > contain the same data (will be mirrors), so from the > functional perspective, there will be only one Diameter > server in the network. > > Now, I would like to understand if this assumption is > correct, otherwise we will need to provide the appropriate > mechanisms in the draft to make it work in other environments. My opinion is yes. > In this case I believe it should be the same (or a cluster of > Diameter servers sharing the same data; I will refer to this > as one Diameter server). The issue is than in step 5 the > second SIP server will inform the Diameter server that such > second SIP server is serving the user. Consequently, further > Diameter requrests (such as UAR in step 10) or the LIR > command (step 2 in Figure 2) will return in the response > routing information, that is, the address of SIP server 2. > > This point is of vital importance for the whole system. If > there are several Diameter servers (with a discongruent view > of the data, such us serving SIP server or user profile), we > will not achieve the desired functionality. > > > > > > This request will also serve to make the Diameter server > > aware of the SIP or SIPS URI of the SIP server 2, so as to return > > subsequent requests of the same user to the same SIP server 2. > > > > [AL] So what you are saying here is that you inform the Diameter > > server of the SIP Server selected by SIP1. > > Correct. In doing so, the second SIP server "registers" > itself in the Diameter server. > > > > > [AL] What subsequent requests? Why wouldnt subsequent commands go > > directly to SIP2? > > I will explain this with the help of figure 4. Figure 4 is an > example of a user calling sip:miguel.a.garcia@ericsson.com. > The SIP INVITE will arrive to any of the multiple SIP server > 1. This is done by using the procedures in RFC 3263 (Locating > SIP servers). This RFC makes usage of DNS to find "entry > points" or "edge" SIP servers. > > So the INVITE in step 1 of Figure 4 will arrive to an edge > SIP server in ericsson.com. This SIP server does not know the > address of the SIP server that is triggering or providing > services to me, so SIP server 1 sends the LIR command to a > Diameter server in the ericsson.com real (step 2 in figure > 4). LIA will return the address of the SIP server allocated > to me, that may be something like sip:server33.ericsson.com > (in the example this will correspond to SIP server 2). > What I wanted to say is that my SIP URI will be in the format > of user@domain rather than user@host.domain, so in general > other SIP requests will ***not*** be addressed to > sip:miguel.a.garcia@server33.ericsson.com but to > sip:miguel.a.garcia@ericsson.com instead. So those subsequent > requests need the routing information from the Diameter server, in > order for the SIP request to reach the appropriate SIP server. Okay. I understand. But doesn't the scale of this worry you? 30 million subscriber's state being maintained in real-time. Is there a way to make this more manageable. Is it an issue? From owner-aaa-wg@merit.edu Mon Aug 11 01:06:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24149 for ; Mon, 11 Aug 2003 01:06:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6BA1491203; Mon, 11 Aug 2003 01:06:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 396E891206; Mon, 11 Aug 2003 01:06:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDE6191203 for ; Mon, 11 Aug 2003 01:06:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3F705DDB4; Mon, 11 Aug 2003 01:06:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 1DBD05DDB3 for ; Mon, 11 Aug 2003 01:06:00 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7B55pgM017196; Mon, 11 Aug 2003 07:05:51 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL8Y7XR4; Mon, 11 Aug 2003 07:07:36 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.128]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h7B55nSZ015201; Mon, 11 Aug 2003 08:05:50 +0300 (EET DST) Message-ID: <3F37242D.2040603@ericsson.com> Date: Mon, 11 Aug 2003 08:05:49 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, es MIME-Version: 1.0 To: Avi Lior Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: Avi Comments: draft-belinchon-aaa-diameter-mm-app-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Avi: Thanks for the comments. Answers inline... /Miguel Avi Lior wrote: > It seems to me that the major issue in my first review piece was the issue > relating to deployment of Diameter servers. > > A single Diameter Server in your document is really a cluster of Diameter > Servers sharing a common State Store. This is great. You should perhaps > say that somewhere in your document and be done with this aspect of it. I think this is a fair proposal. I will add some discussion aligned to this conclusion. At this stage, I don't think we need an Applicability Statement section, but I would like to receive guidelines from the charis or the ADs. > The issue still remains however. My gut feel says that having all your > subscribers end up at a single cluster sharing the a common State Store is > restrictive and will not scale. Think about a carrier with 30 million > subscribers plus a bunch of visiting subscribers. > > Is it worthwhile to address how this will be done? I think yes not sure > what others think. Others, what do you think? Not being "others", but... I agree that the solution will not scale as it is now. What I can do is to document the solution that 3GPP developped to solve this problem. 3GPP has added a new entity to its architecture, a Diameter Redirect Agent (in 3GPP parliance, this is known as the Subscription Locator Function, SLF). To make a long story short: SIP servers query the SLF. The SLF, operating in redirect mode returns the address of the Diameter server where the relevant information for a particular user is stored. Needless to say, the SLF contains (or is able to access) a simple database that binds users with the Diameter Server that stores the data for that user. Probably there might be other solutions to this problem, and we could document them if it is required. > > There are several ways to solve this problem. You can actually store the > state in the messages (much the same way that RADIUS uses the State > attribute etc). Not sure what is the best solution for this. Due to the multiplicity of SIP servers in the network, I don't know how storing a state in the message will help to solve the problem. The problem to solve is: given the identity of a particular user, any Diameter Client (SIP server) has to be able to find the Diameter Server that is storing the data for that particular user. > > Related to this I think is the notion of portability and mobility. I > suspect that if one designs this for a 3GPP network one would get different > constraints then if one were to consider a 3GPP2 network. I think you have > to look at least to these two networks inorder to come up with a solution. > There maybe other scenarios. At least I am aware of the 3GPP solution, and it seems to work. And as I said before, I would happy to document other solutions as well. Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Mon Aug 11 02:38:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08160 for ; Mon, 11 Aug 2003 02:38:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F064591207; Mon, 11 Aug 2003 02:38:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C030E91208; Mon, 11 Aug 2003 02:38:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D483091207 for ; Mon, 11 Aug 2003 02:38:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA5245DDBF; Mon, 11 Aug 2003 02:38:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 24F7F5DDBD for ; Mon, 11 Aug 2003 02:38:29 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7B68wd25749 for ; Sun, 10 Aug 2003 23:08:58 -0700 Date: Sun, 10 Aug 2003 23:08:58 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Minutes and slides from AAA WG at IETF 57 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Minutes and slides from the IETF 57 AAA WG meeting are available here: http://www.drizzle.com/~aboba/IETF57/AAA/ From owner-aaa-wg@merit.edu Mon Aug 11 05:53:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11702 for ; Mon, 11 Aug 2003 05:53:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 477C291206; Mon, 11 Aug 2003 05:53:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B30F91208; Mon, 11 Aug 2003 05:53:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19DBE91206 for ; Mon, 11 Aug 2003 05:52:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E70EE5DDB3; Mon, 11 Aug 2003 05:52:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 397625DDB0 for ; Mon, 11 Aug 2003 05:52:58 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7B9qngM021192; Mon, 11 Aug 2003 11:52:49 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QL9KJBTF; Mon, 11 Aug 2003 11:52:49 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.128]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h7B9qnSZ001779; Mon, 11 Aug 2003 12:52:49 +0300 (EET DST) Message-ID: <3F376770.9090409@ericsson.com> Date: Mon, 11 Aug 2003 12:52:48 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, es MIME-Version: 1.0 To: Avi Lior Cc: "'maria.c.belinchon@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Avi Comments (second installment): draft-belinchon-aaa- diameter-mm-app-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi: Thanks a lot for your second round of comments. Some answers and discussion inline. /Miguel Avi Lior wrote: > This is my second installment of comments: > > A general comment is the issue of user-name. As indicated in the following > comments the text is based on the fact that username is know but as you > point out it is sometimes not known. You need to address this issue for this > to be a general SIP solution. > Yes, I am aware of this situation. We didn't have time to change this issue before the deadline, but next version of the draft will work to solve this issue. > > 5.1 User-Authorization-Request (UAR) Command > > ................... > > The user name used for authentication of the user is conveyed in a > User-Name AVP (imported from the Diameter baseprotocol [2]). The > location of the authentication user name in the SIP REGISTER request > varies depending on the authentication mechanism. When the > authentication mechanism is HTTP Digest as defined in RFC 2617 [4], > the authentication user name is found in the "username" directive of > the SIP Authorization header field value. > > [AL] Sounds like there are other cases -- that is not a HTTP Digest. > What are they or are you just giving an example? > HTTP Digest is just one of the mechanisms used in SIP for authenticating users. Other mechanisms are possible, but optional for implementation, and they are: - based on the presence of a P-Asserted-Identity (pre-authenticated) - S/MIME bodies - TLS - perhaps some other (there is work on cryptographical identities in SIP). The SIP specification mandates to implement HTTP Digest in all User Agents (end points), that's the reason why I provided a hint on how to find out the username when HTTP Digest is the mechanism. > The SIP or SIPS URI to be registered is conveyed in the > SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or > SIPS URI is found in the To header field value of the SIP REGISTER > request that triggered the Diameter UAR message. > > The SIP-Visited-Network-Identifier AVP indicates the network that is > providing SIP services (e.g., SIP proxy functionality or any other > kind of services) to the SIP User Agent. > > Message Format > ::= < Diameter Header: aaa, REQ, PXY > > < Session-ID > > < Auth-Application-Id > > { Auth-Session-State } > { Origin-Host } > { Origin-Realm } > [ Destination-Host ] > { Destination-Realm } > { User-Name } > { SIP-Public-User-Identity } > [ SIP-Visited-Network-Identifier ] > [ SIP-User-Authorization-Type ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > [AL] I think you have an error with the Destination-Host the bracket > should either be '{' or it should be moved down the list. I think Destination-Host should be mandatory, because the Diameter Client must, at this stage, be aware of the Diameter Server the request will be sent. But I will check if there is a case where it is optional (I doubt it). > > OPEN ISSUE: according to the above description, the User-Name AVP > is mandatory in the UAR message. This AVP is always available in a > 3GPP environment, because 3GPP has mandated the private user > identity to be present in every REGISTER request. However, in a > general SIP environment, a SIP client will not insert any identity > without being challenged. Therefore, the User-Name AVP may not be > present. Action: investigate if this AVP can be set to optional. > > [AL] I think this is a serious issue for this document since it seems to > me that you depend very heavily on the existance of the User-Name > attribute. To be a general solution which you would have to be in the > AAA-WG, I would think you would have to allow for this to be optional. I > dont see any other way. I agree with you. That requires substantial changes to the document, add more example cases, etc. That's the main reason why we didn't have time to cover it before the last deadline. > > > 5.2 User-Authorization-Answer (UAA) Command > > ................... > > When the authorization procedure succeeds, the Diameter server > constructs a User-Authorization-Answer (UAA) message that MUST > include either the address of the SIP server already assigned to the > user or the capabilities needed by the SIP server (Diameter client) > to select another SIP server for the user. This section will be based > on the required capabilities of the SIP server to trigger and execute > services for the user. The former option is used when the Diameter > server is aware of an allocated SIP server to the user, whereas the > latter is used when the Diameter server is not aware of an allocated > SIP server, letting the SIP server to choose, if needed, an > appropriate SIP server according to the required capabilities. > > [AL] The wording of the above par. is awakward. What do you mean by > "This section will be based on the required capabilities...."? Yes, the explanation is not deep enough. One of the functionalities allocated to SIP server 1 (the one at the edge), is the ability to select an appropriate SIP server that will execute and trigger services to the user (i.e., to select SIP server 2). It is expected that different users will have different services, and that may require different capabilities of the SIP server. For instance, a user may require that his/her allocated SIP server is able to execute Java applets. So SIP server 1 is able to select an appropriate SIP server 2, among all those SIP servers in the network that fulfill the required capabilities. So the functionality that we provide is: - The Diameter server stores the capabilites required for the SIP server that will be serving the user. - The SIP server may select an appropriate SIP server that fulfills the requirements (capabilities). Of course, we don't enter into the arena of standardizing these capabilities, their semantics and so on. The Grouped AVP SIP-Server-Capabilities conveys that information, but basically as a collection of integers that identified capabilities. As this is an intradomain functionality, the administrator will define the semantics of "Capability 1" in his network. For instance, in a network, "Capability 1" may convey the semantics "the SIP server has to support Java applets", whereas in another network it may mean "the SIP server has to support the Call Processing Language". We don't enter into discussion how does SIP server 1 selects the server. That issue is out of the scope of the standardisation of the Diameter application for SIP. > > At reception of the Diameter UAR message, the Diameter server MUST > verify the existence of the user in the realm, i.e., the User-Name > AVP value is a valid user within that realm. If the Diameter server > does not recognize the user name received in the User-Name AVP, the > Diameter server MUST build a Diameter User-Authorization-Answer (UAA) > message and MUST set the Result-Code AVP to > DIAMETER_ERROR_USER_UNKNOWN. > > [AL] Change "MUST build a" to "MUST reply with a" ok > > [AL] Is the above paragraph true? Is the user-name the only thing that > can be used to allow the process to continue? This is not really where > the authentication happens right? So other attributes could be used to > verify whether the process should go on? Especially since the username > could be optional. Well, the paragraph will substiantially change when we consider the case when the User Name is unavailable. IMHO the User-Name is just used for authentication/authorization. So this first discrimination on whether the user exists or not should be based on the SIP-Public-User-Identity AVP (that is always available in SIP). > > Then Diameter server MUST authorize that User-Name AVP value is able > to register the SIP or SIPS URI included in the > SIP-Public-User-Identity AVP. If this authorization fails, the > Diameter server must set the Result-Code AVP to > DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter > User-Authorization-Answer (UAA) message. > > [AL] Change "Then Diameter server" to "Next, the Diameter server" ok > > [AL] Again here you are talking about a specific 3GPP behavior no? > user-name can be optional right? Right. So this case is still valid *when the User-Name AVP is valid*, after authentication is requested. We need to add the case when the User-Name is not present in the request and the Diameter server requests authentication. > > If there is a SIP-Visited-Network-Identifier AVP in the Diameter UAR > message, and the SIP-User-Authorization-Type AVP value received in > the Diameter UAR message is set to REGISTRATION or > REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify > whether the user is allowed to roam into the network specified in the > SIP-Visited-Network-Identifier AVP in the Diameter UAR message. If > the user is not allowed to roam into such network, the Diameter AAA > server MUST set the Result-Code AVP value in the Diameter UAA message > to DIAMETER_ERROR_ROAMING_NOT_ALLOWED. > > [AL] Can't i make the decision whether the user is allowed to roam based > only on the SIP-Visited-Network-Identifier? If i dont have a roaming > agreement with the network why should i bother looking up a user? Its > probably faster to do that. SImilar to RADIUS Call Check functionality. > Yes, perhaps you are right. The number of roaming agreements with other networks will be significantly smaller than the number of users, so perhaps the order of checking should be inverted. We will do it. > > ....................... > > In case that the SIP-User-Authorization-Type AVP value received in > the Diameter UAR message is set to REGISTRATION then: > > o If the Diameter server is not aware of any previous registration > of the user name (including registrations of other public user > identities allocated to the same user name), then the Diameter > server does not know of any SIP server allocated to the user. In > this case the Diameter server MUST set the Result-Code AVP value > to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and > the Diameter server SHOULD include the required SIP server > capabilities in the SIP-Server-Capabilities AVP value in the > Diameter UAA message. The SIP-Server-Capabilities AVP will assist > the Diameter client (SIP server) to select an appropriate SIP > server for the user, according to the required capabilities. > > [AL] what if the diameter server just wants to assign a specific SIP > server could it not set the SIP-Server-Name AVP? This seems like a new case that is very easy to add it. So we will write some text with the following ideas: - If the Diameter server is not aware of any previous registration, then there are two options: a) The Diameter server allocates a SIP server to the user (so it will include a SIP-Server-Name AVP and whatever Result-Code). b) The Diameter server delegates the allocation of the SIP server to the Diameter client (this is the text that is currently written). > > [AL] There seems to be some wording problem between the above and below > par. Above you seem to say that the Diameter Server does not know of any > SIP server allocated to the user If the Diameter server is not aware of > any previous registration of the user name. Yet in the paragraph below > you say that in some cases, the Diameter server is aware of a previously > assigned SIP server No, there is no wording problem. I will explain why: The previous paragraph discussing the case when the Diameter Server is not aware of any SIP server allocated to the user. You can think of this situation as "when the user switches on his/her mobile phone". During the registration period, the allocated SIP server will "save" its URI in the Diameter server (Command MAR, SIP-Server-Name AVP). After that, the user will re-register oftely, or just register other identities allocated to him/her. In all this cases, the UAA command will go through the flow described below (when the Diameter server is aware of a previously assigned SIP server for the same or different public user identity allocated to the same user name) > > > o In some cases, the Diameter server is aware of a previously > assigned SIP server for the same or different public user identity > allocated to the same user name. In these cases, re-assignment of > a new SIP server may or may not be needed, depending on the > capabilities of the SIP server. The Diameter server MUST always > include the allocated SIP server URI in the SIP-Server-Name AVP of > the UAA message. If the Diameter server does not return the SIP > capabilities, the Diameter server MUST set the Result-Code AVP in > the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION. > Otherwise, if the Diameter server includes a > SIP-Server-Capabilities AVP then the Diameter server MUST set the > Result-Code AVP in the Diameter UAA message to > DIAMETER_SERVER_SELECTION. The Diameter client will then > determine, based on the received information, whether it needs to > select a new SIP server or not. > > In case that the SIP-User-Authorization-Type AVP value received in > the Diameter UAR message is set to REGISTRATION&CAPABILITIES then > Diameter Server MUST return the list of capabilities in the > SIP-Server-Capabilities AVP value of the Diameter UAA message, it > MUST set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return a > SIP-Server-Name AVP. The SIP-Server-Capabilities AVP enables the SIP > server (Diameter Client) to select another appropriate SIP server for > invoking and executing services for the user, depending on the > required capabilities. The Diameter server MAY leave the list of > capabilities empty to indicate that any SIP proxy can be selected. > > [AL] What if the Diameter server does not want to allow the Client to > change? What would the response be? Mmmmm... I think you have a point here... I need to ask the rest of the authors of the draft, but my first take on this is that the SIP server is not able to distinguish between REGISTRATION and REGISTRATION&CAPABILITIES. IMHO there should be only one value o fthe SIP-User-Authorization-Type: REGISTRATION. Then the Diameter server either returns the capabilities to do a selection or returns the SIP-Server-Name AVP to direct to another server. As a conclusion, this issue needs further inverstigation. > > ............ > > End of section 5.2 > > Avi Lior > Bridgewater Systems Corporation > Phone : (613) 591-9104 x6417 or (613) 591-6655 > Fax : (613) 591-6656 > E-mail : avi@bridgewatersystems.com > www.bridgewatersystems.com Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Tue Aug 12 04:33:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04787 for ; Tue, 12 Aug 2003 04:33:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13A7C91231; Tue, 12 Aug 2003 04:33:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFDDC91232; Tue, 12 Aug 2003 04:33:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7833791231 for ; Tue, 12 Aug 2003 04:33:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E04B5DDBF; Tue, 12 Aug 2003 04:33:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id AB3B85DDB4 for ; Tue, 12 Aug 2003 04:33:36 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7C8XYB21541 for ; Tue, 12 Aug 2003 11:33:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Aug 2003 11:33:34 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 11:33:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 11:33:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: AVP type mismatches in NASREQ-12 Date: Tue, 12 Aug 2003 11:33:32 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C5@esebe023.ntc.nokia.com> Thread-Topic: AVP type mismatches in NASREQ-12 Thread-Index: AcNgrGodhdEhxBn2QG6zZgZaiqtWnA== From: To: X-OriginalArrivalTime: 12 Aug 2003 08:33:33.0732 (UTC) FILETIME=[6AB3DE40:01C360AC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable AVP type mismatches in NASREQ-12 Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 12, 2003 Reference:=20 Document: NASREQ-12 Comment type: T/E Priority: 1 Section: various Rationale/Explanation of issue: When reviewing NASREQ-12, I found a couple of cases where the AVP=20 type specified doesn't match the description of the corresponding=20 RADIUS attribute in RFC 2865/2868/etc.: These two are obviously editorial mistakes: - Framed-IPX-Network should be Unsigned32 instead of UTF8String (it's not UTF-8 or human-readable, and it's always 4 octets) - Tunnel-Client-Auth-Id should be UTF8String instead of Unsigned32 (it's a string, and RFC2868 says it should be UTF-8) These are not that important: - Tunnel-Server-Auth-Id should be UTF8String instead of OctetString (RFC2868 says that it should be UTF-8) - Tunnel-Private-Group-Id should be OctetString instead of UTF8String (RFC2868 says that it can be anything) Best regards, Pasi From owner-aaa-wg@merit.edu Tue Aug 12 04:53:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05464 for ; Tue, 12 Aug 2003 04:53:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9AC391232; Tue, 12 Aug 2003 04:52:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 758F791233; Tue, 12 Aug 2003 04:52:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42A9F91232 for ; Tue, 12 Aug 2003 04:52:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 322115DDAE; Tue, 12 Aug 2003 04:52:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 786EA5DD98 for ; Tue, 12 Aug 2003 04:52:52 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7C8qoP22287 for ; Tue, 12 Aug 2003 11:52:51 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Aug 2003 11:52:50 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 11:52:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 11:52:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Authentication method AVP? Date: Tue, 12 Aug 2003 11:52:47 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB8B@esebe023.ntc.nokia.com> Thread-Topic: Authentication method AVP? Thread-Index: AcNgrxqa74QXMT6zST28FQUxy9cW/g== From: To: X-OriginalArrivalTime: 12 Aug 2003 08:52:48.0088 (UTC) FILETIME=[1AC09D80:01C360AF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Authentication method AVP? Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 12, 2003 Reference:=20 Document: NASREQ-12/EAP Comment type: T Priority: 2 Section: - Rationale/Explanation of issue: Diameter EAP application has Accounting-EAP-Auth-Method AVP=20 that corresponds to the MS-Acct-EAP-Type RADIUS attribute=20 from RFC 2548. In RADIUS, this attribute is used together=20 with MS-Acct-Auth-Type attribute (which has values for PAP,=20 CHAP, EAP, MS-CHAP-1, etc.). Should NASREQ have a corresponding AVP, named perhaps Accounting-Auth-Method? (Note that this is different from Acct-Authentic AVP, which has values for local, RADIUS and=20 Diameter) I guess we could define this AVP in Diameter EAP document=20 if adding this to NASREQ this late would be a problem. Best regards, Pasi From owner-aaa-wg@merit.edu Tue Aug 12 05:20:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06018 for ; Tue, 12 Aug 2003 05:20:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB87791234; Tue, 12 Aug 2003 05:20:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C183291236; Tue, 12 Aug 2003 05:20:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8690891234 for ; Tue, 12 Aug 2003 05:20:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 720275DD9F; Tue, 12 Aug 2003 05:20:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C08435DD99 for ; Tue, 12 Aug 2003 05:20:41 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7C9KaP21676 for ; Tue, 12 Aug 2003 12:20:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Aug 2003 12:20:34 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 12:20:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 12 Aug 2003 12:20:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Minor NASREQ-12 editorial nits Date: Tue, 12 Aug 2003 12:20:30 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB8C@esebe023.ntc.nokia.com> Thread-Topic: Minor NASREQ-12 editorial nits Thread-Index: AcNgsvnxxMkPUoxBQEem9a48Qj10Xw== From: To: X-OriginalArrivalTime: 12 Aug 2003 09:20:32.0855 (UTC) FILETIME=[FB07E670:01C360B2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Minor NASREQ-12 editorial nits Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 12, 2003 Reference:=20 Document: NASREQ-12 Comment type: E Priority: 1 Section: various Rationale/Explanation of issue: - The draft mentions the CMS Application in several places.=20 Since CMS is dead, should these be removed? - Section 3.1: "The type of request is identified through the Auth-Request-Type AVP, and the default mode is both=20 authentication and authorization." The default mode would make more sense if Auth-Request-Type AVP=20 was optional to include. But since it's mandatory, maybe=20 this sentence would be clearer with the second part deleted? - References: - IPv6Addr has been obsoleted by RFC3513 - AAATrans, RADDynAuth, and RADIUSIANA have been published=20 as RFCs (3539, 3576, 3575) - DiamEAP is now at version -02 - The following references are never cited in the document,=20 so they're probably unnecessary: NAI, ExtRADPract, CDM2000,=20 TCPCompress, L2F, ATMP, MSMPPE, UTF-8 - Typos: - Section 4.6: s/the the/the/ - Section 4.6: ".sp"? - Section 4.8: s/(AVP Code 94 is/(AVP Code 94) is/ - Section 6.11: s/proprietarySingleLink/proprietary SingleLink/ - Section 6.12: s/proprietary, SingleLink/proprietary SingleLink/ - Section 7.8: s/QOS/QoS/ (twice) - Section 9.1: s/availible/available/ - Section 9.2: s/reponse/response/ - Section 10.1: extra " in last line of table - The document has lots of extra spaces between words in=20 several places, but the RFC editor will probably=20 take care of them. Best regards, Pasi From owner-aaa-wg@merit.edu Tue Aug 12 06:10:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07344 for ; Tue, 12 Aug 2003 06:10:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BFA191236; Tue, 12 Aug 2003 06:10:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E611591237; Tue, 12 Aug 2003 06:10:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE0C391236 for ; Tue, 12 Aug 2003 06:10:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C68EE5DDAA; Tue, 12 Aug 2003 06:10:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 3FD635DDA9 for ; Tue, 12 Aug 2003 06:10:00 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 96A986A901; Tue, 12 Aug 2003 13:09:43 +0300 (EEST) Message-ID: <3F38BC4E.2080605@kolumbus.fi> Date: Tue, 12 Aug 2003 13:07:10 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Authentication method AVP? References: <052E0C61B69C3741AFA5FE88ACC775A608BB8B@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB8B@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Authentication method AVP? > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: August 12, 2003 > Reference: > Document: NASREQ-12/EAP > Comment type: T > Priority: 2 > Section: - > Rationale/Explanation of issue: > > Diameter EAP application has Accounting-EAP-Auth-Method AVP > that corresponds to the MS-Acct-EAP-Type RADIUS attribute > from RFC 2548. In RADIUS, this attribute is used together > with MS-Acct-Auth-Type attribute (which has values for PAP, > CHAP, EAP, MS-CHAP-1, etc.). > > Should NASREQ have a corresponding AVP, named perhaps > Accounting-Auth-Method? (Note that this is different from Yes. > Acct-Authentic AVP, which has values for local, RADIUS and > Diameter) > > I guess we could define this AVP in Diameter EAP document > if adding this to NASREQ this late would be a problem. I think we should put it in NASREQ. --Jari From owner-aaa-wg@merit.edu Tue Aug 12 10:27:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16299 for ; Tue, 12 Aug 2003 10:27:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53E7F91247; Tue, 12 Aug 2003 10:27:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BBD391248; Tue, 12 Aug 2003 10:27:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4431191247 for ; Tue, 12 Aug 2003 10:27:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E98A5DDBC; Tue, 12 Aug 2003 10:27:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 7F1AE5DDC1 for ; Tue, 12 Aug 2003 10:27:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7CDvUb03447 for ; Tue, 12 Aug 2003 06:57:30 -0700 Date: Tue, 12 Aug 2003 06:57:30 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Updating Issue Status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've gone and updated the AAA Issues list at: http://www.drizzle.com/~aboba/AAA/issues.html In order to clarify which issues are still open, I'd appreciate it if the editors could go over the outstanding issues and let me know which ones have been closed, and if so, in what version of the document. Thanks! From owner-aaa-wg@merit.edu Tue Aug 12 10:38:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17370 for ; Tue, 12 Aug 2003 10:38:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4140E91249; Tue, 12 Aug 2003 10:38:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00CFA9124B; Tue, 12 Aug 2003 10:38:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D273991249 for ; Tue, 12 Aug 2003 10:38:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD9565DD9F; Tue, 12 Aug 2003 10:38:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E43CB5DD9B for ; Tue, 12 Aug 2003 10:38:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7CE90S04137 for ; Tue, 12 Aug 2003 07:09:00 -0700 Date: Tue, 12 Aug 2003 07:09:00 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Issue 414: Keying AVPs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've finally gotten the -07 draft of the EAP Keying Framework out: http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.txt This clarifies a few issues. While the AAA-Key AVP will *generally* contain the MSK, this might not necessarily be the case -- it could for example contain a quantity derived from the EMSK and even in some cases, one derived from the MSK. For example, if the MSK is not actually sent to the NAS, then quantities derived off the MSK could be used to provide cryptographic separation between material sent to different NASes. So the -07 version makes a distinction between the AAA-Key, and the MSK and EMSK (and quantities derived from them). All this to say that perhaps the AVP should be named "EAP-Key" or something like that. I agree that including a list of ciphers with the AAA-Key AVP is not a good idea since this keying material MUST be ciphersuite independent, according to the Key Framework draft. Similarly, directionality is not useful since this is keying material, not a session key. However, it does strike me that perhaps a key lifetime might make sense, since overloading Session-Timeout or another equivalent AVP seems like a bad idea. One issue which is still open is whether the Key-Name should be included along with the key. IEEE 802.11i has a new PMK naming proposal in D5.0 which essentially names keys based on the key itself as well as Called-Station-Id and Calling-Station-Id. However, I'm not clear how the station knows which algorithm was used to generate the key (could be one of several). I don't care much for options 3 and 4. ----------------------------------------------------------------------------- Issue 414: Key AVPs Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 19 Jun 2003 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg04961.html Document: EAP-01 Comment type: T Priority: 1 Section: various Rationale/Explanation of issue: What should the AVPs for transporting keys look like? Here are some alternatives for starting a discussion: Alternative 1: EAP-Master-Session-Key (OctetString) Pros/cons: + Simple + Does not try to solve all keying problems forever, but just enough for EAP. + Consistent with 2284bis + The Diameter server doesn't have to know what the key is used for - The Diamater server doesn't know what the key is used for - New AVPs may be needed for more complex needs in the future (but if we don't know them yet, we can define them later). Alternative 2: From old NASREQ-09: NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key-Data } { NAS-Key-Binding } | [ NAS-Key-Lifetime ] [ NAS-IV ] * [ AVP ] NAS-Key-Direction: (BIDIRECTIONAL, UPLINK, DOWNLINK) NAS-Key-Type: (CIPHER_KEY, INTEGRITY_KEY, MASTER_CIPHER_KEY, MASTER_INTEGRITY_KEY, MASTER_KEY) NAS-Key-Binding: (DES, 3DES, RC4-40, RC4-128) Pros/cons. - The Key-Type/Binding is complex, but it still can't specify even something simple like "use this key for 802.11i PMK" -- a BIDIRECTIONAL,MASTER_KEY could be used for some other purpose! - Including a list of ciphers here is probably not a good idea. Alternative 3: EAP-Session-Key ::= < AVP Header: TBD > { EAP-Key-Type } 1* { EAP-Key-Data } * [ AVP ] EAP-Key-Type is of type Enumerated, with the following values assigned: IEEE_802_11I_PAIRWISE_MASTER_KEY (1) A single EAP-Key-Data AVP contains the Pairwise Master Key to be used in 802.11i four-way handshake. IEEE_802_11_WEP_KEY (2) A single EAP-Key-Data AVP contains the 802.11 WEP key (TBD: is this correct?). MS_MPPE_KEYS (3) Two EAP-Key-Data AVPs included, first containing the downlink (send) key, and the second the uplink (recv) key. IKE_V2_AUTH_KEY (4) A single EAP-Key-Data AVP contains the MSK for IKEv2 authentication. PANA_something (5) To be defined when PANA progresses. Pros/cons: + Simple binding, extensible - ? Alternative 4: Like 3, but instead of creating a new Enumeration namespace, just use the AVP namespace. That is, create four new AVPs: IEEE-802-11i-Pairwise-Master-Key IEEE-802-11-WEP-Key MS-MPPE-Keys IKEv2-Auth-Key Pros/cons: + Grouped AVPs can include other stuff, like encryption policies for MPPE, or allowed cipher algorithms, etc. + Any new use for EAP will probably require a spec saying how it is used with RADIUS/Diameter anyway (e.g. we will soon need a "IKEv2 RADIUS/Diameter Usage Guidelines" document, similar to the existing "IEEE 802.1X RADIUS Usage Guidelines") + New keying AVPs can be defined using the normal ABNF syntax. + New AVP required for new key uses -- it's a good thing if they keys can't be used for other purposes too easily. - New AVP required for new key uses. From owner-aaa-wg@merit.edu Wed Aug 13 08:59:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18249 for ; Wed, 13 Aug 2003 08:59:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6546D9127E; Wed, 13 Aug 2003 08:59:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34F7E9127F; Wed, 13 Aug 2003 08:59:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 128E69127E for ; Wed, 13 Aug 2003 08:59:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF7AA5DDCC; Wed, 13 Aug 2003 08:59:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 1587B5DDC9 for ; Wed, 13 Aug 2003 08:59:00 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7DCwwB17924 for ; Wed, 13 Aug 2003 15:58:58 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Aug 2003 15:58:58 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 15:58:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Updating Issue Status Date: Wed, 13 Aug 2003 15:58:58 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0258@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Updating Issue Status Thread-Index: AcNg3elQE3w6WQEZTzmW5X2EZvtGzAAu8QgQ From: To: Cc: , X-OriginalArrivalTime: 13 Aug 2003 12:58:58.0734 (UTC) FILETIME=[A92814E0:01C3619A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, I just noticed that we have issue 419 for the GST proposal. Actually the GST proposal is to address the below comment within the issue 408 raised by Avi Lior. "Redirect In many instances in the text the action to take when a user resources are no longer available is to terminate the session. That is one possible action, the other possible action is to restrict access (or direct the user) to a portal where they can recharge their account etc..." Should we really have issue 419 or perhaps Avi's (and others) could review the GST proposal to check if the comment within issue 408 is properly addressed? Regards Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 12 August, 2003 16:58 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Updating Issue Status >=20 >=20 > I've gone and updated the AAA Issues list at: >=20 > http://www.drizzle.com/~aboba/AAA/issues.html >=20 > In order to clarify which issues are still open, I'd=20 > appreciate it if the > editors could go over the outstanding issues and let me know=20 > which ones > have been closed, and if so, in what version of the document. >=20 > Thanks! >=20 From owner-aaa-wg@merit.edu Wed Aug 13 09:40:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18905 for ; Wed, 13 Aug 2003 09:40:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5AB0F91280; Wed, 13 Aug 2003 09:40:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 282C991281; Wed, 13 Aug 2003 09:40:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3C2191280 for ; Wed, 13 Aug 2003 09:40:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFFA75DDD0; Wed, 13 Aug 2003 09:40:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id A47C75DDC9 for ; Wed, 13 Aug 2003 09:40:11 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7DDeAP03690 for ; Wed, 13 Aug 2003 16:40:10 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Aug 2003 16:40:10 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 16:40:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Re: Issue 414: Keying AVPs Date: Wed, 13 Aug 2003 16:40:09 +0300 Message-ID: Thread-Topic: [AAA-WG]: Re: Issue 414: Keying AVPs Thread-Index: AcNg36aUig2yJo+8QgugisEYYCEcqAAv5jQw From: To: , X-OriginalArrivalTime: 13 Aug 2003 13:40:10.0055 (UTC) FILETIME=[6A2DBD70:01C361A0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > I agree that including a list of ciphers with the AAA-Key AVP is not a > good idea since this keying material MUST be ciphersuite independent, > according to the Key Framework draft. Similarly,=20 > directionality is not > useful since this is keying material, not a session key. >=20 > However, it does strike me that perhaps a key lifetime might=20 > make sense, > since overloading Session-Timeout or another equivalent AVP=20 > seems like a > bad idea. Why? Doesn't the Session-Timeout really mean that after expiration=20 full (re-)authentication must be done and thus new keys must be=20 derived? Diameter has Session-Timeout and Authorization-Lifetime AVPs (see=20 also Termination-Action (NASREQ) and Re-Auth-Request-Type AVPs).=20 I don't know why, but NASREQ recommends to use Authorization-Lifetime=20 AVP only. No need for Session-Timeout? Then it's not overloading I=20 guess. I'm just confused with all these lifetime AVPs and recommendations. - Dan >=20 > One issue which is still open is whether the Key-Name should=20 > be included > along with the key. IEEE 802.11i has a new PMK naming=20 > proposal in D5.0 > which essentially names keys based on the key itself as well as > Called-Station-Id and Calling-Station-Id. However, I'm not=20 > clear how the > station knows which algorithm was used to generate the key=20 > (could be one > of several). >=20 From owner-aaa-wg@merit.edu Wed Aug 13 10:20:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21455 for ; Wed, 13 Aug 2003 10:20:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98F4891284; Wed, 13 Aug 2003 10:19:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6470291285; Wed, 13 Aug 2003 10:19:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64B2A91284 for ; Wed, 13 Aug 2003 10:19:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45FF15DDC6; Wed, 13 Aug 2003 10:19:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 82C325DDB4 for ; Wed, 13 Aug 2003 10:19:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7DDnq518722; Wed, 13 Aug 2003 06:49:52 -0700 Date: Wed, 13 Aug 2003 06:49:52 -0700 (PDT) From: Bernard Aboba To: Dan.Forsberg@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Issue 414: Keying AVPs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Why? Doesn't the Session-Timeout really mean that after expiration > full (re-)authentication must be done and thus new keys must be > derived? In RADIUS, Session-Timeout can be used to indicate the maximum amount of time that the user can have (with Termination-Action not specified or set to default), or the maximum time to re-authentication (if Termination-Action = RADIUS). While it is true that a re-authentication implies a re-key, the reverse is not true; a re-key can be done without re-authenticating (e.g. rerun the 4-way handshake in 802.11). Also typically a re-key is done after a certain amount of data is sent. For example in block ciphers this is related to the birthday attack probability. For a credible cipher (e.g. AES) this is typically quite a large number. For WEP it was small due to its flaws and so people have set Session-Timeout to 10 minutes or less. In general it would be useful to be able to set the re-key and re-authentication timers independently. > Diameter has Session-Timeout and Authorization-Lifetime AVPs (see > also Termination-Action (NASREQ) and Re-Auth-Request-Type AVPs). > I don't know why, but NASREQ recommends to use Authorization-Lifetime > AVP only. No need for Session-Timeout? Then it's not overloading I > guess. The Authorization-Lifetime AVP specifies when the NAS needs to re-authorize the session. This is still not the same thing as specifying when a rekey is required. > I'm just confused with all these lifetime AVPs and recommendations. Yes, it is confusing. I've never been convinced that Authorization-Lifetime AVP really adds any value to Diameter other than requiring more logic in a RADIUS/Diameter gateway. From owner-aaa-wg@merit.edu Wed Aug 13 10:22:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21646 for ; Wed, 13 Aug 2003 10:22:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0697491285; Wed, 13 Aug 2003 10:22:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C236D91286; Wed, 13 Aug 2003 10:22:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAC5E91285 for ; Wed, 13 Aug 2003 10:22:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCC475DDCA; Wed, 13 Aug 2003 10:22:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 48A225DDB4 for ; Wed, 13 Aug 2003 10:22:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7DDqIp18851; Wed, 13 Aug 2003 06:52:18 -0700 Date: Wed, 13 Aug 2003 06:52:18 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: aaa-wg@merit.edu, avi@bridgewatersystems.com Subject: RE: [AAA-WG]: Updating Issue Status In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D018B0258@esebe016.ntc.nokia.com> Message-ID: References: <142DC466081D9B409AAD1DDCA4B21E1D018B0258@esebe016.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Should we really have issue 419 or perhaps Avi's (and others) could > review the GST proposal to check if the comment within issue 408 is > properly addressed? Either way would work. It might be a bit easier to track the many issues raised in 408 if a few of the larger ones were split off. From owner-aaa-wg@merit.edu Wed Aug 13 11:03:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22705 for ; Wed, 13 Aug 2003 11:03:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AECA89123D; Wed, 13 Aug 2003 11:02:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CA429128D; Wed, 13 Aug 2003 11:02:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02C389123D for ; Wed, 13 Aug 2003 11:02:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0E845DDC1; Wed, 13 Aug 2003 11:02:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 354DC5DDB4 for ; Wed, 13 Aug 2003 11:02:28 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7DF2Qp24229 for ; Wed, 13 Aug 2003 18:02:27 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Aug 2003 18:02:24 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 18:02:24 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 18:02:24 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 13 Aug 2003 18:02:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Re: Issue 414: Keying AVPs Date: Wed, 13 Aug 2003 18:02:23 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C8@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: Issue 414: Keying AVPs Thread-Index: AcNhpgBk/CJqUJ/cQ32IVU7fAFTIMwAA+UpA From: To: Cc: X-OriginalArrivalTime: 13 Aug 2003 15:02:24.0264 (UTC) FILETIME=[E7324880:01C361AB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > In RADIUS, Session-Timeout can be used to indicate the maximum > amount of time that the user can have (with Termination-Action not > specified or set to default), or the maximum time to > re-authentication (if Termination-Action =3D RADIUS). While it is > true that a re-authentication implies a re-key, the reverse is not > true; a re-key can be done without re-authenticating (e.g. rerun the > 4-way handshake in 802.11). Also typically a re-key is done after a > certain amount of data is sent. For example in block ciphers this > is related to the birthday attack probability. For a credible > cipher (e.g. AES) this is typically quite a large number. For WEP > it was small due to its flaws and so people have set Session-Timeout > to 10 minutes or less. In general it would be useful to be able to > set the re-key and re-authentication timers independently. I agree with you that setting these timers separately could be useful. One possible solution would be that=20 Authorization-Lifetime (or Session-Timeout, I'm confused about them) would specify the lifetime of the MSK (=3D=3Dafter this period, you need to contact the AAA server, which may give you a new MSK), and some=20 new AVP (maybe "Rekeying-Interval") would specify link-layer=20 rekeying interval (=3D=3DTSK lifetime)? Another possibility would be to configure TSK lifetime locally=20 on the access points. This would also allow volume-based TSK=20 lifetimes ("rekey TSK after sending X gigabytes"), or do we need an AVP for also that? This Rekeying-Interval AVP would be somewhat link layer specific,=20 but I don't think it matters (some link layers might not even=20 support TSK rekeying e.g. because they use good ciphers which=20 don't need it, and even rekeying means different things in e.g. 802.11i, PANA and IKEv2). Do you think something like this would work? Best regards, Pasi From owner-aaa-wg@merit.edu Wed Aug 13 13:51:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27693 for ; Wed, 13 Aug 2003 13:51:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5361891212; Wed, 13 Aug 2003 13:51:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2126191213; Wed, 13 Aug 2003 13:51:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D17191212 for ; Wed, 13 Aug 2003 13:51:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 000AB5DDA4; Wed, 13 Aug 2003 13:51:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 467985DD90 for ; Wed, 13 Aug 2003 13:51:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7DHLGF30459; Wed, 13 Aug 2003 10:21:16 -0700 Date: Wed, 13 Aug 2003 10:21:16 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Issue 414: Keying AVPs In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222C8@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A61222C8@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree with you that setting these timers separately > could be useful. One possible solution would be that > Authorization-Lifetime (or Session-Timeout, I'm confused about them) I'm also confused, and this worries me because we've had several people say they were confused about this over the last few days. Perhaps we need to revisit whether the current NASREQ text on this really makes sense? > would specify the lifetime of the MSK (==after this period, you need > to contact the AAA server, which may give you a new MSK), and some > new AVP (maybe "Rekeying-Interval") would specify link-layer > rekeying interval (==TSK lifetime)? One issue is that in practice the rekey interval (expressed in terms of packets) depends on the negotiated ciphersuite. So WEP needs to be rekeyed much more frequently than say, AES. Since AAA and EAP are ciphersuite independent, the AAA server does not in practice have the information required to set the rekey interval appropriately, since the ciphersuite may not be determined until the secure association protocol runs. I think this means that a Rekey-Interval AVP isn't appropriate for inclusion in the AAA-Key Grouped AVP. > Another possibility would be to configure TSK lifetime locally > on the access points. This would also allow volume-based TSK > lifetimes ("rekey TSK after sending X gigabytes"), or do > we need an AVP for also that? This might make more sense, since one could configure the APs with different lifetimes depending on the negotiated ciphersuite (e.g. a table of ciphersuites and corresponding rekey intervals in octets). This would make it possible to set a WEP lifetime of X octets and an AES lifetime of Y octets where Y >> X. Doing this on a per-AP versus per-session basis would work fine; there is no need to set different sessions to different values other than because they negotiated different ciphersuites. > This Rekeying-Interval AVP would be somewhat link layer specific, > but I don't think it matters (some link layers might not even > support TSK rekeying e.g. because they use good ciphers which > don't need it, and even rekeying means different things in e.g. > 802.11i, PANA and IKEv2). > > Do you think something like this would work? I think you've made an argument for why the Rekey-Interval should be left to link layer management rather than AAA. However, I have some additional confusion to add to the mix :) Yet another parameter that might need to be set is the AAA-Key caching interval. This is the time that the NAS retains the AAA-Key after the session has terminated. This is different from either the rekey interval or the re-authentication interval. Would this be appropriate for sending in the AAA-Key Grouped AVP? From owner-aaa-wg@merit.edu Wed Aug 13 20:03:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11863 for ; Wed, 13 Aug 2003 20:03:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7300D9123C; Wed, 13 Aug 2003 20:01:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44E449123D; Wed, 13 Aug 2003 20:01:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CB649123C for ; Wed, 13 Aug 2003 20:01:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E56D5DD99; Wed, 13 Aug 2003 20:01:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 782DA5DD91 for ; Wed, 13 Aug 2003 20:01:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7DNVv718604; Wed, 13 Aug 2003 16:31:57 -0700 Date: Wed, 13 Aug 2003 16:31:56 -0700 (PDT) From: Bernard Aboba To: Tom Hiller Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: advancing Diameter MIPv4 In-Reply-To: <3F2EE164.1060901@lucent.com> Message-ID: References: <200307301803.h6UI3b610402@cichlid.adsl.duke.edu> <3F2EE164.1060901@lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Comments below: > I have a security question regarding changes I proposed for this draft: The > security guidance for distributing keys is that "only those entities that need > the key should see the key". [BA] This was one of the elements of the guidance. The entire presentation is available here: http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt > Now then for the FA(s) to receive a key from the > HAAA via TLS, 3GPP2 carriers have to open pinholes in the firewalls so TLS can > run. This exposes the 3GPP2 carrier to possible attacks due to all the > pinholes being open, i.e., one per FA. I presume that this concern exists on the HAAA, rather than the FA, no? Today HAAAs typically only need to accept traffic from known AAA agents; under this proposal they would need to accept AAA traffic directly from NASes. > If instead the HAAA could send the keys under the > protection of TLS in usual MIPv4-Diameter messages (e.g., the AMA message) to > the AAAF, then AAAF could just proxy the message with key to the FA, which is > all intra-domain. Then there would not have to be as many holes in the firewalls. I think this issue arises because the NAS initiates the key-related traffic, and therefore a pinehole needs to be opened for the HAAA to receive that traffic. However, if the HAAA were to initiate the key-related traffic a "stateful inspection" filter on the firewall would open the holes automatically. Of course, this would require the NAS to be able to receive keys from HAAAs, but presumably the NAS knows which HAAAs it is attempting to get keys from so it can screen out unsolicited traffic from other HAAAs. > Also, there is some concern about the need for the Diameter clients to have the > certificates to establish TLS to HAAA servers. Having the TLS connection to the > AAAF would solve this problem, albeit the keys are exposed to the AAAF. Diameter clients either require TLS w/certs or IPsec (either certs or pre-shared keys). If only pre-shared keys are available, then IPsec is the only option. Are you saying that the preference is to use IPsec w/pre-shared keys instead of TLS? > Should we revisit the requriement for the AAAF to not see the keys, i.e., to > allow it to see the keys and thereby reduce the functionality required at the > Diameter client in the FA as well as the number of pinholes? I'd suggest that we discuss the problem and figure out what the options are for solving it. > Note: It turns out that my slides from the IETF presentation show the "AAAF" and > the "FA" as being merged in figures 8, 9, and 10. This was not intentional, > however, it's just inherited from the original draft. > > To find the MIPv4-Diameter presentation from the AAA WG: > http://www.drizzle.com/~aboba/IETF57/AAA/ > and click "MIPv4-Diameter Edit.ppt". > > thanks, > Tom From owner-aaa-wg@merit.edu Thu Aug 14 04:07:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03168 for ; Thu, 14 Aug 2003 04:07:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4171E91242; Thu, 14 Aug 2003 04:07:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00EA191243; Thu, 14 Aug 2003 04:07:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC50791242 for ; Thu, 14 Aug 2003 04:07:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A4405DD90; Thu, 14 Aug 2003 04:07:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 941815DD9A for ; Thu, 14 Aug 2003 04:07:39 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7E87bp07333 for ; Thu, 14 Aug 2003 11:07:38 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Aug 2003 11:07:37 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 14 Aug 2003 11:07:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Updating Issue Status Date: Thu, 14 Aug 2003 11:07:30 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C7E48@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Updating Issue Status Thread-Index: AcNhpkVToGbXaa3tTB2gAHFRJxbnmwAlLOcQ From: To: Cc: , X-OriginalArrivalTime: 14 Aug 2003 08:07:36.0850 (UTC) FILETIME=[1F8E0720:01C3623B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Either way would work. It might be a bit easier to track the=20 > many issues > raised in 408 if a few of the larger ones were split off. OK. > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 13 August, 2003 16:52 > To: Stura Marco (NET/Helsinki) > Cc: aaa-wg@merit.edu; avi@bridgewatersystems.com > Subject: RE: [AAA-WG]: Updating Issue Status >=20 >=20 > > Should we really have issue 419 or perhaps Avi's (and others) could > > review the GST proposal to check if the comment within issue 408 is > > properly addressed? >=20 > Either way would work. It might be a bit easier to track the=20 > many issues > raised in 408 if a few of the larger ones were split off. >=20 From owner-aaa-wg@merit.edu Fri Aug 15 07:43:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24826 for ; Fri, 15 Aug 2003 07:43:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39DFA91298; Fri, 15 Aug 2003 07:43:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F370891299; Fri, 15 Aug 2003 07:43:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B4BBF91298 for ; Fri, 15 Aug 2003 07:43:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C37E5DE38; Fri, 15 Aug 2003 07:43:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 203F65DE1F for ; Fri, 15 Aug 2003 07:43:14 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7FBh47W004325; Fri, 15 Aug 2003 13:43:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 15 Aug 2003 13:43:16 +0200 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu, aboba@internaut.com Cc: "'marco.stura@nokia.com'" , john.loughney@nokia.com, "Leena Mattila (TU/LMF)" , juha-pekka.koskinen@nokia.com Subject: [AAA-WG]: Missing CCA flows (issue 407) Date: Fri, 15 Aug 2003 13:42:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, In the issue 407, Credit Control Review, we were advised to provide some message diagrams explaining the protocol usage. In the current CCA draft (draft-ietf-aaa-diameter-cc-00) we have described some message flows in Appendix A, Credit Control sequences. However, the example flows for the refund and price enquiry cases were not included in the above version. To close this part of the issue, we have prepared some additional message flows to clarify these cases. Flows are available here, Price Enquiry: http://standards.ericsson.net/harri/Price_enquiry.txt Refund: http://standards.ericsson.net/harri/Refund.txt All comments and suggestions are most welcome. Regards........Harri From owner-aaa-wg@merit.edu Fri Aug 15 09:13:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26471 for ; Fri, 15 Aug 2003 09:13:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4391B9129B; Fri, 15 Aug 2003 09:13:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 111D49129F; Fri, 15 Aug 2003 09:13:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BEA49129B for ; Fri, 15 Aug 2003 09:13:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 815855DE51; Fri, 15 Aug 2003 09:13:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 77CA85DE52 for ; Fri, 15 Aug 2003 09:13:17 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7FDDE414113 for ; Fri, 15 Aug 2003 16:13:15 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 15 Aug 2003 16:13:14 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 16:13:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 16:13:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Authorization-Lifetime/Session-Timeout confusion Date: Fri, 15 Aug 2003 16:13:13 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222CB@esebe023.ntc.nokia.com> Thread-Topic: Authorization-Lifetime/Session-Timeout confusion Thread-Index: AcNjLvtD5YlcU8WlR3enSa8GONfNWw== From: To: X-OriginalArrivalTime: 15 Aug 2003 13:13:13.0561 (UTC) FILETIME=[FB7FD490:01C3632E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 15, 2003 Reference:=20 Document: NASREQ Comment type: T Priority: 1 Section: various Rationale/Explanation of issue: There seems to be some confusion about Authorization-Lifetime and Session-Timeout AVPs between Base and NASREQ. More specifically, the state machine in Base (Section 8.1)=20 specifies that when Session-Timeout expires, the access=20 device MUST send a STR and move to state Discon.=20 This is inconsistent with with NASREQ description for Termination-Action AVP, which allows other behavior as well. Proposed change: Remove the Termination-Action AVP completely.=20 When translating a RADIUS Access-Accept to Diameter AA-Answer,=20 do the following: - If the RADIUS message contains a Session-Timeout attribute and a Termination-Action attribute set to DEFAULT (or no=20 Termination-Action attribute at all), translate it=20 to AA-Answer with a Session-Timeout AVP (and remove the Termination-Action attribute). - If the RADIUS message contains a Session-Timeout attribute and a Termination-Action attribute set to AA-REQUEST, translate it to AA-Answer with Authorization-Lifetime AVP and Re-Auth-Request-Type set to AUTHORIZE_AUTHENTICATE (and remove the Session-Timeout attribute). When translating a Diameter AA-Answer (with successful result code) to RADIUS Access-Accept, - If the Diameter message contains a Session-Timeout AVP but no=20 Authorization-Lifetime AVP, translate it to Session-Timeout=20 attribute (and no Termination-Action). - If the Diameter message contains a Authorization-Lifetime AVP but=20 no Session-Timeout AVP, translate it to Session-Timeout attribute=20 and Termination-Action set to AA-REQUEST. (And remove Authorization-Lifetime and Re-Auth-Request-Type) - If the Diameter message has both, the Session-Timeout is always greater or equal than Authorization-Lifetime (required by Base).=20 I guess the safest bet is to translate it to Session-Timeout value (with value from Authorization-Lifetime AVP, the smaller one)=20 and Termination-Action set to AA-REQUEST. (And remove=20 Authorization-Lifetime and Re-Auth-Request-Type) Best regards, Pasi From owner-aaa-wg@merit.edu Sat Aug 23 21:51:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05192 for ; Sat, 23 Aug 2003 21:51:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C360912D9; Sat, 23 Aug 2003 21:50:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65908912DC; Sat, 23 Aug 2003 21:50:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8053E912D9 for ; Sat, 23 Aug 2003 21:50:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AAC65DDF1; Sat, 23 Aug 2003 21:50:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D425F5DD9A for ; Sat, 23 Aug 2003 21:50:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7O1K4t30012 for ; Sat, 23 Aug 2003 18:20:05 -0700 Date: Sat, 23 Aug 2003 18:20:04 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Completion of AAA WG last call on NASREQ-12 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has completed on NASREQ-12. Four comments were received, Issues 416, 417, 418, and 423, up on the Issues list: http://www.drizzle.com/~aboba/AAA/issues.html Given that the comments are relatively minor, I'd like to propose the following schedule: September 1, 2003: Proposed resolution of the comments September 15, 2003: NASREQ -13 on the IETF archive September 16, 2003: NASREQ-13 submitted to IESG for consideration as a Proposed Standard. From owner-aaa-wg@merit.edu Mon Aug 25 07:51:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11942 for ; Mon, 25 Aug 2003 07:51:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B32891205; Mon, 25 Aug 2003 07:51:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3CAE912ED; Mon, 25 Aug 2003 07:51:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 897A3912CA for ; Mon, 25 Aug 2003 07:51:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 752175DD97; Mon, 25 Aug 2003 07:51:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id AEE9C5DD93 for ; Mon, 25 Aug 2003 07:51:38 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7PBpQ408919 for ; Mon, 25 Aug 2003 14:51:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Aug 2003 14:51:25 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 14:51:25 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 14:51:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Command Code & AVP values for Diameter applications Date: Mon, 25 Aug 2003 14:51:23 +0300 Message-ID: Thread-Topic: [AAA-WG]: Completion of AAA WG last call on NASREQ-12 Thread-Index: AcNp4jG9/jnnyZQkSoigCSoOZnHyTQBHIPsQ From: To: , X-OriginalArrivalTime: 25 Aug 2003 11:51:25.0074 (UTC) FILETIME=[35F1A720:01C36AFF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, The Diameter / AAA IANA registry is setup. I think that it would be a = good idea if all of the Diameter applications would prepare their = applications so that the values could be reserved in the registry. Could I ask the other authors to look at: = http://www.iana.org/assignments/aaa-parameters and organize the values that need to be inserted? I am planning on getting values for the Diameter Credit Control = application, so it makes it easier if everyone does this. thanks, John From aaa-admin@ietf.org Tue Aug 26 15:33:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28927 for ; Tue, 26 Aug 2003 15:33:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjGz-0007lF-1a; Tue, 26 Aug 2003 15:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rQLk-0004I1-Q7 for aaa@optimus.ietf.org; Mon, 25 Aug 2003 19:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21995 for ; Mon, 25 Aug 2003 19:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rQLh-0000ja-00 for Aaa@ietf.org; Mon, 25 Aug 2003 19:02:09 -0400 Received: from [212.105.61.114] (helo=mail.sekvencia.se) by ietf-mx with esmtp (Exim 4.12) id 19rQLe-0000iT-00 for Aaa@ietf.org; Mon, 25 Aug 2003 19:02:06 -0400 thread-index: AcNrXOddtzHLABjKS8OzDrjAAmWSeg== From: To: Content-Transfer-Encoding: 7bit Date: Tue, 26 Aug 2003 01:01:28 +0200 Importance: normal Content-Class: urn:content-classes:message Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s" X-DSNContext: 335a7efd - 4457 - 00000001 - 80040546 Message-ID: Subject: [Aaa] Delivery Status Notification (Failure) Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_SOBIG.F in file document_all.pif The uncleanable file document_all.pif is moved to /etc/iscan/virus/virQQByuaiZa. --------------------------------------------------------- --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: text/plain; charset="unicode-1-1-utf-7" Content-Transfer-Encoding: 7bit This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. joakim@sekvencia.se --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: message/delivery-status Content-Transfer-Encoding: 7bit Reporting-MTA: dns;mail.sekvencia.se Received-From-MTA: dns;RKC-RUMNR1 Arrival-Date: Tue, 26 Aug 2003 01:01:26 +0200 Final-Recipient: rfc822;joakim@sekvencia.se Action: failed Status: 5.1.1 --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: message/rfc822 thread-index: AcNrXNDYO1daIY0gT8mWtJWFOR8y4w== Received: from RKC-RUMNR1 ([213.65.136.114] unverified) by mail.sekvencia.se with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Aug 2003 01:01:26 +0200 From: To: Subject: Re: Re: My details Date: Tue, 26 Aug 2003 0:59:59 +0200 X-MailScanner: Found to be clean Content-Class: urn:content-classes:message Priority: normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_039193E7" Return-Path: Message-ID: X-OriginalArrivalTime: 25 Aug 2003 23:01:26.0559 (UTC) FILETIME=[CFE572F0:01C36B5C] This is a multi-part message in MIME format. --_NextPart_000_039193E7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_039193E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) document_all.pif is removed from here because it contains a virus. --------------------------------------------------------- --_NextPart_000_039193E7-- --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Tue Aug 26 15:33:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29002 for ; Tue, 26 Aug 2003 15:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjYx-0001VM-5G for aaa-archive@odin.ietf.org; Tue, 26 Aug 2003 15:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJX7JI005783 for aaa-archive@odin.ietf.org; Tue, 26 Aug 2003 15:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjYx-0001VC-28 for aaa-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 15:33:07 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28925 for ; Tue, 26 Aug 2003 15:33:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjGz-0007lF-1a; Tue, 26 Aug 2003 15:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rQLk-0004I1-Q7 for aaa@optimus.ietf.org; Mon, 25 Aug 2003 19:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21995 for ; Mon, 25 Aug 2003 19:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rQLh-0000ja-00 for Aaa@ietf.org; Mon, 25 Aug 2003 19:02:09 -0400 Received: from [212.105.61.114] (helo=mail.sekvencia.se) by ietf-mx with esmtp (Exim 4.12) id 19rQLe-0000iT-00 for Aaa@ietf.org; Mon, 25 Aug 2003 19:02:06 -0400 thread-index: AcNrXOddtzHLABjKS8OzDrjAAmWSeg== From: To: Content-Transfer-Encoding: 7bit Date: Tue, 26 Aug 2003 01:01:28 +0200 Importance: normal Content-Class: urn:content-classes:message Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s" X-DSNContext: 335a7efd - 4457 - 00000001 - 80040546 Message-ID: Subject: [Aaa] Delivery Status Notification (Failure) Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_SOBIG.F in file document_all.pif The uncleanable file document_all.pif is moved to /etc/iscan/virus/virQQByuaiZa. --------------------------------------------------------- --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: text/plain; charset="unicode-1-1-utf-7" Content-Transfer-Encoding: 7bit This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. joakim@sekvencia.se --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: message/delivery-status Content-Transfer-Encoding: 7bit Reporting-MTA: dns;mail.sekvencia.se Received-From-MTA: dns;RKC-RUMNR1 Arrival-Date: Tue, 26 Aug 2003 01:01:26 +0200 Final-Recipient: rfc822;joakim@sekvencia.se Action: failed Status: 5.1.1 --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s Content-Type: message/rfc822 thread-index: AcNrXNDYO1daIY0gT8mWtJWFOR8y4w== Received: from RKC-RUMNR1 ([213.65.136.114] unverified) by mail.sekvencia.se with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Aug 2003 01:01:26 +0200 From: To: Subject: Re: Re: My details Date: Tue, 26 Aug 2003 0:59:59 +0200 X-MailScanner: Found to be clean Content-Class: urn:content-classes:message Priority: normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_039193E7" Return-Path: Message-ID: X-OriginalArrivalTime: 25 Aug 2003 23:01:26.0559 (UTC) FILETIME=[CFE572F0:01C36B5C] This is a multi-part message in MIME format. --_NextPart_000_039193E7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_039193E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) document_all.pif is removed from here because it contains a virus. --------------------------------------------------------- --_NextPart_000_039193E7-- --9B095B5ADSN=_01C3670138EFD1D800001969mail.sekvencia.s-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Aug 26 16:07:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03987 for ; Tue, 26 Aug 2003 16:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rk5q-0005LP-Om; Tue, 26 Aug 2003 16:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rk4F-00059t-E6 for aaa@optimus.ietf.org; Tue, 26 Aug 2003 16:05:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03600 for ; Tue, 26 Aug 2003 16:05:22 -0400 (EDT) From: p.eo@spray.se Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rk4D-0000Wb-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:05:25 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19rk48-0000WQ-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:05:21 -0400 To: Date: Tue, 26 Aug 2003 22:02:45 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0815BF40" Message-Id: Subject: [Aaa] Re: Your application Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0815BF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0815BF40 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0815BF40-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Aug 26 19:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19542 for ; Tue, 26 Aug 2003 19:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rluQ-0002Iy-D5; Tue, 26 Aug 2003 18:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkWL-00070L-7l for aaa@optimus.ietf.org; Tue, 26 Aug 2003 16:34:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07115 for ; Tue, 26 Aug 2003 16:34:23 -0400 (EDT) From: Denise.Papish@axa-financial.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rkWJ-00019o-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:34:27 -0400 Received: from [161.233.252.244] (helo=snj1afswt02.equitable.com) by ietf-mx with esmtp (Exim 4.12) id 19rkWI-00019D-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:34:26 -0400 Received: from 10.73.102.20 by snj1afswt02.equitable.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.3)); Tue, 26 Aug 2003 16:36:55 -0400 To: Aaa@ietf.org Message-ID: Date: Tue, 26 Aug 2003 16:33:48 -0400 X-MIMETrack: Serialize by Router on NJMAIL01/Equitable(Release 5.0.12 |February 13, 2003) at 08/26/2003 04:33:49 PM MIME-Version: 1.0 X-WSS-ID: 13551B6D3025893-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Aaa] Denise S Papish/NY/AXA-Financial/Equitable is out of the office. Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I will be out of the office from 08/25/2003 until 09/03/2003. I will respond to your message when I return. ********************************************************************** Confidentiality Note: This message and any attachments may contain legally privileged and/or confidential information. Any unauthorized disclosure, use or dissemination of this e-mail message or its contents, either in whole or in part, is prohibited. If you are not the intended recipient of this e-mail message, kindly notify the sender and then destroy it. ********************************************************************** _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Aug 26 19:47:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23214 for ; Tue, 26 Aug 2003 19:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmLa-0003SN-6F; Tue, 26 Aug 2003 18:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rm0K-00030r-7b for aaa@optimus.ietf.org; Tue, 26 Aug 2003 18:09:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14936 for ; Tue, 26 Aug 2003 18:09:25 -0400 (EDT) From: willy.lindberg@telia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rm0H-0003Fc-00 for Aaa@ietf.org; Tue, 26 Aug 2003 18:09:29 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19rm0D-0003FZ-00 for Aaa@ietf.org; Tue, 26 Aug 2003 18:09:26 -0400 To: Date: Wed, 27 Aug 2003 0:06:55 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_08875CAA" Message-Id: Subject: [Aaa] Re: Thank you! Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_08875CAA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_08875CAA Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_08875CAA-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Aug 27 02:33:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26126 for ; Wed, 27 Aug 2003 02:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rs3v-00048Z-BP for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 00:37:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R4bcgX015895 for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 00:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rnX1-0007ho-Rk for aaa-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 19:47:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23164 for ; Tue, 26 Aug 2003 19:47:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rnX0-0005FC-00 for aaa-web-archive@ietf.org; Tue, 26 Aug 2003 19:47:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rnWz-0005F9-00 for aaa-web-archive@ietf.org; Tue, 26 Aug 2003 19:47:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmLa-0003SN-6F; Tue, 26 Aug 2003 18:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rm0K-00030r-7b for aaa@optimus.ietf.org; Tue, 26 Aug 2003 18:09:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14936 for ; Tue, 26 Aug 2003 18:09:25 -0400 (EDT) From: willy.lindberg@telia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rm0H-0003Fc-00 for Aaa@ietf.org; Tue, 26 Aug 2003 18:09:29 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19rm0D-0003FZ-00 for Aaa@ietf.org; Tue, 26 Aug 2003 18:09:26 -0400 To: Date: Wed, 27 Aug 2003 0:06:55 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_08875CAA" Message-Id: Subject: [Aaa] Re: Thank you! Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_08875CAA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_08875CAA Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_08875CAA-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Aug 27 02:44:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27292 for ; Wed, 27 Aug 2003 02:44:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsKH-00057T-7K for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 00:54:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R4sVL1019667 for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 00:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmt9-0005TZ-NG for aaa-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 19:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19488 for ; Tue, 26 Aug 2003 19:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rmt6-0004Id-00 for aaa-web-archive@ietf.org; Tue, 26 Aug 2003 19:06:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rmt5-0004Ia-00 for aaa-web-archive@ietf.org; Tue, 26 Aug 2003 19:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rluQ-0002Iy-D5; Tue, 26 Aug 2003 18:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkWL-00070L-7l for aaa@optimus.ietf.org; Tue, 26 Aug 2003 16:34:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07115 for ; Tue, 26 Aug 2003 16:34:23 -0400 (EDT) From: Denise.Papish@axa-financial.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rkWJ-00019o-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:34:27 -0400 Received: from [161.233.252.244] (helo=snj1afswt02.equitable.com) by ietf-mx with esmtp (Exim 4.12) id 19rkWI-00019D-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:34:26 -0400 Received: from 10.73.102.20 by snj1afswt02.equitable.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.3)); Tue, 26 Aug 2003 16:36:55 -0400 To: Aaa@ietf.org Message-ID: Date: Tue, 26 Aug 2003 16:33:48 -0400 X-MIMETrack: Serialize by Router on NJMAIL01/Equitable(Release 5.0.12 |February 13, 2003) at 08/26/2003 04:33:49 PM MIME-Version: 1.0 X-WSS-ID: 13551B6D3025893-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Aaa] Denise S Papish/NY/AXA-Financial/Equitable is out of the office. Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I will be out of the office from 08/25/2003 until 09/03/2003. I will respond to your message when I return. ********************************************************************** Confidentiality Note: This message and any attachments may contain legally privileged and/or confidential information. Any unauthorized disclosure, use or dissemination of this e-mail message or its contents, either in whole or in part, is prohibited. If you are not the intended recipient of this e-mail message, kindly notify the sender and then destroy it. ********************************************************************** _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Aug 27 13:14:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18908 for ; Wed, 27 Aug 2003 13:14:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s35c-0001CC-Io; Wed, 27 Aug 2003 12:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpks-0005U9-KE for aaa@optimus.ietf.org; Tue, 26 Aug 2003 22:09:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05410 for ; Tue, 26 Aug 2003 22:09:44 -0400 (EDT) From: zkrnetic@yahoo.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpkp-0000jy-00 for Aaa@ietf.org; Tue, 26 Aug 2003 22:09:47 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19rpkk-0000jp-00 for Aaa@ietf.org; Tue, 26 Aug 2003 22:09:42 -0400 To: Date: Wed, 27 Aug 2003 4:07:14 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_096360D2" Message-Id: Subject: [Aaa] Your details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_096360D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_096360D2 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_document.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_096360D2-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Aug 27 13:30:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20305 for ; Wed, 27 Aug 2003 13:30:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2vi-0000bl-7O; Wed, 27 Aug 2003 12:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ruMl-0006IV-7B for aaa@optimus.ietf.org; Wed, 27 Aug 2003 03:05:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29402 for ; Wed, 27 Aug 2003 03:05:09 -0400 (EDT) From: napredak@paleol.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ruMh-0007Qx-00 for Aaa@ietf.org; Wed, 27 Aug 2003 03:05:11 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19ruMd-0007Qb-00 for Aaa@ietf.org; Wed, 27 Aug 2003 03:05:07 -0400 To: Date: Wed, 27 Aug 2003 9:02:41 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0A71E08E" Message-Id: Subject: [Aaa] Re: Your application Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0A71E08E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0A71E08E Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0A71E08E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Aug 27 15:26:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00659 for ; Wed, 27 Aug 2003 15:26:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s48G-0005nP-WF; Wed, 27 Aug 2003 13:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s0QD-0003bt-8C for aaa@optimus.ietf.org; Wed, 27 Aug 2003 09:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26204 for ; Wed, 27 Aug 2003 09:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0QB-0005nM-00 for Aaa@ietf.org; Wed, 27 Aug 2003 09:33:11 -0400 Received: from smtp7.libero.it ([193.70.192.90]) by ietf-mx with esmtp (Exim 4.12) id 19s0QA-0005mj-00 for Aaa@ietf.org; Wed, 27 Aug 2003 09:33:10 -0400 Received: from smtp7.libero.it (193.70.192.90) by smtp7.libero.it (7.0.019) id 3F38C0E7003BDA4A for Aaa@ietf.org; Wed, 27 Aug 2003 15:32:40 +0200 Received: by smtp7.libero.it (7.0.019) id 3F38C0EC017034F4 for Aaa@ietf.org; Wed, 27 Aug 2003 15:32:40 +0200 From: Mail Delivery Service To: Aaa@ietf.org Date: Wed, 27 Aug 2003 15:32:40 +0200 Message-ID: <3F38C0EC017034F1@smtp7.libero.it> MIME-Version: 1.0 Content-Type: Multipart/Report; report-type=delivery-status; boundary="========/3F38C0EC017034EF/smtp7.libero.it" Subject: [Aaa] Delivery Status Notification Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This multi-part MIME message contains a Delivery Status Notification. If you can see this text, your mail client may not be able to understand MIME formatted messages or DSNs (see RFC 2045 through 2049 for general MIME information and RFC 1891 through 1894 for DSN specific information). --========/3F38C0EC017034EF/smtp7.libero.it Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit - These recipients of your message have been processed by the mail server: naneh@libero.it; Failed; 5.7.0 (other or undefined security status) --========/3F38C0EC017034EF/smtp7.libero.it Content-Type: Message/Delivery-Status Reporting-MTA: dns; smtp7.libero.it Received-from-MTA: dns; RKC-RUMNR1 (213.65.136.114) Arrival-Date: Wed, 27 Aug 2003 15:32:39 +0200 Final-Recipient: rfc822; naneh@libero.it Action: Failed Status: 5.7.0 (other or undefined security status) --========/3F38C0EC017034EF/smtp7.libero.it Content-Type: Text/RFC822-headers Return-Path: Received: from RKC-RUMNR1 (213.65.136.114) by smtp7.libero.it (7.0.019) id 3F38C0EC017034EF for naneh@libero.it; Wed, 27 Aug 2003 15:32:39 +0200 From: To: Subject: Re: Your application Date: Wed, 27 Aug 2003 15:30:07 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0BD4967B" --========/3F38C0EC017034EF/smtp7.libero.it-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Aug 27 19:21:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18036 for ; Wed, 27 Aug 2003 19:21:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4YR-0007dD-Hk; Wed, 27 Aug 2003 13:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s39X-0001Kv-8K for aaa@optimus.ietf.org; Wed, 27 Aug 2003 12:28:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13538 for ; Wed, 27 Aug 2003 12:28:05 -0400 (EDT) From: kojo@skaut.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s39V-00023b-00 for Aaa@ietf.org; Wed, 27 Aug 2003 12:28:09 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s39O-00022s-00 for Aaa@ietf.org; Wed, 27 Aug 2003 12:28:03 -0400 To: Date: Wed, 27 Aug 2003 18:25:30 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0C7418B4" Message-Id: Subject: [Aaa] Re: That movie Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0C7418B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0C7418B4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_all.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0C7418B4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Aug 27 22:45:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04903 for ; Wed, 27 Aug 2003 22:45:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sA5g-0008Cs-4V for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 19:52:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RNqeXH031538 for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 19:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s47g-0005hX-Nv for aaa-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 13:30:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20262 for ; Wed, 27 Aug 2003 13:30:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s47e-00043y-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 13:30:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s47d-00043v-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 13:30:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2vi-0000bl-7O; Wed, 27 Aug 2003 12:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ruMl-0006IV-7B for aaa@optimus.ietf.org; Wed, 27 Aug 2003 03:05:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29402 for ; Wed, 27 Aug 2003 03:05:09 -0400 (EDT) From: napredak@paleol.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ruMh-0007Qx-00 for Aaa@ietf.org; Wed, 27 Aug 2003 03:05:11 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19ruMd-0007Qb-00 for Aaa@ietf.org; Wed, 27 Aug 2003 03:05:07 -0400 To: Date: Wed, 27 Aug 2003 9:02:41 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0A71E08E" Message-Id: Subject: [Aaa] Re: Your application Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0A71E08E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0A71E08E Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0A71E08E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Aug 27 22:56:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06100 for ; Wed, 27 Aug 2003 22:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBgs-0006FM-Fh; Wed, 27 Aug 2003 21:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6Jf-0005BZ-2d for aaa@optimus.ietf.org; Wed, 27 Aug 2003 15:50:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02569 for ; Wed, 27 Aug 2003 15:50:46 -0400 (EDT) From: avadmin@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6Jd-0006vm-00 for Aaa@ietf.org; Wed, 27 Aug 2003 15:50:49 -0400 Received: from ogre-out.blic.net ([217.23.192.21] helo=ogre.blic.net ident=1007) by ietf-mx with smtp (Exim 4.12) id 19s6Jc-0006vh-00 for Aaa@ietf.org; Wed, 27 Aug 2003 15:50:48 -0400 Received: (qmail 20819 invoked from network); 27 Aug 2003 21:47:58 -0000 Date: Wed, 27 Aug 2003 21:47:58 +0000 Message-ID: To: Aaa@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="h7RLlwI01720538" X-Mailer: BLIC.NET Mailwall X-Priority: 1 (High) Subject: [Aaa] VIRUS POSLAN SA VASE ADRESE / VIRUS SENT FROM YOUR ADDRESS Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a MIME message ! --h7RLlwI01720538 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 VVBPWk9SRU5KRSBPIFZJUlVTSU1BIQ0KVklSVVMgV0FSTklORyENCg0KTmFzIGFudGl2aXJ1c 25pIHByb2dyYW0gamUgcHJvbmFzYW8gdmlydXNlIHUgcG9ydWNpIHBvc2xhbm9qIHNhIFZhc2 UgZW1haWwgYWRyZXNlOg0KT3VyIGFudGl2aXJ1cyBwcm9ncmFtIGhhcyBmb3VuZCB2aXJ1c2V zIGluIGEgbWVzc2FnZSBzZW50IGZyb20geW91ciBlbWFpbCBhZGRyZXNzOg0KDQpGcm9tOiBB YWFAaWV0Zi5vcmcNClRvOiBzenJuaXRjaEBibGljLm5ldAoNCg0KSXNwb3J1a2Egb3ZlIHBvc nVrZSBqZSBvYnVzdGF2bGplbmEuDQpEZWxpdmVyeSBvZiB0aGlzIG1lc3NhZ2Ugd2FzIHN0b3 BwZWQuDQoNCk1vbGltbyBWYXMgZGEgcHJvdmplcml0ZSBzdm9qIHJhY3VuYXIgcHJvdGl2IHZ pcnVzYSBpbGkgZGEgc2Ugb2JyYXRpdGUgYWRtaW5pc3RyYXRvcnUgemEgcG9tb2MuDQpQbGVh c2UgY2hlY2sgeW91ciBzeXN0ZW0gZm9yIHZpcnVzZXMsIG9yIGFzayB5b3VyIHN5c3RlbSBhZ G1pbmlzdHJhdG9yIHRvIGRvIHNvLg0KDQotLQ0KQkxJQy5ORVQgSVNQDQpodHRwOi8vd3d3Lm JsaWMubmV0Lw0KKzM4Ny01MS0yMTgtNDY5DQo= --h7RLlwI01720538-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Wed Aug 27 23:21:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08589 for ; Wed, 27 Aug 2003 23:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8y8-00050E-MH for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 18:40:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RMem1L019220 for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 18:40:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3sD-0004e7-HN for aaa-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 13:14:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18864 for ; Wed, 27 Aug 2003 13:14:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3sB-0003f6-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 13:14:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s3sA-0003f3-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 13:14:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s35c-0001CC-Io; Wed, 27 Aug 2003 12:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpks-0005U9-KE for aaa@optimus.ietf.org; Tue, 26 Aug 2003 22:09:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05410 for ; Tue, 26 Aug 2003 22:09:44 -0400 (EDT) From: zkrnetic@yahoo.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpkp-0000jy-00 for Aaa@ietf.org; Tue, 26 Aug 2003 22:09:47 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19rpkk-0000jp-00 for Aaa@ietf.org; Tue, 26 Aug 2003 22:09:42 -0400 To: Date: Wed, 27 Aug 2003 4:07:14 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_096360D2" Message-Id: Subject: [Aaa] Your details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_096360D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_096360D2 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_document.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_096360D2-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Aug 27 23:26:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09109 for ; Wed, 27 Aug 2003 23:26:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBuJ-0007Fo-60; Wed, 27 Aug 2003 21:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s56n-0001b9-CI for aaa@optimus.ietf.org; Wed, 27 Aug 2003 14:33:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24741 for ; Wed, 27 Aug 2003 14:33:23 -0400 (EDT) From: andrea@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s56k-0005D2-00 for Aaa@ietf.org; Wed, 27 Aug 2003 14:33:26 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s56b-0005Cz-00 for Aaa@ietf.org; Wed, 27 Aug 2003 14:33:17 -0400 To: Date: Wed, 27 Aug 2003 20:30:48 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0CE6C894" Message-Id: Subject: [Aaa] Re: Wicked screensaver Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0CE6C894 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0CE6C894 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0CE6C894-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 00:12:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13121 for ; Thu, 28 Aug 2003 00:12:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBkD-0006kM-LD for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 21:38:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1cbKp025928 for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 21:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5vd-00049J-6H for aaa-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 15:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00608 for ; Wed, 27 Aug 2003 15:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5vb-0006PN-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 15:25:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s5vb-0006PK-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 15:25:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s48G-0005nP-WF; Wed, 27 Aug 2003 13:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s0QD-0003bt-8C for aaa@optimus.ietf.org; Wed, 27 Aug 2003 09:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26204 for ; Wed, 27 Aug 2003 09:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0QB-0005nM-00 for Aaa@ietf.org; Wed, 27 Aug 2003 09:33:11 -0400 Received: from smtp7.libero.it ([193.70.192.90]) by ietf-mx with esmtp (Exim 4.12) id 19s0QA-0005mj-00 for Aaa@ietf.org; Wed, 27 Aug 2003 09:33:10 -0400 Received: from smtp7.libero.it (193.70.192.90) by smtp7.libero.it (7.0.019) id 3F38C0E7003BDA4A for Aaa@ietf.org; Wed, 27 Aug 2003 15:32:40 +0200 Received: by smtp7.libero.it (7.0.019) id 3F38C0EC017034F4 for Aaa@ietf.org; Wed, 27 Aug 2003 15:32:40 +0200 From: Mail Delivery Service To: Aaa@ietf.org Date: Wed, 27 Aug 2003 15:32:40 +0200 Message-ID: <3F38C0EC017034F1@smtp7.libero.it> MIME-Version: 1.0 Content-Type: Multipart/Report; report-type=delivery-status; boundary="========/3F38C0EC017034EF/smtp7.libero.it" Subject: [Aaa] Delivery Status Notification Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This multi-part MIME message contains a Delivery Status Notification. If you can see this text, your mail client may not be able to understand MIME formatted messages or DSNs (see RFC 2045 through 2049 for general MIME information and RFC 1891 through 1894 for DSN specific information). --========/3F38C0EC017034EF/smtp7.libero.it Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit - These recipients of your message have been processed by the mail server: naneh@libero.it; Failed; 5.7.0 (other or undefined security status) --========/3F38C0EC017034EF/smtp7.libero.it Content-Type: Message/Delivery-Status Reporting-MTA: dns; smtp7.libero.it Received-from-MTA: dns; RKC-RUMNR1 (213.65.136.114) Arrival-Date: Wed, 27 Aug 2003 15:32:39 +0200 Final-Recipient: rfc822; naneh@libero.it Action: Failed Status: 5.7.0 (other or undefined security status) --========/3F38C0EC017034EF/smtp7.libero.it Content-Type: Text/RFC822-headers Return-Path: Received: from RKC-RUMNR1 (213.65.136.114) by smtp7.libero.it (7.0.019) id 3F38C0EC017034EF for naneh@libero.it; Wed, 27 Aug 2003 15:32:39 +0200 From: To: Subject: Re: Your application Date: Wed, 27 Aug 2003 15:30:07 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0BD4967B" --========/3F38C0EC017034EF/smtp7.libero.it-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Aug 28 00:55:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16813 for ; Thu, 28 Aug 2003 00:55:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCbp-0001y1-7y; Wed, 27 Aug 2003 22:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s74C-0007Hu-6j for aaa@optimus.ietf.org; Wed, 27 Aug 2003 16:38:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06784 for ; Wed, 27 Aug 2003 16:38:50 -0400 (EDT) From: ap@mbox310.swipnet.se Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s74A-00006P-00 for Aaa@ietf.org; Wed, 27 Aug 2003 16:38:54 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s745-00006B-00 for Aaa@ietf.org; Wed, 27 Aug 2003 16:38:49 -0400 To: Date: Wed, 27 Aug 2003 22:36:21 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0D59BAF4" Message-Id: Subject: [Aaa] Re: Re: My details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0D59BAF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0D59BAF4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0D59BAF4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Aug 28 01:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19335 for ; Thu, 28 Aug 2003 01:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBfl-00061l-4P; Wed, 27 Aug 2003 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBaZ-0005hh-9L for aaa@optimus.ietf.org; Wed, 27 Aug 2003 21:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27868 for ; Wed, 27 Aug 2003 21:28:33 -0400 (EDT) From: nkrndija@banjaluka.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBaW-0005TN-00 for Aaa@ietf.org; Wed, 27 Aug 2003 21:28:36 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sBaP-0005Si-00 for Aaa@ietf.org; Wed, 27 Aug 2003 21:28:30 -0400 To: Date: Thu, 28 Aug 2003 3:26:04 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0E62F929" Message-Id: Subject: [Aaa] Re: Re: My details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0E62F929 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0E62F929 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0E62F929-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 03:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13380 for ; Thu, 28 Aug 2003 03:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFLR-0004hq-Mf for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 01:29:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S5TH2H018081 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 01:29:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDQc-0006Il-4t for aaa-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 23:26:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09075 for ; Wed, 27 Aug 2003 23:26:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sDQa-0000nA-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 23:26:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sDQZ-0000n7-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 23:26:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBuJ-0007Fo-60; Wed, 27 Aug 2003 21:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s56n-0001b9-CI for aaa@optimus.ietf.org; Wed, 27 Aug 2003 14:33:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24741 for ; Wed, 27 Aug 2003 14:33:23 -0400 (EDT) From: andrea@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s56k-0005D2-00 for Aaa@ietf.org; Wed, 27 Aug 2003 14:33:26 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s56b-0005Cz-00 for Aaa@ietf.org; Wed, 27 Aug 2003 14:33:17 -0400 To: Date: Wed, 27 Aug 2003 20:30:48 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0CE6C894" Message-Id: Subject: [Aaa] Re: Wicked screensaver Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0CE6C894 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0CE6C894 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0CE6C894-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Aug 28 04:23:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16003 for ; Thu, 28 Aug 2003 04:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFt5-0006J4-6Z; Thu, 28 Aug 2003 02:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDmL-00080b-20 for aaa@optimus.ietf.org; Wed, 27 Aug 2003 23:48:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11349 for ; Wed, 27 Aug 2003 23:48:51 -0400 (EDT) From: emina@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sDmI-0001P0-00 for Aaa@ietf.org; Wed, 27 Aug 2003 23:48:54 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sDmC-0001Ow-00 for Aaa@ietf.org; Wed, 27 Aug 2003 23:48:49 -0400 To: Date: Thu, 28 Aug 2003 5:46:24 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0EE37589" Message-Id: Subject: [Aaa] Re: Your application Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0EE37589 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0EE37589 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0EE37589-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 04:55:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18837 for ; Thu, 28 Aug 2003 04:55:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDL7-0005u8-9D for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 23:20:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3Kn6P022692 for aaa-archive@odin.ietf.org; Wed, 27 Aug 2003 23:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9b2-0006i1-GA for aaa-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 19:21:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18022 for ; Wed, 27 Aug 2003 19:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9b0-0002t7-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 19:20:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s9b0-0002t3-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 19:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4YR-0007dD-Hk; Wed, 27 Aug 2003 13:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s39X-0001Kv-8K for aaa@optimus.ietf.org; Wed, 27 Aug 2003 12:28:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13538 for ; Wed, 27 Aug 2003 12:28:05 -0400 (EDT) From: kojo@skaut.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s39V-00023b-00 for Aaa@ietf.org; Wed, 27 Aug 2003 12:28:09 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s39O-00022s-00 for Aaa@ietf.org; Wed, 27 Aug 2003 12:28:03 -0400 To: Date: Wed, 27 Aug 2003 18:25:30 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0C7418B4" Message-Id: Subject: [Aaa] Re: That movie Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0C7418B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0C7418B4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_all.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0C7418B4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Aug 28 04:58:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19128 for ; Thu, 28 Aug 2003 04:58:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDR8-0006NR-5L; Wed, 27 Aug 2003 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9JC-0005pO-7v for aaa@optimus.ietf.org; Wed, 27 Aug 2003 19:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16603 for ; Wed, 27 Aug 2003 19:02:26 -0400 (EDT) From: pecanac@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9J9-0002SW-00 for Aaa@ietf.org; Wed, 27 Aug 2003 19:02:31 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s9J3-0002SI-00 for Aaa@ietf.org; Wed, 27 Aug 2003 19:02:25 -0400 To: Date: Thu, 28 Aug 2003 0:59:58 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0DDD38DF" Message-Id: Subject: [Aaa] Re: Thank you! Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0DDD38DF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0DDD38DF Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0DDD38DF-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 05:44:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22356 for ; Thu, 28 Aug 2003 05:44:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJ8I-0001u3-Qc for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 05:31:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S9VwRq007314 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 05:31:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEoe-0002q8-JO for aaa-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 00:55:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16768 for ; Thu, 28 Aug 2003 00:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sEob-0002mj-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 00:55:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sEob-0002mg-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 00:55:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCbp-0001y1-7y; Wed, 27 Aug 2003 22:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s74C-0007Hu-6j for aaa@optimus.ietf.org; Wed, 27 Aug 2003 16:38:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06784 for ; Wed, 27 Aug 2003 16:38:50 -0400 (EDT) From: ap@mbox310.swipnet.se Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s74A-00006P-00 for Aaa@ietf.org; Wed, 27 Aug 2003 16:38:54 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s745-00006B-00 for Aaa@ietf.org; Wed, 27 Aug 2003 16:38:49 -0400 To: Date: Wed, 27 Aug 2003 22:36:21 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0D59BAF4" Message-Id: Subject: [Aaa] Re: Re: My details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0D59BAF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0D59BAF4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0D59BAF4-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 06:17:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25468 for ; Thu, 28 Aug 2003 06:17:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEV3-0001qN-Uw for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 00:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S4Z8gB007067 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 00:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCx7-0003x7-DE for aaa-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:56:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06088 for ; Wed, 27 Aug 2003 22:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCx3-0007lw-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 22:55:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCx3-0007lt-00 for aaa-web-archive@ietf.org; Wed, 27 Aug 2003 22:55:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBgs-0006FM-Fh; Wed, 27 Aug 2003 21:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6Jf-0005BZ-2d for aaa@optimus.ietf.org; Wed, 27 Aug 2003 15:50:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02569 for ; Wed, 27 Aug 2003 15:50:46 -0400 (EDT) From: avadmin@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6Jd-0006vm-00 for Aaa@ietf.org; Wed, 27 Aug 2003 15:50:49 -0400 Received: from ogre-out.blic.net ([217.23.192.21] helo=ogre.blic.net ident=1007) by ietf-mx with smtp (Exim 4.12) id 19s6Jc-0006vh-00 for Aaa@ietf.org; Wed, 27 Aug 2003 15:50:48 -0400 Received: (qmail 20819 invoked from network); 27 Aug 2003 21:47:58 -0000 Date: Wed, 27 Aug 2003 21:47:58 +0000 Message-ID: To: Aaa@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="h7RLlwI01720538" X-Mailer: BLIC.NET Mailwall X-Priority: 1 (High) Subject: [Aaa] VIRUS POSLAN SA VASE ADRESE / VIRUS SENT FROM YOUR ADDRESS Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a MIME message ! --h7RLlwI01720538 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 VVBPWk9SRU5KRSBPIFZJUlVTSU1BIQ0KVklSVVMgV0FSTklORyENCg0KTmFzIGFudGl2aXJ1c 25pIHByb2dyYW0gamUgcHJvbmFzYW8gdmlydXNlIHUgcG9ydWNpIHBvc2xhbm9qIHNhIFZhc2 UgZW1haWwgYWRyZXNlOg0KT3VyIGFudGl2aXJ1cyBwcm9ncmFtIGhhcyBmb3VuZCB2aXJ1c2V zIGluIGEgbWVzc2FnZSBzZW50IGZyb20geW91ciBlbWFpbCBhZGRyZXNzOg0KDQpGcm9tOiBB YWFAaWV0Zi5vcmcNClRvOiBzenJuaXRjaEBibGljLm5ldAoNCg0KSXNwb3J1a2Egb3ZlIHBvc nVrZSBqZSBvYnVzdGF2bGplbmEuDQpEZWxpdmVyeSBvZiB0aGlzIG1lc3NhZ2Ugd2FzIHN0b3 BwZWQuDQoNCk1vbGltbyBWYXMgZGEgcHJvdmplcml0ZSBzdm9qIHJhY3VuYXIgcHJvdGl2IHZ pcnVzYSBpbGkgZGEgc2Ugb2JyYXRpdGUgYWRtaW5pc3RyYXRvcnUgemEgcG9tb2MuDQpQbGVh c2UgY2hlY2sgeW91ciBzeXN0ZW0gZm9yIHZpcnVzZXMsIG9yIGFzayB5b3VyIHN5c3RlbSBhZ G1pbmlzdHJhdG9yIHRvIGRvIHNvLg0KDQotLQ0KQkxJQy5ORVQgSVNQDQpodHRwOi8vd3d3Lm JsaWMubmV0Lw0KKzM4Ny01MS0yMTgtNDY5DQo= --h7RLlwI01720538-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Aug 28 07:46:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04731 for ; Thu, 28 Aug 2003 07:46:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJi9-0004P6-O6; Thu, 28 Aug 2003 06:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFw3-0006aY-Di for aaa@optimus.ietf.org; Thu, 28 Aug 2003 02:07:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29283 for ; Thu, 28 Aug 2003 02:07:02 -0400 (EDT) From: Anna_Greta@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sFvz-0004Rk-00 for Aaa@ietf.org; Thu, 28 Aug 2003 02:07:03 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sFvq-0004Rh-00 for Aaa@ietf.org; Thu, 28 Aug 2003 02:06:55 -0400 To: Date: Thu, 28 Aug 2003 8:04:32 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0F61EA88" Message-Id: Subject: [Aaa] Re: Wicked screensaver Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0F61EA88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0F61EA88 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_all.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0F61EA88-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 07:54:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05349 for ; Thu, 28 Aug 2003 07:54:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJvq-0005Ep-6h for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 06:23:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SANA4Y020135 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 06:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFJR-0004Tx-63 for aaa-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 01:27:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19283 for ; Thu, 28 Aug 2003 01:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sFJN-0003Wj-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 01:27:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sFJN-0003Wg-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 01:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBfl-00061l-4P; Wed, 27 Aug 2003 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBaZ-0005hh-9L for aaa@optimus.ietf.org; Wed, 27 Aug 2003 21:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27868 for ; Wed, 27 Aug 2003 21:28:33 -0400 (EDT) From: nkrndija@banjaluka.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBaW-0005TN-00 for Aaa@ietf.org; Wed, 27 Aug 2003 21:28:36 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sBaP-0005Si-00 for Aaa@ietf.org; Wed, 27 Aug 2003 21:28:30 -0400 To: Date: Thu, 28 Aug 2003 3:26:04 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0E62F929" Message-Id: Subject: [Aaa] Re: Re: My details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0E62F929 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0E62F929 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0E62F929-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 09:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15795 for ; Thu, 28 Aug 2003 09:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sK6Z-00063I-RG for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 06:34:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SAYFL8023254 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 06:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sI3Z-0007Ax-Cx for aaa-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 04:23:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15970 for ; Thu, 28 Aug 2003 04:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sI3W-0007Fb-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 04:22:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sI3V-0007FY-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 04:22:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFt5-0006J4-6Z; Thu, 28 Aug 2003 02:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDmL-00080b-20 for aaa@optimus.ietf.org; Wed, 27 Aug 2003 23:48:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11349 for ; Wed, 27 Aug 2003 23:48:51 -0400 (EDT) From: emina@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sDmI-0001P0-00 for Aaa@ietf.org; Wed, 27 Aug 2003 23:48:54 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sDmC-0001Ow-00 for Aaa@ietf.org; Wed, 27 Aug 2003 23:48:49 -0400 To: Date: Thu, 28 Aug 2003 5:46:24 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0EE37589" Message-Id: Subject: [Aaa] Re: Your application Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0EE37589 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0EE37589 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0EE37589-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Thu Aug 28 10:03:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16554 for ; Thu, 28 Aug 2003 10:03:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKtn-0002YH-Lr; Thu, 28 Aug 2003 07:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIGd-0007yi-7I for aaa@optimus.ietf.org; Thu, 28 Aug 2003 04:36:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17298 for ; Thu, 28 Aug 2003 04:36:25 -0400 (EDT) From: robert_dykes@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIGa-0007bM-00 for Aaa@ietf.org; Thu, 28 Aug 2003 04:36:28 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sIGT-0007b6-00 for Aaa@ietf.org; Thu, 28 Aug 2003 04:36:21 -0400 To: Date: Thu, 28 Aug 2003 10:33:55 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0FEAAE3E" Message-Id: Subject: [Aaa] Re: Re: My details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0FEAAE3E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0FEAAE3E Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0FEAAE3E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 10:25:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19308 for ; Thu, 28 Aug 2003 10:25:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKqz-0002BB-8b for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 07:22:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SBMD5g008357 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 07:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIb4-0000pw-Bo for aaa-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 04:57:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19088 for ; Thu, 28 Aug 2003 04:57:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIb1-0000HS-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 04:57:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sIb0-0000HP-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 04:57:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDR8-0006NR-5L; Wed, 27 Aug 2003 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9JC-0005pO-7v for aaa@optimus.ietf.org; Wed, 27 Aug 2003 19:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16603 for ; Wed, 27 Aug 2003 19:02:26 -0400 (EDT) From: pecanac@blic.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9J9-0002SW-00 for Aaa@ietf.org; Wed, 27 Aug 2003 19:02:31 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19s9J3-0002SI-00 for Aaa@ietf.org; Wed, 27 Aug 2003 19:02:25 -0400 To: Date: Thu, 28 Aug 2003 0:59:58 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0DDD38DF" Message-Id: Subject: [Aaa] Re: Thank you! Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0DDD38DF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0DDD38DF Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_9446.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0DDD38DF-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 12:26:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27901 for ; Thu, 28 Aug 2003 12:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sLum-0005o3-RH for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 08:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SCUCjj022309 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 08:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sLEK-0003tB-Cm for aaa-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 07:46:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04658 for ; Thu, 28 Aug 2003 07:46:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sLEJ-0004Q5-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 07:46:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sLEI-0004Q0-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 07:46:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJi9-0004P6-O6; Thu, 28 Aug 2003 06:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFw3-0006aY-Di for aaa@optimus.ietf.org; Thu, 28 Aug 2003 02:07:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29283 for ; Thu, 28 Aug 2003 02:07:02 -0400 (EDT) From: Anna_Greta@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sFvz-0004Rk-00 for Aaa@ietf.org; Thu, 28 Aug 2003 02:07:03 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sFvq-0004Rh-00 for Aaa@ietf.org; Thu, 28 Aug 2003 02:06:55 -0400 To: Date: Thu, 28 Aug 2003 8:04:32 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0F61EA88" Message-Id: Subject: [Aaa] Re: Wicked screensaver Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0F61EA88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0F61EA88 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: document_all.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0F61EA88-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Aug 28 17:46:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21868 for ; Thu, 28 Aug 2003 17:46:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sR8i-00053t-5g for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 14:04:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SI4uo1019448 for aaa-archive@odin.ietf.org; Thu, 28 Aug 2003 14:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sNN4-0002Xk-Nv for aaa-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 10:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16472 for ; Thu, 28 Aug 2003 10:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sNN2-0007dL-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 10:03:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sNN1-0007dH-00 for aaa-web-archive@ietf.org; Thu, 28 Aug 2003 10:03:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKtn-0002YH-Lr; Thu, 28 Aug 2003 07:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIGd-0007yi-7I for aaa@optimus.ietf.org; Thu, 28 Aug 2003 04:36:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17298 for ; Thu, 28 Aug 2003 04:36:25 -0400 (EDT) From: robert_dykes@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIGa-0007bM-00 for Aaa@ietf.org; Thu, 28 Aug 2003 04:36:28 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19sIGT-0007b6-00 for Aaa@ietf.org; Thu, 28 Aug 2003 04:36:21 -0400 To: Date: Thu, 28 Aug 2003 10:33:55 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0FEAAE3E" Message-Id: Subject: [Aaa] Re: Re: My details Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0FEAAE3E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0FEAAE3E Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0FEAAE3E-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa